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.
2.5 KiB
2.5 KiB
name, description
| name | description |
|---|---|
| pr-ship | 处理已有 PR/MR：检查差异、审核和 CI，必要时修复阻塞项，合并后以合并 commit 做完整回归， 再按配置构建、发布和部署。用户说处理、合并、回归或发布 PR 时使用。 |
PR Ship：合并后的完整交付
重点是合并后的真实状态：PR 分支通过不代表目标分支已回归，也不代表产物和生产已更新。
何时使用
- 用户提供 PR/MR 或要求处理当前 PR。
- 用户要求合并 PR 后完整回归并部署。
不适用
- 没有 PR、需要从零做小改动或修 bug：使用
short-ship。 - 复杂需求尚未形成批准 PRD：使用
specifier和long-ship。 - 只做 diff 审查、不合并：使用
check。
工作规则
- 读取已安装的
shipskill。从 PR 正文、分支名或用户给出的 id 绑定已有 ship；没有则 用 PR 标题生成 slug，创建kind: short的薄记录，source.kind: pr。之后证据都写进 这个 ship id。 - 读取 PR 的目标/源分支、差异、关联任务、审核状态、CI、冲突和变更风险；使用
check。 - 审核、CI 或必需检查缺失时停止。若发现可修复问题，只有当前请求明确包含修复时才在 PR 分支上处理， 然后重新验证；不能静默改变 PR 范围。
- 具备合并条件后执行合并，并重新获取目标分支；记录合并后的 commit，后续所有回归和构建都以它为来源。
- 读取并执行
delivery-loop的状态机，运行完整回归；失败时停在合并后的中间状态或回到修复流程，不部署失败版本。 每个完成阶段把指针写入该 ship 的current.yaml。 - 只有项目 profile 和当前授权允许时才构建、发布和部署；生产部署完成后做节点状态和关键路径检查。
安全门
- 不绕过审核、CI、分支保护或冲突；不强推、不重写已共享历史。
- 不用 PR 源分支的旧 APK/镜像证明合并版本已发布。
- 目标分支变化、合并后代码漂移、回归失败、产物来源不明或部署健康检查失败时停止。
必读资料
- 记录格式：已安装的
shipskill 与references/record.md。 - 执行交付阶段时读取已安装的
delivery-loopskill 及其状态机 reference。 - 发布版本时遵循
releaser；构建/部署/回归分别遵循builder、deployer、tester。
完成报告
报告 ship id、PR/MR、审核/CI 结果、合并 commit、完整回归证据、产物摘要、tag、部署目标、健康检查和回滚点。