fix(pi): preserve direct reply continuity across compaction

[ruby-dlee]

Intent

Fix the Pi primary-session compaction failure that made a direct captain exchange effectively disappear behind automated watcher turns and left the resumed model unable to track the captain reply obligation. Start from the observed live JSONL evidence around entries 1480-1497: a real captain question and completed assistant answer were followed by an older extension-generated watcher turn and compaction whose first-kept entry was automation. Establish precisely that the submitted human steering input was delayed but persisted and answered, not omitted or starved, while no additional submitted human input exists in that interval. Preserve the latest exact human exchange and any genuinely admitted open reply obligation across compaction, distinctly from watcher and guard custom messages. Capture exact queued image content at the submission boundary, including image data and MIME type, but treat input records as provisional until Pi proves preflight or queue admission so rejected or handler-consumed input cannot become a false reply obligation. Prove with executable installed-Pi coverage that an older automation follow-up does not reorder or starve a later human image steering input, and that compaction before delivery restores exact admitted image content. Automated prompts must use context-participating custom messages, never masquerade as human user turns, and must not bypass Pi queue ownership. Do not disable compaction, enlarge keepRecentTokens, special-case wording, or add a refusal. Preserve every recovered validation and implementation commit. Update the authoritative Pi documentation and regenerate runtime/test artifacts from .pi/extensions/fm-primary-pi-watch.ts through the real instruction and installed Pi emitters rather than editing generated copies. Drive review, tests, documentation, lint, push, PR, and CI to checks-green.

What Changed

• Track provisional Pi input observations and admitted direct exchanges with exact text and image content, preserving answered exchanges and open reply obligations across compaction.
• Deliver watcher and turn-end automation as context-participating custom messages without impersonating human turns or bypassing Pi’s queue ownership.
• Add installed-Pi and live compaction coverage for image steering order, retry continuity, exact delivery association, and post-compaction context restoration, with corresponding protocol documentation.

Risk Assessment

✅ Low: The retry-cohort repair is narrowly scoped, preserves the required direct-exchange and custom-message invariants, and has executable fail-before/pass-after plus installed-consumer evidence with no substantiated remaining defect.

Testing

The passing baseline was supplemented with focused installed-Pi checks covering consumed versus admitted input, identical retry, answer association, real automation/human queue ordering and starvation, exact image delivery through compaction, both retry lifecycle outcomes, installed type compatibility, and test registration. Reviewer-visible CLI transcripts were captured; no screenshot was applicable because the changed end-user surface is Pi session/CLI behavior rather than rendered UI.

Evidence: Installed Pi exact-delivery proof

ok - installed Pi exact delivery association preserved

== tests/fm-pi-exact-delivery-association.test.sh ==
ok - installed Pi exact delivery association preserved

Evidence: Installed Pi retry lifecycle proof

PI_RETRY_CONTINUITY_PROOF_OK

== tests/fm-pi-retry-continuity.test.sh ==
PI_RETRY_CONTINUITY_PROOF_OK

Evidence: Installed Pi consumer compatibility

ok - exact Pi continuity consumer typecheck passed

== tests/fm-pi-direct-continuity-types.test.sh ==
ok - exact Pi continuity consumer typecheck passed

Pipeline

Updates from git push no-mistakes

✅ **intent** - passed

✅ No issues found.

✅ **Rebase** - passed

✅ No issues found.

🔧 **Review** - 2 issues found → auto-fixed (11) ✅

• 🚨 .pi/extensions/fm-primary-pi-watch.ts:342 - The required provisional-admission invariant remains violated. This handler immediately appends submitted, but installed Pi invokes input before later handlers may return action: "handled", before idle model/auth validation, and before streaming queue acceptance. A consumed or rejected input therefore remains reachable as SUBMITTED_NOT_DELIVERED once no pending messages exist, creating a false reply obligation. Persist only after Pi confirms preflight/queue admission, or record a cancellation transition excluded by the fold.
• 🚨 tests/fm-pi-watch-extension.test.sh:476 - The required installed-Pi ordering regression is still absent. This fixture calls the extension's input handler directly, manually flips pendingMessages, and manually appends automation; the live test waits for automation to settle before sending another human prompt and never submits an image. Neither executes competing older automation and later human image steering through Pi's real queues, so ordering, starvation, queue admission, and compaction-before-delivery image recovery remain unproved as explicitly required.

🔧 Fix: Captain, admit Pi input and prove queue ordering
2 issues (1 error, 1 warning) still open:

• 🚨 .pi/extensions/fm-primary-pi-watch.ts:347 - Admission is still inferred from global queue state rather than acceptance of this specific input. Concrete path: an older watcher follow-up is already queued, a later human steer is consumed by another input handler, then this timer sees ctx.hasPendingMessages() true because of the watcher and marks the rejected steer admitted; once the watcher drains, continuity promotes that steer to SUBMITTED_NOT_DELIVERED. The immediate fallback has the same identity problem: a later unrelated before_agent_start can admit the newest unmatched handled input. This contradicts the required invariant that handler-consumed/rejected input cannot create an obligation. Record admission at a Pi boundary that identifies the accepted input, or add a cancellation/handled transition; the regression should include a consumed steer while unrelated automation remains queued.
• ⚠️ .pi/extensions/fm-primary-pi-watch.ts - The fixer could not prove the semantic repair with a public/executable fail-before/pass-after regression and relevant integration or consumer compatibility evidence; primary-agent handoff is required.

🔧 Fix: Require exact input-specific Pi admission
2 issues (1 error, 1 warning) still open:

• 🚨 .pi/extensions/fm-primary-pi-watch.ts:397 - Exact-content matching drops concurrently queued duplicate inputs. If two identical human steers are submitted before either is delivered, both remain pending matches, so each exact user message_end finds matches.length === 2 and records neither delivery. Both genuinely accepted inputs are then excluded from continuity despite Pi delivering them. Associate indistinguishable exact matches in queue order, while continuing to reject non-exact matches.
• ⚠️ .pi/extensions/fm-primary-pi-watch.ts - The fixer could not prove the semantic repair with a public/executable fail-before/pass-after regression and relevant integration or consumer compatibility evidence; primary-agent handoff is required.

🔧 Fix: Preserve duplicate Pi input obligations
3 issues (1 error, 2 warnings) still open:

• 🚨 .pi/extensions/fm-primary-pi-watch.ts:397 - The new FIFO exact-content association can still admit a handler-consumed input. Concrete path: submit steer A, another input handler consumes it, then submit identical accepted steer B; B's exact message_end selects unresolved A at matches[0], marking the consumed input delivered while B remains provisional. The same ambiguity exists for identical immediate retries in matchingProvisional. This contradicts the required invariant that handler-consumed input cannot become a false obligation. Admission needs an input-specific accepted identity or cancellation transition at Pi's input-handler/queue boundary; content alone cannot distinguish this sequence.
• ⚠️ tests/fm-pi-watch-extension.test.sh:551 - The executor's public regression produced the same successful output digest before and after the repair, so it does not provide the required fail-before/pass-after evidence for the changed admission behavior. Add executable coverage for a consumed input followed by an identical accepted retry; it should fail against the pre-repair implementation and prove that only the accepted input becomes an obligation.
• ⚠️ .pi/extensions/fm-primary-pi-watch.ts - The fixer could not prove the semantic repair with a public/executable fail-before/pass-after regression and relevant integration or consumer compatibility evidence; primary-agent handoff is required.

🔧 Fix: Separate Pi observations from admitted exchanges
3 issues (1 error, 2 warnings) still open:

• 🚨 .pi/extensions/fm-primary-pi-watch.ts:423 - A later successful assistant turn marks every earlier delivered exchange as answered unless any custom_message occurred after its delivery. Concrete path: Q1 is delivered, its assistant turn aborts/errors, Q2 is delivered, and the assistant successfully answers only Q2; the Q2 answer is recorded against both Q1 and Q2, silently erasing Q1's open obligation. Associate completion with the user input(s) that initiated or joined that specific agent turn rather than all historically open exchanges.
• ⚠️ tests/fm-pi-watch-extension.test.sh:551 - The required semantic-repair proof remains unverified: the executor's fail-before, pass-after, and integration commands all exited 127, and the before/after public-check digests are identical. This does not establish the required executable fail-before/pass-after regression or consumer compatibility evidence despite the test additions.
• ⚠️ .pi/extensions/fm-primary-pi-watch.ts - The fixer could not prove the semantic repair with a public/executable fail-before/pass-after regression and relevant integration or consumer compatibility evidence; primary-agent handoff is required.

🔧 Fix: Scope Pi answers to active runs
2 warnings still open:

• ⚠️ tests/fm-pi-watch-extension.test.sh:742 - The active-run attribution repair is not merge-ready under the required semantic-proof rule: executor-owned fail-before, pass-after, and integration runs all exited 127, with identical before/after public-check digests, while repair_complete remains false. The added handler-level regression therefore lacks verified fail-before/pass-after and installed-consumer evidence. Re-run the recorded exact public and consumer commands successfully through the executor before accepting this repair.
• ⚠️ .pi/extensions/fm-primary-pi-watch.ts - The fixer could not prove the semantic repair with a public/executable fail-before/pass-after regression and relevant integration or consumer compatibility evidence; primary-agent handoff is required.

🔧 Fix: Emit stable Pi continuity proof
3 issues (1 error, 2 warnings) still open:

• 🚨 .pi/extensions/fm-primary-pi-watch.ts:409 - Delivery is matched to the oldest undelivered exchange solely by identical serialized content. Concrete path: Q1 is admitted but its run aborts before message_end; the captain retries identical Q2, which creates a second admission; Q2's delivered message is assigned to Q1, so Q2 remains SUBMITTED_NOT_DELIVERED, and Q2's successful answer closes Q1 instead. Compaction then reports an apparent open obligation for the already answered retry. Preserve an input-specific admission/delivery correlation at Pi's admission boundary instead of selecting by content alone.
• ⚠️ tests/fm-pi-watch-extension.test.sh:1383 - The required semantic-repair proof remains unverified: the executor recorded no completed fail-before, pass-after, or installed-consumer result (repair_complete=false, all exits -1). The behavioral marker added to the test is therefore still only an unexecuted proof claim; obtain successful executor-owned results for the recorded public and consumer commands before accepting the repair.
• ⚠️ tests/fm-pi-watch-extension.test.sh - The fixer could not prove the semantic repair with a public/executable fail-before/pass-after regression and relevant integration or consumer compatibility evidence; primary-agent handoff is required.

🔧 Fix: Preserve exact Pi delivery association, captain
3 issues (1 error, 2 warnings) still open:

• 🚨 docs/supervision-protocols/pi.md:27 - Intent requires “Update the authoritative Pi documentation,” but this section still claims immediate admission via the removed before_agent_start handler, FIFO content matching, and SUBMITTED_NOT_DELIVERED; the current implementation admits only exact message_end deliveries and performs none of those behaviors. Update this authoritative contract to describe the final delivery-boundary design.
• ⚠️ tests/fm-pi-watch-extension.test.sh:1367 - The semantic repair remains unverified: executor-owned fail-before, pass-after, and installed-consumer checks all have exit -1, with repair_complete=false. The focused test/token is executable in design, but successful targeted and consumer evidence is still required before accepting this integration repair.
• ⚠️ .pi/extensions/fm-primary-pi-watch.ts - The fixer could not prove the semantic repair with a public/executable fail-before/pass-after regression and relevant integration or consumer compatibility evidence; primary-agent handoff is required.

🔧 Fix: Prove exact Pi delivery continuity
2 warnings still open:

• ⚠️ tests/fm-pi-direct-continuity.test.sh:34 - The required semantic-repair proof remains unverified: executor-owned fail-before, pass-after, and installed-consumer checks all have exit -1 (repair_complete=false, failure category integration_command_not_targeted). The new wrapper is plausible executable coverage, but successful targeted and consumer results are still required before accepting the Pi delivery-association repair.
• ⚠️ docs/supervision-protocols/pi.md - The fixer could not prove the semantic repair with a public/executable fail-before/pass-after regression and relevant integration or consumer compatibility evidence; primary-agent handoff is required.

🔧 Fix: Captain, wire targeted Pi consumer proof
2 warnings still open:

• ⚠️ tests/fm-pi-direct-continuity.test.sh:34 - The required semantic repair is still unverified: the public executable check returned identical successful output before and after the latest repair, so it does not provide the required fail-before/pass-after evidence for exact Pi delivery association. The owner should review the proof boundary before accepting this integration repair.
• ⚠️ tests/fm-pi-direct-continuity.test.sh - The fixer could not prove the semantic repair with a public/executable fail-before/pass-after regression and relevant integration or consumer compatibility evidence; primary-agent handoff is required.

🔧 Fix: Prove exact Pi delivery association
1 error still open:

• 🚨 .pi/extensions/fm-primary-pi-watch.ts:402 - A successful Pi retry cannot close the captain exchange. The first agent_start assigns run A and the user delivery records A; after an error, abort, or compaction retry, Pi emits a new agent_start without re-emitting the existing user message, so the successful answer occurs under run B and fails this equality check. Compaction can then incorrectly restore the answered question as OPEN_REPLY_OBLIGATION. Associate answers across Pi's logical request/retry lifecycle while keeping later user deliveries distinct.

🔧 Fix: Preserve Pi retry reply cohorts, captain
✅ Re-checked - no issues remain.

✅ **Test** - passed

✅ No issues found.

• if [ "${FM_AZURE_VALIDATION_CELL:-0}" = 1 ]; then exec "$FM_AZURE_VALIDATION_SHARD_BRIDGE" behavior --count "${FM_AZURE_VALIDATION_SHARD_COUNT:-8}"; else exec bin/fm-no-mistakes-test-command.sh; fi
• Configured baseline (already completed successfully): if [ "${FM_AZURE_VALIDATION_CELL:-0}" = 1 ]; then exec "$FM_AZURE_VALIDATION_SHARD_BRIDGE" behavior --count "${FM_AZURE_VALIDATION_SHARD_COUNT:-8}"; else exec bin/fm-no-mistakes-test-command.sh; fi
• tests/fm-pi-exact-delivery-association.test.sh
• tests/fm-pi-retry-continuity.test.sh
• tests/fm-pi-direct-continuity-types.test.sh
• tests/test-suite-seal.test.sh
• git status --short and targeted transient-artifact scan

✅ **Document** - passed

✅ No issues found.

🔧 **Lint** - 1 issue found → auto-fixed ✅

• ⚠️ linter found issues (exit code 1)

🔧 Fix: Fix ShellCheck-safe Pi runtime discovery loops
✅ Re-checked - no issues remain.

✅ **Push** - passed

✅ No issues found.