laily
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.
1.9 KiB
1.9 KiB
name, description
| name | description |
|---|---|
| ship | 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。
创建目录用 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 才能继续交付。