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.

skills/requirement-flow/README.md

@@ -1,23 +1,24 @@
-# requirement-flow
+# requirement-flow（已弃用）
 
-把复杂需求从 PRD 评审、任务拆分、协作开发一路推进到集成回归和配置允许的发布部署。
+`requirement-flow` 已改名为 [long-ship](../long-ship/README.md)。本目录只是兼容占位，
+让旧项目里的 `.pouch.yaml`、已经装好的旧软链和旧说法不至于失效；真正的说明和流程都在
+`long-ship/`。
 
-## 什么时候使用
+## 使用示例
 
 ```text
-把动态编辑需求做成 PRD，批准后拆任务开发，最后完整回归并部署测试环境。
+使用 requirement-flow，把动态编辑需求做成 PRD，批准后拆任务开发。
 ```
 
-## 使用前准备
+Agent 命中后会立刻转到 `long-ship`，按同一套规则执行。新请求建议直接用新名。
 
-- 需求目标和相关项目上下文。
-- 用户愿意评审并明确批准某个 PRD 版本。
-- 项目已配置 ACK、测试环境和需要的构建/部署能力。
+## 迁移
 
-## Agent 会做什么
+```bash
+pouch add long-ship          # 新名，当前项目
+pouch add long-ship -g       # 新名，全局
+```
 
-先生成可评审 PRD；批准后建立有依赖的任务 DAG，独立验证子任务，最后以集成结果推进交付。
-
-## 如何判断完成
-
-你会得到 PRD 版本、任务与依赖、各任务验证、集成回归、最终 PR/合并、产物和部署证据。
+- 旧软链保持有效，不需要先删除。
+- 各项目 `.pouch.yaml` 里的 `requirement-flow` 可以分批改成 `long-ship`。
+- 确认没有项目再按旧名启用后，删除本目录即可；它是纯占位，删除不丢内容。