@lininn/openflow 0.1.8 → 0.2.0

package/README.md

@@ -65,6 +65,7 @@ Re-generates project skills after upgrading the npm package.
 | `/openflow proposal` | proposal | Lightweight capture — 3-5 questions to converge on requirements |
 | `/openflow brainstorming` | brainstorming | Deep design — multi-round tradeoff exploration |
 | `/openflow spec` | spec | Call OpenSpec to generate specs + auto-translate to plan-ready.md |
+| `/openflow amend` | amend | Revise requirements/specs before close and update plan-ready.md |
 | `/openflow build` | build | Call Superpowers to execute implementation |
 | `/openflow close` | close | Verify consistency + archive |
 
@@ -117,6 +118,12 @@ User Requirements
                           └──────────┬───────────┘
                                      │
                           ┌──────────▼───────────┐
+                          │  /openflow amend       │
+                          │  Requirement revision  │
+                          │  (only when needed)    │
+                          └──────────┬───────────┘
+                                     │
+                          ┌──────────▼───────────┐
                           │  /openflow close       │
                           │  Verify + archive      │
                           └──────────────────────┘

package/README.zh-CN.md

@@ -65,6 +65,7 @@ openflow update
 | `/openflow proposal` | proposal | 轻量提问，3-5 问快速收敛需求 |
 | `/openflow brainstorming` | brainstorming | 深度设计，多轮方案探索 |
 | `/openflow spec` | spec | 调用 OpenSpec 生成规格 + 自动翻译 |
+| `/openflow amend` | amend | close 前修订需求/规格并更新 plan-ready.md |
 | `/openflow build` | build | 调用 Superpowers 执行实现 |
 | `/openflow close` | close | 验证一致性 + 归档 |
 
@@ -117,6 +118,12 @@ Works without them: yes, with manual-file fallback
                           └──────────┬───────────┘
                                      │
                           ┌──────────▼───────────┐
+                          │  /openflow amend      │
+                          │  需求变更修订          │
+                          │  （仅需要时）           │
+                          └──────────┬───────────┘
+                                     │
+                          ┌──────────▼───────────┐
                           │  /openflow close       │
                           │  验证一致性 + 归档      │
                           └──────────────────────┘

package/dist/cli/index.js

@@ -7,7 +7,7 @@ export function run() {
     program
         .name('openflow')
         .description('OpenSpec + Superpowers workflow orchestrator')
-        .version('0.1.0');
+        .version('0.1.9');
     program.addCommand(initCommand);
     program.addCommand(statusCommand);
     program.addCommand(updateCommand);

package/dist/cli/init.js

@@ -108,6 +108,7 @@ export const initCommand = new Command('init')
     logger.info('  /openflow proposal      Quick requirement capture');
     logger.info('  /openflow brainstorming  Deep design exploration');
     logger.info('  /openflow spec           Generate specs + translate');
+    logger.info('  /openflow amend          Revise requirements before close');
     logger.info('  /openflow build          Execute implementation');
     logger.info('  /openflow close          Verify + archive');
     logger.blank();

package/dist/cli/status.js

@@ -64,7 +64,7 @@ export const statusCommand = new Command('status')
         const hasProposal = fs.existsSync(path.join(changeDir, 'proposal.md'));
         let status = '';
         if (hasPlanReady) {
-            status = '→ ready for /openflow build';
+            status = '→ ready for /openflow build or /openflow amend';
         }
         else if (hasProposal) {
             status = '→ needs /openflow spec';

package/dist/core/skill-generator.js

@@ -29,7 +29,7 @@ export function generateSkills(options) {
         // Generate main SKILL.md
         generateSkillFile(skillsDir, 'SKILL.md', depStatus);
         // Generate phase files
-        const phases = ['proposal', 'brainstorming', 'spec', 'build', 'close'];
+        const phases = ['proposal', 'brainstorming', 'spec', 'amend', 'build', 'close'];
         for (const phase of phases) {
             generateSkillFile(skillsDir, `${phase}.md`, depStatus);
         }
@@ -100,13 +100,40 @@ function getInlineTemplate(filename, depStatus) {
     const templates = {
         'SKILL.md': `---
 name: openflow
-description: "OpenSpec + Superpowers 工作流协调器。使用 /openflow proposal 轻量提问、/openflow brainstorming 深度设计、/openflow spec 生成规格、/openflow build 执行实现、/openflow close 验证归档。串联需求规格与工程执行，消除格式鸿沟。"
+description: "OpenSpec + Superpowers 工作流协调器。使用 /openflow proposal 轻量提问、/openflow brainstorming 深度设计、/openflow spec 生成规格、/openflow amend 在归档前修订需求、/openflow build 执行实现、/openflow close 验证归档。串联需求规格与工程执行，消除格式鸿沟。"
 ---
 
 # openflow - 工作流协调器
 
 根据用户调用的子命令和项目当前状态，路由到对应阶段。
 
+## 续接与中断恢复
+
+如果本轮没有显式 \`/openflow ...\` 子命令，但上一轮已经进入 openflow 任一阶段，并且用户是在补充范围、回答确认问题、说“继续”、修正需求、或说明新增/移除边界：
+
+1. 默认继续上一 openflow 阶段，不把该回复当作普通编码请求
+2. 如果上一阶段是 proposal、brainstorming、spec 或 amend，只能继续产出/更新 OpenSpec 文档和计划文档，不得修改任何代码或实现文件
+3. 如果上一阶段是 build，但用户补充的是需求、验收条件或规格边界变更，切到 \`/openflow amend\`，不要直接改代码
+4. 只有用户显式调用 \`/openflow build\`，或状态检测明确进入 build 阶段后，才允许修改代码或实现文件
+5. 中断后恢复时，先重新读取当前阶段文件和 \`openspec/changes/\` 状态，再继续执行
+
+典型场景：
+- proposal 阶段整理需求后，用户补充“运营端也要做回显”。这仍是需求范围修正，必须继续 proposal 文档收敛，不能直接进入代码实现。
+- brainstorming 阶段询问“是否只覆盖企业端？”后，用户回复“运营端也要做回显”。这仍是设计范围修正，必须继续 brainstorming/proposal 文档收敛，不能直接进入代码实现。
+
+## 阶段写入边界
+
+| 阶段 | 允许写入 | 禁止写入 |
+|------|----------|----------|
+| proposal | \`openspec/changes/**/proposal.md\` | 任何代码或实现文件 |
+| brainstorming | \`openspec/changes/**/proposal.md\` | 任何代码或实现文件 |
+| spec | \`openspec/changes/**\`、\`plan-ready.md\` | 任何代码或实现文件 |
+| amend | \`openspec/changes/**\`、\`plan-ready.md\`、\`docs/superpowers/plans/*.md\` | 代码、测试、其他实现文件 |
+| build | 代码、测试、实现计划状态 | 规格文档（除非另开变更） |
+| close | 归档、验证记录、\`close-issues.md\` | 代码、测试、其他实现文件 |
+
+如果用户在 proposal/brainstorming/spec/amend 阶段提出“就按这个做”“范围改成 X”“继续”等话术，不代表进入 build；必须先完成该阶段文档产物并提示下一步。
+
 ## 子命令
 
 | 命令 | 阶段 | 说明 |
@@ -114,6 +141,7 @@ description: "OpenSpec + Superpowers 工作流协调器。使用 /openflow propo
 | \`/openflow proposal\` | proposal | 轻量提问，快速收敛需求 |
 | \`/openflow brainstorming\` | brainstorming | 深度设计，多轮探索 |
 | \`/openflow spec\` | spec | 调用 OpenSpec 生成规格 + 翻译 |
+| \`/openflow amend\` | amend | build/close 前受控修改需求、规格和计划 |
 | \`/openflow build\` | build | 调用 Superpowers 执行实现 |
 | \`/openflow close\` | close | 验证一致性 + 归档 |
 
@@ -139,10 +167,12 @@ description: "OpenSpec + Superpowers 工作流协调器。使用 /openflow propo
 
 根据子命令或状态检测结果，读取对应阶段文件并执行：
 
-1. 如果用户指定了子命令（如 \`/openflow build\`），优先按指定阶段执行，但检查前置条件
-2. 如果用户只输入 \`/openflow\`，执行状态检测，自动路由到对应阶段
-3. 读取当前 openflow skill 目录下的阶段文件：\`<阶段>.md\`（与本 \`SKILL.md\` 同目录；不要依赖 Claude 专属环境变量）
-4. 按阶段文件中的流程执行
+1. 如果这是上一 openflow 阶段的续接回复，先按“续接与中断恢复”保持阶段
+2. 如果用户在 build 中明确提出需求变更、补充 spec、修改验收条件或重新生成规格，路由到 amend
+3. 如果用户指定了子命令（如 \`/openflow build\`），优先按指定阶段执行，但检查前置条件
+4. 如果用户只输入 \`/openflow\`，执行状态检测，自动路由到对应阶段
+5. 读取当前 openflow skill 目录下的阶段文件：\`<阶段>.md\`（与本 \`SKILL.md\` 同目录；不要依赖 Claude 专属环境变量）
+6. 按阶段文件中的流程执行，并遵守阶段写入边界
 
 ### 前置条件检查
 
@@ -151,6 +181,7 @@ description: "OpenSpec + Superpowers 工作流协调器。使用 /openflow propo
 | proposal | 无 | — |
 | brainstorming | 无 | — |
 | spec | 需要有活跃变更目录或有用户需求 | "请先用 /openflow proposal 或 /openflow brainstorming 描述需求" |
+| amend | 需要有活跃变更目录，通常需要 plan-ready.md | "还没有可修订的活跃变更，请先完成 /openflow spec" |
 | build | 需要存在 plan-ready.md | "请先完成 /openflow spec 生成规格和翻译" |
 | close | 需要实现已完成 | "实现尚未完成，请先用 /openflow build 执行" |
 `,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lininn/openflow",
-  "version": "0.1.8",
+  "version": "0.2.0",
   "description": "OpenSpec + Superpowers workflow orchestrator for Claude Code",
   "bin": {
     "openflow": "./bin/openflow.js"

package/templates/SKILL.md

@@ -1,12 +1,39 @@
 ---
 name: openflow
-description: "OpenSpec + Superpowers workflow orchestrator. Use /openflow proposal for quick capture, /openflow brainstorming for deep design, /openflow spec to generate specs + translate, /openflow build to execute, /openflow close to verify and archive. Bridges requirements specs and engineering execution."
+description: "OpenSpec + Superpowers workflow orchestrator. Use /openflow proposal for quick capture, /openflow brainstorming for deep design, /openflow spec to generate specs + translate, /openflow amend to revise requirements before close, /openflow build to execute, /openflow close to verify and archive. Bridges requirements specs and engineering execution."
 ---
 
 # openflow - 工作流协调器
 
 根据用户调用的子命令和项目当前状态，路由到对应阶段。
 
+## 续接与中断恢复
+
+如果本轮没有显式 `/openflow ...` 子命令，但上一轮已经进入 openflow 任一阶段，并且用户是在补充范围、回答确认问题、说“继续”、修正需求、或说明新增/移除边界：
+
+1. 默认继续上一 openflow 阶段，不把该回复当作普通编码请求
+2. 如果上一阶段是 proposal、brainstorming、spec 或 amend，只能继续产出/更新 OpenSpec 文档和计划文档，不得修改任何代码或实现文件
+3. 如果上一阶段是 build，但用户补充的是需求、验收条件或规格边界变更，切到 `/openflow amend`，不要直接改代码
+4. 只有用户显式调用 `/openflow build`，或状态检测明确进入 build 阶段后，才允许修改代码或实现文件
+5. 中断后恢复时，先重新读取当前阶段文件和 `openspec/changes/` 状态，再继续执行
+
+典型场景：
+- proposal 阶段整理需求后，用户补充“运营端也要做回显”。这仍是需求范围修正，必须继续 proposal 文档收敛，不能直接进入代码实现。
+- brainstorming 阶段询问“是否只覆盖企业端？”后，用户回复“运营端也要做回显”。这仍是设计范围修正，必须继续 brainstorming/proposal 文档收敛，不能直接进入代码实现。
+
+## 阶段写入边界
+
+| 阶段 | 允许写入 | 禁止写入 |
+|------|----------|----------|
+| proposal | `openspec/changes/**/proposal.md` | 任何代码或实现文件 |
+| brainstorming | `openspec/changes/**/proposal.md` | 任何代码或实现文件 |
+| spec | `openspec/changes/**`、`plan-ready.md` | 任何代码或实现文件 |
+| amend | `openspec/changes/**`、`plan-ready.md`、`docs/superpowers/plans/*.md` | 代码、测试、其他实现文件 |
+| build | 代码、测试、实现计划状态 | 规格文档（除非另开变更） |
+| close | 归档、验证记录、`close-issues.md` | 代码、测试、其他实现文件 |
+
+如果用户在 proposal/brainstorming/spec/amend 阶段提出“就按这个做”“范围改成 X”“继续”等话术，不代表进入 build；必须先完成该阶段文档产物并提示下一步。
+
 ## 子命令
 
 | 命令 | 阶段 | 说明 |
@@ -14,6 +41,7 @@ description: "OpenSpec + Superpowers workflow orchestrator. Use /openflow propos
 | `/openflow proposal` | proposal | 轻量提问，快速收敛需求 |
 | `/openflow brainstorming` | brainstorming | 深度设计，多轮探索 |
 | `/openflow spec` | spec | 调用 OpenSpec 生成规格 + 翻译 |
+| `/openflow amend` | amend | build/close 前受控修改需求、规格和计划 |
 | `/openflow build` | build | 调用 Superpowers 执行实现 |
 | `/openflow close` | close | 验证一致性 + 归档 |
 
@@ -39,10 +67,12 @@ description: "OpenSpec + Superpowers workflow orchestrator. Use /openflow propos
 
 根据子命令或状态检测结果，读取对应阶段文件并执行：
 
-1. 如果用户指定了子命令（如 `/openflow build`），优先按指定阶段执行，但检查前置条件
-2. 如果用户只输入 `/openflow`，执行状态检测，自动路由到对应阶段
-3. 读取当前 openflow skill 目录下的阶段文件：`<阶段>.md`（与本 `SKILL.md` 同目录；不要依赖 Claude 专属环境变量）
-4. 按阶段文件中的流程执行
+1. 如果这是上一 openflow 阶段的续接回复，先按“续接与中断恢复”保持阶段
+2. 如果用户在 build 中明确提出需求变更、补充 spec、修改验收条件或重新生成规格，路由到 amend
+3. 如果用户指定了子命令（如 `/openflow build`），优先按指定阶段执行，但检查前置条件
+4. 如果用户只输入 `/openflow`，执行状态检测，自动路由到对应阶段
+5. 读取当前 openflow skill 目录下的阶段文件：`<阶段>.md`（与本 `SKILL.md` 同目录；不要依赖 Claude 专属环境变量）
+6. 按阶段文件中的流程执行，并遵守阶段写入边界
 
 ### 前置条件检查
 
@@ -51,5 +81,6 @@ description: "OpenSpec + Superpowers workflow orchestrator. Use /openflow propos
 | proposal | 无 | — |
 | brainstorming | 无 | — |
 | spec | 需要有活跃变更目录或有用户需求 | "请先用 /openflow proposal 或 /openflow brainstorming 描述需求" |
+| amend | 需要有活跃变更目录，通常需要 plan-ready.md | "还没有可修订的活跃变更，请先完成 /openflow spec" |
 | build | 需要存在 plan-ready.md | "请先完成 /openflow spec 生成规格和翻译" |
 | close | 需要实现已完成 | "实现尚未完成，请先用 /openflow build 执行" |

package/templates/amend.md

@@ -0,0 +1,136 @@
+---
+name: openflow/amend
+description: Revise active OpenSpec requirements during build, regenerate plan-ready.md, and append implementation tasks without archiving the change
+---
+
+# Amend: 需求变更修订
+
+## 目标
+
+在 active change 已经进入 spec/build 后，发现需求遗漏或规格需要改变时，受控修改 OpenSpec 文档和执行计划，然后回到 `/openflow build` 继续实现。
+
+## 适用场景
+
+- build 过程中发现原需求漏了一个功能、边界或验收条件
+- 用户明确说“修改需求”“补充 spec”“重新生成规格”“需求变更”
+- close 前发现规格本身不完整，而不是代码没有按现有规格实现
+
+不适用：
+- 只是代码没有实现现有 spec → 继续 `/openflow build`
+- 变更已经 close/archive → 开新的 `/openflow proposal` 或 `/openflow brainstorming`
+- 只是文案、注释或实现细节调整，且不改变行为 → 继续当前实现阶段
+
+## 前置条件
+
+- `openspec/changes/<变更名>/` 下存在 active change
+- 至少存在 `proposal.md`
+- 通常应已存在 `plan-ready.md`；如果没有，优先回到 `/openflow spec`
+
+如果没有 active change，提示：
+> "还没有活跃变更。请先用 /openflow proposal 或 /openflow brainstorming 创建需求。"
+
+如果变更已归档，提示：
+> "该变更已经归档。归档后的需求调整应开启新的 /openflow proposal。"
+
+## 流程
+
+### 1. 确认当前变更
+
+检查 `openspec/changes/` 下的 active change。
+
+如果有多个，列出并让用户选择：
+> "检测到多个活跃变更：[列表]。要修订哪个变更？"
+
+读取当前变更的文档：
+- `proposal.md`
+- `design.md`（如果存在）
+- `specs/**/spec.md`
+- `tasks.md`（如果存在）
+- `plan-ready.md`（如果存在）
+- `docs/superpowers/plans/` 下对应实现计划（如果存在）
+
+### 2. 判断是 amend 还是 build
+
+先判断用户描述属于哪类：
+
+| 情况 | 处理 |
+|------|------|
+| 现有 spec 已覆盖，只是代码未完成 | 回到 `/openflow build` |
+| 新增/修改行为、验收条件、边界、非目标 | 继续 amend |
+| 技术方案受影响 | 修改 `design.md` 并追加任务 |
+| 不确定是否改变需求 | 问 1 个澄清问题 |
+
+### 3. 修改 OpenSpec 文档
+
+按影响范围更新：
+
+- `proposal.md`：追加 `## Amendments`，记录本次需求变更的日期、原因和摘要
+- `design.md`：仅当技术方案或约束变化时修改
+- `specs/<capability>/spec.md`：使用 `ADDED`、`MODIFIED`、`REMOVED` 或 `RENAMED Requirements` 表达 delta
+- `tasks.md`：追加新任务；不要重写或删除已完成任务
+
+要求：
+- 每个新增或修改的 requirement 必须至少有一个 `#### Scenario:`
+- `MODIFIED Requirements` 必须包含完整的新 requirement 文本，不只写差异片段
+- 已完成任务保留原 checkbox 状态
+
+### 4. 校验 OpenSpec
+
+如果 OpenSpec CLI 可用，运行：
+
+```bash
+openspec validate <变更名> --strict
+```
+
+校验失败时，修正文档后重新校验。
+
+### 5. 重新生成 plan-ready.md
+
+根据修订后的 OpenSpec 文档更新 `plan-ready.md`。
+
+规则：
+- 保留原 `## 来源`
+- 追加 `## Amendments`，记录本次修订来源和影响
+- 保留已完成实现步骤的历史上下文
+- 追加新的实现步骤，按执行依赖排序
+- 不删除已经完成或正在执行的步骤，除非用户明确要求废弃并说明迁移方式
+
+建议追加格式：
+
+```markdown
+## Amendments
+
+### YYYY-MM-DD: <简短标题>
+- 原因：<为什么需要改>
+- 影响规格：<spec 路径>
+- 影响任务：<tasks.md 条目>
+
+## 追加实现步骤
+
+### Task N: <任务名>
+- 目标：<做什么>
+- 改动文件：<哪些文件>
+- 验证方式：<怎么验证>
+```
+
+### 6. 同步详细实现计划
+
+如果 `docs/superpowers/plans/YYYY-MM-DD-<变更名>.md` 已存在：
+- 已勾选任务不动
+- 未完成任务可按新需求调整
+- 追加新 task，保留 checkbox
+- 记录本次 amend 来源路径
+
+如果详细实现计划还不存在：
+- 不创建代码实现计划，提示下一步用 `/openflow build`
+
+### 7. 提示下一步
+
+> "需求变更已写入 OpenSpec，plan-ready.md 已更新。接下来继续 `/openflow build`。"
+
+## 关键原则
+
+- amend 阶段只允许修改规格、任务、plan-ready.md 和实现计划文档，不直接修改代码
+- amend 是 close/archive 前的受控需求变更入口，不用于修代码
+- 不把 build 中的自然语言补充直接当作实现指令；只要改变需求或验收条件，先 amend
+- 已归档变更不可 amend，必须开启新 change

package/templates/brainstorming.md

@@ -9,6 +9,12 @@ description: Deep design — multi-round exploration to confirm architecture and
 
 通过多轮对话，深入探索需求、方案取舍和架构决策。产出比 proposal 更完整的需求描述和设计方向。
 
+## 中断续接规则
+
+如果用户在本阶段被打断后继续回复、补充范围、回答确认问题、或修正边界，仍然停留在 brainstorming 阶段。继续收敛设计并更新 `openspec/changes/**/proposal.md`，不要因为用户明确了范围就直接进入实现或修改任何代码。
+
+典型错误：在确认“只改企业端？”后，用户回复“运营端也要做回显”，这只是范围修正，必须继续记录需求和方案，不得直接修改任何代码或实现文件。
+
 ## 流程
 
 ### 1. 理解背景
@@ -60,6 +66,7 @@ openspec list
 ## 注意
 
 - 不要写代码
+- 本阶段只允许写 OpenSpec 需求/设计方向文档，禁止修改任何代码或实现文件
 - 不要跳过取舍讨论直接给答案
 - 如果项目很大，建议先拆分成独立的子项目
 - 允许用户改变方向，不要过早锁定

package/templates/build.md

@@ -9,6 +9,12 @@ description: Call Superpowers to execute implementation, supports checkpoint rec
 
 读取 plan-ready.md，调用 Superpowers 的 writing-plans 生成详细实现计划，然后按 TDD 铁律执行。
 
+## 中断续接规则
+
+如果用户在 build 阶段被打断后继续回复、说“继续”、或补充实现细节，保持 build 阶段并从实现计划/checkbox 状态恢复。不要回到 proposal、brainstorming 或 spec。
+
+如果用户明确要求修改需求、补充 spec、改变验收条件、改变功能边界或重新生成规格，停止实现并切到 `/openflow amend`。amend 完成后再回到 `/openflow build`。
+
 ## 前置条件
 
 - `openspec/changes/<变更名>/plan-ready.md` 存在
@@ -69,6 +75,7 @@ docs/superpowers/plans/YYYY-MM-DD-<变更名>.md
 
 ## 关键原则
 
-- **不允许在 build 阶段修改规格文档** — 发现问题先记录，留到 close 阶段处理
+- **不允许在 build 阶段修改规格文档** — 发现需求遗漏或规格错误时切到 `/openflow amend`
+- build 是唯一默认允许修改代码或实现文件的阶段；如果上一阶段不是 build，不要因为用户确认范围而自动写代码
 - plan-ready.md 是锁定的设计决策，Superpowers 按计划展开执行，不重新理解需求
 - 断点恢复依赖文件系统状态，不依赖 AI 的会话记忆

package/templates/close.md

@@ -9,6 +9,10 @@ description: Verify implementation consistency and archive
 
 验证代码实现与设计文档一致，确认规格变更全部体现，然后归档。
 
+## 中断续接规则
+
+如果用户在 close 阶段被打断后继续回复、说“继续”、或要求完成归档，保持 close 阶段并继续验证/归档。close 阶段不允许顺手修代码；发现差异只记录到 `close-issues.md`。
+
 ## 前置条件
 
 - `docs/superpowers/plans/` 下的实现计划全部 checkbox 已勾选
@@ -82,5 +86,6 @@ mv openspec/changes/<变更名> openspec/changes/archive/$(date +%Y-%m-%d)-<变
 ## 关键原则
 
 - close 阶段不做代码修改，只做验证和归档
+- 本阶段只允许写归档、验证记录或 `close-issues.md`；禁止修改任何代码或实现文件
 - 不一致先记录，不现场修复
 - 防止边写代码边改需求的恶性循环

package/templates/proposal.md

@@ -9,6 +9,12 @@ description: Lightweight requirement capture — 3-5 questions to quickly conver
 
 用最少的提问，把用户脑子里的需求变成可执行的变更描述。不做深度设计，不生成代码。
 
+## 中断续接规则
+
+如果用户在本阶段被打断后继续回复、补充范围、回答确认问题、或修正边界，仍然停留在 proposal 阶段。继续更新 `openspec/changes/**/proposal.md`，不要因为用户说“就这样做”“继续”“范围改成 X”而写任何代码或实现文件。
+
+典型错误：proposal 阶段确认“只改企业端？”后，用户回复“运营端也要做回显”。这只是需求范围补充，必须继续更新 proposal，不得直接修改任何代码或实现文件。
+
 ## 流程
 
 ### 1. 提出关键问题
@@ -51,5 +57,6 @@ openspec list
 
 - 不要做技术设计，那是 spec 和 brainstorming 的事
 - 不要写代码
+- 本阶段只允许写 OpenSpec 需求文档，禁止修改任何代码或实现文件
 - 问题要具体，不要泛泛而谈
 - 如果用户的需求很大（跨多个独立子系统），建议拆分

package/templates/spec.md

@@ -9,6 +9,10 @@ description: Call OpenSpec to generate specs, auto-translate to plan-ready.md af
 
 调用 OpenSpec 生成完整的规格文档（proposal.md, design.md, specs/, tasks.md），用户确认后自动翻译成 Superpowers 可执行的 plan-ready.md。
 
+## 中断续接规则
+
+如果用户在本阶段被打断后继续回复、补充范围、要求调整规格、或确认规格摘要，仍然停留在 spec 阶段。只更新 `openspec/changes/**` 与 `plan-ready.md`，不要修改任何代码或实现文件。
+
 ## 前置条件
 
 - `openspec/changes/` 下存在活跃变更目录（由 proposal 或 brainstorming 阶段创建）
@@ -101,6 +105,7 @@ openspec validate <变更名> --strict
 ## 关键原则
 
 - **一条代码都不许写** — spec 阶段只产出文档
+- 本阶段只允许写 `openspec/changes/**` 与 `plan-ready.md`，禁止修改任何代码或实现文件
 - 翻译必须在用户确认后自动生成，不需要用户手动触发
 - plan-ready.md 的 ## 来源 部分必须写明路径，方便 Superpowers 执行时回溯
 - 按执行依赖排序是翻译的关键步骤：先依赖后依赖方