fix(authority): confirm durable projections and recover archived Monitor state

[huangruiteng]

Goal And Delivered Outcome

Related to #4574 (R5), shared-authority D1/L5 and TS T2. Base: main.

A durable Markdown write previously proved provenance from the head read before rendering. It did not detect a canonical commit overlapping that write. Executed delivery now confirms the rendered revision against a fresh authority read after durable file readback. Unpinned settlement catches up at most three times; an explicitly pinned revision stays pinned and reports pending on overlap. Business commits are never repeated to repair display delivery.

Full-source recovery also rejected archived Monitor material_change_generation values because archive metadata remained textual while canonical records held integers. Archive readback now reuses the existing numeric decoder, preserving zero and strict parity.

Scope And Continuation

• Extract exact/list canonical reads from mutation orchestration into one TS read owner; share the existing provider-opening seam. Confirmation is an optional internal field on the existing list request, not a new RPC or durable authority record.
• Python retains Markdown rendering, durable IO and bounded retry. Ordinary reads and preview retain their behavior; downlevel runtimes cannot silently acknowledge delivery.
• Complete within this delivery/recovery boundary. No provider default, live promotion, new queue/drainer or broad Python retirement. Existing whole-Goal work feat(coordination): add reviewed whole-Goal coordination-authority promotion #4799, caller/executor work fix(control-plane): require explicit mutation actors #4816 and SQLite qualification [Task]: Qualify SQLite D2 capacity and crash/replay recovery on the merged provider #4224/test(sqlite): split logical, WAL and lock-wait capacity evidence #4778 retain their scopes. D2 soak and D3 cutover remain open.
• Bilingual shared-authority and TS checkpoints updated. Future-facing pass separates read ownership and reuses the generation codec without speculative provider structure.

Validation

• Tested revision: 4ec4de488a10c2308cebe4bd46510d6125e175f7. Full backend suites ran on the same PR patch at 4b4fbbcd; the stable patch id is 809a3137. Later rebases first integrated disjoint quota/extensions and PR-review changes, then main's promotion-plan provider/policy binding in the shared runtime. The resulting exact head passed the affected promotion/provider runtime suite 67/67 and typecheck; the unchanged projection patch retains the Python 101/101, focused TS 91/91, provider 776/776, PostgreSQL 195/195 and Canary 19/19 evidence described below.
• Run state: finished
• Input classes: synthetic, public_fixture, authorized_private_read_only

Check kind	Result	Public-safe evidence / limitation
integration	passed	Final 25-file Canary premerge: 19 selected checks, zero failures and zero manual holds; exact-head structured review result verified
static	passed	TS typecheck, Ruff, configured mypy (22 sources), compile, diff/public-boundary checks
unit / integration	passed	Focused TypeScript: 91/91; focused Python: 101/101; File/SQLite/NoKV authority conformance: 776/776
real_backend	passed	Isolated PostgreSQL 16: 195/195, zero failed/skipped; native/legacy confirmation also exercised on real File/SQLite and NoKV reference
real_entrypoint	passed	Real CLI read/projection/terminal/archive plus Chat apply → failed display confirmation → same-proposal retry; canonical revision and task identity preserved
regression_parity	passed	Immutable baseline fails four stronger overlap assertions and six archived-generation regressions; a separate baseline reproduces an already-stale priority assertion, now aligned with the existing structured priority/title contract
real_backend / regression_parity	passed	Read-only frozen source (1,010 Todos, 9 leases) copied into disposable stores: baseline render rejection retained, head File/SQLite recovery catches up in two attempts, narrative and complete canonical records preserved; File/SQLite/PostgreSQL reads preserve the same full source

Stable delivery adds one full provider read. Five warm local samples on that source had medians about 1.30 s (File) and 1.15 s (SQLite); these are absolute observations, not a baseline speedup, fleet SLO or large-capacity qualification. Three attempts bound churn. A confirmation names one observed head, not future freshness or a database/filesystem transaction.

Private source material and diagnostic artifacts are excluded. Public synthetic cases reproduce the regression. PostgreSQL service HTTP/auth/deployment, long-running D2 soak and live cutover were not exercised or claimed.

Frontend / Visual Evidence

UI impact: none. No fields or controls added to the frontend. The existing Team Plan adapter already maps projection-pending to a retryable proposal failure, and the dashboard retries that same proposal; the expanded Chat integration verifies both write and confirmation failure. CLI readback exposes rendered/observed revisions. No Lark-specific write path or configuration editor changes.

Shared-authority RFC fixture impact

• Reuse productionScaleCoordinationFixture native/legacy shapes, including archived Monitor generation and complete Todo/lease inventories.
• Shared conformance verifies ordinary response parity, matching/current and overlapping/pending confirmation, full-source preservation and absence of authority writes.
• Frozen legacy source → disposable File/SQLite/PostgreSQL rehearsal; no live Goal, registry, writer fence, Todo or lease mutation.

Boundary Checklist

• Public-safe code, fixtures and summaries; no private state, logs, credentials or local paths.
• Cohesive projection recovery scope; no benchmark work.
• Existing UI flow inspected; UI impact none.
• Both commits include DCO sign-off.
• Exact-head author-owned review is published; merge remains an independent-maintainer decision because this changes control-plane/runtime behavior.

[huangruiteng]

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

Reviewed head: aadf403445b9b4e450eb081a5b0e76191c0e6ef4

动机

本 PR 是 #4574 / R5、shared-authority D1/L5、TS T2 的一个完整增量：提高已提交 Todo 的展示恢复可靠性。旧合同只承诺读取时的来源正确，写完 Markdown 并不检查期间 canonical 是否前进；本 PR 明确加强交付确认，不能把它描述成旧合同已经承诺了永久新鲜度。另外，归档 Monitor 的整数代数被当成字符串回读，确实会阻断整份严格投影恢复。

改动思路

复用已有 list RPC、provider selector、journal-backed 投影路径、文件锁、writer fence 和耐久化工具。TS 在完整快照上核对“已渲染 revision”和“本次观察 revision”；Python 承担实际文件 IO 和最多三次追赶。没有新队列、持久 ACK、后台 worker 或默认 provider。显式固定 revision 的命令遇到并发只报告 pending，不能擅自改成另一个目标。

具体改动

• local_authority_read.ts 接管原 mutation runtime 中的 exact/list 读取；local_authority_provider.ts 接管共享打开入口和根路径校验，实际 handlers、handoff 与测试引用同步迁移。普通读取的完整数据、顺序、acceptance guard、错误与无 Markdown fallback 语义保持。
• projection_delivery.ts 定义并验证内部 readback 输入，在同一次完整 authority 读取中派生 pending/delivered/current。Python bridge 拒绝缺失或不一致的确认，旧 runtime 不会被默认为成功。
• provider_projection.py 在文件耐久读回后确认，复用返回的完整快照追赶；持续变化有上限，缺失文件首次使用仅创建写入，后续追赶使用普通替换。失败保留原业务提交，重试展示不会重复业务。
• machine_section_projection.py 让归档 Monitor 复用现有整数解码，保留零值和严格语义比较，不改写 canonical 记录。
• 测试覆盖真实 File/SQLite 竞争提交、固定版本、连续变化、缺失展示、确认故障及旧 runtime；Chat 同 proposal 重试保持任务和 canonical revision。四种 provider/reference 的 native/legacy 合成 fixture 证明完整来源及只读确认。原有 priority 测试在 baseline 已失败，本 PR 仅按既有结构化 priority/title 协议修正断言。
• 投影协议与中英文 shared-authority、TS RFC 更新这段已交付边界，保留 D2、整 Goal 切换和默认晋升的原门槛。

对主干的风险

主要取舍是正常执行多一次完整 provider 读取。确认只证明某个观察点一致，之后 canonical 仍可能前进；它不是数据库与文件的原子事务。读取故障可能使业务已成功但展示仍 pending，这是可见且可恢复的状态。

25 个文件，产品代码净增 86 行，其中 Python 净增 45 行；读模块搬迁不冒充已删除重复业务规则。未扩大 provider 权限、actor/lease 生命周期或 quota 义务。UI 沿用既有 Team Plan 失败后重试原 proposal 的路径，后端真实交互已覆盖；没有新增页面或配置。

验证：100 项 TS 聚焦测试；Python 分组运行分别为 39、50、60 项及 2 项旧 runtime 用例（分组可能重叠）；隔离真实 PostgreSQL 16 的 193 项集成测试全部通过且零跳过；Canary 19 项通过；TS typecheck、Ruff、配置内 mypy、compile 和公共边界检查通过。最终提交质量回执已验证。

不可变 baseline 上，4 项更强的并发确认用例和 6 项归档代数用例失败；head 通过。经授权只读冻结的完整来源在隔离 File/SQLite 下恢复并追赶成功，三个真实 provider 保持完整 canonical 来源；原始数据未公开。PostgreSQL HTTP/auth/部署、D2 长期 soak 和 live cutover 不在本次验证范围。按本 Goal 的 wait_for_ci=false 策略未查询远端 CI。

我的整体评价

APPROVE。没有发现阻塞项。它闭合了一条实际运行的投影恢复链路，代码边界合理，失败与重试都有真实入口证据；额外读取成本作为非阻塞取舍保留。更小的归档修复会留下交付确认缺口，更大的队列或全面宿主改写则超出已证明需要的范围。

未来重构检查已落实：读取从写编排独立出来，provider 打开和代数解码复用既有 owner；保留仍有真实调用方的 Python IO。D1 全量 consumer、D2、D3 和默认切换仍需后续验收。本评审不授权晋升或合并，PR 留待 maintainer。

English verdict: APPROVE - aadf403. Durable projection confirmation and archived Monitor recovery are validated through real entrypoints and isolated File/SQLite/PostgreSQL. No blocking finding; one additional full read is an explicit tradeoff. Canary 19 and PostgreSQL 193 passed; default promotion and long-soak qualification remain open.

[huangruiteng]

Merge-readiness qualification

评估对象：aadf403445b9b4e450eb081a5b0e76191c0e6ef4

当前 exact head 已有完整的 author-owned APPROVE 结论；本次按 capability 的 qualify_pull_request_merge_readiness 动作只复核合并前状态，不重复代码审阅。

结论：NOT READY。

• exact head 未漂移，现有 review conclusion 仍绑定该提交；
• GitHub merge state 为 DIRTY，必须先基于当前 main 解决冲突；
• 28 个检查中 25 个成功、3 个失败：test-shard (2)、pytest、merge-gate；
• review thread 完整且无 unresolved thread；
• readiness gate 的阻塞原因为 status_checks_failed、status_checks_incomplete、merge_state_requires_update。

最小下一步：rebase/update 当前分支并保留已审语义，修复或重跑失败检查；head 一旦变化，旧 review/readiness 不得复用，需要对新 exact head 重新执行完整 review 与 merge-readiness gate。此结论不授予 merge authority，admin bypass 也不能覆盖该 gate。

English verdict: REQUEST_CHANGES - exact head aadf403 retains its prior code approval but is not merge-ready because the branch is DIRTY and test-shard, pytest, and merge-gate are failing; update/rebase, restore green checks, then restart exact-head review and readiness.

[huangruiteng]

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

Reviewed head: 4b4fbbcdaffd9941be827f767ed3f260fd464b94

动机

本 PR 闭合 shared-authority D1/L5 的一个独立交付缺口：旧路径能证明 Markdown 来自写入前读到的 canonical head，却无法发现耐久写期间发生的并发 canonical commit，因此可能把刚落后的展示误报为 delivered/current。同时，归档 Monitor 的 material_change_generation 来自文本元数据，未复用已有整数 codec 时会与 canonical 整数严格比较失败，阻断整份恢复。

这是 #4574/R5 的有用增量，不宣称完成整个 D1/D2/D3。整 Goal consumer、长期 soak、默认切换和 live promotion 仍留在既有后续边界；本 PR 只解决“耐久展示确认 + 有界追赶 + 归档代数恢复”。

改动思路

canonical authority 继续是唯一真相。TS 读取 owner 在一次完整 provider read 上比较“主机已经耐久读回的 rendered revision”和“本次观察到的 provider head”；Python 继续负责真实 Markdown IO、fsync/readback 与最多三次的未固定版本追赶。显式固定 revision 绝不自动改目标，持续 churn 或确认故障保持 pending，业务提交不会重做。

设计复用了现有 list effect、provider selector、TodoProjectionDelivery、原子文件写入与 normalize_todo_generation，没有新增 RPC、持久 ACK、队列、后台 worker、provider 默认或第二套 authority。rebase 时同时保留了主干后来加入的 promotion-review 与 Agent-addressed read 语义。

具体改动

• 将 canonical exact/list read 从 mutation orchestration 拆到 local_authority_read.ts，并把 provider opening/root validation 放回共享 owner；普通请求不带 projection_readback，响应形状与完整来源保持不变。
• projection_delivery.ts 严格解码内部 readback，只以 revision 精确相等映射 delivered/current，不相等映射 pending。
• provider_projection.py 在耐久文件读回后请求确认；未固定版本复用返回的完整新快照，最多三次。缺失文件只在首次写使用 create-only，后续追赶走普通原子替换。
• 归档 Monitor 复用现有 generation 数字解码，保留 0，非法值仍拒绝，不改写 canonical 记录。
• 协议和中英文 RFC 明确新增读取成本、观察点而非永久新鲜度、固定版本语义及未完成边界。

关键代码讲解

1. project_current_canonical_todos：展示副作用与有界重试 owner；保证 pinned intent 不漂移、business mutation 不重放。
2. listLocalCoordinationTodos：在同一个完整 provider snapshot 上返回 ordinary data 与可选确认，避免 Python 成为第二个 canonical-head 判断者。
3. confirmProjectionReadback：纯 typed equality，将 revision mismatch 明确归类为 pending。
4. openRuntimeAuthorityStore：让 read/mutation 复用同一 provider construction seam，保留已有测试注入与生产 selector。
5. _parsed_archive_records：让归档 generation 与 active/capture 使用同一整数 codec。

对主干的风险

主要代价是稳定交付增加一次完整 provider read；本地观测约束不等于未来永久新鲜度。读取失败可能出现“业务已提交、展示 pending”，但状态可见且可通过原 projection path 恢复。没有发现权限、lease、claim、quota、scheduler 或默认 provider 的扩张。

精确 head 验证：

• Python 聚焦：101/101；TypeScript 聚焦：91/91。
• File/SQLite/NoKV authority conformance：776/776。
• 隔离 PostgreSQL 16：195/195，0 failed，0 skipped；临时实例已停止并移入废纸篓。
• TS typecheck、Ruff、配置内 mypy（22 sources）、py_compile、diff/public boundary 均通过。
• 最终 25-file Canary：19/19，0 failure，0 manual hold。
• immutable defect baseline 曾失败 4 项 overlap 与 6 项 archived-generation 回归；相关 defect-owner 文件从该 baseline 到当前 main 未变化，head 全部通过。

一次早期本地 conformance 调用未设置 LOOPX_TEST_PYTHON，错误使用系统旧 Python，因此被判为无效并中止；绑定 worktree 解释器后的完整套件已全部通过。按 loopx-meta 的 wait_for_ci=false 策略，本次未读取、轮询或等待远端 CI。

未验证且未声称：PostgreSQL service HTTP/auth/deployment、live production traffic、长期 D2 soak 与 D3 cutover。

我的整体评价

APPROVE。未发现阻塞项。改动把 canonical 比较放在正确的 TS owner，把文件耐久与有限恢复留给真实 Python host，兼容普通读路径，并用真实四类 backend 与负路径证明不会 false-ack、无限循环或重复业务提交。相较只修归档 codec，它闭合了实际交付链；相较新增 drainer/事务层，它保持了合适范围。

未来重构检查已落实：读取从 mutation runtime 分离、provider opening/root validation 复用、归档 generation 复用现有 codec；当前没有证据支持继续扩张抽象。

这是 control-plane/runtime 行为变更；本评审不授予作者自合并或 admin-bypass 权限，按仓库政策应由独立 maintainer 在该 exact head 上完成合并决定。

English verdict: APPROVE - 4b4fbbc. The rebased exact head preserves main's promotion-review and Agent-addressed read semantics, validates durable projection confirmation and archived Monitor recovery across File/SQLite/NoKV/PostgreSQL, and has no blocking finding. Local validation passed without consulting CI; independent maintainer merge is still required by repository policy.

[huangruiteng]

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

Reviewed head: 5624c4cf6c2c18b51045dba689921ceb22e34ea2

动机

本 PR 闭合 shared-authority D1/L5 的一个独立交付缺口：旧路径能证明 Markdown 来自写入前读到的 canonical head，却无法发现耐久写期间发生的并发 canonical commit，因此可能把刚落后的展示误报为 delivered/current。同时，归档 Monitor 的 material_change_generation 来自文本元数据，未复用已有整数 codec 时会与 canonical 整数严格比较失败，阻断整份恢复。

这是 #4574/R5 的有用增量，不宣称完成整个 D1/D2/D3。整 Goal consumer、长期 soak、默认切换和 live promotion 仍留在既有后续边界；本 PR 只解决“耐久展示确认 + 有界追赶 + 归档代数恢复”。

改动思路

canonical authority 继续是唯一真相。TS 读取 owner 在一次完整 provider read 上比较“主机已经耐久读回的 rendered revision”和“本次观察到的 provider head”；Python 继续负责真实 Markdown IO、fsync/readback 与最多三次的未固定版本追赶。显式固定 revision 绝不自动改目标，持续 churn 或确认故障保持 pending，业务提交不会重做。

设计复用了现有 list effect、provider selector、TodoProjectionDelivery、原子文件写入与 normalize_todo_generation，没有新增 RPC、持久 ACK、队列、后台 worker、provider 默认或第二套 authority。rebase 时同时保留了主干后来加入的 promotion-review 与 Agent-addressed read 语义。

具体改动

• 将 canonical exact/list read 从 mutation orchestration 拆到 local_authority_read.ts，并把 provider opening/root validation 放回共享 owner；普通请求不带 projection_readback，响应形状与完整来源保持不变。
• projection_delivery.ts 严格解码内部 readback，只以 revision 精确相等映射 delivered/current，不相等映射 pending。
• provider_projection.py 在耐久文件读回后请求确认；未固定版本复用返回的完整新快照，最多三次。缺失文件只在首次写使用 create-only，后续追赶走普通原子替换。
• 归档 Monitor 复用现有 generation 数字解码，保留 0，非法值仍拒绝，不改写 canonical 记录。
• 协议和中英文 RFC 明确新增读取成本、观察点而非永久新鲜度、固定版本语义及未完成边界。

关键代码讲解

1. project_current_canonical_todos：展示副作用与有界重试 owner；保证 pinned intent 不漂移、business mutation 不重放。
2. listLocalCoordinationTodos：在同一个完整 provider snapshot 上返回 ordinary data 与可选确认，避免 Python 成为第二个 canonical-head 判断者。
3. confirmProjectionReadback：纯 typed equality，将 revision mismatch 明确归类为 pending。
4. openRuntimeAuthorityStore：让 read/mutation 复用同一 provider construction seam，保留已有测试注入与生产 selector。
5. _parsed_archive_records：让归档 generation 与 active/capture 使用同一整数 codec。

对主干的风险

主要代价是稳定交付增加一次完整 provider read；本地观测约束不等于未来永久新鲜度。读取失败可能出现“业务已提交、展示 pending”，但状态可见且可通过原 projection path 恢复。没有发现权限、lease、claim、quota、scheduler 或默认 provider 的扩张。

精确 head 验证：

• Python 聚焦：101/101；TypeScript 聚焦：91/91。
• File/SQLite/NoKV authority conformance：776/776。
• 隔离 PostgreSQL 16：195/195，0 failed，0 skipped；临时实例已停止并移入废纸篓。
• TS typecheck、Ruff、配置内 mypy（22 sources）、py_compile、diff/public boundary 均通过。
• 最终 25-file Canary：19/19，0 failure，0 manual hold。
• immutable defect baseline 曾失败 4 项 overlap 与 6 项 archived-generation 回归；相关 defect-owner 文件从该 baseline 到当前 main 未变化，head 全部通过。

后续两次 base-only rebase 的主干增量分别只涉及 quota/extensions 与 PR-review skill/contract tests；最终补丁指纹保持 809a3137，25 个 PR 文件与完整验证时的内容逐字节一致。最后一次受影响运行路径验证仍为 Python 101/101、TS 91/91、typecheck 与 Canary 19/19。

一次早期本地 conformance 调用未设置 LOOPX_TEST_PYTHON，错误使用系统旧 Python，因此被判为无效并中止；绑定 worktree 解释器后的完整套件已全部通过。按 loopx-meta 的 wait_for_ci=false 策略，本次未读取、轮询或等待远端 CI。

未验证且未声称：PostgreSQL service HTTP/auth/deployment、live production traffic、长期 D2 soak 与 D3 cutover。

我的整体评价

APPROVE。未发现阻塞项。改动把 canonical 比较放在正确的 TS owner，把文件耐久与有限恢复留给真实 Python host，兼容普通读路径，并用真实四类 backend 与负路径证明不会 false-ack、无限循环或重复业务提交。相较只修归档 codec，它闭合了实际交付链；相较新增 drainer/事务层，它保持了合适范围。

未来重构检查已落实：读取从 mutation runtime 分离、provider opening/root validation 复用、归档 generation 复用现有 codec；当前没有证据支持继续扩张抽象。

这是 control-plane/runtime 行为变更；本评审不授予作者自合并或 admin-bypass 权限，按仓库政策应由独立 maintainer 在该 exact head 上完成合并决定。

English verdict: APPROVE - 5624c4c. The rebased exact head preserves main's promotion-review and Agent-addressed read semantics, validates durable projection confirmation and archived Monitor recovery across File/SQLite/NoKV/PostgreSQL, and has no blocking finding. Later base-only changes were disjoint and the PR patch/files remained identical. Local validation passed without consulting CI; independent maintainer merge is still required by repository policy.

[huangruiteng]

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

Reviewed head: 4ec4de488a10c2308cebe4bd46510d6125e175f7

动机

本 PR 闭合 shared-authority D1/L5 的一个独立交付缺口：旧路径能证明 Markdown 来自写入前读到的 canonical head，却无法发现耐久写期间发生的并发 canonical commit，因此可能把刚落后的展示误报为 delivered/current。同时，归档 Monitor 的 material_change_generation 来自文本元数据，未复用已有整数 codec 时会与 canonical 整数严格比较失败，阻断整份恢复。

这是 #4574/R5 的有用增量，不宣称完成整个 D1/D2/D3。整 Goal consumer、长期 soak、默认切换和 live promotion 仍留在既有后续边界；本 PR 只解决“耐久展示确认 + 有界追赶 + 归档代数恢复”。

改动思路

canonical authority 继续是唯一真相。TS 读取 owner 在一次完整 provider read 上比较“主机已经耐久读回的 rendered revision”和“本次观察到的 provider head”；Python 继续负责真实 Markdown IO、fsync/readback 与最多三次的未固定版本追赶。显式固定 revision 绝不自动改目标，持续 churn 或确认故障保持 pending，业务提交不会重做。

设计复用了现有 list effect、provider selector、TodoProjectionDelivery、原子文件写入与 normalize_todo_generation，没有新增 RPC、持久 ACK、队列、后台 worker、provider 默认或第二套 authority。rebase 时同时保留了主干后来加入的 promotion-review 与 Agent-addressed read 语义。

具体改动

• 将 canonical exact/list read 从 mutation orchestration 拆到 local_authority_read.ts，并把 provider opening/root validation 放回共享 owner；普通请求不带 projection_readback，响应形状与完整来源保持不变。
• projection_delivery.ts 严格解码内部 readback，只以 revision 精确相等映射 delivered/current，不相等映射 pending。
• provider_projection.py 在耐久文件读回后请求确认；未固定版本复用返回的完整新快照，最多三次。缺失文件只在首次写使用 create-only，后续追赶走普通原子替换。
• 归档 Monitor 复用现有 generation 数字解码，保留 0，非法值仍拒绝，不改写 canonical 记录。
• 协议和中英文 RFC 明确新增读取成本、观察点而非永久新鲜度、固定版本语义及未完成边界。

关键代码讲解

1. project_current_canonical_todos：展示副作用与有界重试 owner；保证 pinned intent 不漂移、business mutation 不重放。
2. listLocalCoordinationTodos：在同一个完整 provider snapshot 上返回 ordinary data 与可选确认，避免 Python 成为第二个 canonical-head 判断者。
3. confirmProjectionReadback：纯 typed equality，将 revision mismatch 明确归类为 pending。
4. openRuntimeAuthorityStore：让 read/mutation 复用同一 provider construction seam，保留已有测试注入与生产 selector。
5. _parsed_archive_records：让归档 generation 与 active/capture 使用同一整数 codec。

对主干的风险

主要代价是稳定交付增加一次完整 provider read；本地观测约束不等于未来永久新鲜度。读取失败可能出现“业务已提交、展示 pending”，但状态可见且可通过原 projection path 恢复。没有发现权限、lease、claim、quota、scheduler 或默认 provider 的扩张。

精确 head 验证：

• Python 聚焦：101/101；TypeScript 聚焦：91/91。
• File/SQLite/NoKV authority conformance：776/776。
• 隔离 PostgreSQL 16：195/195，0 failed，0 skipped；临时实例已停止并移入废纸篓。
• TS typecheck、Ruff、配置内 mypy（22 sources）、py_compile、diff/public boundary 均通过。
• 最终 25-file Canary：19/19，0 failure，0 manual hold。
• immutable defect baseline 曾失败 4 项 overlap 与 6 项 archived-generation 回归；相关 defect-owner 文件从该 baseline 到当前 main 未变化，head 全部通过。

前两次 base-only rebase 的主干增量只涉及 quota/extensions 与 PR-review skill/contract tests。最新 main 又在共享 runtime 加入 promotion-plan provider/policy binding；PR 补丁指纹仍保持 809a3137，rebase 后专门重跑受影响的 promotion/provider runtime 测试 67/67 和 typecheck，确认 read-owner 迁移没有覆盖新规则。其余证据仍绑定同一 PR patch：Python 101/101、TS 91/91、Canary 19/19。

一次早期本地 conformance 调用未设置 LOOPX_TEST_PYTHON，错误使用系统旧 Python，因此被判为无效并中止；绑定 worktree 解释器后的完整套件已全部通过。按 loopx-meta 的 wait_for_ci=false 策略，本次未读取、轮询或等待远端 CI。

未验证且未声称：PostgreSQL service HTTP/auth/deployment、live production traffic、长期 D2 soak 与 D3 cutover。

我的整体评价

APPROVE。未发现阻塞项。改动把 canonical 比较放在正确的 TS owner，把文件耐久与有限恢复留给真实 Python host，兼容普通读路径，并用真实四类 backend 与负路径证明不会 false-ack、无限循环或重复业务提交。相较只修归档 codec，它闭合了实际交付链；相较新增 drainer/事务层，它保持了合适范围。

未来重构检查已落实：读取从 mutation runtime 分离、provider opening/root validation 复用、归档 generation 复用现有 codec；当前没有证据支持继续扩张抽象。

这是 control-plane/runtime 行为变更；本评审不授予作者自合并或 admin-bypass 权限，按仓库政策应由独立 maintainer 在该 exact head 上完成合并决定。

English verdict: APPROVE - 4ec4de4. The rebased exact head preserves main's promotion-plan binding, promotion-review, and Agent-addressed read semantics, validates durable projection confirmation and archived Monitor recovery across File/SQLite/NoKV/PostgreSQL, and has no blocking finding. The PR patch id remained stable and the affected exact-head promotion/provider suite passed 67/67. Local validation passed without consulting CI; independent maintainer merge is still required by repository policy.