Documented vs. planned vs. live.
And what's actually broken.

✓ Resolved major D3 STEWARD.md ceremony violates the "No boot-turn race" rule

STEWARD.md steps 6 → 7 → 8 vs. config.html § Rotation governance L262–263

Step 6 spawns with initialMessage (boot turn begins). Step 7 immediately calls m_release_session({keepPendingTurn:true}) — the handle is dropped while the boot turn is still pending, and no m_await_session_response is ever inserted for the boot ack. Step 8 then sends "## Replacement readiness". The smoke-test message arrives queued behind the boot turn; the Steward awaits the first response, which is the boot ack (a ## Context health block), reads it as a failed readiness response, and step 10 fires — m_close_session on a healthy successor + Teams-pings Charlie "rotation aborted".

Fix. Between step 6 and step 7 insert m_await_session_response(<new>, timeoutMs: 600000), validate a green ## Context health ack, then release with keepPendingTurn:false.

Shipped by Unit B — STEWARD.md ceremony rewritten to await a green ## Context health ack before release; the boot-turn-race invariant is preserved.

✓ Resolved major D4 Orphan-turn race in rotate skill step 4 → 5

rotate-clawpilot-role/SKILL.md steps 4–5 vs. plan.md L129–130 ORPHAN-TURN LESSON

Step 4 does m_release_session({keepPendingTurn:false}); step 5 immediately m_send_to_session with the heavy readiness probe — exactly the anti-pattern plan.md L129–130 warned about ("Re-messaging a just-RELEASED session handle caused an adoption race… awaits returned status:timeout forever"). The lesson was learned by the Operator on the orchestrator but never folded back into the rotate skill or STEWARD.md. Same downstream as D3: false smoke-test timeout → healthy-successor kill.

Fix. Insert a 1-line status-probe send-and-await between step 4 release and step 5 readiness probe (e.g. m_send_to_session({sessionName, message:"ping — confirm adopted"}) + m_await_session_response) to cleanly re-adopt the handle before the heavy probe.

Shipped by Units A + B — the status-probe re-adopt is folded into the new rotate-role skill between the release and the readiness probe.

✓ Resolved major D5 ZOMBIE path violates "metadata-only" + lacks the Charlie-ack guard for delete:true

STEWARD.md L131 vs. STEWARD.md L19/L42/L186 + config.html § Rotation governance L258–259

The ZOMBIE branch says: "synthesize state from last 20 turns via m_get_session_transcript" and on success "m_close_session({delete:true}) (delete the zombie, Charlie accepted the risk)". The brief's own hard rules contradict both halves — reading 20 turns of a peer's transcript IS reading content ("metadata only", "privacy of peer thought process is a feature"), and delete:true is documented as requiring an explicit Charlie ack quoted in the ledger. "Charlie accepted the risk" is asserted, not requested.

Fix. Require an inline m_ask_user Charlie-ack (quoting the zombie's sessionId + lastActivityAt) before the transcript read and the delete:true close; or downgrade to delete:false (archive) and surface post-facto.

Shipped by Unit B — rotate-role now defaults to cold-spawn + archive (no transcript read, no delete); the escalated transcript-read / delete:true path requires an explicit Charlie m_ask_user ack quoting the zombie's sessionId + lastActivityAt.

✓ Resolved major D6 Steward self-rotation has no defined procedure; "rotator spawns successor" invariant is unreconciled

STEWARD.md L110 · rotate-clawpilot-role L16 / L212 · config.html L240–242

The only mention of self-rotation is a one-line do-not ("Never rotate yourself without explicit Charlie ack"). No procedure for who spawns the successor — the rotator-spawns-successor invariant is circular when rotator equals rotatee. The rotate skill (L212) references "Steward (self-rotation case): broadcast confirmation, ask Operator to update the ledger", implying either the outgoing Steward spawned the successor (invariant break) or the Operator did (undocumented). config.html L240–242 confirms two Steward self-rotations have actually happened this engagement — this is a live gap, not hypothetical.

Fix. Add a one-paragraph "Steward self-rotation" branch to STEWARD.md naming Operator as the rotator-of-record (so the invariant holds), with the exact Charlie-ack message format required before the Operator-side spawn.

Shipped by Unit B — STEWARD.md gains a Steward-self-rotation branch naming the Operator as rotator-of-record; haleon workflow.json adds selfRotationRotator:"operator" + a documented Operator role (spawnAtBootstrap:false).

✓ Resolved major HS-1 session_turn_seq is client-supplied with no UNIQUE — silent duplicate-claim defeats gap-scan

sp_create_agent_run takes p_session_turn_seq integer DEFAULT NULL — no allocator, no UNIQUE index, no trigger. Two concurrent skill invocations on the same session both read MAX(seq)+1 = N and both INSERT N. The sequence 1,2,3,N,N,5 looks contiguous to gap-scan; one writer's row is hidden. NULL is also accepted, silently defeating the whole audit story without any error.

Fix. CREATE UNIQUE INDEX agent_runs_session_seq_uniq ON haleon.agent_runs(session_id, session_turn_seq) WHERE session_id IS NOT NULL AND session_turn_seq IS NOT NULL; + RAISE if either is NULL in sp_create_agent_run. Concurrent duplicates now error loudly; loser retries with MAX+1.

Shipped by Unit E — partial UNIQUE on (session_id, session_turn_seq) added; sp_create_agent_run now RAISEs 23502 on NULL session_id / session_turn_seq / created_by_agent (also closes HS-3 with created_by_agent NOT NULL).

✓ Resolved major HS-2 Unclosed runs (phase-2 update never lands) bypass gap-scan entirely

sp_update_agent_run uses COALESCE — a missing completion call leaves completed_at / tokens / success all NULL. The INSERT-at-spawn row IS present, so (session_id, session_turn_seq) is contiguous → gap-scan green. Row is "open forever" with no TTL watchdog. Cost rollup treats NULL tokens as 0 so the cost number doesn't betray the leak either.

Fix. Add Steward-audit view v_open_agent_runs (completed_at IS NULL AND spawned_at < now() - interval '15 minutes') + a partial index. Add open-run scan to the Steward audit duties.

Shipped by Unit E — v_open_agent_runs view + index added and the open-run scan folded into the STEWARD.md audit-model. (OpenAgentRun still needs its dab-config entry + a 2nd MCP restart — see host actions.)

✓ Resolved major HS-5 Late-arriving completion silently dropped from finalised UTC-day cells

The rollup aggregates by spawned_at (correct — that's the day-of-spend). But ring-tick only rolls "today". A turn spawned yesterday at 23:55 and completed today at 00:05 fills its tokens after yesterday's cell was computed — yesterday is under-counted forever unless someone re-runs sp_rollup_cost_telemetry(yesterday, today).

Fix. Ring-tick's rollup call uses a rolling 2-day window: (today-1, today) AND (today, today+1). ON CONFLICT DO UPDATE re-aggregates yesterday cleanly.

Shipped by Unit E — ring-tick core-tick step 5 now does a rolling 2-day rollup (today-1 AND today); covers Unit D's late-arriving cost fold-in too.

✓ Resolved major HS-9 Audit row for a gap has no first-class slot for the gap key

A gap means the row that would have had id=X was never written — there is no UUID to put in detail_ref. The class='audit' finding therefore has detail_ref=NULL, leaving only free-text columns to encode "session=Y seq=4 missing." No documented convention exists; the query "show audits for the gap in session Y turn 4" is undefined.

Fix (convention only, no DDL). Steward writes gap audits with triggered_by = 'gap:'||session_id||':'||session_turn_seq (parseable, indexable via LIKE 'gap:%'). Document in STEWARD.md § Audit-model (a). Stronger alternative: ALTER TABLE agent_runs ADD COLUMN finding_key text.

Shipped by Unit E — the convention is adopted: Steward gap-audits use triggered_by = 'gap:'||session_id||':'||session_turn_seq, documented in the STEWARD.md audit-model.