fix(authority): recover canonical Todo projection during refresh

[huangruiteng]

Problem and behavior

A promoted Goal can have committed canonical Todos but stale or missing Markdown. Ordinary refresh-state and same-Turn replay did not recover that display. Refresh planning read canonical Todos, but the missing-work diagnostic read Markdown again, producing either a false expansion request or a hidden empty frontier.

This closes the refresh caller's recovery gap under #4574 and the shared-authority L5/D1 / TypeScript T3 checkpoints:

• Committed refresh and same-Turn replay reuse existing journal-backed Todo projection recovery. Display failure remains pending alongside successful refresh; recovery does not repeat Todo mutations, quota settlement or replayed run history.
• Planning, gap diagnosis and initial rendering share a complete canonical snapshot. Durable publication still requires a fresh provider confirmation; concurrent advances are retried from the returned complete snapshot.
• TypeScript owns latest-versus-pinned intent and the three-attempt bound through a typed confirmation. Python retains locking, rendering and durable publication. Pinned requests never silently retarget.
• Behavior change: committed promoted refresh now repairs Todo sections. Legacy and dry-run behavior remain unchanged. Existing non-Todo narrative is preserved; missing documents recover Todo sections only.

The existing Todo projection owner is sufficient: no new capability, provider, persisted ACK, RPC method or schema version. The adjacent refactor removes Python retry policy and duplicate Markdown-based Todo diagnosis. CLI JSON/Markdown and Turn use the same boundary; no settings or packaged frontend assets change, and external-delivery authorization remains unchanged.

Validation

• Full TypeScript control-plane suite: 2,874 passed, 24 skipped (integration opt-ins tested separately where applicable); typecheck passed.
• Focused Python production-entrypoint, refresh/replay, planning, concurrency and projection suites: 223 passed.
• Real isolated PostgreSQL 16.15, Node 24.21.0: authority suite 285 passed, zero skipped. An earlier run used an incompatible subprocess Python; after selecting the checkout environment, one run hit a 90-second child timeout. The isolated complete rerun passed; the earlier failures are not counted as passes.
• Disposable File/SQLite rehearsals from an authorized read-only source snapshot verified ordinary refresh, actual CLI replay, publication failure, missing-display recovery and unchanged canonical readback. Active source state was not migrated or modified; private snapshots and logs are excluded.
• Extended the existing 464-Todo production-scale fixture; all-provider confirmation conformance checks pinned/latest overlap and bounded retry.
• Risk-based premerge canary: 10 selected checks passed out of 15 matched candidates; compile, maintainability and diff checks passed, no manual holds. Ruff and public-boundary scan passed.

Remaining boundary

This is the refresh recovery slice, not full L5 consumer qualification, a background drainer or a provider-default switch. Successful confirmation is a point-in-time observation; another writer may advance immediately afterward. Recovery adds durable display work and confirmation IO, with no latency-improvement claim.

Updated English/Chinese RFCs retain an estimated 5–8 cohesive delivery packages for remaining caller/executor fences, consumer qualification, SQLite D2, whole-Goal migration and default/retirement. They reconcile merged #4870/#4888/#4920 and still-open #4922/#4931, including the failing and missing D2 evidence in #4224. PostgreSQL deployment qualification remains separate. Rendering and validated import/export are not slated for indiscriminate Python deletion.

[huangruiteng]

Request changes conclusion (author-owned PR; GitHub blocks formal self-review)

Reviewed exact head: fa245069c60cb10e95a615d0e7a9543e0e5faece

动机

已提升到 canonical Todo authority 的 Goal，普通 refresh-state 或同一 Turn 重放可能在业务提交成功后仍留下缺失/过期的 Markdown Todo 区。继续从 Markdown 诊断缺口会误报待办扩展，或隐藏可执行前沿。该 PR 要让刷新顺手恢复显示，而不重做 Todo 写入、quota 结算或历史事件。

改动思路

方案复用现有 provider 快照、journal-backed projection outbox 和机器区渲染，不增加第二个队列/ACK。规划阶段携带完整 canonical 快照，持久发布前重新确认 provider revision；TS 决定 pinned/latest 与三次尝试上限，Python 保留锁、渲染和发布。这个归属方向合理，pinned 不追新 head，失败保持 pending。

具体改动

关键代码讲解

• refresh_state_run 在已提交刷新和 replay 返回处调用 recover_refresh_todo_projection，并将 canonical Todo 字段传给缺口诊断；空 canonical 分组不会退回旧 Markdown。
• project_current_canonical_todos 可复用规划快照渲染，但仍通过新的 provider readback 确认是否需要重试；旧业务提交不重放。
• confirmProjectionReadback 给出 finish/retry 的 typed 决策；文档和 268 行 refresh 回归测试覆盖恢复、失败与重叠。

本地聚焦验证：41 个 Python 测试、7 个 TS 测试及 git diff --check 通过。没有在这些路径上复现新的代码缺陷。

对主干的风险

当前 exact head 的必需集成检查仍为红：Frontstage Pages 的 showcase catalog smoke 因 README 语句断言失败；此后 main 的 #4969 已修该 smoke，说明本分支需要吸收主干后重测。minimum-Node 检查另有 4 个 SQLite deferred-lease 用例失败（不在本 PR 改动路径），merge-gate 也失败。不能把这些失败直接归因于本补丁，但也不能把局部通过当作可合并证据。请先同步当前 main，对新 exact head 重跑必需检查；若 minimum-Node 仍红，定位并修复/隔离该 lane 后再复审。保持本 PR 的刷新、重放和 revision-overlap 回归覆盖。

我的整体评价

实现边界和已有局部证据支持这个恢复方向；本次结论仅因当前 head 的必需集成验证未闭合而请求修改，不要求增加新的恢复机制。相邻重构审视：现有 outbox 已足够，无需再抽象。新 head 与检查读回后可复审。

English verdict: REQUEST_CHANGES - At fa24506 the focused 41 Python/7 TS tests pass, but required Frontstage and minimum-Node checks remain red; sync current main and revalidate the exact head before merge.