**模式配置**：此提示词在非交互式环境中运行（如 CI/CD、自动化脚本）。

**非交互式模式行为**：
- 禁止使用 `AskUserQuestion` 或任何交互式工具
- 当需要用户输入时，使用合理的默认值（如选择最近修改的变更）
- 跳过可选的确认步骤，记录所做的假设

**交互式模式行为**：
- 遵循正常的交互式流程，提示用户输入

---

在实验性工作流中归档已完成的变更。

**输入**：可选地指定变更名称（例如，`add-auth`）。如果省略，检查是否可以从对话上下文推断。如果模糊或不明确，你必须提示可用的变更。

**步骤**

1. **如果未提供变更名称，使用合理的默认值**

   如果提供了名称，使用它。否则：
   - **在非交互式模式下**：选择最近修改的变更
   - **在交互式模式下**：运行 `openspec list --json` 以获取可用的变更并让用户选择

   当向用户显示选项时，仅显示活动变更（尚未归档）。
   如果可用，包括每个变更使用的 schema。

   始终宣布："归档变更：<name>"以及如何覆盖。

2. **检查工件完成状态**

   运行 `openspec status --change "<name>" --json` 以检查工件完成情况。

   解析 JSON 以了解：
   - `schemaName`：正在使用的工作流
   - `artifacts`：工件列表及其状态（`done` 或其他）

   **如果任何工件不是 `done`：**
   - 显示警告，列出未完成的工件
   - **在交互式模式下**：提示用户确认继续
   - **在非交互式模式下**：记录假设并继续
   - 如果用户确认或在非交互式模式下，继续

3. **检查任务完成状态**

   读取 tasks 文件（通常是 `tasks.md`）以检查未完成的任务。

   计算标记为 `- [ ]`（未完成）与 `- [x]`（完成）的任务。

   **如果发现未完成的任务：**
   - 显示警告，显示未完成任务的数量
   - **在交互式模式下**：提示用户确认继续
   - **在非交互式模式下**：记录假设并继续
   - 如果用户确认或在非交互式模式下，继续

   **如果不存在 tasks 文件**：在没有任务相关警告的情况下继续。

4. **评估 delta spec 同步状态（强制同步）**

   在 `openspec/changes/<name>/specs/` 检查 delta specs。

   {%-*
   EMBEDDED SYNC LOGIC FROM openspec-v1-sync.zh-CN.scriban
   The following steps (查找 delta specs, 对于每个 delta spec，将更改应用到主 specs)
   are embedded from sync template to ensure self-contained archive operation.
   *-%}

   **如果不存在 delta specs：**
   - 直接继续归档步骤

   **如果存在 delta specs：**
   - **必须执行 spec sync 操作**（强制同步）

   **第一步：查找 delta specs**

   在 `openspec/changes/<name>/specs/*/spec.md` 中查找 delta spec 文件。

   每个 delta spec 文件包含以下部分：
   - `## ADDED Requirements` - 要添加的新需求
   - `## MODIFIED Requirements` - 对现有需求的更改
   - `## REMOVED Requirements` - 要删除的需求
   - `## RENAMED Requirements` - 要重命名的需求（FROM:/TO: 格式）

   **第二步：对于每个 delta spec，将更改应用到主 specs**

   对于位于 `openspec/changes/<name>/specs/<capability>/spec.md` 的每个具有 delta spec 的能力：

   a. **读取 delta spec** 以了解预期的更改

   b. **读取主 spec** 位于 `openspec/specs/<capability>/spec.md`（可能尚不存在）

   c. **智能地应用更改**：

      **ADDED Requirements：**
      - 如果主 spec 中不存在需求 → 添加它
      - 如果需求已存在 → 更新它以匹配（视为隐式 MODIFIED）

      **MODIFIED Requirements：**
      - 在主 spec 中找到需求
      - 应用更改 - 这可以是：
        - 添加新场景（不需要复制现有场景）
        - 修改现有场景
        - 更改需求描述
      - 保留 delta 中未提及的场景/内容

      **REMOVED Requirements：**
      - 从主 spec 中删除整个需求块

      **RENAMED Requirements：**
      - 找到 FROM 需求，重命名为 TO

   d. **如果能力尚不存在，创建新主 spec**：
      - 创建 `openspec/specs/<capability>/spec.md`
      - 添加 Purpose 部分（可以简短，标记为 TBD）
      - 添加包含 ADDED 需求的 Requirements 部分

   **关键原则：智能合并**

   与程序化合并不同，你可以应用**部分更新**：
   - 要添加场景，只需在 MODIFIED 下包含该场景 - 不要复制现有场景
   - delta 代表*意图*，而不是整体替换
   - 使用你的判断来明智地合并更改

   **同步失败处理：**
   - 如果同步失败（合并冲突、验证错误），**阻止归档操作**并显示错误
   - 显示同步失败的详细错误信息
   - 提供解决指导（例如：解决 delta spec 中的冲突，然后重试归档）
   - 保留变更目录在原始位置（不部分归档）

   **在执行前显示组合摘要**，包括：
   - 将应用哪些更改（添加、修改、删除、重命名的需求）
   - 将更新哪些能力

5. **执行归档（无条件）**

   **归档是无条件的**：无论工件或任务完成状态如何，都必须执行归档操作。

   如果归档目录不存在，则创建：
   ```bash
   mkdir -p openspec/changes/archive
   ```

   使用当前日期生成目标名称：`YYYY-MM-DD-<change-name>`

   **检查目标是否已存在：**
   - 如果是：失败并显示错误，建议重命名现有归档或使用不同日期
   - 如果否：将变更目录移动到归档

   ```bash
   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
   git add openspec/changes/<name>
   git add openspec/changes/archive/YYYY-MM-DD-<name>
   ```

   {{#if isMonoSpecs}}
   **这是一个 MonoSpecs 仓库。**

   **仓库类型**：MonoSpecs（规范驱动开发）
   **仓库路径**：`{{ monospecsRepoPath }}`
   {{/if}}

   {{#if commitWhenArchive}}
   **此仓库启用了自动提交。**

   **重要提示**：归档变更后，你必须执行 Git 提交。

   **关键**：仅在 MonoSpecs 仓库根目录提交：`{{ monospecsRepoPath }}`

   **警告**：不要在任何代码仓库（`repos/` 目录下）中提交。
   提交必须仅影响包含 `openspec/` 目录的 MonoSpecs 仓库。

   **精确暂存策略**：
   - `mv` 命令移动目录，然后 `git add` 暂存删除和添加操作
   - 如果存在 delta specs 且在步骤 4 中已同步，需要额外暂存同步的规范文件变更，使用 `git add openspec/specs/`
   - **MonoSpecs 多用户环境警告**：使用精确暂存策略避免提交其他用户的变更

   ```bash
   # 验证你在 MonoSpecs 仓库根目录
   pwd  # 应该显示：{{ monospecsRepoPath }}

   # 如果存在 delta specs 且在步骤 4 中已同步，暂存同步的规范文件变更
   # 检查 openspec/specs/ 在同步操作期间是否被修改
   git status openspec/specs/
   # 如果上述命令显示有修改，执行：git add openspec/specs/

   # 检查暂存区内容（验证归档相关变更已暂存）
   git diff --cached --name-only

   # 如果输出包含 openspec/changes/archive/YYYY-MM-DD-<name>/，执行提交
   # 使用增强的消息格式（包含 proposal 上下文和 Co-Authored-By 声明）
   ```

   **生成增强的 Commit Message**：

   a. **读取提案内容**：
      - 读取归档目录下的 `openspec/changes/archive/YYYY-MM-DD-<name>/proposal.md` 文件
      - 注意：由于目录已通过 `mv` 移动到 archive，路径使用 archive 下的路径

   b. **提取关键信息**：
      - **Summary**：从 "## Why" 部分提取 1-2 句话作为提案摘要
      - **Changes**：从 "## What Changes" 部分提取变更列表（转换为 bullet points）
      - **Capabilities**：从 "## Capabilities > Modified Capabilities" 部分提取修改的能力名称

   c. **格式化 commit message**：
      使用以下模板生成多行 commit message：

      ```bash
      git commit -m "$(cat <<'EOF'
      Archive OpenSpec change: <change-name>

      <Summary from Why section (1-2 sentences)>

      Changes:
      - <Change 1 from What Changes>
      - <Change 2 from What Changes>
      - <Change 3...>

      Capabilities: <modified-specs>

      {{#if coAuthoredByTrailer}}{{{coAuthoredByTrailer}}}{{else}}Co-Authored-By: Hagicode <noreply@hagicode.com>{{/if}}
      EOF
      )"
      ```

   d. **Fallback 处理**：
      - 如果 `proposal.md` 文件不存在或无法读取，使用简化格式：
      ```bash
      git commit -m "$(cat <<'EOF'
      Archive OpenSpec change: <change-name>

      {{#if coAuthoredByTrailer}}{{{coAuthoredByTrailer}}}{{else}}Co-Authored-By: Hagicode <noreply@hagicode.com>{{/if}}
      EOF
      )"
      ```
      - 如果 proposal.md 存在但无法解析（格式异常、缺少预期章节等）：
        - 如果只有 Why 部分可解析，生成仅包含 Summary 的增强格式
        - 如果只有 What Changes 部分可解析，生成仅包含 Changes 列表的增强格式
        - 如果两部分都无法解析，使用上述 fallback 格式
      - **确保 Co-Authored-By 声明始终包含在所有格式中**

   **Commit Message 格式要求**：
   - Summary 段落不超过 2 句话
   - Changes 列表包含最多 7 个变更项（如果超过，使用概括性描述或省略次要项）
   - Capabilities 行列出所有修改的能力，用逗号分隔
   - Co-Authored-By 行位于提交信息末尾，之前有一个空行

   **提交后：**
   - 验证提交已创建：`git log -1 --oneline`
   - 归档完成并已提交
   {{/if}}

6. **显示摘要**

   显示归档完成摘要，包括：
   - 变更名称
   - 使用的 schema
   - 归档位置
   - Spec 同步状态（已同步 / 跳过同步 / 无 delta specs）
   - 关于任何警告的说明（未完成的工件/任务）

**成功时的输出**

```
## 归档完成

**变更：** <change-name>
**Schema：** <schema-name>
**归档到：** openspec/changes/archive/YYYY-MM-DD-<name>/
**Specs：** ✓ 已同步到主 specs
{{#if isMonoSpecs}}
**仓库类型**：MonoSpecs
{{/if}}
{{#if commitWhenArchive}}
**Git：** ✓ 已提交（Archive OpenSpec change: <change-name>）
{{/if}}

所有工件完成。所有任务完成。
```

**成功时的输出（无 Delta Specs）**

```
## 归档完成

**变更：** <change-name>
**Schema：** <schema-name>
**归档到：** openspec/changes/archive/YYYY-MM-DD-<name>/
**Specs：** 无 delta specs
{{#if isMonoSpecs}}
**仓库类型**：MonoSpecs
{{/if}}
{{#if commitWhenArchive}}
**Git：** ✓ 已提交（Archive OpenSpec change: <change-name>）
{{/if}}

所有工件完成。所有任务完成。
```

**成功时的输出（带警告）**

```
## 归档完成（带警告）

**变更：** <change-name>
**Schema：** <schema-name>
**归档到：** openspec/changes/archive/YYYY-MM-DD-<name>/
**Specs：** ✓ 已同步到主 specs

**警告：**
- 归档时 2 个工件未完成
- 归档时 3 个任务未完成

如果这不是有意的，请检查归档。
```

**错误时的输出（归档已存在）**

```
## 归档失败

**变更：** <change-name>
**目标：** openspec/changes/archive/YYYY-MM-DD-<name>/

目标归档目录已存在。

**选项：**
1. 重命名现有归档
2. 删除现有归档（如果是重复的）
3. 等待不同日期再归档
```

**保护措施**
- 如果未提供，始终提示变更选择
- 使用工件图（openspec status --json）进行完成检查
- **强制同步**：如果存在 delta specs，必须先执行 spec sync 操作
- **无条件归档**：无论工件或任务完成状态如何，都必须执行归档
- **同步失败时阻止**：如果 spec sync 失败，阻止归档并显示错误信息
- 移动到归档时保留 .openspec.yaml（它随目录移动）
- 清楚地显示发生的事情
- 始终执行同步评估并在执行前显示组合摘要
{{#if commitWhenArchive}}
- **Git 提交范围限制**：仅在 `{{ monospecsRepoPath }}` 的 MonoSpecs 仓库中提交
- **不要在代码仓库中提交**：永远不要在 `repos/` 目录下的任何仓库中提交
- **归档后始终提交**：在 MonoSpecs 仓库中归档后始终执行 Git 提交
- **使用 mv 处理未跟踪文件**：使用 `mv` 而非 `git mv` 来移动变更目录，因为 `git mv` 对未跟踪文件会失败
- **精确暂存策略**：
  - 移动后使用 `git add` 暂存原始位置的删除
  - 使用 `git add` 暂存新位置的添加
  - 仅当存在 delta specs 时执行 `git add openspec/specs/`
  - 检查暂存区内容（`git diff --cached --name-only`）后再提交
- **MonoSpecs 多用户环境警告**：MonoSpecs 仓库可能同时有多个编辑，使用精确暂存避免提交无关变更
- **验证工作目录**：运行 git 命令前始终验证当前目录
{{/if}}
