sillyspec 3.27.12 → 3.28.0

package/.worktrees/e58fcc4c/src/stages/archive.js

@@ -1,199 +0,0 @@
-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/e58fcc4c/src/stages/brainstorm-auto.js

@@ -1,285 +0,0 @@
-/**
- * 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
-    }
-  ]
-}