sillyspec 3.20.6 → 3.21.0

package/docs/sillyspec/file-lifecycle/worktree-and-guard.md

@@ -1,211 +0,0 @@
----
-author: qinyi
-created_at: 2026-06-04 16:25:42
-updated_at: 2026-06-28
----
-
-# Worktree 与 Hook 门禁
-
-## 命令入口
-
-`src/index.js` 暴露：
-
-```text
-sillyspec worktree create <change-name> [--base <branch>]
-sillyspec worktree apply <change-name> [--check-only]
-sillyspec worktree list
-sillyspec worktree cleanup <change-name>
-```
-
-实现分别调用：
-
-- `WorktreeManager.create()`
-- `applyWorktree()`
-- `WorktreeManager.list()`
-- `WorktreeManager.cleanup()`
-
-## `create`
-
-默认路径：
-
-```text
-.sillyspec/.runtime/worktrees/<change-name>/
-```
-
-默认分支：
-
-```text
-sillyspec/<change-name>
-```
-
-关键校验与分支：
-
-1. `changeName` 不能为空，不能包含 `..`、`/`、`\`。
-2. 如果当前目录是 git submodule，直接报错。
-3. 如果当前目录已经是 linked worktree，创建 `native-worktree` meta，复用当前目录。
-4. 普通主工作区必须先确认 `.sillyspec/.runtime/worktrees` 被 `.gitignore` 忽略，否则报错。
-5. 如果 worktree 目录存在但没有 `meta.json`，视为幽灵目录并自动删除。
-6. 如果目标 branch 已存在，报错。
-7. 默认 base 是当前 `HEAD`；传 `--base` 时使用指定 ref。
-8. `git worktree add` 失败时：
-   - 如果 git 版本低于 2.15 或不可用，报错。
-   - 其他失败降级为 `in-place-fallback`，在主工作区记录 meta。
-9. 创建普通 worktree 后，会 best-effort `fetch origin` 并尝试 fast-forward 到默认远端分支。
-10. 主工作区已有 staged/unstaged/untracked 变更时，会 overlay 到 worktree，并创建 baseline checkpoint commit。
-11. **依赖供给**（change `2026-06-28-worktree-deps-provision`）：baseline overlay 后调用 `provisionDeps(worktreePath, mainCwd)`（`src/worktree-deps.js`）——lockfile 一致时 junction/symlink 主 checkout 的 `node_modules`（瞬时零网络），否则按 `local.yaml` 的 `project.type` + lockfile 推断并执行 install。结果写入 meta（`depsStatus` 等字段）。**供给失败不阻断 create**，只记 `depsStatus=failed`，交由 execute 验证硬门阻断。
-
-## `meta.json`
-
-普通 worktree 的 `meta.json` 位于 worktree 目录内：
-
-```text
-.sillyspec/.runtime/worktrees/<change>/meta.json
-```
-
-`native-worktree` 和 `in-place-fallback` 下，meta 仍写到 `.sillyspec/.runtime/worktrees/<change>/meta.json`，其中 `worktreePath` 可能指向当前工作目录。
-
-主要字段：
-
-| 字段 | 说明 |
-|---|---|
-| `changeName` | 变更名 |
-| `branch` | worktree 分支 |
-| `baseBranch` | 基准分支或 ref |
-| `baseHash` | 创建时基准 commit |
-| `actualBaseHash` | worktree 当前 HEAD |
-| `createdAt` | 创建时间 |
-| `worktreePath` | 实际执行目录 |
-| `mode` | `worktree` / `native-worktree` / `in-place-fallback` |
-| `baselineFiles` | 从主工作区 overlay 的未提交文件 |
-| `baselineCommit` | baseline checkpoint commit |
-| `baselineHash` | execute 前主工作区 dirty baseline hash |
-| `depsStatus` | 依赖供给状态：`linked` / `installed` / `n/a` / `failed` / `missing` / `stale`（provisionDeps 写入） |
-| `depsMethod` | 供给机制：`junction` / `symlink` / `install` / `null` |
-| `depsSource` | 依赖来源：`main-checkout` / `install` / `null` |
-| `depsLockHash` | 供给时 lockfile/package.json 的 sha256 前 16 位 |
-| `depsCheckedAt` | 上次供给时间（ISO8601） |
-| `depsError` | 仅 `depsStatus=failed` 时填，install/junction 失败信息 |
-
-## `apply`
-
-`applyWorktree(changeName, { checkOnly })` 的真实流程：
-
-1. 读取 `meta.json`。
-2. diff base 使用 `baselineCommit || baseHash`。
-3. 收集 tracked diff 和 untracked 新文件。
-4. 从 `.sillyspec/changes/<change>/design.md` 解析“文件变更清单”作为 allow list。
-5. 如果 allow list 非空，要求 changed files 都在清单内。
-6. 如果 meta 有 `baselineHash`，重新计算主工作区 dirty hash；不同则拒绝 apply。
-7. 检查主工作区和 apply 文件有无未提交冲突。
-8. 比较主工作区 `HEAD` 与 worktree `baseHash` 的目标文件 blob。
-9. `--check-only` 到这里返回。
-10. 生成临时 patch。
-11. 在主工作区执行 `git apply --check`。
-12. 执行 `git apply --3way`。
-13. 成功后自动调用 `WorktreeManager.cleanup()`。
-
-无变更时，如果不是 check-only，也会 cleanup。
-
-## `cleanup`
-
-`cleanup(changeName, { force })`：
-
-| mode | 非 force 行为 |
-|---|---|
-| `worktree` | 尝试 `git worktree remove --force`，删除目录，删除分支，删除 meta 目录 |
-| `native-worktree` | 抛错，避免删除用户自己的 worktree |
-| `in-place-fallback` | 返回 `skipped` |
-| 无 meta 且目录不存在 | 返回 `skipped` |
-
-如果 `git worktree remove` 失败但目录可删，结果是 `force-cleaned`。
-
-## execute 阶段
-
-`execute.js` 的固定前缀第 3 步是“创建 worktree”，prompt 要求运行：
-
-```text
-sillyspec worktree create <change-name>
-```
-
-后续 Wave prompt 要求把子代理 cwd 设置为 worktree 路径。完成确认 step 根据 mode 分别处理：
-
-- `worktree`：check-only，用户确认后 apply，再 cleanup。
-- `native-worktree`：可以 apply，但不要 cleanup。
-- `in-place-fallback`：跳过 apply/cleanup。
-- 无 worktree：只展示 diff 摘要。
-
-注意：`buildExecuteSteps()` 有 `noWorktree` 参数，但当前 `runCommand()` 没有解析 `--no-worktree` flag，CLI help 也没有列出该 flag。文档不要把 `--no-worktree` 写成已接通的公开流程。
-
-### execute 依赖验证硬门（change `2026-06-28-worktree-deps-provision`）
-
-`run.js completeStep` 在 execute 分支标记 step done **之前**调用 `enforceDepsGate()`：
-
-1. 读 `meta.depsStatus`：∈ `{linked, installed, n/a}` 放行。
-2. 否则判断 wave 级 opt-out（`isCurrentWaveAllNoDepsVerify`）：仅当前 wave（如 `Wave 2 执行`）内**全部** task 的 `tasks/task-NN.md` frontmatter `no_deps_verify: true` 才跳门。非 wave 步骤（确认执行范围/acceptance/suffix）恒过门。
-3. 不达标 → step 置 `blocked` + `process.exit(1)` 拒绝 `--done`，提示 `sillyspec worktree doctor --fix` 或手动 install。
-
-execute **入口自检**：已存在 worktree（`create()` short-circuit 不供给）时，入口校验 `depsStatus` 缺失 / `node_modules` 丢失（missing）/ `lockfileHash` 变化（stale）→ 触发 `provisionDeps` 重供给并更新 meta，再交门判定。
-
-## quick 阶段
-
-quick 当前不创建 worktree。
-
-`quick.js` 第 2 步明确写的是“直接在主工作区实现任务”。`worktree-guard.js` 在 stage 为 `quick` 时，对 Write/Edit/MultiEdit 直接放行；Bash 仅拦截危险命令。quick 作为辅助阶段完成后，`run.js` 会重置 quick 步骤并清空 `currentStage`，从而删除 gate 状态。
-
-因此旧文档中“quick 创建 worktree/meta.json”的描述不符合当前代码。
-
-## Hook 门禁
-
-入口：`src/hooks/claude-pre-tool-use.cjs`
-
-输入：Claude Code PreToolUse hook 的 JSON。它只映射这些工具：
-
-- `Write`
-- `Edit`
-- `MultiEdit`
-- `Bash`
-
-实际判断：`src/hooks/worktree-guard.js`
-
-### 文件白名单
-
-以下写入直接放行：
-
-- 路径中包含 `.sillyspec`，但 `.sillyspec/.runtime/worktrees/` 例外
-- 路径中包含 `.git`
-- 扩展名为 `.md`
-- 文件名为 `package.json`、`tsconfig.json`、`local.yaml`、`local.yml`
-
-`.sillyspec/.runtime/worktrees/` 下的写入不会仅因路径包含 `.sillyspec` 而放行；它必须命中当前 gate 中 active change 对应的 `meta.json.worktreePath`。
-
-### 阶段门禁
-
-阶段读取顺序：
-
-1. `.sillyspec/.runtime/gate-status.json`
-2. `sqlite3` CLI 查询 `.sillyspec/.runtime/sillyspec.db`
-
-只有 `execute` 和 `quick` 被视为允许源码写入的阶段。
-
-### execute 写入
-
-execute 阶段的源码写入必须位于已登记 worktree 内：
-
-1. hook 读取 `.sillyspec/.runtime/gate-status.json` 或 SQLite，得到当前 active changes。
-2. 对每个 active change 读取 `.sillyspec/.runtime/worktrees/<change>/meta.json`。
-3. 只有目标路径位于 `meta.json.worktreePath` 内时才允许写入。
-
-这意味着随便构造一个包含 `.sillyspec/.runtime/worktrees/` 字符串的路径不会被放行。主工作区写源码仍会被拦截。
-
-### quick 写入
-
-quick 阶段写文件直接放行，不要求 worktree。
-
-### Bash 命令
-
-- 已登记 worktree 内 cwd：全部 Bash 放行。
-- 非 execute/quick：只读白名单放行。
-- quick：危险黑名单拦截，其余放行。
-- execute 主工作区：危险黑名单拦截；只读白名单放行；其他不确定命令当前放行。
-
-`worktree-guard.js` 的本地扩展白名单优先读取 `.sillyspec/local.yaml` / `.sillyspec/local.yml`，并兼容项目根 `local.yaml` / `local.yml`。

package/docs/sillyspec/file-lifecycle.md

@@ -1,132 +0,0 @@
----
-author: qinyi
-created_at: 2026-05-31 11:00:00
-updated_at: 2026-07-02 11:00:00
----
-
-# SillySpec 文件生命周期
-
-> 本文档按当前代码重写。它描述的是仓库里已经实现或运行时会暴露的行为，不描述期望设计。
-
-## 文档拆分
-
-| 文件 | 说明 |
-|---|---|
-| [storage-and-state.md](file-lifecycle/storage-and-state.md) | `.sillyspec/.runtime/`、SQLite、gate、artifact、history、local 配置口径 |
-| [stage-artifacts.md](file-lifecycle/stage-artifacts.md) | 各阶段的运行时步骤、变更目录产物、归档和 quicklog |
-| [worktree-and-guard.md](file-lifecycle/worktree-and-guard.md) | `sillyspec worktree`、`meta.json`、apply、cleanup、Claude hook 门禁 |
-| [platform-workflows-sync.md](file-lifecycle/platform-workflows-sync.md) | 平台模式、workflow check、manifest、SillyHub sync |
-| [known-implementation-gaps.md](file-lifecycle/known-implementation-gaps.md) | 当前代码与提示文案/旧文档不一致的地方 |
-
-## 代码依据
-
-本组文档主要对照以下实现：
-
-- `src/init.js`
-- `src/db.js`
-- `src/scan-postcheck.js`
-- `src/knowledge-match.js`
-- `src/progress.js`
-- `src/run.js`
-- `src/stages/*.js`
-- `src/worktree.js`
-- `src/worktree-apply.js`
-- `src/hooks/worktree-guard.js`
-- `src/workflow.js`
-- `src/sync.js`
-- `src/modules.js`
-- `src/index.js`
-
-运行时阶段列表以导入 `src/stages/index.js` 后得到的对象为准。当前导入结果：
-
-| 阶段 | 当前步骤数 | 备注 |
-|---|---:|---|
-| scan | 11 | 辅助阶段；step 2 后会按项目动态展开 `perProject` 步骤；第 10 步「Extract Project Knowledge」写入 `knowledge/` |
-| brainstorm | 11 | 独立包含“写设计文档并自审”和“用户确认并生成规范文件” |
-| propose | 7 | 包含“生成规范文件”与“自检门控”，四件套是该阶段预期产物 |
-| plan | 动态 | 默认 8 步；`plan.md` 解析到任务后插入任务蓝图协调器 |
-| execute | 动态 | 默认 12 步；Wave 来自 `plan.md`，解析失败时默认 3 个 Wave |
-| verify | 7 | 只读校验 + 写 `verify-result.md` |
-| archive | 5 | 辅助阶段；第 4 步必须带 `--confirm`，由 `run.js` 移动目录并注销 active change |
-| quick | 3 | 辅助阶段；直接在主工作区实现，不创建 worktree |
-| explore | 1 | 只读探索 |
-| status | 3 | 状态展示 |
-| doctor | 5 | 环境和项目自检 |
-
-## 顶层目录口径
-
-当前 `sillyspec init` 会创建或维护以下目录：
-
-| 路径 | tracked | 创建/维护方 | 当前生命周期 |
-|---|---|---|---|
-| `.sillyspec/projects/` | 是 | `init.js`、scan prompt 人工确认后 | 项目注册表，`*.yaml` 描述项目名、路径、状态 |
-| `.sillyspec/docs/<project>/scan/` | 是 | `init.js` 建目录；scan 阶段生成文档 | 代码扫描产物，workflow `scan-docs` 会检查 |
-| `.sillyspec/docs/<project>/modules/` | 是 | scan 可选步骤、archive sync、`modules` 子命令 | 模块索引和模块卡片 |
-| `.sillyspec/changes/<change>/` | 是 | `ProgressManager.initChange()` 确保目录；阶段 prompt 写入 | 单个变更包文档和验收产物 |
-| `.sillyspec/changes/archive/` | 是 | archive `确认归档 --confirm` 分支 | 已归档变更目录 |
-| `.sillyspec/knowledge/` | 是 | `init.js` 建目录；scan「Extract Project Knowledge」步骤产出 | `INDEX.md`、`uncategorized.md`，以及 scan 提取的 `conventions.md`/`patterns.md`/`known-issues.md` |
-| `.sillyspec/workflows/` | 是 | `init.js` 从模板复制 | workflow check 定义 |
-| `.sillyspec/quicklog/` | 是 | quick prompt | 每次 quick 任务记录（始终写入；关联变更另在各 change tasks.md 勾选） |
-| `.sillyspec/shared/` | 是 | `init.js` | 共享目录，当前无核心生命周期逻辑 |
-| `.sillyspec/workspace/` | 是 | `init.js` | 工作区目录，当前无核心生命周期逻辑 |
-| `.sillyspec/.runtime/` | 否 | `init.js`、`ProgressManager`、运行时命令 | DB、gate、artifacts、history、workflow-runs、worktrees、knowledge-hit-report.json、postcheck-result.json |
-
-`init.js` 会把 `.sillyspec/.runtime/`、`.sillyspec/local.yaml`、`.sillyspec/codebase/SCAN-RAW.md` 追加到 `.gitignore`。
-
-> **平台模式残留清理边界**（`init.js` `cleanupRuntimeResidue`，由 `run.js` 启动时首次执行一次）：
-> 当 `specRoot` 指向外部、源码目录的 `.sillyspec/` 含真实资产（`changes/`/`projects/`/`sillyspec.db`）时，只清理运行时残留，**不整删 `.runtime/`**。清理白名单保留权威状态：`worktrees/`、`sillyspec.db`、`global.json`、`gate-status.json`、`contract-artifacts/`、`execute-runs/`；其余子项（`artifacts/`、`scan-runs/`、`scan-projects.json`、`user-inputs.md`、`postcheck-result.json` 等可重建缓存）逐项删除，`local.yaml`、`codebase/` 整删。未知子项默认保留（安全侧倾斜）。
-> 该清理在 `run.js` 启动时**仅执行一次**：首次处理后写 cwd 根的 `.sillyspec-platform-cleaned` 标记文件，后续每次 `run` 直接跳过。旧版每次启动都打印 `❌ 拒绝删除` 红叉属误导性噪声（清理既不阻塞流程也不动真实资产），已降为 `ℹ️` 一次性提示。
-
-## 主要文件流
-
-```text
-sillyspec init
-  -> .sillyspec/projects/<project>.yaml
-  -> .sillyspec/docs/<project>/scan/.gitkeep
-  -> .sillyspec/workflows/*.yaml
-  -> .sillyspec/knowledge/{INDEX.md,uncategorized.md}
-  -> .sillyspec/.runtime/{sillyspec.db,user-inputs.md,artifacts,history,logs,templates}
-
-sillyspec run scan
-  -> .sillyspec/docs/<project>/scan/*.md
-  -> .sillyspec/docs/<project>/modules/_module-map.yaml      (optional prompt)
-  -> .sillyspec/docs/<project>/modules/<module>.md           (optional prompt)
-  -> .sillyspec/knowledge/{conventions,patterns,known-issues}.md  (Extract Project Knowledge)
-  -> .sillyspec/knowledge/INDEX.md                           (索引更新)
-  -> .sillyspec/.runtime/scan-projects.json                  (step expansion state)
-  -> .sillyspec/.runtime/postcheck-result.json              (scan-postcheck 结构化结果)
-
-brainstorm / propose / plan / execute / verify / archive
-  -> .sillyspec/changes/<change>/...
-  -> .sillyspec/.runtime/sillyspec.db
-  -> .sillyspec/.runtime/user-inputs.md
-  -> .sillyspec/.runtime/artifacts/*.txt                     (long step output)
-
-execute
-  -> .sillyspec/.runtime/worktrees/<change>/meta.json
-  -> .sillyspec/.runtime/knowledge-hit-report.json           (启动时按 taskContext 匹配 knowledge)
-  -> worktree branch sillyspec/<change>
-  -> apply patch back to main workspace, then cleanup
-
-quick
-  -> .sillyspec/quicklog/QUICKLOG-<git-user>.md              (without --change)
-  -> or append checkbox to .sillyspec/changes/<change>/tasks.md
-  -> code changes are made in the main workspace
-```
-
-## 核心修正
-
-这版文档相对旧版长文档做了几项关键修正：
-
-- `quick` 不走 worktree 生命周期。hook 在 quick 阶段对写文件放行，只拦截危险 Bash 命令。
-- `scan` 当前定义是 10 步，并且 step 2 后会动态展开项目级步骤，不是固定 12 步。
-- `brainstorm` 和 `propose` 的重复 object key 已拆成独立步骤，运行时步骤数分别是 11 和 7。
-- `.sillyspec/local.yaml` 是当前主配置口径；scan prompt 写这里，sync 读写这里，hook 优先读这里并兼容根目录 fallback。
-- 平台模式的 `manifest.json` 已接入 scan 完成回调；`workflow-runs` 的 runtimeRoot 路径支持在 `workflow.js` 中存在，但 `run.js` 当前调用没有传入 `runtimeRoot`。
-- `archive` 的目录移动已经由 `run.js` 在第 4 步 `--confirm` 时执行；未带 `--confirm` 会回退该步骤并提示补参。
-- scan 第 10 步「Extract Project Knowledge」把长期有效的项目知识写入 `.sillyspec/knowledge/`（`conventions.md`/`patterns.md`/`known-issues.md` + 更新 `INDEX.md`）；`scan-postcheck.js` 校验产物（INDEX.md 存在、引用文件真实存在）。
-- execute 启动时由 `knowledge-match.js` 按 plan.md 的 task 关键词匹配知识库，命中报告注入 prompt 并写 `.runtime/knowledge-hit-report.json`。
-- 平台模式残留清理只删缓存、保留权威状态（`worktrees/`、`sillyspec.db`、`global.json`、`gate-status.json`、`contract-artifacts/`、`execute-runs/`），不再整删 `.runtime/`——否则 worktree meta 被清掉会导致 `depsStatus` 恒为 unknown、`branch already exists` 死循环、`worktree doctor` orphan 误判。
-- plan→execute Contract 校验（`parseWavesFromPlan`）只解析 `## Wave N` 段内的 `- [ ] task-XX:` 行；遇到非 Wave 标题行（`## 自检` 等）即退出当前 Wave 段，避免自检 `- [x]` checkbox 被误当 task 定义。
-- `executePlanPostcheck` 的 `resolveChangeDir` 复用 `run.js` 模块内本地函数，不从 `./modules.js` 导入（该模块未导出此函数）。
-- Revision v1：`stages` 表新增 `revision`/`reopened_from_step`/`reopened_at`/`stale_reason` 列；阶段新增 `revising`/`stale` 状态；`sillyspec run <stage> --reopen --from-step <n>` 重开已完成阶段、级联标记下游 stale；`.runtime/postcheck-result.json` 由 `scan-postcheck.js` 的 `writeStructuredResult` 落盘（本地写 `specDir/.runtime`，平台写 `runtimeRoot/scan-runs/<id>`）。

package/docs/workflow-contract-regression.md

@@ -1,106 +0,0 @@
-# Workflow Contract Regression Audit
-
-> 日期：2026-06-19  
-> 范围：16 commits (f52e670..977ad0a)  
-> 结论：**全绿，0 bug，274 个断言全部通过**
-
-## 审计目标
-
-确认今晚 16 个 commit 引入的 contract/revision/stale safety 改动没有误伤现有主链路。
-
-## 审计范围
-
-### 新增功能
-1. **Revision v1** — 阶段重开 + 步骤级修订控制
-2. **Revision v1.1** — 可观测性与状态自检
-3. **Revision v1.2** — progress repair 安全修复状态元数据
-4. **Execute stale safety v1** — 防止基于旧 plan 继续执行
-5. **Verify/Archive stale safety** — 8 个测试固化安全链
-6. **Plan→Execute contract v1** — 校验 + 文档 + 测试
-7. **Plan postcheck contract v1** — plan 完成时校验 execute 契约
-8. **Brainstorm→Plan contract v1** — design.md 输入校验
-
-### 新增契约链
-
-```
-brainstorm → design.md → [Design Contract 校验] → plan → plan.md → [Plan Contract 校验] → execute
-```
-
-- **brainstorm → plan**: `validateDesignForPlan` — 3 error + 3 warning
-- **plan → execute**: `validatePlanForExecute` — 5 error + 1 warning
-- 双重校验：plan 完成时 + execute 启动时
-
-### 新增 Stale Cascade 链
-
-```
-scan → brainstorm → plan → execute → verify → archive
-```
-
-- `checkConsistency` 基于 STAGE_ORDER 遍历上游，自动发现下游假完成
-- `repair` cascade：execute stale → verify/archive stale → verify stale → archive stale
-
-## 测试执行
-
-### 命令
-```bash
-cd ~/Desktop/sillyspec && npm test
-```
-
-### 测试套件 (15 个，274 断言)
-
-| 测试套件 | 断言数 | 状态 |
-|---------|-------|------|
-| brainstorm-plan-contract.test.mjs | 11 | ✅ |
-| plan-execute-contract.test.mjs | 12 | ✅ |
-| platform-artifacts.test.mjs | 31 | ✅ |
-| platform-failure-samples.test.mjs | 20 | ✅ |
-| platform-recovery-chain.test.mjs | 15 | ✅ |
-| platform-recovery.test.mjs | 19 | ✅ |
-| platform-scan-p0.test.mjs | 19 | ✅ |
-| revision-v1.test.mjs | 12 | ✅ |
-| scan-paths.test.mjs | 38 | ✅ |
-| scan-postcheck.test.mjs | 38 | ✅ |
-| spec-dir.test.mjs | 15 | ✅ |
-| stage-contract.test.mjs | 19 | ✅ |
-| stage-definitions.test.mjs | 29 | ✅ |
-| wait-gates.test.mjs | 15 | ✅ |
-| worktree-guard.test.mjs | (included) | ✅ |
-
-**总计：15 套件，274 断言，0 失败。**
-
-## 主链路验收
-
-### 1. 完整主链路 (scan → brainstorm → plan → execute → verify)
-- ✅ stage-contract.test.mjs 覆盖了各阶段的校验与转换
-- ✅ stage-definitions.test.mjs 覆盖了所有阶段定义的步骤初始化
-- ✅ 无 contract 误伤
-
-### 2. Plan 级别验收 (none/light/full)
-- ✅ plan-execute-contract.test.mjs 覆盖 none/light/full
-- ✅ plan postcheck 在 plan completion path 执行
-- ✅ execute startup 二次校验保留
-
-### 3. Revision 链路
-- ✅ revision-v1.test.mjs 覆盖 reopen/repair/checkConsistency
-- ✅ verify/archive --reopen 清除旧 completed steps
-- ✅ execute --reopen 重新解析最新 plan.md
-- ✅ repair cascade execute → verify → archive
-
-### 4. Progress check/repair
-- ✅ 正常状态无误报
-- ✅ 异常状态报告清晰（checkConsistency 输出 upstream/downstream 关系）
-- ✅ repair 只修 progress 元数据，不改产物文件
-
-## 发现
-
-**0 bug。** 274 个断言全部通过，无回归。
-
-### 设计确认
-- checkConsistency 和 repair 基于 STAGE_ORDER 通用遍历，不针对特定 stage
-- verify/archive 用静态 steps，不需要从文件重解析
-- contract validator 只在阶段边界执行，不影响阶段内步骤流转
-- repair cascade 是自然结果，不需要硬编码 stage 间关系
-
-## 文件变更统计
-
-16 commits, 28 files changed, +3675/-689 lines。