---
name: ship
description: >-
  short-ship、long-ship、pr-ship、specifier 共用的交付记录格式。一次交付一个
  ship-id，目录在 .pouch/ship/{id}/。新建 id 使用 YYYYMMDD-短语，例如
  20261014-dynamic-editor。不单独作为用户入口；用户说 short-ship、
  long-ship、交付记录、ship id 时由对应入口读取本 skill。
---

# Ship：一次交付的记录

这是内部记录契约，不替用户选择 short 或 long，也不执行构建或部署。

## 使用方式

`short-ship` / `long-ship` / `pr-ship` 的主会话只编排：读
[manager.md](references/manager.md)，按 `scripts/next_step.py` 开新 agent；派发时
用 [worker-prompt.md](references/worker-prompt.md)。

创建目录用 `scripts/create_ship.py`，改证据指针用 `scripts/append_evidence.py`，
写回后跑 `scripts/validate_ship.py`。

## 不可违反的规则

- 进入 short-ship / long-ship / pr-ship 的第一件事是拿到或创建 `ship-id`。没有 id
  不得改业务代码、不得跑 tester / obtain / deploy。
- 入口主会话不得加载 hunt / tester / builder / deployer / releaser / check /
  specifier / delivery-loop，也不得亲自执行这些步骤；开不出新 agent 时停止。
- 记录只写 `.pouch/ship/<ship-id>/`。功能、小改动和本次修复的任务不要写入
  `.pouch/ack/tasks.yaml`。ACK 任务板只收缺陷；缺陷要交付时在 ship 的 `source` 里引用。
- `ship-id` 用稳定短 slug：小写字母开头，小写字母、数字、连字符，最长 64。不要用日期、
  随机数或当前分支名冒充业务 id。
- 短长同一套字段。`kind: short` 恰好 1 条 task；`kind: long` 是 DAG，子任务默认不是
  新的 ship。
- tester / builder / deployer 的 SSOT 仍在各自目录。ship 只追加指针。本轮跑过的
  测试、obtain、部署若没写入 `current.yaml` 的 `evidence`，该阶段不算完成。
- 新建 ship 的任务带 `testPlan`，开发 worker 把新增/修改测试写入
  `2-develop/test-manifest.yaml`；verify 按 manifest 的 selector 执行，regress 再叠加
  所有 tester catalog 根和项目原生完整测试。没有测试时必须有明确批准的 `testGap`。
- 项目构建/部署契约仍在 `.pouch/ack/delivery.yaml` 和 builder/deployer 配置里，不要
  复制进每个 ship。
- 旧的 `.pouch/specifier/features/<id>/` 在继续该需求时迁到
  `.pouch/ship/<id>/spec/`，规则见 [record.md](references/record.md)。

## 结果

有效 ship 目录含 `current.yaml`、`spec.md`、`tasks.yaml`、`status.md`；long 另有
`spec/` 下的 PRD 与 handoff。校验通过后入口 skill 才能继续交付。