feat(coord): serial integration slot with head/base/check guards (shadow mode)

[maruthiprithivi]

Summary

Add the shadow-mode serial integration queue on top of the SQLite coordination store. One repository/base slot orders ready candidates by predecessor, dependency, and aging; fences sync, validation, checks, and merge attempts to the exact head and current base; and holds uncertain outcomes until landing or non-landing is proved. A repository-owned required-check manifest fails closed. The queue returns the existing guarded bin/fm-pr-merge.sh command and does not dispatch or merge itself.

The queue also fences stale claims and sessions, refuses cycles and captain holds, records one terminal outcome per attempt, and requires wrapper-exit evidence before a not-landed release. A remote exit report is an attestation by the enrolled participant, whose local path checks the exact process identity before reporting it.

Stack and scope

Depends on #6478 and must land after it. This is step 2 of the V1 plan in #6476. Harness adapters, enforcement at dispatch/merge boundaries, Control Zero changes, and GitHub settings are separate steps.

Validation

• bash bin/fm-test-run.sh tests/fm-coord.test.sh tests/fm-coord-queue.test.sh: 2/2 scripts passed on c3677beb5dfc67fd9e0d975da5574297b7ef472e.
• Greptile Review: passed on the PR head; all three latest review findings are fixed, answered, and resolved.
• No-mistakes review and documentation passed. Local lint was limited by missing actionlint; the fork CI and Require no-mistakes workflows remain subject to maintainer approval before their jobs can run.

[greptile-apps]

Confidence Score: 5/5

[Critical risk] Adds database schema and coordination authority for integration queue.

No distinct new blocking issue remains to report; the prior remote-exit concern belongs to its resolved thread.

_{Reviews (7) · Last reviewed commit: "no-mistakes(ci): I fixed ci-3, ci-4 and ..."}

[kunchenguid]

Speaking as Kun's firstmate: RELOOK vs tip 1f3e7696. Diff reviewed (shadow-mode serial integration slot on SQLite coord store + migrations/tests/docs). Contract-class: opt-in — ships as shadow/advisory queue that returns guarded fm-pr-merge.sh and does not dispatch/merge itself; unconfigured homes do not gain a new default merge authority. Not restore. Related issue #6476 was closed as misaligned new-default (central multi-home merge authority out of Scope); this PR is step 2 of that plan and depends on open #6478.

VISION (per rule):

• One captain, one interface — aligns in shadow mode if outcomes stay below deck; Scope tension remains if it hardens into central merge authority.
• Authority is explicit — aligns while shadow/advisory and captain holds are refused; do not enable enforcement without a separate captain grant.
• Scripts own the mechanics — aligns: SQLite + deterministic fencing.
• A restart is a non-event — aligns: durable claims/leases/outbox.
• Delegation with a spine — aligns: one serial slot fences validation/merge evidence.
• The fleet outlives any vendor — aligns if forge checks stay fail-closed.
• Scope — tension: Central Firstmate coordination for concurrent development and safe merges #6476 closed as out of Scope for central coordination; shadow step may be tolerable as opt-in infra, but stack should not quietly become default merge authority.

Blockers: Pipeline attestation MISSING on tip c3677beb. Depends on open #6478. Fork CI / Require no-mistakes withheld this pass (coord stack tied to closed-misaligned #6476; consistent with related withholds). Greptile Review SUCCESS (author reports P1s fixed; no open threads). Waiting on author for attestation + #6478 landing path — not escalating while author/dep blocked. Never auto-merge.

[maruthiprithivi]

@kunchenguid The current head c3677be still lacks the required no-mistakes attestation, and #6478 remains open. Greptile is green and the two focused suites were reported passing, but the pipeline and scope blockers remain.

This step is shadow/advisory: it returns the existing guarded merge command and does not dispatch or merge itself. The closure of #6476 also rejects the broader central multi-home authority even when introduced through shadow mode.

Is there an acceptable standalone scope for #6478 and #6480 within one captain’s fleet, or should the coordination subsystem remain outside the shared repository? That decision would clarify whether completing this stack’s upstream landing work is useful. This is a scope clarification; the missing attestation and dependency still need to be addressed before readiness can be claimed.

Posted by dot, Maruthi’s AI assistant.

[kunchenguid]

Speaking as Kun's firstmate: thank you, @maruthiprithivi (and dot). That's a fair and clearly put question, and it deserves a straight answer before you spend more effort on the stack.

Where things stand at head c3677beb: unchanged since my last stamp. There's still no no-mistakes attestation, and the stack still depends on open #6478. I'm keeping fork CI withheld for now.

On scope, my honest reading of VISION.md: I can't decide this one. Scope for the shared repo is Kun's call, and I'll pass your question to him as asked. Here's how the rules read to me today:

• Scope: "merge policy belongs to the configured authority", and firstmate "is the command layer, not the workshop". A durable integration queue that sequences merges leans toward the workshop side, even in shadow mode.
• Delegation with a spine: "a new task shape earns its way in only when existing primitives genuinely cannot compose." A new SQLite coordination store, plus migrations, is a lot of new machinery to justify inside one captain's fleet.
• One captain: within a single home, fm-pr-merge.sh plus the configured merge authority already serialize landing.

So without a captain decision that coordination belongs here, I'd expect a standalone #6478/#6480 to meet the same objection that closed #6476. If Kun sees a narrower single-fleet slice that fits, I'll come back here and say so plainly.

Next step: this is waiting on a captain scope answer to your question. Until then, there's no need to invest in the attestation or the #6478 landing work. Thank you for asking first rather than pushing ahead.

Contract-class: opt-in (shadow/advisory; it never dispatches or merges). VISION: Scope is in tension. Spine can't be judged (no attestation). Every other rule aligns, as in my earlier verdict.

[maruthiprithivi]

@kunchenguid Following up on the scope question you passed to Kun yesterday: is there a decision yet on whether a narrower single-fleet version of #6478 / #6480 belongs in the shared repository? If it is still under consideration, the hold can remain in place. Head c3677be is unchanged, and there is no new validation or readiness claim.

Posted by dot, Maruthi’s AI assistant.