sillyspec 3.28.3 → 3.28.5

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

@@ -1,156 +1,156 @@
----
-name: sillyspec:plan
-description: 用于把 design 拆解为可执行的实现计划。适合用户说"拆任务、做计划、排 wave、规划实现步骤"。产出 plan.md（Wave 分组 + 任务 ID 引用 + 依赖关系）+ tasks.md 任务清单（唯一真相，plan 阶段展开写回）。
----
-
-## 何时使用
-
-- 用户说"拆任务、做计划、排 wave、规划实现步骤"
-- 把 brainstorm 的 design.md 拆成可执行的 Wave + Task
-- 产出：`plan.md`（Wave 分组 + 任务 ID 引用行 + 依赖关系）+ `tasks.md` 任务清单展开写回（唯一真相）+ `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` | 跳过阶段转换/审批检查（不能跳产物校验 gate——review.json/文档产物硬校验仍在） |
-
-## plan 特有
-
-### 动态步骤
-
-plan 的步骤是动态的：`generate_plan`（生成分级计划）→ `review_plan`（审查计划，按规模分级：tier=self 当前 agent 自审 / tier=independent 启动独立审查子代理产出 stage review.json，避免生成+自审同一次输出的偏差）→ CLI 从 `tasks.md` 注册表解析出 task 自动插入"任务蓝图协调器"步骤（per-task；plan.md 只提供 Wave 引用分组）。这是正常行为，不要手动添加。
-
-### Stage Review Gate（plan 的 design review.json）
-
-`review_plan` 步骤在 `tier=independent` 时产出一个 stage 级 `review.json`，CLI `Stage Review Gate` 硬校验其 schema 与 `docHash` 真实性。
-
-- 路径：`.sillyspec/.runtime/stage-reviews/plan-review-<stage-review-run-id>/review.json`（目录可能不存在需手建；run-id 由该步 `--done` prompt 输出指定）。marker 文件 `.runtime/current-stage-review-run-id-plan-<变更名>`。
-- **run-id / marker 由 CLI 自动生成注入**（review step prompt 渲染时 echo 完整目录路径 + 写 marker；撞 gate 报缺 review.json 时 gate 也 echo 完整路径 + 写 marker）。直接用 CLI 给的路径写 review.json，**勿手算 run-id（必须 `review-` 前缀）、勿手写 marker**。卡住时用 `sillyspec register-stage-review --change <名> --stage plan` 一步生成。
-- 字段（`schemaVersion:1`，`reviewType=plan` —— plan 阶段主审查文档是 `plan.md`；execute 阶段才是 `acceptance`）：
-
-  ```json
-  {
-    "schemaVersion": 1,
-    "reviewType": "plan",
-    "reviewedFiles": ["changes/<变更名>/plan.md"],   // [0] 为主文档
-    "docHash": "<sha256(reviewedFiles[0] 文件内容，hex)>",
-    "specVerdict": "pass",       // pass | fail | cannot_verify
-    "qualityVerdict": "pass",    // pass | fail | cannot_verify
-    "checklist": [               // 扁平数组，逐条对照 plan 章节/Wave 结构/task 完整性核验
-      { "item": "Wave 分级合理", "result": "pass", "note": "..." }   // result: pass | gap | fail
-    ],
-    "requiredEvidence": [],      // cannot_verify 时必填非空
-    "reviewerNotes": "..."
-  }
-  ```
-
-- `docHash` = `sha256(主审查文档内容)`（hex）—— plan 主文档是 `plan.md`（`reviewedFiles[0]`）。CLI 重算 sha256 比对，不符判伪造（fail-closed）。docHash 可先占位（如 "TODO"）；改 plan.md 后勿手算 sha256——跑 `sillyspec register-stage-review --change <变更名> --stage plan --refresh-hash` 一键重算代填（verdict 保留；多阶段联动加 --all）。忘跑也不会被拦：gate 检测到「仅 docHash 失配」时自动机械重算放行（verdict 保留 + 审计行留痕）；schema/verdict 错误照常 fail-closed。`tier=self`（≤3 文件）降级为当前 agent 自审。
-- 运行时 CLI 会把精确 schema 表 + 完整 JSON 示例 + docHash 算法注入到该步 prompt，以你实际收到的注入版契约为权威逐字模板。
-
-### 契约门控（阻断完成）
-
-- **plan 启动前**：CLI 校验 `design.md` 是否满足 plan 契约（缺文件变更清单/风险登记/自审章节会阻断）。若失败需先 `sillyspec run brainstorm --reopen --from-step N` 修订设计。
-- **plan 完成时**：CLI 校验 `tasks.md`（任务注册表）× `plan.md`（Wave ID 引用）是否满足 execute 契约（引用存在性/覆盖恰一次/编号连续/旧格式拦）。失败会阻断完成，提示修复后重新 `--done`。
-
-### 生产接线路径检查
-
-plan 完成校验会检查：design 提到入口文件（cli.ts/main.ts/server.ts 等）但 task 的 allowed_paths 不含该文件 → 报 error。若确实不需要改入口，在 design.md 明示理由。
-
-## 跨仓 task 卡片协议（一个 change 改多个仓库）
-
-单个 change 的 task 可以分散到主仓 + 多个跨仓仓实现（典型场景：dogfood 自指、monorepo 多包仓、共享库 + 调用方联合改造）。**单仓 change 不需要任何跨仓配置**（所有 task 不写 `repo:` 即走原流程，零回归）。
-
-### 跨仓 task 卡片字段
-
-在 `tasks/task-NN.md` frontmatter 加：
-
-- `repo: <key>`（可选，缺省='main'=主仓 task）：task 所属仓的 key。key 必须在 `.sillyspec/local.yaml` `repos:` 段注册（`main` 隐式=主仓不用注册）。跨仓 change 缺注册 → execute 启动 fail-closed 阻断。
-- `allowed_paths`：跨仓 task 时指**相对跨仓仓根**的路径（非主仓根）。例如跨仓 task 改 `sillyspec` 仓的 `src/foo.js`，allowed_paths 写 `src/foo.js`（相对 sillyspec 仓根），不是 `../sillyspec/src/foo.js`。
-- `base_commit` / `head_commit`：**不要手写**——CLI 在 execute 派发/回收时自动落盘双锡点（锁 base/head 防 diff 漂移），plan 阶段不写。
-
-### local.yaml `repos:` 段（跨仓注册表）
-
-> 📍 `local.yaml` 恒在 `.sillyspec/local.yaml`——项目根目录**没有**这个文件，别去那里找或新建（hook 会拦）。worktree 内该文件不随 checkout 出现，读配置直接跑 `sillyspec config cat`（自动定位到主仓真实配置）；可用键清单见 `sillyspec config schema`。
-
-跨仓 change 的每个 repo key 都要注册（execute 启动 fail-closed 校验）。**用命令注册，勿手编 YAML**：
-
-```
-sillyspec local register-repo <key> <跨仓仓根路径>
-```
-
-（外科手术式写入，只动 `repos:` 段，其余内容保留；execute 启动报缺注册时，报错文案里就带这条命令。）手写格式参考：
-
-```yaml
-repos:
-  shared-lib: ../shared-lib
-  tool-repo: C:/path/to/your/tool-repo
-```
-
-key = task 卡 `repo:` 引用名，value = 跨仓仓绝对路径（或相对主仓根的路径）。`main` 不用注册。
-
-### design.md 文件变更清单按仓分段
-
-跨仓 change 的 `## 文件变更清单` 段须按仓分段，段头格式 `## <repo> 仓变更`（主仓段头可省略或写 `## main 仓变更`）：
-
-```markdown
-## 文件变更清单
-
-### sillyspec 仓变更
-| 操作 | 文件路径 | 说明 |
-|---|---|---|
-| 修改 | src/task-review.js | 跨仓 task 改的文件 |
-
-### main 仓变更
-| 操作 | 文件路径 | 说明 |
-|---|---|---|
-| 修改 | src/index.js | 主仓 task 改的文件 |
-```
-
-plan 完成校验会按仓分段对账：跨仓仓路径相对跨仓仓根校验 task allowed_paths 覆盖，主仓路径相对主仓根校验。跨仓 task 与主仓 task 同名物理路径分属不同 repo 不判冲突。
-
-### Wave 划分
-
-同 Wave 内允许混合主仓 + 跨仓 task（execute 按 per-task workdir 派发，不强制同 Wave 同 repo）。共享文件的 task 仍须分到不同 Wave（同 Wave 共享文件会被强制并行，子代理互相覆盖）。
-
-## 阶段流转
-
-```
-brainstorm → plan → execute
-```
-
-plan 完成后（plan.md 通过 execute 契约校验），运行 `sillyspec run execute --change <变更名>` 开始实现。
-
-## 铁律
-
-- **必须用 exec 工具（shell）执行 CLI，不要自己编造流程**
-- 只做当前步骤 prompt 描述的操作，不跳过、不自行扩展
-- tasks.md 是任务清单唯一真相（checkbox 注册表，plan 阶段展开写回——保留 ql-xxx 等非 task-XX 行）；plan.md Wave 段只写纯 ID 引用行（`- task-XX`），不重抄任务名
-- 完成后立即 `--done`，不跳过
-
-## 用户指令
-$ARGUMENTS
+---
+name: sillyspec:plan
+description: 用于把 design 拆解为可执行的实现计划。适合用户说"拆任务、做计划、排 wave、规划实现步骤"。产出 plan.md（Wave 分组 + 任务 ID 引用 + 依赖关系）+ tasks.md 任务清单（唯一真相，plan 阶段展开写回）。
+---
+
+## 何时使用
+
+- 用户说"拆任务、做计划、排 wave、规划实现步骤"
+- 把 brainstorm 的 design.md 拆成可执行的 Wave + Task
+- 产出：`plan.md`（Wave 分组 + 任务 ID 引用行 + 依赖关系）+ `tasks.md` 任务清单展开写回（唯一真相）+ `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` | 跳过阶段转换/审批检查（不能跳产物校验 gate——review.json/文档产物硬校验仍在） |
+
+## plan 特有
+
+### 动态步骤
+
+plan 的步骤是动态的：`generate_plan`（生成分级计划）→ `review_plan`（审查计划，按规模分级：tier=self 当前 agent 自审 / tier=independent 启动独立审查子代理产出 stage review.json，避免生成+自审同一次输出的偏差）→ CLI 从 `tasks.md` 注册表解析出 task 自动插入"任务蓝图协调器"步骤（per-task；plan.md 只提供 Wave 引用分组）。这是正常行为，不要手动添加。
+
+### Stage Review Gate（plan 的 design review.json）
+
+`review_plan` 步骤在 `tier=independent` 时产出一个 stage 级 `review.json`，CLI `Stage Review Gate` 硬校验其 schema 与 `docHash` 真实性。
+
+- 路径：`.sillyspec/.runtime/stage-reviews/plan-review-<stage-review-run-id>/review.json`（目录可能不存在需手建；run-id 由该步 `--done` prompt 输出指定）。marker 文件 `.runtime/current-stage-review-run-id-plan-<变更名>`。
+- **run-id / marker 由 CLI 自动生成注入**（review step prompt 渲染时 echo 完整目录路径 + 写 marker；撞 gate 报缺 review.json 时 gate 也 echo 完整路径 + 写 marker）。直接用 CLI 给的路径写 review.json，**勿手算 run-id（必须 `review-` 前缀）、勿手写 marker**。卡住时用 `sillyspec register-stage-review --change <名> --stage plan` 一步生成。
+- 字段（`schemaVersion:1`，`reviewType=plan` —— plan 阶段主审查文档是 `plan.md`；execute 阶段才是 `acceptance`）：
+
+  ```json
+  {
+    "schemaVersion": 1,
+    "reviewType": "plan",
+    "reviewedFiles": ["changes/<变更名>/plan.md"],   // [0] 为主文档
+    "docHash": "<sha256(reviewedFiles[0] 文件内容，hex)>",
+    "specVerdict": "pass",       // pass | fail | cannot_verify
+    "qualityVerdict": "pass",    // pass | fail | cannot_verify
+    "checklist": [               // 扁平数组，逐条对照 plan 章节/Wave 结构/task 完整性核验
+      { "item": "Wave 分级合理", "result": "pass", "note": "..." }   // result: pass | gap | fail
+    ],
+    "requiredEvidence": [],      // cannot_verify 时必填非空
+    "reviewerNotes": "..."
+  }
+  ```
+
+- `docHash` = `sha256(主审查文档内容)`（hex）—— plan 主文档是 `plan.md`（`reviewedFiles[0]`）。CLI 重算 sha256 比对，不符判伪造（fail-closed）。docHash 可先占位（如 "TODO"）；改 plan.md 后勿手算 sha256——跑 `sillyspec register-stage-review --change <变更名> --stage plan --refresh-hash` 一键重算代填（verdict 保留；多阶段联动加 --all）。忘跑也不会被拦：gate 检测到「仅 docHash 失配」时自动机械重算放行（verdict 保留 + 审计行留痕）；schema/verdict 错误照常 fail-closed。`tier=self`（≤3 文件）降级为当前 agent 自审。
+- 运行时 CLI 会把精确 schema 表 + 完整 JSON 示例 + docHash 算法注入到该步 prompt，以你实际收到的注入版契约为权威逐字模板。
+
+### 契约门控（阻断完成）
+
+- **plan 启动前**：CLI 校验 `design.md` 是否满足 plan 契约（缺文件变更清单/风险登记/自审章节会阻断）。若失败需先 `sillyspec run brainstorm --reopen --from-step N` 修订设计。
+- **plan 完成时**：CLI 校验 `tasks.md`（任务注册表）× `plan.md`（Wave ID 引用）是否满足 execute 契约（引用存在性/覆盖恰一次/编号连续/旧格式拦）。失败会阻断完成，提示修复后重新 `--done`。
+
+### 生产接线路径检查
+
+plan 完成校验会检查：design 提到入口文件（cli.ts/main.ts/server.ts 等）但 task 的 allowed_paths 不含该文件 → 报 error。若确实不需要改入口，在 design.md 明示理由。
+
+## 跨仓 task 卡片协议（一个 change 改多个仓库）
+
+单个 change 的 task 可以分散到主仓 + 多个跨仓仓实现（典型场景：dogfood 自指、monorepo 多包仓、共享库 + 调用方联合改造）。**单仓 change 不需要任何跨仓配置**（所有 task 不写 `repo:` 即走原流程，零回归）。
+
+### 跨仓 task 卡片字段
+
+在 `tasks/task-NN.md` frontmatter 加：
+
+- `repo: <key>`（可选，缺省='main'=主仓 task）：task 所属仓的 key。key 必须在 `.sillyspec/local.yaml` `repos:` 段注册（`main` 隐式=主仓不用注册）。跨仓 change 缺注册 → execute 启动 fail-closed 阻断。
+- `allowed_paths`：跨仓 task 时指**相对跨仓仓根**的路径（非主仓根）。例如跨仓 task 改 `sillyspec` 仓的 `src/foo.js`，allowed_paths 写 `src/foo.js`（相对 sillyspec 仓根），不是 `../sillyspec/src/foo.js`。
+- `base_commit` / `head_commit`：**不要手写**——CLI 在 execute 派发/回收时自动落盘双锡点（锁 base/head 防 diff 漂移），plan 阶段不写。
+
+### local.yaml `repos:` 段（跨仓注册表）
+
+> 📍 `local.yaml` 恒在 `.sillyspec/local.yaml`——项目根目录**没有**这个文件，别去那里找或新建（hook 会拦）。worktree 内该文件不随 checkout 出现，读配置直接跑 `sillyspec config cat`（自动定位到主仓真实配置）；可用键清单见 `sillyspec config schema`。
+
+跨仓 change 的每个 repo key 都要注册（execute 启动 fail-closed 校验）。**用命令注册，勿手编 YAML**：
+
+```
+sillyspec local register-repo <key> <跨仓仓根路径>
+```
+
+（外科手术式写入，只动 `repos:` 段，其余内容保留；execute 启动报缺注册时，报错文案里就带这条命令。）手写格式参考：
+
+```yaml
+repos:
+  shared-lib: ../shared-lib
+  tool-repo: C:/path/to/your/tool-repo
+```
+
+key = task 卡 `repo:` 引用名，value = 跨仓仓绝对路径（或相对主仓根的路径）。`main` 不用注册。
+
+### design.md 文件变更清单按仓分段
+
+跨仓 change 的 `## 文件变更清单` 段须按仓分段，段头格式 `## <repo> 仓变更`（主仓段头可省略或写 `## main 仓变更`）：
+
+```markdown
+## 文件变更清单
+
+### sillyspec 仓变更
+| 操作 | 文件路径 | 说明 |
+|---|---|---|
+| 修改 | src/task-review.js | 跨仓 task 改的文件 |
+
+### main 仓变更
+| 操作 | 文件路径 | 说明 |
+|---|---|---|
+| 修改 | src/index.js | 主仓 task 改的文件 |
+```
+
+plan 完成校验会按仓分段对账：跨仓仓路径相对跨仓仓根校验 task allowed_paths 覆盖，主仓路径相对主仓根校验。跨仓 task 与主仓 task 同名物理路径分属不同 repo 不判冲突。
+
+### Wave 划分
+
+同 Wave 内允许混合主仓 + 跨仓 task（execute 按 per-task workdir 派发，不强制同 Wave 同 repo）。共享文件的 task 仍须分到不同 Wave（同 Wave 共享文件会被强制并行，子代理互相覆盖）。
+
+## 阶段流转
+
+```
+brainstorm → plan → execute
+```
+
+plan 完成后（plan.md 通过 execute 契约校验），运行 `sillyspec run execute --change <变更名>` 开始实现。
+
+## 铁律
+
+- **必须用 exec 工具（shell）执行 CLI，不要自己编造流程**
+- 只做当前步骤 prompt 描述的操作，不跳过、不自行扩展
+- tasks.md 是任务清单唯一真相（checkbox 注册表，plan 阶段展开写回——保留 ql-xxx 等非 task-XX 行）；plan.md Wave 段只写纯 ID 引用行（`- task-XX`），不重抄任务名
+- 完成后立即 `--done`，不跳过
+
+## 用户指令
+$ARGUMENTS

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

@@ -1,16 +1,16 @@
----
-name: sillyspec:propose
-description: 已废弃重定向 — 生成结构化规范四件套请直接走 brainstorm。适合用户说"生成规范、补全四件套、propose"——一律转用 /sillyspec:brainstorm。
----
-
-## propose 阶段已废弃（重定向到 brainstorm）
-
-`propose` 阶段已从 CLI 移除（`src/stages/propose.js` 标注 @deprecated 且未注册进 stageRegistry）——**`sillyspec run propose` 不存在**（报「未知阶段: propose」）。本 skill 只保留触发词重定向，没有任何 propose 专属流程，勿尝试执行任何 `run propose` 命令。
-
-用户说"生成规范 / 补全四件套 / propose"时，**直接执行 `/sillyspec:brainstorm`**：
-
-- brainstorm 产出同一套四件套（`proposal.md` + `design.md` + `requirements.md` + `tasks.md`），且含需求澄清与 Design Grill 审查
-- 「已有零散设计只需补全」与「新需求从零设计」在 brainstorm 内同流程处理——若用户明确要求跳过澄清，在对话探索步骤直接说明「需求已明确」尽早推进即可
-
-## 用户指令
-$ARGUMENTS
+---
+name: sillyspec:propose
+description: 已废弃重定向 — 生成结构化规范四件套请直接走 brainstorm。适合用户说"生成规范、补全四件套、propose"——一律转用 /sillyspec:brainstorm。
+---
+
+## propose 阶段已废弃（重定向到 brainstorm）
+
+`propose` 阶段已从 CLI 移除（`src/stages/propose.js` 标注 @deprecated 且未注册进 stageRegistry）——**`sillyspec run propose` 不存在**（报「未知阶段: propose」）。本 skill 只保留触发词重定向，没有任何 propose 专属流程，勿尝试执行任何 `run propose` 命令。
+
+用户说"生成规范 / 补全四件套 / propose"时，**直接执行 `/sillyspec:brainstorm`**：
+
+- brainstorm 产出同一套四件套（`proposal.md` + `design.md` + `requirements.md` + `tasks.md`），且含需求澄清与 Design Grill 审查
+- 「已有零散设计只需补全」与「新需求从零设计」在 brainstorm 内同流程处理——若用户明确要求跳过澄清，在对话探索步骤直接说明「需求已明确」尽早推进即可
+
+## 用户指令
+$ARGUMENTS

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

@@ -1,21 +1,21 @@
----
-name: sillyspec:resume
-description: 恢复工作 — 从中断处继续
----
-
-## 交互规范
-
-**当需要用户从多个选项中做出选择时，必须使用 Claude Code 内置的 AskUserQuestion 工具，将选项传入。** 不要用编号列表让用户手动输入数字。需要自由输入时在选项中加入"Other（自定义输入）"。
-
-## 流程
-
-1. **读进度**：跑 `sillyspec progress show`。
-2. **有活跃变更**：把当前状态（变更/阶段/步骤）转述给用户，用 AskUserQuestion 问「直接继续执行下一步 / 查看更多细节」。
-3. **无活跃变更**：跑 `sillyspec next`——CLI 已内置全套探测（文件存在性 → 推断阶段 → 建议命令 + 依据），按输出转述并执行建议命令。勿自行 ls/cat 重算（输出与实际不符时才手工核对）。
-
-## 关键原则
-
-- 进度存 SQLite（`.sillyspec/.runtime/sillyspec.db`），随 `sillyspec run <stage> --done` 自动更新，不需要手动保存、不需要从中途状态"恢复文件"——直接续跑即可。
-
-## 用户指令
-$ARGUMENTS
+---
+name: sillyspec:resume
+description: 恢复工作 — 从中断处继续
+---
+
+## 交互规范
+
+**当需要用户从多个选项中做出选择时，必须使用 Claude Code 内置的 AskUserQuestion 工具，将选项传入。** 不要用编号列表让用户手动输入数字。需要自由输入时在选项中加入"Other（自定义输入）"。
+
+## 流程
+
+1. **读进度**：跑 `sillyspec progress show`。
+2. **有活跃变更**：把当前状态（变更/阶段/步骤）转述给用户，用 AskUserQuestion 问「直接继续执行下一步 / 查看更多细节」。
+3. **无活跃变更**：跑 `sillyspec next`——CLI 已内置全套探测（文件存在性 → 推断阶段 → 建议命令 + 依据），按输出转述并执行建议命令。勿自行 ls/cat 重算（输出与实际不符时才手工核对）。
+
+## 关键原则
+
+- 进度存 SQLite（`.sillyspec/.runtime/sillyspec.db`），随 `sillyspec run <stage> --done` 自动更新，不需要手动保存、不需要从中途状态"恢复文件"——直接续跑即可。
+
+## 用户指令
+$ARGUMENTS

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

@@ -1,25 +1,25 @@
----
-name: sillyspec:state
-description: 查看当前工作状态 — 显示 SillySpec 进度
----
-
-## 流程
-
-跑 `sillyspec progress show [--change <名>]`，把 CLI 输出**原样转述**给用户即可——输出本身已是成品格式（变更/阶段/最近活跃/未决冲突/滞留信号/下一步建议），勿再按自备模板重排。
-
-- 多活跃变更时输出为汇总表；需要单变更细节加 `--change <名>`。
-- 输出「没有活跃的变更」时，提示用户：新项目 `/sillyspec:init`、已有项目 `/sillyspec:scan`、恢复中断 `/sillyspec:resume`。
-
-## progress 只读子命令（诊断用）
-
-```bash
-sillyspec progress check                   # 状态一致性检查（只报告，不修复）
-sillyspec progress repair                  # 修复状态元数据（dry-run，加 --apply 才真改）
-sillyspec progress validate                # 校验并修复
-sillyspec progress reset [--stage <阶段>]  # 重置进度（破坏性，慎用）
-```
-
-- `/sillyspec:status` 看项目整体进度（change 文件级别）；`/sillyspec:state` 看当前工作状态（阶段/步骤级别）——status 看"有什么"，state 看"在做什么"。
-
-## 用户指令
-$ARGUMENTS
+---
+name: sillyspec:state
+description: 查看当前工作状态 — 显示 SillySpec 进度
+---
+
+## 流程
+
+跑 `sillyspec progress show [--change <名>]`，把 CLI 输出**原样转述**给用户即可——输出本身已是成品格式（变更/阶段/最近活跃/未决冲突/滞留信号/下一步建议），勿再按自备模板重排。
+
+- 多活跃变更时输出为汇总表；需要单变更细节加 `--change <名>`。
+- 输出「没有活跃的变更」时，提示用户：新项目 `/sillyspec:init`、已有项目 `/sillyspec:scan`、恢复中断 `/sillyspec:resume`。
+
+## progress 只读子命令（诊断用）
+
+```bash
+sillyspec progress check                   # 状态一致性检查（只报告，不修复）
+sillyspec progress repair                  # 修复状态元数据（dry-run，加 --apply 才真改）
+sillyspec progress validate                # 校验并修复
+sillyspec progress reset [--stage <阶段>]  # 重置进度（破坏性，慎用）
+```
+
+- `/sillyspec:status` 看项目整体进度（change 文件级别）；`/sillyspec:state` 看当前工作状态（阶段/步骤级别）——status 看"有什么"，state 看"在做什么"。
+
+## 用户指令
+$ARGUMENTS

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

@@ -1,33 +1,33 @@
----
-name: sillyspec:workspace
-description: 工作区管理 — 初始化、管理多项目工作区，查看子项目状态
----
-
-## 交互规范
-
-**当需要用户从多个选项中做出选择时，必须使用 Claude Code 内置的 AskUserQuestion 工具，将选项以参数传入。** 不要用编号列表让用户手动输入数字。需要自由输入时在选项中加入"Other（自定义输入）"。
-
-## CLI 命令（一切读写都走命令，勿手写 yaml / 勿 bash 解析）
-
-```bash
-sillyspec workspace add <名> <相对路径> [--role <角色>] [--repo <仓库地址>]   # 登记子项目（外科写入 yaml，已有字段保留；路径须存在）
-sillyspec workspace remove <名>                                             # 删除登记（项目本体不动）
-sillyspec workspace status                                                  # 三态探测表（未初始化/已初始化/已扫描+文档数）
-```
-
-无参运行任一子命令可见用法。`status` 的输出即成品状态表，直接转述给用户即可，勿再自行 for-loop 探测。
-
-## 核心流程
-
-1. **解析指令**：无参数 / `status` → 跑 `workspace status` 转述；`add` / `remove` → 交互收集参数后跑命令；`info <名>` → 读该子项目 `PROJECT.md` / `REQUIREMENTS.md` 摘要转述。
-2. **初始化工作区**（`projects/` 尚无任何 yaml 且用户同意时）：用 AskUserQuestion 逐个收集子项目名称/相对路径/角色（可选 repo），每收集一个跑一次 `workspace add`；添加完询问是否继续或完成。共享规范目录 `.sillyspec/shared/` 需要时手动创建。
-3. **收尾**：add/remove 后建议 git 提交（CLI 只写 yaml 不提交）；提示下一步对子项目跑 `/sillyspec:init` 或 `/sillyspec:scan`。
-
-## 绝对规则
-
-- 不修改子项目目录下的任何文件
-- 子项目路径必须是相对于工作区根目录的相对路径，且真实存在（`workspace add` 会校验）
-- yaml 读写一律交给 CLI——字段口径（name/path/status/role/repo）由命令维护，不手工拼
-
-## 用户指令
-$ARGUMENTS
+---
+name: sillyspec:workspace
+description: 工作区管理 — 初始化、管理多项目工作区，查看子项目状态
+---
+
+## 交互规范
+
+**当需要用户从多个选项中做出选择时，必须使用 Claude Code 内置的 AskUserQuestion 工具，将选项以参数传入。** 不要用编号列表让用户手动输入数字。需要自由输入时在选项中加入"Other（自定义输入）"。
+
+## CLI 命令（一切读写都走命令，勿手写 yaml / 勿 bash 解析）
+
+```bash
+sillyspec workspace add <名> <相对路径> [--role <角色>] [--repo <仓库地址>]   # 登记子项目（外科写入 yaml，已有字段保留；路径须存在）
+sillyspec workspace remove <名>                                             # 删除登记（项目本体不动）
+sillyspec workspace status                                                  # 三态探测表（未初始化/已初始化/已扫描+文档数）
+```
+
+无参运行任一子命令可见用法。`status` 的输出即成品状态表，直接转述给用户即可，勿再自行 for-loop 探测。
+
+## 核心流程
+
+1. **解析指令**：无参数 / `status` → 跑 `workspace status` 转述；`add` / `remove` → 交互收集参数后跑命令；`info <名>` → 读该子项目 `PROJECT.md` / `REQUIREMENTS.md` 摘要转述。
+2. **初始化工作区**（`projects/` 尚无任何 yaml 且用户同意时）：用 AskUserQuestion 逐个收集子项目名称/相对路径/角色（可选 repo），每收集一个跑一次 `workspace add`；添加完询问是否继续或完成。共享规范目录 `.sillyspec/shared/` 需要时手动创建。
+3. **收尾**：add/remove 后建议 git 提交（CLI 只写 yaml 不提交）；提示下一步对子项目跑 `/sillyspec:init` 或 `/sillyspec:scan`。
+
+## 绝对规则
+
+- 不修改子项目目录下的任何文件
+- 子项目路径必须是相对于工作区根目录的相对路径，且真实存在（`workspace add` 会校验）
+- yaml 读写一律交给 CLI——字段口径（name/path/status/role/repo）由命令维护，不手工拼
+
+## 用户指令
+$ARGUMENTS

package/AGENTS.md

@@ -0,0 +1,25 @@
+<!-- SillySpec v3.28.3 — 由 sillyspec init 生成，可自由编辑；重跑 init 同版本不更新 -->
+# Agent 指引
+
+## 项目说明
+本项目使用 **SillySpec** 管理变更，采用文档驱动开发。SillySpec 是给 Agent 调用的 CLI 流程控制器，不是给人类直接使用的产品，也不是处理业务逻辑的工具——你（Agent）通过 CLI 告诉它"我在哪"，它告诉你"下一步做什么"；你执行步骤，它校验产出、推进状态，人类只在关键决策点介入审批。要考虑多 agent 同时操作代码，代码随时可能变化。所有变更以稳定、可用、可维护为目标，按生产级标准处理。
+
+## 核心规则
+1. **禁止绕过本文件规则和 SillySpec 流程**。所有变更走 sillyspec 流程，不裸改裸提交。
+2. **改代码前必须先说明依据**——依据的文档路径（design.md / 模块文档 / file-lifecycle.md）或现有代码依据，无依据不改。
+3. **新功能 / 大改动走完整流程**：`brainstorm → plan → execute → verify → archive`。
+4. **小修复 / 小调整走 quick**：`sillyspec run quick`。
+5. **执行顺序**：文档 → 读代码 → 写测试 → 写实现 → 跑测试 → 验收 → 更新文档。
+6. **判规模选档**：≤3 文件、范围明确走 `quick`；多阶段 / 架构级走完整流程。
+7. **代码先行不补流程（倒推 B 模式）**：代码若已先写好，**不回头补 brainstorm/plan 装样子**——用 `quick --done` 收尾 + 补 quicklog 条目，把已落盘改动如实登记进进度库。
+8. **实证核验再 `--done`**：触及 `src`/`test` 的改动，CLI 会在 `quick --done` 时**亲自实测** `.sillyspec/local.yaml` 的 `commands.test` / `commands.lint`（门禁：实测失败阻断 --done 回 pending；纯 doc/配置与未配置命令自动跳过；倒推 B 模式按 --files 声明边界兜底判定）。agent 侧预跑**可选**——想省「--done 被拦→修复→重跑」一轮时才预跑；纯 doc/配置改动无需跑。以落盘文件与测试结果为准，不信口头"已完成"。
+9. **中途停下不靠额外命令存进度**——进度已由上一次 `--done` 自动落盘；恢复时用 `sillyspec progress show` 查看进度，再用 `sillyspec run <stage>` 续跑，不直接 commit 半成品。
+10. **实现完成后对照文档验收**（design.md / 模块文档），并检查是否影响已有测试。
+11. **非测试逻辑本身有误时，禁止改测试来"通过"**——修逻辑，不修测试。
+12. **git hook 拦截提交时禁止跳过**（如 `.husky/pre-push`），修复问题后再提交。
+13. **代码必须兼容 Windows / Linux / macOS**（路径 / 换行 / 并发都要顾）。
+14. **任务记录隔离**：永不重置 / reset / 清零已存在的 change；多个活跃 change 各自 `--change <名>` 隔离不重叠；quick 同一 QUICKLOG 按 ql-ID 条目追加，不冲突。
+15. **quicklog 结构化落盘**：末步 `--done` 用四参数 `--req/--cause/--solution/--result`（CLI 合成结构化 output 并自动提取标题/四段分行）；文件括注用 `--file-notes "path::注 || path2"`。骨架由 CLI 接管，`--done` 后按需核对即可，勿手拼模板。
+16. **代码可能随时在修改**（多 agent 并行），Edit 前重跑 + 查最新态；破坏性 git op 前先备份。
+17. **不奉承用户**，禁止"你说得对"类话术，直接给结论、依据、方案。
+18. **禁止目录级 git add / git add -A**（多会话共享仓）：.sillyspec/ 等目录里有并行会话的进行中文件与已提交文档，目录级暂存会夹带他者改动甚至误删已提交文件（2026-09-10 实证）。提交一律用显式 pathspec（git add -- 文件1 文件2），提交前 git status 核对暂存面只含本会话文件。

package/INSTRUCTIONS.md

@@ -0,0 +1,12 @@
+## SillySpec — 规范驱动开发
+
+在执行开发任务时，遵循以下规范：
+
+### 代码规范
+- 写代码前先读取 `.sillyspec/docs/<project>/scan/CONVENTIONS.md`（代码风格）和 `.sillyspec/docs/<project>/scan/ARCHITECTURE.md`（架构）
+- 调用已有方法前，用 grep 确认方法存在，不许编造
+- 遵循 `.sillyspec/docs/<project>/scan/CONVENTIONS.md` 中的代码风格
+
+### 工作流程
+- 读取 sillyspec.db 确认当前阶段（使用 `sillyspec progress show`）
+- 各阶段产出文件位于 `.sillyspec/changes/<变更名>/` 下

package/package.json

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

package/results-review-tier.md

@@ -0,0 +1,18 @@
+# Worker 审查报告：src/review-tier.js（77 行，只读审查）
+
+## 三行审查结论
+
+1. **职责**：classifyReviewTier 是审查分级器（CLI done 门禁与 prompt 注入两侧共用同一函数防判定漂移），按 plan_level 确定性映射（none/light→self，full→independent），无 plan_level 时退「design.md 变更文件数 ≤3」启发式，designPath 完全未传（fileCount=null）时 fail-safe 判 independent（宁严勿松）。
+2. **风险**：tier 判定权完全下放 agent 自报的 plan_level——agent 在 plan step1 低估规模报 light 即可绕过独立审查（自审自批），CLI 无第二道防线；这是 2026-08-14 tier-plan-level 改造的已知设计取舍（消除两套标准打架），但意味着分级质量上限受制于 agent 自律。
+3. **结论**：**pass** —— 纯函数、双侧共用判定、fail-safe 方向正确（无法证明规模→从严）、注释与实现一致（含 fileCount=0 按"真无变更=极小"的字面处理）；未发现逻辑缺陷，无需改动。
+
+## 结构化摘要
+
+- **发现**：
+  - 分级四步短路判定顺序清晰：none→self、light→self、full→independent、无 plan_level→文件数启发式（≤SELF_REVIEW_FILE_THRESHOLD=3→self）。
+  - fail-safe 双分支处理完备：fileCount=0（design 有但清单空）按极小判 self；fileCount=null（designPath 未传）判 independent。
+  - 注释记录了改造动机（此前 light+7 文件被文件数强制 independent，两套标准打架），可追溯性好。
+  - 唯一依赖 parseFileChangeList(designPath).size（Set），无其他副作用，纯函数可测性好。
+- **结论**：pass，无阻塞问题；风险项为设计取舍而非缺陷，如实登记。
+- **产出文件路径**：results-review-tier.md（本文件）
+- **风险**：见三行结论第 2 条（plan_level 自报低报可绕独立审查，无 CLI 二次防线）。

package/src/agent-session-log.js

@@ -30,8 +30,8 @@
  *   - cursor / opencode：loose 探测器（无 cwd/env 归属线索，仅 precise 全落空时启用）
  *   - 其他 CLI：env SILLYSPEC_AGENT_LOG 显式指定（绝对路径）
  *
- * 上报配置来源（优先级）：env SILLYHUB_PLATFORM_URL + SILLYHUB_PLATFORM_TOKEN（daemon
- * 注入通道）> local.yaml platform 段（与进度同步同源）。**不受平台模式 sentinel 限制**
+ * 上报配置来源（优先级）：env SILLYHUB_PLATFORM_URL + SILLYHUB_PLATFORM_TOKEN（预留
+ * 通道，daemon 未实现注入、需显式 export）> local.yaml platform 段（与进度同步同源）。**不受平台模式 sentinel 限制**
  * （链路 A 进度同步在平台模式跳过是因为 daemon 自有进度回传链路；agent 日志没有
  * daemon 链路，本上报就是它的主通道）。env SILLYSPEC_AGENT_LOG_PUSH=0 可关。
  *
@@ -559,7 +559,8 @@ export function detectAgentLogEntries({
  * 不 import sync.js 防拖 ProgressManager 重链）。
  *
  * 优先级：env SILLYHUB_PLATFORM_URL + SILLYHUB_PLATFORM_TOKEN（两键齐全才生效——
- * daemon 注入通道，平台模式 specRoot 的 local.yaml 无 platform 段时靠它）>
+ * 预留的外部注入通道，daemon 未实现注入、需显式 export；平台模式 specRoot 的
+ * local.yaml 无 platform 段时本就无凭据可上报，勿指望 env 兜底）>
  * specBase/local.yaml platform 段（url + token，与链路 A 同源）。
  * @returns {{url:string, token:string}|null} 未配置返回 null（合法状态，静默跳过上报）
  */