af6e139d30
short-ship and long-ship share one ship-id record under .pouch/ship/<id>/. specifier writes PRDs into spec/; delivery-loop appends evidence pointers. Old names stay as deprecation stubs so existing installs keep working.
40 lines
1.9 KiB
Markdown
40 lines
1.9 KiB
Markdown
---
|
||
name: ship
|
||
description: >-
|
||
short-ship、long-ship、pr-ship、specifier 共用的交付记录格式。一次交付一个
|
||
ship-id,目录在 .pouch/ship/<id>/。不单独作为用户入口;用户说 short-ship、
|
||
long-ship、交付记录、ship id 时由对应入口读取本 skill。
|
||
---
|
||
|
||
# Ship:一次交付的记录
|
||
|
||
这是内部记录契约,不替用户选择 short 或 long,也不执行构建或部署。
|
||
|
||
## 使用方式
|
||
|
||
入口 skill 在拿到或创建 `ship-id` 之后读取 [record.md](references/record.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。
|
||
- 记录只写 `.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`,该阶段不算完成。
|
||
- 项目构建/部署契约仍在 `.pouch/ack/delivery.yaml` 和 builder/deployer 配置里,不要
|
||
复制进每个 ship。
|
||
- 旧的 `.pouch/specifier/features/<id>/` 在继续该需求时迁到
|
||
`.pouch/ship/<id>/spec/`,规则见 record.md。
|
||
|
||
## 结果
|
||
|
||
有效 ship 目录含 `current.yaml`、`spec.md`、`tasks.yaml`、`status.md`;long 另有
|
||
`spec/` 下的 PRD 与 handoff。校验通过后入口 skill 才能继续交付。
|