2 Commits

Include renames

Author	SHA1	Message	Date
jkooe	9baf3b0443	fix(cli): rollback 指纹校验容忍 12/64 位两种口径 ... QA 独立验证路由的 P0 缺陷（tests/unit/qa-v210-supplement.test.mjs C⑦ 红）： - 写后校验（rollback.ts:462）：back.hash 是 64 位流式 sha256，而老 LKG 记录的 expectHash 只有 12 位（无 hash_full）→ 严格 === 必不成立 → 老记录回滚永远 被判「写后校验失败」并用回滚源还原，向后兼容路径实际不可用。 - 重启复核（rollback.ts:519）：新 LKG 记录带 hash_full（64 位）时，p.buildHash 是 12 位 → 严格 === 必不成立 → 回滚其实成功却被误报「90s 内未复核到回滚版本」 并以退出码 1 结束（--backup 逃生门同样命中此缺陷）。 修法：新增纯函数 hashMatchesEither（短的一方是长的一方前缀即命中），仅用于 「校验/复核」方向；挑回滚源仍用单向 hashMatches —— hash_full 在手时不许前缀 糊弄（C⑥ 钉死），两条语义各有其守卫。 README 单测数 476 → 477（新增 hashMatchesEither 用例，docs-numbers 守卫强制耦合）。	2026-10-26 21:00:26 +08:00
jkooe	6b2fa29710	feat(cli): nodeagent rollback —— 从 LKG 回滚被控端（ARCH T03 / PRD P0-2） ... - 新增 apps/cli/src/cmd/rollback.ts：读 LKG → 指纹比对定位备份 → 覆盖写入口（同 deploy 姿势）→ 写后校验（失败用回滚源还原）→ 受控重启 → probeOnce 复核 build.hash == LKG（90s 墙钟） - 纯函数 planRollback/pickBackupByHash/hashMatches/backupNameRegex + 流式 hashRemoteFile（client 注入，可假测）；hash_full 全量优先、 老记录回落 12 位前缀（A-P0-3/R-2 向后兼容） - --dry-run 只读零写；--backup 逃生门直指备份路径；退出码 0/1/2 分明 - HELP/README 写明能力圈边界：RPC 命令需被控端可达，「完全起不来」 走看门狗自动恢复或带外恢复；不提供自动回滚（DELIVERY-PIPELINE §6） - 19 条单测：无 LKG 零调用 / already-lkg 零写 / 写后校验失败自动还原 / 无匹配零写 / dry-run 只读 / 多候选 mtime 新→早 / Windows 路径与元字符	2026-10-25 23:45:02 +08:00