feat(recovery): inspect full backups without activating restored state

[songoow]

Full backups previously needed manual extraction; the shipped recovery UI only handled configuration snapshots. This adds backup-state verify and full-archive inspection inside the existing Settings backup disclosure. An operator selects the archive/manifest pair, creates one new private inert copy, and reads which captured components are readable, historical-only or unknown. Previous reports remain discoverable after reload. Reports now retain measured archive/regular-file sizes and monotonic archive-processing/owner-read durations; historical readback preserves those observations and older reports without measurements show their absence.

The TypeScript owner binds observed archive/member bytes to both manifests, reuses configuration verification and complete canonical File/SQLite Todo/history readers, and never grants execution or adoption authority. Python handles bounded tar/filesystem IO. Database inspection runs in a disposable, time/memory-bounded process: a recursive SQLite metadata view must not stall the shared daemon. Sparse records are refused before standard-library extent decoding; a publication failure still cleans staging when the destination becomes occupied, preserving the foreign content. The real 20,001-commit history probe exposed a capacity failure being converted into an unknown component and published. History now checks its canonical cursor and aborts publication on the existing capacity code; exactly 20,000 commits remain fully readable. The UI distinguishes this definitive refusal from a lost response. Every v0 audit remains held for incomplete capture/owner metadata. No Goal, provider, Host, lease or pending effect is activated.

Conflict reconciliation at e50e3fbaeb94d6216d5ab321e1cf34dc10f68cc4 integrates main 38cb407edc39752d3ad6b4d414ca5c5255aba177. The backup guide preserves both exclusive publication/retry semantics and inert inspection. Fresh integration testing exposed a duplicated digest-format matcher; recovery now reuses the canonical bare SHA-256 owner, with its consumer registered in the existing guard. The initial TS run had 26 passes and one guard failure; after repair all 27 targeted TS cases pass. Fresh validation also passes 64 Python backup/configuration/recovery/member-integrity cases, control-plane and frontend typechecks, chat bundle build/verification, packaged browser journeys against disposable real File and SQLite owners, docs governance, semantic drift and the 291-site registry IO census. Browser checks cover absent original sources, keyboard/mobile/English flows, damaged input, retained historical measurements and no restored Goal registration. An initial bundle build refused a concurrent source edit; the stable-source rebuild passes. The reconciliation diff contains no detected credential literals or local/private paths. The prior wheel/capacity/platform qualification below is historical and was not repeated by this reconciliation. No merge or complete-recovery qualification is claimed.

Original qualification at 13dd7eca02c1cd240fa9a68bf51e6e917e0f6aed: 162 affected Python tests (including 35 recovery cases) and 27 targeted TS tests pass. Five new sparse/cleanup regression cases failed before repair and pass afterward; malformed PAX and metadata variants also reject. Typecheck, focused mypy/Ruff, semantic drift, docs governance and premerge (10 catalog + 8 risk + public boundary) pass. Old backup plan/configuration outputs match the immutable baseline after removing only the observation timestamp. Backend tests/premerge ran at 729287c1a; the final one-line frontend refinement is covered by fresh tsc/build and browser evidence. A fresh wheel from this head passed isolated-install HTTP asset verification and real File/SQLite packaged browser journeys: original sources hidden, Chinese/English, keyboard, mobile, damaged-input handling and historical report reload. Installed archive-adapter bytes match source and sparse refusal was exercised there too. The measured values displayed in the real packaged UI are unchanged after reload; malformed measurement values and digest tampering reject. Phase durations exclude uploads, verifier startup and final publication, and are not RTO. The native capacity matrix covers near-limit archive/expanded size, the 16 MiB manifest edge, exact 20,000/20,001 members, 128/129 File/SQLite Goals and history boundaries; all over-limit cases refuse with no destination or staging. The guide records local wall/RSS observations and their limitations. Python 3.12/3.13 installed tar-hook and ordinary inspection cases pass. Both final-wheel browser profiles also use a real over-limit history archive and preserve the previous report. Other workspace browser APIs remain synthetic fixtures.

Before/after and operator guide include public synthetic screenshots. Configuration JSON remains the default; one explicit archive-inspection action creates the inert copy. Opening navigation and the collapsed backup entry are unchanged.

This is a usable bounded increment of the accepted complete-recovery RFC, not full M1 qualification: maintainer capacity freeze, compound worst-case and broader platform/provider qualification remain open under Sections 10/12. M2 capture profiles, M3 controlled reactivation, Goal direction/amendment and live-model collaboration also remain open. No merge, deployment or change to the current user installation is claimed. The new component-state vocabulary is registered separately; F1/F2 remains six producer entries and #4447's original 26-entry closing scope is unchanged.

[songoow]

Reviewer: model_agent | GPT-6 | OpenAI | self_reported

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

Reviewed exact head: f5a8b76dd31d34dac43bccca9fd4ce35747724a1。
本次是作者账户下的模型自评，不是独立维护者批准。未发现阻塞这一有界检查增量的问题；完整恢复与发布资格仍有下述缺口。

动机

原 Goal 工作区已经不可用、手中只剩完整备份的本地用户，需要先知道积累的任务和历史是否还能读。原先设置页只能恢复配置，完整备份需要手工解包；现在选择归档和配套清单，一次操作即可建立隔离副本并查看保存的任务与历史。

File/SQLite 实测在原来源不可达后读到任务和历史，报告区分可读、仅历史与未知，刷新后仍可读回。此操作不注册或启动 Goal，不恢复旧租约、Host、凭据授权或未决外部操作。完整 M1 仍缺逐份耗时/数据大小报告及完整容量测量；M2 捕获一致性、M3 身份接纳和继续执行、远端存储及 G1 团队验收仍开放。

改动思路

归档 IO、领域可读性和界面投影各自沿既有 owner 扩展；独立进程只隔离已复现的数据库计算风险，不建立新的 Goal 权限源。本 PR 只交付来源丢失后的隔离检查与历史报告读回；逐份运行指标、容量资格和后续接纳继续归属原 recovery RFC。

Python 负责有上限的 gzip/tar 与文件系统操作。TypeScript 负责两份清单与观察字节的一致性、报告状态，以及通过原配置验证器、选定的 File/SQLite provider、完整 Todo/lease/acceptance reader 和 committed history 得出可读结论。报告是这些来源的派生观察，不是用户手填的成功状态，也不成为第二个 Goal store。旧格式无法证明的 owner 留在 unknown；数据库字节检查通过也只先算 historical-only。

直接沿用配置恢复无法覆盖完整归档与领域历史；增加通用 adoption 框架又会提前引入身份和外部 effect 权限。当前边界把可用检查、CLI/API、设置页和错误恢复放在同一 PR，副本可以独立检查与移除。配置快照仍是默认选项；文件选择提供原系统没有的两个输入，一次操作确认创建副本，没有多余的启用确认。

具体改动

全量 diff 为 30 个文件，主要是归档适配器、类型化 owner/contract、HTTP/client/UI、对应验证与文档。另有 JsonObject 移至纯 runtime_decode 并重导出，避免前端经类型引用带入 Node 依赖；词表、glossary 和原 registry IO 行号随之对齐。没有新增后台循环或第二套配置存储。截图使用公开可复现的合成数据。

关键代码讲解

1. verify_state_backup：先核对外部 digest，再扫描归档与清单。执行路径在私有 staging 中复制，再检查字节未变化、读取 owner、核验报告后发布到新目录。预览不虚构 owner 读取结果。现有目标拒绝覆盖；发布失败即使目标已被占用，仍清理自有 staging、保留外来内容。
2. auditOwners：配置复用 verifyConfigurationBackup；Goal 复用 openLocalAuthorityStoreHandle 与 canonicalTodoCollection，扫描全部历史并核对最终 head/revision。SQLite 先拒绝 view/virtual table，再做 integrity/领域读取。服务端 provider 不连接，缺失选定存储不新建或回退。
3. decodeStateRecoveryAudit：owner 和客户端共享状态、计数及依赖校验，禁止 true execution/activation。历史读回另外核对 digest 与备份身份；这证明报告未变，不证明副本后来没有变化。
4. StateRecoverySettings：只从既有设备范围的备份入口进入；错误清除旧成功展示，丢失响应可查原结果，刷新后能列出历史记录。历史状态明确写“尚未重新验证副本”，不会显示为新鲜运行状态。

与已接受规格逐项对照

依据 docs/architecture/rfcs/complete-state-recovery-v0.md，规格版本固定为 b760c1e，按 PR 修改前的要求判断；本 PR 仅更新成熟度检查点，没有降低规范要求。

规格原有行/章节	本提交处置与证据
Archive and manifest bind exactly	已实现本切片；archive、内外 manifest 和 member witness 负例均拒绝发布。
Extraction is confined	已实现本切片；路径、链接、碰撞、类型、容量、PAX/sparse 与失败清理覆盖。POSIX 之外不声称资格。
M1 stays inert	File/SQLite 原来源隐藏后执行；原 registry 不增加恢复 Goal，执行与 activation 始终 false。
M1 audit is understandable in product	新 wheel 的真实后端设置页流程通过，包括桌面/手机、中英文、键盘、损坏输入和历史重载。
v0 uncertainty is honest	每个 v0 报告保持 held 与 legacy_manifest_incomplete，未分类余项 unknown。
Privacy boundary holds	输出使用受限 Goal 标签、哈希组件 ID 和 opaque HTTP refs；原始路径/内容不进入报告或截图，public-boundary 检查通过。
SQLite and configuration remain valid	配置与生产者的独立 SQLite snapshot 已验证；WAL-mode 副本保持 unknown，完整存储 profile 验收继续由 recovery storage owner 承接。
10. Operational contract	部分实现；逐份耗时/大小与完整容量范围测量待补。不得将本次判断表述成完整 M1 已发布或生产 SLO。
Capture profiles are truthful	留给 M2；当前诚实保留 legacy best-effort，不推断跨 owner 同时刻。
Dependency graph is complete	完整 owner inventory 与交叉引用待 M2/M3；当前仅对已识别配置/authority 建依赖，其余显式未知。
M3 restores one Goal end to end	留给 M3；不调用身份、writer fence、session 或 effect 接纳路径，仍需恢复后续行和原入口独立验收。

对主干的风险

最强风险是把可读备份误当成可执行权限，或让非可信数据库计算阻塞共享 runtime。已复现递归 SQLite metadata view 超出有界探针，因此数据库检查放在可终止的独立进程：90 秒 deadline、512 MiB V8 heap、64 MiB SQLite process heap；owner audit 不注册到共享 Effect daemon。超时测试之后仍通过真实共享 runtime 执行普通配置操作。这个进程不是 G1 worker，也不证明多 Agent 协作。

本次复评还实际得到 5 个红例：四种 sparse 路径进入了不该进入的标准库 extent decoder，以及目标目录被占用后 staging 未清理。新提交提前拒绝 sparse，并用嵌套 finally 保证自有 staging 清理。没有复现或声称 sparse 死循环。PAX 变体和畸形长度也按受控错误拒绝；自有精确错误码优先保留。

最终验证：相关 Python 161 passed（其中 recovery 34 项）；本轮针对性 TS 26 passed；typecheck、mypy/Ruff、语义检查、docs governance 通过。完整 premerge 为 10 catalog + 8 risk + public boundary，另有 diff/compile 检查通过。五个缺陷负例先红后绿，没有删除断言或提高旧预算。更早的浏览器 fixture/等待时序问题已修正；本次新 wheel 的 File/SQLite 两条流程均重新通过。曾调用错误的 semantic smoke 文件名，随后实际运行的是仓库 semantic-vocabulary-drift-smoke，不把错误调用计作成功。

源代码与隔离 wheel 的归档模块字节相同，安装产物还单独执行了 sparse 拒绝；HTTP 静态资源验证通过。浏览器只把备份 API 接到真实隔离后端，其他 workspace API 仍是合成 fixture；没有执行真实模型、改变用户安装、恢复活跃 Goal 或连接 PostgreSQL。当前独立本地证据覆盖变更不变量；远端观察为 Summary 成功、七项作业排队，CI/维护者合并门单独保留。

语义与 CI 对齐

新增共享观察词表 state_recovery_component_state 有明确 TS owner；分类靠 typed literal/decoder，不靠文案匹配。registry 共 27 项，正式 F1/F2 producer 仍为六项，#4447 原 26 项关闭范围未扩张。diff advisory 与完整 drift 均已执行。next_action 是建议，执行禁止由契约和不存在的 activation 路径保证，未把硬门称为 guidance。错误与义务保持领域中立。

我的整体评价

结论为 APPROVE，justified_increment。long_horizon 和 user_experience 均有可验证改善：积累的完整工作记录可在来源丢失后被读取，错误不会伪造进度，历史能回到原设置流程。完整恢复、运行指标和容量资格尚未满足，必须继续原 RFC 的缺口，不能用本 PR 的测试数量关闭它们。

兼容性比较使用同一份合成输入，在固定 base/head 执行原 backup plan 和 configuration capture；仅去掉观察时间，完整 JSON 一致（SHA256 bd87f7aeb82b2010d85ee0c2b20e079c66c56d55c8f60c8ce4e3fd9d29127f1f）。新 verify 是有意增加的行为。旧配置路径在新 wheel 中先执行通过，再进入新检查；默认选择、既有启用边界和主导航保持原语义。扩大后的备份 disclosure 增加格式选项是已披露的界面变化，并非声称所有像素相同。

体量与结果相称：没有 generic adoption framework，复用了真正的配置/状态 owner。相邻收敛已做在共享 JsonObject 和 canonical domain reader 上；保留历史格式服务真实存量，不增加请求版本兼容梯子。剩余主要风险是 tarfile 私有 hook 的跨 Python 版本资格、完整容量范围以及未实现的恢复接纳。公开 guide、RFC checkpoint 和此评审保持相同的部分交付边界。本结论不授权合并、部署或全量 M1 发布。

English verdict: APPROVE - f5a8b76. The bounded inert-inspection increment reuses existing owners and preserves live authority; sparse and cleanup regressions were repaired. 161 Python tests, 26 targeted TS tests, premerge and fresh installed-wheel File/SQLite browser journeys pass. Full M1 operational qualification and M2/M3 recovery remain open; this self-review does not authorize merge or deployment.

[songoow]

Reviewer: model_agent | GPT-6 | OpenAI | self_reported

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

Reviewed exact head: 1f45a9819ab41d05eaff9a375760c1526393a2e1。
本次是作者账户下的模型自评，不是独立维护者批准。未发现阻塞这一有界检查增量的问题；完整恢复与发布资格仍有下述缺口。

动机

原 Goal 工作区已经不可用、手中只剩完整备份的本地用户，需要先知道积累的任务和历史是否还能读。原先设置页只能恢复配置，完整备份需要手工解包；现在选择归档和配套清单，一次操作即可建立隔离副本并查看保存的任务与历史。

File/SQLite 实测在原来源不可达后读到任务和历史，报告区分可读、仅历史与未知，刷新后仍可读回。此操作不注册或启动 Goal，不恢复旧租约、Host、凭据授权或未决外部操作。完整 M1 仍缺完整容量测量；M2 捕获一致性、M3 身份接纳和继续执行、远端存储及 G1 团队验收仍开放。

改动思路

归档 IO、领域可读性和界面投影各自沿既有 owner 扩展；独立进程只隔离已复现的数据库计算风险，不建立新的 Goal 权限源。本 PR 只交付来源丢失后的隔离检查与历史报告读回；容量资格和后续接纳继续归属原 recovery RFC。

Python 负责有上限的 gzip/tar 与文件系统操作。TypeScript 负责两份清单与观察字节的一致性、报告状态，以及通过原配置验证器、选定的 File/SQLite provider、完整 Todo/lease/acceptance reader 和 committed history 得出可读结论。报告是这些来源的派生观察，不是用户手填的成功状态，也不成为第二个 Goal store。旧格式无法证明的 owner 留在 unknown；数据库字节检查通过也只先算 historical-only。

直接沿用配置恢复无法覆盖完整归档与领域历史；增加通用 adoption 框架又会提前引入身份和外部 effect 权限。当前边界把可用检查、CLI/API、设置页和错误恢复放在同一 PR，副本可以独立检查与移除。配置快照仍是默认选项；文件选择提供原系统没有的两个输入，一次操作确认创建副本，没有多余的启用确认。

具体改动

相对上次评审 f5a8b76 的新增内容是报告内的实际数据量和阶段耗时：Python 用单调时钟记录归档处理，TS 记录 owner 读取，均在 digest 封存前写入。旧报告缺字段仍可读，界面显示未记录；修改测量值会使报告读回失败。新 wheel 的真实后端验证展示以及刷新前后数值相同。两个阶段明确排除上传、子进程启动和最终发布，不宣传为整体恢复时间。基线、既有调用者与运行环境未变；受影响检查和安装产物已重跑，未沿用旧 head 的批准。

全量 diff 为 30 个文件，主要是归档适配器、类型化 owner/contract、HTTP/client/UI、对应验证与文档。另有 JsonObject 移至纯 runtime_decode 并重导出，避免前端经类型引用带入 Node 依赖；词表、glossary 和原 registry IO 行号随之对齐。没有新增后台循环或第二套配置存储。截图使用公开可复现的合成数据。

关键代码讲解

1. verify_state_backup：先核对外部 digest，再扫描归档与清单。执行路径在私有 staging 中复制，再检查字节未变化、读取 owner、核验报告后发布到新目录。预览不虚构 owner 读取结果。现有目标拒绝覆盖；发布失败即使目标已被占用，仍清理自有 staging、保留外来内容。
2. auditOwners：配置复用 verifyConfigurationBackup；Goal 复用 openLocalAuthorityStoreHandle 与 canonicalTodoCollection，扫描全部历史并核对最终 head/revision。SQLite 先拒绝 view/virtual table，再做 integrity/领域读取。服务端 provider 不连接，缺失选定存储不新建或回退。
3. decodeStateRecoveryAudit：owner 和客户端共享状态、计数及依赖校验，禁止 true execution/activation。历史读回另外核对 digest 与备份身份；这证明报告未变，不证明副本后来没有变化。
4. StateRecoverySettings：只从既有设备范围的备份入口进入；错误清除旧成功展示，丢失响应可查原结果，刷新后能列出历史记录。历史状态明确写“尚未重新验证副本”，不会显示为新鲜运行状态。

与已接受规格逐项对照

依据 docs/architecture/rfcs/complete-state-recovery-v0.md，规格版本固定为 b760c1e，按 PR 修改前的要求判断；本 PR 仅更新成熟度检查点，没有降低规范要求。

规格原有行/章节	本提交处置与证据
Archive and manifest bind exactly	已实现本切片；archive、内外 manifest 和 member witness 负例均拒绝发布。
Extraction is confined	已实现本切片；路径、链接、碰撞、类型、容量、PAX/sparse 与失败清理覆盖。POSIX 之外不声称资格。
M1 stays inert	File/SQLite 原来源隐藏后执行；原 registry 不增加恢复 Goal，执行与 activation 始终 false。
M1 audit is understandable in product	新 wheel 的真实后端设置页流程通过，包括桌面/手机、中英文、键盘、损坏输入和历史重载。
v0 uncertainty is honest	每个 v0 报告保持 held 与 legacy_manifest_incomplete，未分类余项 unknown。
Privacy boundary holds	输出使用受限 Goal 标签、哈希组件 ID 和 opaque HTTP refs；原始路径/内容不进入报告或截图，public-boundary 检查通过。
SQLite and configuration remain valid	配置与生产者的独立 SQLite snapshot 已验证；WAL-mode 副本保持 unknown，完整存储 profile 验收继续由 recovery storage owner 承接。
10. Operational contract	部分实现；逐份归档/普通文件大小及两个处理阶段耗时现已记录，完整容量范围测量待补。不得将本次判断表述成完整 M1 已发布或生产 SLO。
Capture profiles are truthful	留给 M2；当前诚实保留 legacy best-effort，不推断跨 owner 同时刻。
Dependency graph is complete	完整 owner inventory 与交叉引用待 M2/M3；当前仅对已识别配置/authority 建依赖，其余显式未知。
M3 restores one Goal end to end	留给 M3；不调用身份、writer fence、session 或 effect 接纳路径，仍需恢复后续行和原入口独立验收。

对主干的风险

最强风险是把可读备份误当成可执行权限，或让非可信数据库计算阻塞共享 runtime。已复现递归 SQLite metadata view 超出有界探针，因此数据库检查放在可终止的独立进程：90 秒 deadline、512 MiB V8 heap、64 MiB SQLite process heap；owner audit 不注册到共享 Effect daemon。超时测试之后仍通过真实共享 runtime 执行普通配置操作。这个进程不是 G1 worker，也不证明多 Agent 协作。

本次复评还实际得到 5 个红例：四种 sparse 路径进入了不该进入的标准库 extent decoder，以及目标目录被占用后 staging 未清理。新提交提前拒绝 sparse，并用嵌套 finally 保证自有 staging 清理。没有复现或声称 sparse 死循环。PAX 变体和畸形长度也按受控错误拒绝；自有精确错误码优先保留。

最终验证：相关 Python 161 passed（其中 recovery 34 项）；本轮针对性 TS 27 passed；typecheck、mypy/Ruff、语义检查、docs governance 通过。完整 premerge 为 10 catalog + 8 risk + public boundary，另有 diff/compile 检查通过。五个缺陷负例先红后绿，没有删除断言或提高旧预算。更早的浏览器 fixture/等待时序问题已修正；本次新 wheel 的 File/SQLite 两条流程均重新通过。曾调用错误的 semantic smoke 文件名，随后实际运行的是仓库 semantic-vocabulary-drift-smoke，不把错误调用计作成功。

源代码与隔离 wheel 的归档模块字节相同，安装产物还单独执行了 sparse 拒绝；HTTP 静态资源验证通过。浏览器只把备份 API 接到真实隔离后端，其他 workspace API 仍是合成 fixture；没有执行真实模型、改变用户安装、恢复活跃 Goal 或连接 PostgreSQL。运行指标新 UI 已检查真实渲染：收在原核对信息中，不增加必经交互；SQLite 样本显示 4,465 归档字节、33,560 普通文件字节、归档处理 84 ms 和读取 14 ms，仅为这次合成样本，不能外推容量/SLO。当前独立本地证据覆盖变更不变量；远端观察为 Summary 成功、七项作业排队，CI/维护者合并门单独保留。

语义与 CI 对齐

新增共享观察词表 state_recovery_component_state 有明确 TS owner；分类靠 typed literal/decoder，不靠文案匹配。registry 共 27 项，正式 F1/F2 producer 仍为六项，#4447 原 26 项关闭范围未扩张。diff advisory 与完整 drift 均已执行。next_action 是建议，执行禁止由契约和不存在的 activation 路径保证，未把硬门称为 guidance。错误与义务保持领域中立。

我的整体评价

结论为 APPROVE，justified_increment。long_horizon 和 user_experience 均有可验证改善：积累的完整工作记录可在来源丢失后被读取，错误不会伪造进度，历史能回到原设置流程。完整恢复和容量资格尚未满足，必须继续原 RFC 的缺口，不能用本 PR 的测试数量关闭它们。

兼容性比较使用同一份合成输入，在固定 base/head 执行原 backup plan 和 configuration capture；仅去掉观察时间，完整 JSON 一致（SHA256 bd87f7aeb82b2010d85ee0c2b20e079c66c56d55c8f60c8ce4e3fd9d29127f1f）。新 verify 是有意增加的行为。旧配置路径在新 wheel 中先执行通过，再进入新检查；默认选择、既有启用边界和主导航保持原语义。扩大后的备份 disclosure 增加格式选项是已披露的界面变化，并非声称所有像素相同。

体量与结果相称：没有 generic adoption framework，复用了真正的配置/状态 owner。相邻收敛已做在共享 JsonObject 和 canonical domain reader 上；保留历史格式服务真实存量，不增加请求版本兼容梯子。剩余主要风险是 tarfile 私有 hook 的跨 Python 版本资格、完整容量范围以及未实现的恢复接纳。公开 guide、RFC checkpoint 和此评审保持相同的部分交付边界。本结论不授权合并、部署或全量 M1 发布。

English verdict: APPROVE - 1f45a98. The bounded inert-inspection increment reuses existing owners and preserves live authority; sparse and cleanup regressions were repaired. 161 Python tests, 27 targeted TS tests, premerge and fresh installed-wheel File/SQLite browser journeys pass. Full M1 operational qualification and M2/M3 recovery remain open; this self-review does not authorize merge or deployment.

[songoow]

Reviewer: model_agent | GPT-6 | OpenAI | self_reported

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

Reviewed exact head: 13dd7eca02c1cd240fa9a68bf51e6e917e0f6aed。
本次是作者账户下的模型自评，不是独立维护者批准。未发现阻塞这一有界检查增量的问题；完整恢复与发布资格仍有下述缺口。

动机

原 Goal 工作区已经不可用、手中只剩完整备份的本地用户，需要先知道积累的任务和历史是否还能读。原先设置页只能恢复配置，完整备份需要手工解包；现在选择归档和配套清单，一次操作即可建立隔离副本并查看保存的任务与历史。

File/SQLite 实测在原来源不可达后读到任务和历史，报告区分可读、仅历史与未知，刷新后仍可读回。此操作不注册或启动 Goal，不恢复旧租约、Host、凭据授权或未决外部操作。完整 M1 仍需维护者冻结容量默认值，以及组合最坏情形和更广平台的验证；M2 捕获一致性、M3 身份接纳和继续执行、远端存储及 G1 团队验收仍开放。

改动思路

归档 IO、领域可读性和界面投影各自沿既有 owner 扩展；独立进程只隔离已复现的数据库计算风险，不建立新的 Goal 权限源。本 PR 只交付来源丢失后的隔离检查与历史报告读回；容量资格和后续接纳继续归属原 recovery RFC。

Python 负责有上限的 gzip/tar 与文件系统操作。TypeScript 负责两份清单与观察字节的一致性、报告状态，以及通过原配置验证器、选定的 File/SQLite provider、完整 Todo/lease/acceptance reader 和 committed history 得出可读结论。报告是这些来源的派生观察，不是用户手填的成功状态，也不成为第二个 Goal store。旧格式无法证明的 owner 留在 unknown；数据库字节检查通过也只先算 historical-only。

直接沿用配置恢复无法覆盖完整归档与领域历史；增加通用 adoption 框架又会提前引入身份和外部 effect 权限。当前边界把可用检查、CLI/API、设置页和错误恢复放在同一 PR，副本可以独立检查与移除。配置快照仍是默认选项；文件选择提供原系统没有的两个输入，一次操作确认创建副本，没有多余的启用确认。

具体改动

相对上次评审 1f45a98，本次重审发现并修复真实容量问题：20,001 次 SQLite 提交曾被标为 unknown 但仍发布副本。现在复用 canonical cursor decoder 在扫描前检查，容量异常沿原 owner 向上传递；20,000 次完整读取、20,001 次无副本拒绝的真实 CLI 测试先红后绿。界面只对这一明确拒绝清掉“检查是否已有结果”，避免把它当成响应丢失；已有历史报告仍可读取。基线、既有调用者、依赖未变，受影响验证和最终安装产物已重跑，未继承旧批准。运行数据沿用相同报告和两个单调计时阶段，没有增加 RPC、权限或容量上限。

全量 diff 为 30 个文件，主要是归档适配器、类型化 owner/contract、HTTP/client/UI、对应验证与文档。另有 JsonObject 移至纯 runtime_decode 并重导出，避免前端经类型引用带入 Node 依赖；词表、glossary 和原 registry IO 行号随之对齐。没有新增后台循环或第二套配置存储。截图使用公开可复现的合成数据。

关键代码讲解

1. verify_state_backup：先核对外部 digest，再扫描归档与清单。执行路径在私有 staging 中复制，再检查字节未变化、读取 owner、核验报告后发布到新目录。预览不虚构 owner 读取结果。现有目标拒绝覆盖；发布失败即使目标已被占用，仍清理自有 staging、保留外来内容。
2. auditOwners：配置复用 verifyConfigurationBackup；Goal 复用 openLocalAuthorityStoreHandle 与 canonicalTodoCollection，扫描全部历史并核对最终 head/revision。SQLite 先拒绝 view/virtual table，再做 integrity/领域读取。服务端 provider 不连接，缺失选定存储不新建或回退。
3. decodeStateRecoveryAudit：owner 和客户端共享状态、计数及依赖校验，禁止 true execution/activation。历史读回另外核对 digest 与备份身份；这证明报告未变，不证明副本后来没有变化。
4. StateRecoverySettings：只从既有设备范围的备份入口进入；错误清除旧成功展示，丢失响应可查原结果，刷新后能列出历史记录。历史状态明确写“尚未重新验证副本”，不会显示为新鲜运行状态。

与已接受规格逐项对照

依据 docs/architecture/rfcs/complete-state-recovery-v0.md，规格版本固定为 b760c1e，按 PR 修改前的要求判断；本 PR 仅更新成熟度检查点，没有降低规范要求。

规格原有行/章节	本提交处置与证据
Archive and manifest bind exactly	已实现本切片；archive、内外 manifest 和 member witness 负例均拒绝发布。
Extraction is confined	已实现本切片；路径、链接、碰撞、类型、容量、PAX/sparse 与失败清理覆盖。POSIX 之外不声称资格。
M1 stays inert	File/SQLite 原来源隐藏后执行；原 registry 不增加恢复 Goal，执行与 activation 始终 false。
M1 audit is understandable in product	新 wheel 的真实后端设置页流程通过，包括桌面/手机、中英文、键盘、损坏输入和历史重载。
v0 uncertainty is honest	每个 v0 报告保持 held 与 legacy_manifest_incomplete，未分类余项 unknown。
Privacy boundary holds	输出使用受限 Goal 标签、哈希组件 ID 和 opaque HTTP refs；原始路径/内容不进入报告或截图，public-boundary 检查通过。
SQLite and configuration remain valid	配置与生产者的独立 SQLite snapshot 已验证；WAL-mode 副本保持 unknown，完整存储 profile 验收继续由 recovery storage owner 承接。
10. Operational contract	部分实现；逐份数据量/处理耗时与单轴容量案例已测；维护者默认值冻结、组合最坏情形和其他平台仍待资格化。不得将本次判断表述成完整 M1 已发布或生产 SLO。
Capture profiles are truthful	留给 M2；当前诚实保留 legacy best-effort，不推断跨 owner 同时刻。
Dependency graph is complete	完整 owner inventory 与交叉引用待 M2/M3；当前仅对已识别配置/authority 建依赖，其余显式未知。
M3 restores one Goal end to end	留给 M3；不调用身份、writer fence、session 或 effect 接纳路径，仍需恢复后续行和原入口独立验收。

对主干的风险

最强风险是把可读备份误当成可执行权限，或让非可信数据库计算阻塞共享 runtime。已复现递归 SQLite metadata view 超出有界探针，因此数据库检查放在可终止的独立进程：90 秒 deadline、512 MiB V8 heap、64 MiB SQLite process heap；owner audit 不注册到共享 Effect daemon。超时测试之后仍通过真实共享 runtime 执行普通配置操作。这个进程不是 G1 worker，也不证明多 Agent 协作。

本次复评还实际得到 5 个红例：四种 sparse 路径进入了不该进入的标准库 extent decoder，以及目标目录被占用后 staging 未清理。新提交提前拒绝 sparse，并用嵌套 finally 保证自有 staging 清理。没有复现或声称 sparse 死循环。PAX 变体和畸形长度也按受控错误拒绝；自有精确错误码优先保留。

最终验证：相关 Python 162 passed（其中 recovery 35 项）；本轮针对性 TS 27 passed；typecheck、mypy/Ruff、语义检查、docs governance 通过。完整 premerge 为 10 catalog + 8 risk + public boundary，另有 diff/compile 检查通过。162 项后端测试和 premerge 的源提交为 729287c；最终 13dd7ec 仅新增一行前端 pending 清理和两行浏览器断言，后端字节未变，最终 wheel 的 tsc/build 和真实浏览器覆盖该差异。五个缺陷负例先红后绿，没有删除断言或提高旧预算。更早的浏览器 fixture/等待时序问题已修正；本次新 wheel 的 File/SQLite 两条流程均重新通过。曾调用错误的 semantic smoke 文件名，随后实际运行的是仓库 semantic-vocabulary-drift-smoke，不把错误调用计作成功。

容量修复 wheel 在 884eae4 构建并通过 Python3.12/3.13 的安装检查；最终 13dd7ec 又重新构建 wheel、安装到独立环境并验证 HTTP 静态资源及两条浏览器旅程。归档 Python 模块始终相同，未将旧 wheel 当作最新前端。浏览器只把备份 API 接到真实隔离后端，其他 workspace API 仍是合成 fixture；没有执行真实模型、改变用户安装、恢复活跃 Goal 或连接 PostgreSQL。运行指标新 UI 已检查真实渲染：收在原核对信息中，不增加必经交互；SQLite 样本显示 4,465 归档字节、33,560 普通文件字节、归档处理 84 ms 和读取 14 ms，仅为这次合成样本，不能外推容量/SLO。当前独立本地证据覆盖变更不变量；远端观察为 Summary 成功、七项作业排队，CI/维护者合并门单独保留。

本次还通过 native producer → 真 CLI 测得容量案例：511 MiB 展开数据和 127 MiB 不可压缩数据可检查；512 MiB 数据加归档开销和 128 MiB+1 的压缩输入拒绝；外部清单以 JSON 空白填至 16 MiB 可接受、再多一字节拒绝；精确 20,000/20,001 成员通过/拒绝；128 个真实 File/SQLite Goal 均可读，129 个按对应上限拒绝。所有拒绝均无新目标和残留 staging。单次观察最长为 20,000 成员的 8.698 秒，time -l 报告的最大 RSS 225.8 MiB；不是进程树同时占用总和、生产 SLO 或所有上限可组合的证明。原指南记录完整范围与量纲，§12 的维护者冻结没有被自评替代。

旧版本生成的 authority_history_capacity held 报告已用当前真实读回函数核对完整相等，未删除或重写；新请求的拒绝与旧报告的历史事实分别成立。浏览器使用真实 20,001 提交归档，验证清晰拒绝、无无效查结果按钮、旧报告仍可读；File/SQLite 原成功路径也通过。

语义与 CI 对齐

新增共享观察词表 state_recovery_component_state 有明确 TS owner；分类靠 typed literal/decoder，不靠文案匹配。registry 共 27 项，正式 F1/F2 producer 仍为六项，#4447 原 26 项关闭范围未扩张。diff advisory 与完整 drift 均已执行。next_action 是建议，执行禁止由契约和不存在的 activation 路径保证，未把硬门称为 guidance。错误与义务保持领域中立。

我的整体评价

结论为 APPROVE，justified_increment。long_horizon 和 user_experience 均有可验证改善：积累的完整工作记录可在来源丢失后被读取，错误不会伪造进度，历史能回到原设置流程。完整恢复、容量默认值的维护者冻结与组合最坏情形资格尚未满足，必须继续原 RFC 的缺口，不能用本 PR 的测试数量关闭它们。

兼容性比较使用同一份合成输入，在固定 base/head 执行原 backup plan 和 configuration capture；仅去掉观察时间，完整 JSON 一致（SHA256 bd87f7aeb82b2010d85ee0c2b20e079c66c56d55c8f60c8ce4e3fd9d29127f1f）。新 verify 是有意增加的行为。旧配置路径在新 wheel 中先执行通过，再进入新检查；默认选择、既有启用边界和主导航保持原语义。扩大后的备份 disclosure 增加格式选项是已披露的界面变化，并非声称所有像素相同。

体量与结果相称：没有 generic adoption framework，复用了真正的配置/状态 owner。相邻收敛已做在共享 JsonObject 和 canonical domain reader 上；保留历史格式服务真实存量，不增加请求版本兼容梯子。剩余主要风险是未测试的 Python/平台组合、复合容量最坏情形以及未实现的恢复接纳；已有 Python3.12.13/3.13.12 安装产物通过普通检查和 GNU/PAX sparse/metadata 拒绝。公开 guide、RFC checkpoint 和此评审保持相同的部分交付边界。本结论不授权合并、部署或全量 M1 发布。

English verdict: APPROVE - 13dd7ec. The bounded inert-inspection increment reuses existing owners and preserves live authority; sparse and cleanup regressions were repaired. 162 Python tests, 27 targeted TS tests, premerge and fresh installed-wheel File/SQLite browser journeys pass. Full M1 operational qualification and M2/M3 recovery remain open; this self-review does not authorize merge or deployment.

[mergify]

This pull request has merge conflicts with main and cannot be merged
until they are resolved. Please rebase or merge the base branch, @songoow.

Choose the remote for the base repository, not an out-of-date fork.
For a fork clone, first inspect git remote -v; upstream must point
to https://github.com/loopx-project/loopx.git. If it is absent, add it
with git remote add upstream https://github.com/loopx-project/loopx.git.
Then run:

git fetch upstream
git rebase upstream/main
# Resolve each conflict, git add the resolved files, then git rebase --continue.
git push --force-with-lease origin HEAD

For a same-repository clone whose origin points to
https://github.com/loopx-project/loopx.git, use origin instead of
upstream for fetch/rebase. If you prefer merging the base, use
git merge <base-remote>/main and push normally.

Keep the DCO Signed-off-by trailer on every commit when you rebase.
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[loopx-agent]

Reviewer: model_agent · gpt-6.1-sol · OpenAI · runtime_reported · reasoning_effort=xhigh

Reviewed exact head: e50e3fb

动机

持有本地完整备份及清单、原工作区不可达，需要检查哪些未完成工作仍可读的操作者。
完整备份只支持计划/创建，需要手工解包；原设置入口只恢复配置快照，来源失联后没有受约束的完整归档检查与可读工作历史页面。
同一新wheel页面通过真实File/SQLite后端读取原来源失联后的未完成任务，分开显示可读、仅历史和未知；归档检查与历史重载保持held和零执行权限，损坏/超限不替换旧审计。
不注册Goal、选择liveprovider、恢复Host/lease/timer/effects或使用归档凭据；不证明全量M1运行资格、M2/M3、G1协作、其它平台/provider、生产SLO。
功能与负例资格已建立，当前未见新的代码正确性阻塞；修改前RFC规定的维护者容量默认值冻结仍明确开放，属于当前M1合并阻塞。复合最坏情形、其它平台/服务provider、M2/M3及生产SLO未资格；没有 live recovery、网络provider验证或merge。

改动思路

复用既有配置、选定存储与完整Todo/history reader；TypeScript组合只决定离线可读性，Python做有界tar/私有文件IO，数据库验证在可终止进程内隔离；沿原备份disclosure增加显式格式选择，不创建adoption框架。
当前是可逆的M1验证/隔离读取实现切片，M2捕获一致性和M3身份/作用接纳独立；但M1合并前容量冻结是原§12.1前置门，不能用部分交付标签延期该门。
归档/审计digest绑定观察，组件数量是派生投影；recorded audit是历史事实，不能从当前时间补算成新验证。共享JsonObject下沉到primitive decoder并保留实际effect_program调用者reexport；digest与domainreader复用已有owner。已做相邻有界收敛，不加入M3框架或第二authority。

具体改动

规范依据：docs/architecture/rfcs/complete-state-recovery-v0.md@38cb407，按修改前accepted文本判断。§9表格没有额外验收编号，使用原行名；新checkpoint和作者旧head自评不能豁免这些条件。

• §5 / M1 verify-audit boundary：M1 verifies/extracts/audits without live activation, v0 incompletefactsheld（implemented）。
• §7 / v0 compatibility and privacy：Retaincreationflags/v0historicaldata, privateoutput andno restoredcode（implemented）。
• §9 / Archive and manifest bind exactly：Observedbytes bindarchive/bothmanifests/memberinventory andrejectcorruption（implemented）。
• §9 / M1 audit is understandable in product：ExistingpackagedSettings viewshowsstates/owner/oneactionwithoutauthority（implemented）。
• §10 / M1 duration and data size：Measuredverificationphases/bytes withoutRTOclaim andoldreportabsencehonest（implemented）。
• §11 / M1 entry gate：AcceptedRFC plusfrozenlimits/auditschema beforeoperator-accessibleM1merge（not_met）。
• §12.1 / M1 capacity defaults：Backup/reliabilitymaintainers freezearchive/expansion/entry/graph/time defaults beforeM1merge（not_met）。
• §11 / M2-M3：Captureconsistency andcontrolledGoaladoption remain separate laterowner milestones（out_of_scope）。

关键代码讲解

• loopx/state_recovery.py:342 verify_state_backup：observed bytes先核对archive，再进行有界scan/manifest/member校验；execute只在新私有staging读取owner、重hash并发布inertcopy，旧目标拒绝。
• loopx/control_plane/state_recovery.ts:71 verifyStateRecoveryManifest / inspectGoal：复用canonicaldigest、配置与选定File/SQLite完整Todo/history reader。20,000cursor上限先检查；超限传播拒绝，不改成unknown后继续发布。
• loopx/state_recovery.py:87 _audit_owners / state_recovery_worker：数据库检查位于可终止90s、512MiB V8/64MiB SQLite的独立进程；shared daemon没有owner-audit dispatch，恢复代码和视图不被执行。
• state-recovery-settings.tsx:33 StateRecoverySettings：设备范围显式选择归档/清单并执行，结果区分当前检查和历史读回；新input清旧success，响应丢失读原checkpoint，明确历史容量拒绝不制造已有结果按钮。

对主干的风险

当前精确head独立执行60项Python、27项TypeScript均通过、无skip；包括真实File/SQLite CLI在原来源失联后的完整Todo/journal、审计不可变、选定store缺失不创建/不回退、恶意tar/PAX/sparse/links/collision、SQLiteview、worker超时后共享runtime可用、20,000全量历史及20,001拒绝。原生premerge5项直接和19项选中执行检查通过。不可变旧基线25项原backup/config测试通过；同路径合成输入的实际配置HTTP导出/restorepreview/unknowninput/foreignorigin与普通backupplan完整观察一致，只归一化每次plan的created_at观测时间，不归一化SHA、身份、权限、字段或错误。

当前normal wheel在独立Python3.12环境安装，归档Python、typedowner/decoder和前端assets与当前source字节相等。Ego真实wheel页面+真实HTTP File/SQLite后端完成一项原unfinished task读取，原source已失联；当前runtime只保持原fixture Goal，三个显式inertcopy不注册Goal。键盘Tab/Enter、390px无横向溢出、损坏输入清旧success、旧audit bytes不变、真实20,001容量清晰拒绝、丢失响应读回原copy及reload保留原measurement/time均验证。其它workspace发现/status为syntheticfixture，没有live模型、活动Goal、PostgreSQL或用户安装改动。没有继承作者162等旧head测试数字。

阻塞发现

[P2] M1 当前 profile 仍缺维护者容量冻结（RFC checkpoint:40–41）。修改前 §11 / M1 entry gate 要求frozen limits，§12.1 / M1 capacity defaults 明确在M1 merge前由backup/reliabilitymaintainers冻结archive、expansion、entry、graph和verification-time默认值；当前checkpoint和guide却仍宣布此冻结开放，CLI/HTTP/UI已提供该M1检查profile。单项容量成功证明实现行为，不能代替owner决定；partial标签也不能把原before-merge门延期到发布。最小修复是在原RFC/checkpoint或reviewthread记录维护者对当前profile的明确冻结和边界，再核对实际入口使用这些值；或保持为不可用的实现前置切片，直到原owner门满足。无需为此重跑CI或一并完成M2/M3。当前功能验证没有新的正确性blocker，但这个accepted验收项为not_met。

语义与 CI 对齐

Advisory先于全树semantic检查；新state_recovery_component_state注册一个TS owner与shareddecoder，readable/historical_only/unknown是观察语义，不是执行生命周期。正式producer闭合资格没有从6项扩张成27项。local-snapshot新方法扩展既有成对Python/TStransport allowlist，普通2MiB RPC不升限。无substring新分类或领域专属通用控制面义务；owner next_action是建议，private/permissionfalse/容量拒绝为强制，§12.1冻结也是明确前置义务。off路径的原完整配置值、错误、权限和普通backup语义经真实base/head对照保持；增加设备格式radio是披露的界面增量，不声称pixel相同。CI为not_consulted，不查询/等待。本次没有merge或冻结授权；复合最坏情形、其它平台/provider和后续M2/M3仍按原milestone保留。

我的整体评价

long_horizon=improved：原来源失联后仍可读完整历史，copied lease/effects没有新权威；user_experience=improved：已有入口一次明确操作获得可读性结果，错误/历史/unknown诚实，原配置路径保持。
实现是justified_increment，31路径围绕同一完整source/CLI/HTTP/packagedUI切片，体量包含必要tar边界与真实receiver负例，已有decoder/digest/domainreaders足够。相邻refactor已应用，无需新activation框架。整体REQUEST_CHANGES仅针对原M1容量owner前置门尚未满足，不把本地green当作该门已关闭，也不要求未来受控恢复一起交付。

English verdict: REQUEST_CHANGES - The bounded inert-inspection implementation and independent real File/SQLite CLI/wheel/browser validation pass. The accepted RFC requires a maintainer-owned capacity-default freeze before M1 merge, while this exact head explicitly leaves it open; record that decision or retain an unavailable prerequisite boundary. This does not require CI completion or M2/M3 delivery.

[mergify]

This pull request has merge conflicts with main and cannot be merged
until they are resolved. Please rebase or merge the base branch, @songoow.

Choose the remote for the base repository, not an out-of-date fork.
For a fork clone, first inspect git remote -v; upstream must point
to https://github.com/loopx-project/loopx.git. If it is absent, add it
with git remote add upstream https://github.com/loopx-project/loopx.git.
Then run:

git fetch upstream
git rebase upstream/main
# Resolve each conflict, git add the resolved files, then git rebase --continue.
git push --force-with-lease origin HEAD

For a same-repository clone whose origin points to
https://github.com/loopx-project/loopx.git, use origin instead of
upstream for fetch/rebase. If you prefer merging the base, use
git merge <base-remote>/main and push normally.

Keep the DCO Signed-off-by trailer on every commit when you rebase.
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork