feat(ship): clarify delivery stop semantics

skills/ship/references/manager.md

@@ -51,7 +51,7 @@
 3. 按 JSON 行动：
    - `status: done`：写完成报告，结束。
    - `status: blocked` / `ask_user`：告诉用户缺口或问题，等回复。生产部署（`stopAt:
-     released` 且下一步是 `deploy`）必须再问一次，除非当前这句话已经授权。
+     deployed` 且下一步是 `deploy`）必须再问一次，除非当前这句话已经授权。
    - `actor: manager`：补账本或问用户，再跑 `next_step.py`。
    - `actor: worker`：开新 agent，等待，把结果写入 `manager.lastStep` /
      `manager.lastResult` / `manager.lastSummary`，按 `targetState` / `taskId` 更新账本，立刻

skills/ship/references/record.md

@@ -90,6 +90,20 @@ evidence:
 `delivery.state` 使用 delivery-loop 内部里程碑：`change_ready`、`verified`、
 `pr_opened`、`merged`、`regression_passed`、`artifact_built`、`published`、`deployed`。
 
+用户可见的 canonical `stopAt` 与内部里程碑映射如下：
+
+| stopAt | 停止含义 | 内部里程碑 |
+| --- | --- | --- |
+| `develop_verified` | 开发验证完成：单元测试、新增功能集成测试和静态检查通过；不等于完整回归 | `verified` |
+| `review_ready` | PR/MR 已创建，等待审核 | `pr_opened` |
+| `release_ready` | PR 已合并且完整回归通过；尚未表示发布或部署 | `regression_passed` |
+| `released` | 产物已构建并发布 | `published` |
+| `deployed` | 目标环境实际部署完成并通过健康检查 | `deployed` |
+
+为兼容旧记录，`verified` 是 `develop_verified` 的别名，`validation_ready` 是
+`release_ready` 的别名；新记录应使用 canonical 名称。`delivery.state` 内部里程碑
+名称保持不变。
+
 `source.kind`：`user` | `hunt` | `ack` | `pr` | `feishu`。修 ACK 缺陷时
 `source.kind: ack` 且 `ref` 为缺陷任务 id。
 

skills/ship/references/worker-prompt.md

@@ -21,6 +21,10 @@ scripts/append_evidence.py 追加后跑 scripts/validate_ship.py。
 验收：见 spec.md 与 tasks.yaml 里该任务的 expected / verification。
 授权：<本步允许的 git/PR/部署动作；未写的不要做>
 
+测试边界：`verify` / `verify_task` 只负责开发阶段验证，执行任务相关的单元测试、
+新增功能集成测试和静态检查，不执行合并后的完整 tester 回归；`regress` 只在合并后
+负责完整回归，必须覆盖发现的每个 tester catalog 根和项目声明的原生测试套件。
+
 若步骤是 `verify_task` 或 `regress` 且 skill 是 `tester`：先执行
 `python3 <tester-skill>/scripts/catalog.py roots --root <project-root>`。`verify_task` 按
 任务范围选择相关测试根；`regress` 必须对返回的每个独立测试根分别执行 `validate`、