ship

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Ship a change through team-orchestrated implementation, dual verification, leader-driven fixing, and archival.

Input: Optionally specify a change name (e.g.,

/opsx:ship my-feature

). If omitted, prompt for selection.

Team Structure

Role	Agent Type	Phase	Responsibility
Leader	Main agent (you)	All	Orchestration, OpenSpec verify, direct fix, archive
implementer	general-purpose	1	Task implementation (apply methodology)
reviewer	general-purpose	2, 3	Codex code review (spawned on-demand at Phase 2)

Steps

Select the change
If name provided, use it. Otherwise run
```
openspec list --json
```
and use AskUserQuestion to let the user select.
IMPORTANT: Do NOT guess or auto-select. Always let the user choose if not provided.
Verify prerequisites
bash
```
openspec status --change "<name>" --json
```
Confirm the tasks artifact exists. If tasks don't exist, suggest running
```
/opsx:continue
```
first and stop.
Codex availability check:
bash
```
which codex
```
If
```
codex
```
is not installed, use AskUserQuestion to present options:
1. "Install Codex, then re-run
```
/opsx:ship
```
  " — stop workflow
2. "Proceed without Codex (OpenSpec verify only, skip code review)" — continue with
```
CODEX_AVAILABLE=false
```
3. "Abort" — stop workflow
Store the result as
```
CODEX_AVAILABLE
```
(true/false) for use in later phases.

Create team and spawn implementer

TeamCreate:

```
team_name
```
:
```
ship-<change-name>
```
```
description
```
:
```
Ship change: <change-name>
```

Spawn only the implementer using the Task tool (reviewer is spawned later in Phase 2):

implementer teammate:

```
subagent_type
```
:
```
general-purpose
```
```
team_name
```
:
```
ship-<change-name>
```
```
name
```
:
```
implementer
```
```
mode
```
:
```
bypassPermissions
```
```
run_in_background
```
:
```
true
```

prompt

You are the **implementer** in team "ship-CHANGENAME".

Your job: implement all tasks from OpenSpec change "CHANGENAME".

## How to implement

Read planning artifacts for context:
- openspec/changes/CHANGENAME/proposal.md — intent and scope
- openspec/changes/CHANGENAME/design.md — technical approach
- openspec/changes/CHANGENAME/specs/ — requirements
- openspec/changes/CHANGENAME/tasks.md — implementation checklist

Read project patterns from CLAUDE.md.

For each unchecked task (`- [ ]`) in tasks.md:
1. Understand the task from context
2. Make the code changes required
3. Keep changes minimal and focused
4. Mark task complete: `- [ ]` → `- [x]`
5. Send progress to leader via SendMessage: "Task N/M complete: <description>"

After all tasks complete:
- Send final summary to leader via SendMessage listing all completed tasks

## Workflow

1. Check TaskList for assigned tasks
2. When you have an implement task, run the implementation
3. Send progress updates to leader via SendMessage
4. Mark TaskList task completed via TaskUpdate
5. Check TaskList for next work

IMPORTANT: Follow project patterns from CLAUDE.md.
IMPORTANT: Always communicate progress to the leader via SendMessage.
IMPORTANT: If a task is unclear or blocked, report to leader instead of guessing.

Replace

CHANGENAME

in the prompt with the actual change name before spawning.

Phase 1: Implement
- TaskCreate: subject "Implement all tasks for <change-name>"
- TaskUpdate: assign owner to
```
implementer
```
- SendMessage to
```
implementer
```
  : "Implement all tasks for change <change-name>. Read artifacts, implement each task, mark checkboxes, and send me progress updates."
Wait for implementer to complete. The implementer will send progress messages and a final summary.

Error handling: If implementer fails or crashes:
- Read
```
openspec/changes/<name>/tasks.md
```
  to assess partial progress
- Report to user: "Implementer failed. N/M tasks completed. Remaining: [list]"
- Use AskUserQuestion: "Continue with leader implementing remaining tasks?" / "Abort and retry later"
- If user chooses to continue, leader implements remaining tasks directly
After implementer reports completion:
- Read tasks.md to verify all checkboxes are checked
- If incomplete tasks remain, send implementer back to finish them
- Report progress to user: "Phase 1 complete: N/N tasks implemented"
Shutdown implementer immediately after Phase 1:
- SendMessage type
```
shutdown_request
```
  to
```
implementer
```
- Do not wait — proceed to Phase 2 while shutdown processes

Phase 2: Dual Verify

a. Spawn and start reviewer (background, if CODEX_AVAILABLE)

Only if

CODEX_AVAILABLE=true

Spawn reviewer teammate using the Task tool:

```
subagent_type
```
:
```
general-purpose
```
```
team_name
```
:
```
ship-<change-name>
```
```
name
```
:
```
reviewer
```
```
mode
```
:
```
bypassPermissions
```
```
run_in_background
```
:
```
true
```

prompt

You are the **reviewer** in team "ship-CHANGENAME".

Your job: run Codex code review against the implementation for change "CHANGENAME".

## How to review

When you receive a review task:

1. Read the review prompt template: .codex/prompts/code-review.md
2. Identify files changed for this change by reading:
   - openspec/changes/CHANGENAME/tasks.md (completed tasks reference files)
   - openspec/changes/CHANGENAME/design.md (affected files listed)
3. Run Codex review:

   ```bash
   codex exec \
     --dangerously-bypass-approvals-and-sandbox \
     -m gpt-5.3-codex \
     "Review the code changes for OpenSpec change CHANGENAME. Follow the review methodology in .codex/prompts/code-review.md. Read the change artifacts at openspec/changes/CHANGENAME/ for context. Write the full review report."

Parse the Codex output and write structured review to: openspec/changes/CHANGENAME/review-report.md
Send summary to leader via SendMessage: Include CRITICAL/WARNING/SUGGESTION counts and overall assessment.
Mark task completed via TaskUpdate
Check TaskList for next work

Output Format

Write review to: openspec/changes/CHANGENAME/review-report.md

# Code Review: CHANGENAME

## Summary
| Dimension       | Finding Count | Max Severity |
|-----------------|---------------|--------------|
| Security        | N             | ...          |
| Performance     | N             | ...          |
| Correctness     | N             | ...          |
| Maintainability | N             | ...          |

## CRITICAL
- [finding] — `file.ts:line` — Recommendation: ...

## WARNING
- [finding] — `file.ts:line` — Recommendation: ...

## SUGGESTION
- [finding] — `file.ts:line` — Recommendation: ...

## Assessment
[Summary of overall code quality and readiness]

IMPORTANT: Only review, do NOT modify code. IMPORTANT: Always communicate results to the leader via SendMessage.

undefined

Replace

CHANGENAME

in the prompt with the actual change name before spawning.

Then:

TaskCreate: subject "Code review for <change-name>"
TaskUpdate: assign owner to
```
reviewer
```
SendMessage to
```
reviewer
```
: "Run Codex code review for change <change-name>. Write review-report.md and send me the summary."

b. Leader runs OpenSpec verify (foreground)

Follow the verification methodology from

.claude/commands/opsx/verify.md

(steps 2-8):

Read all change artifacts
Verify Completeness (task + spec coverage)
Verify Correctness (requirement implementation, scenario coverage)
Verify Coherence (design adherence, pattern consistency)

Write report to

openspec/changes/<name>/verify-report.md

c. Collect and merge results into combined-report.md

If CODEX_AVAILABLE and reviewer completed successfully:

Read both verify-report.md and review-report.md
Merge into
```
openspec/changes/<name>/combined-report.md
```
:
- Deduplicate issues appearing in both reports
- Combine all unique CRITICAL/WARNING/SUGGESTION issues

If reviewer failed or CODEX_AVAILABLE=false:

Copy verify-report.md content to

openspec/changes/<name>/combined-report.md

If reviewer failed, report to user: "Codex review failed. Proceeding with OpenSpec verify results only."

Report to user: "Dual verify complete. CRITICAL: N | WARNING: N | SUGGESTION: N"

If 0 CRITICAL + 0 WARNING + 0 SUGGESTION → skip to step 8 (archive) If issues found → proceed to step 6 (fix loop)

Phase 3: Fix Loop (max 3 iterations)

For iteration N = 1, 2, 3:

a. Leader directly fixes issues
- Read
```
openspec/changes/<name>/combined-report.md
```
  (always use combined-report as single source of truth)
- Read change artifacts for context (
```
design.md
```
  ,
```
specs/
```
  ,
```
tasks.md
```
  )
- For each CRITICAL, WARNING, and SUGGESTION issue:
  1. Read the referenced source file at the specified
```
file:line
```
  2. Understand the issue in context of change requirements
  3. Apply the minimal, scoped fix
- Keep changes strictly scoped to reported issues — no refactoring or improvements beyond the fix
- If a design decision in
```
design.md
```
  conflicts with code, update the code to match design
- Write fix summary to
```
openspec/changes/<name>/fix-summary.md
```
  :
```
# Fix Summary: <change-name> (Round N)

## Fixes Applied
### CRITICAL
- [issue] → Fixed in `file.ts:line` — [what changed]
### WARNING
- [issue] → Fixed in `file.ts:line` — [what changed]
### SUGGESTION
- [issue] → Fixed in `file.ts:line` — [what changed]

## Could Not Fix
- [issue] — Reason: [explanation]
```
b. Re-verify and update combined-report.md

Round 1 (leader-only, fast check):
- Leader runs OpenSpec verify (steps from verify.md)
- Update verify-report.md
- Copy verify-report.md to combined-report.md
Round 2+ (smart escalation):
- If previous round's combined-report.md still has CRITICAL or WARNING issues AND
```
CODEX_AVAILABLE=true
```
  :
  - Leader runs OpenSpec verify + Send reviewer to run Codex review again (dual verify)
  - Merge into combined-report.md
- Otherwise (only SUGGESTION issues remaining, or CODEX_AVAILABLE=false):
  - Leader-only verify
  - Copy verify-report.md to combined-report.md
c. Check results
- If 0 issues in combined-report.md → go to step 8 (archive)
- If N < 3 and issues remain → continue loop (N + 1)
- If N = 3 and issues remain → go to step 7
Report each round: "Fix Round N complete. CRITICAL: N | WARNING: N | SUGGESTION: N"

Max iterations exceeded

Display to user:

## Ship Paused: <change-name>

3 fix rounds completed, issues remain.

**Remaining Issues:**
[paste CRITICAL/WARNING/SUGGESTION from latest combined-report.md]

**Options:**
1. Fix manually, then re-run `/opsx:ship`
2. Archive with warnings: `/opsx:archive <change-name>`
3. Review full report: openspec/changes/<name>/combined-report.md

Proceed to step 9 (cleanup).

Phase 4: Archive

Execute the

/opsx:archive

logic (follow

.claude/commands/opsx/archive.md

Check artifact completion status
Assess delta spec sync state (prompt user for sync choice)
Move change to archive directory
Display ship completion summary:

## Ship Complete: <change-name>

**Verification:** All checks passed
**Fix Rounds:** N/3 used
**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
**Specs:** ✓ Synced / No delta specs / Sync skipped

Phase 5: Cleanup
- If
```
reviewer
```
  is still running: SendMessage type
```
shutdown_request
```
  to
```
reviewer
```
- Wait for shutdown confirmation (timeout: if no response after 30 seconds, proceed)
- If shutdown_request fails or times out: log warning and proceed
- TeamDelete to clean up team resources
IMPORTANT: Always run cleanup, even if ship was paused or failed.

Progress Reporting

Report progress to user at each phase:

undefined

通过团队编排的实现、双重验证、负责人主导的修复和归档流程来交付一项变更。

输入：可选择指定变更名称（例如：

/opsx:ship my-feature

）。如果省略，将提示用户进行选择。

团队结构

角色	Agent类型	阶段	职责
负责人	主Agent（即你）	所有阶段	流程编排、OpenSpec验证、直接修复、归档
实现人员	通用型	1	任务实现（遵循方法论）
评审人员	通用型	2、3	Codex代码评审（在第2阶段按需启动）

步骤

选择变更
如果已提供名称，则使用该名称。否则运行
```
openspec list --json
```
，并通过AskUserQuestion让用户进行选择。
重要提示：请勿猜测或自动选择。如果未提供名称，务必让用户选择。
验证前置条件
bash
```
openspec status --change "<name>" --json
```
确认任务工件存在。如果任务不存在，建议先运行
```
/opsx:continue
```
然后终止流程。
Codex可用性检查：
bash
```
which codex
```
如果未安装
```
codex
```
，使用AskUserQuestion提供以下选项：
1. "安装Codex，然后重新运行
```
/opsx:ship
```
  " — 终止工作流
2. "不使用Codex继续（仅进行OpenSpec验证，跳过代码评审）" — 设置
```
CODEX_AVAILABLE=false
```
  后继续
3. "中止" — 终止工作流
将结果存储为
```
CODEX_AVAILABLE
```
（true/false），供后续阶段使用。

创建团队并启动实现人员Agent

TeamCreate:

```
team_name
```
:
```
ship-<change-name>
```
```
description
```
:
```
Ship change: <change-name>
```

使用Task工具仅启动实现人员Agent（评审人员将在第2阶段后期启动）：

实现人员成员：

```
subagent_type
```
:
```
general-purpose
```
```
team_name
```
:
```
ship-<change-name>
```
```
name
```
:
```
implementer
```
```
mode
```
:
```
bypassPermissions
```
```
run_in_background
```
:
```
true
```

prompt

你是团队"ship-CHANGENAME"中的**实现人员**。

你的工作：完成OpenSpec变更"CHANGENAME"的所有任务。

## 实现方式

阅读规划工件以了解上下文：
- openspec/changes/CHANGENAME/proposal.md — 目标与范围
- openspec/changes/CHANGENAME/design.md — 技术方案
- openspec/changes/CHANGENAME/specs/ — 需求说明
- openspec/changes/CHANGENAME/tasks.md — 实现检查清单

阅读CLAUDE.md中的项目模式。

针对tasks.md中每个未勾选的任务（`- [ ]`）：
1. 根据上下文理解任务内容
2. 完成所需的代码变更
3. 保持变更最小且聚焦
4. 标记任务完成：`- [ ]` → `- [x]`
5. 通过SendMessage向负责人发送进度："任务N/M完成：<描述>"

所有任务完成后：
- 通过SendMessage向负责人发送最终摘要，列出所有已完成的任务

## 工作流

1. 检查TaskList中的已分配任务
2. 当你有实现任务时，执行实现工作
3. 通过SendMessage向负责人发送进度更新
4. 通过TaskUpdate标记TaskList中的任务为已完成
5. 检查TaskList中的下一项工作

重要提示：遵循CLAUDE.md中的项目模式。
重要提示：务必通过SendMessage向负责人沟通进度。
重要提示：如果任务不明确或受阻，请向负责人报告，不要自行猜测。

在启动前将提示中的

CHANGENAME

替换为实际的变更名称。

阶段1：实现
- TaskCreate：主题"为<change-name>实现所有任务"
- TaskUpdate：将负责人分配给
```
implementer
```
- 向
```
implementer
```
  发送SendMessage："为变更<change-name>实现所有任务。阅读工件内容，完成每个任务，勾选复选框，并向我发送进度更新。"
等待实现人员完成。实现人员将发送进度消息和最终摘要。

错误处理：如果实现人员失败或崩溃：
- 读取
```
openspec/changes/<name>/tasks.md
```
  评估部分完成的进度
- 向用户报告："实现人员执行失败。已完成N/M个任务。剩余任务：[列表]"
- 使用AskUserQuestion："由负责人继续完成剩余任务？" / "中止并稍后重试"
- 如果用户选择继续，负责人直接完成剩余任务
实现人员报告完成后：
- 读取tasks.md以验证所有复选框已勾选
- 如果仍有未完成的任务，让实现人员返回完成
- 向用户报告进度："阶段1完成：已实现N/N个任务"
阶段1完成后立即关闭实现人员：
- 向
```
implementer
```
  发送类型为
```
shutdown_request
```
  的SendMessage
- 无需等待，在关闭过程中直接进入阶段2
阶段2：双重验证

a. 启动评审人员（后台运行，如果CODEX_AVAILABLE为true）
仅当
```
CODEX_AVAILABLE=true
```
时：
使用Task工具启动评审人员成员：
- ```
subagent_type
```
  :
```
general-purpose
```
- ```
team_name
```
  :
```
ship-<change-name>
```
- ```
name
```
  :
```
reviewer
```
- ```
mode
```
  :
```
bypassPermissions
```
- ```
run_in_background
```
  :
```
true
```
- ```
prompt
```
  :
```
你是团队"ship-CHANGENAME"中的**评审人员**。

你的工作：针对变更"CHANGENAME"的实现结果运行Codex代码评审。

## 评审方式

当你收到评审任务时：

1. 读取评审提示模板：.codex/prompts/code-review.md
2. 通过以下文件识别此变更涉及的修改文件：
   - openspec/changes/CHANGENAME/tasks.md（已完成任务会引用文件）
   - openspec/changes/CHANGENAME/design.md（列出了受影响的文件）
3. 运行Codex评审：

   ```bash
     codex exec \
       --dangerously-bypass-approvals-and-sandbox \
       -m gpt-5.3-codex \
       "Review the code changes for OpenSpec change CHANGENAME. Follow the review methodology in .codex/prompts/code-review.md. Read the change artifacts at openspec/changes/CHANGENAME/ for context. Write the full review report."
```
1. 解析Codex的输出，并将结构化评审结果写入： openspec/changes/CHANGENAME/review-report.md
2. 通过SendMessage向负责人发送摘要：包含CRITICAL/WARNING/SUGGESTION的数量和整体评估。
3. 通过TaskUpdate标记任务为已完成
4. 检查TaskList中的下一项工作
输出格式

将评审结果写入：openspec/changes/CHANGENAME/review-report.md
```
  # Code Review: CHANGENAME
  
  ## Summary
  | Dimension       | Finding Count | Max Severity |
  |-----------------|---------------|--------------|
  | Security        | N             | ...          |
  | Performance     | N             | ...          |
  | Correctness     | N             | ...          |
  | Maintainability | N             | ...          |
  
  ## CRITICAL
  - [finding] — `file.ts:line` — Recommendation: ...
  
  ## WARNING
  - [finding] — `file.ts:line` — Recommendation: ...
  
  ## SUGGESTION
  - [finding] — `file.ts:line` — Recommendation: ...
  
  ## Assessment
  [Summary of overall code quality and readiness]
```
重要提示：仅进行评审，不要修改代码。重要提示：务必通过SendMessage向负责人沟通结果。
```
  undefined
```
在启动前将提示中的
```
CHANGENAME
```
替换为实际的变更名称。
然后：
- TaskCreate：主题"为<change-name>进行代码评审"
- TaskUpdate：将负责人分配给
```
reviewer
```
- 向
```
reviewer
```
  发送SendMessage："为变更<change-name>运行Codex代码评审。写入review-report.md并向我发送摘要。"
b. 负责人运行OpenSpec验证（前台）
遵循
```
.claude/commands/opsx/verify.md
```
中的验证方法论（步骤2-8）：
- 读取所有变更工件
- 验证完整性（任务+需求覆盖）
- 验证正确性（需求实现、场景覆盖）
- 验证一致性（遵循设计、模式统一）
- 将报告写入
```
openspec/changes/<name>/verify-report.md
```
c. 收集并合并结果到combined-report.md

如果CODEX_AVAILABLE为true且评审人员成功完成：
- 读取verify-report.md和review-report.md
- 合并到
```
openspec/changes/<name>/combined-report.md
```
  ：
  - 去除两个报告中重复的问题
  - 合并所有唯一的CRITICAL/WARNING/SUGGESTION问题
如果评审人员失败或CODEX_AVAILABLE为false：
- 将verify-report.md的内容复制到
```
openspec/changes/<name>/combined-report.md
```
- 如果评审人员失败，向用户报告："Codex评审失败。仅基于OpenSpec验证结果继续。"
向用户报告："双重验证完成。CRITICAL：N | WARNING：N | SUGGESTION：N"

如果0个CRITICAL + 0个WARNING + 0个SUGGESTION → 跳转到步骤8（归档） 如果发现问题 → 进入步骤6（修复循环）
阶段3：修复循环（最多3次迭代）

对于迭代N = 1、2、3：

a. 负责人直接修复问题
- 读取
```
openspec/changes/<name>/combined-report.md
```
  （始终以combined-report为唯一事实来源）
- 读取变更工件以了解上下文（
```
design.md
```
  、
```
specs/
```
  、
```
tasks.md
```
  ）
- 针对每个CRITICAL、WARNING和SUGGESTION问题：
  1. 读取指定
```
file:line
```
    的源文件
  2. 根据变更需求理解问题内容
  3. 应用最小化、针对性的修复
- 严格将变更范围限定在报告的问题内 — 不要进行重构或超出修复范围的改进
- 如果
```
design.md
```
  中的设计决策与代码冲突，更新代码以匹配设计
- 将修复摘要写入
```
openspec/changes/<name>/fix-summary.md
```
  ：
```
# 修复摘要：<change-name>（第N轮）

## 已应用的修复
### CRITICAL
- [问题] → 修复于`file.ts:line` — [变更内容]
### WARNING
- [问题] → 修复于`file.ts:line` — [变更内容]
### SUGGESTION
- [问题] → 修复于`file.ts:line` — [变更内容]

## 无法修复的问题
- [问题] — 原因：[说明]
```
b. 重新验证并更新combined-report.md

第1轮（仅负责人，快速检查）：
- 负责人运行OpenSpec验证（遵循verify.md中的步骤）
- 更新verify-report.md
- 将verify-report.md复制到combined-report.md
第2+轮（智能升级）：
- 如果上一轮的combined-report.md仍有CRITICAL或WARNING问题且
```
CODEX_AVAILABLE=true
```
  ：
  - 负责人运行OpenSpec验证 + 让评审人员再次运行Codex评审（双重验证）
  - 合并结果到combined-report.md
- 否则（仅剩余SUGGESTION问题，或CODEX_AVAILABLE为false）：
  - 仅由负责人进行验证
  - 将verify-report.md复制到combined-report.md
c. 检查结果
- 如果combined-report.md中无问题 → 进入步骤8（归档）
- 如果N < 3且仍有问题 → 继续循环（N + 1）
- 如果N = 3且仍有问题 → 进入步骤7
每一轮都向用户报告："修复第N轮完成。CRITICAL：N | WARNING：N | SUGGESTION：N"

超出最大迭代次数

向用户显示：

## 交付暂停：<change-name>

已完成3轮修复，仍有问题存在。

**剩余问题：**
[粘贴最新combined-report.md中的CRITICAL/WARNING/SUGGESTION内容]

**选项：**
1. 手动修复，然后重新运行`/opsx:ship`
2. 带警告归档：`/opsx:archive <change-name>`
3. 查看完整报告：openspec/changes/<name>/combined-report.md

进入步骤9（清理）。

阶段4：归档

执行

/opsx:archive

逻辑（遵循

.claude/commands/opsx/archive.md

）：

检查工件完成状态
评估增量需求同步状态（提示用户选择同步方式）
将变更移动到归档目录
显示交付完成摘要：

## 交付完成：<change-name>

**验证：** 所有检查通过
**修复轮次：** 使用了N/3次
**归档至：** openspec/changes/archive/YYYY-MM-DD-<name>/
**需求：** ✓ 已同步 / 无增量需求 / 跳过同步

阶段5：清理
- 如果
```
reviewer
```
  仍在运行：向
```
reviewer
```
  发送类型为
```
shutdown_request
```
  的SendMessage
- 等待关闭确认（超时：如果30秒后无响应，继续执行）
- 如果shutdown_request失败或超时：记录警告并继续
- 执行TeamDelete以清理团队资源
重要提示：无论交付是否暂停或失败，始终执行清理步骤。

进度报告

在每个阶段向用户报告进度：

undefined

Shipping: <change-name>

交付中：<change-name>

✓ Team created: ship-<change-name> ✓ Implementer spawned

── Phase 1: Implement ── ⏳ Implementing tasks... ✓ Task 1/N: <description> ✓ Task 2/N: <description> ✓ All tasks implemented ✓ Implementer shutdown

── Phase 2: Dual Verify ── ⏳ Spawning reviewer... ⏳ OpenSpec verify + Codex review in progress... CRITICAL: 1 | WARNING: 2 | SUGGESTION: 1

── Phase 3: Fix Loop ── ⏳ Fix Round 1/3... ✓ Fix applied ⏳ Re-verifying... ✓ All checks passed!

── Phase 4: Archive ── ✓ Specs synced ✓ Archived to openspec/changes/archive/YYYY-MM-DD-<name>/

── Phase 5: Cleanup ── ✓ Team shutdown complete

Ship complete!


**Guardrails**

- Always prompt for change selection if not provided
- Max 3 fix iterations — hard limit to prevent infinite loops
- Implementer implements, reviewer reviews, leader orchestrates — separation of concerns
- Leader does OpenSpec verify and fixes issues directly (not delegated to teammates)
- Implementer is shut down after Phase 1 to free resources
- Reviewer is spawned on-demand at Phase 2 (not at team creation)
- Codex availability is checked upfront; workflow adapts if unavailable
- Agent failures trigger user-facing options instead of silent failure
- combined-report.md is the single source of truth for fix loop (never reference verify-report.md or review-report.md directly in fix loop)
- Always run cleanup (step 9), even on failure or pause
- All working files preserved in change directory (verify-report.md, review-report.md, combined-report.md, fix-summary.md)
- The reviewer follows `.codex/prompts/code-review.md` for review methodology
- The leader reads `.codex/prompts/verify-fix-loop.md` for fix constraints reference
- The implementer follows apply methodology from `.claude/commands/opsx/apply.md`

✓ 团队已创建：ship-<change-name> ✓ 实现人员已启动

── 阶段1：实现 ── ⏳ 正在执行任务... ✓ 任务1/N：<描述> ✓ 任务2/N：<描述> ✓ 所有任务已完成 ✓ 实现人员已关闭

── 阶段2：双重验证 ── ⏳ 正在启动评审人员... ⏳ OpenSpec验证 + Codex评审进行中... CRITICAL: 1 | WARNING: 2 | SUGGESTION: 1

── 阶段3：修复循环 ── ⏳ 修复第1/3轮... ✓ 已应用修复 ⏳ 正在重新验证... ✓ 所有检查通过！

── 阶段4：归档 ── ✓ 需求已同步 ✓ 已归档至openspec/changes/archive/YYYY-MM-DD-<name>/

── 阶段5：清理 ── ✓ 团队已完成关闭

交付完成！