sillyspec 3.7.8 → 3.7.9

package/templates/brainstorm.md

@@ -21,6 +21,23 @@ cat .sillyspec/STATE.md 2>/dev/null
 - phase 为 `brainstorm` 或无 STATE.md → ✅ 继续
 - 其他 phase → 提示用户当前阶段，建议先完成
 
+## 进度恢复检查（必须先执行）
+
+1. 读取 `.sillyspec/.runtime/progress.json`（使用 read 工具）
+2. 如果文件存在且 `currentStage` 为 `brainstorm`：
+   a. 按 resume-dialog.md 模板向用户展示恢复信息（见下方）
+   b. 用户确认后，将 `resumeCount` +1，更新 `lastActiveAt`，写入 progress.json
+   c. 将已完成步骤的结论作为「已确认的决策，无需重新讨论」注入上下文
+   d. 从 `inProgressStep.id` 继续，**禁止回头重新讨论已完成步骤**
+3. 如果文件不存在或 `currentStage` 不是 `brainstorm`：正常启动
+
+### 恢复对话规则
+- 首次恢复（resumeCount < 3）：友好欢迎，展示进度条和关键结论
+- 频繁中断（resumeCount >= 3）：建议重新开始，但尊重用户选择
+- 长时间中断（距 lastActiveAt > 24h）：先回顾上次聊了什么，再问是否继续
+- 恢复时说「欢迎回来」而非「检测到中断」
+- 参考模板：`.sillyspec/.runtime/templates/resume-dialog.md`
+
 ## 用户想法
 $ARGUMENTS
 
@@ -28,18 +45,19 @@ $ARGUMENTS
 
 ## Checklist（必须按顺序完成，不允许跳步或并行）
 
-- [ ] **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** — 用户确认设计方案
-- [ ] **Step 9** — 输出 design.md
-- [ ] **Step 10** — 更新 STATE.md
+- [ ] **Step 1** — 加载项目上下文 → 保存进度
+- [ ] **Step 2** — 协作与复用检查（同名变更 + 全局模板）→ 保存进度
+- [ ] **Step 3** — 原型/设计图分析（如有）→ 保存进度
+- [ ] **Step 4** — 评估需求范围，复杂需求拆分子项目/阶段，生成 MASTER.md → 保存进度
+- [ ] **Step 5** — 对话式探索（一次一个问题，2-3 轮内完成）→ 保存进度
+- [ ] **Step 6** — 提出 2-3 个方案并推荐 → 保存进度
+- [ ] **Step 7** — 分段展示设计，逐段确认 → 保存进度
+- [ ] **Step 8** — 写设计文档并保存 → 保存进度
+- [ ] **Step 9** — AI 自审（对照约束检查）→ 保存进度
+- [ ] **Step 10** — 用户确认设计方案 → 保存进度
+- [ ] **Step 11** — 输出 design.md → 保存进度
+- [ ] **Step 12** — 更新 STATE.md → 保存进度
+- [ ] **Step 13** — 保存最终进度
 
 **终态：** brainstorm 完成后唯一出口是 `/sillyspec:plan`。不允许直接进入 execute 或任何代码操作。
 
@@ -63,14 +81,14 @@ ls .sillyspec/changes/ 2>/dev/null | grep -v archive
 ls .sillyspec/knowledge/ 2>/dev/null
 ```
 
-### Step 1.5: 协作与复用检查
+### Step 2: 协作与复用检查
 
 - **同名变更：** `ls .sillyspec/changes/ | grep -v archive` — 有相关变更则提示避免冲突
 - **全局模板：** `ls ~/.sillyspec/templates/ 2>/dev/null` — 有匹配模板则建议复用
 
 无匹配则跳过，不输出。
 
-### Step 2: 原型/设计图分析（如有图片则必做）
+### Step 3: 原型/设计图分析（如有图片则必做）
 
 **不要只看描述文字，图片包含布局、字段、交互等视觉信息。**
 
@@ -82,7 +100,7 @@ ls .sillyspec/knowledge/ 2>/dev/null
 
 展示分析结果，问用户确认有无遗漏。
 
-### Step 2b: 大模块拆分
+### Step 4: 大模块拆分
 
 **满足以下任意 2 条就建议拆分：**
 - 3+ 个可独立交付的功能模块
@@ -108,7 +126,7 @@ git add .sillyspec/changes/<变更名>/MASTER.md
 
 **子阶段 brainstorm：** 读取 MASTER.md + 前序阶段经验 + 对应原型，设计文档保存到 `.sillyspec/changes/<变更名>/stages/<stage-N>/`。
 
-### Step 3: 对话式探索
+### Step 5: 对话式探索
 
 **核心规则：一次只问一个问题。**
 
@@ -119,15 +137,15 @@ git add .sillyspec/changes/<变更名>/MASTER.md
 
 探索阶段可使用项目已配置的 MCP 工具或 web search 调研技术方案和 API 用法，不要凭记忆写方案。检测可用工具：`cat .claude/mcp.json .cursor/mcp.json 2>/dev/null`
 
-### Step 4: 提出 2-3 种方案
+### Step 6: 提出 2-3 种方案
 
 每种方案列优劣，给出推荐和理由。
 
-### Step 5: 分段展示设计
+### Step 7: 分段展示设计
 
 简单项目几句话；复杂项目每段 200-300 字逐段确认。
 
-### Step 6: 写设计文档
+### Step 8: 写设计文档
 
 保存到 `.sillyspec/changes/<变更名>/design.md`：
 
@@ -151,34 +169,72 @@ git add .sillyspec/changes/<变更名>/MASTER.md
 
 **注意：** 引用的表名必须来自 ARCHITECTURE.md 数据模型或明确标注"新增"。必须先读取 `.sillyspec/codebase/ARCHITECTURE.md`。
 
-### Step 7: AI 自审（必须执行）
+### Step 9: AI 自审（必须执行）
 
-- 需求覆盖：是否完整覆盖 Step 3 确认的需求点？
+- 需求覆盖：是否完整覆盖 Step 5 确认的需求点？
 - 约束一致性：技术方案是否与 ARCHITECTURE.md、CONVENTIONS.md 一致？
 - 表名/字段真实性：是否来自真实 schema？
 - 范围控制：是否包含不必要功能（YAGNI）？
 - 验收标准：是否具体、可测试？
-- 变更冲突：是否与 Step 1.5 检测到的已有变更冲突？
+- 变更冲突：是否与 Step 2 检测到的已有变更冲突？
 - 缺口：模糊表述（"适当的"/"必要时"等）是否已明确化
 - 缺口：隐含假设（登录态、数据量、并发预期）是否已显式写出
 - 缺口：边界场景（空数据、并发、服务不可用）是否已考虑
 
 发现问题 → 修改文档，重新自审。不确定的标注「⚠️ 自审存疑」让用户判断。
 
-### Step 8: 用户确认（⛔ 门禁）
+### Step 10: 用户确认（⛔ 门禁）
 
 展示设计方案，AskUserQuestion：确认 / 需要修改 / 推翻重来。
 
-### Step 9: 输出技术方案
+### Step 11: 输出技术方案
 
-用户确认后，确认 design.md 已包含完整内容（动机、需求、方案、文件变更、代码风格参照）。如 Step 6 已保存则无需重复。
+用户确认后，确认 design.md 已包含完整内容（动机、需求、方案、文件变更、代码风格参照）。如 Step 8 已保存则无需重复。
 
-### Step 10: 更新 STATE.md
+### Step 12: 更新 STATE.md
 
 自动更新 `.sillyspec/STATE.md`（不存在则创建）：当前变更、阶段、下一步 `/sillyspec:plan`、关键决策、历史记录。不需要 Git 提交。
 
+### Step 13: 保存最终进度
+
+1. 更新 `.sillyspec/.runtime/progress.json`：
+   - `stages.brainstorm.status` 设为 `completed`
+   - 写入 `stageSummary`（2-3 句总结核心设计决策）
+   - `currentStage` 更新为 `plan`
+   - `checkpoint` 设为「brainstorm 完成，等待 plan」
+2. Append `user-inputs.md` 最终记录
+3. 告知用户：「brainstorm 完成 ✅ 进度已保存，下一步 /sillyspec:plan」
+
 ## 关键原则
 - YAGNI — 无情砍掉不需要的功能
 - 总是探索替代方案
 - 设计可以很短，但必须存在
 - "简单"的项目更需要设计——未检视的假设造成最大浪费
+
+## 进度保存规则（⚠️ HARD-GATE）
+
+**每步完成后必须执行，不允许跳过：**
+
+1. 使用 write 工具更新 `.sillyspec/.runtime/progress.json`
+2. 将当前步骤 ID 加入 `completedSteps`
+3. 在 `summaries` 中写入本步结构化摘要：
+   - `conclusion`（1-2句核心结论，必填）
+   - `decisions`（用户确认的决策列表）
+   - `rejectedAlternatives`（被否方案 + 简要理由）
+   - `userMessages`（用户影响决策的原话）
+   - `openQuestions`（遗留问题）
+   - `keyEntities`（涉及的关键实体/概念）
+4. 更新 `checkpoint`（一句话描述）
+5. 刷新 `lastActiveAt`（ISO 格式）
+6. `_version` +1
+7. Append `.sillyspec/.runtime/user-inputs.md`（格式见 progress-format.md）
+8. 对用户说：「✅ 第X步完成，进度已保存。」
+
+**下步启动检查：** 进入下一步前，先确认 progress.json 的 currentStep 已更新。如果发现未保存，立即补保存。
+
+## 多任务并行提醒
+
+如果用户在 brainstorm 过程中临时要求执行 quick 任务：
+- quick 任务不写入 progress.json，不影响当前 brainstorm 状态
+- quick 完成后，brainstorm 从断点继续
+- 告知用户：「quick 任务会独立执行，brainstorm 进度不受影响」

package/templates/commit.md

@@ -43,6 +43,8 @@ git diff --cached --stat
 ```bash
 USER=$(git config user.name 2>/dev/null || echo "default")
 cat .sillyspec/quicklog/QUICKLOG-${USER}.md 2>/dev/null
+# 同时扫描活跃变更目录下的归属 quicklog
+for dir in .sillyspec/changes/*/quicklog/*.md; do [ -f "$dir" ] && cat "$dir"; done 2>/dev/null
 ```
 
 **来源 B — tasks.md（execute 产生的修改）：**

package/templates/execute.md

@@ -244,7 +244,8 @@ done
    - **查阅 Playwright 用法：** 优先使用已安装的 playwright skill（SKILL.md），不要凭记忆写 API。未安装则通过 Context7 MCP 或 web search 查最新文档
    - 有测试框架则编写测试文件，无框架则编写 `.sillyspec/changes/<变更名>/e2e-steps.md` 结构化测试步骤
    - **写完必须立即跑一遍确认通过**，失败则修复后重跑，不要"写了就算完成"
-8. **暂存：** 完成后在工作目录执行 git add -A（不要 commit，由用户通过 /sillyspec:commit 统一提交）
+8. **Lint 校验：** 完成后对修改的文件运行 lint 工具（与 quick 相同规则），自动修复可修复的问题，不可修复的标注在报告中
+9. **暂存：** lint 通过后执行 git add -A（不要 commit，由用户通过 /sillyspec:commit 统一提交）
 9. **不修改计划外的文件**，如必须修改则在报告中说明
 10. **遵守编码规范：** prompt 中「编码规范约束」段的所有规则必须严格遵守。如规范与任务描述冲突，优先遵守规范并报告
 

package/templates/progress-format.md

@@ -0,0 +1,90 @@
+# Progress Format — AI 写入规范
+
+> 本文件供 AI 在各阶段执行时参考，规范 progress.json 和 user-inputs.md 的写入方式。
+
+## 文件位置
+
+- **进度文件：** `.sillyspec/.runtime/progress.json`
+- **用户输入记录：** `.sillyspec/.runtime/user-inputs.md`
+
+## progress.json 字段说明
+
+| 字段 | 类型 | 说明 |
+|------|------|------|
+| `_version` | number | 内部版本号，固定为 `1` |
+| `schemaVersion` | string | Schema 版本，固定为 `"1.0.0"` |
+| `currentStage` | string | 当前阶段：`brainstorm` / `propose` / `plan` / `execute` / `verify` |
+| `lastActiveAt` | string | ISO 8601 时间戳，每次更新时刷新 |
+| `resumeCount` | number | 恢复次数，每次恢复时 +1 |
+| `checkpoint` | string | 一句话描述当前进度（给恢复时快速定位） |
+| `stages.<stage>.status` | string | 阶段状态：`not_started` / `in_progress` / `completed` |
+| `stages.<stage>.completedSteps` | number[] | 已完成步骤 ID 列表 |
+| `stages.<stage>.inProgressStep` | object/null | 当前进行中的步骤：`{ id, name, startedAt, partialContext }` |
+| `stages.<stage>.summaries` | object | 步骤结论，key 为步骤 ID，value 见下方 |
+| `stages.<stage>.artifacts` | array | 产出文件列表：`[{ stepId, name, paths }]` |
+| `stages.<stage>.stageSummary` | string/null | 阶段总结 |
+
+### summaries 结构
+
+```json
+{
+  "1": {
+    "conclusion": "一句话结论",
+    "keyEntities": ["实体1", "实体2"],
+    "decisions": ["决定A"],
+    "rejectedAlternatives": ["被否的方案B"],
+    "userMessages": ["用户原话摘要"],
+    "openQuestions": ["未解决的问题"]
+  }
+}
+```
+
+## user-inputs.md 格式
+
+每步完成时 **append**（不覆盖）用户在本步说的所有原话：
+
+```markdown
+# 用户输入记录
+
+## Step 1 - 需求理解 (2026-04-05 00:30)
+- 我们主要做研发项目管理，不搞CRM
+- 目标用户是中大型团队，50人以上
+
+## Step 3 - 竞品分析 (2026-04-05 00:45)
+- Jira太重了，我们想做轻的
+- 排期最烦了，能不能AI帮搞
+```
+
+### 时间戳格式
+
+`YYYY-MM-DD HH:MM`
+
+### 获取当前时间
+
+- JavaScript：`new Date().toLocaleString('sv-SE', { timeZone: 'Asia/Shanghai', hour12: false }).slice(0, 16)` → `"2026-04-05 13:37"`
+- 或 shell 命令：`date '+%Y-%m-%d %H:%M'`
+
+## 每步完成后的保存流程
+
+1. **更新 progress.json**：
+   - 将步骤 ID 加入 `completedSteps`
+   - 清空 `inProgressStep`（或设为下一步）
+   - 在 `summaries` 中写入本步结论
+   - 刷新 `lastActiveAt`
+   - 更新 `checkpoint`（一句话描述）
+
+2. **Append user-inputs.md**：
+   - 追加 `## Step N - 步骤名 (YYYY-MM-DD HH:MM)` 段落
+   - 列出用户在本步的所有原话
+   - **不要删除之前的内容，只追加**
+
+3. **如果阶段完成**：
+   - 设置 `stages.<stage>.status = "completed"`
+   - 写入 `stageSummary`
+   - 更新 `currentStage` 为下一阶段
+
+## 多任务并行说明
+
+- `quick` 命令**不修改** progress.json，独立执行
+- quick 完成后主流程状态不变，直接继续
+- `resume` 恢复时忽略 quick 的内容

package/templates/quick.md

@@ -19,6 +19,14 @@ $ARGUMENTS
 ## 流程
 
 1. **解析参数：** 检查是否携带 `--change <变更名>`，确定记录方式
+1.5 **归属检查：** 如果没有 `--change` 参数，检查 `.sillyspec/changes/` 下是否有非 archive 的活跃变更目录：
+   ```bash
+   ls -d .sillyspec/changes/*/ 2>/dev/null | grep -v archive
+   ```
+   - 有活跃变更 → AskUserQuestion 询问本次 quick 归属哪个变更，默认选当前活跃的
+   - 用户选择后将日志写入 `.sillyspec/changes/<变更名>/quicklog/` 而非独立 QUICKLOG
+   - 用户选择"无归属" → 走原有的独立 QUICKLOG 流程
+   - 无活跃变更 → 走原有的独立 QUICKLOG 流程
 2. **理解任务：** 模糊则问一个问题确认
 3. **加载上下文：** `cat .sillyspec/codebase/{CONVENTIONS,ARCHITECTURE}.md 2>/dev/null`
 3b. **编码规范扫描：** 检测项目中的编码规范配置文件（`.eslintrc*`、`.prettierrc*`、`tsconfig.json`、`.editorconfig`、`tailwind.config.*`、`CONTRIBUTING.md`），提取关键规则生成摘要。写作代码时必须严格遵守这些规则（分号/引号/缩进/命名风格等），如不确定优先遵守规范约束。
@@ -54,14 +62,39 @@ cat .sillyspec/local.yaml 2>/dev/null
 ```bash
 mvn test -pl <模块> -Dtest=<测试类> 2>/dev/null || ./gradlew test --tests <测试类> 2>/dev/null || pnpm test 2>/dev/null || npm test 2>/dev/null || pytest <测试文件> 2>/dev/null
 ```
-8. **Git 暂存：** `git add -A`。**不要 commit**，由用户通过 `/sillyspec:commit` 统一提交。**工作区模式下，确认当前在正确的子项目目录中执行暂存。**
-9. **记录：**
+8. **Lint 校验（如项目配置了）：** 写完代码后、暂存前，运行项目的 lint 工具验证代码质量：
+   ```bash
+   # 检测并运行可用的 lint 工具
+   npx eslint <修改的文件> 2>/dev/null || \
+   npx prettier --check <修改的文件> 2>/dev/null || \
+   npx tsc --noEmit 2>/dev/null || \
+   true  # 没有 lint 工具则跳过
+   ```
+   - **有报错 → 自动修复：** `npx eslint --fix <修改的文件>` / `npx prettier --write <修改的文件>`
+   - **修复后仍有报错 → 在 QUICKLOG 中标注，提醒用户手动处理**
+   - **工作区模式下，在子项目目录中执行，不要在主项目目录执行**
+9. **Git 暂存：** `git add -A`。**不要 commit**，由用户通过 `/sillyspec:commit` 统一提交。**工作区模式下，确认当前在正确的子项目目录中执行暂存。**
+10. **记录：**
    - **有 `--change`：** 在 `.sillyspec/changes/<变更名>/tasks.md` 追加 task 并勾选，**记录精确到秒的时间戳**：
 
 ```
 - [x] [YYYY-MM-DD HH:MM:SS] 任务描述
 ```
-   - **无 `--change`：** 记录到 `.sillyspec/quicklog/QUICKLOG-<git用户名>.md`（见下方规则）
+   - **无 `--change` 但步骤 1.5 确认了归属变更：** 记录到 `.sillyspec/changes/<变更名>/quicklog/YYYY-MM-DD-HHMMSS-任务简述.md`，格式：
+
+```markdown
+# quick: 任务描述
+
+- 时间：YYYY-MM-DD HH:MM:SS
+- 关联变更：<变更名>
+- 修改文件：
+  - `path/to/file1`
+  - `path/to/file2`
+- 改动说明：（2-3 句描述做了什么）
+- 发现的坑：（如有，简要记录）
+```
+
+   - **无 `--change` 且无归属：** 记录到 `.sillyspec/quicklog/QUICKLOG-<git用户名>.md`（见下方规则）
 10. **检查复杂度：** 任务比预期复杂 → 建议用完整流程
 
 11. **记录发现的坑：** 执行过程中如果发现项目特有的规律、陷阱或约定（如"某方法参数顺序容易搞反"、"某表有隐藏软删除字段"），追加到 `.sillyspec/knowledge/uncategorized.md`，格式：

package/templates/resume-dialog.md

@@ -0,0 +1,55 @@
+# Resume Dialog Template
+
+> 此模板用于 AI 恢复中断的 SillySpec 工作流程。
+
+## 恢复流程
+
+当用户执行 `resume` 或对话中断后恢复时，按以下步骤操作：
+
+### 1. 读取进度
+
+```
+读取 .sillyspec/.runtime/progress.json
+读取 .sillyspec/.runtime/user-inputs.md（截取当前阶段相关部分）
+读取 .sillyspec/STATE.md
+```
+
+### 2. 向用户确认
+
+用简洁的语言告知：
+
+- 当前阶段和步骤
+- 上次做到哪里（checkpoint）
+- 距上次活跃时间
+- 下一步要做什么
+
+**示例：**
+
+> 📋 上次你在 **brainstorm** 阶段的 **Step 4 - 技术选型**，已经讨论了前端框架的选择。
+> 距今约 2 小时。要继续技术选型，还是回顾一下之前的结论？
+
+### 3. 恢复上下文
+
+从 `summaries` 和 `user-inputs.md` 中提取之前的关键信息，注入对话：
+
+- 已完成的步骤结论
+- 已做的决策和被否的方案
+- 未解决的问题
+- 用户的关键偏好
+
+### 4. 继续执行
+
+从 `inProgressStep` 指定的步骤继续。如果 `inProgressStep` 为空但从 `completedSteps` 可推断进度，则从下一步开始。
+
+### 5. 更新进度
+
+- `resumeCount` +1
+- 刷新 `lastActiveAt`
+- 开始执行后更新 `inProgressStep`
+
+## 注意事项
+
+- 不要重新问已完成步骤中已经确认的问题
+- 除非用户主动要求，不要从头开始
+- 如果 progress.json 损坏，告知用户并建议运行 `sillyspec progress validate`
+- quick 任务不影响主流程进度