6a-spec-install 1.0.8-dev.3 → 1.0.8

package/.6aspec/rules/green/6A_clarify_sop.md

@@ -19,6 +19,7 @@
 ## 前置条件
 - 已通过 `/6aspec:green:new` 创建了需求目录和初始 `requirement.md`
 - 状态文件 `.green-status.json` 存在
+- **阶段限制**：需求澄清（clarify）仅允许在 **new 之后、领域建模（model）之前** 执行。进入领域建模及后续阶段后，不得再执行需求澄清。
 
 ## 输入要求
 - **自动读取**：现有的 `requirement.md` 和 `.green-status.json`
@@ -43,15 +44,22 @@ find 6aspecdoc/green -maxdepth 2 -name ".green-status.json" -type f
 - 读取 `6aspecdoc/green/<feature-name>/.green-status.json`
 - 读取 `6aspecdoc/green/<feature-name>/requirement.md`
 
-**1.3 状态检查**
+**1.3 阶段门禁（必须通过，否则拒绝执行）**
 
-允许的状态：`created` 或 `requirement_clarified`
+需求澄清仅允许在 **new 之后、model 之前** 执行。读取状态文件后，检查 `status`：
+
+- **允许执行**：仅当 `status` 为 **`created`** 或 **`requirement_clarified`** 时，允许继续执行本 SOP。
+- **拒绝执行**：若 `status` 为 **`modeled`**、**`designed`**、**`tasks_created`**、**`implementing`**、**`completed`**、**`archived`** 中任一，则**立即停止**，不得进行任何需求文档修改或澄清对话，并输出：
 
-如果状态不符合，输出：
 ```
-⚠️ 当前状态为 <status>，通常在 "created" 或 "requirement_clarified" 阶段执行 clarify。
+❌ 不允许执行需求澄清 (clarify)
+
+当前状态：<status>
+允许执行 clarify 的阶段：仅限 created 或 requirement_clarified（即 new 之后、领域建模 model 之前）。
+
+主流程中需求澄清窗口已结束，进入领域建模及后续阶段后不得再修改需求澄清范围。若确有需求变更，请与产品/业务方评估后，通过新需求或变更流程处理。
 
-是否继续？（在后续阶段执行 clarify 会更新需求文档但不会回退状态）
+下一步建议：运行 /6aspec:green:status 查看当前状态，或按当前阶段继续执行对应命令（如 model、design、tasks、execute-task、archive）。
 ```
 
 ### Step 2: 分析现有文档的薄弱环节
@@ -184,6 +192,7 @@ find 6aspecdoc/green -maxdepth 2 -name ".green-status.json" -type f
 4. 更新后检查文档格式是否符合 `new` SOP 中的模板规范
 
 ## 注意
+- **阶段限制**：仅当状态为 `created` 或 `requirement_clarified` 时可执行；进入 `modeled` 及之后阶段后**禁止**执行 clarify，直接拒绝并提示。
 - **不可覆盖**：绝不可覆盖用户之前已确认的结论，只能追加新信息
 - **递进深入**：每一轮 clarify 的问题应该比上一轮更深入、更具体
 - **适时收敛**：如果评估所有维度都是 🟢，应主动建议用户进入下一步（领域建模），而不是无限制地继续澄清

package/.6aspec/rules/green/6A_rollback_sop.md

@@ -0,0 +1,198 @@
+# rollback: 流程回退标准操作流程 (Rollback SOP)
+
+## 目标
+将当前需求回退**一个阶段**，并删除该阶段生成的工件，以便重新执行上一阶段或修正后重做本阶段。仅允许单步回退，且**必须获得用户明确确认后**才执行删除与状态更新。
+
+## 规则
+1. **单步回退**：每次只能回退一个阶段，不允许跨多阶段回退
+2. **先提示后执行**：必须先列出将删除的文件并提示用户，**只有在用户给出明确确认指令后**才允许执行删除和状态更新
+3. **禁止从实现阶段回退**：状态为 `implementing`、`completed`、`archived` 时不允许回退；`created` 无上一阶段，也不允许
+
+## 允许回退的状态与目标
+
+| 当前状态 | 回退后状态 | 将删除的工件 |
+|----------|------------|--------------|
+| `requirement_clarified` | `created` | `6aspecdoc/green/<feature-name>/requirement.md` |
+| `modeled` | `requirement_clarified` | `6aspecdoc/green/<feature-name>/artifacts/domain-model.md` |
+| `designed` | `modeled` | `6aspecdoc/green/<feature-name>/artifacts/tech-design.md`、`api-definition.md`；若存在则一并删除 `artifacts/visual-logic.md` |
+| `tasks_created` | `designed` | `6aspecdoc/green/<feature-name>/tasks/` 目录下全部文件（含 `README.md` 及所有 `task-*.md`） |
+
+## 执行步骤
+
+### Step 1: 确定需求并读取状态
+
+1. **确定当前需求**：根据当前工作目录或用户 @ 的文件，确定 `6aspecdoc/green/<feature-name>/`；若有多个需求则让用户选择。
+2. **读取状态文件**：读取 `6aspecdoc/green/<feature-name>/.green-status.json`。若文件不存在，停止并提示先运行 `/6aspec:green:new`。
+3. **阶段门禁**：检查 `status`：
+   - **允许回退**：仅当 `status` 为 `requirement_clarified`、`modeled`、`designed`、`tasks_created` 之一时继续。
+   - **拒绝回退**：若为 `created`、`implementing`、`completed`、`archived`，则停止并输出：
+
+```
+❌ 不允许执行回退 (rollback)
+
+当前状态：<status>
+
+允许回退的阶段：仅限 requirement_clarified、modeled、designed、tasks_created。
+created（无上一阶段）、implementing（已进入代码实现）、completed、archived 不允许回退。
+
+若已进入实现阶段且需求有变更，建议通过修改需求/设计文档并补充任务处理，或新建需求。
+```
+
+### Step 2: 列出回退影响并请求用户明确确认
+
+根据当前状态，输出**回退影响说明**，并**禁止在未得到用户明确确认前执行任何删除或写状态文件操作**。
+
+输出格式（必须包含以下内容）：
+
+```markdown
+## 回退影响说明
+
+- **当前状态**：<current-status>
+- **回退后状态**：<target-status>
+- **回退后下一步**：需重新执行 <command>（<描述>）
+
+### 即将删除的文件（执行回退后将不可恢复）
+
+<按下面表格根据当前状态填写>
+
+| 路径 | 说明 |
+|------|------|
+| <path1> | <说明> |
+| <path2> | <说明> |
+
+### 状态文件更新
+
+- `.green-status.json` 中 `status` 将更新为 `<target-status>`
+- 当前阶段对应工件的 `status` 将置为 pending/blocked
+
+---
+
+⚠️ **请确认后再执行回退**
+
+回退将**永久删除**上述文件，且不可通过本命令恢复。
+
+请明确回复以下之一后，我才会执行删除与状态更新：
+- **「确认回退」**
+- **「执行回退」**
+
+若不需要回退，请直接说明取消。
+```
+
+**根据当前状态填写的删除清单：**
+
+- **requirement_clarified → created**  
+  | 路径 | 说明 |
+  |------|------|
+  | `6aspecdoc/green/<feature-name>/requirement.md` | 需求澄清文档 |
+
+- **modeled → requirement_clarified**  
+  | 路径 | 说明 |
+  |------|------|
+  | `6aspecdoc/green/<feature-name>/artifacts/domain-model.md` | 领域模型文档 |
+
+- **designed → modeled**  
+  | 路径 | 说明 |
+  |------|------|
+  | `6aspecdoc/green/<feature-name>/artifacts/tech-design.md` | 技术设计文档 |
+  | `6aspecdoc/green/<feature-name>/artifacts/api-definition.md` | API 定义文档 |
+  | `6aspecdoc/green/<feature-name>/artifacts/visual-logic.md` | 可视化逻辑图（若存在） |
+
+- **tasks_created → designed**  
+  | 路径 | 说明 |
+  |------|------|
+  | `6aspecdoc/green/<feature-name>/tasks/` 下全部文件 | 任务列表及 README 等 |
+
+### Step 3: 等待用户明确确认
+
+- **仅当**用户回复中包含「确认回退」或「执行回退」的**明确意图**时，才继续执行 Step 4。
+- 若用户回复取消、或仅表达犹豫（如「再想想」），则**不执行**回退，并回复已取消。
+- 若用户未明确确认，则**不得**执行任何文件删除或状态文件写入。
+
+### Step 4: 执行回退（仅在用户已明确确认后）
+
+4.1 **删除工件文件**  
+按 Step 2 中列出的路径执行删除（若某路径不存在则跳过，不报错）。
+
+4.2 **更新 `.green-status.json`**  
+按当前回退类型更新状态与工件状态（见下表），并更新 `lastModified`、`nextAction`。
+
+**requirement_clarified → created**
+
+```json
+{
+  "status": "created",
+  "lastModified": "<ISO8601-now>",
+  "artifacts": {
+    "requirement": { "status": "pending", "path": "..." },
+    "models": { "status": "blocked", "path": "..." },
+    "design": { "status": "blocked", "path": "..." },
+    "tasks": { "status": "blocked", "path": "..." }
+  },
+  "nextAction": { "command": "new", "description": "完成需求澄清" }
+}
+```
+
+**modeled → requirement_clarified**
+
+```json
+{
+  "status": "requirement_clarified",
+  "lastModified": "<ISO8601-now>",
+  "artifacts": {
+    "models": { "status": "ready", "path": "..." },
+    "design": { "status": "blocked", "path": "..." },
+    "tasks": { "status": "blocked", "path": "..." }
+  },
+  "nextAction": { "command": "model", "description": "开始领域建模" }
+}
+```
+
+**designed → modeled**
+
+```json
+{
+  "status": "modeled",
+  "lastModified": "<ISO8601-now>",
+  "artifacts": {
+    "design": { "status": "blocked", "path": "..." },
+    "tasks": { "status": "blocked", "path": "..." }
+  },
+  "tasks": { "total": 0, "completed": 0, "remaining": 0 },
+  "nextAction": { "command": "design", "description": "开始技术方案设计" }
+}
+```
+
+**tasks_created → designed**
+
+```json
+{
+  "status": "designed",
+  "lastModified": "<ISO8601-now>",
+  "artifacts": {
+    "tasks": { "status": "blocked", "path": "..." }
+  },
+  "tasks": { "total": 0, "completed": 0, "remaining": 0 },
+  "nextAction": { "command": "tasks", "description": "开始任务拆解" }
+}
+```
+
+### Step 5: 输出回退结果
+
+```
+✅ 回退已执行
+
+需求：<feature-name>
+回退前状态：<previous-status>
+当前状态：<new-status>
+已删除：<列出已删除的路径>
+
+下一步：请运行 /6aspec:green:<command> 重新执行该阶段（或先修改需求/设计后再执行）。
+```
+
+## 注意
+- **严禁在未获得用户明确确认前**执行 Step 4 的删除或状态更新。
+- 删除为永久操作，不提供撤销；用户确认前务必确保其理解将删除的内容。
+- 仅支持单步回退；需回退多步时，请多次执行 rollback。
+
+## 参考
+- 状态定义：`.6aspec/rules/green/green_status_schema.md`

package/.6aspec/rules/green/green_status_schema.md

@@ -119,6 +119,19 @@ tasks (任务列表)
    - 条件：用户确认归档
    - 触发：执行归档命令
 
+## 回退（rollback）
+
+仅允许**单步回退**，且**必须先提示用户、获得明确确认后**才可执行；执行时将删除当前阶段生成的工件。
+
+| 当前状态 | 回退后状态 | 触发命令 | 将删除的工件 |
+|----------|------------|----------|--------------|
+| `requirement_clarified` | `created` | `/6aspec:green:rollback` | requirement.md |
+| `modeled` | `requirement_clarified` | `/6aspec:green:rollback` | artifacts/domain-model.md |
+| `designed` | `modeled` | `/6aspec:green:rollback` | artifacts/tech-design.md、api-definition.md、visual-logic.md（若存在） |
+| `tasks_created` | `designed` | `/6aspec:green:rollback` | tasks/ 目录下全部文件 |
+
+**不允许回退**：`created`（无上一阶段）、`implementing`、`completed`、`archived`。详见 `.6aspec/rules/green/6A_rollback_sop.md`。
+
 ## 示例
 
 ### 初始状态（刚创建）

package/.claude/commands/6aspec/green/rollback.md

@@ -0,0 +1,8 @@
+---
+description: 流程回退（单步回退并删除当前阶段工件，需用户明确确认）
+---
+
+1. Immediate response upon activation: rollback workflow has been activated
+2. Read file: `.6aspec/rules/green/6A_rollback_sop.md`
+3. Strictly follow the "Rollback SOP" defined in that file
+4. **Do not** perform any file deletion or status file update until the user has explicitly confirmed (e.g. "确认回退" or "执行回退")

package/.cursor/commands/6aspec/green/rollback.md

@@ -0,0 +1,9 @@
+---
+description: 流程回退（单步回退并删除当前阶段工件，需用户明确确认）
+alwaysApply: false
+---
+
+1. Immediate response upon activation: rollback workflow has been activated
+2. Read file: `.6aspec/rules/green/6A_rollback_sop.md`
+3. Strictly follow the "Rollback SOP" defined in that file
+4. **Do not** perform any file deletion or status file update until the user has explicitly confirmed (e.g. "确认回退" or "执行回退")

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "6a-spec-install",
-  "version": "1.0.8-dev.3",
+  "version": "1.0.8",
   "description": "6A-spec 驱动开发提示词安装工具，支持 Cursor 和 Claude",
   "main": "lib/installer.js",
   "bin": {

package/.claude/commands/opsx/apply.md

@@ -1,152 +0,0 @@
----
-name: "OPSX: Apply"
-description: Implement tasks from an OpenSpec change (Experimental)
-category: Workflow
-tags: [workflow, artifacts, experimental]
----
-
-Implement tasks from an OpenSpec change.
-
-**Input**: Optionally specify a change name (e.g., `/opsx:apply add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **Select the change**
-
-   If a name is provided, use it. Otherwise:
-   - Infer from conversation context if the user mentioned a change
-   - Auto-select if only one active change exists
-   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
-
-   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
-
-2. **Check status to understand the schema**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used (e.g., "spec-driven")
-   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
-
-3. **Get apply instructions**
-
-   ```bash
-   openspec instructions apply --change "<name>" --json
-   ```
-
-   This returns:
-   - Context file paths (varies by schema)
-   - Progress (total, complete, remaining)
-   - Task list with status
-   - Dynamic instruction based on current state
-
-   **Handle states:**
-   - If `state: "blocked"` (missing artifacts): show message, suggest using `/opsx:continue`
-   - If `state: "all_done"`: congratulate, suggest archive
-   - Otherwise: proceed to implementation
-
-4. **Read context files**
-
-   Read the files listed in `contextFiles` from the apply instructions output.
-   The files depend on the schema being used:
-   - **spec-driven**: proposal, specs, design, tasks
-   - Other schemas: follow the contextFiles from CLI output
-
-5. **Show current progress**
-
-   Display:
-   - Schema being used
-   - Progress: "N/M tasks complete"
-   - Remaining tasks overview
-   - Dynamic instruction from CLI
-
-6. **Implement tasks (loop until done or blocked)**
-
-   For each pending task:
-   - Show which task is being worked on
-   - Make the code changes required
-   - Keep changes minimal and focused
-   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
-   - Continue to next task
-
-   **Pause if:**
-   - Task is unclear → ask for clarification
-   - Implementation reveals a design issue → suggest updating artifacts
-   - Error or blocker encountered → report and wait for guidance
-   - User interrupts
-
-7. **On completion or pause, show status**
-
-   Display:
-   - Tasks completed this session
-   - Overall progress: "N/M tasks complete"
-   - If all done: suggest archive
-   - If paused: explain why and wait for guidance
-
-**Output During Implementation**
-
-```
-## Implementing: <change-name> (schema: <schema-name>)
-
-Working on task 3/7: <task description>
-[...implementation happening...]
-✓ Task complete
-
-Working on task 4/7: <task description>
-[...implementation happening...]
-✓ Task complete
-```
-
-**Output On Completion**
-
-```
-## Implementation Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 7/7 tasks complete ✓
-
-### Completed This Session
-- [x] Task 1
-- [x] Task 2
-...
-
-All tasks complete! You can archive this change with `/opsx:archive`.
-```
-
-**Output On Pause (Issue Encountered)**
-
-```
-## Implementation Paused
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 4/7 tasks complete
-
-### Issue Encountered
-<description of the issue>
-
-**Options:**
-1. <option 1>
-2. <option 2>
-3. Other approach
-
-What would you like to do?
-```
-
-**Guardrails**
-- Keep going through tasks until done or blocked
-- Always read context files before starting (from the apply instructions output)
-- If task is ambiguous, pause and ask before implementing
-- If implementation reveals issues, pause and suggest artifact updates
-- Keep code changes minimal and scoped to each task
-- Update task checkbox immediately after completing each task
-- Pause on errors, blockers, or unclear requirements - don't guess
-- Use contextFiles from CLI output, don't assume specific file names
-
-**Fluid Workflow Integration**
-
-This skill supports the "actions on a change" model:
-
-- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
-- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly

package/.claude/commands/opsx/archive.md

@@ -1,157 +0,0 @@
----
-name: "OPSX: Archive"
-description: Archive a completed change in the experimental workflow
-category: Workflow
-tags: [workflow, archive, experimental]
----
-
-Archive a completed change in the experimental workflow.
-
-**Input**: Optionally specify a change name after `/opsx:archive` (e.g., `/opsx:archive add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **If no change name provided, prompt for selection**
-
-   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
-
-   Show only active changes (not already archived).
-   Include the schema used for each change if available.
-
-   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
-
-2. **Check artifact completion status**
-
-   Run `openspec status --change "<name>" --json` to check artifact completion.
-
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used
-   - `artifacts`: List of artifacts with their status (`done` or other)
-
-   **If any artifacts are not `done`:**
-   - Display warning listing incomplete artifacts
-   - Prompt user for confirmation to continue
-   - Proceed if user confirms
-
-3. **Check task completion status**
-
-   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
-
-   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
-
-   **If incomplete tasks found:**
-   - Display warning showing count of incomplete tasks
-   - Prompt user for confirmation to continue
-   - Proceed if user confirms
-
-   **If no tasks file exists:** Proceed without task-related warning.
-
-4. **Assess delta spec sync state**
-
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
-
-   **If delta specs exist:**
-   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
-   - Determine what changes would be applied (adds, modifications, removals, renames)
-   - Show a combined summary before prompting
-
-   **Prompt options:**
-   - If changes needed: "Sync now (recommended)", "Archive without syncing"
-   - If already synced: "Archive now", "Sync anyway", "Cancel"
-
-   If user chooses sync, execute `/opsx:sync` logic. Proceed to archive regardless of choice.
-
-5. **Perform the archive**
-
-   Create the archive directory if it doesn't exist:
-   ```bash
-   mkdir -p openspec/changes/archive
-   ```
-
-   Generate target name using current date: `YYYY-MM-DD-<change-name>`
-
-   **Check if target already exists:**
-   - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
-
-   ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
-   ```
-
-6. **Display summary**
-
-   Show archive completion summary including:
-   - Change name
-   - Schema that was used
-   - Archive location
-   - Spec sync status (synced / sync skipped / no delta specs)
-   - Note about any warnings (incomplete artifacts/tasks)
-
-**Output On Success**
-
-```
-## Archive Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** ✓ Synced to main specs
-
-All artifacts complete. All tasks complete.
-```
-
-**Output On Success (No Delta Specs)**
-
-```
-## Archive Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** No delta specs
-
-All artifacts complete. All tasks complete.
-```
-
-**Output On Success With Warnings**
-
-```
-## Archive Complete (with warnings)
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** Sync skipped (user chose to skip)
-
-**Warnings:**
-- Archived with 2 incomplete artifacts
-- Archived with 3 incomplete tasks
-- Delta spec sync was skipped (user chose to skip)
-
-Review the archive if this was not intentional.
-```
-
-**Output On Error (Archive Exists)**
-
-```
-## Archive Failed
-
-**Change:** <change-name>
-**Target:** openspec/changes/archive/YYYY-MM-DD-<name>/
-
-Target archive directory already exists.
-
-**Options:**
-1. Rename the existing archive
-2. Delete the existing archive if it's a duplicate
-3. Wait until a different date to archive
-```
-
-**Guardrails**
-- Always prompt for change selection if not provided
-- Use artifact graph (openspec status --json) for completion checking
-- Don't block archive on warnings - just inform and confirm
-- Preserve .openspec.yaml when moving to archive (it moves with the directory)
-- Show clear summary of what happened
-- If sync is requested, use /opsx:sync approach (agent-driven)
-- If delta specs exist, always run the sync assessment and show the combined summary before prompting