--- name: openspec-archive-change description: 在实验性工作流中归档已完成的变更。当用户想要在实施完成后最终确定和归档变更时使用。 license: MIT compatibility: Requires openspec CLI. metadata: author: openspec version: "1.0" generatedBy: "1.1.1" --- 在实验工作流中归档已完成的变更。 **输入**: 可选择指定变更名称。如果省略,检查是否可以从对话上下文中推断。如果模糊或不明确,你**必须**提示可用的变更。 **步骤** 1. **如果未提供变更名称,提示用户选择** 运行 `openspec list --json` 获取可用的变更。使用 **AskUserQuestion 工具**让用户选择。 仅显示活跃的变更 (尚未归档的)。 如果可用,包含每个变更使用的 schema。 **重要**: 不要猜测或自动选择变更。始终让用户选择。 2. **检查 artifact 完成状态** 运行 `openspec status --change "" --json` 检查 artifact 完成情况。 解析 JSON 以了解: - `schemaName`: 正在使用的工作流 - `artifacts`: artifacts 列表及其状态 (`done` 或其他) **如果任何 artifacts 不是 `done` 状态:** - 显示警告,列出未完成的 artifacts - 使用 **AskUserQuestion 工具**确认用户是否要继续 - 如果用户确认则继续 3. **检查任务完成状态** 读取任务文件 (通常是 `tasks.md`) 检查未完成的任务。 统计标记为 `- [ ]` (未完成) vs `- [x]` (已完成) 的任务。 **如果发现未完成的任务:** - 显示警告,显示未完成任务的数量 - 使用 **AskUserQuestion 工具**确认用户是否要继续 - 如果用户确认则继续 **如果不存在任务文件:** 无任务相关警告地继续。 4. **评估 delta spec 同步状态** 检查 `openspec/changes//specs/` 中的 delta specs。如果不存在,无同步提示地继续。 **如果存在 delta specs:** - 将每个 delta spec 与其对应的主 spec `openspec/specs//spec.md` 比较 - 确定将应用哪些更改 (添加、修改、删除、重命名) - 在提示前显示综合摘要 **提示选项:** - 如果需要更改: "立即同步 (推荐)", "归档但不同步" - 如果已同步: "立即归档", "仍然同步", "取消" 如果用户选择同步,执行 /opsx-sync 逻辑 (使用 openspec-sync-specs 技能)。无论选择什么都继续归档。 5. **执行归档** 如果不存在则创建归档目录: ```bash mkdir -p openspec/changes/archive ``` 使用当前日期生成目标名称: `YYYY-MM-DD-` **检查目标是否已存在:** - 如果是: 失败并显示错误,建议重命名现有归档或使用不同日期 - 如果否: 将变更目录移动到归档 ```bash mv openspec/changes/ openspec/changes/archive/YYYY-MM-DD- ``` 6. **显示摘要** 显示归档完成摘要,包括: - 变更名称 - 使用的 Schema - 归档位置 - 是否同步了 specs (如果适用) - 关于任何警告的注释 (未完成的 artifacts/任务) **成功时的输出** ``` ## 归档完成 **变更:** **Schema:** **归档到:** openspec/changes/archive/YYYY-MM-DD-/ **Specs:** ✓ 已同步到主 specs (或 "无 delta specs" 或 "跳过同步") 所有 artifacts 完成。所有任务完成。 ``` **防护机制** - 如果未提供变更,始终提示选择 - 使用 artifact 图 (openspec status --json) 进行完成度检查 - 不要因警告而阻止归档 - 只需通知并确认 - 移动到归档时保留 .openspec.yaml (它随目录一起移动) - 显示清晰的发生情况摘要 - 如果请求同步,使用 openspec-sync-specs 方法 (代理驱动) - 如果存在 delta specs,在提示前始终运行同步评估并显示综合摘要