fix(backup): validate upgrade backups and guide in-place 2.0 adoption

[loopx-agent]

Existing backup archives containing legitimate hardlinked files could be produced successfully and then rejected by verification/recovery. Reuse the current tar IO adapter to restore only links to earlier verified regular members, retaining the existing path, digest, private-permission and unsafe-link refusals.

Provide a bilingual Agent prompt for the 1.x → 2.0 in-place upgrade: keep the same installation, project, state routes and Goal/Agent identities; inspect the actual installation, authority format/provider and ownership policy; use the existing update, backup, format-upgrade, cold-import or policy-migration owner only where needed; then continue the original task. The recovery RFC and roadmap mirrors describe that same bounded route. The IO stream-copy extraction remains local to the existing module and passes the unchanged maintainability budget.

Validation on this content:

• Normal official 1.4.2 → 2.0.0a1 wheel replacement in the same isolated Python environment: both an old Markdown/legacy Goal imported to SQLite and an already-current SQLite Goal passed. Existing paths, full active/archive Tasks, relationships, configuration bytes and required material remained intact; the original Task produced its result, and original-operation recovery preserved later writes.
• Both upgrade profiles verified the 1.4.2-produced backup containing hardlinks. All 1,792 candidate wheel package entries matched the noneditable installation.
• 4 existing historical-policy/receipt tests passed against that installed candidate on real File/SQLite stores. These use synthetic historical fixtures, separately from the two actual 1.4.2-created profiles.
• Retained runtime evidence: 88 backup/configuration cases and the 15 final normal-project/unsafe-link cases passed on the unchanged IO/test source. The current revision changes documentation only.
• Relative links and both RFC mirrors checked; public/private scan clean. Native premerge validation covers the changed IO, tests and upgrade documentation; exact-scope change-quality receipt is recorded.

The target remains a 2.0 candidate. This proposal qualifies the named isolated CLI/data paths; broader release, platform and long-running qualification remains separate. No live user installation or Goal was upgraded.

中文：本次“迁移”是 1.x → 2.0 原地迁移式升级。保留已证实有用的硬链接备份修复，提供 Agent 可执行的原地升级 prompt；按实际状态复用安装更新、authority 格式升级、旧 Markdown 导入及 policy 升级入口。两条真实普通安装原地升级路径和 4 项已安装历史策略／原回执测试通过；完整任务、归档、关系、配置、材料、原路由和后写得到验证。完整跨平台／长期及发布资格仍独立保留。

[loopx-agent]

Reviewer: model_agent | OpenAI | gpt-6.1-sol | runtime_reported | reasoning_effort=max

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

未发现当前版本的阻塞性问题。这是作者自评，不替代独立维护者审批，也不表示可以直接合并。

动机

准备把现有 LoopX 1.x 原地升级到 2.0、并依赖私有备份保留原任务和材料的用户与 Agent。 原来，同一份正常备份中的两个文件名引用同一份材料时，备份能生成，验证却拒绝硬链接；现在只接受指向先前普通成员的明确引用，原材料可在隔离副本中读回。 原备份能够安全核验，用户的 Agent 可以用一段提示组合已有升级入口，保留原路径、完整工作与后写并继续原任务。 本次不交付跨机搬迁、会话转移、新迁移执行器或新 UI；不授权活跃升级、合并或发布。 完整平台、真实 Host 接续、发布默认和长期运行资格仍由各自现有 owner 验收；M2/M3 灾难恢复保持原有边界。

改动思路

硬链接属于归档 IO 的兼容缺口；在现有 Python IO 适配器修补，TS 继续拥有清单与审计，不新增迁移决策源。 当前 PR 仅修复可用备份的隔离核验，并给出复用原子能力的原地升级 prompt；不建立新执行体系。 最小可行修复就是扩展原有有界扫描器；仅让未来的 producer 把硬链接摊平成副本，修不好已经存在的备份，通用解包器又会绕过已有安全边界。这里没有新增持久化状态、协议版本、CLI 命令、调度器或权限 owner。原来先校验归档/清单、再验证内容、最后发布私有隔离副本的顺序保持不变。

输入	基线	当前版本
普通成员	预览/隔离核验成功	完整结果相同，仅观察时间、耗时及其审计摘要不同
producer 的明确回指硬链接	拒绝，副本不存在	预览不写盘；执行保留原字节、同一 inode 与私有权限
前向、链式、符号链接或目录目标，越界/非零 body	拒绝	继续拒绝，不发布目标

这是源码与真实 CLI 执行结果的比较，没有增加新的交互层；一段 prompt 让 Agent 从现有环境识别信息，只对确实缺失的版本选择或权限询问用户。

具体改动

评审基准是修改前已接受的 docs/architecture/rfcs/complete-state-recovery-v0.md，spec_revision=aeeab9214f8a85ee2fce5a840ee66077e5d7821f；固定版本规范。没有用本 PR 改写后的提案反向定义通过标准。

• Archive and manifest bind exactly：仍先核对外部摘要和内外清单，故意错误的摘要在真实入口拒绝。
• Extraction is confined：只允许先前普通成员，新增的目录、前向、链式、符号链接、越界目标和非零大小反例全部拒绝；失败不留下目标或 staging。
• M1 stays inert：成功仍只产生新的隔离副本和审计；预览不写盘，执行权和激活资格仍为 false。
• v0 uncertainty is honest：不完整 owner/capture 信息仍是 held/unknown，原 legacy_manifest_incomplete 与下一步说明保持。
• M2、M3：捕获一致性和受控灾难恢复的整体验收不属于这次修复，原要求保留，没有被原地升级 prompt 替代。

关键代码讲解

1. _scan 在原路径/父目录冲突检查之后识别硬链接，目标必须已经以普通成员出现，且链接 body 大小为零；普通文件全部验证后，才在私有 staging 内建立硬链接。它不会通过活跃源路径解析目标。
2. _copy_regular_member 只是把原有有界读流、摘要、字节数、私有文件、fsync 和 finally 关闭提到同模块 helper；没有新 IO 框架，原维护性上限没有调高。
3. verify_state_backup 继续让 TS 核对清单和 owner，第二次扫描/摘要仍防输入变化，最后只发布新的 inert 审计。CLI 与既有 HTTP 上传共用这个入口，两处适配器和 typed owner 均未改动。

双语 RFC/roadmap 和升级 prompt 统一为原安装/原项目的 1.x→2.0 升级。已有效的 provider/policy 保持，只有实际需要时才执行格式升级、Markdown 导入或历史 policy 迁移；原操作恢复、后写保留、停止旧写方与二进制/数据回退的区别都有明确说明。旧链接锚点保留，六份文档与两处源码变化均按最终八文件 diff 检查。

对主干的风险

主要风险是新支持硬链接后误放过越界/间接引用，或 helper 提取改变普通成员核验。为此在固定基线 aeeab9214f8a85ee2fce5a840ee66077e5d7821f 与当前 b41fd1023a36446ec4fdcdb1abf4be66d2916d00 上，使用同一真实 producer 归档/清单，执行了 22 次公开 CLI 比较：普通输入一致，旧硬链接缺陷可重现，当前字节/inode/权限与七类拒绝通过；整个过程没有触碰活跃用户状态，临时 runtime 已通过其 owner 停止。

第一次汇总比较错误地保留了每次核验的观察时间及其派生审计摘要；实际各 CLI 断言已完成。保留原回读后，逐份独立核对审计摘要，再排除这些明确的时间差进行比较，没有重跑副作用或修改产品断言。完整诊断、清单/归档身份、owner 状态和权限标志都保留比较。

复用了与当前 IO/测试源码逐字一致的既有 88 项备份/配置验证、15 项最终反例，以及正常安装的两条 1.4.2→候选原地升级和四项历史 policy/receipt 验证；这些范围分别计数，没有相加制造一个总成绩。当前八文件的 6 个直接检查与 14 个所选 premerge 检查通过。全 diff 的语义探针无可识别的新词汇载体，但它不证明动态构造或文本含义；hardlink 仍是本地 tar 输入分类。

当前评审策略是 wait_for_ci=false，未查询或等待远端 CI。Windows/任意 Host/真实模型对 prompt 的采用、正式发布和完整长期资格没有由本评审证明；主干集成与合并准入也须另查。新指南是显式复制的说明，不自动注入或激活功能，没有默认关闭功能的旁路或第二套权限来源。

我的整体评价

交付判断为 justified_increment。long_horizon：improved，原回执与后写保留，隔离核验不派发任务或重复副作用；既有长期资格未被提前结算。 user_experience：improved，一段 prompt 复用既有上下文和权限，没有新增用户表单、工作路径重填或迁移确认层。 这两条判断只覆盖已执行的本地归档/升级路径，不冒充完整 Host 接续或默认资格。

已有 v0 备份是独立持久化输入；保留格式读回，通过既有 IO 接纳明确硬链接，不增加平行版本分支。 已经删除专用迁移 executor/UI 方案，只保留原 IO 修复与 prompt；同模块 stream-copy helper 降低热函数复杂度，没有新抽象层。 硬链接属于归档 IO 的兼容缺口；在现有 Python IO 适配器修补，TS 继续拥有清单与审计，不新增迁移决策源。 当前 PR 仅修复可用备份的隔离核验，并给出复用原子能力的原地升级 prompt；不建立新执行体系。 这次保留的是能复现、可回归验证的原子能力修复；没有必要把已删除的搬迁系统加回来。M2/M3、R5/T4、D2/D3 的剩余资格仍由原 owner 推进。本结论针对当前完整 diff；任何新的相关源码或范围变化都应重新检查。

English verdict: APPROVE — b41fd1023a36446ec4fdcdb1abf4be66d2916d00. The existing verifier safely admits producer back-references while retaining inertness, confinement and old receipt boundaries. Paired real-CLI evidence supports the fix; the guide composes existing primitives for an in-place upgrade. Author-owned COMMENTED self-review; independent approval and merge authority remain separate. CI was not consulted.

[loopx-agent]

Reviewer: model_agent | OpenAI | gpt-6.1-sol | runtime_reported | reasoning_effort=max

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

本次评审针对完整 4a95a9b108faa16afb90bde8c0788a57f8e47088。作者自评认为可接受；独立维护者审批与合并授权仍需分别满足。

动机

准备把现有 LoopX 1.x 原地升级到 2.0、并依赖私有备份保留原任务和材料的用户与 Agent。 原来，同一份正常备份中的两个文件名引用同一份材料时，备份能生成，验证却拒绝硬链接；现在只接受指向先前普通成员的明确引用，原材料可在隔离副本中读回。 原备份能够安全核验，用户的 Agent 可以用一段提示组合已有升级入口，保留原路径、完整工作与后写并继续原任务。 本次不交付跨机搬迁、会话转移、新迁移执行器或新 UI；不授权活跃升级、合并或发布。 完整平台、真实 Host 接续、发布默认和长期运行资格仍由各自现有 owner 验收；M2/M3 灾难恢复保持原有边界。

改动思路

硬链接属于归档 IO 的兼容缺口；在现有 Python IO 适配器修补，TS 继续拥有清单与审计，不新增迁移决策源。 当前 PR 仅修复可用备份的隔离核验，并给出复用原子能力的原地升级 prompt；不建立新执行体系。 不修改现有 producer 让它只对将来摊平链接，因为这修不好已经保存的备份；也不改用通用解包器绕开已有安全边界。仍先核对归档与清单，再验证文件，最后只发布私有隔离副本。升级由用户的 Agent 组合现有安装、备份、格式、导入和策略入口，不增加权限 owner 或交互层。

输入	固定基线 aee 的观测	b41 的观测（本 head 的运行源码相同）
普通成员	预览/隔离核验成功	完整结果相同，仅明确的观察时间、耗时及派生摘要不同
producer 的回指硬链接	拒绝，无副本	预览不写盘；执行保留原字节、同一 inode 与私有权限
前向、链式、符号链接/目录目标，越界或非零 body	拒绝	继续拒绝，不发布目标

具体改动

以修改前接受的 完整恢复规范 为标准，spec_ref=docs/architecture/rfcs/complete-state-recovery-v0.md，spec_revision=aeeab9214f8a85ee2fce5a840ee66077e5d7821f，没有用本 PR 新写的说明反向定义通过标准。

• Archive and manifest bind exactly：先核对摘要与内外清单，错误摘要的真实入口反例保持拒绝。
• Extraction is confined：只接受较早的普通成员；目录、前向、链式、符号链接、越界目标和非零 body 反例拒绝，失败不发布目标或留下 staging。
• M1 stays inert：成功仍是新的隔离副本和审计；预览不写盘，没有执行权或激活资格。
• v0 uncertainty is honest：不完整 capture/owner 保持 held/unknown，原诊断与下一步说明保留。
• M2、M3：捕获一致性和受控灾难恢复不在本修复范围，既有要求保留。

关键代码讲解

1. _scan 在原有路径/父目录冲突检查后识别硬链接，要求目标已经作为普通成员出现、body 为零；普通文件验证完毕后才在私有 staging 建立链接，不通过活跃源解析目标。
2. _copy_regular_member 是同模块的原有界读流提取，保留摘要、字节上限、私有权限、fsync 和 finally 关闭，维护性上限未调高。
3. verify_state_backup 继续复用 TS 清单/owner 审计与二次归档检查，最终只发布新的 inert 结果；既有 CLI 与 HTTP 使用同一个适配器。

双语 RFC/roadmap 与 96 行升级指南 均指向同一安装、项目和状态路由的 1.x→2.0 升级。保留有效 provider/policy，只按实际状态选择必要操作；原回执恢复、后写保留、旧写方停止，以及二进制回退与数据回退的区别没有省略。

相对上次 b41，本次只修 容量说明 中仍把所有硬链接列为拒绝的矛盾，统一为较早普通成员可用、其他目标拒绝。整树比较确认其余运行代码、测试、调用方和依赖均未变化；完整 PR 仍为八文件（+308/-146）。这是对整个最终 diff 的判断，并非只检查最后一条文案。

对主干的风险

主要风险仍是误接纳越界或间接引用，以及普通文件流提取造成行为变化。原 aee↔b41 的同归档真实 CLI 对照包含 22 次调用，覆盖普通结果比较、producer 缺陷与七类拒绝；它们保留原执行版本。本次通过整树只有一处文档差异核实复用条件，没有把旧执行改标成新 head 的重跑。原比较对观察时间及派生审计摘要的处理错误已用保留回执独立校验修正，没有重放副作用。

同理复用 88 项备份/配置、15 项最终反例、两条同环境的正式 1.4.2→候选升级，以及四项分别构造的已安装历史 policy/receipt 测试。原路径、完整任务/归档/关系/配置/材料和后写由这些对应范围证明，不合成一个虚构总成绩。当前六个直接检查和十四个所选检查全部通过，没有命令失败、告警或人工 hold。premerge 包装最初因旧 CQR 拒绝；又遇 main 的 a54→860 更新，已检查相关账户/Chat 路由变化和十三个未变 owner/依赖，按新 base 重建 CQR 并读回 valid。原拒绝记录保留，没有靠重跑健康矩阵改写结果。

当前整合后的 main/head 组合没有执行，真实 Host、模型采用 prompt、更广平台、发布默认和长期资格也未由本评审证明。wait_for_ci=false，未查询或等待 CI。现有预算和权限拒绝不变，hardlink 仍是归档适配器的本地输入分类；没有新增协议状态、默认开关或自动升级，语义探针也不被当作全文语义证明。

我的整体评价

交付判断为 justified_increment。long_horizon：improved，原回执与后写保留，隔离核验不派发任务或重复副作用；既有长期资格未被提前结算。 user_experience：improved，一段 prompt 复用既有上下文和权限，没有新增用户表单、工作路径重填或迁移确认层。 判断覆盖有证据的本地归档/升级路径，剩余完整 Host、平台与发布资格继续由各自 owner 验收。

已有 v0 备份是独立持久化输入；保留格式读回，通过既有 IO 接纳明确硬链接，不增加平行版本分支。 已经删除专用迁移 executor/UI 方案，只保留原 IO 修复与 prompt；同模块 stream-copy helper 降低热函数复杂度，没有新抽象层。 硬链接属于归档 IO 的兼容缺口；在现有 Python IO 适配器修补，TS 继续拥有清单与审计，不新增迁移决策源。 当前 PR 仅修复可用备份的隔离核验，并给出复用原子能力的原地升级 prompt；不建立新执行体系。 本轮把先前遗漏的兼容说明统一到已执行的规则，保留最小修复和原来验收，不增加迁移系统。独立审批、合并准备度与维护者授权仍是后续单独的判断。

English verdict: APPROVE — 4a95a9b108faa16afb90bde8c0788a57f8e47088. The complete eight-file proposal repairs safe producer hardlink verification and provides an in-place upgrade prompt using existing owners. The documentation contradiction is resolved; prior real-path evidence is reused with an explicit source check, current local checks passed and the refreshed CQR verifies. Author-owned COMMENTED self-review; independent approval, integration and merge authority remain separate. CI was not consulted.