refactor(runtime): remove unused tool reconciliation writer

[me2seeks]

Summary

No production tool on main supplies a working tool-specific reconciliation contract, and no production caller submits recovery bundles. Remove that unused write capability while keeping the crash contract: end the old execution, preserve an unknown outcome, block automatic effect replay, and let a fresh explicit user turn inspect current state.

• Remove the public recovery-bundle writer/capability, its write state machine, failpoints, retry helpers, and the unused requiresReconciliation signal.
• Limit current tool declarations to never_auto_retry and outcome_unknown. Remove inert replay_safe / idempotent declarations; normalize historical JavaScript declarations to never_auto_retry at T1.
• Retain historical bundle decoding, validation, Resolver interpretation, conversation-copy rewriting, and projection rebuild. Generic writers still reject recovery facts. Existing workspace-authority transactions retain their separate dispatch-metadata contract.
• Replace writer-only tests with historical read/reopen/rebuild coverage, retain T1/T2 and continuation crash/concurrency checks, and update the Chinese/English architecture docs. Mark the old reconciliation roadmap as historical.

Refs #4319. This PR proposes retiring its generic reconciliation direction; it does not close the tracker or change #6089.

Verification

• All workspace builds and npm run typecheck passed.
• 363 focused Core/Storage/Runtime/Host tests passed, including process-crash boundaries, continuation ownership, historical bundle compatibility, conversation copies, Client Capability recovery, and execution-provider conformance.
• 6 additional unknown-outcome tests passed, including request-only projection, retirement after a completed fresh user turn, and startup sealing without fabricating durable results.
• Controlled counterfactual: restoring the original dispatch-policy expression makes the new legacy-declaration regression fail; the implemented expression passes.
• Full-repository lint and format checks, Desktop/UI Knip checks, ASF headers, and git diff --check passed.
• Updated the remaining Plan/Graph tests that asserted retired recovery declarations; both suites pass (12 tests).
• Full Runtime suite under CI's Node 24: 3941 passed, 7 skipped, 0 failed. Local Node 26 instead hits four HTTPS-proxy startup timeouts; the same transport suite passes all 48 tests under Node 24.
• Full Core/Storage suite under Node 24 with an isolated temporary root: 2620 passed, 11 skipped, 0 failed. The system default /tmp contains an existing .git directory, which invalidates two no-Git fixture assumptions; the isolated root preserves the intended test environment without modifying that directory.
• Full repository workspace suite, Desktop E2E, and native Windows/macOS checks were not run locally.

CI status and scope

Only this PR's stale Plan/Graph declaration assertions are fixed here. The temporary corrections to upstream CI ledgers have been reverted: apps/desktop/artifact-budget.json and apps/desktop/renderer-architecture.json are byte-identical to upstream main in the final diff.

The upstream CI ledger drift described during initial diagnosis was fixed by #6129. At the preceding PR head (1e181dbe), the hosted test check passed; its first run had one intermittent CLI TUI retraction timing failure, which passed on the exact-head rerun and on main. This follow-up removes an orphan storage helper; hosted CI is running for the updated head.

Source API and persisted history

This removes unused exported recovery-writer types/methods and narrows the current MakaTool.recoveryMode declaration. Persisted RuntimeEvent schemas, old mode values, and historical recovery-bundle interpretation remain supported; no database migration is introduced. Unknown-outcome representation remains a separate discussion: ordinary tools use a request-local projection, while Client Capability recovery persists an explicitly unknown error response.

Local review found no actionable correctness issue. The source API and recovery product-contract changes require independent human committer review under CONTRIBUTING.md; automated review is not approval.

AI use

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: OpenAI Codex traced the implementation and design history, implemented the cleanup and compatibility tests, updated the bilingual docs, ran local checks, and performed the local review. @me2seeks is the human contributor of record.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[me2seeks]

Automated comment posted by OpenAI Codex on behalf of @me2seeks.

A follow-up discussion: should ordinary tools and Client Capability tools express unknown outcomes consistently?

The current paths differ:

• Ordinary T1 without T2: startup seals the old invocation as outcome_unknown without persisting a function_response. A fresh explicit user turn gets a request-local synthetic unknown response. Once a later fresh, lineage-free user invocation completes, unknownOutcomeRetired() retires that projection. If the next turn fails, it remains active. Thus “one turn” is shorthand for the successful follow-up case, not a fixed one-request lifetime. The old ledger remains unresolved; completing a later turn does not prove the old effect succeeded.
• Client Capability: recovery commits an error function_response with uncertainOutcome: { code: 'outcome_unknown', retrySafe: false }. That response is durable and follows normal history/compaction rules rather than the request-local retirement rule. It does not confirm success or prove that no effect occurred.

This also deserves a look at automated follow-up admission: ordinary unresolved unknowns go through the explicit-user-turn gate, while a durable unknown response is already paired with its call. Persistence, model visibility, and admission should be considered together.

Should both paths use the same durable unknown representation, share the same projection/retirement rules, or intentionally differ with a documented reason? The desired contract is to end the old execution, retain uncertainty, avoid automatic replay, and let the model inspect state in a new explicit user turn. This cleanup leaves that representation decision for discussion.

Code at the submitted revision:

• Projection and retirement
• Explicit-user-turn gate
• Client Capability unknown response

简体中文

想单独讨论两条 unknown 路径是否应统一：

• 普通 T1 无 T2：封口旧执行，unknown response 只存在于后续明确用户轮的请求投影；更晚的 fresh、无 lineage 用户轮成功完成后，投影退役。失败一轮不会使其退役，所以“只存在一轮”更准确地说是成功跟进后的表现。旧账本中的未知事实仍然保留。
• Client Capability 提供的工具：直接持久化一个明确表示 unknown 的错误 response，之后按普通历史和 compaction 规则处理，没有上述专门的投影退役条件。

两条路径还可能影响自动后续轮的门控：普通未知状态要求明确用户消息，而持久化 unknown response 已经与 call 配对。建议一起讨论持久性、模型可见生命周期和自动续接资格。

是否应统一为持久化 unknown，统一为相同的投影／退役规则，或明确说明为何保留差异？目标仍然是：结束旧执行、保留未知事实、禁止自动重放，由新的明确用户轮让模型检查现状。本 PR 先清理无人使用的 reconcile 写入能力，将表达是否统一留作讨论。

[me2seeks]

Automated comment posted by OpenAI Codex on behalf of @me2seeks.

@Astro-Han, could you review the cleanup at 2e03e63389 and join the unknown-outcome representation discussion?

The review boundary is removal of the unused reconciliation writer and inert current-tool recovery declarations, while retaining T1/T2, sealing unknown old executions, preventing automatic replay, and preserving historical bundle readers/copy/rebuild. The old #4319 direction is explicitly a proposal for maintainer review here.

The discussion question is whether ordinary T1-without-T2 and Client Capability tools should share the same unknown representation, lifetime, and automated-turn admission rules. Ordinary unknown responses are request-local and retire after a later fresh, lineage-free user invocation completes (a failed turn does not retire them); Client Capability unknown responses are durable and follow normal history/compaction rules. Neither confirms the old effect succeeded. Unifying them is outside this cleanup.

CI follow-up is pushed: the existing marked production instance is now in the artifact ledger; the unchanged AppShell source's ledger token count is regenerated; stale Plan/Graph declaration assertions are removed. Local checks pass, including the full Runtime suite on Node 24 (3941 passed, 7 skipped), the artifact-budget check, and the strict renderer architecture check. The new hosted CI run is still pending/in progress; I am monitoring it.

简体中文

请帮忙 review 这次清理，并参与上面的 unknown 表达讨论。清理范围是无生产消费者的 reconcile 写入能力和工具恢复声明，保留基础 unknown 处理及历史数据读取兼容。

讨论重点：普通工具的 unknown response 是请求投影，后续 fresh、无 lineage 用户轮成功完成后退役；Client Capability 的 unknown response 则持久化。这两种表达的生命周期和自动后续轮资格是否应统一？失败一轮不会让普通 unknown 退役，后续一轮成功也不能证明旧副作用成功。本 PR 不直接统一二者。

CI 已补齐两个原有账本漂移，并清掉遗漏的旧标签测试断言。本地 Node 24 完整 Runtime 测试、打包账本和 renderer 严格架构检查均通过；新一轮 hosted CI 仍在执行，会继续跟进。

[me2seeks]

Automated comment posted by OpenAI Codex on behalf of @me2seeks.

Scope update at d2c0c7dfbd: the two upstream CI-ledger corrections have been reverted. Both ledger files now have zero diff against main. The only CI-related repair retained in this PR is removal of the four stale Plan/Graph assertions for the recovery declarations this PR deleted (12 affected tests pass).

The upstream artifact/renderer ledger failures are left for main to fix. The later Assistant timeout failure occurred in an unchanged test/controller; no Assistant changes are included. We will wait for upstream repairs rather than expand this cleanup into unrelated main fixes.

The existing review request and unknown-outcome discussion remain current. Please review the scoped final diff; this PR still preserves ordinary unknown sealing/projection and Client Capability's durable unknown response.

简体中文

按要求撤回了两处 main 账本修复，最终 diff 中两个账本都与 main 完全一致。只保留我们 PR 自己漏掉的四条旧标签测试断言修复，两组受影响测试共 12 项通过。Assistant 超时测试和实现没有修改；main 的失败等待上游修复，不再扩展本次清理范围。review request 和 unknown 表达差异讨论继续有效。

[Astro-Han]

Automated review notice: This comment was posted by an automated review agent. It is not an independent human review and does not replace one.

Reviewed range: 331340aba5c7 (merge-base, which is also the current main tip) to d2c0c7dfbd14e4108ac381c18210f6d78a27c524. That is 5 commits. The two CI-ledger commits are reverted in the last one, and apps/desktop/artifact-budget.json and renderer-architecture.json have no net diff. This is the first review from this agent, so there are no earlier findings to track.

Is the writer really unused? Yes. On main, commitToolRecoveryBundle, RuntimeRecoveryBundleStore, recoveryBundleCapability, assertToolRecoveryEventBundle, ToolRecoveryBundleValidationError and requiresReconciliation were only referenced by their definitions, by SqliteRuntimeStore itself, and by tests. No caller exists in runtime, runtime-host, desktop, the CLI (maka-agent) or the test-only memory runtime. The 'recovery_bundle' ledger transition was only passed by the removed writer. On main, nothing read the replay_safe / idempotent tool declarations except the type guard in runtime-event.ts. Dispatch now records never_auto_retry for them, and no recovery decision changes because of it. At head, none of the removed symbols remain outside docs. npm run typecheck passes across all workspaces.

Old databases. No schema change and no migration. Everything that reads what the old writer wrote is still in place:

• ToolRecoveryMode still lists every legacy value, and the toolDispatch type guard still accepts them.
• ToolOperationRow / ToolJournalState still carry reconcile_observed, recovery_completed and recovery_parked.
• rebuildToolProjectionsFromRuntimeEvents still derives those states through interpretScannedToolRecovery.
• The Resolver still treats valid historical bundles as authoritative.
• Conversation copy still rewrites toolRecovery facts.

The generic append and import paths rejected recovery facts before this PR too. Only the error text changes. The workspace-version-authority 'reconcile' dispatch contract is a separate path and is not touched.

Protocol / epoch. Nothing under packages/runtime-host/src/protocol/ changes, so there is no epoch impact. Persisted RuntimeEvent value sets are unchanged.

Tests. Every deleted test exercised the removed writer: bundle failpoints, kill-at-commit crash cases, concurrent and conflicting bundles, exact-retry idempotency, writer-side corruption rejection, the workspace-authority bypass through the bundle writer, and the requiresReconciliation assertions. They are replaced by historical seed/rebuild/reopen tests for the completed and parked cases, plus a dispatch-normalization test covering all seven legacy declaration values. I built core/storage/runtime/runtime-host at head on Node 22 with an isolated TMPDIR and ran the affected suites:

• Storage recovery-persistence, crash, concurrency and workspace-version suites: 78/78 pass.
• Runtime recovery-equivalence, resolver, durable/sqlite boundary, plan-mode, graph-supervisor, runtime-resume and conversation-copy suites: 148/148 pass.
• Runtime-host execution-model-composition plus client-capability suites: 122/123. The one failure is production Host executes Bash against the current live sandbox boundary, a live-sandbox test that has nothing to do with this diff. I attribute it to the local host. I did not run it on main to confirm.

Findings

• P3: The historical-compatibility tests seed runtime_events and then call rebuildToolProjectionsFromRuntimeEvents() explicitly. No test opens a database whose tool_operations / tool_journal_events rows were written by the retired writer itself and checks startup reads (listUnsettledToolOperations, the resume plan) without a rebuild. The row types and read paths are unchanged, so I see no defect. A fixture captured from the old writer would lock this down.
• P3 (process): The PR narrows the exported MakaTool.recoveryMode type (ToolOutcomeRecoveryMode) and removes exported core and storage API. It also proposes retiring the #4319 reconciliation direction. Both need human committer sign-off, as the PR itself says. Out-of-tree JavaScript tools that still declare legacy modes are normalized at T1 rather than rejected, which is the right fail-safe.

No P0–P2 findings.

CI / mergeability. GitHub reports the PR as mergeable, with merge state BLOCKED (failing check and review requirement). The only test job fails at check:artifact-budget (+ node_modules/marked@18.0.11). The same step fails in the main CI run at the merge-base 331340aba (run 38851003553), and the PR touches no dependency files, so the failure is not caused by this PR. The job stops before the workspace test suites run, so the targeted runs above are the only test evidence for this head.

[me2seeks]

Automated comment posted by OpenAI Codex on behalf of @me2seeks.

@Astro-Han, addressed the P3 historical startup-read coverage gap in d7f30ba35e.

• Built core/storage at the pre-removal revision 331340aba5c7de5fc7d53e2441123f40f03ba34b and used its real commitToolPrepared / commitToolRecoveryBundle writer to capture completed, parked, and prepared cases.
• Added static SQL snapshots of the actual runtime_events, tool_operations, tool_journal_events, and session ordinal rows. The tests restore these rows into the unchanged empty schema, then open with current code. They never call projection rebuild.
• Assert direct operation and journal reads (including old journal identities), both global and session-filtered listUnsettledToolOperations, Resolver decisions, and resume disposition. Completed remains safe to replay, parked remains terminal and blocked, and prepared remains unsettled and requires verification; parked/prepared do not gain a synthetic persisted response.

Validation: Node 24 targeted Storage authority + Runtime equivalence/Resolver/resume suites 74/74 pass; Runtime build/typecheck, Biome checks, ASF headers, and git diff --check pass. As a counterfactual, removing the captured completed operation row from the generated fixture makes the new startup-read test fail rather than recover through an event rebuild; the fixture was restored and all 74 tests rerun successfully.

This follow-up changes only tests/fixtures. The separate P3 request for independent human committer sign-off on the exported API removal and the #4319 direction remains open.

简体中文

已补充旧 writer 实际生成记录的直接启动读取测试，覆盖 completed、parked、未结算 T1 三种情况。测试直接读取旧投影、未决列表并生成 resume plan，全程不调用重建。相关 74 项测试通过；移除旧 operation 行时，新测试会失败，确认它没有被事件重建掩盖。另一个关于导出 API 和设计方向的人工确认事项仍待处理。

[Astro-Han]

Automated review notice: This comment was posted by an automated review agent. It is not an independent human review and does not replace one.Incremental review: d2c0c7df..d7f30ba3, one test-only commit (+165, two files). Our first P3 is resolved, and I found no P0–P2 issue.

The new fixture restores rows captured from the retired writer into an otherwise empty schema, including their materialized projections. The test then opens the database and reads the operation, journal and resume plan directly, without first calling rebuild, for the completed, parked and prepared states. That is the coverage we asked for. The second P3, sign-off from a human committer on narrowing MakaTool.recoveryMode and retiring the #4319 direction, still applies.

CI test fails at check:artifact-budget (marked@18.0.11). Main fails the same way, so this PR did not cause it; #6129 refreshes that ledger.

[Astro-Han]

Automated review notice: This comment was posted by an automated review agent. It is not an independent human review and does not replace one.Incremental review: d7f30ba3..1e181dbe, one merge of main at 2c429077 (#6129). The merge applied without conflicts: git show --remerge-diff is empty, so it adds no author change. My conclusions from d7f30ba3 still hold: no P0–P2 issue. The P3 about sign-off from a human committer on narrowing MakaTool.recoveryMode still applies. CI test now passes on this head.

[chinawch007]

AI review — OpenAI Codex. This automated review is not an independent human review and does not count as the committer approval required by CONTRIBUTING.md.

Reviewed 1e181dbe6711bea40cc985bb4bfdb02002ec7c0a against merge-base 2c42907728ba4a53fd1dacf66e3083793b3b6d6b (all 34 changed files), including the existing review discussion and the subsequent historical-database fixtures.

Conclusion: no new actionable correctness findings in the reviewed scope.

• Checked the removed writer/types/capability and requiresReconciliation against repository callers. No production consumer remains. Current tool declarations normalize legacy values at T1, while persisted legacy modes remain decodable.
• Checked historical completed/parked/prepared rows, direct startup reads without rebuild, bundle validation, projection rebuild and conversation-copy identity rewriting. The earlier startup-read coverage concern is addressed. Generic writers still reject recovery facts; workspace-authority transactions retain their separate guarded path.
• Traced ordinary T1-without-T2 through startup sealing, explicit-user-turn projection and continuation/replay rejection, and checked the Client Capability durable unknown response. The existing difference between the two unknown representations is unchanged and is not reported as a new defect.

Validation performed for this review: built Core, Storage, MCP, Runtime, both ACP plugins and Runtime Host from this exact head using Node 24.18.0 / npm 11.19.0, then ran 293 tests: 293 passed, 0 failed, 0 skipped.

Coverage	Passed
Core recovery authority; Storage persistence, process crash, concurrency, workspace authority and continuation admission	104
Runtime resolver/equivalence, T1/T2, resume/continuation crashes, conversation copy, Plan/Graph and MCP tools	158
Host recovery/continuation and Client Capability recovery	25
Selected unknown projection/retirement, startup sealing and Host image-tool tests	4
Host startup state matrix	2

git diff --check passes. GitHub's test check is also successful for this head. I did not rerun the full repository suite, Desktop E2E, packaging or cross-platform checks.

The exported source-API removal and proposed retirement of the #4319 reconciliation direction remain the already-disclosed maintainer decision. This review neither resolves that decision nor replaces the independent human committer review required by the contribution guide. #6089 and unifying unknown-outcome representations remain outside this cleanup.

[liugddx]

AI review — OpenAI Codex, posted on behalf of @liugddx. This review does not replace the independent human committer review required by CONTRIBUTING.md.

COMMENTED: no blocking findings; one non-blocking P3 cleanup. Reviewed 1e181dbe6711bea40cc985bb4bfdb02002ec7c0a against merge-base 2c42907728ba4a53fd1dacf66e3083793b3b6d6b. The removal preserves historical bundle reading, conversation copy, and projection rebuild, keeping the compatibility boundary intact.

• P3 (non-blocking): remove the orphaned helper. The only caller of assertNoReservedRecoveryFact in packages/storage/src/sqlite-runtime-store.ts:4979 was the recovery bundle writer removed by this PR. Only the declaration remains. Delete this local helper; the active validation in tool-commit-validation.ts remains in use. An inline comment is attached.
• PR description correction: “Hosted CI remains blocked” is stale. The test check passes on the reviewed head.

Assessment of the approach:

• Optimal solution: for the stated goal of retiring unused functionality, this is a reasonable and sufficiently small change.
• First principles: removing a write entry point with no production consumers while retaining the authority for interpreting historical facts is the right separation. Neither commitToolRecoveryBundle nor requiresReconciliation had a production caller. Resume admission still uses Resolver decisions to block unresolved tool calls.
• Occam's razor: remove the dead helper above; no replacement abstraction is needed.
• Test quality: no low-quality tests to delete. The normalization regression has demonstrated discrimination: restoring the old expression fails the assertion for a historical replay_safe declaration; restoring the current implementation passes. Keep the historical compatibility tests. The prepared/completed/parked SQL snapshots were also reproduced with the actual old writer and compared table by table, with matching results.

Validation and limitations: the focused tests passed 169/169. An additional Core/conversation-copy run had 37 passes and 13 failures, all reporting EBUSY while cleaning up SQLite files on Windows. I did not rerun those failures on the base, so I cannot attribute them to this PR. Core/Storage builds and git diff --check passed. The full Runtime build did not pass with the reused local dependency versions, which differ from this head's requirements. I did not run the full repository suite or Desktop E2E. These local limitations are recorded separately from the passing hosted CI on the reviewed head.

The smallest correct version is the current change with the dead helper removed. Removing the exported APIs and retiring the #4319 direction remain decisions for human maintainers.

[liugddx]

AI review — OpenAI Codex, posted on behalf of @liugddx. This is not a substitute for the independent human committer review required by CONTRIBUTING.md.

APPROVE at 1e181dbe6711bea40cc985bb4bfdb02002ec7c0a.

I rechecked the reviewed head and existing follow-up evidence. The removed reconciliation writer and requiresReconciliation have no production callers; historical recovery bundles remain readable, copyable and rebuildable; legacy declarations are normalised at the durable boundary; and the current test check is green. The focused validation and historical-database coverage reported in the review discussion support the compatibility claim.

The previously reported orphaned assertNoReservedRecoveryFact helper remains a small non-blocking P3 cleanup in packages/storage/src/sqlite-runtime-store.ts:4979. It does not affect runtime behaviour or merge safety. The exported API removal and retirement of the #4319 direction still deserve the human committer sign-off called out in the PR description.

No blocking correctness finding remains in this head.