@lininn/openflow 0.1.8-beta.0 → 0.1.9

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/core/skill-generator.js

@@ -107,6 +107,31 @@ description: "OpenSpec + Superpowers 工作流协调器。使用 /openflow propo
 
 根据用户调用的子命令和项目当前状态，路由到对应阶段。
 
+## 续接与中断恢复
+
+如果本轮没有显式 \`/openflow ...\` 子命令，但上一轮已经进入 openflow 任一阶段，并且用户是在补充范围、回答确认问题、说“继续”、修正需求、或说明新增/移除边界：
+
+1. 默认继续上一 openflow 阶段，不把该回复当作普通编码请求
+2. 如果上一阶段是 proposal、brainstorming 或 spec，只能继续产出/更新 OpenSpec 文档，不得修改任何代码或实现文件
+3. 只有用户显式调用 \`/openflow build\`，或状态检测明确进入 build 阶段后，才允许修改代码或实现文件
+4. 中断后恢复时，先重新读取当前阶段文件和 \`openspec/changes/\` 状态，再继续执行
+
+典型场景：
+- proposal 阶段整理需求后，用户补充“运营端也要做回显”。这仍是需求范围修正，必须继续 proposal 文档收敛，不能直接进入代码实现。
+- brainstorming 阶段询问“是否只覆盖企业端？”后，用户回复“运营端也要做回显”。这仍是设计范围修正，必须继续 brainstorming/proposal 文档收敛，不能直接进入代码实现。
+
+## 阶段写入边界
+
+| 阶段 | 允许写入 | 禁止写入 |
+|------|----------|----------|
+| proposal | \`openspec/changes/**/proposal.md\` | 任何代码或实现文件 |
+| brainstorming | \`openspec/changes/**/proposal.md\` | 任何代码或实现文件 |
+| spec | \`openspec/changes/**\`、\`plan-ready.md\` | 任何代码或实现文件 |
+| build | 代码、测试、实现计划状态 | 规格文档（除非另开变更） |
+| close | 归档、验证记录、\`close-issues.md\` | 代码、测试、其他实现文件 |
+
+如果用户在 proposal/brainstorming/spec 阶段提出“就按这个做”“范围改成 X”“继续”等话术，不代表进入 build；必须先完成该阶段文档产物并提示下一步。
+
 ## 子命令
 
 | 命令 | 阶段 | 说明 |
@@ -139,10 +164,11 @@ description: "OpenSpec + Superpowers 工作流协调器。使用 /openflow propo
 
 根据子命令或状态检测结果，读取对应阶段文件并执行：
 
-1. 如果用户指定了子命令（如 \`/openflow build\`），优先按指定阶段执行，但检查前置条件
-2. 如果用户只输入 \`/openflow\`，执行状态检测，自动路由到对应阶段
-3. 读取当前 openflow skill 目录下的阶段文件：\`<阶段>.md\`（与本 \`SKILL.md\` 同目录；不要依赖 Claude 专属环境变量）
-4. 按阶段文件中的流程执行
+1. 如果这是上一 openflow 阶段的续接回复，先按“续接与中断恢复”保持阶段
+2. 如果用户指定了子命令（如 \`/openflow build\`），优先按指定阶段执行，但检查前置条件
+3. 如果用户只输入 \`/openflow\`，执行状态检测，自动路由到对应阶段
+4. 读取当前 openflow skill 目录下的阶段文件：\`<阶段>.md\`（与本 \`SKILL.md\` 同目录；不要依赖 Claude 专属环境变量）
+5. 按阶段文件中的流程执行，并遵守阶段写入边界
 
 ### 前置条件检查
 

package/package.json

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

package/templates/SKILL.md

@@ -7,6 +7,31 @@ description: "OpenSpec + Superpowers workflow orchestrator. Use /openflow propos
 
 根据用户调用的子命令和项目当前状态，路由到对应阶段。
 
+## 续接与中断恢复
+
+如果本轮没有显式 `/openflow ...` 子命令，但上一轮已经进入 openflow 任一阶段，并且用户是在补充范围、回答确认问题、说“继续”、修正需求、或说明新增/移除边界：
+
+1. 默认继续上一 openflow 阶段，不把该回复当作普通编码请求
+2. 如果上一阶段是 proposal、brainstorming 或 spec，只能继续产出/更新 OpenSpec 文档，不得修改任何代码或实现文件
+3. 只有用户显式调用 `/openflow build`，或状态检测明确进入 build 阶段后，才允许修改代码或实现文件
+4. 中断后恢复时，先重新读取当前阶段文件和 `openspec/changes/` 状态，再继续执行
+
+典型场景：
+- proposal 阶段整理需求后，用户补充“运营端也要做回显”。这仍是需求范围修正，必须继续 proposal 文档收敛，不能直接进入代码实现。
+- brainstorming 阶段询问“是否只覆盖企业端？”后，用户回复“运营端也要做回显”。这仍是设计范围修正，必须继续 brainstorming/proposal 文档收敛，不能直接进入代码实现。
+
+## 阶段写入边界
+
+| 阶段 | 允许写入 | 禁止写入 |
+|------|----------|----------|
+| proposal | `openspec/changes/**/proposal.md` | 任何代码或实现文件 |
+| brainstorming | `openspec/changes/**/proposal.md` | 任何代码或实现文件 |
+| spec | `openspec/changes/**`、`plan-ready.md` | 任何代码或实现文件 |
+| build | 代码、测试、实现计划状态 | 规格文档（除非另开变更） |
+| close | 归档、验证记录、`close-issues.md` | 代码、测试、其他实现文件 |
+
+如果用户在 proposal/brainstorming/spec 阶段提出“就按这个做”“范围改成 X”“继续”等话术，不代表进入 build；必须先完成该阶段文档产物并提示下一步。
+
 ## 子命令
 
 | 命令 | 阶段 | 说明 |
@@ -39,10 +64,11 @@ description: "OpenSpec + Superpowers workflow orchestrator. Use /openflow propos
 
 根据子命令或状态检测结果，读取对应阶段文件并执行：
 
-1. 如果用户指定了子命令（如 `/openflow build`），优先按指定阶段执行，但检查前置条件
-2. 如果用户只输入 `/openflow`，执行状态检测，自动路由到对应阶段
-3. 读取当前 openflow skill 目录下的阶段文件：`<阶段>.md`（与本 `SKILL.md` 同目录；不要依赖 Claude 专属环境变量）
-4. 按阶段文件中的流程执行
+1. 如果这是上一 openflow 阶段的续接回复，先按“续接与中断恢复”保持阶段
+2. 如果用户指定了子命令（如 `/openflow build`），优先按指定阶段执行，但检查前置条件
+3. 如果用户只输入 `/openflow`，执行状态检测，自动路由到对应阶段
+4. 读取当前 openflow skill 目录下的阶段文件：`<阶段>.md`（与本 `SKILL.md` 同目录；不要依赖 Claude 专属环境变量）
+5. 按阶段文件中的流程执行，并遵守阶段写入边界
 
 ### 前置条件检查
 

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,10 @@ description: Call Superpowers to execute implementation, supports checkpoint rec
 
 读取 plan-ready.md，调用 Superpowers 的 writing-plans 生成详细实现计划，然后按 TDD 铁律执行。
 
+## 中断续接规则
+
+如果用户在 build 阶段被打断后继续回复、说“继续”、或补充实现细节，保持 build 阶段并从实现计划/checkbox 状态恢复。不要回到 proposal、brainstorming 或 spec，除非用户明确要求修改需求或重新生成规格。
+
 ## 前置条件
 
 - `openspec/changes/<变更名>/plan-ready.md` 存在
@@ -70,5 +74,6 @@ docs/superpowers/plans/YYYY-MM-DD-<变更名>.md
 ## 关键原则
 
 - **不允许在 build 阶段修改规格文档** — 发现问题先记录，留到 close 阶段处理
+- 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 执行时回溯
 - 按执行依赖排序是翻译的关键步骤：先依赖后依赖方