Repository navigation
feat(recovery): inspect full backups without activating restored state - #6279
huangruiteng merged 28 commits into
Conversation
Signed-off-by: song <liusongstep@gmail.com>
Signed-off-by: song <liusongstep@gmail.com>
Signed-off-by: song <liusongstep@gmail.com>
Signed-off-by: song <liusongstep@gmail.com>
Signed-off-by: song <liusongstep@gmail.com>
Signed-off-by: song <liusongstep@gmail.com>
songoow
left a comment
songoow
left a comment
There was a problem hiding this comment.
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 行号随之对齐。没有新增后台循环或第二套配置存储。截图使用公开可复现的合成数据。
关键代码讲解
verify_state_backup：先核对外部 digest，再扫描归档与清单。执行路径在私有 staging 中复制，再检查字节未变化、读取 owner、核验报告后发布到新目录。预览不虚构 owner 读取结果。现有目标拒绝覆盖；发布失败即使目标已被占用，仍清理自有 staging、保留外来内容。auditOwners：配置复用verifyConfigurationBackup；Goal 复用openLocalAuthorityStoreHandle与canonicalTodoCollection，扫描全部历史并核对最终 head/revision。SQLite 先拒绝 view/virtual table，再做 integrity/领域读取。服务端 provider 不连接，缺失选定存储不新建或回退。decodeStateRecoveryAudit：owner 和客户端共享状态、计数及依赖校验，禁止 true execution/activation。历史读回另外核对 digest 与备份身份；这证明报告未变，不证明副本后来没有变化。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.
Signed-off-by: song <liusongstep@gmail.com>
Signed-off-by: song <liusongstep@gmail.com>
Signed-off-by: song <liusongstep@gmail.com>
songoow
left a comment
songoow
left a comment
There was a problem hiding this comment.
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 行号随之对齐。没有新增后台循环或第二套配置存储。截图使用公开可复现的合成数据。
关键代码讲解
verify_state_backup：先核对外部 digest，再扫描归档与清单。执行路径在私有 staging 中复制，再检查字节未变化、读取 owner、核验报告后发布到新目录。预览不虚构 owner 读取结果。现有目标拒绝覆盖；发布失败即使目标已被占用，仍清理自有 staging、保留外来内容。auditOwners：配置复用verifyConfigurationBackup；Goal 复用openLocalAuthorityStoreHandle与canonicalTodoCollection，扫描全部历史并核对最终 head/revision。SQLite 先拒绝 view/virtual table，再做 integrity/领域读取。服务端 provider 不连接，缺失选定存储不新建或回退。decodeStateRecoveryAudit：owner 和客户端共享状态、计数及依赖校验，禁止 true execution/activation。历史读回另外核对 digest 与备份身份；这证明报告未变，不证明副本后来没有变化。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.
Signed-off-by: song <liusongstep@gmail.com>
Signed-off-by: song <liusongstep@gmail.com>
…daries Signed-off-by: song <liusongstep@gmail.com>
…sponse Signed-off-by: song <liusongstep@gmail.com>
songoow
left a comment
songoow
left a comment
There was a problem hiding this comment.
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 行号随之对齐。没有新增后台循环或第二套配置存储。截图使用公开可复现的合成数据。
关键代码讲解
verify_state_backup：先核对外部 digest，再扫描归档与清单。执行路径在私有 staging 中复制，再检查字节未变化、读取 owner、核验报告后发布到新目录。预览不虚构 owner 读取结果。现有目标拒绝覆盖；发布失败即使目标已被占用，仍清理自有 staging、保留外来内容。auditOwners：配置复用verifyConfigurationBackup；Goal 复用openLocalAuthorityStoreHandle与canonicalTodoCollection，扫描全部历史并核对最终 head/revision。SQLite 先拒绝 view/virtual table，再做 integrity/领域读取。服务端 provider 不连接，缺失选定存储不新建或回退。decodeStateRecoveryAudit：owner 和客户端共享状态、计数及依赖校验，禁止 true execution/activation。历史读回另外核对 digest 与备份身份；这证明报告未变，不证明副本后来没有变化。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.
|
This pull request has merge conflicts with Choose the remote for the base repository, not an out-of-date fork. 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 HEADFor a same-repository clone whose Keep the DCO |
mergify
Bot
added
the
needs-rebase
Signed-off-by: song <liusongstep@gmail.com>
mergify
Bot
removed
the
needs-rebase
loopx-agent
left a comment
loopx-agent
left a comment
There was a problem hiding this comment.
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.
|
This pull request has merge conflicts with Choose the remote for the base repository, not an out-of-date fork. 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 HEADFor a same-repository clone whose Keep the DCO |
mergify
Bot
added
the
needs-rebase
Preserve inert recovery and current registry witness locations. Signed-off-by: song <liusongstep@gmail.com>
mergify
Bot
removed
the
needs-rebase
|
This pull request has merge conflicts with Choose the remote for the base repository, not an out-of-date fork. 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 HEADFor a same-repository clone whose Keep the DCO |
|
This pull request has merge conflicts with Choose the remote for the base repository, not an out-of-date fork. 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 HEADFor a same-repository clone whose Keep the DCO |
mergify
Bot
added
the
needs-rebase
Both sides registered one cross_runtime vocabulary on the same base (state_recovery_component_state here, delivery_turn_kind in loopx-project#6427), so the registry, smoke anchor and drift-test pins each move one step past either side: 28 vocabularies, 22 unverified cross_runtime, 29 on the add-one probe. Signed-off-by: song <liusongstep@gmail.com>
|
Merged current
中文：合入最新 main 解冲突；双方各登记一个 cross_runtime 词汇导致文本相同的 26→27 被自动合并，实际应为 28，已把 registry、smoke anchor 与 drift 测试的各 pin 再各进一步并通过全部语义检查；M1 容量默认值的 owner 决策仍待定，本次不改变该阻塞。 |
mergify
Bot
removed
the
needs-rebase
loopx-agent
left a comment
loopx-agent
left a comment
There was a problem hiding this comment.
Review exact head: 6279@b36867bada885c837025107c96f40f2c4c0ac5c9
Reviewer: model_agent; model=gpt-6.1-sol; provider=OpenAI; declaration_source=runtime_reported; reasoning_effort=xhigh
动机
原工作目录已不可用、持有完整备份与配套清单的本地用户。完整备份可以创建，但缺少受限离线验证与产品可读审计；直接解压会把旧状态误认为执行许可。当前 M1 实现仍未满足合入前容量默认值冻结。当前 head 的真实 CLI 与打包入口可检查隔离副本、读取原未完成任务和历史，坏输入拒绝且历史仍可读；容量 owner 冻结仍未获得，不能批准 M1 合入。不恢复执行、不接纳 Goal 身份或租约、不重放效果；不证明 M2/M3、其他平台/provider、实机安装、模型或长期 RPO/RTO。剩余当前阻塞是已接受 RFC 的 M1 capacity defaults owner 决定；M3 恢复后继续未完成任务和后续平台资格分别保持开放。
改动思路
复用既有配置、File/SQLite、Todo/history 和摘要 owner，TS 决定语义，Python 仅受限归档 IO 与隔离 worker；不应建立恢复权威或让原始解压决定可执行。本 PR 的可独立交付边界是完整备份的可读 inert inspection，而合入仍受既有 M1 冻结条件约束；不用 M2/M3 全部完成作前置。
依据为不可变 accepted RFC。本次分别核对 Archive and manifest bind exactly、Extraction is confined、M1 stays inert、M1 audit is understandable in product、SQLite and configuration remain valid、v0 uncertainty is honest，当前本地源码范围有证据；M1 capacity defaults 仍不满足。M3 restores one Goal end to end 是后续独立验收，当前只读结果不替代它。
具体改动
完整 32 路径 +2264/-35：12 个 runtime/CLI/HTTP/typed 文件、4 个前端文件、9 份公开文档/图片、6 个测试/示例和 1 份语义 registry。verify_state_backup:342 在摘要、清单、路径、链接、容量预检后复制到私有 staging；auditStateRecoveryOwners:275 在一次性 worker 通过既有配置、File/SQLite、Todo/history owner 检查；decodeStateRecoveryAudit:57 与客户端共用，StateRecoveryRequestMixin:24 负责 loopback upload/list/read。未知、仅历史和可读均不赋执行权；20,000 历史完整读取，20,001 拒绝发布，失败保留旧审计并清理 staging。
相对前次 1695 精确头，当前 32 路径中 22 个 blob 相同；其余是 main 的 route/transport/fixture 与语义词汇合并适配，已独立重验消费者和当前实际入口。重点核对双方新词汇合并后真实应为 28：cross_runtime 未覆盖 22、owner_symbols 53 不变；当前 126 项语义 drift 测试通过。没有把语义计数绿当作业务验收。类型别名和 canonical digest/history 复用是合适的相关重构，不需另造恢复权威。
对主干的风险
当前 190 项 Python 通过，含 35 项真实恢复、backup/configuration 与 126 项语义检查。TS 组为 34 过、1 失败：消费者名单漏 direction_authority 的同一断言，在未改 base 上单独跑是 16 过、1 失败；该生产消费者 blob 完全相同，当前新增 recovery consumer 已正确登记。这是已有 #6431 独立修复的主干失败，保留归因，不宣称全绿。typecheck、打包构建、advisory 后 full semantic、canary 5 direct/19 selected 通过，无 hold/skip；这些绿灯不能撤销下面的 owner 门禁。没有查询或等待 CI。
实际当前打包旅程走设置→能力中心→设备备份→完整归档检查；原 project/runtime/registry 隐藏后，经真实 HTTP/Python/TS/SQLite 读取一个未完成任务和一条历史，未注册恢复 Goal。键盘从配套清单 Tab 到验证按钮、Enter 完成；改坏清单撤回成功且拒绝，原历史结果可重新打开并明确尚未重验，原测量保留。窄屏与截图单独核对，发现用 synthetic discovery，其余恢复 backend 为真实源码；源打包不等于安装 App。原默认 backup plan/create/occupied-retry 在同 Python 的 base/head 均 0/0/1，完整计划和重试诊断只归一临时根/时钟后相等，实际 gzip 大小、比例和摘要没有伪称逐字相同。
[P2] M1 合入前容量默认值冻结仍待原 owner。 本头 RFC:683–709 和作者最新说明均明确：128 MiB 归档、512 MiB 展开、20,000 成员/历史、128 Goals/SQLite、90 秒 worker 等仍是待决定的原值提案。已接受的 §11 M1 entry 与 §12.1 要求 backup/reliability maintainer 在 M1 merge 前冻结。当前没有该决定；文档测量是单独的历史合成观察，未覆盖上限组合或生产 SLO。不能把一次成功、保持原值、同步 main 或测试通过当成 owner 决定。
我的整体评价
REQUEST_CHANGES，仅保留上述具体 P2。只读检查及普通失败/历史恢复有独立价值；最小下一步是原 backup/reliability owner 针对本地 POSIX File/SQLite inert profile，记录明确值、测量/取舍及审阅 revision 的冻结决定，或将未获准路径保持为不可交付 prerequisite。无需先实现全部 M2/M3，不新增审批流程。M3、其他平台/provider 和长期净收益继续开放；本评审不授予激活、合并或升级能力。
English verdict: REQUEST_CHANGES - b36867b; the existing M1 capacity-default owner freeze remains pending before merge. Current inert CLI/product readback and failure recovery are useful:190 Python pass,34 TS pass with one identical baseline digest-pin failure retained,5+19 risk checks pass. This does not grant the missing scoped owner decision or qualify M3 activation.
Use the existing workspace backend forwarder for state-recovery routes so same-origin archive uploads reach the disposable real server. Assert the upload HTTP status before waiting for the success view, making rejected requests fail directly. Reproduced the packaged scenario timeout on the parent, then HTTP 403 with the added assertion. Verified the complete scenario with SQLite, file authority, and an isolated installed wheel; origin guards and focused recovery/history controls pass. No production origin policy or capacity defaults change. Signed-off-by: song <liusongstep@gmail.com>
loopx-agent
left a comment
loopx-agent
left a comment
There was a problem hiding this comment.
Review exact head: 6279@5751b050f616f156fa591aac5aa82627d8396fe0
Reviewer: model_agent; model=gpt-6.1-sol; provider=OpenAI; declaration_source=runtime_reported; reasoning_effort=xhigh
动机
原工作目录不可用、持有完整备份与配套清单的本地用户，需要检查未完成任务和历史，而不是把旧状态直接作为执行许可。本 PR 提供有界的私有隔离副本及可读审计，仍未满足已接受 RFC 的 M1 合入前容量默认值冻结。当前修正了浏览器测试转发被服务端拒绝的问题；它没有取得容量 owner 的决定，也没有实现 M3 恢复执行。
用户从设置选择完整归档与清单，可在原目录不可用时读取隔离副本中的未完成任务和历史。当前真实打包旅程完成键盘上传、失败后历史读取和重载，原测量保持，恢复 Goal 未注册。M1 容量默认值的原 owner 冻结仍待完成。
改动思路
依据已接受的完整恢复 RFC，分别检查归档/清单绑定、受限提取、M1 inert、产品可读审计、SQLite/配置有效性及旧格式未知状态。既有 backup、配置、Todo/history 和摘要 owner 保持权威，TS 判定审计语义，Python 仅处理受限归档 IO 和一次性 worker。普通解压不能解决这些边界，也不应另建恢复权威。
逐项映射：Archive and manifest bind exactly、Extraction is confined、M1 stays inert、M1 audit is understandable in product、SQLite and configuration remain valid、v0 uncertainty is honest，在本地检查 profile 有证据；M3 restores one Goal end to end 仍为后续开放验收。
最小可独立检查的切片是 inert inspection；M1 capacity defaults 仍是该切片自身的合入条件，不要求先完成所有 M2/M3。真实 Goal 采用、Host、会话、租约与 effect 重放均不由检查报告授权。
具体改动
全 PR 为 32 路径、+2268/-35，覆盖 runtime/CLI/HTTP/typed、前端、公开文档/图片、语义登记及验证。verify_state_backup:342 在摘要、清单、路径、链接和容量检查后建立私有 staging；auditStateRecoveryOwners:275 通过原配置、File/SQLite、Todo/history reader 检查；decodeStateRecoveryAudit:57 供后端与客户端共用；StateRecoveryRequestMixin:24 提供 loopback upload/list/read。20,000 条历史完整读取、20,001 条拒绝发布；未知和仅历史状态不授执行权。
相对前次评审 b36867b，base 仍为 3593cf17，32 个路径中 31 个 head blob 完全相同；唯一变化是 configuration-backup.mjs 采用既有 fetchWorkspaceBackend，并在等待成功视图前断言上传响应。已核对全 PR 失效矩阵，复用仍有效的归档/default-off 证据，并重新运行当前 Python/typed/build 和真实打包旅程。相关前向重构合适：删除重复转发知识，复用原 helper；无需新增抽象或改服务端 origin 策略。
对主干的风险
当前 190 项 Python 通过；本次运行的两个 TS 模块为 21 过、1 失败，其中恢复模块 5 过，摘要 owner 模块 16 过、1 失败。失败仍是消费者名单漏 direction_authority，与固定 base 的同一失败一致；相关生产 owner/consumer blob 未变，新增 recovery consumer 已登记。保留 #6431 的既有主干失败，不宣称全绿。typecheck、打包及源码校验、Ruff、先 advisory 后 full semantic、canary 5 direct +19 selected 均通过，零 skip/hold；未查询 CI。
真实后端反例：父版本的原始转发把浏览器 Host/Origin 带往不同端口，返回 403；当前共享 helper 的同源上传返回 200，外来 Origin 仍返回 403。产品验证使用真实备份与配套清单；上传接收不等于审计验证成功。
当前打包页由设置→能力中心→完整归档检查进入，Tab/Enter 上传并验证；真实 SQLite 后端读回一个原未完成任务和一条历史，报告为 2 可读、1 仅历史、1 未知，未注册恢复 Goal。损坏归档拒绝并清除旧成功视图，历史仍可打开；重载后重新读取历史，原字节/耗时测量不变且明确“尚未重新验证副本”。390px 页面无横向溢出。周围 discovery 使用合成 fixture，恢复 HTTP/读者为真实代码；没有把源码打包当作已安装 App 或长期 RPO/RTO。
[P2] M1 合入前容量默认值冻结仍待原 owner。 已接受 RFC §11 M1 entry、§12.1 要求 backup/reliability maintainers 在 M1 merge 前冻结；当前 RFC:705–709 和 PR 正文仍明确 pending/not_met。128 MiB 归档、512 MiB 展开、20,000 成员/历史、128 Goals/SQLite、90 秒 worker 等是待决定提案。保持原值、修复测试转发或一次成功均不代替该决定；组合最大负载、生产 SLO、其他平台/provider 仍未资格。
我的整体评价
REQUEST_CHANGES，仅保留上述 M1 owner 冻结条件。 浏览器转发修复有效，完整只读检查具有独立价值。最小下一步仍是原 backup/reliability owner 针对本地 POSIX File/SQLite inert profile 记录明确值、取舍、测量边界及审阅 revision，或保持未获准实现为 prerequisite。无需先实现全部 M2/M3，不增加新的审批流程。该评审不授予激活、合并或升级权限。
English verdict: REQUEST_CHANGES - 5751b05. The real origin-forwarding regression is fixed and foreign origins remain refused;190 Python tests pass,21 TS tests pass with the identical baseline digest-pin failure retained, and5+19 risk checks pass. The accepted M1 capacity-default owner freeze is explicitly still pending before merge; M3 activation and broader operating qualification remain open. CI was not consulted.
|
@huangruiteng 本 PR 只剩一个阻塞项，而且是需要你记录的一个决定，不是代码问题。请看这一条即可。 需要决定的事：已接受的 RFC 只需在本 PR 的 review 里写一句话，例如：
或者指出某个具体值需要更多证据。决定一旦记录，我会在同一 PR 把 RFC 该节从 pending 改为决定记录（Appendix B 决策日志加一行，引用你的 review），其它内容不动。 这个决定不意味着什么：不启用任何 Goal、不恢复 lease、不重放 effect；不批准多上限组合的最坏负载、生产 SLO、Windows、PostgreSQL 或 M2/M3。只是让 M1 惰性检查能按已接受 RFC 的门合入。 其它状态：loopx-agent 在精确头 English: the only remaining blocker is the RFC §12.1 owner decision on the unchanged M1 capacity defaults for the local POSIX File/SQLite inert-inspection profile. One sentence in a review on head |
…6279-ci-repair-20261015 Signed-off-by: song <liusongstep@gmail.com>
Signed-off-by: song <liusongstep@gmail.com>
loopx-agent
left a comment
loopx-agent
left a comment
There was a problem hiding this comment.
Reviewer: model_agent; model=gpt-6.1-sol; provider=OpenAI; declaration_source=runtime_reported; reasoning_effort=xhigh
Reviewed exact head: 6279@7f62b602019429c05a03254ab2f30a3fafa32c6e.
动机
原工作目录不可用、手中持有完整备份与清单的用户，需要安全读取未完成任务和历史。直接解压不能证明状态可执行；本 PR 在原设置和 CLI 入口建立私有隔离副本，报告可读、仅历史与未知资产，并保持执行许可为 false。这个只读增量有独立价值，但已接受 RFC 的 M1 容量默认值决定仍未满足，M3 继续任务也未实现。
本次新头还修复测试复用无关旧 runtime 的问题，使调用方选择的 Node 确实用于该测试，并只清理测试自己启动的进程。当前实际验证支持这一修复；它不取得容量 owner 的决定，不认证安装 App、其他平台、恢复时限或长期收益。
改动思路
TS owner 绑定外部/归档内清单、实测成员与 canonical 配置/File/SQLite/Todo/history reader；Python 负责受限 tar IO、私有 staging 和一次性离线 worker。原 authority、Goal、摘要和历史 owner 没有被第二个“恢复全部”权威替代，未知或仅历史数据不能授执行许可。失败不发布新成功结果，旧审计保留记录时的测量。
当前边界仍是 inert inspection：用户可以读恢复证据，不能由报告激活 Goal、恢复租约或重放效果。保留归档 IO、typed 决策与原设置投影的分工是合理的；M1 本身的容量决定仍是已有合入条件，不要求先完成所有 M2/M3。相关前向重构已应用于测试：将 backup 原有的私有 runtime fixture 提到 conftest，只给两个明确声明的模块使用，避免复制或自动影响所有测试。
具体改动
关键代码讲解
完整 PR 相对实际基线 a59aed703374040240f23b2e51ddaf209fcbacc4 为 34 路径 +2286/-46，包含 runtime/CLI/HTTP/typed、四个前端文件、文档与合成图片、语义登记及聚焦验证。不是只审最后三个测试文件。
verify_state_backup（loopx/state_recovery.py:342）先校验清单/摘要和受限成员，再在新 staging 提取、复查并离线审计，失败清理，不改活动 registry。128 MiB/512 MiB 等上限保持原值，保持原值并不构成 owner 冻结。auditStateRecoveryOwners（loopx/control_plane/state_recovery.ts:275）与decodeStateRecoveryAudit调用现有 canonical reader、统一验证保存报告。20,000 条已提交历史完整读取，20,001 拒绝发布；不能用展示页数冒充完整历史。StateRecoveryRequestMixin和现有StateRecoverySettings提供 loopback 上传/验证/历史读取；历史审计不冒充重新验证。普通配置备份默认路径保持，不加载归档里的程序或凭据。isolated_effect_runtime（tests/conftest.py:41）同时隔离 Pythontempfile.tempdir与子进程 TMPDIR；两个测试模块用 usefixtures 明确请求它。teardown 在 monkeypatch 恢复前停止同一私有 namespace，原测试断言未删除。
与前次已审 5751b050f616f156fa591aac5aa82627d8396fe0 比较，34 个 PR 路径中 28 个 blob 完全相同；变动为三个测试 fixture 文件、主干 runtime retirement、digest consumer pin 和语义 producer 登记。完整增量与消费者/依赖均已检查：恢复产品/UI/浏览器 forwarder、构建 launcher、锁文件和 Vite 配置未改；package 仅多了无关 task-inspector smoke 命令。旧结论不继承。
规范为 docs/architecture/rfcs/complete-state-recovery-v0.md，spec_revision a59aed7。criterion_id Archive and manifest bind exactly、Extraction is confined、M1 stays inert、M1 audit is understandable in product、SQLite and configuration remain valid、v0 uncertainty is honest：在已限定本地 inspection profile 内 implemented；M1 capacity defaults：not_met；M3 restores one Goal end to end：deferred，仍归原后续验收。
对主干的风险
当前 64 Python、22 TS 全通过，0 skip，控制面 typecheck 和正确 dashboard 入口的 Chat bundle 构建/校验通过。Python 覆盖真实 File/SQLite、源不可用、完整历史/overflow、恶意归档、worker 失败和清理。独立 runtime 反例先在自己的另一 namespace 启动真实 server：无 fixture 复用原 PID，隔离后使用不同 PID；teardown 删除新 locator，同时原进程仍存活、原 locator 逐字相同。两者均是一次性测试状态，没有停止共享用户 runtime。当前服务实际为 Node24.21.0/SQLite3.53.4，不能继承作者 Node22 的平台资格。
旧打包浏览器的上传、键盘、坏输入后历史读取、重载测量不变和 390px 布局证据明确属于 5751b050f。当前仅对上述未变源码/消费者范围复用，重新跑了 source tests、typed/backend、typecheck 和 bundle；本轮没有重跑浏览器、wheel 或实机安装。此前 root/apps/presentation 的错误 build 命令未执行构建，已保留并在实际 dashboard 目录纠正，不计作产品失败或通过。原 digest-pin 失败也保留为历史，当前22项中对应断言已真实通过。
[P2] M1 容量默认值仍待原 owner 决定。 当前 RFC §11 M1 entry 要求 frozen limits，§12.1 与 Pending M1 capacity-default decision（第705行起）仍明确 pending；最新作者 comment6184625572 也请求该决定。没有维护者决定记录。最小修复是原 backup/reliability maintainer 针对本地 POSIX File/SQLite inert profile 记录明确值、证据边界、取舍及审阅 revision，或保留未获准路径为 prerequisite；不通过新 fixture、保持上限或绿灯替代决定。
语义与 CI 对齐
readable/historical_only/unknown 扩展已登记 recovery vocabulary，两个 large-snapshot 方法属于既有本地 transport 的精确允许集，不是通用扩权。当前 advisory 的两个候选已按此 owner 核对；风险 canary 为 5 direct + 19 selected 全通过，零失败、advisory failure 与 hold。旧默认 Node cache ENOTEMPTY 保留，本次显式关闭可选缓存，不称默认稳定；未查询或等待 CI。组合最大负载、Windows/ACL、服务 PostgreSQL、M2/M3、安装和长期 RPO/RTO 均未资格。
我的整体评价
REQUEST_CHANGES，仅保留上述 M1 已有合入条件。 新测试隔离有实际判别证据，当前只读代码和既有产品旅程仍有价值。long_horizon=improved 限于安全检查与历史可读；user_experience=improved 限于原设置入口读取恢复证据，不把更多测试或配置机制当作完成恢复任务。它没有激活身份或效果，也未扩大该能力的权限名称。
本头不需要新增框架；复用原 fixture、canonical reader 与统一解码是合适的相关收敛。原容量 owner 决定、M3 旅程和其他平台保持独立，不增设无关审批。既有 CHANGES_REQUESTED 不因旧提交或测试数量自动失效；本评审不授予合并、升级或激活权限。
English verdict: REQUEST_CHANGES - 7f62b60. The real runtime-isolation counterexample and64 Python/22 TS tests pass; current typecheck and Chat build pass. Prior packaged-browser evidence is reused only for unchanged source, not relabeled as a new run. The accepted M1 capacity-default owner decision is still explicitly pending before merge; M3 activation and broader qualification remain open.
|
1.同意容量 |
loopx-agent
left a comment
loopx-agent
left a comment
There was a problem hiding this comment.
Reviewer: model_agent; model=GPT-6; provider=OpenAI; declaration_source=self_reported
REQUEST_CHANGES — 请补齐与已合入 #6486 的复用及阶段衔接设计，保留本 PR 的 M1 只读检查边界。
Reviewed head: 6279@7f62b602019429c05a03254ab2f30a3fafa32c6e；base: a59aed703374040240f23b2e51ddaf209fcbacc4。
动机
原工作环境不可用、手中持有完整备份的用户，需要找回未完成任务与历史，并清楚知道接下来能否继续工作。原来只能手动解包；本 PR 提供隔离副本、可读性检查和产品入口，是有独立价值的阶段。继续执行仍是后续结果，不能把“文件和数据库可读”显示成“任务已恢复运行”。
维护者已在最新公开决定中同意容量，并要求思考与近期 checkpoint 能力的互补复用。请引用并回填这条决定，不再重复请求容量确认；其范围仍限原本的 M1 profile。本次补充要求是把两条恢复路径放回同一产品和架构设计中，说明当前复用、合理分工及后续衔接，而非强求本 PR 完成全部灾难恢复。
改动思路
建议保留两个清晰用途：backup-state verify 负责完整归档的安全提取和历史资产检查；research-checkpoint 负责有明确捕获边界的研究分支及上下文接续。共享已有捕获、校验和领域 owner，不建立第二个“恢复全部”的权威。
这已有代码基础，并非要求从头造统一框架。#6486 的 _loopx_state_components已经调用 build_state_backup_plan；checkpoint artifact owner复用现有 SQLite snapshot owner。归档解码、安全链接处理与普通目录捕获具有不同输入风险，不能仅因代码形似就强行合并；真正相同的业务规则才应收敛到一个 owner。
本 PR 当前应完成复用审视、必要的有界收敛及关系说明。跨格式接续和完整恢复若超过 M1 边界，明确留在原 M2/M3 计划与现有 owner 下，避免另建并行恢复路线。
具体改动
关键代码讲解
全 PR 相对上述 base 为 34 个路径、+2286/-46，涵盖归档 IO、typed owner/transport、CLI/HTTP、四个前端文件、文档/图片和验证。verify_state_backup（loopx/state_recovery.py:342）绑定归档与清单、预检、隔离提取、再次核对并发布审计；auditStateRecoveryOwners（loopx/control_plane/state_recovery.ts:275）通过既有配置和 canonical File/SQLite/Todo/history reader 分类；decodeStateRecoveryAudit（state_recovery_contract.ts:57）供服务端和客户端共享，并拒绝激活标志矛盾。StateRecoverySettings 提供上传、历史读取及失败后的结果查找。测试 fixture 的隔离、语义词汇登记和双语 RFC 更新也属于当前完整变更范围。
规范依据是 complete-state-recovery-v0.md，spec_revision a59aed703374040240f23b2e51ddaf209fcbacc4。其中 Archive and manifest bind exactly、Extraction is confined、M1 stays inert、M1 audit is understandable in product、SQLite and configuration remain valid、v0 uncertainty is honest 对应现有检查路径；本轮不把源码对应关系计作新的执行通过。M1 capacity defaults 已出现上述维护者决定，需要回填；M3 restores one Goal end to end 仍为后续验收。
本轮请求修改：
- 给出具体复用结论。 在本 PR 的设计说明中对照状态清单、SQLite 快照、组件/文件摘要、隔离发布、历史读回、会话及 Todo 上下文采用，写清当前 owner、已复用部分和必要分工。若发现当前调用路径上的重复规则，做有界收敛并保留行为验证；若没有，明确理由。不要求为抽象而增加新框架、统一格式或做无关语言迁移。
- 补齐衔接契约和阶段归属。 两种现有格式并不互换。只对有完整组件、版本、捕获边界及相应 provider 资格的输入，设计“隔离核验 → 当前 Goal/会话准入 → 知识采用 → 当前工作准入”的衔接。旧 v0 清单缺少的信息继续为 unknown，不能推断或补造一致性。同步本 PR 涉及的双语 RFC/指南和既有 M2/M3 检查点，吸收已合入 RFC 对 checkpoint 的区分。
- 把用户结果和验证写清。 M1 如实展示找回了哪些工作、哪些只是历史、哪些未知以及下一步；不要让用户理解协议后自行拼接恢复流程。后续联合验收以一个已完成部分工作、仍有未完成任务的普通 Goal 为例，在原来源不可用后，经受控恢复完成原未完成任务，并保留独立结果检查。该联合恢复验收属于后续阶段，不新增为 M1 的全量前置门槛。
对主干的风险
必须保留两种语义的差异：新 Goal 的研究分支可以让源 Goal 继续存在；灾难替换需要证明旧写方被排除，并由原生命周期、authority、session 和 effect owner 逐一准入。最近的 checkpoint 不自动解决后者。旧租约、额度、定时器、凭据、pending effect 和待投递消息不因文件恢复而生效；不确定的外部操作必须沿原身份读回对账，不能以新操作盲目重发。私有会话、凭据及本地路径也不能进入公开恢复报告。
如调整共享代码，验证应覆盖原备份创建/预览的未启用路径、旧 v0 历史读取、损坏或缺失组件、权限/身份拒绝、源捕获期间移动、同一操作重试、部分恢复中断，以及不复活旧权限和不泄露私有数据。现有测试覆盖了多类路径/权限/归档负例、完整历史容量边界、真实 HTTP 和产品历史读回；源码中的这些断言不能代替执行或证明两种格式已经联合恢复。
本轮是对新增架构方向的源码专项复核，没有重跑完整 Python/TS、打包浏览器或安装态验收，不继承旧评审的通过结论。当前远端检查仍有失败和未结束项，其归因在本轮未验证；不据此宣称本 PR 引入了那些失败，也不作合入就绪判断。没有复现新的运行时权限漏洞。
我的整体评价
REQUEST_CHANGES：先回应维护者已明确提出的 checkpoint 互补复用要求，交付具体的 owner/复用结论、必要的当前代码收敛和清晰阶段衔接，并回填已同意的容量决定。完整只读检查应保留独立价值；不要求本 PR 一次完成 M2/M3，也不把默认关闭的研究接续自动开启。
long_horizon 与 user_experience 的完整执行收益在本轮均为 not_yet_proven：源码支持 M1 的可读检查增量，但跨入口接续、真实采用及最终完成任务仍需其所在阶段的执行证据。这里请求的是上述有界修改和明确的后续验收，不能以“有一个备份包”或“新命令能运行”代替。保留现有格式兼容和 owner 分工；只有真实重复值得在本 PR 收敛。此次评审不授予激活、合并、升级或部署权限。
English verdict: REQUEST_CHANGES - 7f62b60. Address the maintainer-requested reuse and boundary assessment with merged #6486: identify existing shared owners, consolidate only proven duplicate rules, and document the qualified bridge and its staged acceptance. Preserve independently useful inert M1 inspection; full M2/M3 recovery is not a new M1 prerequisite. Capacity consent is already recorded and should be reflected, not requested again. This is a source-based supplementary assessment, not a fresh runtime, packaged-UI or merge-readiness certification.
Signed-off-by: song <liusongstep@gmail.com>
Signed-off-by: song <liusongstep@gmail.com>
Signed-off-by: song <liusongstep@gmail.com>
|
Follow-up implemented at
This is an implementation and validation response, not a new approval. The new head still needs independent review, hosted checks and separate maintainer merge authorization. No installed-app/wheel or joint M2/M3 recovery qualification was rerun. The PR description now reflects the current boundary and preserves the failed attempts and untested cases. |
|
This pull request has merge conflicts with Choose the remote for the base repository, not an out-of-date fork. 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 HEADFor a same-repository clone whose Keep the DCO |
mergify
Bot
added
the
needs-rebase
songoow
left a comment
songoow
left a comment
There was a problem hiding this comment.
Reviewer: model_agent; model=gpt-6-astra; provider=OpenAI; declaration_source=runtime_reported; reasoning_effort=xhigh
Approval conclusion (author-owned PR; GitHub blocks formal self-approval)
Reviewed exact head: 6279@aad964cd390307c3639f204342a54ecf504609c9.
Base/accepted specification revision: 21d6649fd3e19358c188d1540077caa747084abc.
动机
持有完整备份、原工作目录已不可用的操作者需要找回任务和历史证据。原来只能手工解包并自行判断文件是否可信；现在在原设置入口选择归档与清单，一次操作得到私有隔离副本和可读、仅历史、未知的分类。
已验证原来源不可用后仍能检查真实 File/SQLite 任务与完整历史，并在坏输入之后重新读取先前报告；报告不会启动 Goal。本次不交付继续执行、跨格式转换、Windows/PostgreSQL 恢复、生产 RTO 或跨 owner 一致性资格。M2 仍需补齐组件版本与捕获边界；M3 仍需原生命周期、会话、Todo 和 effect owner 准入并完成未完任务的独立验收。
这是已接受 RFC 中独立有用的 M1 增量。完整备份的存在、一次读取成功或绿色检查都不能代替“原任务已经恢复执行”。长期价值在本阶段表现为完整保留历史、拒绝截断以及可重复读取原观察，为后续恢复保留可靠输入；不据此认定 M2/M3 的持续执行收益已经证实。
改动思路
归档 IO、typed 可读性判断和现有设置投影分别有真实调用；研究 checkpoint 已共享清单、SQLite snapshot 和摘要规则，独立提取逻辑保护不同输入边界。
保留独立有用的 M1 惰性检查，原 M2/M3 承接资格及恢复执行，不加入统一恢复服务或推测性的格式转换器。
我比较了“不做、继续人工解包”“只扩展配置快照”“直接套用研究 checkpoint 目录捕获”和现方案：前两者缺少完整归档及 Goal 历史核验，目录捕获没有 tar 的路径、扩展 header、链接及解压风险边界。现方案的新增成本有实际调用支撑，未发现必须在本 PR 删除的重复决策 owner。
与已合入 #6486 的关系已落实到双语 RFC 的具体矩阵：_loopx_state_components 调用 build_state_backup_plan，两种创建路径共用 SQLite snapshot owner，结构摘要共用 canonicalAuthoritySha256；Todo/Explore/native session 的采用继续归原 owner。研究分支允许来源继续存在，灾难替换需要排除旧 writer；两种格式当前不互换。新版文档没有用“复用”掩盖尚未实现的桥接。
具体改动
关键代码讲解
完整 PR 相对上述基线为 35 个路径、+2400/-60，本评审覆盖整个差异：归档 adapter、typed owner/worker/transport、CLI/HTTP、四个前端文件、双语规范/指南/路线图、三张合成图片、语义登记以及 Python/TS/browser 验证。未只审最后一条 smoke 修改。
verify_state_backup（loopx/state_recovery.py:342）先检查私有输入、真实 archive digest、内外清单与成员，再预扫描、隔离提取、重新核对输入、调用一次性 worker 并发布新 audit。已有目标拒绝覆盖，失败清理本次 staging。Python 的职责是 tar/filesystem IO，没有复制生命周期准入规则。auditStateRecoveryOwners（loopx/control_plane/state_recovery.ts:275）组合配置与既有 canonical File/SQLite/Todo/history reader。existingOnly禁止补建或回退；历史必须完整，20,000/20,001 边界分别为完整读取/拒绝发布；未知 provider 和缺失 owner 仍为 unknown。SQLite 检查不进入共享 daemon，恢复文件不会作为插件加载。verifySavedStateRecoveryAudit（同文件第 280 行）与decodeStateRecoveryAudit验证摘要、身份、组件、汇总和 false 权限标志。旧报告没有 measurements 时保留缺失，重载不重新计时；这是历史观察回读，不是对副本再次验真。_state_recovery_verify（loopx/presentation/state_recovery_api.py:111）把不透明 upload refs 映射到私有新目录。浏览器不能传任意目标路径，原 loopback/origin 边界仍在。StateRecoverySettings用共享 decoder 展示可读/历史/未知、错误及后续 owner 动作；原配置快照仍是默认入口。- 测试 fixture 只由 backup/recovery 两个模块明确请求，隔离并清理其自身 runtime。M2 browser smoke 的新增断言验证关闭详情清空路由、Back 恢复刚关闭任务及列表选择；生产导航行为未改。类型层将
JsonObject移到无业务依赖的runtime_decode并保留原 re-export，避免客户端拉入控制面实现。
最后一次旧头评审针对 7f62b6020 提出的两个事项现已回应：维护者容量同意已写入两种语言的决定记录，仍只批准原 profile；checkpoint 复用、输入差异和 M2/M3 归属已具体化。上游集成带来的新消费者已重新核对。此判断不继承旧评审的通过结论。
规范映射依据 docs/architecture/rfcs/complete-state-recovery-v0.md，spec_revision 21d6649fd3e19358c188d1540077caa747084abc。先读 accepted base 再检查改动，未以修改后的规范反向定义通过条件：
| criterion_id | 本头判断与证据 |
|---|---|
| Archive and manifest bind exactly | implemented：真实 CLI/HTTP 拒绝 archive、manifest、member witness 不一致，错误先于发布 |
| Extraction is confined | implemented：路径/链接/重名/特殊文件/PAX/sparse、私有权限和目标占用负例覆盖；旧报告保留 |
| M1 stays inert | implemented：来源移除后真实 File/SQLite 检查，无恢复 Goal 注册；执行标志 false，worker 与共享 runtime 分离 |
| M1 audit is understandable in product | implemented：打包设置、桌面/390px、键盘提交、损坏输入、历史重载与中英文读回；周边 workspace 数据为合成 fixture，备份 HTTP/backend 为真实 |
| SQLite and configuration remain valid | implemented within inspection profile：既有配置验证、SQLite integrity/schema 检查和 canonical reader；不把损坏/缺失来源标成 readable，也不承诺恢复运行 |
| v0 uncertainty is honest | implemented：缺失 witness 不伪造验证，remaining owner 和 capture 不完整继续 held/unknown |
| Privacy boundary holds | implemented within local profile：私有文件、opaque refs、错误不返回内部路径；报告只呈现受限事实；归档未获跨机隐私认证 |
| M1 capacity defaults | implemented：上述维护者同意及不变值的双语记录；不批准组合最坏负载、生产 SLO 或 M2/M3 |
| M3 restores one Goal end to end | deferred：原 §11 M2/M3 与生命周期/会话/Todo/effect owner，当前没有格式桥接或重新执行资格 |
对主干的风险
最大的风险是“摘要正确、文件可读”被误当作恢复权限，或检查过程触碰活动状态。当前 adapter、一次性 worker、existing-only reader、false 权限 decoder 与前端文案保持该边界。额外反例把一个真实备份中的 selector 改成合法 PostgreSQL 选择：实际得到 offline_provider_unsupported，没有选择可读的旧本地库来掩盖不支持。另一反例同时重排内外清单 witness：组件事实和汇总不变，新的字节身份不同，原报告仍能逐值读回。两者均经真实归档发布路径，无伪造 audit 结果。
本轮执行和当前会话可复用证据：
- 当前精确头的 backup/recovery + research-checkpoint capture/CLI 合并验证：100 passed、12 skipped。其中 M1 backup/recovery 的 52 项全部通过；12 个 skip 要求显式真实 native Host，属于未改动 checkpoint 的诊断资格，不能算本次联合恢复通过。没有发起真实模型或外部服务恢复。
- immutable base 的 backup/configuration 同一组旧契约：29 passed；head 的配置 suite 12 passed，backup 的 17 项包含在上述 100 项中。对照覆盖实际创建、配置导出/验证/隔离恢复、占用目标、损坏输入和独立读回；未使用新功能的默认行为保持。
- 五组 TypeScript suite（recovery、configuration backup、checkpoint artifacts、digest owner、runtime handlers）：53 passed、0 skipped；额外两项真实归档反例 2 passed。
- 同一会话此前在
9f0657a9f执行的语义漂移 126 passed、typecheck、Chat bundle 构建/验证、docs governance 和 configuration-backup/goal-work-map 两个 packaged 场景通过。已核对至本头只新增 M2 smoke 断言，相关生产源码、依赖及构建输入未变；M2 packaged 场景在本头对应源码通过。桌面和手机结果截图已实际查看，层级、历史时刻、未激活状态和下一步同时可见。 - 旧头三个工作地图相关 hosted 失败由已集成主干修复；M2 的旧后退断言在本会话先复现再修正。此前 Node25/未资格化 SQLite 的 8 failed / 44 passed 保留为失败尝试，由已识别的 runtime 资格错误及 Node24.21.0 完整重跑覆盖。最初的额外 provider probe 错用没有 selector 的 legacy File fixture，在准备阶段失败；改用实际带 selector 的 SQLite fixture 后，两项 probe 通过。
- 语义 advisory 的两项是已登记 recovery vocabulary 与两个现有私有 snapshot 方法的允许项。状态分类为共享 typed contract，不用 substring 推断。硬容量没有提高；普通 transport 未放宽。
next_action是操作建议，权限和容量拒绝是机器强制，未改变通用调度、额度或工作义务。
远端当前头 CI 尚有排队/运行中的任务；本次没有把它们当作通过，也没有仅因 pending 请求修改。远端全量检查、合并条件和旧 blocking review 的协调仍单独处理。未重新做安装 App/wheel、生产跨平台、真实 PostgreSQL 或 M2/M3 联合恢复验收；历史安装证据不升级为本头的新实测。
我的整体评价
APPROVE，范围限当前 M1 惰性检查增量。 没有发现需要阻塞本头的缺陷。容量 owner 决定和 checkpoint 互补复用要求已得到可检查的回应；不需要为了“统一”再造第二个恢复权威。前向重构审视保留已有清单/snapshot/digest/reader owner，复用测试隔离 fixture，并将类型依赖缩到合适位置；未发现需要随本 PR 扩大的重构。
这是作者账号下发布的完整自评审，采用 GitHub COMMENTED 记录批准结论；不冒充其他维护者的独立批准，也不授予合并权限。旧 REQUEST_CHANGES 是否可撤销必须逐项核对并由有权方处理；新头 CI、maintainer merge authorization 和未来阶段仍保持独立门槛。
English verdict: APPROVE - aad964c. The bounded inert M1 inspection is useful, reuses existing semantic owners, preserves default behavior, and addresses the maintainer's capacity consent and checkpoint relationship. Current runtime validation: 100 passed / 12 explicitly unqualified native-Host skips; baseline parity 29 passed; head configuration 12 passed; TypeScript 53 passed; two independent real-archive counterfactuals passed. Packaged UI evidence was checked for unchanged-source validity and the new M2 assertion passed. No new blocker found. Hosted CI, existing review reconciliation, maintainer merge authority and M2/M3 qualification remain separate.
|
Frame-aligned review closeout for 完整评审与验证结论已发布，并对远端读回正文重新执行
|
Signed-off-by: song <liusongstep@gmail.com>
|
Resolved the latest main conflict in
The PR body now reflects this integration head. Prior-head review does not certify this new head; hosted CI and exact-head review remain separate. No merge or deployment performed. |
mergify
Bot
removed
the
needs-rebase
songoow
left a comment
songoow
left a comment
There was a problem hiding this comment.
Reviewer: model_agent; model=gpt-6-astra; provider=OpenAI; declaration_source=runtime_reported; reasoning_effort=xhigh
Approval conclusion (author-owned PR; GitHub blocks formal self-approval)
Reviewed exact head: 6279@c0a11e13986d18367c280eeba6aac983e0fae990; base: 544e9de7a7d0691e5a96fa359e9b87c5722598d4. 按当前 capability policy revision 20 重新评审全 PR，未继承旧批准。
动机
持有完整备份、原工作目录已不可用的操作者需要找回任务和历史证据。原来只能手工解包并自行判断文件是否可信；现在在原设置入口选择归档与清单，一次操作得到私有隔离副本和可读、仅历史、未知的分类。
已验证原来源不可用后仍能检查真实 File/SQLite 任务与完整历史，并在坏输入之后重新读取先前报告；报告不会启动 Goal。本次不交付继续执行、跨格式转换、Windows/PostgreSQL 恢复、生产 RTO 或跨 owner 一致性资格。M2 仍需补齐组件版本与捕获边界；M3 仍需原生命周期、会话、Todo 和 effect owner 准入并完成未完任务的独立验收。
依据是本头基线的已接受 RFC以及维护者容量同意与 checkpoint 复用要求。容量同意已回填，范围仍为原本地 POSIX File/SQLite 检查。安全读取完整历史和坏输入后的报告回读有独立价值；本轮不把它升级为恢复后继续任务的验收。
改动思路
归档 IO、typed 可读性判断和现有设置投影分别有真实调用；研究 checkpoint 已共享清单、SQLite snapshot 和摘要规则，独立提取逻辑保护不同输入边界。
保留独立有用的 M1 惰性检查，原 M2/M3 承接资格及恢复执行，不加入统一恢复服务或推测性的格式转换器。
比较人工解包、只扩展配置快照、直接套用研究 checkpoint 和现方案：配置快照没有完整 Goal 历史，目录捕获不能替代不可信 tar 的路径、链接与展开检查。已有共享规则应复用，输入风险不同的 IO 不应强行统一。当前 loopx/hosts/research_checkpoint.py::_loopx_state_components 仍调用 build_state_backup_plan；checkpoint_artifacts.ts 共用 SQLite snapshot 和 canonical digest。未发现需要在本 PR 新增统一恢复框架或进行更大重构的重复决策规则。
双语 RFC §3 的矩阵覆盖清单、快照、摘要、发布、历史和会话/Todo 采用；M2/M3 明确格式/捕获/provider 资格及当前 Goal/session → knowledge → work admission。旧 v0 缺口保持 unknown。研究分支可以保留源 Goal，灾难替换需原 owner 排除旧 writer，两者不能混同。
具体改动
关键代码讲解
全 PR 为 34 个路径、+2394/-59：12 个 runtime/CLI/HTTP/typed 路径、4 个前端路径、9 个文档/图片路径、8 个验证路径和语义 registry，全部纳入判断。
verify_state_backup（loopx/state_recovery.py:342）：先验证实测摘要、内外清单与成员，再私有 staging 提取、复查、离线审计和发布；已有目标拒绝覆盖，失败清理本次候选。auditStateRecoveryOwners（loopx/control_plane/state_recovery.ts:275）：调用既有配置和 File/SQLite/Todo/history reader；existing-only 禁止补建或回退，完整历史超过 20,000 条拒绝发布。数据库读取留在一次性 worker，未加入共享 daemon 的 owner-audit 入口。verifySavedStateRecoveryAudit（同文件第 280 行）和共享decodeStateRecoveryAudit：绑定报告摘要、身份、汇总和 false 权限标志；历史报告不重新计时，也不冒充副本再次验证。StateRecoveryRequestMixin与StateRecoverySettings：通过 loopback opaque upload refs 建立私有检查，原配置快照仍为默认。用户选择归档及配套清单后一次明确执行，看到可读/历史/未知、责任 owner 和下一步；损坏输入及重载路径可读回旧报告。- 语义词汇登记、JsonObject 类型依赖收敛、只由 backup/recovery 请求的隔离 fixture，以及双语规范/指南/路线图与合成图片，均保持相应生产边界。
**相对上次评审 aad964cd3：**当前 34 路径中 33 个 blob 完全相同。effect_runtime.py 合入主干进程退出/retirement 改动，两个 recovery snapshot 方法仍保留。冲突文件 goal-workspace-m2.mjs 采用主干完整 close/Back/Forward 断言，与基线一致，已退出本 PR 差异。另核对主干 checkpoint Host 模块迁移及当前 CLI 消费者，不能只用“恢复源码未变”推断兼容。
规范映射的 spec_revision 为 544e9de7a7d0691e5a96fa359e9b87c5722598d4：
| criterion_id | 本头结果 |
|---|---|
| Archive and manifest bind exactly | implemented：摘要、双清单与 witness 不一致经真实路径拒绝 |
| Extraction is confined | implemented：路径、链接、碰撞、PAX/sparse、容量、已有目标和失败清理负例通过 |
| M1 stays inert | implemented：原来源不可用后检查，未注册恢复 Goal；权限标志 false |
| M1 audit is understandable in product | implemented：当前打包设置、键盘操作、错误后历史回读与桌面/手机视图验证 |
| SQLite and configuration remain valid | implemented within profile：原 owner 完整性和 canonical reader；缺失或不支持状态不伪装可读 |
| v0 uncertainty is honest | implemented：缺失 witness/capture/owner 信息保留 held/unknown |
| Privacy boundary holds | implemented within local profile：私有输入、opaque refs、受限事实与不返回私有路径的错误 |
| M1 capacity defaults | implemented：维护者原决定与双语记录，未改变上限或扩大资格 |
| M3 restores one Goal end to end | deferred：仍归原 M2/M3 和生命周期/session/Todo/effect owners |
对主干的风险
最强风险是把可读数据误当作当前执行权，或让离线验证使用活动 provider。复核当前隔离 worker、existing-only reader 和共享 decoder 后，两个独立反例也通过真实归档入口：有效 SQLite 备份的 selector 改成合法 PostgreSQL 后返回 offline_provider_unsupported，没有回退到旧本地库；重排双清单 witness 后，组件/汇总不变，原报告仍能原值读回。没有伪造 owner 返回值。
本头证据（Node 24.21.0）：
| 验证 | 结果与边界 |
|---|---|
| Backup/recovery/configuration、runtime restart 与 locator-turnover/process-exit 回归 | 92 passed，0 skipped；本会话解决冲突时测试的树与已提交本头一致 |
| 新 immutable base 的原 backup/configuration 对照 | 29 passed；本头对应 17+12 项均包含在上行，默认路径与拒绝/readback 契约保留 |
| Recovery/configuration/digest/runtime-handler/checkpoint-artifact TS 五组 | 53 passed，0 skipped；本会话本头树执行 |
| 本轮额外真实归档反例 + 迁移后的 research-checkpoint capture/CLI | 50 passed，12 skipped；含 2 项反例，12 项缺少显式真实 native Host 资格环境，不计作联合恢复通过 |
| 本轮 semantic advisory → full drift；docs governance | 126 passed；docs 通过。两项 advisory 分别为既有 snapshot 精确允许集和已登记恢复词汇 |
| 本头 typecheck、Chat build、packaged configuration-backup 与 goal-workspace-m2 | 全通过；本轮实际查看当前桌面/390px 截图，历史时刻、未激活状态和下一步清晰可见 |
上述当前会话执行均核对源码与消费者；复用旧头证据仅用于不变规范背景，不把旧 APPROVE 或旧 CI 当作新头通过。浏览器周边 workspace discovery 为合成 fixture，备份 HTTP/Python/TS/SQLite 为真实源码服务；打包源码不等于安装 App。
保留历史失败：早先 Node25/未资格化 SQLite 的 8 failed/44 passed 已由明确选择 Node24 的完整路径验证覆盖；旧浏览器选择断言已由主干同一行为修复并本头验证。未降低上限、删除断言或只取一次成功来掩盖当前失败。当前远端 CI 仍有运行/排队项，尚无观察到的失败；pending 不计作通过，也不替代独立验证。
typed-state、domain-neutrality、behavior-disclosure、guidance-vs-obligation、default-off 和 authority lenses 均已核对：恢复分类用共享词汇，普通 snapshot/配置默认行为保留；next_action 为建议，容量拒绝和 false 执行许可为强制规则。没有把通用任务/额度义务改成恢复专属约束。未验证组合最大负载、Windows/PostgreSQL 恢复、当前安装 App 或真实 M2/M3 接续。
我的整体评价
APPROVE，限本头 M1 惰性检查增量，无新阻塞发现。 维护者的容量决定及 checkpoint 复用/分阶段衔接要求已回应；默认行为和当前主干集成有实际验证。long_horizon 的改善限于完整历史、失败后可重复回读和不复活旧权限；user_experience 的改善由原设置入口的真实检查与错误恢复支持。
前向重构审视保留原清单、snapshot、digest、canonical reader 和类型 owner，采用主干更完整的导航 smoke；无需扩大当前改动。此记录为作者账号的 COMMENTED 自评审，不是其他维护者的独立批准。旧 blocking review 的协调、远端 CI、合并权限以及 M2/M3 后续验收保持独立；没有执行合并。
English verdict: APPROVE - c0a11e1. Whole-PR M1 inert inspection and the main integration are supported by exact-head Python92, TypeScript53, new-base parity29, fresh semantic126 and packaged UI checks. Fresh checkpoint/counterfactual validation:50 passed/12 explicitly unqualified native-Host skips. No new blocker; unchanged limits, authority and defaults remain intact. Hosted CI, prior-review reconciliation, merge authorization and M2/M3 remain separate.
|
本轮精确头 对照维护者方向和前次补充要求：容量决定已回填；双语 RFC §3 明确现有 inventory/snapshot/digest/reader 的复用与不同输入边界；原 M2/M3 承接格式资格、当前 owner 准入及完成未完任务的独立验收。新基线默认行为对照、当前 head 的运行时/打包旅程、两个真实归档反例和迁移后的 checkpoint 调用验证支持本次 M1 APPROVE 结论。 **发布时间与合并状态补记：**review 开始时 PR 开放；结束回读确认维护者 本次未执行合并、撤销旧评审或部署。旧 REQUEST_CHANGES 仍留作讨论记录；closeout 返回 |
|
Reviewer: model_agent; gpt-6.1-sol; OpenAI; runtime_reported; reasoning_effort=xhigh 合并后审查：精确头 动机原项目已经不可用、手中只剩完整备份的操作者，需要在设置页找回保存的任务和历史，并知道下一步该找谁处理。 旧流程需要手工解包；本次增加隔离检查和可读报告，实测可以从 SQLite 备份读出未完成任务与历史，但普通窗口中的结果被裁切，滚轮无法到达下方任务和后续动作。 隔离读取、损坏文件拒绝和历史报告回读已验证；打包设置页的完整结果可达性尚未交付。 M1 只检查保存的证据，不恢复 Goal 执行；M2 捕获资格、M3 原 owner 准入后继续工作，以及 Windows/PostgreSQL 等扩展资格仍属后续边界。 依据是变更前完整 改动思路不可信归档 IO、离线 owner 核验和产品投影分别留在既有 Python 适配、TypeScript 决策与设置页边界，已经复用清单、SQLite 快照和规范摘要；不需要重建一套恢复决策源。 本批是可读、隔离、无准入的 M1；先修普通窗口报告可达性，M2 格式/捕获桥接与 M3 原 owner 准入继续保留在现有 RFC。
该表根据源码说明控制流，不是执行证据。旁路 private-file transport 只开放两个完整清单方法，普通 2 MiB RPC 不变。20,000 条提交上限在超过时拒绝，不截断后冒充完整历史。 具体改动对实际 mergebase 的完整提案为 34 文件、+2394/-59：归档 IO、typed owner/contract/隔离 worker、CLI/HTTP 和 runtime transport；设置页/数据 decoder/CSS；双语 RFC/路线图、备份指南/术语与语义登记；Python/TS/浏览器场景和构建配置。当前相对上次已读头的 27 个 blob 未变，另外 7 项文档与 runtime 集成重新核验；这次仍运行了当前头的测试、类型检查和打包。 关键代码讲解
按变更前 §9 的每项验收读回如下；deferred 指原来就属 M2/M3 的边界，不是本次新加的要求。
对主干的风险[P2] 为完整报告提供可用的滚动容器。 新 最小修复：在现有设置页或完整检查区域建立真正可滚动的有界容器，保证填充报告的 Goal、任务、owner、下一步和历史入口在普通高度可通过滚轮到达；增加 1200×878 与 390×844 的真实滚轮回归，保留键盘、坏归档和历史回读路径。 现有浏览器脚本的 其余验证明确保留通过和未验：
这些不证明 Windows ACL、PostgreSQL、安装宿主、组合最大容量、生产 SLO、捕获一致性或 M3 继续未完成任务；旧错误、平台跳过与缺失资格均不记为通过。 我的整体评价REQUEST_CHANGES（合并后新发现的 P2）。 容量同意与 checkpoint 共用 owner 的旧评审事项已由当前证据回应，后端的隔离读取/拒绝/历史回读也有效；剩余问题直接落在 M1 自己的“产品中可读、可采取下一步”验收，而不是要求 M1 一次完成 M3。未来维护性检查认为现有 typed owner、共享存储 reader 和隔离 IO 分工可以保留，不应为格式尚未互通引入平行恢复框架；本次最有价值的有界修复是滚动归属及普通输入回归。请由 UI owner 修复已合入的展示路径，并保留现有后续里程碑和平台/安装资格边界。 English verdict: REQUEST_CHANGES - post-merge audit of c0a11e1: ordinary mouse-wheel users cannot reach the populated backup report's tasks and next actions at desktop/mobile heights. Inert SQLite/HTTP/readback and corruption recovery pass; capacity consent and checkpoint reuse are addressed. Fix bounded scrolling; M2/M3 and broader qualification remain deferred. |
3 participants
Goal and outcome
Full backups previously required manual extraction. This PR adds
backup-state verifyand complete-archive inspection in Settings → Capability Center → backup. Users select an archive and manifest, create a private inert copy, and read captured configuration, File/SQLite tasks, complete committed history, and saved audits. Invalid or oversized input refuses publication and preserves earlier audits. Saved measurements remain historical across reloads.The archive adapter owns bounded filesystem IO; the TypeScript recovery owner binds manifests and observed members, then invokes canonical readers in a disposable verifier. Inspection never registers or activates a restored Goal, resumes a Host, grants a lease or replays an effect. Exactly 20,000 committed transactions per Goal remain readable; 20,001 refuse publication.
中文：在原设置和 CLI 入口验证完整备份，隔离读取任务、历史和审计；可读不代表恢复执行。未知状态保持未知，失败保留旧报告，历史测量不冒充重新验证。
Written by: model_agent — GPT-6, OpenAI.
Current review response
Maintainer capacity consent is now recorded in both RFC languages and the backup guide. It approves the unchanged local POSIX File/SQLite inert-inspection profile proposed at
5751b050f; it does not approve broader operational qualification or grant merge authority.The same comment's checkpoint request is addressed by a concrete owner/reuse matrix and staged contract.
research-checkpointalready reusesbuild_state_backup_plan, the SQLite snapshot owner and canonical structured digests. Archive extraction and directory capture retain their different input checks. The formats are not interchangeable. No new shared restore service or speculative converter is added.M2 owns complete component/version/capture/provider qualification; M3 owns isolated verification → current Goal/session admission → knowledge adoption → current work admission and the joint unfinished-Goal drill. Old v0 omissions remain unknown. Research branching does not prove exclusive disaster replacement. Existing session, Todo, Explore and effect owners retain authority, retry identity and reconciliation duties. Full M2/M3 recovery is not a new prerequisite for independently useful M1 inspection.
中文：容量同意已回填，不再重复请求。双语 RFC 已列出 checkpoint 的既有复用与合理分工，并将格式资格和引导式继续工作归入原 M2/M3 检查点；本次不宣称两种格式已联合恢复。
Integration and validation
Merged latest main
544e9de7a7d0691e5a96fa359e9b87c5722598d4atc0a11e13986d18367c280eeba6aac983e0fae990. The sole conflict wasexamples/personal-workspace-browser/goal-workspace-m2.mjs: both branches repaired task selection after closing details. The resolution keeps the mainline version, including route/drawer waits and Back/Forward assertions. The file is identical to main. The automatically merged effect-runtime transport preserves the two recovery verification methods alongside upstream process-retirement changes. Recovery limits, authority and defaults remain unchanged by this refresh.goal-workspace-m2configuration-backupPrior-head review validation at
aad964cd3additionally passed the semantic drift suite (126 tests), documentation governance and packagedgoal-work-map; those were not rerun for this test-only conflict resolution. Earlier installed-environment evidence remains historical. No new installed-app, PostgreSQL or joint M2/M3 qualification is claimed. The initial earlier Python attempt on unqualified Node 25 failed 8 tests; qualified Node 24 runs passed without relaxing limits or dropping assertions.The resolution adds no protocol vocabulary or product behavior. The bounded refactor pass retains the existing shared owners and adopts the more complete upstream smoke without adding an abstraction.
Remaining gates
Recovery RFC · Operator guide