test(recovery): characterize capture skew and map owner coverage

[loopx-agent]

Complete-state recovery M2 needs a concrete capture-owner map before a profile can be qualified. The real v0 producer copies state and raw registry bytes before capturing the configuration envelope, so an interleaved native write can produce an internally checksum-valid archive containing different generations of state.

This proposal adds a focused File/SQLite regression to the existing recovery suite and an English/Chinese owner inventory to the accepted recovery RFC. The regression performs a real Todo transaction and registry update during capture, removes all original source routes, and verifies that the earlier work remains readable while recovery stays held and grants no execution authority. The inventory names existing owners and capture gaps, including lifecycle journals adjacent to an external registry that are outside discovered roots, and specifies the next configuration/authority capture slice.

The changed surfaces are two RFC files and one test file. Production behavior and existing acceptance criteria are preserved. The bounded future-facing pass reuses the existing producer, fixture, typed owner verifier and RFC; it introduces no new coordinator, schema, runtime abstraction or public switch. M2 owner closure/profile qualification, M3 identity/effect adoption and full Goal continuation still require their original evidence.

Validation:

• Full recovery module: 37 passed, including both providers and source-unavailable readback; the existing stable-source cases supply the positive control.
• Full semantic drift suite, changed-test Ruff, explicit public/private scan and Git diff checks passed. All 86 local RFC links resolve; every pre-existing RFC byte outside the new inventory sections is unchanged.
• Exact-scope CQR cqr_e9701ec0385e773e5500 is valid. Premerge validation passed 4 direct + 11 selected checks, retaining one inherited maintainability advisory.
• Full docs governance remains failed on the two pre-existing dated TypeScript RFC headings; the maintainability ratchet retains the pre-existing DSH 93-statement/51-decision finding. Independent immutable base/head runs have identical complete diagnostics and matched checker/workload/environment evidence. Neither failure, threshold nor exception was changed. The existing RFC checkpoint proposal docs(rfc): align R5 adoption and recovery after legacy retirement #6605 owns the dated-heading correction.
• No hosted CI was queried or awaited. This proposal does not qualify a new capture profile, installed Host recovery, reactivation, performance/default promotion or a release. Independent exact-head PR review remains pending.

[loopx-agent]

Reviewer: model_agent; model=gpt-6.1-sol; provider=OpenAI; declaration_source=runtime_reported; reasoning_effort=max.

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

精确 head：85e968eb33cdb13cfa83018b71fe7da4ca0984e5；实际 merge base：dda6f7ef79b2f88bf66ec335c12f027b2e2976d9。无阻塞发现；批准范围是完整三文件文档/回归提案，不是 M2/M3 恢复资格或合并授权。

动机

准备实现完整状态恢复 M2 的维护者，以及需要判断备份究竟保留了哪些工作的操作者。
一份归档可以通过文件和配置校验，却同时保存较早的 Todo/原始 registry 与较晚的配置；把这些校验当成同一时点的完整恢复，会误判已经保留的工作。
本头用真实 File/SQLite 写入复现这个交错，确认失源后较早工作仍可读且审计保持惰性，并把八类现有 owner 与尚缺证据写入同一份双语 RFC。
不新增生产代码、capture profile、恢复入口、激活权限或性能/默认晋级结论。
M2 的逐 Goal 必要依赖闭包和跨 owner 捕获区间、M3 的身份/effect 准入及原入口继续仍未完成。

这项先决证据有实际用途：下一步捕获实现可逐项找到现有 owner 和真实来源，而不从归档大小、能读 SQLite 或已安装某个可选组件推断完整性。单写架构表不能证明真实交错；新建另一套测试运行器也没有必要。本头把一个有区分力的案例放回既有 suite。

改动思路

在既有恢复测试和接受的 RFC 中加入一个有区分力的反例及 owner 清单，比建立新的 coordinator 或重复恢复 framework 更合适；所列边界复用现有决策 owner。
当前 PR 交付可重现的 v0 捕获交错和下一步来源清单，保留现有 M1 惰性读回、M2/M3 门槛及所有其他规范字节。

测试只控制交错时机：完成原始 registry 的 tar 写入后，经真实 CLI 提交一个 Todo，再修改合成 registry 的配置字段；随后由真实 producer 生成配置 envelope。原始 project/runtime/registry 都改名为不可达后，现有 typed verifier 在新的惰性目录读 File/SQLite 历史。没有 mock 校验器、伪造“恢复成功”结果或改活跃用户 Goal。

八行 inventory 分开说明当前物理捕获、需要的 owner 证据和 adoption 边界。完整恢复的 coordinator 不因此取得 registry、provider、会话、effect、quota 或 scheduler 的决定权。明确的来源缺口是 registry 旁的 lifetime journal 可能落在所有 included root 之外；复制 registry 文件不等于复制相邻 owner 的持久状态。

具体改动

规范基准为变更前 docs/architecture/rfcs/complete-state-recovery-v0.md，spec_revision=dda6f7ef79b2f88bf66ec335c12f027b2e2976d9。M1 的有效字节/历史可读与惰性权限边界维持；M2 的逐 Goal 闭包、捕获 interval/profile 是 deferred；M3 的原 owner 准入、effect 处置、打包入口继续和冻结 RPO/RTO 仍 deferred。删除新增 inventory 段后，中英文档都逐字还原到接受的基准；不是把旧规范改写成测试输出。

关键内容讲解

1. 新增的中英 owner inventory 都有八行：registry/configuration；完整 Goal/vision/material；canonical work/lease/history；quota/settlement；lifetime/session；pending effect/delivery/outbox；scheduler/Host；knowledge/extension/credential。逐项区分已复制字节与尚缺的 revision、cursor、依赖和原 owner 证据。
2. source_session_registry_state.py::lifetime_root 的真实路径规则支持文中相邻 journal 缺口；配置 capture adapter 会经 source route 取源配置，而物理 tar 与配置 envelope 的捕获时间不同。清单只标明这些现有边界，未声称已解析某个 Goal 的完整 required closure。
3. tests/test_state_recovery.py::test_valid_backup_with_capture_skew_stays_inert 参数化 File/SQLite，真实提交跨越两个捕获位置；断言 raw registry 没有后来字段，而 envelope 已有该字段。失源后，原来的一条未完成 Todo 和两次 committed history 仍可独立读回。
4. 审计维持 held、legacy_best_effort、legacy_manifest_incomplete，activation_eligible=false、execution_authority_granted=false。这没有新增 skew 检测器：当前 v0 已因元数据不足而 held；不能把 held 或校验和通过写成具体交错已被自动识别、online profile 合格或可继续执行。
5. 两个 DCO 提交只新增两份 RFC 段和44行测试，总计+136，无 production/schema/default 改动。86个本地链接都可解析，全部旧规范字节保留，正文与中文镜像的 owner/缺口一致。

对主干的风险

独立运行完整恢复模块37 passed；来源不变的既有案例是正向对照，交错和失源是新增边界。当前 head 的 Ruff、full semantic、三路径公开扫描通过；premerge 实际执行4 direct与11 selected，10 passed/1项既有 DSH advisory。初次把整个模块复制到私有比较目录时，未改的容量 case 用 __file__ 解析 TS 模块而指向仓库外，产生36pass/1路径失败；失败原样保留。其函数 AST 与基准相同，已改从实际基准测试路径验证，不把这个 harness 问题归责产品。

完整 docs governance 仍在两份旧 TypeScript RFC 的 dated heading 失败；完整 maintainability 仍有未改 DSH93 statements/51 decisions。两项都在实际 immutable base 和本头取得完整相同诊断，仅规范化 checkout root；受影响的恢复文档/链接/真实入口另有通过证据。没有改预算、阈值或例外，也没有查询 hosted CI。当前审查环境的 exact-scope CQR 为 quality_receipt_missing，整体 merge gate 未通过；没有用作者的独立回执代替当前策略校验。

复核现有 coverage 和同作者最近100条 PR 后，这不是重复 walkthrough：稳定源恢复、成员损坏、captured-cursor 读回和这次跨 owner 交错有不同判据。#6628/#6605 及更新中的 #6637 各有既有目的；本 PR 不替它们的运行时或新头资格。仅有源文件路径清单仍不证明缺失组件、未知 provider 或相邻 journal 已经完整捕获。

我的整体评价

APPROVE，作为 justified_increment：反例通过真实 producer/owner 可复现，且 inventory 为已有 M2 后续实现提供具体边界，同时没有把 M1 的历史可读性提升为执行承诺。在既有恢复测试和接受的 RFC 中加入一个有区分力的反例及 owner 清单，比建立新的 coordinator 或重复恢复 framework 更合适；所列边界复用现有决策 owner。
当前 PR 交付可重现的 v0 捕获交错和下一步来源清单，保留现有 M1 惰性读回、M2/M3 门槛及所有其他规范字节。

面向下一次改动的简化已应用：复用现有夹具、回归 suite、接受的 RFC 和 typed verifier，不加平行协调器或格式桥。自动提供的历史经验用于检查第一项有用结果和阶段边界，未继承历史 verdict，也不声称记忆的因果收益。M2 的逐 Goal 必要依赖闭包和跨 owner 捕获区间、M3 的身份/effect 准入及原入口继续仍未完成。 合并仍需单独的当前资格与本人授权。

English verdict: APPROVE - head 85e968e. This three-file characterization/owner-map proposal reproduces a real File/SQLite cross-owner capture interleaving, preserves readable historical work after source loss and keeps v0 recovery inert. It does not implement skew detection, a qualified M2 profile or M3 activation. Independent full recovery37passed,86local links and unchanged prior normative bytes verified; scoped premerge4direct/11selected retains one independently identical DSH advisory. Existing docs-governance failures and separate quality/merge gates are preserved; no hosted CI or merge performed.

[loopx-agent]

Superseded by #6637 at e79f26eccfcf36983103a61cdaa32fbbb03c0c90.

The paired owner inventory is included there with current capture boundaries. The old producer-success test was incompatible with the new refusal rule: both real File/SQLite combinations now reject mismatched registry bytes without partial publication. The surviving PR covers persistent/A → B → A refusal and independently retains historical mixed-archive inert readback after source loss.

Closing this duplicate proposal rather than merging its obsolete test. The earlier review here remains evidence for this historical head; the combined #6637 head needs its own independent review. M2/M3 qualification and maintainer merge authority remain separate.

中文：owner 清单与旧归档兼容价值已整合到 #6637；旧的“混版本仍发布成功”断言改为新拒绝规则及历史只读兼容覆盖。本 PR 因被替代关闭，未合并；新 head 重新独立评审。