Implement self-update recovery (T-403)
This commit is contained in:
@@ -47,7 +47,7 @@ SoftBox 软件盒子是一个使用 Go + Gio 开发的 Windows 桌面客户端,
|
||||
|
||||
## 当前阶段
|
||||
|
||||
当前项目已完成 Phase 0～2、T-301～T-303、T-615 与审核整改 `T-604`～`T-614`。Windows 安全路径阻断项、图标缓存资源边界、后台结果回 UI 线程的事件接线、双适配器交互契约、`VisibleItems` 快照生命周期、双端 Gio shell 职责拆分、unsafe cache 安全诊断/runbook、ZIP 中央目录/EOCD(含 ZIP64)预扫描、安装文件/目录/journal 的代码层耐久顺序、Catalog canonicalization/签名静态 corpus，以及同句柄 Catalog size/SHA→严格 app.json→staging/switch/回滚安装链均已关闭；T-303 已将 verified-package 的 staging 前磁盘/运行状态预检和稳定失败码落实到 core，T-615 已将 ZIP 输入/staging 输出 I/O 分界、平台磁盘满分类和清理失败恢复落实到 core。T-401 已完成完整路径进程检测、受控启动和 Switcher 临界区复查；T-402 已完成子软件更新编排；T-403 已正式落成，下一步实现 SoftBox 自更新助手、健康确认与恢复。物理断电、文件锁与杀毒软件干扰验证保留到 T-601 发布前环境验证。
|
||||
当前项目已完成 Phase 0～2、T-301～T-303、T-615 与审核整改 `T-604`～`T-614`。Windows 安全路径阻断项、图标缓存资源边界、后台结果回 UI 线程的事件接线、双适配器交互契约、`VisibleItems` 快照生命周期、双端 Gio shell 职责拆分、unsafe cache 安全诊断/runbook、ZIP 中央目录/EOCD(含 ZIP64)预扫描、安装文件/目录/journal 的代码层耐久顺序、Catalog canonicalization/签名静态 corpus，以及同句柄 Catalog size/SHA→严格 app.json→staging/switch/回滚安装链均已关闭；T-303 已将 verified-package 的 staging 前磁盘/运行状态预检和稳定失败码落实到 core，T-615 已将 ZIP 输入/staging 输出 I/O 分界、平台磁盘满分类和清理失败落实到 core。T-401 已完成完整路径进程检测、受控启动和 Switcher 临界区复查；T-402 已完成子软件更新编排；T-403 已完成受限 SoftBoxUpdater、自身 EXE 健康确认与可恢复切换。物理断电、文件锁与杀毒软件干扰验证保留到 T-601 发布前环境验证。
|
||||
|
||||
优先路径:
|
||||
|
||||
@@ -55,7 +55,7 @@ SoftBox 软件盒子是一个使用 Go + Gio 开发的 Windows 桌面客户端,
|
||||
2. 已完成 Phase 1:清单验签、ZIP 安全解压、原子切换回滚原型。
|
||||
3. 已完成 Phase 2 与 T-301:清单/列表/详情/图标缓存 + 可恢复下载队列。
|
||||
4. 已完成 T-604:modern/Win7 workspace 与 Gio 版本解析彻底隔离。
|
||||
5. 已完成 T-606～T-615:图标缓存资源边界、UI 线程事件接线、双 Gio 适配器交互契约、`VisibleItems` generation 生命周期、双端 `shell.go` 同 package 镜像职责拆分、unsafe cache 诊断/人工恢复指引、ZIP 中央目录/EOCD 预扫描、安装耐久顺序、Catalog 静态签名向量，以及 staging 输出 I/O 根因与磁盘满诊断;已完成 T-302/T-303:已验签 Catalog 选择与同句柄 size/SHA、严格 app.json、安全 staging/switch/健康与记录写回滚链路，以及 staging 前磁盘/运行状态预检与稳定失败码。T-401 已完成进程检测、受控启动与切换临界区复查；T-402 已完成关闭确认、自然退出等待和更新编排；T-403 已正式落成，当前执行 SoftBoxUpdater 自更新与健康恢复；完成后进入 Phase 5。T-601 仍须补真实 Windows 环境的断电/干扰注入。
|
||||
5. 已完成 T-606～T-615:图标缓存资源边界、UI 线程事件接线、双 Gio 适配器交互契约、`VisibleItems` generation 生命周期、双端 `shell.go` 同 package 镜像职责拆分、unsafe cache 诊断/人工恢复指引、ZIP 中央目录/EOCD 预扫描、安装耐久顺序、Catalog 静态签名向量，以及 staging 输出 I/O 根因与磁盘满诊断;已完成 T-302/T-303:已验签 Catalog 选择与同句柄 size/SHA、严格 app.json、安全 staging/switch/健康与记录写回滚链路，以及 staging 前磁盘/运行状态预检与稳定失败码。T-401 已完成进程检测、受控启动与切换临界区复查；T-402 已完成关闭确认、自然退出等待和更新编排；T-403 已完成 SoftBoxUpdater 的受限 transaction、PID 自然退出、固定健康启动与恢复。下一步按路线图正式落成 Phase 5 的 T-501。T-601 仍须补真实 Windows 环境的断电/干扰注入。
|
||||
|
||||
## 领取任务规则
|
||||
|
||||
|
||||
@@ -19,7 +19,7 @@
|
||||
| 包完整性 | SHA-256 | 已定 | 下载后、执行前强制校验 |
|
||||
| 传输 | HTTPS | 已定 | 清单与软件包一律 HTTPS |
|
||||
| Windows API | golang.org/x/sys/windows + 动态加载(LoadLibrary) | 已定 | Win10 专属 API 动态加载并降级,不进导入表 |
|
||||
| EXE 签名 | Authenticode | 已定 | 主程序与 Updater 均签名;证书采购待确认 |
|
||||
| EXE 签名 | Authenticode | 已定 | 主程序与 Updater 均签名;证书采购待确认；当前本地自更新只做受限切换，不消费在线签名包 |
|
||||
| 测试 | go test(core 无头可测) + fake/stub 注入 | 已定 | domain/application 不依赖 Gio 与 Windows API |
|
||||
| CI | Gitea Actions 模板 + 本地 Phase 0 脚本 | 部分已定 | `.gitea/workflows/phase0-build.yml` 复用本地入口;远端 runner 可用性待确认 |
|
||||
| 静态检查 | go vet(+ 待定 golangci-lint) | 部分已定 | vet 必跑;lint 工具后续确认 |
|
||||
|
||||
@@ -83,6 +83,7 @@ soft_quay/
|
||||
│ └─ updater/ # 盒子自更新编排
|
||||
├─ app-modern/ # 现代版(go.mod,Go 1.25 + Gio v0.10.1)
|
||||
│ ├─ cmd/softbox/
|
||||
│ ├─ cmd/softboxupdater/# 无 Gio 的受限自更新助手
|
||||
│ ├─ ui/gio/ # shell 根编排 + header/catalog/detail/style 职责文件
|
||||
│ └─ platform/windows/
|
||||
├─ app-win7/ # Win7 遗留版(go.mod,Go 1.20 + Gio v0.6.0)
|
||||
@@ -187,7 +188,7 @@ T-613 已把该状态机的代码层耐久顺序收敛为:payload 的 CRC/长度
|
||||
|
||||
真实断电时的硬件/驱动缓存、杀毒软件/文件锁干扰和目标文件系统行为仍需 T-601 在 Windows VM/真机做故障注入；T-302 的代码级链路与单元测试不替代硬件级断电验证。
|
||||
|
||||
盒子自更新由独立 `SoftBoxUpdater.exe` 完成(传入 PID、暂存目录、目标目录;等待退出→备份→切换→启动新版→失败恢复)。
|
||||
T-403 的盒子自更新由独立、无 Gio 的 `SoftBoxUpdater.exe` 完成。它仅接受正 PID、绝对 `<root>/app` 和绝对 `<root>/staging/<request-id>`；request ID 不走 CLI，而是从已准备 staging 的规范目录名派生并复验。旧 PID 自然退出后才检查/恢复上次 journal，随后以 `prepared → target_backed_up → staging_activated → launched → committed` 把 `app` 与同 root staging 受限 rename。`core/updater` 只依赖 PID waiter、固定 launcher、health waiter 和目录同步接口；Windows 的 `OpenProcess(SYNCHRONIZE)`/短等待、无 shell 固定 health 启动和 `FlushFileBuffers` 均保留在两端 `platform/windows`，非 Windows stub fail closed。新版仅能从自身 `<root>/app/SoftBox.exe` 在匹配的已激活 transaction 下写最小 `<root>/self-update-health.json` 确认；确认前旧 backup 不删除，失败优先 restore，文件锁导致 restore 失败则保留 journal/backup 而不强杀。它不提供下载、签名校验、版本选择或 UI 触发，可信 package→staging 链继续后置。
|
||||
|
||||
授权:平台层采集多个稳定硬件标识 → 清洗生成 machine_hash(不保存原始序列号/MAC)→ 服务端 Ed25519 私钥签发许可证 → 客户端内置公钥离线验签;许可证与程序文件、用户配置分开保存;子软件必须独立再次验证,不能只信盒子。
|
||||
|
||||
|
||||
+7
-1
@@ -366,7 +366,13 @@ SoftBox.exe --repair-app <id> # 按 files.json 修复安装(V1.1)
|
||||
SoftBoxUpdater.exe --pid <主程序PID> --staging <暂存目录> --target <目标目录>
|
||||
```
|
||||
|
||||
等待主进程退出 → 备份旧版 → 切换新版 → 启动新版 SoftBox → 失败时恢复备份。退出码:0 成功;非 0 失败并写日志。
|
||||
这是受约束的本地激活助手，**不是**自更新下载或签名校验入口。`target` 必须是绝对 `<root>/app`，`staging` 必须是绝对 `<root>/staging/<request-id>`；`request-id` 不作为 CLI 参数，助手只从已准备 staging 的末段取得并重新校验安全字符。它拒绝相对路径、交叉 root、符号链接、非目录、已有同 ID backup 和任意可执行路径/参数。
|
||||
|
||||
助手先等待正 PID 的旧主进程自然退出（OpenProcess/等待失败、取消或超时均不把它当成已退出），再恢复遗留 transaction 并执行 `prepared → target_backed_up → staging_activated → launched → committed`。它只允许 `app → backups/<request-id>`、`staging/<request-id> → app` 两次受限 rename，并以原子 JSON transaction 和目录同步建立崩溃恢复栅栏；不会写 `data/` 或 `licenses/`，也不会强杀进程。
|
||||
|
||||
新版只以 `<root>/app/SoftBox.exe --softbox-update-health <request-id>`、固定工作目录启动。主程序在 Gio Layout 前从自身 EXE 推导 root，且仅当本地 transaction 处于已激活/已启动阶段并匹配 request ID 时，才在 `<root>/self-update-health.json` 原子写入仅含 `schema_version` 和 `request_id` 的确认。助手只接受完全匹配的确认后才清理 backup/transaction；启动或健康失败会尽力恢复旧 `app`，若 Windows 文件锁禁止恢复则保留 journal/backup 供下次受控助手在旧 PID 退出后恢复。退出码:0 成功；非 0 表示未提交或恢复材料仍需处理。
|
||||
|
||||
当前没有可信 self-update 下载源、SHA-256/签名消费链、版本选择或 UI 触发器。任何调用方都必须在此助手之前独立完成可信包验证和安全 staging；真实文件锁、杀毒/断电和 UAC/签名发布由 T-601/T-603 的 Windows 环境验证覆盖。
|
||||
|
||||
### 5.3 子软件推荐参数(v1 推荐,非强制)
|
||||
|
||||
|
||||
@@ -13,23 +13,24 @@
|
||||
## 当前快照
|
||||
|
||||
- 日期:2026-07-19
|
||||
- 阶段:Phase 2 已完成(T-201～T-204);Phase 3 的 T-301 可恢复下载队列、T-302 安装流程整合、T-303 失败处理/磁盘预检查与 T-615 staging 输出 I/O/磁盘满诊断整改已完成;审核整改 T-604～T-614 与 Phase 4 的 T-401 进程检测、受控启动和切换临界区复查、T-402 子软件更新编排已完成
|
||||
- 阶段:Phase 2 已完成(T-201～T-204);Phase 3 的 T-301 可恢复下载队列、T-302 安装流程整合、T-303 失败处理/磁盘预检查与 T-615 staging 输出 I/O/磁盘满诊断整改已完成;审核整改 T-604～T-614 与 Phase 4 的 T-401 进程检测、受控启动和切换临界区复查、T-402 子软件更新编排、T-403 受限盒子自更新事务已完成
|
||||
- 技术栈:根 Go 1.25 workspace 只纳入 core/app-modern,`app-win7/go.work` 独立纳入 core/app-win7;版本闸门证明 modern Gio v0.10.1 与 win7 Gio v0.6.0 不交叉解析
|
||||
- 生产代码:core 已有 Catalog/本地状态/存储、共享 Windows 安全相对路径策略与静态跨实现 canonicalization/Ed25519 vector corpus(拒绝非法 surrogate、`-0` 和非唯一 Base64 signature,大整数保持 token)、安全 ZIP 解压/回滚原型及 T-302/T-303/T-615 安装 use case(`core/application/install.InstallService` 只取已过滤 Catalog entry + architecture，强制注入 disk/storage-failure/target-state checker；`Extractor.ExtractVerifiedFileWithCheck` 在同一普通文件句柄按 size→SHA-256→EOCD/ZIP64→严格 app.json→已规划 payload 的 staging 前预检→安全 staging 的顺序处理，空间要求为 payload+64 MiB，ZIP 输入错误与 staging 创建/write/sync/close 错误分界并保留原始 I/O 链；平台可识别的后者磁盘满返回 `disk_full`，其余输出 I/O 返回稳定 code 且不触发 switch；清理失败可观察，Recover 仅删除已验证 layout 内的残留 staging；每个实际 payload 文件 hash 与受验证 entrypoint/working directory/min_os/requires_admin 写入 installed-app;health 或记录写失败经 Switcher 回滚；更新 current→backup 紧邻前复查精确 entrypoint，明确运行/检测故障保持旧版本并清理 staging),transaction/switch/rollback/recovery 的 journal、rename、清理经统一 fail-closed 耐久栅栏,Windows 使用目录句柄 FlushFileBuffers)、纯 core `application/launch`（只接收 app ID、受控 current/普通 entrypoint/兼容/授权/运行状态/启动器接口全部 fail closed）、双端 Toolhelp 完整映像路径检测/Win7 可用系统版本判断/无参数受控启动与非 Windows fail-closed stub、发布稳定只读 generation 的无 IO 软件列表模型、按 key in-flight + 流式有界读取 + 32 MiB/256-key LRU 的可信图标缓存、图标 Load/Decode 事件发布用例、有界 application event relay,以及默认并发 2 的持久可恢复下载队列;modern/win7 主循环已接 relay/Invalidate,AppShell 已实现搜索/分类/视图、惰性列表、详情右栏、完整图标失败 identity 生命周期与仅 `unsafe_cache` 可见的安全 locator/人工恢复提示,并按 root/header/catalog/detail/style 同 package 镜像职责拆文件
|
||||
- T-402 更新用例:`core/application/update` 只接收外层可信的 install selection，验证已装版本/旧 entrypoint后，运行中才请求关闭确认并以 1 秒～10 分钟上限等待自然退出，随后委托已有 `InstallService` 的双重运行复查与 rollback；取消、超时、Toolhelp 检测错误和安装错误均保留稳定 code/错误链，不强杀且不改 `data/`、`licenses/`。两端 platform 对齐 `WaitForExit` 契约，Windows 固定短轮询完整路径，非 Windows 返回明确不支持。
|
||||
- T-403 自更新:`core/updater` 只接受正 PID、真实 `<root>/app` 与同 root `<root>/staging/<safe-request-id>`，先等待旧 PID 自然退出，随后恢复遗留 journal 或以 `prepared → target_backed_up → staging_activated → launched → committed` 切换；目录 rename、原子 JSON 和目录 durability 均由受限路径与平台同步栅栏保护。助手只启动固定 `<root>/app/SoftBox.exe --softbox-update-health <request-id>`，主程序在 Gio Layout 前从自身 EXE 写最小 health 确认；失败优先恢复旧 app，Windows 锁阻止恢复时保留 backup/journal，不强杀。两端有无 Gio `cmd/softboxupdater`，非 Windows 平台边界 fail closed；没有自更新下载、签名消费、版本选择或 UI 触发器。
|
||||
- 测试:core 覆盖 Catalog 静态 canonicalization/Ed25519 vectors、非法 surrogate/`-0`/Base64 fail-closed、列表快照 generation/零复制、SemVer/12 状态、本地安装记录、Windows dot-space/设备名/Unicode 折叠路径攻击、ZIP destination 包含性与 EOCD/ZIP64 原始包/中央目录/条目数预扫描、T-302/T-303/T-615 同句柄 package size/SHA、严格/有界 app.json、verified payload 预检 hook、容量精确阈值/故障、程序运行/状态故障、稳定安装失败码、staging write/sync/close ENOSPC 与普通输出 I/O 原因保留、CRC 输入分界、清理失败/受控恢复、payload hash 与启动元数据记录、Catalog 选择拒绝、transaction recovery、health/记录写失败回滚、switch 临界区复查、受控启动的旧 metadata/unsafe layout/缺文件/兼容/授权/运行/启动失败、payload/staging tree/journal/rename/rollback/recovery/cleanup 耐久顺序及错误注入、Windows 原生目录 `FlushFileBuffers`、图标并发/取消/读取边界/LRU、真实目录/symlink fail-closed 与 cache→`unsafe_cache` event、relay 背压与关闭、下载并发/暂停/取消/重试/Range/断连/恢复/事件失败与文件身份替换;两个 app 覆盖 Toolhelp snapshot full-path collision/error seam、OS version 判断和非 Windows fail-closed stub，以及 Editor/视图/分类/行/恢复/关闭接线、500 项 viewport、AppID 控件与分类控件生命周期、详情上下文、空状态语义、UI drain 前后、图标失败身份生命周期与 `unsafe_cache` 详情语义;安装恢复矩阵保持通过
|
||||
- 数据:`schemas/` 已有 manifest/app.json/installed-app.json/download-task.json v1 Schema并注明 Windows 路径运行时权威规则;`testdata/catalog/` 有公开虚构清单样例和 v1 静态 canonicalization/Ed25519 corpus;`testdata/zip/` 与 `testdata/download/` 记录运行时生成的攻击/传输矩阵
|
||||
- 标准启动路径:`./init.sh` / `./init.ps1`(同步依赖、执行完整 Phase 0 闸门、打印双目标构建命令)
|
||||
- 标准验证路径:`bash scripts/verify_phase0.sh` / `./scripts/verify_phase0.ps1`
|
||||
- 版本管理:git 已初始化,main 分支,远端 origin 为 Gitea `opc/soft_quay`;harness 文档已提交
|
||||
- 当前 blocker:T-403 已正式落成，当前执行 SoftBoxUpdater 的受限 CLI、主 PID 自然退出、健康确认和可恢复自更新事务。可信自更新包下载/签名、许可证策略与完整端到端 cmd/UI 编排仍未装配；不得为此执行未验证 staging 或伪装自更新闭环。T-614 的外部 `softbox-catalog` 消费 corpus CI 证据仍需跨仓库协调；物理断电、文件锁/杀毒软件干扰仍需 T-601 的目标 Windows VM/真机故障注入
|
||||
- 当前 blocker:可信自更新包下载/签名、版本选择、许可证策略与完整端到端 cmd/UI 编排仍未装配；不得为此执行未验证 staging 或伪装自更新闭环。下一步应按路线图正式落成 Phase 5 的 T-501。T-614 的外部 `softbox-catalog` 消费 corpus CI 证据仍需跨仓库协调；物理断电、文件锁/杀毒软件干扰仍需 T-601 的目标 Windows VM/真机故障注入
|
||||
|
||||
## 当前目录要点
|
||||
|
||||
| 路径 | 状态 | 说明 |
|
||||
| --- | --- | --- |
|
||||
| `docs/` | 已有 | harness coding 文档集(本次初始化完成) |
|
||||
| `docs/tasks/` | 已有 | Phase 0～2、T-301～T-303、T-604～T-615、T-401 与 T-402 已完成;T-403 已正式落成，正在执行 |
|
||||
| `docs/tasks/` | 已有 | Phase 0～2、T-301～T-303、T-604～T-615、T-401～T-403 已完成 |
|
||||
| `scripts/` | 已有 | harness 治理、core 边界、Go 版本检查与 Phase 0 双平台验证入口 |
|
||||
| `core/` | 已建 | Go 1.20 兼容;已有正式 Catalog、本地状态/存储、共享 Windows safepath、列表模型、有界并发图标缓存、图标事件/relay、可恢复下载队列与 Phase 1 安装安全原型 |
|
||||
| `app-modern/` | 已建 | Go 1.25.0 + Gio v0.10.1;Modern AppShell 已接入虚拟列表、详情、图标事件 drain/过期拒绝和内存 ImageOp,并拆为五类 shell 职责文件 |
|
||||
@@ -41,9 +42,8 @@
|
||||
|
||||
任务状态以 `docs/tasks/` 各任务文件 frontmatter 的 `status` 为准。本节只写项目级摘要:
|
||||
|
||||
- 已完成:Phase 0 的 `T-001`～`T-004`;Phase 1 的 `T-101`、`T-102`、`T-103`;Phase 2 的 `T-201`～`T-204`;Phase 3 的 `T-301`～`T-303` 与 `T-615`;审核整改 `T-604`～`T-614`;Phase 4 的 `T-401`、`T-402`。
|
||||
- 正在进行:无。
|
||||
- 正在进行:T-403（依赖 T-402 已完成）；完成、验证并提交后，才可按路线图正式落成 Phase 5 的 T-501。T-601 的物理断电与干扰故障注入仍保留为发布前环境验证。
|
||||
- 已完成:Phase 0 的 `T-001`～`T-004`;Phase 1 的 `T-101`、`T-102`、`T-103`;Phase 2 的 `T-201`～`T-204`;Phase 3 的 `T-301`～`T-303` 与 `T-615`;审核整改 `T-604`～`T-614`;Phase 4 的 `T-401`～`T-403`。
|
||||
- 正在进行:无；下一步可按路线图正式落成 Phase 5 的 T-501。T-601 的物理断电与干扰故障注入仍保留为发布前环境验证。
|
||||
|
||||
## 当前可运行内容
|
||||
|
||||
|
||||
+7
-5
@@ -3,12 +3,12 @@ id: T-403
|
||||
title: SoftBox 自更新助手与健康确认恢复
|
||||
phase: 4
|
||||
deps: [T-402]
|
||||
status: TODO
|
||||
status: DONE
|
||||
created: 2026-07-19
|
||||
issue: null
|
||||
context_ref: null
|
||||
context_ref: 2900deba4f6ea2e442555e52044118d62983fd74
|
||||
claim_branch: null
|
||||
work_branch: null
|
||||
work_branch: agent/codex/T-403
|
||||
write_paths:
|
||||
- docs/tasks/T-403.md
|
||||
- core/updater/
|
||||
@@ -36,10 +36,10 @@ Phase 4 的子软件更新已能在用户关闭子软件后安全委托既有安
|
||||
## 方案
|
||||
|
||||
1. 新建 Go 1.20 兼容的 `core/updater`，固定布局为 `<root>/app`（target）、`<root>/staging/<request-id>`（已由可信外层准备的新目录）、`<root>/backups/<request-id>`、`self-update-transaction.json` 与健康确认文件。请求只接受正主进程 PID、safe request ID、绝对且严格满足该布局的 staging/target；逐项 `Lstat` 拒绝 symlink、非目录、交叉 root、预存 backup/journal 异常，绝不接受 UI/CLI 传入可执行参数或任意移动路径。
|
||||
2. updater 先恢复上次未完成 transaction，再等待原主 PID 自然退出；取消、超时和等待错误均不触碰 target。退出后按 journal 栅栏执行 `prepared → target_backed_up → staging_activated → launched → committed`：只可把 old `app` 改名为本 request 的 backup、把同 root staging 改名为 `app`；每步用临时 JSON + 原子替换并同步目录。任何启动前/启动失败路径尝试恢复 old app；无法恢复时保留可验证 journal/backup，下一次 updater 可恢复，绝不删除 data/licenses。
|
||||
2. updater 先等待原主 PID 自然退出，才恢复上次未完成 transaction；取消、超时和等待错误均不触碰 target。退出后按 journal 栅栏执行 `prepared → target_backed_up → staging_activated → launched → committed`：只可把 old `app` 改名为本 request 的 backup、把同 root staging 改名为 `app`；每步用临时 JSON + 原子替换并同步目录。任何启动前/启动失败路径尝试恢复 old app；无法恢复时保留可验证 journal/backup，下一次 updater 可恢复，绝不删除 data/licenses。
|
||||
3. 新版只能以已验证绝对 `<root>/app/SoftBox.exe`、固定工作目录和内部固定 `--softbox-update-health <request-id>` 参数启动。`SoftBox.exe` 在 Gio Layout 之前（非 UI goroutine I/O）从自己的可执行路径推导同一 root，校验 request ID 和 health locator 后原子写入仅含 request ID 的健康确认；不得接受路径、URL 或任意命令。助手等待匹配确认后才 committed/清理 backup；超时、错误或错误 request ID 均返回稳定失败，保留恢复材料。新版已运行但未确认且 Windows 拒绝 rollback 时 fail closed 留 journal，不强杀；后续受控 updater 在主 PID 退出后恢复。
|
||||
4. 两端 `platform/windows` 增加一致的主 PID 自然退出和固定内部健康启动边界。Windows 以 `OpenProcess(SYNCHRONIZE)` + 可取消的短 `WaitForSingleObject` 轮询实现，不将无权限/不存在 PID 当作“已退出”；启动不经 shell/PATH、只传固定 health flag。非 Windows stub 明确返回不支持。clock/process/launcher seam 覆盖已退出、正常退出、取消、超时、OpenProcess/wait 错误与参数固定性。
|
||||
5. 两端新增无 Gio 的 `cmd/softboxupdater`，严格解析 `--pid`、`--staging`、`--target`（内部 request ID 由助手生成），装配 core/platform 后以非 0 退出失败；主 cmd 只识别内部 health flag 并继续正常启动，不增加用户可传的任意执行入口。验证脚本同时构建主 EXE 和 Updater EXE；文档定义内部健康文件、恢复语义、真实下载/签名未装配事实与 T-601 真机限制。
|
||||
5. 两端新增无 Gio 的 `cmd/softboxupdater`，严格解析 `--pid`、`--staging`、`--target`；request ID 不作为 CLI 参数，而是由受信任预备器创建的规范 `<root>/staging/<request-id>` 目录名确定并被助手重新校验，装配 core/platform 后以非 0 退出失败；主 cmd 只识别内部 health flag 并继续正常启动，不增加用户可传的任意执行入口。验证脚本同时构建主 EXE 和 Updater EXE；文档定义内部健康文件、恢复语义、真实下载/签名未装配事实与 T-601 真机限制。
|
||||
|
||||
## 验收要点
|
||||
|
||||
@@ -65,3 +65,5 @@ Phase 4 的子软件更新已能在用户关闭子软件后安全委托既有安
|
||||
## 执行记录
|
||||
|
||||
- 2026-07-19:正式落成。以 T-402 完成后的 Phase 4 依赖为基线，冻结独立 updater、受限根目录、PID 自然退出、健康确认 journal 和可恢复 rollback 的最小自更新协议；明确可信 self-update 下载/签名、真机故障和发布签名继续后置。
|
||||
- 2026-07-19:领取任务，基于 `2900deba4f6ea2e442555e52044118d62983fd74` 在 `agent/codex/T-403` 执行；先重跑基线，再实现独立 updater 与健康确认。
|
||||
- 2026-07-19:完成。新增 Go 1.20 `core/updater`，固定 `<root>/app`、`staging/<request-id>`、`backups/<request-id>`、原子 transaction/health 文件与可恢复受限 rename；旧 PID 必须自然退出，健康确认必须来自自身 `app/SoftBox.exe` 且匹配已激活 transaction。双端 `platform/windows` 增加 `OpenProcess(SYNCHRONIZE)`/可取消等待、固定无 shell health 启动和目录 durability，non-Windows 明确 fail closed；两个无 Gio `cmd/softboxupdater` 严格处理 CLI，主 cmd 在 Gio Layout 前处理内部 health flag。规格实现前修正了“先恢复再等待 PID”会在旧主程序仍运行时改目录，以及“助手生成 ID”无法对应预备 staging 的矛盾：安全顺序为先等待再恢复，request ID 仅从受信任的规范 staging 目录名派生并复验。可信 self-update 下载/签名、版本选择和 UI 触发未装配。验证通过：`go -C core vet ./...`、`go -C core test -count=1 ./...`、`go -C core test -count=10 ./updater`、两端全包测试与 Windows amd64 的主程序/Updater 构建、`./scripts/verify_phase0.ps1`、`python scripts/validate_agent_context.py`、`python scripts/validate_harness_governance.py`。
|
||||
|
||||
Reference in New Issue
Block a user