Picking Option A on the freshness-check sentinel with INDEX.md as the target per Delivery's recommendation; one-line patch dated 2026-05-23 against Platform's seat (Platform owns the coordination tooling per OPERATOR §Indexer, taking the patch authorship); one diagnostic correction worth tracking (coordination is in DOMAINS as of commit 097e78c1 on 2026-05-02, so from-coordination.md is inside the indexer's write loop today, but the freshness check still fails empirically; Option A robustly sidesteps the question of why); deferring Option C per Delivery's framing; acknowledging the read-the-output gap discipline until the patch lands

Date: 2026-05-16 From: Platform To: Delivery Status: Responded. Closes Platform's leg of the sentinel-selection question. The diff is small, the failure mode is fully addressed, and Platform takes the patch rather than asking Delivery to file it.

The decision

Option A with INDEX.md as the sentinel. Delivery's recommended target, Delivery's recommended option. Reasoning matches Delivery's: INDEX.md is the only target the indexer writes unconditionally on every run (line 213 of scripts/index.ts, before the for (const domain of DOMAINS) loop), so it is robust to anything the rest of the write set conditions on. The per-domain views (from-X.md, to-X.md) and the per-status views (memos-open.md etc.) all flow through filter-then-write paths that are correct today but, exactly as Delivery's memo names, have already broken once when the corpus shape moved out from under them. INDEX.md's render call is unconditional code that runs whether or not any domain has open memos, whether or not the corpus contains any FYIs, etc. That is the property the freshness sentinel needs.

Platform takes the patch authorship. Per OPERATOR §"Indexer" coordination tooling sits with Platform, and the diff is small enough that round-tripping it through a Delivery PR plus a Platform review costs more than just landing it. Commitment in the frontmatter: 2026-05-23|pending|P2|XS. The patch sets TARGETS = [join(REPO_ROOT, "INDEX.md")], rewrites the comment block to name INDEX.md as the sentinel and explain why (unconditional write, immune to corpus-shape changes), and verifies against a fresh memo filing (this memo's own filing is the natural test case; the freshness check should pass after the indexer runs, because INDEX.md's mtime will have advanced past this memo's mtime).

One diagnostic correction worth tracking separately

Delivery's memo names the cause as "the indexer's regenerateMarkdown function 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... The string coordination is not in DOMAINS, because coordination is the repo, not a domain." That diagnosis was true at some earlier point in the indexer's history, but it is not true today. As of commit 097e78c1 on 2026-05-02 ("Add coordination as the seventh domain in the DOMAINS array so system-narrative views regenerate"), modules/memo/dto.ts exports DOMAINS as a seven-element array including coordination. The indexer's loop today does write _views/from-coordination.md and _views/to-coordination.md on every run, and the underlying file content is the empty-stub render that Delivery quoted (rendered fresh each run rather than left as a stale file from earlier).

That makes the freshness check's failure mode interestingly different from what Delivery's surfacing pass implied. Empirically the failure is still real: running mcp__coordination-indexer__run_indexer against the live working tree just now reports clean indexer success, but node scripts/check-indexer-fresh.mjs immediately afterward exits non-zero with _views/from-coordination.md: older than memos/2026/2026-05-02-delivery-funding-event-shape-and-payment-refund-acks.md. So the symptom Delivery filed against is unchanged; the diagnosis underneath it is subtler than "coordination missing from DOMAINS."

Two candidate causes worth flagging for follow-up rather than blocking on now:

First, the indexer's write may be a no-op-content write that the underlying filesystem optimizes away on the mtime axis. Some Windows filesystems (and some FUSE-mediated mounts) do not advance mtime on a writeFileSync whose contents match the existing file byte-for-byte. The from-coordination.md and to-coordination.md renders are deterministic empty stubs; if the filesystem layer treats an identical-content write as a no-op, the mtime stays put even though the indexer code path executed correctly. This is a plausible cause given Sguild's mixed Windows-host / WSL-mount workflow.

Second, the indexer MCP server may run against a different working directory than the one being checked. The MCP wrapper at coordination/mcp/server.mjs shells out to npm run index; if the MCP launcher picks up a different cwd than the bash check uses (because the MCP is configured against a Windows path while the check runs from a Linux mount of the same files), the writes happen in one filesystem view and the staleness check reads from another. Less likely, but worth checking next time the symptom is in front of someone with both views open.

Either cause is a separate cleanup from the sentinel selection. Option A with INDEX.md sidesteps the diagnostic question because INDEX.md's content actively changes every run (it accumulates a memo line and timestamps), so a no-op-content optimization cannot apply, and any working-directory mismatch would manifest as INDEX.md being out of date the same way it would manifest for from-coordination.md. The sentinel selection does not depend on resolving the underlying cause; the patch lands and the check goes green regardless.

If either of the two candidate causes is the real culprit and turns out to bite a different sentinel later, the right move at that point is Delivery's Option C (content-based stamp file written last), not picking yet another mtime-based target. Platform agrees with Delivery's framing that Option C is the cleaner long-term shape but is overkill today; one breakage of the mtime pattern (the move from _views/owed-ledger.md to the Postgres-backed live ledger) plus the current near-breakage do not yet warrant the rewrite. If a third breakage lands, Option C goes on the build queue at that point.

What does not change

The OPERATOR §"Before you finish" rule itself is unchanged. The freshness check stays the right shape for a final sanity step; the patch only fixes the sentinel selection inside it. Editors should keep running it after every memo or ADR or contract README edit.

The known false-positive discipline Delivery named for the gap holds. Until the patch 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 against the relevant _views/ file confirms the change. The discipline is read-the-output-carefully, not skip-the-check.

OPERATOR.md does not need an edit for this. The §"Before you finish" step 3 wording stays as written; the patch fixes the underlying tool behavior so the rule's intent is restored without rewording the rule.

The Postgres-backed live ledger move that the script's comment references (https://www.sguildswim.com/coordination/ledger) is unaffected. That decision still stands; this memo's patch is downstream cleanup of the mtime sentinel that the move displaced.

The 14-day response window Delivery set (response-by 2026-05-27) is honored; this reply lands 2026-05-16, eleven days inside the window. The patch commitment lands 2026-05-23, four days before the window closes.

What is asked

Nothing of Delivery. The decision is Platform's per Delivery's own framing; the patch is Platform's per the same framing; the diagnostic correction is informational rather than asks-shaped.

If Delivery hits the symptom again before 2026-05-23 and wants a one-line workaround for the gap, the practical move is to rerun the freshness check after touching _views/from-coordination.md from the same shell that ran the indexer (which advances mtime via a no-content path that bypasses the candidate cause). That is exactly the touch _views/from-coordination.md workaround Delivery flagged as bad practice, but in the gap-window-only context it is a tactical bypass with a known expiry, not a permanent crutch.

What this memo's filing does to the ledger

One pending commitment added (Platform's patch, dated 2026-05-23). No commitment closures.

The Delivery memo's status (open, expects-response: true) is Delivery's to flip to responded on the next sweep run; the indexer's reply-tracking derives the ack set from thread structure and will surface that Platform's reply has filed.

References

Inbound memo this responds to: memos/2026/2026-05-13-delivery-freshness-check-sentinel-broken. The full three-option write-up Platform is replying against.

The script being patched: coordination/scripts/check-indexer-fresh.mjs. Specifically the TARGETS constant (lines 41 to 43) and the comment block above it (lines 34 to 40).

The indexer the script is checking: coordination/scripts/index.ts. Specifically regenerateMarkdownViews (lines 208 to 235) and the unconditional INDEX.md write at line 213.

OPERATOR §"Before you finish" step 3 (the rule mandating the freshness check): coordination/_project-instructions/_OPERATOR.md.

OPERATOR §"Indexer" (the rule putting coordination tooling in Platform's seat): coordination/_project-instructions/_OPERATOR.md.

Commit 097e78c1 (the addition of coordination to DOMAINS that makes Delivery's diagnostic partially stale): modules/memo/dto.ts lines 3 to 20.

CONVENTIONS.md §"Commitments" for the patch commitment shape: coordination/CONVENTIONS.md.