sillyspec 3.27.11 → 3.28.0

package/src/task-review.js

@@ -244,6 +244,19 @@ export function validateReviewSchema(review) {
     errors.push('缺少 head 字段（git commit hash）')
   }
 
+  // diffPaths（可选，统一 commit 模式）：路径限定评审范围。主代理统一 commit（全部 task 一个
+  // commit）下 per-task 提交区间不存在，base..head 只能取整变更区间——diffPaths=本 task 的
+  // allowed_paths，评审/校验 diff 收窄为 git diff base..head -- diffPaths 的路径限定切片
+  // （坑 task-review-unified-commit-scope，2026-09-01 实证：此前任务边界只靠 changedFiles
+  // 「归属说明」，gate 无法机器验证本 task 切片非空）。缺省=不过滤（per-task commit 模式
+  // base..head 本就是任务区间，行为零变化）。
+  if (review.diffPaths !== undefined) {
+    if (!Array.isArray(review.diffPaths) || review.diffPaths.length === 0
+        || !review.diffPaths.every(p => typeof p === 'string' && p.trim())) {
+      errors.push('diffPaths（若提供）应为非空字符串数组（路径限定评审范围，统一 commit 模式填本 task 的 allowed_paths；per-task commit 模式无需此字段）')
+    }
+  }
+
   return { ok: errors.length === 0, errors }
 }
 
@@ -499,7 +512,10 @@ export function validateTaskReviews(opts) {
             errors.push(`${taskId}: 纯验证 task（task_type: verification）零 diff 合法，但 review 缺 requiredEvidence（须披露验证区间/命令/结论出处）——声明不能替代披露`)
           }
         } else {
-          errors.push(`${taskId}: base..head（${review.base.slice(0, 8)}..${review.head.slice(0, 8)}）无任何代码变更 — 评审了一个零改动的任务，review 疑似伪造`)
+          const scopeNote = Array.isArray(review.diffPaths) && review.diffPaths.length > 0
+            ? `（diffPaths 路径限定切片为空——统一 commit 模式下 diffPaths 应为本 task 的 allowed_paths；task 确未实现请把 verdict 回 fail）`
+            : ''
+          errors.push(`${taskId}: base..head（${review.base.slice(0, 8)}..${review.head.slice(0, 8)}）无任何代码变更 — 评审了一个零改动的任务，review 疑似伪造${scopeNote}`)
           continue
         }
       }
@@ -590,6 +606,8 @@ function parsePorcelainFiles(statusOut) {
  *   1. base/head 必须是仓库中可解析的真实 commit
  *   2. base..head 的 diff 不能为空（评审一个零改动的"任务"无意义）
  *   3. review.changedFiles（如提供）必须与实际 diff 文件有交集
+ * 带 diffPaths（统一 commit 模式）时 2/3 在 `base..head -- diffPaths` 的路径限定切片上跑
+ * （坑 task-review-unified-commit-scope）：整变更区间下机器可验「本 task 切片非空」。
  *
  * git 环境不可用（非 git 仓库 / git 缺失）时返回 unavailable，由调用方降级为
  * warning——不因环境问题误杀，但记录在输出中。
@@ -694,9 +712,23 @@ export function verifyReviewGitEvidence(review, gitDir, cache = null) {
   } catch {}
   diffFiles = [...new Set(diffFiles)].filter(Boolean)
 
+  // ── diffPaths 路径限定切片（坑 task-review-unified-commit-scope，2026-09-01 实证）──
+  // 主代理统一 commit（全部 task 一个 commit）下 per-task 提交区间不存在，10 个 task 的
+  // review 只能共用同一对 base..head（整变更区间）——任务边界此前只靠 changedFiles「归属
+  // 说明」，本函数无法机器验证「本 task 的切片非空」。diffPaths（=task 的 allowed_paths）
+  // 把 emptyDiff/交叉比对收窄到切片：统一 commit 模式成为一等公民（per-task commit 模式
+  // 不填 diffPaths，行为零变化）。切片在 commit diff ∪ working-tree 并集之后过滤（与
+  // 归属口径同源：generateTaskReviewDrafts 的 allowed_paths 过滤用 pathMatches）。
+  const scopePaths = Array.isArray(review.diffPaths) && review.diffPaths.length > 0
+    ? review.diffPaths.filter(p => typeof p === 'string' && p.trim())
+    : null
+  const scopeNote = scopePaths ? `，diffPaths 切片 ${scopePaths.length} 路径` : ''
+  if (scopePaths) diffFiles = diffFiles.filter(f => scopePaths.some(p => pathMatches(f, p)))
+
   const emptyDiff = diffFiles.length === 0
 
-  // changedFiles 交叉比对：完全不相交 = review 描述的改动与实际 diff 无关（diffFiles 已含 working-tree）
+  // changedFiles 交叉比对：完全不相交 = review 描述的改动与实际 diff 无关（diffFiles 已含 working-tree，
+  // 有 diffPaths 时已收窄为路径限定切片）
   if (!emptyDiff && Array.isArray(review.changedFiles) && review.changedFiles.length > 0) {
     // 注记剥离（坑 changedfiles-annotation-suffix-mismatch，2026-08-22 实证：changedFiles 带
     // 「src/a.js（新增）」类注记后缀被判完全不相交，agent 用正则修还贪婪吞了路径段两轮才对）。
@@ -715,8 +747,9 @@ export function verifyReviewGitEvidence(review, gitDir, cache = null) {
       return diffSet.has(nf) || diffFiles.some(d => d.endsWith(nf) || nf.endsWith(d))
     })
     if (!hasOverlap) {
-      errors.push(`changedFiles 与实际 git diff（${review.base.slice(0, 8)}..${review.head.slice(0, 8)}，${diffFiles.length} 个文件）完全不相交 — review 内容与代码变更无关。` +
-        `检查：changedFiles 必须是纯文件路径（注记/说明写 reviewerNotes，不拼进路径数组）；路径拼写与 diff 对照`)
+      errors.push(`changedFiles 与实际 git diff（${review.base.slice(0, 8)}..${review.head.slice(0, 8)}${scopeNote}，${diffFiles.length} 个文件）完全不相交 — review 内容与代码变更无关。` +
+        `检查：changedFiles 必须是纯文件路径（注记/说明写 reviewerNotes，不拼进路径数组）；路径拼写与 diff 对照` +
+        (scopePaths ? `；diffPaths 是否覆盖了 changedFiles 所在路径（切片按 diffPaths 过滤）` : ''))
     }
   }
 
@@ -1218,6 +1251,11 @@ export async function generateTaskReviewDrafts({ changeName, cwd, platformOpts =
       base: taskBase,
       head: taskHead,
       changedFiles: taskChangedFiles,
+      // 统一 commit 模式（坑 task-review-unified-commit-scope）：base..head 是整变更区间时，
+      // diffPaths 把证据校验切片收窄到本 task 的 allowed_paths。仅在有归属切片时带
+      // （无归属草稿 changedFiles 为空，带 diffPaths 会让切片空 → emptyDiff 误判伪造，
+      // 与「留给 agent 复核升级」的草稿语义冲突）。
+      ...(allowedPaths.length > 0 ? { diffPaths: allowedPaths } : {}),
       specVerdict: 'cannot_verify',
       qualityVerdict: 'cannot_verify',
       requiredEvidence: ['auto-generated draft: 待 agent 对照 ' + taskId + ' brief + diff 复核后升级为 pass/fail'],
@@ -1378,6 +1416,14 @@ export async function adoptTaskReviewMechanics({ changeName, cwd, platformOpts =
     merged.base = taskBase
     merged.head = taskHead
     merged.changedFiles = taskChangedFiles
+    // diffPaths（统一 commit 模式，坑 task-review-unified-commit-scope）：与草稿同口径——仅
+    // 有归属切片（taskChangedFiles 非空）时带 allowed_paths，空归属不带（防切片恒空 →
+    // emptyDiff 误判伪造）。
+    if (taskChangedFiles.length > 0 && allowedPaths.length > 0) {
+      merged.diffPaths = allowedPaths
+    } else {
+      delete merged.diffPaths
+    }
     if (draftRepo) merged.repo = draftRepo
 
     let verdictTouched = false
@@ -1403,6 +1449,7 @@ export async function adoptTaskReviewMechanics({ changeName, cwd, platformOpts =
       || prev.base !== merged.base
       || prev.head !== merged.head
       || JSON.stringify(prev.changedFiles ?? null) !== JSON.stringify(merged.changedFiles)
+      || JSON.stringify(prev.diffPaths ?? null) !== JSON.stringify(merged.diffPaths ?? null)
       || prev.repo !== merged.repo
 
     try {

package/src/verify-postcheck.js

@@ -613,6 +613,31 @@ const SUMMARY_LINE_RE = /(={2,}.*={2,}|^\s*\d+\s+(failed|passed|skipped|pending)
 // 与失败信号（× 行 / FAIL 横幅 / 汇总计数）无关，全部剔除。
 const CONSOLE_CAPTURE_RE = /^\s*(?:stdout|stderr)\s*\|/
 const ENV_NOISE_RE = /not\s+implemented\s*:/i
+// 报表行（vitest/jest 测试运行器自身输出，非被捕获的 console 内容）：失败结果标记行
+// （×✕✗✘ 前缀 / FAIL 文件行）、❯ 文件摘要行、⎯ 分节分隔行——用作捕获块的结束边界。
+const REPORT_LINE_RE = /^\s*(?:[×✕✗✘]|FAIL\b|❯|⎯)/
+// Python/pytest 警告噪声（坑 verify-pytest-warnings-noise，2026-09-01 实证）：pytest 把
+// warnings summary 打印成「测试 id 行 + `<路径>:<行号>: <XxxWarning>: 消息` 归因行 + 缩进
+// 源码展示行」。归因行的**文件路径**常含 exception/error 子串（starlette `_exception_handler.py`
+// 是 FastAPI 全家桶标配，路径即命中 /exception/i）——整块被判失败行，backend 全量实测真实
+// 1 个守卫失败被上百行 DeprecationWarning 噪声淹没、只能人工分模块定位。warning 不是失败
+// 信号：① 区段级整段剔（区段头 → 下一 pytest 区段头）；② 行级剔（截断 tail 看不到区段头时
+// 兜底：归因/分组/Node 警告行 + 其上下文的 id/源码展示行）。真实失败的归因行（如
+// `file.py:42: AssertionError`）非 *Warning 类名，形态可分、不受影响。
+// 区段头：`============================== warnings summary ===============================`
+const PY_WARNINGS_SECTION_RE = /^\s*=+.*warnings summary.*=+\s*$/i
+// pytest 任意区段分隔头（`==== short test summary info ====` / `==== 3 failed, 300 passed in 12s ====`）
+const PY_SECTION_RE = /^\s*=+.*=+\s*$/
+// warning 归因行：`C:\...\file.py:59: DeprecationWarning: ...` / `file.py:7: UserWarning: ...`
+// （盘符/相对路径两形态；截断前缀 … 是普通非冒号字符，[^:\r\n] 天然兼容）
+const PY_WARNING_ATTR_RE = /^\s*(?:[A-Za-z]:)?(?:[^:\r\n]*[\\/])?[^:\r\n]*:\d+:\s+\w*Warning:/
+// 分组归因行：`tests/test_x.py: 13 warnings`
+const PY_WARNING_GROUP_RE = /^\s*(?:[A-Za-z]:)?[^:\r\n]*:\s*\d+\s+warnings?\b/i
+// Node 进程警告行：`(node:1234) [DEP0040] DeprecationWarning: ...`
+const NODE_WARNING_RE = /^\s*\(node:\d+\)\s*(?:\[[^\]]*\]\s*)?\w*Warning:/
+// pytest 测试 id 行（`path/to/test.py::TestClass::test_x`，无空格）——warnings summary 内
+// 逐条 warning 的归属头；只在 warning 上下文激活时剔（正常输出里的 id 行不动）
+const PY_TEST_ID_RE = /^\S+::\S+$/
 // 通过行（行首标记，剥 ANSI 后判定）：vitest/jest/mocha 的 ✓√✔ 前缀行 + jest 的 PASS 文件行。
 // 坑 verify-known-failures-pass-line-false-positive：FAILED/error:/exception 是子串匹配，
 // 通过行用例名恰含这些字样（如「✓ … 超时后 syncStatus=failed」）会被误判失败行——
@@ -630,15 +655,42 @@ const ANSI_RE = /\x1b\[[0-9;]*[A-Za-z]/g
  */
 export function partitionFailures(output, knownFailures) {
   const lines = String(output || '').split(/\r?\n/)
-  // 分类在剥 ANSI 后的行上做，返回保留原文（remaining 展示给 agent 时不变形）
-  const failureLines = lines.filter(l => {
-    if (PASS_LINE_RE.test(l)) return false
+  // 分类在剥 ANSI 后的行上做，返回保留原文（remaining 展示给 agent 时不变形）。
+  // 捕获块状态机（坑 verify-console-capture-block-noise，2026-08-31 daemon 套件 ~710 行实证）：
+  // vitest 把测试内 console 输出捕获为 `stdout|`/`stderr|` 横幅 + 后续内容行——旧逻辑只剔
+  // 横幅行本身，内容行（通过用例的结构化日志，常含 error:/failed 字样）仍中子串匹配成假
+  // 失败行。块以横幅开始，直到下一报表行（通过/失败标记、FAIL 文件行、❯ 文件摘要、⎯ 分节
+  // 符、汇总行）结束；块内内容行一律剔除。真实失败恒有 ×/FAIL 报表行（先结束块、照常参与
+  // 分类），失败检出不受影响；检测不到失败行时 judgeWithKnownFailures 仍 fail-safe 判 failed。
+  const failureLines = []
+  let inCapture = false
+  // pytest warnings summary 区段态：区段头开区、下一 pytest 区段头收区，区段内容整段剔
+  let inPyWarnings = false
+  // warning 上下文态（行级兜底）：命中归因/分组/Node 警告行后，紧随的缩进源码展示行、
+  // pytest 测试 id 行与组间空行同属该 warning 展示块，一并剔；报表行/其他内容行终结上下文。
+  let pyWarnCtx = false
+  for (const l of lines) {
     const bare = l.replace(ANSI_RE, '')
-    if (PASS_LINE_RE.test(bare)) return false
-    if (CONSOLE_CAPTURE_RE.test(bare)) return false
-    if (ENV_NOISE_RE.test(bare)) return false
-    return PER_TEST_FAIL_RE.test(bare) && !SUMMARY_LINE_RE.test(bare)
-  })
+    if (CONSOLE_CAPTURE_RE.test(bare)) { inCapture = true; pyWarnCtx = false; continue }
+    if (PY_WARNINGS_SECTION_RE.test(bare)) { inPyWarnings = true; pyWarnCtx = true; continue }
+    if (inPyWarnings) {
+      if (PY_SECTION_RE.test(bare)) inPyWarnings = false // 下一区段头（short test summary info 等）收区
+      continue // 区段内容（测试 id / 归因 / 源码展示行）：warning 噪声，非失败信号
+    }
+    const isReportLine = PASS_LINE_RE.test(bare) || REPORT_LINE_RE.test(bare) || SUMMARY_LINE_RE.test(bare)
+    if (inCapture && !isReportLine) continue // 捕获块内容行：console 噪声，非失败信号
+    if (isReportLine) inCapture = false
+    // ── Python/pytest 警告行级剔除（截断 tail 无区段头时的兜底）──
+    if (PY_WARNING_ATTR_RE.test(bare) || PY_WARNING_GROUP_RE.test(bare) || NODE_WARNING_RE.test(bare)) { pyWarnCtx = true; continue }
+    if (pyWarnCtx) {
+      if (isReportLine) pyWarnCtx = false // 报表行（含 short summary 区段头）终结 warning 上下文
+      else if (PY_TEST_ID_RE.test(bare) || /^\s{2,}\S/.test(bare) || bare.trim() === '') continue // 同块源码展示 / 测试 id / 组间空行
+      else pyWarnCtx = false
+    }
+    if (PASS_LINE_RE.test(bare)) continue
+    if (ENV_NOISE_RE.test(bare)) continue
+    if (PER_TEST_FAIL_RE.test(bare) && !SUMMARY_LINE_RE.test(bare)) failureLines.push(l)
+  }
   const pats = (knownFailures || []).map(p => String(p).toLowerCase()).filter(Boolean)
   const exempted = []
   const remaining = []

package/src/verify-probes.js

@@ -257,6 +257,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('| 状态 | 前端调用 | 后端端点 | 文件 |')

package/src/workflow.js

@@ -583,6 +583,10 @@ export function saveWorkflowRun(result, options = {}) {
     workflow: result.workflow,
     project: result.project,
     status: result.status,
+    // 坑 archive-batch-31-tool-notes ①：status 按步骤口径而非 workflow 整体口径时
+    // 标注来源（如 step:extract-module-impact——整体 status 因下一步角色恒 fail，见
+    // complete-handlers.js archive 分支注释），排查者据此区分「本步失败」与「口径说明」。
+    ...(result.status_scope ? { status_scope: result.status_scope } : {}),
     spec_version: result.spec_version,
     roles: result.roles,
     workflow_checks: result.workflow_checks,

package/src/worktree-apply.js

@@ -842,10 +842,10 @@ export function applyWorktree(changeName, { cwd, checkOnly = false, merge = fals
         const marker = `sillyspec apply ${changeName} --stash-dirty ${new Date().toISOString()}`;
         const before = (gitQuiet(projectRoot, ['stash', 'list']) || '').split('\n').filter(Boolean).length;
         // pathspec 限定 stash 范围与探针/4.5 同口径（排除 .sillyspec/ 运行时与他者 spec 产物、
-        // .claude/docs/CLAUDE.md）——裸 push -u 会把排除项的未跟踪文件一并卷走，恢复时与
+        // .claude/docs/CLAUDE.md/AGENTS.md）——裸 push -u 会把排除项的未跟踪文件一并卷走，恢复时与
         // apply 期间重建的 spec 文件 already exists 互踩（实证 dbg）。
         git(projectRoot, ['stash', 'push', '--include-untracked', '-m', marker,
-          '--', '.', ':(exclude).sillyspec/', ':(exclude).claude/', ':(exclude)docs/', ':(exclude)CLAUDE.md'], { timeout: 60000 });
+          '--', '.', ':(exclude).sillyspec/', ':(exclude).claude/', ':(exclude)docs/', ':(exclude)CLAUDE.md', ':(exclude)AGENTS.md'], { timeout: 60000 });
         const headEntry = ((gitQuiet(projectRoot, ['stash', 'list']) || '').split('\n')[0] || '');
         const after = (gitQuiet(projectRoot, ['stash', 'list']) || '').split('\n').filter(Boolean).length;
         const sha = gitQuiet(projectRoot, ['rev-parse', '--verify', 'stash@{0}']);
@@ -884,12 +884,12 @@ export function applyWorktree(changeName, { cwd, checkOnly = false, merge = fals
     // （这些文件 apply 前无未提交修改，还原 = apply 前状态），无关脏文件不在 patch/rollback 范围
     // 不受影响 → fail-safe，报错后 stash 重试即可。放行时 warning 提示此路径。
     // 排除非交付物的元数据/文档 churn（execute 自身改的 + 多操作者常改的 agent 指引/文档），
-    // 否则别人改 CLAUDE.md/docs/.claude → 判定 dirty → apply 误阻断（多操作者仓库高频踩坑）。
+    // 否则别人改 CLAUDE.md/AGENTS.md/docs/.claude → 判定 dirty → apply 误阻断（多操作者仓库高频踩坑）。
     // 注意：排除规则必须和 computeBaselineHash (worktree.js) 一致（虽已不比对 hash，仍用同一口径判当前 dirty）。
     if (meta.baselineHash) {
       // pathspec：`--` 结束选项，`.` 包含全部，后续 :(exclude) 排除非交付物元数据/文档 churn
       // （与 computeBaselineHash 同口径）。数组形式逐元素传递，:(exclude) magic 字面直传不经 shell。
-      const exclude = ['--', '.', ':(exclude).sillyspec/', ':(exclude).claude/', ':(exclude)docs/', ':(exclude)CLAUDE.md'];
+      const exclude = ['--', '.', ':(exclude).sillyspec/', ':(exclude).claude/', ':(exclude)docs/', ':(exclude)CLAUDE.md', ':(exclude)AGENTS.md'];
       const staged = gitQuiet(projectRoot, ['diff', '--cached', ...exclude]) || '';
       const unstaged = gitQuiet(projectRoot, ['diff', ...exclude]) || '';
       const untracked = gitQuiet(projectRoot, ['ls-files', '--others', '--exclude-standard', ...exclude]) || '';

package/src/worktree.js

@@ -226,9 +226,9 @@ export function computeBaselineHash(cwd) {
   //   - .sillyspec/：brainstorm/plan 蓝图 + runtime 产物
   //   - .claude/：agent 配置/skills/CLAUDE.md（多操作者 agent 指引 churn）
   //   - docs/：文档（非代码交付物）
-  //   - CLAUDE.md：根 agent 指引（多操作者常改）
+  //   - CLAUDE.md / AGENTS.md：根 agent 指引（多操作者常改；AGENTS.md 为内容源、CLAUDE.md 为指针）
   // 必须和 applyWorktree step 4.5 (worktree-apply.js) 使用相同的排除规则。
-  const exclude = ['--', '.', ':(exclude).sillyspec/', ':(exclude).claude/', ':(exclude)docs/', ':(exclude)CLAUDE.md'];
+  const exclude = ['--', '.', ':(exclude).sillyspec/', ':(exclude).claude/', ':(exclude)docs/', ':(exclude)CLAUDE.md', ':(exclude)AGENTS.md'];
   const staged = gitQuiet(cwd, ['diff', '--cached', ...exclude], { timeout: 30000 }) || '';
   const unstaged = gitQuiet(cwd, ['diff', ...exclude], { timeout: 30000 }) || '';
   const untracked = gitQuiet(cwd, ['ls-files', '--others', '--exclude-standard', ...exclude], { timeout: 30000 }) || '';
@@ -1632,7 +1632,9 @@ export class WorktreeManager {
   }
 
   /**
-   * DB 归档态探测（坑 doctor-reprovision-archived-change）：changes 表 status='archived'。
+   * DB 终态探测（坑 doctor-reprovision-archived-change）：changes 表 status='archived'
+   * （归档收尾）或 'deleted'（change-delete 删除，2026-08-30）——两种终态的 worktree 都是
+   * 死目录，doctor 一致跳过供给、fix 走 cleanup。
    * 只读直查（node:sqlite）——doctor 是同步方法，惰性动态 import 不可用；DB 不存在/无行/
    * 读失败 → false（保守退回普通 deps 供给路径）。
    * @param {string} name
@@ -1645,7 +1647,7 @@ export class WorktreeManager {
       const db = openDatabase(dbPath, { readOnly: true });
       try {
         const row = db.prepare('SELECT status FROM changes WHERE name = ?').get(name);
-        return row?.status === 'archived';
+        return row?.status === 'archived' || row?.status === 'deleted';
       } finally { try { db.close() } catch {} }
     } catch { return false }
   }

package/{.worktrees/542c4415/templates/claude-instruction.md → templates/agents-instruction.md}

@@ -1,4 +1,4 @@
-# Claude Code 指引
+# Agent 指引
 
 ## 项目说明
 本项目使用 **SillySpec** 管理变更，采用文档驱动开发。SillySpec 是给 Agent 调用的 CLI 流程控制器，不是给人类直接使用的产品，也不是处理业务逻辑的工具——你（Agent）通过 CLI 告诉它"我在哪"，它告诉你"下一步做什么"；你执行步骤，它校验产出、推进状态，人类只在关键决策点介入审批。要考虑多 agent 同时操作代码，代码随时可能变化。所有变更以稳定、可用、可维护为目标，按生产级标准处理。
@@ -15,7 +15,7 @@
 9. **中途停下不靠额外命令存进度**——进度已由上一次 `--done` 自动落盘；恢复时用 `sillyspec progress show` 查看进度，再用 `sillyspec run <stage>` 续跑，不直接 commit 半成品。
 10. **实现完成后对照文档验收**（design.md / 模块文档），并检查是否影响已有测试。
 11. **非测试逻辑本身有误时，禁止改测试来"通过"**——修逻辑，不修测试。
-12. **hook 拦截提交时禁止跳过**（`.husky/pre-push`），修复问题后再提交。
+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` 后按需核对即可，勿手拼模板。

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