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/specifier/references/html-prd.md

@@ -28,7 +28,7 @@ HTML 是给人离线评审的交付物，不是运行中的产品页面。它必
 - 颜色和状态不能只依靠颜色表达；为状态提供文字标签。
 - 长表格允许横向滚动，代码或 API 示例使用 `pre`，正文保持可复制。
 - `h1` 只有一个；标题层级连续；链接和表格有可读的焦点/边框状态。
-- 页首显示 feature ID、PRD 版本、状态、生成时间和基于的版本。
+- 页首显示 ship id、PRD 版本、状态、生成时间和基于的版本。
 - 变更内容用文字摘要或 `ins` / `del` 标记表达，不要只用颜色标记。
 
 ## 内容质量
@@ -36,4 +36,4 @@ HTML 是给人离线评审的交付物，不是运行中的产品页面。它必
 - 把“体验好”“性能足够”“支持权限”等不可验证表述改成可观察信号或明确待决策项。
 - 不把实现方案伪装成用户需求；需求、决策和任务分开写。
 - 未知事实写“待确认”，并加入未决问题，不填看似合理的数字、接口或页面。
-- 每条验收都能被 ACK 的 Test 按步骤观察；测试工具不可用时仍能区分产品失败和环境失败。
+- 每条验收都能被 long-ship / Test 按步骤观察；测试工具不可用时仍能区分产品失败和环境失败。

skills/specifier/references/review-loop.md

@@ -9,15 +9,17 @@
 
 ## 状态
 
-`current.yaml` 至少记录：
+ship `current.yaml` 的 spec 字段至少记录：
 
 ```yaml
-featureId: tenant-permissions
-currentRevision: v002
-status: review
-prd: prd-v002.html
-approvedRevision: null
-reviews: review.yaml
+shipId: tenant-permissions
+kind: long
+spec:
+  revision: v002
+  specStatus: review
+  prd: spec/prd-v002.html
+  approvedRevision: null
+  reviews: spec/review.yaml
 ```
 
 允许的状态：
@@ -55,11 +57,11 @@ reviews: review.yaml
 
 ## 每轮评审
 
-1. 读取 `current.yaml`、当前 HTML 和所有未解决的 review 项；不要只读用户最新一句话。
+1. 读取 ship `current.yaml`、当前 HTML 和所有未解决的 review 项；不要只读用户最新一句话。
 2. 将新反馈归类：`change`、`decision`、`question`、`rejected`、`parked`。
 3. 说明每个反馈对范围、架构、任务和验收的影响。
 4. 生成新版本 HTML，保留旧文件。
-5. 更新 `current.yaml` 和 `review.yaml`，并在回复中给出：新版本路径、变更摘要、未决问题、
+5. 更新 ship `current.yaml` 的 spec 字段和 `spec/review.yaml`，并在回复中给出：新版本路径、变更摘要、未决问题、
    是否仍需批准。
 
 如果反馈只影响措辞，也生成新版本；评审记录需要保持可追溯。若用户明确说不采纳，记录理由，
@@ -82,7 +84,8 @@ reviews: review.yaml
 - HTML 版本、状态文件和 review 记录一致。
 
 如果用户说“继续”“可以”“看起来不错”，但没有绑定版本，继续保持 `review`，请用户确认
-具体版本。批准后把 `approvedRevision` 写入 `current.yaml`，再生成 handoff；不要同时启动 ACK。
+具体版本。批准后把 `spec.approvedRevision` 写入 ship `current.yaml`，再生成
+`spec/handoff.yaml`；不要同时启动 long-ship 或 ACK。
 
 ## 批准后的变更
 
@@ -94,5 +97,5 @@ reviews: review.yaml
 4. 标记受影响的任务、验收、风险和 ACK handoff 字段；
 5. 重新等待用户批准。
 
-已经进入 ACK 的任务不会因 HTML 更新而自动改变。需要执行变更时，明确告诉用户应创建新的
-ACK 任务或由 ACK 重新规划，不能静默改写执行记录。
+已经进入 long-ship 的任务不会因 HTML 更新而自动改变。需要执行变更时，明确告诉用户应
+修订本 ship 的 `tasks.yaml` 或重新规划，不能静默改写执行记录。