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.
3.1 KiB
3.1 KiB
name, description
| name | description |
|---|---|
| short-ship | 处理范围已清楚的单次变更：小功能、文案、加按钮，或已有证据的 bug。建立 ship 记录、改代码、验证，再按配置发 PR、合并、构建或部署。触发词：short-ship、 小需求、小改动、修 bug、改文案、加按钮。复杂需求用 long-ship；已有 PR 用 pr-ship。 |
Short Ship：单次变更到交付
把一次范围清楚的改动推进到项目配置允许的停止点。
何时使用
- 加按钮、改文案、改短描述、单页小功能，目标与验收已经明确。
- 用户报告错误、回归、崩溃或明确要求修 bug，并且能指出问题。
- 用户要求改完后继续测试、发 PR、合并、构建、发布或部署。
不适用
- 跨模块、要方案取舍、要多任务协作：使用
long-ship和specifier。 - 已有 PR 的合并和发布：使用
pr-ship。 - 只做根因分析、不改代码：使用
hunt。
工作规则
- 读取已安装的
shipskill。没有ship-id就从需求生成候选 slug，用scripts/create_ship.py --kind short建.pouch/ship/<id>/；已有目录则校验后复用。 写spec.md四段：要做什么、不做什么、可观察验收、怎么验。有故障证据时加复现和根因。 任务保持恰好 1 条。功能任务不要写入.pouch/ack/tasks.yaml。 - 有故障证据时使用
hunt确认根因、复现和验收信号。纯小需求跳过 hunt。 - 修改代码并补或更新回归用例；行为、API、图片、UI 改动不得只跑编译。
- 使用
tester做黑盒、浏览器或真机验证；涉及资源加载时检查真实 URL、状态、类型、 内容和截图。跑完立刻用 shipappend_evidence.py --kind testRun追加指针。 - 读取并执行
delivery-loop。停止点由用户或项目 delivery profile 决定，canonical 为verified、validation_ready、review_ready或released。每个完成阶段都要把 对应指针写入该 ship 的current.yaml；缺指针则阶段未完成。需要产物时只调用 builderobtain.sh --sha <merged-or-pushed-commit>。 - 范围涨到需要 PRD 或多条任务时，同一
ship-id把kind改为long，交给long-ship，不要另开 id。
安全门
- 没有 ship-id、spec.md 四段不齐、验收不可观察时停止。
- 根因不清、测试缺失、真机不可达、CI/回归失败或工作树有无关改动时停止并说明。
- 不强推、不覆盖他人分支、不绕过 PR 审核，不把测试环境成功当生产成功。
- 数据迁移、破坏性 API、权限/密钥、安全修复和不可逆生产操作需要额外确认。
必读资料
- 记录格式：已安装的
shipskill 与references/record.md。 - 交付阶段：已安装的
delivery-loop及其状态机 reference。 - 测试、构建、部署、提交前审查：项目的
tester、builder、deployer、check、releaser。
完成报告
报告 ship id、spec 路径、根因（若有）、变更、测试/真机证据指针、停止点、commit、 PR/tag、产物摘要、部署状态和未完成项。