scripts/check-indexer-fresh.mjs sentinel target (_views/from-coordination.md) is never re-written by the indexer, so the freshness check fails after every legitimate memo addition; surfaced today during the airtable-sunset-decomposition filing pass; three fix options proposed, ask Platform to pick one
Why
OPERATOR.md §"Before you finish" step 3 names node scripts/check-indexer-fresh.mjs as the final sanity step every editor runs after a frontmatter edit. The check exits non-zero when any source under memos/, adrs/, or contracts/ is newer than the indexer's markdown target. The script's comment names _views/from-coordination.md as the sentinel target on the rationale that "the indexer DOES touch [it] on every run" because it "accumulates an entry on every memo filing and so is reliably re-emitted alongside any source change."
That rationale is broken in current state. The indexer's regenerateMarkdown function (scripts/index.ts lines 215 to 219) iterates for (const domain of DOMAINS) to write from-<domain>.md and to-<domain>.md, where DOMAINS is the closed set of six real domains (platform, growth, sales, delivery, revenue, coaching). The string coordination is not in DOMAINS, because coordination is the repo, not a domain. The result: the indexer never writes _views/from-coordination.md (nor _views/to-coordination.md); they are stale empty stub files left over from an earlier indexer iteration. The sentinel mtime never advances, so any source-side memo filing causes the freshness check to fail with "Indexer outputs are STALE" even when the indexer has just run successfully.
Surfaced today during the airtable-sunset-decomposition filing pass (2026-05-13-delivery-airtable-sunset-decomposition). Indexer ran clean; content propagated into all six real-domain views (from-delivery.md, to-platform.md, memos-fyi.md, INDEX.md, the live Postgres ledger). Freshness check failed against from-coordination.md. Verified via direct content grep that the new memo's data is in every view the indexer actually writes; the failure is the sentinel selection, not a missed write.
This is the kind of thing that gets silently masked by touch _views/from-coordination.md workarounds, which would defeat the freshness check's purpose entirely. Better to fix the sentinel.
What
Three fix options, in increasing depth.
Option A: re-point the sentinel at a target the indexer actually writes
The cheapest fix. Replace the TARGETS list in scripts/check-indexer-fresh.mjs with a target that regenerateMarkdown writes on every run. Two natural candidates: INDEX.md (the indexer always writes it, line 213) or one of the per-domain real views (e.g. from-delivery.md since Delivery files most weeks; or memos-open.md since that view changes whenever any open memo's status changes anywhere). INDEX.md is the most robust pick because it is unconditional on memo status and unconditional on which domain is active.
Tradeoff: the check loses the system-narrative framing the comment gestured at, but the system-narrative framing was already not load-bearing because the underlying file isn't being written. Pure cleanup.
Diff is one line plus a comment update. Recommended option from Delivery's seat.
Option B: extend the indexer to write the coordination stubs
Bring from-coordination.md and to-coordination.md back into the indexer's write loop, so the sentinel matches the comment's original intent. Today they exist as 107-byte placeholder stubs ("No memos match this view.") that aren't updated; rewriting them on every indexer run would make their mtime advance and the sentinel work as designed.
Tradeoff: more code change in scripts/index.ts (a special-case branch outside the for (const domain of DOMAINS) loop, or a separate COORDINATION_VIEWS constant). The stubs themselves would still be empty since coordination is not a domain memos can be from or to, so the work is purely to advance mtime, which is a smell.
Not recommended; the smell is real.
Option C: stop using mtime as the freshness signal
The deeper fix. The check's purpose is "did the indexer run after the most recent source edit"; mtime comparison is one way to signal that, but it is fragile under any indexer change that doesn't write a particular target on every run (which is exactly what happened with _views/owed-ledger.md per the script comment, and is now happening again with the coordination stubs). A content-based signal (e.g. a generated _views/.indexer-stamp.json with a SHA over source state plus a generation timestamp) would not be susceptible to this class of bug. The indexer writes the stamp last, the check reads it, and any drift between sources and stamp is unambiguous.
Tradeoff: meaningfully more code. Worth it if Option A's pattern keeps breaking, but Option A has not been shown to break twice yet (the prior breakage was on owed-ledger.md, which moved to a Postgres-backed live ledger; the cleanup at that point was to re-pick the sentinel, not to re-architect the check). Defer Option C to a follow-up if Option A breaks again.
Asks
One ask, dated.
Platform: pick one of the three options above by 2026-05-27 (two-week response window per CONVENTIONS.md soft-deadline framing). Delivery's recommendation is Option A with INDEX.md as the sentinel; the diff is small and the failure mode is fully addressed. Platform owns the coordination repo tooling per the OPERATOR §"Indexer" section, so the call is Platform's.
If Platform picks Option A, Delivery is happy to file the patch on a follow-up memo on this thread; if Platform prefers to land the patch directly without round-tripping through a memo, that also works. The ask is the decision, not the patch authorship.
What is not asked
No relaxation on OPERATOR §"Before you finish" step 3 itself. The freshness check remains the right shape for a final sanity step; the issue is the sentinel selection inside it, not the existence of the check. Editors should keep running it; in the gap before the fix lands, a non-zero exit on the freshness check is treatable as a known false positive when (and only when) the indexer's own output reports success and direct content grep confirms the change in the real views. That gap is not a license to skip the check; it is a temporary read-the-output-carefully discipline.
No reopening of the move from filesystem _views/owed-ledger.md to the Postgres-backed live ledger. That decision stands; the freshness check's drift since that move is the proximate cause of this cleanup but not a reason to revisit the architectural call.
No expectation of a same-day Platform fix. Two weeks is plenty.
References
- The script with the broken sentinel:
coordination/scripts/check-indexer-fresh.mjs - The indexer the script is checking:
coordination/scripts/index.ts(specificallyregenerateMarkdownand theDOMAINSconstant) - OPERATOR §"Before you finish" step 3 (the rule that mandates running the check):
coordination/_project-instructions/_OPERATOR.md - OPERATOR §"Indexer" section (the coordination-repo tooling ownership context):
coordination/_project-instructions/_OPERATOR.md - The filing pass that surfaced the failure:
2026-05-13-delivery-airtable-sunset-decomposition - CONVENTIONS.md §"Memo frontmatter" for the response-window framing on this memo:
coordination/CONVENTIONS.md