6a-spec-install 1.0.8-dev.2 → 1.0.8-dev.4

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

@@ -15,7 +15,7 @@
 
 **1.1 检查是否在需求目录下**
 
-检查当前工作目录是否在 `6aspec/green/<feature-name>/` 下：
+检查当前工作目录是否在 `6aspecdoc/green/<feature-name>/` 下：
 
 ```bash
 pwd
@@ -26,7 +26,7 @@ pwd
 **1.2 如果不在需求目录下，列出所有活跃需求**
 
 ```bash
-find 6aspec/green -maxdepth 2 -name ".green-status.json" -type f
+find 6aspecdoc/green -maxdepth 2 -name ".green-status.json" -type f
 ```
 
 如果找到多个需求，使用 **AskUserQuestion** 让用户选择要查看的需求。
@@ -40,10 +40,10 @@ find 6aspec/green -maxdepth 2 -name ".green-status.json" -type f
 
 ### Step 2: 读取状态文件
 
-读取 `6aspec/green/<feature-name>/.green-status.json` 文件：
+读取 `6aspecdoc/green/<feature-name>/.green-status.json` 文件：
 
 ```javascript
-const statusPath = '6aspec/green/<feature-name>/.green-status.json';
+const statusPath = '6aspecdoc/green/<feature-name>/.green-status.json';
 const status = JSON.parse(fs.readFileSync(statusPath, 'utf8'));
 ```
 
@@ -241,7 +241,7 @@ const status = JSON.parse(fs.readFileSync(statusPath, 'utf8'));
 ```
 错误：未找到状态文件
 
-路径：6aspec/green/<feature-name>/.green-status.json
+路径：6aspecdoc/green/<feature-name>/.green-status.json
 
 这可能是因为：
 1. 需求目录不是通过 /6aspec:green:new 创建的
@@ -255,7 +255,7 @@ const status = JSON.parse(fs.readFileSync(statusPath, 'utf8'));
 ```
 错误：状态文件格式错误
 
-路径：6aspec/green/<feature-name>/.green-status.json
+路径：6aspecdoc/green/<feature-name>/.green-status.json
 
 错误信息：<parse-error>
 
@@ -266,7 +266,7 @@ const status = JSON.parse(fs.readFileSync(statusPath, 'utf8'));
 
 1. **只读操作**：status 命令只读取状态，不修改任何文件
 2. **时间格式化**：显示时间时使用易读格式（YYYY-MM-DD HH:mm）
-3. **路径简化**：显示文件路径时使用相对路径，省略 `6aspec/green/<feature-name>/` 前缀
+3. **路径简化**：显示文件路径时使用相对路径，省略 `6aspecdoc/green/<feature-name>/` 前缀
 4. **用户友好**：使用图标和颜色（如果终端支持）提升可读性
 5. **状态一致性**：如果发现状态不一致（如工件状态与生命周期状态不匹配），显示警告信息
 

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

@@ -13,8 +13,8 @@ alwaysApply: false
 
 在执行任务拆解前，**必须**先完成依赖检查，不通过则**立即停止**并提示，不得继续：
 
-1. **确定当前需求**：根据当前工作目录或用户 @ 的文件，确定 `6aspec/green/<feature-name>/`；若有多个需求则让用户选择。
-2. **读取状态文件**：读取 `6aspec/green/<feature-name>/.green-status.json`。若文件不存在，停止并提示先运行 `/6aspec:green:new` 创建需求。
+1. **确定当前需求**：根据当前工作目录或用户 @ 的文件，确定 `6aspecdoc/green/<feature-name>/`；若有多个需求则让用户选择。
+2. **读取状态文件**：读取 `6aspecdoc/green/<feature-name>/.green-status.json`。若文件不存在，停止并提示先运行 `/6aspec:green:new` 创建需求。
 3. **检查上一流程已完成**：
    - 若 `status` 不是 `designed`，停止并提示：
      ```
@@ -26,7 +26,7 @@ alwaysApply: false
      请先完成技术方案设计：运行 /6aspec:green:design，并确保生成 artifacts/tech-design.md、api-definition.md 且状态已更新为 designed。
      ```
    - 若 `artifacts.design.status` 不是 `done`，停止并提示先运行 `/6aspec:green:design` 完成技术方案。
-4. **检查 tech-design.md 存在**：若 `6aspec/green/<feature-name>/artifacts/tech-design.md` 不存在，停止并提示先完成技术方案设计。
+4. **检查 tech-design.md 存在**：若 `6aspecdoc/green/<feature-name>/artifacts/tech-design.md` 不存在，停止并提示先完成技术方案设计。
 
 **只有以上检查全部通过后，才允许继续执行本 SOP 的拆解步骤。**
 
@@ -35,7 +35,7 @@ alwaysApply: false
 你是一个**技术项目经理 (TPM)**。在执行任务拆解前，请严格遵守：
 
 1.  **主动检索 (Active Retrieval)**：
-    *   当用户指定 `{功能名称}` 时，优先尝试读取 `6aspec/green/<feature-name>/artifacts/tech-design.md`。
+    *   当用户指定 `{功能名称}` 时，优先尝试读取 `6aspecdoc/green/<feature-name>/artifacts/tech-design.md`。
     *   如果找不到 TDD 文档，**立即停止**并报错，提示用户先完成 TDD 设计。
 
 2.  **思维链门禁 (Chain of Thought Gatekeeping)**：
@@ -76,7 +76,7 @@ alwaysApply: false
 
 ### 1. 目录结构
 所有任务文件必须存储在以下路径：
-- `6aspec/green/<feature-name>/tasks/`（feature-name 使用 kebab-case 命名，如：user-authentication）
+- `6aspecdoc/green/<feature-name>/tasks/`（feature-name 使用 kebab-case 命名，如：user-authentication）
 
 ### 2. 文件命名规范
 - 格式：`task-{序号}-{任务类型}-{功能简名}.md`
@@ -141,16 +141,16 @@ alwaysApply: false
 2. **合并依赖项**：将该入口点涉及的所有业务逻辑（Service）、数据访问（Repository）、模型定义（DTO/VO/Enum）全部归入该入口点的原子任务中。
 3. **排序与编排**：基于`<thinking>`中的依赖分析，对任务进行逻辑排序（先基础后上层，先前置后依赖）。
 4. **生成文件**：为每个识别出的入口点生成独立的任务 Markdown 文件。
-5. **生成总览**：任务拆解完成后，必须在 `6aspec/green/<feature-name>/tasks/README.md` 输出任务总览。
+5. **生成总览**：任务拆解完成后，必须在 `6aspecdoc/green/<feature-name>/tasks/README.md` 输出任务总览。
 6. **状态维护（必须执行）**：后续每当完成一个任务，必须同步更新：
    - 对应任务文件中的"任务状态"。
-   - `6aspec/green/<feature-name>/tasks/README.md` 中该任务的状态展示。
+   - `6aspecdoc/green/<feature-name>/tasks/README.md` 中该任务的状态展示。
 
 ## 输出要求
 1. **格式**：Markdown 源码格式。
 2. **一致性**：任务中的类名、方法名和字段名必须与 TDD 保持完全一致。
 3. **禁用范围**：不拆解前端任务、不拆解单纯的单元测试任务、不拆解 Entity/SQL 任务。
-4. **总览 README（必须输出）**：在 `6aspec/green/<feature-name>/tasks/README.md` 生成任务总览文件，必须包含：
+4. **总览 README（必须输出）**：在 `6aspecdoc/green/<feature-name>/tasks/README.md` 生成任务总览文件，必须包含：
    - **项目进度看板**：任务总工时、已完成工时、进度条。
    - **任务清单**：按推荐执行顺序排列，包含状态图标 (✅/🔄/⏳)。
    - **开发阶段划分**：建议将任务划分为 Phase 1 (Core), Phase 2 (Extensions) 等阶段。

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

@@ -21,14 +21,14 @@ alwaysApply: false
 
 ## 输入要求
 ### 必需输入
-- **TDD 文档路径**：`6aspec/green/<feature-name>/artifacts/tech-design.md`（feature-name 使用 kebab-case 命名，如：user-authentication）
+- **TDD 文档路径**：`6aspecdoc/green/<feature-name>/artifacts/tech-design.md`（feature-name 使用 kebab-case 命名，如：user-authentication）
 - **人类选择的生成范围（必须明确，否则中断提问）**：
   - 需要生成的图表类型：Flowchart / Sequence / State（可多选）
   - 覆盖范围：具体到“哪些入口/哪些业务流程/哪些对象”（例如：仅 `3.1` 中某个写 API；或某个事件订阅；或某个后台任务）
   - 抽象层级：是否细到 service/repository/facade 级别（建议默认到 service/repository/facade）
 
 ### 可选输入（用于补齐 TDD 未显式写清的信息）
-- 数据模型文档：`6aspec/green/<feature-name>/artifacts/domain-model.md`
+- 数据模型文档：`6aspecdoc/green/<feature-name>/artifacts/domain-model.md`
 - PRD：`.prd/{功能名称}-prd.md`
 - 事件清单：`./.6aspec/biz/event-list.md`（当涉及事件订阅/发布时）
 - 能力地图：`./.6aspec/biz/functional-capability-Map.md`（当涉及跨模块 Facade 依赖时）
@@ -42,7 +42,7 @@ alwaysApply: false
 
 ## 输出要求
 1. **输出格式**：Markdown 源码 + Mermaid 代码块（严禁截图）
-2. **输出位置**：`6aspec/green/<feature-name>/artifacts/visual-logic.md`
+2. **输出位置**：`6aspecdoc/green/<feature-name>/artifacts/visual-logic.md`
 3. **引用关系**：在输出文档开头必须写明：
    - 输入 TDD 文档路径
    - 本次选择生成的图表类型与覆盖范围
@@ -88,7 +88,7 @@ alwaysApply: false
 - 迁移必须标注触发入口（API/事件/定时任务/后台任务）
 
 ### 第四步：输出文档并自检
-1. 写入 `6aspec/green/<feature-name>/artifacts/visual-logic.md`
+1. 写入 `6aspecdoc/green/<feature-name>/artifacts/visual-logic.md`
 2. 自检：
    - Mermaid 语法是否完整
    - 是否严格遵循"按需生成"与"范围约束"

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

@@ -7,7 +7,7 @@
 ## 文件位置
 
 ```
-6aspec/green/<feature-name>/.green-status.json
+6aspecdoc/green/<feature-name>/.green-status.json
 ```
 
 ## 状态文件结构
@@ -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`。
+
 ## 示例
 
 ### 初始状态（刚创建）
@@ -132,19 +145,19 @@ tasks (任务列表)
   "artifacts": {
     "requirement": {
       "status": "pending",
-      "path": "6aspec/green/user-authentication/requirement.md"
+      "path": "6aspecdoc/green/user-authentication/requirement.md"
     },
     "models": {
       "status": "blocked",
-      "path": "6aspec/green/user-authentication/artifacts/"
+      "path": "6aspecdoc/green/user-authentication/artifacts/"
     },
     "design": {
       "status": "blocked",
-      "path": "6aspec/green/user-authentication/artifacts/"
+      "path": "6aspecdoc/green/user-authentication/artifacts/"
     },
     "tasks": {
       "status": "blocked",
-      "path": "6aspec/green/user-authentication/tasks/"
+      "path": "6aspecdoc/green/user-authentication/tasks/"
     }
   },
   "tasks": {
@@ -170,20 +183,20 @@ tasks (任务列表)
   "artifacts": {
     "requirement": {
       "status": "done",
-      "path": "6aspec/green/user-authentication/requirement.md",
+      "path": "6aspecdoc/green/user-authentication/requirement.md",
       "completedAt": "2026-02-16T03:15:00Z"
     },
     "models": {
       "status": "ready",
-      "path": "6aspec/green/user-authentication/artifacts/"
+      "path": "6aspecdoc/green/user-authentication/artifacts/"
     },
     "design": {
       "status": "blocked",
-      "path": "6aspec/green/user-authentication/artifacts/"
+      "path": "6aspecdoc/green/user-authentication/artifacts/"
     },
     "tasks": {
       "status": "blocked",
-      "path": "6aspec/green/user-authentication/tasks/"
+      "path": "6aspecdoc/green/user-authentication/tasks/"
     }
   },
   "tasks": {
@@ -209,23 +222,23 @@ tasks (任务列表)
   "artifacts": {
     "requirement": {
       "status": "done",
-      "path": "6aspec/green/user-authentication/requirement.md",
+      "path": "6aspecdoc/green/user-authentication/requirement.md",
       "completedAt": "2026-02-16T03:15:00Z"
     },
     "models": {
       "status": "done",
-      "path": "6aspec/green/user-authentication/artifacts/",
+      "path": "6aspecdoc/green/user-authentication/artifacts/",
       "completedAt": "2026-02-16T03:45:00Z",
       "files": ["domain-model.md"]
     },
     "design": {
       "status": "done",
-      "path": "6aspec/green/user-authentication/artifacts/",
+      "path": "6aspecdoc/green/user-authentication/artifacts/",
       "completedAt": "2026-02-16T04:15:00Z"
     },
     "tasks": {
       "status": "done",
-      "path": "6aspec/green/user-authentication/tasks/",
+      "path": "6aspecdoc/green/user-authentication/tasks/",
       "completedAt": "2026-02-16T04:30:00Z",
       "files": ["task_01_user_model.md", "task_02_auth_api.md", "task_03_session.md"]
     }
@@ -250,7 +263,7 @@ tasks (任务列表)
 所有命令在执行前应该读取状态文件，了解当前状态：
 
 ```javascript
-const statusPath = '6aspec/green/<feature-name>/.green-status.json';
+const statusPath = '6aspecdoc/green/<feature-name>/.green-status.json';
 const status = JSON.parse(fs.readFileSync(statusPath, 'utf8'));
 ```
 

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.2",
+  "version": "1.0.8-dev.4",
   "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