Supervisor promises recovery without dispatching remaining stages

[usirin]

Summary

The supervisor recovered a completed builder's saved output, said it was continuing, but launched no remaining stage. The workflow used an inline JavaScript chain rather than Fabrika's durable lane ledger.

What I was doing

Investigating the stalled publication of #8600 after workflow de8d8c9a-a024-436f-9c24-f0df2059594b lost its host.

What I observed

On 2026-09-08 at 20:18:09Z the parent checked failed workflow status. At 20:18:14Z it checked child 8d652be4-cacd-4cb2-8f03-69ce5c83ad72 and saw complete. At 20:18:18Z it read the saved builder handoff with 18 screenshot references. At 20:18:22Z it said "I'm recovering from the saved handoff." The subsequent parent session through 20:22:44Z contains discussion but no recovery dispatch. At 20:19:31Z it described UI review and shipping as the two remaining steps. The original script had both stages explicitly after the builder await, but no lane ledger was allocated; its prompts explicitly told children not to invent lane report operands. A pi-subagents mission existed, but that is not the Fabrika lane ledger and does not execute missing stages by itself.

Why it matters

A correct infrastructure stop became an unacted-on recovery promise. Neither child completion nor an agent saying it is recovering starts the next stage. Replacing the subagent tool alone would not stop this behavior.

Pointers

• Original parent session 01a07a62-9d95-7bfd-8b7b-c0b7872f0534, lines 787-809
• claude-plugins/fabrika/skills/operate/SKILL.md, ledger-only state and boot/resume contract
• packages/fabrika-pi/agents/operator.md
• packages/fabrika-pi/README.md, package bundles skills and agent shells, not a durable execution service
• Screenshot handoff: feat: Tuval needs Codex alongside Pi and Claude #8600 (comment)
• Related state reporting issue: Pi stale workflow repair mislabels a successful detached child #8621

Suggested next step (non-binding)

Add a recovery case to the operator evaluation: after a dead workflow and successful child, reconcile saved output and clean-tree state, then either make an authorized same-protocol remaining-stage dispatch or report the exact blocker. Do not end with a progress claim unsupported by a dispatch. For governed lanes, use the existing ledger and prove/report contracts rather than relying only on an in-memory script. Do not retroactively invent ledger entries. Confidence 99% in the observed no-dispatch gap, 90% that this evaluation improves behavior; it is not process-crash prevention.

---

_{Filed by an agent · session 425cb3d4-b7c2-4bc3-b562-0776c88e7787 · branch umut/tuval-pi-0.85.0 · 2026-09-08T20:31:02Z}

[usirin]

Operator ownership correction from the founder: the operator is already responsible for coordinating builder, reviewer and shipper. This is not a proposal to add that responsibility to the supervisor or build a second wrapper.

Further transcript evidence: the operator was listed as executable at parent session lines 624, 661, 675 and 786. No operator execution call or read of the operate skill appears before the stalled workflow. At lines 625/627 the supervisor read review/build, then read generic pi-subagents guidance at 635/647 and authored its own triage/build/review script at 649. The original request at 622 was to prepare a commit/PR for a reviewer, with no merge; later scripts kept this hand-authored structure after authority expanded. At 721 and later the supervisor explicitly instructed children that no Fabrika lane ledger was allocated. There is no observed operator launch refusal to justify a fallback. This proves bypass, not the model's internal reason for choosing it.

The current operate contract already requires fresh lane status after child return, proof/record repair when a terminal did not land, dead-spawn cleanup and parking, and replacement-operator resume from the ledger. A remaining scope question matters: this PR is Part of an issue and the issue must remain open; the standard lane returns to queued after a partial merge. Finishing this PR only must not silently authorize implementation of the remaining issue. A no-ledger PR cannot be described as an existing lane ready for resume.

Ran existing mock-based lane report, brief and prove tests: 3 files, 140 tests passed. These establish CLI mechanics, not operator model behavior or process-crash resilience. A paper-only operator evaluation is running separately; no live lane or PR action is authorized by that test.

[usirin]

The operator paper evaluation completed: workflow 15961e0d-54da-4612-98f1-a0890696445c, child a481348a-a4d5-4581-97c4-413a0cb897b4. It read its installed skill but performed no lane commands, agent launches, GitHub actions or file changes. These are proposed-action answers, not end-to-end recovery proof.

It correctly distinguished dead operator from successful builder, required a fresh ledger read, avoided repeating completed work, and proposed proof-gated repair for a missing builder report. For a truly dead builder it required a recorded spawn-dead block, incident filing, claim cleanup, safe worktree retirement and supported unpark before redispatch. Its missing-report answer used lane report rather than the operator section's explicit prove/transition path; the CLI tests cover proof-gated report behavior, but exact actor-path compliance was not exercised.

For the actual no-ledger PR-only situation, it correctly refused to invent a UI-review state or turn PR-only permission into permission to finish the whole issue. But it also repeated an obsolete operate paragraph saying Part of cannot resolve through lane brief; tested CLI behavior supports it. That false blocker needs a docs/evaluation correction, not a custom subagent wrapper.

Conclusion: the operator already owns and reasons through the ordinary recovery cases. The original supervisor bypassed it despite executable discovery. There is still no demonstrated bounded existing-PR adoption path for this exact no-ledger handoff, and this paper test does not prove process crash recovery.