sillyspec 3.27.12 → 3.28.2

package/src/verify-probes.js

@@ -13,6 +13,9 @@
  * verify-result.md 骨架：七章节固定结构 + 探针结果机械预填 + 其余章节 <!--TODO--> 占位。
  * 结论章节留「待填」——extractVerifyConclusion 找不到 PASS/FAIL 关键词即判不过，骨架不能
  * 直接过门（与 symbol-impact 骨架同款防偷懒语义）。
+ * P3b 增量：①章节标题行末尾 claims 层标注（可复跑探针/确定性检查/人工判断，纯后缀不新增行）；
+ * ②--init 同步落盘 verify-facts.json 机器底稿（探针命令行 + 首跑关键指标 + 时间戳，CLI 全权写，
+ * 供事后独立复跑审计；重复 --init 覆盖为最近一次 init 快照）。
  */
 import { existsSync, readFileSync, readdirSync, writeFileSync } from 'fs'
 import { join, dirname, basename } from 'path'
@@ -257,6 +260,9 @@ export function renderVerifyProbesReport(result) {
   if ((probe5.scanRoots || []).length > 1) {
     L.push(`- ℹ️ 后端端点比对集为多根并集（主仓既有 ∪ worktree 新增 ∪ 存量 artifact），共扫 ${probe5.scanRoots.length} 个根`)
   }
+  if (probe5.prefixAlignedCount > 0) {
+    L.push(`- ℹ️ ${probe5.prefixAlignedCount} 处前端调用经挂载前缀对齐匹配（endpoints 提取不含 include_router/app.use 挂载点前缀，比对时剥除对齐——非契约缺口）`)
+  }
   if ((probe5.missingBackend || []).length > 0) {
     L.push('')
     L.push('| 状态 | 前端调用 | 后端端点 | 文件 |')
@@ -286,9 +292,85 @@ export function renderVerifyProbesReport(result) {
   return L.join('\n')
 }
 
+/**
+ * 从 runVerifyProbes 结果构造 verify-facts.json 机器底稿对象（P3b 可复跑审计底稿）。
+ * 命令行统一 `sillyspec verify-probes --change <name>`；指标 fail-soft——字段不可得时少列
+ * 该键而非报错（probe5 形态随 verifyApiParity 演进，宁可少列不可失真）。
+ * @param {{ probe1?: object, probe3?: object, probe5?: object, probe6?: object }} result
+ * @param {{ changeName?: string, now?: string }} [opts] now 缺省取当前时刻（ISO）
+ * @returns {{ schemaVersion: number, change: string, generatedAt: string, probes: object }}
+ */
+export function buildVerifyFacts(result, { changeName, now } = {}) {
+  const command = `sillyspec verify-probes --change ${changeName}`
+  // undefined 值键不进 metrics（「取不到的字段宁可少列」）
+  const defined = (o) => Object.fromEntries(Object.entries(o).filter(([, v]) => v !== undefined))
+  const len = (a) => (Array.isArray(a) ? a.length : undefined)
+  const num = (v) => (typeof v === 'number' ? v : undefined)
+  const p1 = (result && result.probe1) || {}
+  const p3 = (result && result.probe3) || {}
+  const p5 = (result && result.probe5) || {}
+  const p6 = (result && result.probe6) || {}
+  return {
+    schemaVersion: 1,
+    change: changeName,
+    generatedAt: now || new Date().toISOString(),
+    probes: {
+      probe1: {
+        command,
+        metrics: defined({
+          matches: len(p1.matches),
+          skippedFiles: len(p1.skippedFiles),
+          worktreeHits: num(p1.worktreeHits),
+          globEntries: len(p1.globEntries),
+        }),
+      },
+      probe3: {
+        command,
+        metrics: defined({
+          tasks: len(p3.tasks),
+          hasTest: Array.isArray(p3.tasks) ? p3.tasks.filter(t => t && t.hasTest).length : undefined,
+        }),
+      },
+      probe5: {
+        command,
+        metrics: defined({
+          backendEndpoints: num(p5.backendCount),
+          frontendCalls: num(p5.frontendCount),
+        }),
+      },
+      probe6: {
+        command,
+        metrics: defined({
+          deletions: len(p6.deletions),
+          unavailable: typeof p6.unavailable === 'boolean' ? p6.unavailable : undefined,
+        }),
+      },
+    },
+  }
+}
+
+/**
+ * verify-probes --init 落盘 verify-facts.json（CLI 全权写）。重复 --init 无条件覆盖——语义是
+ * 「最近一次机械预填的审计底稿快照」（骨架已存在跳过时 facts 照样刷新），agent 勿手改：
+ * 事后复跑审计的对照快照，防篡改一致性检查的对比基准是 verify-result.md 正文（非本文件）。
+ * @param {string} changeDir 变更目录（spec 根下 changes/<name>）
+ * @param {object} result runVerifyProbes 返回值
+ * @param {string} changeName 变更名（统一命令行呈现）
+ * @returns {{ facts: object, path: string }}
+ */
+export function writeVerifyFacts(changeDir, result, changeName) {
+  const facts = buildVerifyFacts(result, { changeName })
+  const factsPath = join(changeDir, 'verify-facts.json')
+  writeFileSync(factsPath, JSON.stringify(facts, null, 2) + '\n')
+  console.log(`📝 已刷新 verify-facts.json 机器底稿: ${factsPath}（CLI 全权写，勿手改）`)
+  return { facts, path: factsPath }
+}
+
 /**
  * 生成 verify-result.md 骨架（七章节；探针结果机械预填，语义章节 <!--TODO--> 占位）。
  * 结论章节留「待填」——extractVerifyConclusion 无 PASS/FAIL 关键词即判不过，骨架不能直接过门。
+ * 章节标题行末尾带 claims 层标注（P3b）：探针结果=可复跑探针 / 测试结果=确定性检查 / 其余=
+ * 人工判断——纯渲染层后缀，不新增行，verify gate 结论提取按关键词窗口制不受影响。
  * @returns {string|null} 骨架全文；无 design.md/tasks.md（非完整流程变更）→ null
  */
 export function generateVerifyResultSkeleton(result) {
@@ -298,33 +380,33 @@ export function generateVerifyResultSkeleton(result) {
     '> 探针结果已机械预填；其余章节把 `<!--TODO-->` 替换为真实内容。**结论必须写明 PASS / FAIL**——',
     '> 留「待填」会被 gate 判不过（fail-closed）。',
     '',
-    '## 结论：<待填：PASS 或 FAIL（+一句话理由）>',
+    '## 结论：<待填：PASS 或 FAIL（+一句话理由）> [层：人工判断]',
     '',
-    '## 任务完成度',
+    '## 任务完成度 [层：人工判断]',
     '<!--TODO: 逐 task 对照 tasks.md 勾选与验收标准，完成/未完成/存疑三态-->',
     '',
-    '## 设计一致性',
+    '## 设计一致性 [层：人工判断]',
     '<!--TODO: 实现与 design.md 的偏差（无偏差也显式写「一致」）-->',
     '',
-    '## 探针结果（CLI 机械预填）',
+    '## 探针结果（CLI 机械预填） [层：可复跑探针——gate 抽查防篡改]',
     renderVerifyProbesReport(result),
     '',
-    '## 测试结果',
+    '## 测试结果 [层：确定性检查——CLI 实测对账]',
     '<!--TODO: 测试命令 + 结果（通过数/失败数；known_failures 豁免逐条注明）-->',
     '',
-    '## 决策追踪矩阵（如存在 decisions.md；无则删本节）',
+    '## 决策追踪矩阵（如存在 decisions.md；无则删本节） [层：人工判断]',
     '<!--TODO: | 决策 ID | FR | Task | Evidence | 状态 |（D-xxx@vN → FR-xxx → task → 证据回指闭环）-->',
     '',
-    '## 技术债务',
+    '## 技术债务 [层：人工判断]',
     '<!--TODO: TODO/FIXME/HACK 统计（探针 1 的命中已预填在上方探针结果）-->',
     '',
-    '## 变更风险等级',
+    '## 变更风险等级 [层：人工判断]',
     '<!--TODO: doc-only / unit-sufficient / contract-required / integration-critical / deployment-critical；若 design.md frontmatter 有 risk_level 显式声明，写明「显式声明 = <等级>」+ 理由；若有命中被同句否定语境抑制（如「不新增 daemon 协议」），写明被抑制关键词与理由（抑制可审计，不许用来静默降级）-->',
     '',
-    '## Runtime Evidence',
+    '## Runtime Evidence [层：人工判断]',
     '<!--TODO: 关键命令输出/时间戳/commit hash 证据链；integration/deployment-critical 必填，按实际触碰的运行时组件写（启动命令/端点/请求响应/日志片段/生命周期终态断言/失败模式排除），未涉及的行写「不涉及」-->',
     '',
-    '## 代码审查',
+    '## 代码审查 [层：人工判断]',
     '<!--TODO: 问题列表 + 总体评价-->',
     '',
   ]

package/src/workflow.js

@@ -14,6 +14,7 @@ import { join, resolve, basename } from 'path'
 import jsYaml from 'js-yaml'
 import { WORKFLOW_STATUS } from './constants.js'
 import { contentNonEmpty, lineCount, missingSections, placeholderLineMatches } from './check-primitives.js'
+import { collectInvalidDocRefs } from './docs-check.js'
 
 // ─── Workflow 加载 ───
 
@@ -214,6 +215,35 @@ function checkOutput(outputDef, projectName, cwd, specBase) {
         }
         break
       }
+      case 'ref_exists': {
+        // 引用事实核验（archify 借鉴，2026-09-04）：层1+层2 联合核验，语义与
+        // scan-postcheck 的 scan_doc_ref_invalid 单一源（collectInvalidDocRefs）。
+        // min = 文档至少须含的 file:line 引用条数（缺省 1；显式 0 = 只核验有效性不求数量）。
+        if (existsSync(fullPath)) {
+          const min = check.min ?? 1
+          let verified
+          try {
+            verified = collectInvalidDocRefs(cwd, [{ name: rawPath, absPath: fullPath }])
+          } catch {
+            // 核验器故障 fail-open（与 scan-postcheck 的 checkScanDocRefs 同口径），不伪装成「引用数不足」
+            results.push({ passed: true, check: `ref_exists(${min})`, detail: '引用核验器异常，跳过（fail-open）' })
+            break
+          }
+          const enough = verified.totalRefs >= min
+          const passed = verified.invalid.length === 0 && enough
+          let detail = ''
+          if (!enough) {
+            const crossNote = verified.skippedCrossRepo > 0 ? `（另有 ${verified.skippedCrossRepo} 条 repo:// 跨仓引用未计入）` : ''
+            detail = `file:line 引用仅 ${verified.totalRefs} 条，要求至少 ${min} 条${crossNote}: ${rawPath}`
+          } else if (verified.invalid.length > 0) {
+            detail = `${verified.invalid.length} 条引用未通过核验: ${verified.invalid.slice(0, 3).map(i => `${i.ref}（${i.reason}）`).join('; ')} — ${rawPath}`
+          }
+          results.push({ passed, check: `ref_exists(${min})`, detail })
+        } else {
+          results.push({ passed: false, check: `ref_exists(${check.min ?? 1})`, detail: `文件不存在: ${rawPath}` })
+        }
+        break
+      }
       default:
         results.push({ passed: true, check: check.type, detail: `未知检查类型，跳过: ${check.type}` })
     }

package/templates/agents-instruction.md

@@ -11,7 +11,7 @@
 5. **执行顺序**：文档 → 读代码 → 写测试 → 写实现 → 跑测试 → 验收 → 更新文档。
 6. **判规模选档**：≤3 文件、范围明确走 `quick`；多阶段 / 架构级走完整流程。
 7. **代码先行不补流程（倒推 B 模式）**：代码若已先写好，**不回头补 brainstorm/plan 装样子**——用 `quick --done` 收尾 + 补 quicklog 条目，把已落盘改动如实登记进进度库。
-8. **实证核验再 `--done`**：`quick --done` 前，触及 `src`/`test` 的改动先 `npm test` + `npm run lint`；纯 doc/配置改动可跳过（lint 不扫 docs/，空转无信息），以落盘文件与测试结果为准，不信口头"已完成"。
+8. **实证核验再 `--done`**：`quick --done` 前，触及 `src`/`test` 的改动先跑 `.sillyspec/local.yaml` 配置的测试与 lint 命令（`commands.test` / `commands.lint`；未配置时用项目构建工具的等价命令，如 Node 项目 `npm test` + `npm run lint`、Python 项目 `pytest` + `ruff check`）；纯 doc/配置改动可跳过（lint 不扫 docs/，空转无信息），以落盘文件与测试结果为准，不信口头"已完成"。
 9. **中途停下不靠额外命令存进度**——进度已由上一次 `--done` 自动落盘；恢复时用 `sillyspec progress show` 查看进度，再用 `sillyspec run <stage>` 续跑，不直接 commit 半成品。
 10. **实现完成后对照文档验收**（design.md / 模块文档），并检查是否影响已有测试。
 11. **非测试逻辑本身有误时，禁止改测试来"通过"**——修逻辑，不修测试。

package/templates/prompts/taskcard-rules.md

@@ -10,6 +10,11 @@ TaskCard 格式规则（必须严格遵守）：
 - 不需要：修改文件章节、覆盖来源章节、接口定义章节、TDD 步骤章节、参考章节
 - frontmatter 必须以三减号结尾闭合（开头和结尾各一行 ---）。缺结尾会让 postcheck 提取不到 frontmatter，误报「字段缺失 / allowed_paths 为空」
 - allowed_paths 用块式写法（键名换行后每项一行「  - 路径」），不要用流式方括号 [path]——块式与所有校验器一致最稳
+- target_files 是可选字段：对账用精确文件级意图声明——列出本 task 计划改动的文件，供事后「计划改哪些 vs 实际改了哪些」对账；无明确文件级意图时保留骨架带出的 `target_files: []` 空占位不动，不猜清单（空 `[]` 是唯一允许的流式写法，填入实际路径后必须改块式）
+  - 格式：块式列表（`target_files:` 换行后每项一行「  - 路径」），精确文件路径、仓根相对、正斜杠；当前不存在、将由本 task 新建的文件加 `NEW:` 前缀
+  - 正例：`target_files:` + `  - src/taskcard.js`（已存在文件，精确路径）+ `  - NEW:src/foo.js`（本 task 将新建的文件）
+  - 反例：`  - src/**`（禁 glob）、`  - src/dir/`（禁目录前缀）、`  - C:\repo\src\a.js` 或 `  - /repo/src/a.js`（禁绝对路径）——对账按精确路径逐字匹配，任何非精确形态永不命中
+  - 与 allowed_paths 的语义区别（两者并存、不可互替）：allowed_paths 是 worktree 写入守卫白名单（子代理只被授权改这些路径），目录前缀与 glob 合法（覆盖性授权）；target_files 是对账用精确文件级意图声明，禁 glob、禁目录前缀、禁绝对路径——且 target_files 列出的每个文件都应落在 allowed_paths 的授权范围内
 - implementation / acceptance / constraints / verify 的每条列表项是 YAML plain scalar，避免以下特殊字符触发 ScannerError：
   - 冒号+空格（如代码签名 provider_id:str、queryUsage(id:string)）会被当映射键报 mapping values are not allowed here——去掉冒号后空格或改成中文描述
   - 花括号且内部含冒号或引号（如 JS 对象、JS 模板字面量）会报 expected block end——改用不含这些字符的中文描述

package/templates/workflows/scan-docs.yaml

@@ -21,9 +21,12 @@ roles:
             min: 20
           - type: contains_sections
             sections: ["技术栈", "架构概览"]
+          - type: ref_exists
+            min: 3
     constraints:
       - "禁止读源码全文，只用 grep/rg 搜索"
       - "Schema 只记表名+说明+字段数"
+      - "关键架构事实（模块职责/技术栈组件/数据存储）带反引号 path:line 引用，禁止猜行号——postcheck 逐条核验"
 
   - id: conventions
     name: "代码约定"
@@ -65,9 +68,12 @@ roles:
           - type: file_exists
           - type: min_lines
             min: 15
+          - type: ref_exists
+            min: 1
     constraints:
       - "STRUCTURE: 目录树+模块说明"
       - "INTEGRATIONS: 按类型分组外部依赖"
+      - "外部集成条目带反引号 path:line 引用（真实可核验），禁止猜行号"
 
   - id: quality
     name: "测试+债务+概览"

package/.claude/worktrees/sillyspec-data-model-research/.claude/skills/sillyspec-archive/SKILL.md

@@ -1,87 +0,0 @@
----
-name: sillyspec:archive
-description: 用于归档已验证完成的变更。适合用户说"归档、archive、收尾这个变更"。执行模块影响分析 + 同步模块文档 + 移动到 archive 目录 + 更新 ROADMAP。
----
-
-## 何时使用
-
-- 用户说"归档、archive、收尾这个变更"
-- verify 已通过，把变更包归档沉淀
-- 5 步：任务完成度检查 → 模块影响分析 → 同步模块文档 → 确认归档 → 更新路线图
-
-> 🔧 模块影响分析步：先跑 `sillyspec module-impact --change <变更名>` 生成 module-impact.md 骨架——文件×模块归属按 `_module-map.yaml` paths 前缀匹配预填 + 未匹配文件清单，你只需逐行填「影响类型」与 review 标记（以 git diff 为准，真实 > 声明）；已存在不覆盖。
-
-## 多变更说明
-
-项目有多个活跃变更（`.sillyspec/changes/` 下有多个目录）时，所有 `sillyspec run` 命令需加 `--change <变更名>` 指定操作目标；只有一个变更时可省略（CLI 自动检测）。
-
-## 步骤生命周期（所有阶段通用）
-
-> `sillyspec archive` 是 `sillyspec run archive` 的顶层别名，两者等价。
-
-```bash
-sillyspec run archive                          # 输出当前步骤 prompt
-sillyspec run archive --done --output "摘要"   # 完成当前步骤
-sillyspec run archive --status                 # 查看阶段进度
-sillyspec run archive --skip                   # 跳过可选步骤
-sillyspec run archive --reset                  # 重置阶段（从头开始）
-sillyspec run archive --reopen --from-step N   # 重新打开已完成阶段修订（N=序号或名称）
-```
-
-## 通用参数（所有阶段适用）
-
-| 参数 | 说明 |
-|---|---|
-| `--change <名>` | 指定变更名（多活跃变更必填，单变更可省略自动检测） |
-| `--spec-dir <path>` | 指定规范目录（默认 `<项目>/.sillyspec`） |
-| `--non-interactive` | CI/脚本下禁用交互式 prompt |
-| `--skip-approval` | 跳过阶段转换/审批检查（不能跳产物校验 gate——review.json/文档产物硬校验仍在） |
-
-## archive 特有
-
-### `--confirm`（确认归档步骤必填）
-
-第 4 步「确认归档」由 CLI 执行目录移动，**必须带 `--confirm`**：
-
-```bash
-sillyspec run archive --done --confirm --output "确认归档"
-```
-
-不带 `--confirm` 时 CLI 回退步骤为 pending 并提示，不会误归档。
-
-### 归档前硬校验
-
-CLI 移动目录前会校验 `plan.md` 存在——缺失则 `exit(1)` 阻断（目录尚未移动，可补全后重试）。移动后校验 `design.md` / `module-impact.md`（缺失只告警，因目录已移动）。
-
-### 模块文档同步（第 3 步）
-
-第 3 步「sync-module-docs」会更新 `_module-map.yaml` + 模块卡片，**必须暂停等用户确认**：
-
-```bash
-sillyspec run archive --wait --reason "等待用户确认模块文档同步" --options "确认写入,跳过同步" --output "diff 摘要"
-sillyspec run archive --continue --answer "确认写入"
-```
-
-只有用户 `--continue --answer "确认写入"` 后才写入文件。
-
-### 归档结果
-
-归档后变更目录从 `changes/<名>/` 移到 `changes/archive/<名>/`，并从活跃列表注销。后续用 `/sillyspec:commit` 提交。
-
-## 阶段流转
-
-```
-verify → archive → git commit
-```
-
-archive 完成后，运行 `/sillyspec:commit` 提交归档结果（`git add .sillyspec/changes/`）。
-
-## 铁律
-
-- **必须用 exec 工具（shell）执行 CLI，不要自己编造流程**
-- 不要用 `mv`/`rename` 重命名变更目录，必须由 CLI 的「确认归档」步骤移动
-- 归档不可逆——确认前核对变更名、文件列表、module-impact.md
-- 完成后立即 `--done`，不跳过
-
-## 用户指令
-$ARGUMENTS

package/.claude/worktrees/sillyspec-data-model-research/.claude/skills/sillyspec-auto/SKILL.md

@@ -1,93 +0,0 @@
----
-name: sillyspec:auto
-description: 自动模式 — 全流程自动推进（通用版）
-argument-hint: "<需求描述>"
----
-
-## 交互规范
-
-**当需要用户从多个选项中做出选择时，必须使用 Claude Code 内置的 AskUserQuestion 工具，将选项以参数传入。** 不要用编号列表让用户手动输入数字。
-
-## 用法
-
-- `/sillyspec:auto 实现用户登录功能`
-- `/sillyspec:auto 修复搜索结果的排序问题`
-
-## 任务
-$ARGUMENTS
-
----
-
-## 执行流程
-
-你是全流程编排器，按 brainstorm → plan → execute → verify 顺序自动推进。
-
-### 启动
-
-```bash
-sillyspec run auto --input "<用户需求>" [--mode <模式>]
-```
-
-2. 读取 CLI 输出的 step prompt（含角色描述）
-3. 执行 prompt 中的操作
-4. **记录 CLI 输出中显示的 Change 名称**（如 `Change: 2026-06-02-xxx`）
-
-### 步骤循环
-
-重复以下循环直到 CLI 输出"全部流程已完成"：
-
-1. **读取 CLI 输出的 step prompt**
-2. **判断是否需要用户确认：**
-   - prompt 含"请用户选择 / 等待用户回答 / 展示给用户 / 用户确认" → **暂停，等用户回复**
-   - 纯内部操作 → **直接执行**
-3. **执行 prompt 要求的操作**
-4. **完成后运行：**
-   ```bash
-   sillyspec run auto --done --change <变更名> --output "<你的摘要>"
-   ```
-   - ⚠️ **必须携带 `--change <变更名>`**，变更名来自启动时 CLI 输出的 `Change:` 字段
-   - **绝不使用 `--change default`**，除非 CLI 启动时明确显示的 Change 名称就是 `default`
-5. **读取 CLI 输出的下一步 prompt**，回到步骤 1
-
-### auto 参数
-
-| 参数 | 说明 |
-|---|---|
-| `--input "<需求>"` | 启动时传入用户需求 |
-| `--mode <模式>` | 显式指定流程模式（默认按复杂度自动分类） |
-| `--done --change <名> --output "..."` | 完成当前步骤（必带 --change） |
-| `--spec-dir <path>` | 指定规范目录 |
-| `--non-interactive` | CI/脚本下禁用交互 |
-
-## 阶段审核门控（Stage Review Gate）
-
-审核发生在 brainstorm / plan / execute 各阶段的 review 步骤，**分级由 CLI 按变更规模自动判定**（不是 agent 凭关键词或复杂度启发式判断）：
-
-- **tier=self**（变更 ≤3 文件）：当前 agent 自审，直接产 review.json。
-- **tier=independent**（变更 >3 文件）：必须派发**独立 QA 子代理**（独立上下文，不共享实现者分析）产 review.json。
-
-CLI 会在 review 步骤注入：完整 JSON schema 表 + 示例 + docHash 算法 + 自动决策 checklist（AC-001 起，逐条核验公共 API / schema / 鉴权 / 文件边界 / 依赖 / 核心模块 / 兼容性 / 业务等维度）。你按**实际注入的契约与 tier 指令**执行：
-
-- checklist 全 ✅ 且方案唯一合理 → AUTO_DECIDED，推进下一阶段
-- checklist 有 ❌（影响架构/数据/接口/权限/兼容性/业务）→ 暂停，用 AskUserQuestion 让用户选择
-
-**不要**自行编造"简单/中等/复杂 → N 个审核子代理"规则——审核子代理数量由 tier 决定（self=0 额外子代理，independent=1 个独立 QA），不是复杂度启发式；以 CLI 实际注入的 tier 与 checklist 为准。
-
-## 关键规则
-
-- 不要跳过任何步骤
-- 不要手动修改进度数据（SQLite 数据库）
-- 不要自动 commit，只 `git add`
-- 不要使用 npx
-- 不要编造不存在的 CLI 子命令
-- 遇到命令报错 → 展示错误，暂停等用户介入
-- **每次 `sillyspec run auto --done` 都必须携带 `--change <变更名>`**（= CLI 首次输出的 Change 名）
-
-## 异常处理
-
-- 命令执行失败 → 展示错误信息，暂停等待用户指示
-- 用户说"停止"/"暂停" → 立即停止，报告当前进度
-
-## 完成条件
-
-CLI 输出"全部流程已完成"后，输出完整流程总结，提示用户提交改动（`/sillyspec:commit`）。

package/.claude/worktrees/sillyspec-data-model-research/.claude/skills/sillyspec-brainstorm/SKILL.md

@@ -1,114 +0,0 @@
----
-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` | 跳过阶段转换/审批检查（不能跳产物校验 gate——review.json/文档产物硬校验仍在） |
-
-## brainstorm 特有：requiresWait 步骤
-
-某些步骤（如"对话式探索与需求澄清"）需要用户输入。两种方式：
-
-> 自动去重：若前置 step 已对同一问题（waitReason 归一化后相同）确认过，后续重复 wait 会自动跳过，无需再 `--wait`。
-
-- **方式一（推荐）**：分步——先 `--wait` 记录等待，让用户亲眼看到 CLI 打出的选项再作答，再 `--continue --answer`，最后 `--done`：
-  ```bash
-  sillyspec run brainstorm --wait --change <名> --reason "等待用户回答" --output "探索问题"
-  sillyspec run brainstorm --continue --answer "用户回答" --change <名>
-  sillyspec run brainstorm --done --change <名> --output "需求已澄清"
-  ```
-- **方式二**：AI 自行与用户交互后，一步完成（仅在用户已在对话中明确给出答案、无需再走 CLI 等待展示时用）：
-  ```bash
-  sillyspec run brainstorm --done --change <名> --answer "用户回答" --output "需求已澄清"
-  ```
-
-> ⚠️ 两种方式都要求 `--answer` 是**用户真实的回答**，不是你替用户编的回答。`requiresWait` 门只校验 `--answer` 非空，挡不住「AI 伪造用户回答」——所以对方案选择/设计确认这类关键决策，优先用方式一让用户亲手作答，而不是 AI 中继一句话带过。
-
-## 阶段流转
-
-```
-                ┌─ 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` 后再跑相应阶段。
-
-### Stage Review Gate（brainstorm 末尾的 design review.json）
-
-brainstorm 在 `tier=independent` 规模下除 design.md 等四件套外，还需产出一个 stage 级 `review.json`，CLI `Stage Review Gate` 硬校验其 schema 与 `docHash` 真实性。
-
-- 路径：`.sillyspec/.runtime/stage-reviews/brainstorm-review-<stage-review-run-id>/review.json`（目录可能不存在需手建；run-id 由该步 `--done` prompt 输出指定）。marker 文件 `.runtime/current-stage-review-run-id-brainstorm-<变更名>`。
-- **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 brainstorm` 一步生成。
-- 字段（`schemaVersion:1`，`reviewType=design` —— 区别于 execute 的 `acceptance`）：
-
-  ```json
-  {
-    "schemaVersion": 1,
-    "reviewType": "design",
-    "reviewedFiles": ["changes/<变更名>/design.md"],   // [0] 为主文档
-    "docHash": "<sha256(reviewedFiles[0] 文件内容，hex)>",
-    "specVerdict": "pass",       // pass | fail | cannot_verify
-    "qualityVerdict": "pass",    // pass | fail | cannot_verify
-    "checklist": [               // 扁平数组，逐条对照 design 章节核验
-      { "item": "背景与目标", "result": "pass", "note": "..." }   // result: pass | gap | fail
-    ],
-    "requiredEvidence": [],      // cannot_verify 时必填非空
-    "reviewerNotes": "..."
-  }
-  ```
-
-- `docHash` = `sha256(主审查文档内容)`（hex）—— brainstorm 主文档是 `design.md`（即 `reviewedFiles[0]`）。CLI 重算 sha256 比对，不符判伪造（fail-closed）。docHash 可先占位（如 "TODO"）；改 design.md 后勿手算 sha256——跑 `sillyspec register-stage-review --change <变更名> --stage brainstorm --refresh-hash` 一键重算代填（verdict 保留；design 改版多阶段联动加 --all）。`tier=self`（≤3 文件）降级为当前 agent 自审，不强制独立子代理。
-- 运行时 CLI 会把精确 schema 表 + 完整 JSON 示例 + docHash 算法注入到该步 prompt，以你实际收到的注入版契约为权威逐字模板。
-
-## 铁律
-
-- **必须用 exec 工具（shell）执行 CLI，不要自己编造流程**
-- 只做当前步骤 prompt 描述的操作，不跳过、不自行扩展
-- 产物写入 CLI 输出的 `changeDir` 目录（如 `<changeDir>/design.md`），不要自己拼路径
-- 完成后立即 `--done`，不跳过
-
-## 用户指令
-$ARGUMENTS

package/.claude/worktrees/sillyspec-data-model-research/.claude/skills/sillyspec-commit/SKILL.md

@@ -1,67 +0,0 @@
----
-name: sillyspec:commit
-description: 智能提交 — 自动收集变更信息，生成 commit message
-argument-hint: "[可选：自定义 commit message]"
-version: "3.7.32"
----
-
-## 交互规范
-当需要用户从多个选项中做出选择时，必须使用 Claude Code 内置的 AskUserQuestion 工具，将选项以参数传入。
-
-## 用法
-- /sillyspec:commit — 智能提交：自动收集变更信息，生成 commit message
-- /sillyspec:commit "自定义 message" — 使用指定 message 直接提交
-
-## 任务
-$ARGUMENTS
-
----
-
-## 流程
-
-### 1. 收集变更上下文 + 建议 message（一条命令）
-
-```bash
-sillyspec commit
-```
-
-CLI 已接管全部手工收集（上次 commit 时间过滤 QUICKLOG 条目、活跃变更已勾 task、按路径模式归类阶段产出、diff stat），并按下方 type 表生成建议 message + 可照抄的 `git add -A && git commit -m ...` 命令。**它只建议不提交。**
-
-- 命令输出「没有需要提交的修改」→ 结束。
-- 无语义来源匹配（输出会明说）→ 展示 diff stat，让用户自己写。
-
-### 2. 展示确认
-
-把 `sillyspec commit` 的建议 message + 文件统计原样展示给用户（AskUserQuestion）：
-
-选择：确认提交 / 编辑 message / 取消
-
-用户选择编辑 → 让用户输入新 message → 再次确认。
-
-### 3. 执行提交
-
-用户确认后执行 `git add -A` + 输出里给出的 `git commit` 命令（或用户编辑后的 message）。
-
-提交成功后展示 commit hash + 文件数 + 行数统计。
-
-### 参考：message 生成口径（CLI 同源实现，src/commit-suggest.js）
-
-| 来源 | type | 示例 |
-|---|---|---|
-| 只有 quick 条目 | fix | fix: 手机号校验修复（含正则修正） |
-| 只有 execute 已勾 task | feat | feat: <变更名> 完成 task ×N |
-| 只有阶段产出 | docs | docs: sillyspec scan 完成 |
-| 混合来源 | 取最主要的 type | body 里列出所有条目 |
-| 无匹配来源 | — | 展示 diff stat，让用户自己写 |
-
-**如果 $ARGUMENTS 非空**，直接使用用户指定的 message，跳过自动生成，但仍展示 diff stat。
-
-## 多项目
-检查修改的文件分别属于哪个子项目：
-- 修改集中在一个子项目 → 在该子项目目录中 commit
-- 修改跨多个子项目 → 用 AskUserQuestion 让用户选择：分开提交（每个子项目一个 commit）/ 合并提交
-
-## 绝对规则
-- ❌ 不要自动提交，必须展示 message 让用户确认
-- ❌ 不要丢弃用户的修改
-- ✅ $ARGUMENTS 非空时展示 diff stat 后直接提交（不需手动确认）

package/.claude/worktrees/sillyspec-data-model-research/.claude/skills/sillyspec-continue/SKILL.md

@@ -1,47 +0,0 @@
----
-name: sillyspec:continue
-description: 自动判断并执行下一步
----
-
----
-
-你现在是 SillySpec 的自动推进器。
-
-## 判断逻辑
-
-> 🔧 **先跑 `sillyspec next`**——CLI 已内置下方探测表（含活跃变更逐个推断 + task 勾选进度），输出「状态 + 下一步命令 + 依据」。直接按输出的建议命令执行；CLI 异常/输出与实际不符时才按下方手工表兜底。
-
-按顺序检查，第一个未完成的就执行：
-
-```
-1. 有 HANDOFF.json？→ 执行 /sillyspec:resume
-
-2. .sillyspec/changes/ 有进行中的变更？
-   2a. 没有任何文件 → 提示检查 proposal 是否需要完善
-   2b. 没有 design.md → 提示补充 design（运行 /sillyspec:brainstorm 推进到设计产物步）
-   2c. 没有 tasks.md → 执行 /sillyspec:brainstorm（规范文件 proposal/requirements/tasks 由 brainstorm 末步生成）
-   2d. 有 tasks.md 但没有 plan.md → 执行 /sillyspec:plan
-   2e. tasks.md 有未完成项 + 有计划文件 → 执行 /sillyspec:execute
-   2f. tasks.md 全完成 + 没验证 → 执行 /sillyspec:verify
-   2g. 已验证通过 → 执行 /sillyspec:archive
-
-3. 有设计文档但没有对应变更？
-   → 提示运行 /sillyspec:brainstorm（基于设计文档建立变更并生成规范文件）
-
-4. 有 .sillyspec/docs/*/scan/ 但没有进行中的工作？
-   → 提示运行 /sillyspec:brainstorm "你的想法"
-
-5. 什么都没有？
-   → 提示运行 /sillyspec:init（新项目）或 /sillyspec:scan（棕地项目）
-```
-
-## 输出
-
-先报告检测结果，再执行：
-
-> 🤖 SillySpec 自动检测
-> 
-> 当前状态：[描述]
-> 下一步：[执行的命令]
-> 
-> [开始执行...]