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/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` 或重新规划，不能静默改写执行记录。