Define self-update recovery remediation (T-617)

docs/review/phase4-review.md

@@ -7,7 +7,7 @@
 
 ## 总体判断
 
-**Phase 4 的实现设计质量高，未发现可证实的命令注入、强杀或越界移动安全缺陷。** 三个最敏感的点都做对了:**启动无命令注入面**(调用方给不了路径/参数/工作目录,平台层无 shell、无用户参数、绝对路径)、**更新绝不强杀**(只请求关闭 + 等自然退出)、**自更新可回滚且健康确认前不删 backup**。同时 **Phase 3 审查的 O1(切换前不复查运行状态)已被 T-401 闭合**。
+**Phase 4 的启动/更新安全设计质量高，未发现可证实的命令注入、强杀或越界移动安全缺陷；自更新恢复状态机存在一项须由 T-617 修复的 durability 后状态不一致。** 三个最敏感的点都做对了:**启动无命令注入面**(调用方给不了路径/参数/工作目录,平台层无 shell、无用户参数、绝对路径)、**更新绝不强杀**(只请求关闭 + 等自然退出)、**自更新健康确认前不删 backup**。同时 **Phase 3 审查的 O1(切换前不复查运行状态)已被 T-401 闭合**。
 
 不过，补充全栈复核发现 T-403 的自动化故障覆盖低于任务验收所要求的范围。因此 O1 不能仅视为普通“优化项”：Windows 真机锁语义仍属于 T-601，但可在无头环境验证的失败注入、崩溃 phase 和恢复契约应作为后续整改的高优先级测试项。O2、O3 仍是准确的架构/装配边界说明。
 
@@ -80,6 +80,8 @@
 
 **建议:**单列整改任务，先为 updater 的文件操作和目录同步提供最小失败注入 seam，补齐健康超时→rollback 被锁阻塞→后续 `Recover`、各 transaction phase 崩溃恢复、journal/rename/sync/cleanup 失败与 health CLI 参数拒绝的双端测试。真实 Windows 文件锁、杀毒软件和断电结果仍只由 T-601 真机/VM 验证，不以单元测试替代。
 
+**追加状态机发现:**`prepared` journal 成功写入后，`app → backups/<request-id>` 的 `os.Rename` 可能已经完成，而 `renameDirectory` 在随后的目录 sync 返回错误。当前 `Update` 直接返回 `failBeforeActivation`；磁盘成为 target 缺失、managed backup 存在、journal 仍为 `prepared`。现有 `recoverLayout` 对 `prepared` 无条件删除 journal，因而不会把 old app 恢复到 target。该情形不是 Windows 真机锁的未知行为，而是可由既有 `DirectorySyncer` seam 在无头测试复现的恢复一致性缺陷。T-617 必须修复此拓扑判断并覆盖即时/下次恢复；若恢复仍失败，必须保留 journal/backup 与 `ErrRecoveryRequired`。
+
 ### O5 · 端到端装配依赖应拆开跟踪
 
 **现状:**O2 正确指出 launch/update/updater 目前只完成无头 core 边界；production cmd 尚未装配可信 Catalog、许可证或 completed-download 消费源。
@@ -98,7 +100,7 @@
 
 Phase 4 的核心安全属性(启动无注入面、更新不强杀、自更新可回滚且健康门控、切换临界区复查闭合 Phase 3 O1、Windows 隔离 + fail-closed stub)全部到位,失败码体系完整。建议处理顺序:
 
-1. **[高优先级 · 可靠性/测试]** O1/O4:补自更新健康超时后的 Recover/锁阻塞恢复、新进程健康门禁、transaction phase 崩溃恢复与 journal/rename/sync/cleanup 失败注入测试;真机锁语义归 T-601。
+1. **[最高优先级 · 恢复修复与测试]** O1/O4:T-617 先修 prepared rename+sync 后 target/backup 与 journal 不一致，再补自更新健康超时后的 Recover/锁阻塞恢复、新进程健康门禁、transaction phase 崩溃恢复与 journal/rename/sync/cleanup 失败注入测试;真机锁语义归 T-601。
 2. **[准确性 · 装配规划]** O2/O5:文档保持"无头 core 已完成、端到端未接通"表述；可信 Catalog/下载消费、T-502 授权和自更新发布源分别落地，不笼统等待单一任务。
 3. **[后续]** O3:T-502 接入真实授权策略并补端到端授权测试。
 
@@ -126,6 +128,7 @@ Phase 4 的核心安全属性(启动无注入面、更新不强杀、自更新
 ### 采纳
 
 - **接受 O4**,并同意其定级:这是**测试覆盖缺口,不是已证实的实现缺陷**(代码在锁阻塞时 fail closed、保留 journal/backup、不强杀)。但缺少故障注入与中断 phase 恢复测试,意味着该状态机的持久化边界行为"构造上正确"而**未被测试证明**,且后续回归无法拦截。对自更新器(失效即"盒子自己更新不动")值得列高优先级。
+- **T-617 追加发现(2026-07-19):**prepared journal 后首次 rename 已完成但 directory sync 失败时，实际 target/backup 拓扑与 `phasePrepared` 的旧恢复假设不一致；`Recover` 不能再无条件删除该 journal。此项是由既有 `DirectorySyncer` seam 可复现的恢复正确性缺陷，与 O4 的测试覆盖缺口不同；T-617 需作最小状态机修复并以故障测试证明。它不推翻原有“无命令注入、不强杀、无越界移动”的安全裁定。
 - **接受 O5** 对原 O2 的细化:装配前置不应笼统归为"等 T-502"。可信 Catalog 发布配置、签名清单加载/缓存/目标过滤、下载完成文件受控消费可在 T-502 前独立接入;T-502 只决定授权门禁;自更新另缺可信包下载/验签/版本选择/UI 触发器。按四条分别落任务与验收。
 - **接受验证段**:`go test -count=10` 对并发/恢复代码是恰当的抗 flakiness 实践;`-race` 因 `CGO_ENABLED` 禁用无法运行并如实声明"不得表述为 race detector 已通过",该诚实度正确。
 
@@ -143,4 +146,4 @@ Phase 4 的核心安全属性(启动无注入面、更新不强杀、自更新
 3. **[后续]** O3:T-502 接入真实授权策略并补端到端授权测试。
 4. **[真机]** T-601:Windows 文件锁 / 杀毒软件 / 断电故障注入,不由单元测试替代。
 
-> 裁定:Codex 本轮补充(O4 自查、O5 细化、验证段)全部成立;原审核在测试覆盖维度不如本轮严谨,予以采纳。Phase 4 安全总结论(无注入面、不强杀、可回滚且健康门控、Phase 3 O1 已闭合)双方一致,不需回滚或返工。
+> 裁定:Codex 本轮补充(O4 自查、O5 细化、验证段)全部成立;原审核在测试覆盖维度不如本轮严谨,予以采纳。随后发现的 prepared rename+sync 恢复不一致由 T-617 进行最小定向修复；Phase 4 安全总结论(无注入面、不强杀、健康门控、Phase 3 O1 已闭合)仍成立，不需要回滚既有 Phase 4 实现或扩大范围返工。