sillyspec 3.23.6 → 3.23.8

package/.claude/skills/sillyspec-brainstorm/SKILL.md

@@ -1,86 +1,86 @@
----
-name: sillyspec:brainstorm
-description: 用于正式开始开发前的需求澄清和技术方案设计。适合用户提出新功能、新模块、架构调整、复杂改造，或说"先做需求分析、输出技术方案、创建变更前先梳理、帮我设计下"。产出结构化方案（design/proposal/requirements/tasks 四件套），但不直接写代码。
----
-
-## 交互规范
-
-**当需要用户从多个选项中做出选择时，必须使用 Claude Code 内置的 AskUserQuestion 工具，将选项以参数传入。** 不要用编号列表让用户手动输入数字。
-
-## 何时使用
-
-- 用户提出新功能、新模块、架构调整、复杂改造
-- 用户说"先做需求分析、输出技术方案、创建变更前先梳理、帮我设计下"
-- 产出：`design.md` + `proposal.md` + `requirements.md` + `tasks.md`（四件套），不写代码
-
-## 多变更说明
-
-项目有多个活跃变更（`.sillyspec/changes/` 下有多个目录）时，所有 `sillyspec run` 命令需加 `--change <变更名>` 指定操作目标；只有一个变更时可省略（CLI 自动检测）。建议变更名格式：`YYYY-MM-DD-<简短描述>`。
-
-## 步骤生命周期（所有阶段通用）
-
-> `sillyspec brainstorm` 是 `sillyspec run brainstorm` 的顶层别名，两者等价。
-
-```bash
-sillyspec run brainstorm                       # 输出当前步骤 prompt
-sillyspec run brainstorm --done --output "摘要"     # 完成当前步骤（--input "用户原话" 记录输入）
-sillyspec run brainstorm --status              # 查看阶段进度
-sillyspec run brainstorm --skip                # 跳过可选步骤
-sillyspec run brainstorm --reset               # 重置阶段（从头开始）
-sillyspec run brainstorm --reopen --from-step N     # 重新打开已完成阶段修订（N=序号或名称）
-sillyspec run brainstorm --wait --reason "..." --options "A,B"   # 暂停等用户决策
-sillyspec run brainstorm --continue --answer "..."               # 恢复等待中的步骤
-sillyspec run brainstorm --done --answer "..." --output "..."    # 一步完成 wait+done
-```
-
-## 通用参数（所有阶段适用）
-
-| 参数 | 说明 |
-|---|---|
-| `--change <名>` | 指定变更名（多活跃变更必填，单变更可省略自动检测） |
-| `--spec-dir <path>` | 指定规范目录（默认 `<项目>/.sillyspec`） |
-| `--non-interactive` | CI/脚本下禁用交互式 prompt |
-| `--interactive` | 强制交互（即便 stdin 非 TTY） |
-| `--skip-approval` | 跳过审批/校验门控（需明确意图） |
-| `--json` | 输出 JSON（程序化读取） |
-
-## brainstorm 特有：requiresWait 步骤
-
-某些步骤（如"对话式探索"）需要用户输入。两种方式：
-
-> 自动去重：若前置 step 已对同一问题（waitReason 归一化后相同，如"确认设计方案" vs "最终确认设计方案"）确认过，后续重复 wait 会自动跳过，无需再 `--wait`。
-
-- **方式一（推荐）**：AI 自行与用户交互后，一步完成：
-  ```bash
-  sillyspec run brainstorm --done --change <名> --answer "用户回答" --output "需求已澄清"
-  ```
-- **方式二**：分步——先 `--wait` 记录等待，再 `--continue --answer`，最后 `--done`：
-  ```bash
-  sillyspec run brainstorm --wait --change <名> --reason "等待用户回答" --output "探索问题"
-  sillyspec run brainstorm --continue --answer "用户回答" --change <名>
-  sillyspec run brainstorm --done --change <名> --output "需求已澄清"
-  ```
-
-## 阶段流转
-
-```
-                ┌─ scale=large → plan（四件套齐）
-scan → brainstorm ┤
-                └─ scale=small → quick --linked-changes（仅 design.md）
-```
-
-brainstorm 完成时按 design.md frontmatter 的 `scale` 分叉：
-- **large**（多文件/跨模块/有状态机或 schema 变更）：四件套齐 + 自审通过 → `sillyspec run plan --change <变更名>`
-- **small**（≤2 文件、单模块、无跨模块依赖）：仅生成 design.md → `sillyspec run quick --linked-changes <变更名>`
-
-> 规模由 AI 在 brainstorm 最后一步评估并写入 design.md frontmatter。判错可手动改 `scale` 后再跑相应阶段。
-
-## 铁律
-
-- **必须用 exec 工具（shell）执行 CLI，不要自己编造流程**
-- 只做当前步骤 prompt 描述的操作，不跳过、不自行扩展
-- 产物写入 CLI 输出的 `changeDir` 目录（如 `<changeDir>/design.md`），不要自己拼路径
-- 完成后立即 `--done`，不跳过
-
-## 用户指令
-$ARGUMENTS
+---
+name: sillyspec:brainstorm
+description: 用于正式开始开发前的需求澄清和技术方案设计。适合用户提出新功能、新模块、架构调整、复杂改造，或说"先做需求分析、输出技术方案、创建变更前先梳理、帮我设计下"。产出结构化方案（design/proposal/requirements/tasks 四件套），但不直接写代码。
+---
+
+## 交互规范
+
+**当需要用户从多个选项中做出选择时，必须使用 Claude Code 内置的 AskUserQuestion 工具，将选项以参数传入。** 不要用编号列表让用户手动输入数字。
+
+## 何时使用
+
+- 用户提出新功能、新模块、架构调整、复杂改造
+- 用户说"先做需求分析、输出技术方案、创建变更前先梳理、帮我设计下"
+- 产出：`design.md` + `proposal.md` + `requirements.md` + `tasks.md`（四件套），不写代码
+
+## 多变更说明
+
+项目有多个活跃变更（`.sillyspec/changes/` 下有多个目录）时，所有 `sillyspec run` 命令需加 `--change <变更名>` 指定操作目标；只有一个变更时可省略（CLI 自动检测）。建议变更名格式：`YYYY-MM-DD-<简短描述>`。
+
+## 步骤生命周期（所有阶段通用）
+
+> `sillyspec brainstorm` 是 `sillyspec run brainstorm` 的顶层别名，两者等价。
+
+```bash
+sillyspec run brainstorm                       # 输出当前步骤 prompt
+sillyspec run brainstorm --done --output "摘要"     # 完成当前步骤（--input "用户原话" 记录输入）
+sillyspec run brainstorm --status              # 查看阶段进度
+sillyspec run brainstorm --skip                # 跳过可选步骤
+sillyspec run brainstorm --reset               # 重置阶段（从头开始）
+sillyspec run brainstorm --reopen --from-step N     # 重新打开已完成阶段修订（N=序号或名称）
+sillyspec run brainstorm --wait --reason "..." --options "A,B"   # 暂停等用户决策
+sillyspec run brainstorm --continue --answer "..."               # 恢复等待中的步骤
+sillyspec run brainstorm --done --answer "..." --output "..."    # 一步完成 wait+done
+```
+
+## 通用参数（所有阶段适用）
+
+| 参数 | 说明 |
+|---|---|
+| `--change <名>` | 指定变更名（多活跃变更必填，单变更可省略自动检测） |
+| `--spec-dir <path>` | 指定规范目录（默认 `<项目>/.sillyspec`） |
+| `--non-interactive` | CI/脚本下禁用交互式 prompt |
+| `--interactive` | 强制交互（即便 stdin 非 TTY） |
+| `--skip-approval` | 跳过审批/校验门控（需明确意图） |
+| `--json` | 输出 JSON（程序化读取） |
+
+## brainstorm 特有：requiresWait 步骤
+
+某些步骤（如"对话式探索"）需要用户输入。两种方式：
+
+> 自动去重：若前置 step 已对同一问题（waitReason 归一化后相同，如"确认设计方案" vs "最终确认设计方案"）确认过，后续重复 wait 会自动跳过，无需再 `--wait`。
+
+- **方式一（推荐）**：AI 自行与用户交互后，一步完成：
+  ```bash
+  sillyspec run brainstorm --done --change <名> --answer "用户回答" --output "需求已澄清"
+  ```
+- **方式二**：分步——先 `--wait` 记录等待，再 `--continue --answer`，最后 `--done`：
+  ```bash
+  sillyspec run brainstorm --wait --change <名> --reason "等待用户回答" --output "探索问题"
+  sillyspec run brainstorm --continue --answer "用户回答" --change <名>
+  sillyspec run brainstorm --done --change <名> --output "需求已澄清"
+  ```
+
+## 阶段流转
+
+```
+                ┌─ scale=large → plan（四件套齐）
+scan → brainstorm ┤
+                └─ scale=small → quick --linked-changes（仅 design.md）
+```
+
+brainstorm 完成时按 design.md frontmatter 的 `scale` 分叉：
+- **large**（多文件/跨模块/有状态机或 schema 变更）：四件套齐 + Design Grill 审查通过（tier=independent 时由独立审查子代理产出 stage review.json）→ `sillyspec run plan --change <变更名>`
+- **small**（≤2 文件、单模块、无跨模块依赖）：仅生成 design.md → `sillyspec run quick --linked-changes <变更名>`
+
+> 规模由 AI 在 brainstorm 最后一步评估并写入 design.md frontmatter。判错可手动改 `scale` 后再跑相应阶段。
+
+## 铁律
+
+- **必须用 exec 工具（shell）执行 CLI，不要自己编造流程**
+- 只做当前步骤 prompt 描述的操作，不跳过、不自行扩展
+- 产物写入 CLI 输出的 `changeDir` 目录（如 `<changeDir>/design.md`），不要自己拼路径
+- 完成后立即 `--done`，不跳过
+
+## 用户指令
+$ARGUMENTS

package/.claude/skills/sillyspec-execute/SKILL.md

@@ -43,6 +43,7 @@ sillyspec run execute --reopen --from-step N   # 重新打开已完成阶段修
 - **禁止跳过 worktree 或在主仓库直接写代码**
 - worktree 创建失败时 CLI 报错退出，排查后重试
 - dirty 状态/未提交文件**不影响** worktree 创建和进入，直接按 CLI 输出的路径操作，不要自行检查 git 状态
+- create 时若检测到 base 落后/分叉 `origin/<默认分支>`，CLI 会醒目报告（⚠️「落后 N 个 commit」+ 对齐命令），**不阻断** execute。看到此报告时评估是否提示用户先对齐 main，但**不要自行 fetch/ff**——对齐是用户/主仓库的显式动作
 
 ### 依赖门控（depsStatus）
 

package/.claude/skills/sillyspec-plan/SKILL.md

@@ -1,74 +1,74 @@
----
-name: sillyspec:plan
-description: 用于把 design 拆解为可执行的实现计划。适合用户说"拆任务、做计划、排 wave、规划实现步骤"。产出 plan.md（Wave 分组 + Task 列表 + 依赖关系）。
----
-
-## 何时使用
-
-- 用户说"拆任务、做计划、排 wave、规划实现步骤"
-- 把 brainstorm 的 design.md 拆成可执行的 Wave + Task
-- 产出：`plan.md`（Wave 分组 + Task 列表 + 依赖关系），可能含 `tasks/task-NN.md` 任务蓝图
-
-## 多变更说明
-
-项目有多个活跃变更（`.sillyspec/changes/` 下有多个目录）时，所有 `sillyspec run` 命令需加 `--change <变更名>` 指定操作目标；只有一个变更时可省略（CLI 自动检测）。
-
-## 步骤生命周期（所有阶段通用）
-
-> `sillyspec plan` 是 `sillyspec run plan` 的顶层别名，两者等价。
-
-```bash
-sillyspec run plan                             # 输出当前步骤 prompt
-sillyspec run plan --done --output "摘要"      # 完成当前步骤（--input "用户原话" 记录输入）
-sillyspec run plan --status                    # 查看阶段进度
-sillyspec run plan --skip                      # 跳过可选步骤
-sillyspec run plan --reset                     # 重置阶段（从头开始）
-sillyspec run plan --reopen --from-step N      # 重新打开已完成阶段修订（N=序号或名称）
-sillyspec run plan --wait --reason "..." --options "A,B"   # 暂停等用户决策
-sillyspec run plan --continue --answer "..."               # 恢复等待中的步骤
-sillyspec run plan --done --answer "..." --output "..."    # 一步完成 wait+done
-```
-
-## 通用参数（所有阶段适用）
-
-| 参数 | 说明 |
-|---|---|
-| `--change <名>` | 指定变更名（多活跃变更必填，单变更可省略自动检测） |
-| `--spec-dir <path>` | 指定规范目录（默认 `<项目>/.sillyspec`） |
-| `--non-interactive` | CI/脚本下禁用交互式 prompt |
-| `--interactive` | 强制交互（即便 stdin 非 TTY） |
-| `--skip-approval` | 跳过审批/校验门控（需明确意图） |
-| `--json` | 输出 JSON（程序化读取） |
-
-## plan 特有
-
-### 动态步骤
-
-plan 的步骤是动态的：`generate_plan` 步骤完成后，CLI 会从刚生成的 `plan.md` 解析出 task，自动插入"任务蓝图协调器"步骤（per-task）。这是正常行为，不要手动添加。
-
-### 契约门控（阻断完成）
-
-- **plan 启动前**：CLI 校验 `design.md` 是否满足 plan 契约（缺文件变更清单/风险登记/自审章节会阻断）。若失败需先 `sillyspec run brainstorm --reopen --from-step N` 修订设计。
-- **plan 完成时**：CLI 校验 `plan.md` 是否满足 execute 契约（Wave 结构、task 引用等）。失败会阻断完成，提示修复后重新 `--done`。
-
-### 生产接线路径检查
-
-plan 完成校验会检查：design 提到入口文件（cli.ts/main.ts/server.ts 等）但 task 的 allowed_paths 不含该文件 → 报 error。若确实不需要改入口，在 design.md 明示理由。
-
-## 阶段流转
-
-```
-brainstorm → plan → execute
-```
-
-plan 完成后（plan.md 通过 execute 契约校验），运行 `sillyspec run execute --change <变更名>` 开始实现。
-
-## 铁律
-
-- **必须用 exec 工具（shell）执行 CLI，不要自己编造流程**
-- 只做当前步骤 prompt 描述的操作，不跳过、不自行扩展
-- plan.md 是任务完成的唯一真相源，task 拆解粒度要均匀、依赖要明确
-- 完成后立即 `--done`，不跳过
-
-## 用户指令
-$ARGUMENTS
+---
+name: sillyspec:plan
+description: 用于把 design 拆解为可执行的实现计划。适合用户说"拆任务、做计划、排 wave、规划实现步骤"。产出 plan.md（Wave 分组 + Task 列表 + 依赖关系）。
+---
+
+## 何时使用
+
+- 用户说"拆任务、做计划、排 wave、规划实现步骤"
+- 把 brainstorm 的 design.md 拆成可执行的 Wave + Task
+- 产出：`plan.md`（Wave 分组 + Task 列表 + 依赖关系），可能含 `tasks/task-NN.md` 任务蓝图
+
+## 多变更说明
+
+项目有多个活跃变更（`.sillyspec/changes/` 下有多个目录）时，所有 `sillyspec run` 命令需加 `--change <变更名>` 指定操作目标；只有一个变更时可省略（CLI 自动检测）。
+
+## 步骤生命周期（所有阶段通用）
+
+> `sillyspec plan` 是 `sillyspec run plan` 的顶层别名，两者等价。
+
+```bash
+sillyspec run plan                             # 输出当前步骤 prompt
+sillyspec run plan --done --output "摘要"      # 完成当前步骤（--input "用户原话" 记录输入）
+sillyspec run plan --status                    # 查看阶段进度
+sillyspec run plan --skip                      # 跳过可选步骤
+sillyspec run plan --reset                     # 重置阶段（从头开始）
+sillyspec run plan --reopen --from-step N      # 重新打开已完成阶段修订（N=序号或名称）
+sillyspec run plan --wait --reason "..." --options "A,B"   # 暂停等用户决策
+sillyspec run plan --continue --answer "..."               # 恢复等待中的步骤
+sillyspec run plan --done --answer "..." --output "..."    # 一步完成 wait+done
+```
+
+## 通用参数（所有阶段适用）
+
+| 参数 | 说明 |
+|---|---|
+| `--change <名>` | 指定变更名（多活跃变更必填，单变更可省略自动检测） |
+| `--spec-dir <path>` | 指定规范目录（默认 `<项目>/.sillyspec`） |
+| `--non-interactive` | CI/脚本下禁用交互式 prompt |
+| `--interactive` | 强制交互（即便 stdin 非 TTY） |
+| `--skip-approval` | 跳过审批/校验门控（需明确意图） |
+| `--json` | 输出 JSON（程序化读取） |
+
+## plan 特有
+
+### 动态步骤
+
+plan 的步骤是动态的：`generate_plan`（生成分级计划）→ `review_plan`（审查计划，按规模分级：tier=self 当前 agent 自审 / tier=independent 启动独立审查子代理产出 stage review.json，避免生成+自审同一次输出的偏差）→ CLI 从 `plan.md` 解析出 task 自动插入"任务蓝图协调器"步骤（per-task）。这是正常行为，不要手动添加。
+
+### 契约门控（阻断完成）
+
+- **plan 启动前**：CLI 校验 `design.md` 是否满足 plan 契约（缺文件变更清单/风险登记/自审章节会阻断）。若失败需先 `sillyspec run brainstorm --reopen --from-step N` 修订设计。
+- **plan 完成时**：CLI 校验 `plan.md` 是否满足 execute 契约（Wave 结构、task 引用等）。失败会阻断完成，提示修复后重新 `--done`。
+
+### 生产接线路径检查
+
+plan 完成校验会检查：design 提到入口文件（cli.ts/main.ts/server.ts 等）但 task 的 allowed_paths 不含该文件 → 报 error。若确实不需要改入口，在 design.md 明示理由。
+
+## 阶段流转
+
+```
+brainstorm → plan → execute
+```
+
+plan 完成后（plan.md 通过 execute 契约校验），运行 `sillyspec run execute --change <变更名>` 开始实现。
+
+## 铁律
+
+- **必须用 exec 工具（shell）执行 CLI，不要自己编造流程**
+- 只做当前步骤 prompt 描述的操作，不跳过、不自行扩展
+- plan.md 是任务完成的唯一真相源，task 拆解粒度要均匀、依赖要明确
+- 完成后立即 `--done`，不跳过
+
+## 用户指令
+$ARGUMENTS

package/.claude/skills/sillyspec-propose/SKILL.md

@@ -1,61 +1,61 @@
----
-name: sillyspec:propose
-description: 生成结构化规范 — proposal + design + tasks。适合用户说"生成规范、补全四件套、propose"。产出 proposal.md + design.md + tasks.md（+ 可能的 requirements.md）。
----
-
-## 何时使用
-
-- 用户说"生成规范、补全四件套、propose"
-- 已有零散设计/需求，需补全结构化规范四件套
-- 产出：`proposal.md` + `design.md` + `tasks.md`（+ 可选 `requirements.md`）
-
-> 注：propose 与 brainstorm 都产出四件套。brainstorm 是从需求开始的完整设计流程；propose 更偏"补全/生成规范"。新需求一般走 brainstorm。
-
-## 多变更说明
-
-项目有多个活跃变更（`.sillyspec/changes/` 下有多个目录）时，所有 `sillyspec run` 命令需加 `--change <变更名>` 指定操作目标；只有一个变更时可省略（CLI 自动检测）。
-
-## 步骤生命周期（所有阶段通用）
-
-> `sillyspec run propose` 需用 `run` 形式（propose 无顶层别名，与 brainstorm/plan 等不同）。
-
-```bash
-sillyspec run propose                          # 输出当前步骤 prompt
-sillyspec run propose --done --output "摘要"   # 完成当前步骤
-sillyspec run propose --status                 # 查看阶段进度
-sillyspec run propose --skip                   # 跳过可选步骤
-sillyspec run propose --reset                  # 重置阶段（从头开始）
-sillyspec run propose --reopen --from-step N   # 重新打开已完成阶段修订
-```
-
-## 通用参数（所有阶段适用）
-
-| 参数 | 说明 |
-|---|---|
-| `--change <名>` | 指定变更名（多活跃变更必填，单变更可省略自动检测） |
-| `--spec-dir <path>` | 指定规范目录（默认 `<项目>/.sillyspec`） |
-| `--non-interactive` | CI/脚本下禁用交互式 prompt |
-| `--skip-approval` | 跳过审批/校验门控 |
-| `--json` | 输出 JSON（程序化读取） |
-
-## propose 特有：自检门控
-
-propose 含自检步骤，完成时校验四件套文档齐全 + 内容章节（如 proposal 的 Non-Goals、design 的文件变更清单/风险登记/自审）。缺失会阻断完成。
-
-## 阶段流转
-
-```
-(零散设计/需求) → propose → plan
-```
-
-propose 完成后（四件套齐 + 自检通过），运行 `sillyspec run plan --change <变更名>` 进入实现计划。
-
-## 铁律
-
-- **必须用 exec 工具（shell）执行 CLI，不要自己编造流程**
-- 只做当前步骤 prompt 描述的操作，不跳过
-- 产物写入 CLI 输出的 `changeDir` 目录
-- 完成后立即 `--done`，不跳过
-
-## 用户指令
-$ARGUMENTS
+---
+name: sillyspec:propose
+description: 生成结构化规范 — proposal + design + tasks。适合用户说"生成规范、补全四件套、propose"。产出 proposal.md + design.md + tasks.md（+ 可能的 requirements.md）。
+---
+
+## 何时使用
+
+- 用户说"生成规范、补全四件套、propose"
+- 已有零散设计/需求，需补全结构化规范四件套
+- 产出：`proposal.md` + `design.md` + `tasks.md`（+ 可选 `requirements.md`）
+
+> 注：propose 与 brainstorm 都产出四件套。brainstorm 是从需求开始的完整设计流程；propose 更偏"补全/生成规范"。新需求一般走 brainstorm。
+
+## 多变更说明
+
+项目有多个活跃变更（`.sillyspec/changes/` 下有多个目录）时，所有 `sillyspec run` 命令需加 `--change <变更名>` 指定操作目标；只有一个变更时可省略（CLI 自动检测）。
+
+## 步骤生命周期（所有阶段通用）
+
+> `sillyspec run propose` 需用 `run` 形式（propose 无顶层别名，与 brainstorm/plan 等不同）。
+
+```bash
+sillyspec run propose                          # 输出当前步骤 prompt
+sillyspec run propose --done --output "摘要"   # 完成当前步骤
+sillyspec run propose --status                 # 查看阶段进度
+sillyspec run propose --skip                   # 跳过可选步骤
+sillyspec run propose --reset                  # 重置阶段（从头开始）
+sillyspec run propose --reopen --from-step N   # 重新打开已完成阶段修订
+```
+
+## 通用参数（所有阶段适用）
+
+| 参数 | 说明 |
+|---|---|
+| `--change <名>` | 指定变更名（多活跃变更必填，单变更可省略自动检测） |
+| `--spec-dir <path>` | 指定规范目录（默认 `<项目>/.sillyspec`） |
+| `--non-interactive` | CI/脚本下禁用交互式 prompt |
+| `--skip-approval` | 跳过审批/校验门控 |
+| `--json` | 输出 JSON（程序化读取） |
+
+## propose 特有：自检门控
+
+propose 含自检步骤（按规模分级：tier=self 当前 agent 自审 / tier=independent 启动独立审查子代理产出 stage review.json），完成时校验四件套文档齐全 + 内容章节（如 proposal 的 Non-Goals、design 的文件变更清单/风险登记/自审）。缺失会阻断完成。
+
+## 阶段流转
+
+```
+(零散设计/需求) → propose → plan
+```
+
+propose 完成后（四件套齐 + 自检通过），运行 `sillyspec run plan --change <变更名>` 进入实现计划。
+
+## 铁律
+
+- **必须用 exec 工具（shell）执行 CLI，不要自己编造流程**
+- 只做当前步骤 prompt 描述的操作，不跳过
+- 产物写入 CLI 输出的 `changeDir` 目录
+- 完成后立即 `--done`，不跳过
+
+## 用户指令
+$ARGUMENTS

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "sillyspec",
-  "version": "3.23.6",
+  "version": "3.23.8",
   "description": "SillySpec CLI — 流程状态机，让 AI 严格按步骤来",
   "icon": "logo.jpg",
   "homepage": "https://sillyspec.ppdmq.top/",

package/src/db.js

@@ -83,7 +83,7 @@ export class DB {
       CREATE TABLE IF NOT EXISTS project (
         id INTEGER PRIMARY KEY DEFAULT 1,
         name TEXT NOT NULL,
-        schema_version INTEGER DEFAULT 4,
+        schema_version INTEGER DEFAULT 3,
         created_at TEXT NOT NULL,
         updated_at TEXT NOT NULL
       )

package/src/progress.js

@@ -4,8 +4,7 @@
  * 纯 Node.js，无外部依赖。支持多变更并行。
  *
  * 存储结构：
- *   .sillyspec/.runtime/sillyspec.db          — SQLite 数据库（权威状态源）
- *   .sillyspec/.runtime/global.json           — 全局状态缓存（项目名、活跃变更列表）
+ *   .sillyspec/.runtime/sillyspec.db          — SQLite 数据库（权威状态源，含全局状态/项目名/活跃变更）
  *   .sillyspec/.runtime/gate-status.json      — worktree-guard 门禁状态缓存
  *
  * 历史迁移：v1/v2 使用 progress.json 文件，v3 已全部迁移至 SQLite。
@@ -103,7 +102,6 @@ export function resolvePlatformSpecDir(cwd, explicitSpecDir = null) {
 }
 
 const CHANGES_SUBDIR = 'changes';
-const GLOBAL_FILE = 'global.json';
 const CURRENT_VERSION = 3;
 const VALID_STAGES = ['scan', 'brainstorm', 'plan', 'execute', 'verify', 'archive', 'quick', 'explore'];
 const VALID_STATUSES = ['pending', 'in-progress', 'completed', 'failed', 'blocked', 'waiting', 'stale'];

package/src/review-tier.js

@@ -0,0 +1,65 @@
+/**
+ * SillySpec Review Tier — 审查分级
+ *
+ * 决定某阶段的"审查/自检"由「当前 agent 自审」还是「独立审查子代理」执行。
+ *
+ * 为什么需要分级：
+ *   scanProfile（决定 maxAgentCalls / 是否禁子代理）只在 scan 阶段生效（run.js:810
+ *   门控 stageName==='scan'）；change-risk-profile 的 P0/P1/P2 只管 apply 阻塞与
+ *   verify 证据。两者都不约束 brainstorm/plan/execute/propose 的审查方式。
+ *   故新选「plan_level / 变更文件数」作为审查分级维度。
+ *
+ * 分级结果：
+ *   - tier=self         → 当前 agent 自审，CLI 放行（不要求 review.json）
+ *   - tier=independent  → 强制独立审查子代理 + review.json，CLI 硬校验
+ *
+ * CLI 侧（run.js done gate）与 prompt 注入侧用同一个函数，保证两边判定一致——
+ * 不信 agent 自报 tier。
+ */
+
+import { parseFileChangeList } from './change-list.js'
+
+/**
+ * 审查分级阈值：变更文件数 ≤ 此值 → tier=self。
+ * 依据：≤3 文件的变更通常是单点修复/文案调整，独立审查子代理的仪式成本 > 收益。
+ */
+export const SELF_REVIEW_FILE_THRESHOLD = 3
+
+/**
+ * 审查分级
+ *
+ * 判定顺序（短路）：
+ *   1. plan_level === 'none'                          → self（极小变更）
+ *   2. design.md 变更文件数 ≤ SELF_REVIEW_FILE_THRESHOLD → self
+ *   3. 否则                                            → independent
+ *
+ * fail-safe：designPath 传了但解析不到文件清单（fileCount=0）按字面 0 处理（真无文件
+ * 变更 = 极小）；designPath 完全没传（fileCount=null，无法证明规模）→ independent
+ * （宁严勿松）。
+ *
+ * @param {object} [opts]
+ * @param {string} [opts.planLevel] - plan_level 分类结果（none/light/full）。brainstorm/propose 在 plan 之前，可能拿不到。
+ * @param {string} [opts.designPath] - design.md 绝对路径，用于算变更文件数
+ * @returns {{ tier: 'self'|'independent', reason: string, fileCount: number|null }}
+ */
+export function classifyReviewTier({ planLevel, designPath } = {}) {
+  if (planLevel === 'none') {
+    return { tier: 'self', reason: `plan_level=none（极小变更，≤${SELF_REVIEW_FILE_THRESHOLD} 文件等价）`, fileCount: null }
+  }
+
+  let fileCount = null
+  if (designPath) {
+    fileCount = parseFileChangeList(designPath).size
+  }
+
+  if (fileCount !== null && fileCount <= SELF_REVIEW_FILE_THRESHOLD) {
+    return { tier: 'self', reason: `变更文件 ${fileCount} ≤ ${SELF_REVIEW_FILE_THRESHOLD}`, fileCount }
+  }
+
+  const reason = fileCount === null
+    ? (planLevel
+        ? `plan_level=${planLevel}，无法解析变更文件数，按正常规模处理`
+        : '无法解析 design.md 变更文件清单，按正常规模处理')
+    : `变更文件 ${fileCount} > ${SELF_REVIEW_FILE_THRESHOLD}`
+  return { tier: 'independent', reason, fileCount }
+}