sillyspec 3.27.6 → 3.27.9

package/.worktrees/2c37b1d7/src/stages/archive.js

@@ -0,0 +1,199 @@
+export const definition = {
+  name: 'archive',
+  title: '归档变更',
+  description: '规范沉淀，可追溯',
+  steps: [
+    {
+      name: '任务完成度检查',
+      prompt: `检查任务完成度，决定是否可归档。
+
+### 客观完成度报告（CLI 已注入，勿自行数 checkbox）
+{TASK_COMPLETION_REPORT}
+
+### 判定规则
+- **真相源 = review.json verdict**：上方报告由 CLI 从 .runtime/execute-runs/<runId>/tasks/task-NN/review.json 的 specVerdict + qualityVerdict 算出。
+- tasks.md 的 - [x] checkbox **仅作显示态参考**：它依赖自动回填，runId marker / review 缺失时会停在未勾态，与客观 verdict 不一致时**以本报告为准**，不要被未勾 checkbox 误导。
+- 报告「未通过 / 缺失」= 0 且 source 为 review.json → 完成度合格，进入下一步。
+- 报告含「cannot_verify 草稿（未真正复核）」计数 > 0 → 这些 task 只有 cannot_verify 草稿兜底、未被真正复核：先确认 verify 阶段已兑现其 requiredEvidence（verify-result.md 有对应证据），缺证据的派独立子代理对照 task brief + git diff 补真实复核（升级为 pass/fail），勿静默放行。
+- 报告 source 为 plan-checkbox-fallback（客观源不可用）→ 完成度无法客观确认，**必须暂停**让用户交叉核对，不要直接放行。
+- 存在未完成任务 → **必须暂停等待用户决定**，不要自行判断"可以归档"。
+   - 调用：sillyspec run archive --wait --reason "存在未完成任务，是否继续归档" --options "继续归档,回到execute完成剩余任务" --output "未完成任务列表"
+
+### 输出
+完成度报告（已通过/总数 + 数据源 + 未完成任务列表）`,
+      outputHint: '完成度报告',
+      optional: false
+    },
+    {
+      name: 'extract-module-impact',
+      prompt: `最终确认 changes/<change>/module-impact.md（本次变更的模块影响分析）。该文档由 plan review_plan 步生成首版、execute 各 Wave 更新、verify 核对——本步是归档前最后一次确认（module-impact 已非 archive 生成，改活文档终审）。
+
+### 操作
+1. 读取 changes/<change>/module-impact.md（应已存在；large 变更 plan 阶段产出首版）
+2. 运行 git diff --name-only HEAD~1（或 git diff --name-only --cached）获取真实修改文件列表
+3. 三重核对：module-impact.md 记录的受影响模块/文件 vs 真实 git diff 文件列表 vs .sillyspec/docs/<project>/modules/_module-map.yaml 模块映射（不存在则仅核 unmapped 部分）。以 git diff 为准（真实 > 记录）
+4. 发现不一致（漏标受影响模块 / 影响类型错误 / 实际未触碰的模块被误标）→ 直接修正 module-impact.md，使其与实际变更一致
+5. module-impact.md 第一行标题必须用中文：# 模块影响分析（Module Impact）— <变更简述>
+
+### 降级（module-impact.md 不存在）
+若缺失（如旧变更未经新 plan 流程，或 small 变更从未生成）：先跑 \`sillyspec module-impact --change <change-name>\`——CLI 按 _module-map.yaml paths 前缀匹配预填「模块影响矩阵」骨架（文件×模块归属 + 未匹配文件清单，机械部分全代算），你只需逐行填「影响类型」（逻辑变更/数据结构变更/接口变更/调用关系变更/配置变更/新增）与 needs_review 标记，补首行中文标题 \`# 模块影响分析（Module Impact）— <变更简述>\`。骨架无从生成（无 module-map / 无 diff）时才按 archive-impact.yaml 的 impact-analyzer 角色规则全手写。
+
+确认完成后，下一步 sync-module-docs 会读 module-impact.md 更新模块卡片文档。`,
+      outputHint: 'module-impact.md 终审结果 + 修正摘要',
+      optional: false
+    },
+    {
+      name: 'sync-module-docs',
+      // conditionalWait（坑 archive-subconfirm-redundant，2026-08-23 实证：requiresWait 硬门强制
+      // 三段式 --wait → --continue --answer → --done，与 verify 文档同步阻断门、归档移动前死信
+      // 校验、下一步「确认归档 --confirm」四层确认重复，交互碎。改 conditionalWait（brainstorm-auto
+      // 同款先例）：常规同步直接写入 + --done（agent 写入动作在 --done 前完成，坑 verify-archive-
+      // flow-pitfalls 坑4 的「无机会写入」不回归）；仅异常（needs_review/未映射/标记缺失）才 --wait
+      // 请用户裁决。用户确认收敛到「确认归档 --confirm」一处。
+      conditionalWait: true,
+      repeatableWait: true,
+      maxWaitRounds: 3,
+      waitReason: '等待用户裁决模块文档同步异常',
+      waitOptions: ['确认写入', '跳过同步'],
+      prompt: `根据 module-impact.md 同步更新模块索引和卡片文档。
+
+### ⚠️ 核心原则：结构化事实改 _module-map.yaml，语义解释改模块卡片
+- \`_module-map.yaml\` 是唯一的结构化索引源（paths/tags/entrypoints/depends_on/used_by/status/needs_review）
+- 模块卡片只负责语义说明（定位/契约摘要/关键逻辑/注意事项/人工备注）
+- 一个信息只维护一次，不要两边重复
+
+### 操作
+1. 读取 \`.sillyspec/changes/<change-name>/module-impact.md\`
+2. 如果没有受影响模块（只有 unmapped）→ 提示用户，跳过同步
+3. 对每个受影响模块，按影响类型分别更新：
+
+#### 更新 _module-map.yaml 的规则
+- **路径变化** → 更新对应模块的 paths
+- **依赖变化** → 更新 depends_on / used_by（同时更新反向模块的 used_by / depends_on）
+- **导出符号变化** → 更新 entrypoints / main_symbols
+- **新增模块** → 添加完整条目
+- **模块废弃** → status: deprecated
+- **不确定的影响** → needs_review: true, review_reasons 追加原因
+- 如果 _module-map.yaml 的 generated_at 已过时，更新为当前时间
+
+#### 更新模块卡片（modules/<module-id>.md）的规则
+- **契约语义变化**（新增/删除对外能力） → 更新"契约摘要"
+- **关键逻辑变化** → 更新"关键逻辑"
+- **边界变化**（模块职责扩大/缩小） → 更新"定位"
+- **注意事项变化** → 更新"注意事项"
+- **内部实现变化**（不影响对外接口） → 通常不更新卡片
+- **人工备注** → 永远保护，不覆盖
+
+#### 人工备注保护
+1. 用正则提取 \`<!-- MANUAL_NOTES_START -->\` 到 \`<!-- MANUAL_NOTES_END -->\` 之间的内容
+2. 生成新卡片后，原样回填到人工备注区域
+3. 如果标记缺失或重复 → 在 _module-map.yaml 中标记 needs_review: true
+
+#### 新建模块卡片模板
+一级标题格式 \`# <中文名>（<module-id>）\`——中文名从模块职责提炼 2-8 字，括号内保留 module-id 原样（sillyhub 平台解析识别用，与 scan 生成约定一致）。frontmatter 已带 author/created_at 真值（<git-user>/<now-datetime> 占位符由 CLI 每步替换），照抄即过元数据校验、勿删。
+\`\`\`markdown
+---
+schema_version: 1
+doc_type: module-card
+module_id: <module-id>
+author: <git-user>
+created_at: <now-datetime>
+---
+
+# <中文名>（<module-id>）
+
+## 定位
+
+## 契约摘要
+
+## 关键逻辑
+
+## 注意事项
+
+## 人工备注
+
+<!-- MANUAL_NOTES_START -->
+
+<!-- MANUAL_NOTES_END -->
+\`\`\`
+
+4. 展示所有更新内容（diff 摘要），按同步状态分流：
+   - **常规**（无 needs_review 影响、无 unmapped 模块、人工备注标记齐全）→ **直接写入** _module-map.yaml 和受影响的模块卡片，diff 摘要写入 --output 后 --done（本步不单独弹确认——用户确认收敛到下一步「确认归档 --confirm」，该步展示同一 diff 摘要）
+   - **异常**（含 needs_review 影响项 / unmapped 模块 / 人工备注标记缺失或重复 / 覆盖会丢失手动维护字段）→ 暂停请用户裁决：
+     \`sillyspec run archive --wait --reason "等待用户裁决模块文档同步异常" --options "确认写入,跳过同步" --output "diff 摘要 + 异常说明"\`
+     用户 --continue --answer "确认写入" 后写入；"跳过同步" 则不写入，提示 "module-impact.md 已保留，可稍后手动同步"
+5. 回填 module-impact.md 的"更新结果"表格，区分目标：
+   - 目标列写 "\`_module-map.yaml: <module-id>\`" 或 "\`modules/<module-id>.md\`"
+6. **同步完成后**，如需刷新 \`_module-map.yaml\` 索引：\`sillyspec modules rebuild --force\`（默认 dry-run 只预览不写；\`--force\` 才覆盖，但会清空 tags/entrypoints/main_symbols/depends_on/used_by 等手动维护字段——与 archive-impact 的「人工备注保护」约束冲突，仅当手动字段已并入骨架或可接受覆盖时用；优先手动更新 dependencies.md / 模块卡片）
+
+### 输出
+已更新的文件路径列表 + diff 摘要（异常时附裁决结果）`,
+      outputHint: '模块文档更新结果',
+      optional: false
+    },
+    {
+      name: 'decision-distill 决策提炼',
+      // conditionalWait（同 sync-module-docs 先例）：常规提炼直接写入 + --done；仅异常（rejected
+      // 条目缺否决理由/复潮条件 → distillIntoKnowledge 返回 needsWait 非空）才 --wait 请用户裁决
+      // （补录后重跑幂等 / 跳过该条）。勿引入 requiresWait 硬门——与下一步「确认归档 --confirm」
+      // 重复确认（坑 archive-subconfirm-redundant）。
+      conditionalWait: true,
+      repeatableWait: true,
+      maxWaitRounds: 3,
+      waitReason: '等待用户裁决 rejected 决策缺字段',
+      waitOptions: ['补录后继续', '跳过该条'],
+      prompt: `读取变更 decisions.md，把有实现影响的决策提炼进决策知识库（提炼/幂等/INDEX 路由行本体在 CLI 纯函数 src/decision-distill.js，本步只接线，勿手工改写条目格式）。
+
+### 操作
+1. 定位参数：changeDir = \`.sillyspec/changes/<change-name>\`（decisions.md 所在——本步在「确认归档」移动目录之前，仍在原位）；knowledgeRoot = \`.sillyspec/knowledge\`；headHash = \`git rev-parse --short HEAD\`（落条目「最近确认」）
+2. 调用纯函数 \`distillIntoKnowledge(changeDir, knowledgeRoot, headHash)\`，按返回的 \`{ written, skipped, needsWait }\` 分流（见第 3 点）：
+   - 能解析到 sillyspec 源码/安装位置时（如 sillyspec 仓内 dogfood）直接 import 调用：\`node --input-type=module -e "import { distillIntoKnowledge } from './src/decision-distill.js'; console.log(JSON.stringify(distillIntoKnowledge(changeDir, knowledgeRoot, headHash), null, 2))"\`
+   - 解析不到（consumer 仓库无源码，node import 会 ERR_MODULE_NOT_FOUND）→ 按其语义执行：解析 D-xxx@vN 条目；入选规则 = 任意 type 的 status=rejected 留痕 + 五类 type（architecture/compatibility/boundary/definition/process）且 status∈{confirmed,accepted} 提炼 implemented，type=scope 不入选；条目幂等落 \`.sillyspec/knowledge/decisions/<模块域>.md\`（同 ID 同版本重写不重复追加、@vN+1 整段替换旧版并注 supersedes；「模块域」缺失按 impacts 路径与 _module-map.yaml paths 前缀匹配兜底，仍未中归 unmapped）；implemented 条目写「状态：implemented + 锚点：<src 路径:行号，未记录则填"未记录"> + 最近确认：<headHash> + 理由：<一句话>」，rejected 条目写「状态：rejected + 否决理由： + 复潮条件：」；\`knowledge/INDEX.md\` 的 decisions 路由行（\`- <域>|decision|决策 → [decisions/<域>.md](decisions/<域>.md)\`）幂等增删
+3. 分流规则：
+   - **常规**（needsWait 为空且 written 非空）→ 写入已由函数完成，written 摘要（decisions/<域>.md × D-xxx@vN × append/update/supersede）写入 --output 后直接 --done（本步不单独弹确认——用户确认收敛到下一步「确认归档 --confirm」）
+   - **needsWait 非空**（rejected 条目缺否决理由/复潮条件，该条目未写盘、其余条目照常提炼）→ 暂停请用户裁决：
+     \`sillyspec run archive --wait --reason "等待用户裁决 rejected 决策缺字段" --options "补录后继续,跳过该条" --output "needsWait 描述 + 已提炼摘要"\`
+     - 「补录后继续」→ 按 needsWait 描述在 changes/<change-name>/decisions.md 补齐缺失的否决理由/复潮条件，重跑第 2 步（幂等，重跑安全）
+     - 「跳过该条」→ 该条目不入库，--output 注记跳过原因后 --done
+   - **零输出**（skipped 非空 = 无 decisions.md / 无入选条目）→ 不创建任何文件、不动 INDEX，--output 注一句 skipped 原因后直接 --done（同 docs-debt 无债零输出原则）
+4. 降级：调用或解析异常（模块加载失败 / decisions.md 结构异常抛错）→ warn 记录异常摘要后跳过本步 --done（best-effort，同 agent-session-log 先例），不阻断归档——决策提炼失败不挡归档移动
+
+### 输出
+已提炼条目清单（decisions/<域>.md × D-xxx@vN × action）或零输出/跳过/降级原因`,
+      outputHint: '决策提炼结果',
+      optional: false
+    },
+    {
+      name: '确认归档',
+      prompt: `确认归档内容，由 CLI 执行目录移动。
+
+### 操作
+1. 展示：变更目录名、包含的文件列表（含 module-impact.md）、生成总结
+2. 确保任务清单（tasks.md）所有 task checkbox 都已勾选
+3. 让用户确认后，用 \`--confirm\` 完成本步骤：
+   \`sillyspec run archive --done --confirm --output "确认归档"\`
+4. CLI 会创建 \`.sillyspec/changes/archive/\`，并将变更目录移动到 \`.sillyspec/changes/archive/<原变更名>/\`
+
+### 输出
+归档完成 + archive 目录路径`,
+      outputHint: '归档确认',
+      optional: false
+    },
+    {
+      name: '更新路线图和提交',
+      prompt: `更新路线图并暂存变更。
+
+### 操作
+1. 如果 \`.sillyspec/ROADMAP.md\` 存在，标记对应 Phase 为已完成
+2. \`git add .sillyspec/changes/archive/\` — 暂存归档结果（archive/ 下仅本次归档新增，不会裹挟 changes/ 下其他活跃变更；不要 commit，由用户通过统一提交工具处理）
+3. \`git add .sillyspec/docs/<project>/modules/\` — 暂存模块文档更新（如有；精确到本次同步的模块文档，勿 add 整个 .sillyspec/docs/）
+4. \`git add .sillyspec/knowledge/decisions/\` — 暂存决策知识库更新（如有；decision-distill 步骤的提炼产物，精确到 decisions 子目录，勿 add 整个 .sillyspec/knowledge/；不要 commit，由用户通过统一提交工具处理）
+5. 确认 sillyspec.db 中该变更已不再 active（确认归档步骤由 CLI 调用 unregisterChange）
+
+### 输出
+归档完成确认 + 累积规范统计`,
+      outputHint: '归档完成',
+      optional: false
+    }
+  ]
+}

package/.worktrees/2c37b1d7/src/stages/brainstorm-auto.js

@@ -0,0 +1,285 @@
+/**
+ * brainstorm-auto.js — auto/full 模式使用的 brainstorm 步骤定义
+ *
+ * 与 brainstorm.js 的区别：
+ * 1. artifact-first：直接写文件，对话只输出摘要
+ * 2. 自动决策：基于 AC-001~AC-011 checklist，不频繁请示
+ * 3. next-action.json：结构化产物，驱动下游推进
+ * 4. 只有 blocking questions 才 wait 用户
+ * 5. 步骤从 ~13 步精简为 4 步
+ */
+
+export const definition = {
+  name: 'brainstorm',
+  title: '头脑风暴（自动模式）',
+  description: '探索需求、分析技术方案、识别风险 — artifact-first，自动决策优先',
+
+  steps: [
+    {
+      name: '进度确认与上下文加载',
+      migratedFrom: ['状态检查与上下文加载'],
+      prompt: `检查进度、加载项目上下文、匹配模块。用 \`sillyspec progress show\` 查流程进度，不要用 \`sillyspec status\`（项目级快照，不推进流程）。
+
+### 操作
+1. 运行 \`sillyspec progress show\`，确认 currentStage 为 "brainstorm"
+2. 如果未初始化，提示先运行 sillyspec init
+3. **检查变更名称**：如果当前变更名是自动生成的（如 \`2026-06-02-new-change-a3f2b7c1\`），直接重命名为有意义名称，然后运行 \`sillyspec change-rename <旧名> <新名>\`
+
+### 加载上下文
+4. 读取项目总览 \`.sillyspec/docs/<project>/scan/PROJECT.md\`（如存在）+ 共享规范 + 子项目上下文
+5. 加载项目信息：\`cat .sillyspec/projects/*.yaml 2>/dev/null\`
+6. 加载本地配置：\`cat .sillyspec/local.yaml 2>/dev/null\`
+7. 棕地项目：读取 scan 下的 STRUCTURE.md、CONVENTIONS.md、ARCHITECTURE.md
+8. 加载模块索引：读取 \`.sillyspec/docs/<project>/modules/_module-map.yaml\`（如存在）
+9. 查看进行中的变更：\`ls .sillyspec/changes/ | grep -v archive\`
+10. 检查同名变更或可复用模板
+
+### 模块匹配
+根据用户描述的需求关键词，匹配相关模块（用 _module-map.yaml 的 tags/aliases/paths）。
+
+### 子项目判定
+- 单项目：直接确认
+- 多项目且用户已指定：直接确认
+- 多项目且用户未指定：列出项目列表，需要用户确认
+
+### 如果有用户提供的原型/截图
+分析提取：页面结构、表单字段、交互流程、业务规则。
+
+### 输出
+状态摘要 + 项目现状理解（3-5 句）+ 涉及模块列表 + 子项目 + 原型分析（如有）
+
+### 注意
+- 以 CLI 返回为准，不要自行推断阶段
+- 不要用 mv 命令重命名变更目录，必须用 \`sillyspec change-rename\``,
+      outputHint: '状态摘要 + 上下文 + 模块匹配',
+      optional: false
+    },
+    {
+      name: '需求分析与方案设计',
+      // conditionalWait（非 requiresWait）：与主模式 Step3 对齐。prompt 明确「目标明确→跳过追问，
+      // 直接进入方案设计」「checklist 全 ✅ → AUTO_DECIDED」——这两种场景 AI 无需追问，必须能直接 --done。
+      // 若用 requiresWait，CLI 硬门强制要 --answer（complete.js:223），AI 只能伪造 --answer「无需追问」
+      // （正是 Grill 第三病）或 --wait 一个不存在的问题。conditionalWait 让「无需追问」路径直接 --done，
+      // 只在真正需要用户决策（方案选择/拆分确认）时才走 --wait（multi-agent-review B1）。
+      conditionalWait: true,
+      repeatableWait: true,
+      maxWaitRounds: 5,
+      waitReason: '等待用户回答需求问题',
+      waitOptions: ['回答见--answer', '信息够了，进入设计'],
+      prompt: `分析需求，必要时追问，然后设计方案。
+
+### 操作
+
+#### A. 需求评估
+1. 汇总上一步加载的上下文和用户需求
+2. 判断需求是否清晰：
+   - 目标明确、范围清楚、无歧义 → 跳过追问，直接进入方案设计
+   - 有歧义或不清楚 → 挑**一个最关键的**问题追问
+
+#### B. 追问规则（只在需要时）
+- 一次只问一个问题，不要一次性列出多个问题
+- 能从代码/文档确认的不要问用户
+- 多选题优于开放式问题
+- YAGNI — 砍掉不需要的功能
+- 2-3 轮问答就应进入方案设计
+- 优先追问影响架构/数据/接口的问题，实现细节不要问
+
+**如果需要追问：**调用 \`sillyspec run brainstorm --wait --reason "等待用户回答需求问题" --options "回答见--answer,信息够了,进入设计" --output "你的单个问题"\`
+
+#### C. 复杂度评估（追问结束后或不需要追问时）
+1. 判断是否需要拆分或走批量模式：
+   - 3+ 个可独立交付的功能模块 → 建议拆分
+   - 任务 > 10 且有重复模式 → 建议批量模式
+   - 简单 CRUD → 不拆
+2. 如果需要拆分/批量模式：暂停等用户确认
+   - 调用：\`sillyspec run brainstorm --wait --reason "等待用户确认拆分方案" --options "同意拆分,不需要拆分,走批量模式" --output "拆分方案摘要"\`
+3. 不需要拆分 → 继续
+
+#### D. 方案设计（自动决策优先）
+1. 基于需求理解和上下文，提出 1-3 种实现方案
+2. **使用自动决策 checklist（AC-001~AC-011）判断是否需要用户选择：**
+
+\`\`\`
+AC-001: 未修改公共 API
+AC-002: 未修改数据库 schema
+AC-003: 未涉及鉴权/权限
+AC-004: 未扩大 allowed_paths
+AC-005: 未引入新外部依赖
+AC-006: 未修改核心模块（workflow/daemon/session/lifecycle）
+AC-007: 已有项目约定可复用
+AC-008: 不影响向后兼容
+AC-009: 不涉及数据迁移
+AC-010: 单模块范围内可完成
+AC-011: 不涉及业务规则/产品范围/默认行为/用户可见行为变更
+\`\`\`
+
+3. **自动决策判定：**
+   - 只有一个明显合理方案 + checklist 全部 ✅ → **自动选择，标记 AUTO_DECIDED**
+   - 有多个方案但影响不大（checklist 全部 ✅）→ **自动选推荐方案，标记 AUTO_DECIDED**
+   - 有多个方案且 checklist 有 ❌（影响架构/数据/接口/权限/兼容性/业务）→ **只有这一种情况才暂停等用户选择**
+
+4. 如果需要用户选择方案：
+   - 调用：\`sillyspec run brainstorm --wait --reason "等待用户选择方案" --options "方案A,方案B,方案C" --output "方案对比摘要"\`
+
+#### E. Design Grill（轻量交叉审查）
+对方案做快速交叉审查：
+- 检查方案与 ARCHITECTURE.md / CONVENTIONS.md 的一致性
+- 检查是否有术语歧义、边界遗漏
+- 能自动解决的直接修正，只有需要业务判断的才问用户
+- 跳过条件：单模块、无状态流转、< 3 个文件变更
+
+### 输出
+需求理解摘要 + 复杂度评估 + 方案决策（AUTO_DECIDED 或用户选择）
+
+### 注意
+- **不要自问自答。** 不要在自己输出中模拟用户回答然后说"需求已明确"
+- checklist 判定结果必须在 decisions.md 中记录依据`,
+      outputHint: '需求理解 + 方案决策',
+      optional: false
+    },
+    {
+      name: '生成设计产物',
+      prompt: `将设计方案写入文件（artifact-first），不回显正文。
+
+### 操作
+1. 确保变更目录存在：\`mkdir -p .sillyspec/changes/<change-name>\`
+2. **直接将设计方案写入文件，不要先在对话中输出完整内容再写文件。**
+3. 产物写入**变更根目录**（\`.sillyspec/changes/<change-name>/\`），不要建 \`brainstorm/\` 子目录——stage validator 只认根目录，写进子目录会在 \`--done\` 校验时被判产物缺失。
+
+### 产物文件
+
+#### design.md（必填，写入变更根目录 \`design.md\`）
+包含：背景、设计目标、非目标、总体方案、文件变更清单、接口定义、数据模型（如涉及）、兼容策略（brownfield）、风险登记、决策追踪、自审。
+**章节骨架必须按下述字面格式写**（校验器按字面短语匹配，措辞偏离会连环卡门——坑 literal-template-trap，2026-08-24 用户反馈五期②）：
+\`\`\`markdown
+# 设计文档（Design）— <变更简述>
+
+## 背景
+<为什么做、解决什么问题>
+
+## 设计目标
+<要达成什么>
+
+## 非目标
+<明确不做的事——标题必须字面含「非目标」（Non-Goals 也认，但大小写须完全一致）>
+
+## 总体方案
+<技术方案>
+
+## 文件变更清单
+| 操作 | 文件路径 | 说明 |
+|---|---|---|
+| 新增 | src/xxx/NewFile.ts | ... |
+| 修改 | src/xxx/ExistingFile.ts | ... |
+
+## 生命周期契约表
+<仅当涉及 session/lease/agent_run/daemon/lifecycle/state_transition/claim/heartbeat 关键词时必填；
+若不涉及，删掉本节或在正文写紧邻豁免短语：「不涉及生命周期契约」或「生命周期契约：无/N/A」
+——「无需 lifecycle 事件」这类宽写法不被识别（否定词必须紧邻「生命周期契约/lifecycle contract」）>
+
+| 事件 | 发起方 | 接收方 | 必需字段 | 状态变化 |
+|---|---|---|---|---|
+| <事件名> | <发起方> | <接收方> | <字段清单> | <初始态 → 终态> |
+
+## 风险登记
+| 编号 | 风险 | 等级 | 应对策略 |
+|---|---|---|---|
+| R-01 | ... | P0/P1/P2 | ... |
+
+## 决策追踪
+<列出 D-xxx@vN 决策 ID 及覆盖关系；无决策可写「无」>
+
+## 自审
+<对自身设计的校验——标题必须字面含「自审」或「Self-Review」（自我审查等宽写法不识别）>
+\`\`\`
+
+#### decisions.md（必填，写入变更根目录 \`decisions.md\`）
+记录所有决策：
+\`\`\`markdown
+---
+author: <git-user>
+created_at: <now-datetime>
+---
+
+# 决策记录（Decisions）
+
+## D-001@v1: 决策短标题
+- type: architecture | boundary | compatibility | ...
+- priority: P0 | P1 | P2
+- status: AUTO_DECIDED | NEEDS_REVIEW | USER_DECIDED
+- source: user | code | docs
+- question: 被解决的问题
+- answer: 选择或结论
+- checklist: AC-001 ✅, AC-007 ✅（AUTO_DECIDED 时必须列出）
+- normalized_requirement: 可测试约束
+- impacts: [FR-01, task-01]
+- evidence: 代码/文档路径或用户回答轮次
+\`\`\`
+
+#### gaps.md（必填，写入变更根目录 \`gaps.md\`）
+记录已识别的缺口。status=BLOCKER 的缺口会在 plan-postcheck 中触发回退。
+
+#### assumptions.md（必填，写入变更根目录 \`assumptions.md\`）
+记录隐含假设和验证方法。
+
+#### next-action.json（必填，写入变更根目录 \`next-action.json\`）
+\`\`\`json
+{
+  "status": "ready_for_plan" | "waiting_for_user",
+  "decision_level": "high" | "medium" | "low",
+  "has_blocking_questions": true | false,
+  "blocking_reasons": [],
+  "questions": [],
+  "auto_decisions": [
+    { "id": "D-001", "decision": "方案描述", "reason": "AC-007 ✅" }
+  ]
+}
+\`\`\`
+
+### 自审
+对 design.md 执行自审（需求覆盖、文件变更清单具体性、验收标准可测试、非目标清晰、兼容策略）。发现问题直接修改文件。
+
+### 如果有 blocking questions
+将问题写入 next-action.json.questions，在对话中输出问题列表和推荐选项，然后 --wait。
+
+### 输出（artifact-first）
+只输出摘要：
+\`\`\`
+已生成设计产物（5 个文件，均在变更根目录）：
+- design.md — 采用 xxx 方案，涉及 N 个文件变更
+- decisions.md — M 个决策，K 个 AUTO_DECIDED
+- gaps.md — J 个缺口，0 个 BLOCKER
+- assumptions.md — L 个假设
+- next-action.json — ready_for_plan / waiting_for_user
+\`\`\``,
+      outputHint: '产物摘要',
+      optional: false
+    },
+    {
+      name: '生成规范文件',
+      requiresWait: true,
+      waitReason: '等待用户最终确认',
+      waitOptions: ['确认', '需要修改', '推翻重来'],
+      prompt: `生成 proposal.md / requirements.md / tasks.md，让用户确认。
+
+### 操作
+1. 基于变更根目录下的设计产物（design.md / decisions.md / gaps.md / assumptions.md / next-action.json），生成规范文件（直接写入变更根目录）：
+   - **proposal.md**：动机、关键问题、变更范围、不在范围内、成功标准
+   - **requirements.md**：角色表 + FR 编号需求 + Given/When/Then + 非功能需求
+   - **tasks.md**：任务列表骨架（只列名称；任务清单唯一真相，plan 阶段展开细节并写回本文件——execute 勾选与 verify 对照都在本文件）
+2. 所有规范文件头部包含 YAML frontmatter
+3. \`git add {SPEC_ROOT}/changes/<change-name>/\` — 暂存本变更的规范文件（勿用 .sillyspec/ 整目录——会裹挟其他活跃变更；不要 commit）
+
+### 输出（摘要）
+规范文件路径列表（各一句话说明）
+
+### 铁律
+- **直接写文件，不在对话中输出完整内容**
+- 暂停等待用户确认：\`sillyspec run brainstorm --wait --reason "等待用户最终确认" --options "确认,需要修改,推翻重来" --output "规范文件摘要"\`
+- 禁止自动 commit
+- 禁止在确认前推进到后续阶段`,
+      outputHint: '规范文件摘要',
+      optional: false
+    }
+  ]
+}