feat(ack): refine intake and validation workflow

skills/ack/references/model-routing.md

@@ -57,9 +57,8 @@ Coordinator 用强模型但**不亲自跑测试**（测试由 Test 承担），
 - 低档位反复产出表面修复。
 
 升级由 Coordinator 判断并记录原因。升级不是修改一个正在运行的终端：必须选择
-对应强档 profile，重新计算 `profileHash`，再通过 launcher 创建新的 worker。
-v0.10 不自动复用持久化 receipt 指向的旧终端，Test 也不得使用 Developer 的强档
-worker。
+对应强档 profile，重新计算 `profileHash`，再通过 launcher 创建新的 worker。模型或
+profile 升级时不得复用旧 worker，Test 也不得使用 Developer 的强档 worker。
 
 ---
 
@@ -211,10 +210,13 @@ receipt 至少把以下事实绑定在一起：
 
 `receiptHash` 是无密钥的规范 JSON checksum，只能发现意外漂移或未同步修改，**不是
 launcher 身份证明，也不是复用授权**。项目内有写权限的一方可以修改 receipt 后重算
-hash；而当前 Orca metadata 又不能证明终端最初执行的命令、模型和权限。因此 v0.10
-明确禁止根据持久化 receipt 自动复用既有终端：每次需要自动派发 worker，都重新走
-`plan` → 带 expected fingerprint 的 `launch`，只使用该次 launcher 标准输出中的
-fresh handle 完成本次派发。
+hash；而当前 Orca metadata 又不能证明终端最初执行的命令、模型和权限。因此 ACK
+明确禁止根据持久化 receipt 自动复用既有终端。复用只允许发生在同一轮 ACK 内，并且
+必须先证明 worker 空闲、角色/profile/worktree/runtime/incarnation 完全匹配，再由
+受信后端清理历史消息并返回新的 conversation/session identity 与本次 task/attempt
+绑定。正在工作、等待回报、状态不明或关联未完成任务的 worker 都不是空闲候选。任一
+条件不满足、清理失败或清理结果无法确认时，重新走 `plan` → 带 expected fingerprint
+的 `launch`，使用 fresh handle 派发。
 
 `launchFingerprint` 是确定性的完整计划漂移校验，不是一次性授权或幂等键。同一份
 计划重复执行 `launch` 会创建新的 fresh terminal；成功后不得用同一 fingerprint
@@ -223,9 +225,10 @@ fresh handle 完成本次派发。
 提供，而不是把 checksum 冒充成一次性令牌。
 
 持久化 receipt 仍用于审计、dispatch 关联和检测配置漂移；标题、preview、分支名、
-worker 自报或单独的 Orca live metadata 都不能把旧终端提升为可信 worker。未来只有
-在 Orca/ACP 提供启动参数 attestation，或存在项目外可信签发与校验通道后，才开放
-自动复用。CLI / 模型变更仍需更新 allowlist 并重新生成 receipt。
+worker 自报或单独的 Orca live metadata 都不能把旧终端提升为可信 worker。只有
+Orca/ACP 同时提供启动参数 attestation、明确空闲状态、可信历史清理和新会话身份，或
+ACK 接入等价的项目外可信签发与校验通道，才实际启用自动复用。当前 Orca 不满足这些
+条件，所以仍创建 fresh worker。CLI / 模型变更仍需更新 allowlist 并重新生成 receipt。
 
 `ackVersion` 必须使用合法 SemVer。`0.10.0` 及以后版本的任务板必须同时存在
 `project.orchestration` 与顶层 `workerReceipts`；其中任一字段出现，另一个也必须