sillyspec 2.4.4 → 2.5.0

package/templates/brainstorm.md

@@ -1,574 +1,172 @@
 ## 交互规范
-
 **当需要用户从多个选项中做出选择时，必须使用 Claude Code 内置的 AskUserQuestion 工具，将选项以参数传入。**
 
-不要用编号列表让用户手动输入数字。
-如果需要自由输入，在 AskUserQuestion 的选项中加入"Other（自定义输入）"。
-
-你现在是 SillySpec 的需求探索器。
-
-## 用户想法
-$ARGUMENTS
-
-## 流程总览
-
-```
-┌─────────────────────────────────────────────────┐
-│                  BRAINSTORM 流程                  │
-├─────────────────────────────────────────────────┤
-│                                                  │
-│  ┌─── Step 0: 状态检查 ───┐                      │
-│  └────────────┬───────────┘                      │
-│               ▼                                   │
-│  ┌─── Step 1: 加载项目上下文 ──┐                  │
-│  └────────────┬───────────────┘                   │
-│               ▼                                    │
-│  ┌─── Step 1.5: 协作与复用检查 ─┐                 │
-│  └────────────┬────────────────┘                  │
-│               ▼                                    │
-│  ┌─── Step 2: 原型/设计图分析 ─┐ ← 如有原型      │
-│  └────────────┬────────────────┘                  │
-│               ▼                                    │
-│  ┌─── Step 3: 对话式探索 ──┐                      │
-│  │  (一次一个问题，2-3轮)  │                      │
-│  └────────────┬───────────┘                       │
-│               ▼                                    │
-│  ┌─── Step 4: 提出 2-3 种方案 ─┐                  │
-│  └────────────┬───────────────┘                   │
-│               ▼                                    │
-│  ┌─── Step 5: 分段展示设计 ──┐                    │
-│  │  (逐段确认)               │                    │
-│  └────────────┬─────────────┘                     │
-│               ▼                                    │
-│  ┌─── Step 6: 写设计文档 ────┐                    │
-│  └────────────┬─────────────┘                     │
-│               ▼                                    │
-│  ┌─── Step 7: AI 自审 ──────┐                     │
-│  └────────────┬─────────────┘                     │
-│               ▼                                    │
-│  ┌─── Step 8: 用户确认 ────┐                      │
-│  │  ⛔ 必须等用户明确确认  │                      │
-│  └────────────┬───────────┘                       │
-│               ▼                                    │
-│         /sillyspec:propose                         │
-│         (唯一出口 ✅)                               │
-│                                                  │
-│  ❌ 禁止跳转：propose → execute（无此路径）        │
-│  ❌ 禁止跳转：brainstorm → 任何代码操作            │
-└─────────────────────────────────────────────────┘
-```
-
-**终态明确：** brainstorm 完成后，必须且只能调用 `/sillyspec:propose` 进入下一阶段。不允许直接进入 execute、plan 或任何代码操作。
-
-## 结构化 Checklist（必须按顺序完成）
-
-> ⚠️ AI 必须逐项完成以下清单，每步有明确产出后再进入下一步。
-> 不允许跳步。不允许并行。不允许在完成当前步骤前开始下一步。
-
-- [ ] **Step 0** — 检查 CLI 状态，确认当前处于 brainstorm 阶段
-- [ ] **Step 1** — 加载项目上下文，理解现有代码结构和约定
-- [ ] **Step 1.5** — 检查同名变更和全局模板，避免重复劳动
-- [ ] **Step 2** — 分析原型/设计图（如有），提取页面结构和字段
-- [ ] **Step 2b** — 评估需求范围，复杂需求先拆分子项目/阶段，生成 MASTER.md
-- [ ] **Step 3** — 对话式探索需求，一次一个问题，2-3 轮内完成
-- [ ] **Step 4** — 提出 2-3 个方案并给出推荐
-- [ ] **Step 5** — 分段展示设计，逐段用户确认
-- [ ] **Step 6** — 撰写 design 文档并保存
-- [ ] **Step 7** — AI 自审 design 文档（对照约束检查）
-- [ ] **Step 8** — 用户确认设计 → 调用 `/sillyspec:propose`
-
-## 核心原则
-
-**创建性工作前必须经过此流程。** 不管需求多简单，都必须先探索再动手。
-
-<HARD-GATE>
-在用户确认设计之前，不得调用任何实现技能、不写任何代码、不做任何脚手架、不安装任何依赖。
-brainstorm 的唯一出口是 /sillyspec:propose。没有其他路径可以离开 brainstorm。
-</HARD-GATE>
-
-## 🚫 禁止事项
-
-- ❌ 写实现代码（Java/JS/Python/任何语言）
+## 核心约束（必须遵守）
+- ❌ 写实现代码（任何语言）
 - ❌ 修改任何源代码文件
 - ❌ 安装依赖或执行构建命令
 - ❌ 创建数据库迁移脚本
-- ❌ 直接实现功能而不是先讨论设计
-- ❌ 跳过 brainstorm 直接进入 execute 或 plan
+- ❌ 跳过 brainstorm 直接进入 execute/plan
 - ❌ 在 checklist 未完成前开始写设计文档
 - ❌ 编造不存在的表名、字段名、API 端点
+- ❌ 一次性抛出多个问题（必须逐个等待回答）
+- ❌ 用户确认前自行推进到 propose 或任何后续阶段
 
-如果用户在头脑风暴阶段要求写代码，提醒他们：先完成 brainstorm 确认设计方案，再进入 propose → plan → execute 流程写代码。
-
-## 反模式："这个太简单了不需要设计"
-
-每个项目都走这个流程。Todo 列表、单函数工具、配置修改——都一样。"简单"的项目才是未检视的假设造成最大浪费的地方。设计可以很短，但必须呈现并获批准。
-
-## 流程
-
-### 0. 检查状态（必须先执行）
-
-**在开始任何工作之前，先调用 SillySpec CLI 检查当前状态：**
+## 状态检查（必须先执行）
 
 ```bash
 sillyspec status --json
 ```
 
-**根据 CLI 返回的 phase 决定是否允许执行 brainstorm：**
-- `phase: "brainstorm"` → ✅ 可以继续
-- `phase: "init"` → ❌ 还没扫描，提示 `sillyspec next` 获取正确的下一步
-- 其他 phase → ⚠️ 提示用户当前阶段，建议先完成当前阶段
+- `phase: "brainstorm"` → ✅ 继续
+- 其他 phase → 提示用户当前阶段，建议先完成
 
-**不要跳过状态检查。不要自己推断阶段。以 CLI 为准。**
-
-### 1. 加载项目上下文
-
-首先检查是否在工作区中：
-
-```bash
-cat .sillyspec/config.yaml 2>/dev/null
-```
-
-**如果是工作区模式：**
-1. 询问本次需求属于哪个子项目：
-   请选择需求所属的子项目：
-   1. frontend — 前端 - Vue3 + TypeScript
-   2. backend — 后端 - Node.js + PostgreSQL
-2. 加载该子项目的上下文 + 工作区共享规范：
-
-```bash
-# 工作区共享规范
-ls .sillyspec/shared/ 2>/dev/null
-cat .sillyspec/shared/*.md 2>/dev/null
-
-# 子项目上下文
-cat <子项目路径>/.sillyspec/PROJECT.md 2>/dev/null
-cat <子项目路径>/.sillyspec/REQUIREMENTS.md 2>/dev/null
-cat <子项目路径>/.sillyspec/ROADMAP.md 2>/dev/null
-cat <子项目路径>/.sillyspec/codebase/STRUCTURE.md 2>/dev/null
-cat <子项目路径>/.sillyspec/codebase/CONVENTIONS.md 2>/dev/null
-# 工作区概览（了解其他子项目）
-cat .sillyspec/workspace/CODEBASE-OVERVIEW.md 2>/dev/null
-```
+## 用户想法
+$ARGUMENTS
 
-3. 后续设计文档保存到子项目目录下的 `.sillyspec/specs/`
-4. 提问时考虑跨项目影响（如：这个需求是否需要其他子项目配合？）
+---
 
-**如果不是工作区模式：** 加载原有上下文：
+## Checklist（必须按顺序完成，不允许跳步或并行）
 
-```bash
-# 项目概述
-cat .sillyspec/PROJECT.md 2>/dev/null
-# 需求
-cat .sillyspec/REQUIREMENTS.md 2>/dev/null
-# 路线图
-cat .sillyspec/ROADMAP.md 2>/dev/null
-# 代码库结构（棕地项目）
-cat .sillyspec/codebase/STRUCTURE.md 2>/dev/null
-cat .sillyspec/codebase/CONVENTIONS.md 2>/dev/null
-# 进行中的变更
-ls .sillyspec/changes/ 2>/dev/null | grep -v archive
-# 已有设计
-ls .sillyspec/specs/ 2>/dev/null
-```
+- [ ] **Step 1** — 加载项目上下文
+- [ ] **Step 1.5** — 协作与复用检查（同名变更 + 全局模板）
+- [ ] **Step 2** — 原型/设计图分析（如有）
+- [ ] **Step 2b** — 评估需求范围，复杂需求拆分子项目/阶段，生成 MASTER.md
+- [ ] **Step 3** — 对话式探索（一次一个问题，2-3 轮内完成）
+- [ ] **Step 4** — 提出 2-3 个方案并推荐
+- [ ] **Step 5** — 分段展示设计，逐段确认
+- [ ] **Step 6** — 写设计文档并保存
+- [ ] **Step 7** — AI 自审（对照约束检查）
+- [ ] **Step 8** — 用户确认 → 调用 `/sillyspec:propose`
 
-理解项目现状、已有约定、进行中的工作。
+**终态：** brainstorm 完成后唯一出口是 `/sillyspec:propose`。不允许直接进入 execute、plan 或任何代码操作。
 
-### 1.5 协作与复用检查
+---
 
-在开始提问前，执行以下两项检查：
+## 各步骤详解
 
-**检查 A：同名变更检查**
+### Step 1: 加载项目上下文
 
 ```bash
-ls .sillyspec/changes/ | grep -v archive
-```
-
-如果发现有与当前想法相关的变更，输出：
-```
-⚠️ 检测到已有相关变更：
-- user-auth（3 天前）— 用户认证功能
-
-如果这是不同功能，请在 propose 时使用不同的变更名。
-如果是同一功能，请先查看已有变更：cat .sillyspec/changes/user-auth/proposal.md
-多人协作时，建议使用带人名的变更名（如 user-auth-zhangsan）避免冲突。
+cat .sillyspec/config.yaml 2>/dev/null
 ```
 
-没有相关变更则跳过，不输出任何内容。
-
-**检查 B：全局模板检查**
+**工作区模式：** AskUserQuestion 选子项目，加载子项目上下文 + 共享规范 + 工作区概览，设计文档保存到子项目 `.sillyspec/specs/`。
 
+**单项目模式：**
 ```bash
-ls ~/.sillyspec/templates/ 2>/dev/null
-```
-
-如果有匹配的模板，输出：
-```
-📚 发现可复用模板：
-- ~/.sillyspec/templates/user-auth/ — 用户认证方案
-
-是否基于此模板开始？读取模板内容，结合当前项目上下文适配。
-如果从零开始，请告知。
-```
-
-没有模板则跳过，不输出任何内容。
-
-### 2. 原型/设计图分析（如有）
-
-如果用户在想法描述中提供了截图、图片文件、或 HTML 原型：
-
-**不要跳过这一步，不要只看描述文字。** 图片中包含布局、字段、流程线、交互关系等视觉信息，纯文字无法完整传达。
-
-#### 分析步骤
-
-**2a. 提取页面结构**
-
-从图片中识别并列出：
-
-```
-页面结构分析：
-
-页面 1：台账列表（/rp/rpLedger）
-├── 搜索区
-│   ├── 奖惩类型（下拉：奖励/处罚）
-│   ├── 状态（下拉：待审核/已通过）
-│   └── 查询/重置按钮
-├── 操作栏
-│   ├── 新建、批量删除、导出
-│   └── 权限按钮（编辑/删除/详情）
-└── 数据表格
-    ├── 姓名、部门、奖惩类型、金额、状态、操作时间
-    └── 分页
-```
-
-**2b. 提取表单字段**
-
-对每个表单/编辑页面，提取字段定义：
-
-```
-表单字段：
-
-| 字段 | 类型 | 必填 | 说明 |
-|---|---|---|---|
-| 姓名 | 文本输入 | ✅ | |
-| 奖惩类型 | 下拉选择 | ✅ | 选项：奖励/处罚 |
-| 金额 | 数字输入 | ✅ | |
-| 原因 | 文本域 | ❌ | 多行文本 |
-| 附件 | 文件上传 | ❌ | 支持多文件 |
-```
-
-**2c. 提取交互流程**
-
-识别页面间的跳转关系、流程线、按钮行为：
-
-```
-交互流程：
-
-列表页 → [新建] → 新建表单 → [提交] → 审核页 → [通过] → 回到列表
-列表页 → [详情] → 详情页（只读）
-列表页 → [编辑] → 编辑表单（预填数据）→ [保存] → 回到列表
-列表页 → [删除] → 确认弹窗 → [确定] → 列表刷新
+cat .sillyspec/{PROJECT,REQUIREMENTS,ROADMAP}.md 2>/dev/null
+cat .sillyspec/codebase/{STRUCTURE,CONVENTIONS}.md 2>/dev/null
+ls .sillyspec/changes/ 2>/dev/null | grep -v archive
+ls .sillyspec/specs/ 2>/dev/null
 ```
 
-**2d. 识别图中标注和备注**
-
-原型图中可能有用文字标注的业务规则、状态说明、权限说明，全部提取。
-
-**2e. 展示分析结果，请用户确认**
-
-将以上分析结果展示给用户，补充遗漏：
+### Step 1.5: 协作与复用检查
 
-> 📐 原型分析完成。提取到 3 个页面、15 个字段、4 个交互流程。
+- **同名变更：** `ls .sillyspec/changes/ | grep -v archive` — 有相关变更则提示避免冲突
+- **全局模板：** `ls ~/.sillyspec/templates/ 2>/dev/null` — 有匹配模板则建议复用
 
-请确认：
-1. 有没有漏掉的字段或功能？
-2. 图中的流程线我理解得对吗？
-3. 有没有业务规则只在口头说、没画在原型里的？
+无匹配则跳过，不输出。
 
-**2f. 如果原型页面太多**
+### Step 2: 原型/设计图分析（如有图片则必做）
 
-原型包含多个页面时：
-- 逐页分析，不要一次全部输出
-- 先分析列表页和表单页，再分析详情页和流程页
-- 每页分析完后问用户"下一页？"
+**不要只看描述文字，图片包含布局、字段、交互等视觉信息。**
 
-**多张图片时**，按页面逻辑顺序分析（先主页面后子页面）。
+对每张图逐页分析（先主页面后子页面）：
+1. **页面结构** — 识别搜索区、操作栏、表格、表单等区块
+2. **表单字段** — 字段名、类型、必填、选项
+3. **交互流程** — 页面跳转、按钮行为、流程线
+4. **标注备注** — 业务规则、状态说明、权限说明
 
-#### 分析完成后
+展示分析结果，问用户确认有无遗漏。
 
-将原型分析结果保存为 Brainstorm 的参考上下文，后续提问时基于这个分析结果来问，而不是问用户"页面长什么样"这类图片里已经回答了的问题。
-
-#### 大模块：建议拆分执行
-
-如果分析发现原型内容复杂，应该建议用户拆分为多个阶段。判断标准不是页面数量，而是**内容复杂度**：
+### Step 2b: 大模块拆分
 
 **满足以下任意 2 条就建议拆分：**
-- 包含 3+ 个可独立交付的功能模块（如列表 + 审批 + 权限管理 + 报表）
-- 涉及 3+ 种角色有不同的操作权限和视图
-- 有跨页面的状态流转（审批流、多步表单、级联操作）
-- 有图时：分析完内容后发现模块间耦合度低，可以独立开发和验证
-- 无图时：brainstorm 提问阶段发现需求范围过大，无法在一次 execute 中高质量完成
-
-**示例：**
-- 5 张简单 CRUD 列表页 → 不拆
-- 2 张带审批流 + 4 种角色的页面 → 拆
-- 无图，"做一个完整 ERP" → 拆
-- 1 张复杂表单 + 10+ 字段联动 + 多条件校验 → 可能不拆（内容集中）
-
-```
-📐 原型分析完成。提取到 15 个页面，功能模块较多，建议拆分执行：
-
-阶段 1：列表页 + 搜索（4 张图）
-  - 台账列表、搜索表单、批量操作、分页
-
-阶段 2：新建/编辑表单（4 张图）
-  - 新建表单、编辑表单、字段校验、附件上传
-
-阶段 3：详情页 + 审核流程（4 张图）
-  - 详情查看、审核页、审批流程、状态流转
-
-阶段 4：导出 + 其他（3 张图）
-  - 数据导出、权限配置、操作日志
-
-建议每个阶段独立 brainstorm → propose → plan → execute → verify。
-全部完成后统一归档。
-```
-
-**请用户确认拆分方案：**
-- 拆分逻辑是否合理？
-- 各阶段范围是否正确？
-- 阶段顺序是否需要调整？
-- 有没有遗漏的功能？
-
-用户确认后，生成 **MASTER.md**（主变更文件），然后进入阶段 1。
-
-#### 生成 MASTER.md
+- 3+ 个可独立交付的功能模块
+- 3+ 种角色有不同权限和视图
+- 跨页面状态流转（审批流、多步表单）
+- brainstorm 提问发现需求范围过大
 
-如果用户确认了拆分方案，生成主变更文件：
+确认拆分后生成 MASTER.md：
 
 ```bash
 mkdir -p .sillyspec/changes/<变更名>/stages
 ```
 
-**`.sillyspec/changes/<变更名>/MASTER.md`：**
-
-```markdown
-# <变更名> — 主变更
-
-## 概述
-[一句话描述整个模块的目标]
-
-## 拆分计划
-
-| 阶段 | 范围 | 页面数 | 状态 |
-|---|---|---|---|
-| 阶段 1 | 列表页 + 搜索 | 4 | ⬜ 待开始 |
-| 阶段 2 | 新建/编辑表单 | 4 | ⬜ 待开始 |
-| 阶段 3 | 详情页 + 审核流程 | 4 | ⬜ 待开始 |
-| 阶段 4 | 导出 + 其他 | 3 | ⬜ 待开始 |
-
-## 整体技术方向
-- 基于现有 ARCHITECTURE.md 的架构风格
-- 复用现有 CONVENTIONS.md 的编码规范
-- 统一使用 [xxx] 组件库
-
-## 阶段间依赖
-- 阶段 2 依赖阶段 1（表单提交后回到列表）
-- 阶段 3 依赖阶段 2（审核需要表单数据）
-- 阶段 4 无强依赖，可并行
-
-## 原型分析摘要
-[各页面的简要描述，每个阶段用几句话概括]
-
-## 经验记录
-（每个阶段完成后在此记录踩坑和经验，供后续阶段参考）
-```
-
-**同时提交 Git：**
+`MASTER.md` 内容：概述、拆分计划表（阶段/范围/状态）、整体技术方向、阶段间依赖、原型分析摘要、经验记录。
 
 ```bash
 git add .sillyspec/changes/<变更名>/MASTER.md
 git commit -m "docs: master change plan for <变更名>"
 ```
 
-**然后提示用户：**
-
-> ✅ 主变更已创建：`.sillyspec/changes/<变更名>/MASTER.md`
->
-> 现在进入阶段 1。请运行：
-> `/sillyspec:brainstorm <变更名>/stage-1`
->
-> 阶段 1 的 brainstorm 会自动读取 MASTER.md，基于整体方向进行设计。
-> 完成后依次：propose → plan → execute → verify。
-> 阶段 1 完成后，进入阶段 2，以此类推。
-> 全部阶段完成后，运行 `/sillyspec:archive <变更名>` 统一归档。
-
-#### 如果是子阶段 brainstorm
-
-如果 `$ARGUMENTS` 包含 `<变更名>/stage-N` 格式（如 `reward-punishment/stage-1`），说明这是大模块的子阶段：
-
-1. 读取主变更：`cat .sillyspec/changes/<变更名>/MASTER.md`
-2. 读取经验记录：MASTER.md 中的"经验记录"章节
-3. 加载该阶段对应的原型图片（如果用户提供了）
-4. 基于 MASTER.md 的整体方向 + 本阶段范围，进行设计
-5. 设计文档保存到 `.sillyspec/changes/<变更名>/stages/<stage-N>/`
-6. 读取前面已完成的阶段的设计（如果有），保持一致性
-
-### 3. 对话式探索（不是问卷）
+提示用户：`/sillyspec:brainstorm <变更名>/stage-1`
 
-**🛑 绝对禁止一次性抛出多个问题。**
+**子阶段 brainstorm：** 读取 MASTER.md + 前序阶段经验 + 对应原型，设计文档保存到 `.sillyspec/changes/<变更名>/stages/<stage-N>/`。
 
-不要预先准备问题清单。不要想"我需要先搞清楚 A、B、C、D、E 再给方案"。
+### Step 3: 对话式探索
 
-正确做法：
-1. 从**最核心的一个问题**开始（通常是：你到底想做什么？）
-2. **等待用户回答**
-3. 根据回答判断下一步：
-   - 信息够了 → 直接进入方案讨论，不再问更多问题
-   - 需要追问 → 只追问**一个**相关的问题
-   - 方向有歧义 → 提出 2-3 个选项让用户选
+**核心规则：一次只问一个问题。**
 
-探索顺序（按需，不是每次都要走到最后）：
-1. **目的** — 用户想要什么？（不要问"怎么做"）
-2. **约束** — 技术限制、时间、兼容性要求
-3. **边界** — 什么不在范围内
-4. **成功标准** — 怎么算做好了？
+1. 从最核心的问题开始（用户到底想做什么？）
+2. 等待回答，根据信息量决定追问还是进入方案讨论
+3. 探索顺序按需：目的 → 约束 → 边界 → 成功标准
+4. **大多数 brainstorm 2-3 轮就应进入方案讨论**
 
-**目标：用最少的轮次搞清楚需求。** 大多数 brainstorm 2-3 轮问答就应该能进入方案讨论了。如果你发现自己列出了超过 2 个问题还没开始，说明你问错方向了——回到用户的核心需求，重新提问。
+### Step 4: 提出 2-3 种方案
 
-### 4. 提出 2-3 种方案
+每种方案列优劣，给出推荐和理由。
 
-每种方案列出优劣，给出推荐和理由。
+### Step 5: 分段展示设计
 
-### 5. 分段展示设计
+简单项目几句话；复杂项目每段 200-300 字逐段确认。
 
-按复杂度分段展示：
-- 简单项目：几句话就行
-- 复杂项目：每段 200-300 字，逐段确认
+### Step 6: 写设计文档
 
-### 6. 写设计文档
-
-保存到 `.sillyspec/specs/YYYY-MM-DD-<topic>-design.md`
+保存到 `.sillyspec/specs/YYYY-MM-DD-<topic>-design.md`：
 
 ```markdown
 # [Feature Name] 设计
 
 ## 概述
-[一句话描述]
-
 ## 功能描述
-[详细描述用户交互流程]
-
 ## 技术方案
-[架构决策和关键选择]
-
 ## 约束和假设
-[已知的限制条件]
-
 ## 不在范围内
-[明确排除的内容]
-
 ## 验收标准
 - [ ] 标准 1
-- [ ] 标准 2
 ```
 
-### 7. AI 自审
-
-写完设计文档后，**立即进行自审**，不要等用户来挑问题。
+**注意：** 引用的表名必须来自 ARCHITECTURE.md 数据模型或明确标注"新增"。必须先读取 `.sillyspec/codebase/ARCHITECTURE.md`。
 
-自审检查项：
+### Step 7: AI 自审（必须执行）
 
-1. **需求覆盖**：design 是否完整覆盖了用户在 Step 3 中确认的所有需求点？
-2. **约束一致性**：design 中的技术方案是否与 ARCHITECTURE.md、CONVENTIONS.md 一致？
-3. **表名/字段真实性**：是否所有引用的表名和字段都来自真实 schema？新增的是否明确标注？
-4. **范围控制**：是否包含了不必要的功能（违反 YAGNI）？
-5. **验收标准**：验收标准是否具体、可测试？
-6. **与已有变更冲突**：是否与 Step 1.5 中检测到的已有变更冲突？
+- 需求覆盖：是否完整覆盖 Step 3 确认的需求点？
+- 约束一致性：技术方案是否与 ARCHITECTURE.md、CONVENTIONS.md 一致？
+- 表名/字段真实性：是否来自真实 schema？
+- 范围控制：是否包含不必要功能（YAGNI）？
+- 验收标准：是否具体、可测试？
+- 变更冲突：是否与 Step 1.5 检测到的已有变更冲突？
 
-**自审结果处理：**
-- 全部通过 → 进入 Step 8
-- 发现问题 → 修改 design 文档，重新自审，全部通过后再进入 Step 8
-- 不确定的问题 → 在 Step 8 展示给用户时标注「⚠️ 自审存疑」，请用户判断
+发现问题 → 修改文档，重新自审。不确定的标注「⚠️ 自审存疑」让用户判断。
 
-**不要跳过自审。** 这是保证设计质量的关键环节。
-
-### 8. 提交 Git
-
-```bash
-git add .sillyspec/specs/
-git commit -m "docs: design for <topic>"
-```
-
-### 9. 用户确认（⛔ 门禁）
-
-**设计保存后，用 CLI 验证状态：**
+### Step 8: 用户确认（⛔ 门禁）
 
 ```bash
 sillyspec status --json
 ```
 
-CLI 应返回 `phase: "propose"`。
-
-**⛔ 必须等待用户明确确认后才能进入下一阶段。** 展示给用户：
-
-
-请确认设计方案：
-1. ✅ 确认，进入 propose
-2. ✏️ 需要修改（请说明要改什么）
-3. ❌ 推翻重来
-
-**用户选择 1** → 推荐下一步命令：
-
-```bash
-sillyspec next
-```
-
-将 CLI 返回的命令推荐给用户。**不要自己编建议。**
-
-**用户选择 2** → 修改 design 文档，重新自审，再次进入确认门禁。
-**用户选择 3** → 回到 Step 3 或 Step 4 重新探索。
+展示设计方案，AskUserQuestion：确认进入 propose / 需要修改 / 推翻重来。
 
-**不允许在用户确认前自行推进到 propose 或任何后续阶段。**
+用户确认 → `sillyspec next`，将 CLI 返回命令推荐给用户。
 
-### 10. 更新 STATE.md
-
-每次 brainstorm 完成后，**必须自动更新** `.sillyspec/STATE.md`。
-
-**如果 STATE.md 不存在则创建。** 追加或更新以下内容：
-
-```markdown
-# 项目状态
+### Step 9: 更新 STATE.md
 
-## 当前变更
-- 名称：<变更名>
-- 当前阶段：brainstorm ✅
-- 下一步：/sillyspec:propose <变更名>
-
-## 阶段进度（大模块）
-（如果有 MASTER.md，列出各阶段状态）
-
-## 关键决策
-- （brainstorm 中确定的关键技术决策）
-
-## 历史记录
-- <时间> brainstorm 完成：<主题>
-```
-
-**不需要 Git 提交 STATE.md。** 这是工作状态文件，随时变化，不需要版本控制（可以加入 `.gitignore`）。
+自动更新 `.sillyspec/STATE.md`（不存在则创建）：当前变更、阶段、下一步、关键决策、历史记录。不需要 Git 提交。
 
 ## 关键原则
-- 🛑 **一次只问一个问题，等用户回答后再决定下一步**（这是铁律，违反等于 brainstorm 失败）
-- 多选题优于开放式问题
 - YAGNI — 无情砍掉不需要的功能
 - 总是探索替代方案
 - 设计可以很短，但必须存在
-- **2-3 轮问答就应该进入方案讨论**，不要变成问答马拉松
-
-### 注意
-
-在开始生成设计之前，必须先读取相关上下文：
-- `.sillyspec/codebase/ARCHITECTURE.md` — 如果是棕地项目，**必须读取数据模型章节**，设计中引用的表名必须来自真实 schema
-- `.sillyspec/codebase/` 下的其他文档
-- 如果没有上下文文档，先询问用户是否有现有设计或需求文档
-
-**禁止编造不存在的表名、字段名、API 端点。** 如果需要新建表/字段，明确标注为"新增"。
+- "简单"的项目更需要设计——未检视的假设造成最大浪费