feat: rename bugfix-ship/requirement-flow to short-ship/long-ship with shared ship records

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.
2026-10-13 23:11:58 +08:00
parent 93341b3c69
commit af6e139d30
47 changed files with 1497 additions and 222 deletions
@@ -1,29 +1,24 @@
-# bugfix-ship
+# bugfix-ship（已弃用）

-把一个已确认的 bug 从根因分析一路推进到配置允许的 PR、合并或生产部署。
+`bugfix-ship` 已改名为 [short-ship](../short-ship/README.md)。本目录只是兼容占位，
+让旧项目里的 `.pouch.yaml`、已经装好的旧软链和旧说法不至于失效；真正的说明和流程都在
+`short-ship/`。

-## 什么时候使用
+## 使用示例

 ```text
-修复动态编辑页重新打开后图片丢失的问题，测完后发 PR。
+使用 bugfix-ship，修复这个线上回归并部署到测试环境。
 ```

-或：
+Agent 命中后会立刻转到 `short-ship`，按同一套规则执行。新请求建议直接用新名。

-```text
-修复这个线上回归，完整验证并部署到生产。
+## 迁移
+
+```bash
+pouch add short-ship          # 新名，当前项目
+pouch add short-ship -g       # 新名，全局
 ```

-## 使用前准备
-
- 能复现的问题描述、截图或日志。
- 项目已配置测试环境和所需 builder/tester/deployer 能力。
- 若要外部发布，明确允许的停止点或使用项目 profile。
-
-## Agent 会做什么
-
-查根因、改代码、补回归测试、执行必要的黑盒/真机验证，并继续完成配置允许的交付阶段。
-
-## 如何判断完成
-
-你会得到根因、修复 commit、测试证据、PR/合并/tag、产物校验和部署状态；不会只收到“本地测试通过”。
+- 旧软链保持有效，不需要先删除。
+- 各项目 `.pouch.yaml` 里的 `bugfix-ship` 可以分批改成 `short-ship`。
+- 确认没有项目再按旧名启用后，删除本目录即可；它是纯占位，删除不丢内容。
@@ -1,50 +1,19 @@
 ---
 name: bugfix-ship
 description: >-
-  处理已复现或有证据的 bug：查根因、修复、补回归测试、验证并按配置继续发 PR、合并、
-  构建、发布和部署。用户说修复、修好、回归、上线 bug 时使用；不处理新需求规划。
+  【已弃用，兼容占位】bugfix-ship 已改名为 short-ship。命中本 skill 时不要在此执行任何
+  流程，直接读取 ../short-ship/SKILL.md 并按其执行。小需求、小改动、修 bug、改文案、
+  加按钮、修复后发 PR 或部署都属于 short-ship。
 ---

-# Bugfix Ship：修复到交付
+# bugfix-ship（已弃用）

-将一次 bug 修复推进到项目配置允许的最终停止点，而不是在本地测试通过后提前结束。
+本 skill 已改名为 [short-ship](../short-ship/SKILL.md)。这里只是兼容占位，**没有流程内容**。

-## 何时使用
-
- 用户报告错误、回归、崩溃、截图缺陷或明确要求修 bug。
- 用户要求修复后继续测试、发 PR、合并、构建、发布或部署。
-
-## 不适用
-
- 尚未定义目标的复杂新需求：交给 `specifier` 和 `requirement-flow`。
- 已有 PR 的合并和发布：交给 `pr-ship`。
- 只做根因分析、不改代码：使用 `hunt`。
-
-## 工作规则
-
-1. 读取项目约束、当前分支/工作树和相关任务；使用 `hunt` 确认根因、复现和验收信号。
-2. 修改代码并补充或更新回归用例；行为、API、图片、UI 改动不得只跑编译。
-3. 使用 `tester` 执行黑盒、浏览器或真机验证；涉及资源加载时检查真实 URL、状态、类型、
-   内容和截图，不把接口返回“有 URL”当作图片可用。
-4. 读取并执行共享 `delivery-loop` 的状态机。停止点由用户选择或项目 delivery profile
-   决定，使用 ACK canonical 状态：`verified`、`validation_ready`、`review_ready` 或 `released`。
-5. 只有达到配置的停止点并拿到证据后才结束；提交、推送、合并、发布和部署不能静默跳过。
-   需要产物时只调用 builder `obtain.sh --sha <merged-or-pushed-commit>`：CI 项目等该
-   SHA 的流水线，失败（无流水线、job 失败、digest 不对）则停止，不要本机 `docker push`。
-   合进默认分支若项目不构建，把预览推到 `dev/*` 或等 releaser 打 tag。
-
-## 安全门
-
- 根因不清、测试缺失、真机不可达、CI/回归失败或工作树有无关改动时停止并说明。
- 不强推、不覆盖他人分支、不绕过 PR 审核，不把测试环境成功当生产成功。
- 数据迁移、破坏性 API、权限/密钥、安全修复和不可逆生产操作需要额外确认。
-
-## 必读资料
-
- 执行交付阶段时读取已安装的 `delivery-loop` skill 及其状态机 reference。
- 测试环境或回归时使用项目的 `tester`、`deployer` 和 `builder` 契约。
- 提交、合并或发布前使用 `check` 与 `releaser` 的规则。
-
-## 完成报告
-
-报告根因、变更、测试/真机证据、停止点、commit、PR/tag、产物摘要、部署状态和任何未完成项。
+- 用户提到 `bugfix-ship`、`/bugfix-ship` 或 `$bugfix-ship` 时：读取
+  [../short-ship/SKILL.md](../short-ship/SKILL.md)，按其内容与授权边界执行，不要在本目录
+  里寻找步骤、references 或 templates。
+- 本目录不保留 `references/` 和 `templates/`，正文只有一份，在 `short-ship/`。
+- 旧项目 `.pouch.yaml` 里仍写 `bugfix-ship` 也能正常安装，软链不会悬空；方便时改成
+  `short-ship`。
+- 确认没有项目再按旧名启用后，可以直接删除本目录。
@@ -1,6 +0,0 @@
-interface:
-  display_name: "Bugfix Ship"
-  short_description: "Carry a bug fix through verification and delivery"
-  default_prompt: "Use $bugfix-ship to fix this bug, verify it, and continue to the configured delivery stop."
-policy:
-  allow_implicit_invocation: true