Problem
Maka's Runtime resume documents distinguish the recovery work that has landed from the remaining Phase 3 work. Phase 3A established the durable T1/T2 boundary, RecoveryResolver, and atomic recovery-bundle persistence in #1521. Production Write/Edit recovery—trusted file evidence, a filesystem observer/reconciler, and the Host-owned recovery lifecycle—remains documented but is not represented by a focused GitHub issue.
Documentation alone is difficult to use as a progress tracker: contributors cannot query or assign the remaining work, connect child PRs to one canonical checklist, or quickly tell which parts have shipped. This also makes it easier for the design and implementation status to drift apart.
This issue tracks the narrow Phase 3 PR C/D work already described by the architecture. It does not introduce a new recovery design or promise generic automatic recovery for every tool.
Design sources:
Related roadmap: #544
Desired outcome
Use this issue as the canonical, queryable progress tracker for production Write/Edit reconciliation. Keep the checklist and architecture status updated as child PRs land.
Current documented baseline
Required first-version policy
matches_expected_state: finalize without rewriting the file, synthesize the missing successful outcome, and commit a completed recovery bundle.matches_prior_state: park with redo_disabled_pending_cas.diverged or unreadable: park without mutating external state.- Missing, incompatible, or unverifiable contracts and evidence must fail closed.
Out of scope or explicitly deferred
- Automatic redo before a conditional replace/CAS protocol exists
- ShellRun reattachment, Bash replay, or generic child-process recovery
- Generic reconciliation for remote APIs or MCP tools
- Phase 4 Git workspace checkpoints, isolated restore, or durable rebaseline
- Exactly-once guarantees for arbitrary external side effects
Alternatives or workarounds
Continue tracking the work only in architecture documents. That preserves the design, but it does not provide issue ownership, linked implementation progress, or a single status surface for contributors and maintainers.
Problem
Maka's Runtime resume documents distinguish the recovery work that has landed from the remaining Phase 3 work. Phase 3A established the durable T1/T2 boundary,
RecoveryResolver, and atomic recovery-bundle persistence in #1521. Production Write/Edit recovery—trusted file evidence, a filesystem observer/reconciler, and the Host-owned recovery lifecycle—remains documented but is not represented by a focused GitHub issue.Documentation alone is difficult to use as a progress tracker: contributors cannot query or assign the remaining work, connect child PRs to one canonical checklist, or quickly tell which parts have shipped. This also makes it easier for the design and implementation status to drift apart.
This issue tracks the narrow Phase 3 PR C/D work already described by the architecture. It does not introduce a new recovery design or promise generic automatic recovery for every tool.
Design sources:
Related roadmap: #544
Desired outcome
Use this issue as the canonical, queryable progress tracker for production Write/Edit reconciliation. Keep the checklist and architecture status updated as child PRs land.
Current documented baseline
RecoveryResolverRequired first-version policy
matches_expected_state: finalize without rewriting the file, synthesize the missing successful outcome, and commit a completed recovery bundle.matches_prior_state: park withredo_disabled_pending_cas.divergedorunreadable: park without mutating external state.Out of scope or explicitly deferred
Alternatives or workarounds
Continue tracking the work only in architecture documents. That preserves the design, but it does not provide issue ownership, linked implementation progress, or a single status surface for contributors and maintainers.