feat(ack): refine intake and validation workflow

skills/ack/references/orca-adapter.md

@@ -24,27 +24,39 @@ orca orchestration inbox --limit 20 --json
 ```
 
 确认：Orca runtime 可达并取得本次 `runtimeId`；Coordinator 终端存在；当前没有冲突
-的活跃编排任务。Developer/Test worker 必须通过本次 launcher 新建，不要求预先存在。
+的活跃编排任务。Developer/Test worker 先按下节检查安全复用候选；当前 Orca 无可信
+历史清理能力时必须通过本次 launcher 新建。
 
 ---
 
 ## 既有 worker 的处理
 
-v0.10 **不自动复用任何既有终端**。`receiptHash` 是无密钥 checksum，Orca 当前的
-terminal metadata 也不包含原始 Agent argv、模型或权限 attestation；两者即使完全
-匹配，仍不足以证明旧终端由可信 launcher 以目标 profile 创建。标题、preview、分支
-名或 worker 自报更不能作为证明。
+先找同一轮 ACK 内可复用的空闲 worker，再决定是否创建。候选必须同时满足：
+
+- Orca 明确报告终端存活且空闲；不得复用仍在工作、等待 `worker_done` / 复测报告 /
+  escalation，或运行状态不明的 worker；
+- 没有关联 `blocked`、`failed_retest`、`leftover`、未解决环境事件或其它未完成任务；
+- 角色、profile、worktree、runtime/incarnation 与本次目标完全匹配，Developer 与 Test
+  永不互相复用；
+- 受信后端能够清理历史消息，并返回可核对的新 conversation/session identity 和本次
+  task/attempt 绑定；只有看到成功回执后才把 worker 视为已重置。
+
+`receiptHash` 是无密钥 checksum，标题、preview、分支名、worker 自报或普通 Orca
+terminal metadata 都不能证明历史上下文已清理。任何条件不符、清理接口不存在、清理
+失败或结果无法确认时，都重新 `plan`/`launch` fresh worker。
 
 | 情况 | 动作 |
 |------|------|
-| 历史 receipt 与 live metadata 看似完全匹配 | 只作审计，不自动复用；重新 launch |
-| 没有 receipt，或只有同名终端 | 不复用；重新 launch |
+| 同轮空闲，身份完全匹配，历史消息清理得到可信回执 | 生成新的 task/attempt 绑定后复用 |
+| worker 正在工作、等待回报、状态不明或关联未完成任务 | 不复用；保留原终端并重新 launch |
+| profile、角色、worktree、runtime/incarnation 任一不匹配 | 不复用；重新 launch |
+| 无历史消息清理能力，或无法确认清理成功 | 不复用；重新 launch |
 | 需要并发 worker | 使用下一 `slot` 重新 launch |
 | Developer 升级模型档位 | 选择强档安全 profile，重新 plan/launch |
 
-只有刚刚成功返回的 `launch` 标准输出中的 fresh handle，才可用于紧随其后的本次
-dispatch。未来若 Orca/ACP 增加启动参数 attestation，或 ACK 接入项目外可信签发
-通道，再单独设计自动复用；不能用项目文档声明跳过这条限制。
+当前 Orca terminal API 没有返回新会话身份的可信历史消息清理操作，因此当前适配器
+不会复用 Orca worker；仍只使用刚刚成功返回的 `launch` fresh handle。以后后端补齐
+reset/attestation 后才能启用上述复用路径，不能用项目文档声明跳过条件。
 
 ---
 
@@ -114,8 +126,9 @@ Developer: owns implementation and white-box verification.
 Test: owns independent black-box retest and evidence (verifier != implementer).
 
 Policy:
-- Each issue can be dispatched at most 3 rounds.
-- If still failing after 3 rounds, record as leftover and continue next issue.
+- Each issue can have at most 3 valid product-retest rounds.
+- Environment failures are recorded in dispatch.environmentIncidents, reported with the next action, and do not consume a product-retest round.
+- If still failing after 3 valid product rounds, record as leftover and continue next issue.
 - worker_done and retest reports are not final completion; only Coordinator writes tasks.yaml and knowledge.yaml.
 - Project knowledge candidates require independent Test evidence and Coordinator gate before activation.
 EOF
@@ -274,4 +287,26 @@ orca orchestration send \
 无 `retest_result` 类型时用 `--type worker_done`，靠 subject `retest round <n>`
 区分。收到复测结果后，Coordinator 按 `closed-loop.md` 做终检并回写 `tasks.yaml`；
 通过独立验证和 gate 的跨任务经验再由 Coordinator 写入 `knowledge.yaml`。任务通过
-写 `verified`，不过写 `failed_retest`。
+写 `verified`；观察到产品信号失败写 `failed_retest`；环境无法完成则写
+`dispatch.environmentIncidents`，保持或恢复为 `fixed_by_dev`，不占复验轮次。
+
+---
+
+## 整轮结束时回收 worker
+
+只有 Coordinator 已把本轮最终结论写入 `tasks.yaml` 后才开始回收。先按 receipt 的
+`binding.handle` 聚合任务引用：只有一个 handle 关联的全部任务都为 `verified`，且没有
+未解决环境事件，才允许关闭。`open`、`dispatched`、`fixed_by_dev`、`retesting`、
+`blocked`、`failed_retest`、`leftover` 以及状态不明任务关联的 handle 全部保留，不设置
+TTL。普通用户 Shell 和 Coordinator 自己的终端不在回收范围。
+
+逐个回收时：
+
+1. `orca terminal show --terminal <handle> --json`，把 runtimeId、handle、incarnationId
+   和 worktree 与 receipt 逐项核对；不匹配就停止并报告。
+2. `orca terminal close --terminal <handle> --tab --json`。
+3. 核对关闭回执的 runtimeId、handle、tab 和关闭模式，再确认终端不在 live list。
+4. 关闭结果不确定时保留记录并报告，禁止盲目重试或标记为已回收。
+
+关闭终端不删除 `workerReceipts`、dispatch 证据或测试记录；这些仍是审计事实。保留下来
+的 blocked/failed worker 只在后续任务得到验证或用户明确要求清理时回收。