feat(ack): refine intake and validation workflow

skills/ack/references/closed-loop.md

@@ -36,24 +36,27 @@ Coordinator 发现或读取 open 任务
   -> 决定 worktree：当前 worktree 起子 agent，还是新建隔离 worktree（见下节「子任务放哪」）
   -> 解析安全 profile：机器配置只读 tasks.yaml.project.orchestration
   -> 运行 launcher plan 并审阅 launchFingerprint
-  -> 带 expected fingerprint 启动 fresh worker，把 receipt 写回 tasks.yaml（见 orca-adapter.md）
+  -> 检查同轮空闲 worker；可信清理历史消息成功才复用，否则带 expected fingerprint 启动 fresh worker
+  -> 把本次 task/attempt receipt 写回 tasks.yaml（见 orca-adapter.md）
   -> dispatch 给 Developer（--to <worker handle>）
   -> wait：Developer 的 worker_done / escalation（含 knowledgeApplied / knowledgeCandidates）
   -> writeback fixed_by_dev
-  -> 为 Test 独立解析安全 profile，重新 plan/launch fresh worker 并写回 receipt
+  -> 为 Test 独立解析安全 profile；安全重置同角色空闲 worker，或重新 plan/launch fresh worker
   -> dispatch 给 Test（retesting）
   -> wait：Test 的 retest_result（含 knowledgeChecks 和 candidate 独立证据）
   -> Test 通过：gate（Coordinator 读证据对齐意图）
         -> 通过 gate：writeback verified
         -> gate 不满足意图：writeback failed_retest，带意图差异再派发 Developer
-  -> Test 失败：writeback failed_retest，追加证据，再派发 Developer（最多累计三轮）
-  -> 累计三轮失败：writeback leftover，继续下一个任务
+  -> Test 因环境无法完成：记录 environmentIncidents，不计轮次；有界恢复并明确告知用户下一步
+  -> Test 观察到产品失败：writeback failed_retest，追加证据，再派发 Developer（最多累计三轮有效产品复验）
+  -> 累计三轮有效产品失败：writeback leftover，继续下一个任务
 ```
 
 一次派发只修一个明确问题（细则见 `optimization-method.md` §「每轮派发只修一个明确问题」）。
 「决定 worktree」「解析 profile/receipt」几步的决策见下节与 `model-routing.md` /
-`orca-adapter.md`。v0.10 不自动复用历史 receipt 或既有终端；标题、preview、分支名、
-worker 自报和无密钥 receipt checksum 都不能代替可信启动 attestation。
+`orca-adapter.md`。历史 receipt、标题、preview、分支名、worker 自报和无密钥 receipt
+checksum 都不能代替可信启动 attestation 或历史消息清理证明。只复用同一轮内明确空闲、
+身份完全匹配且得到新会话身份的 worker；清理能力缺失或结果不确定时必须 fresh launch。
 Coordinator 默认给新逻辑轮次生成 `<task-id>-A<round>`，并在记录轮次结果时写入
 `tasks[].dispatch.rounds[].attemptId`。它独立于编排工具产生的 `taskId` 和
 `dispatchId`：前者用于知识来源追溯，后两者只用于查询运行时。0.9.0 之前的历史
@@ -106,10 +109,10 @@ Test 对显式引用回报 `not_applicable` 时，说明 Coordinator 的选择
 
 Coordinator 派发前先决定 Developer/Test 在哪工作。两种方式：
 
-**方式 1：当前 worktree 起 fresh 子 agent（终端）**
+**方式 1：当前 worktree 复用安全重置的空闲子 agent，或起 fresh 子 agent（终端）**
 
 ```bash
-# v0.10 不自动复用既有终端；先审阅 plan：
+# 当前 Orca 不能可信清理历史消息，因此先审阅 fresh launch plan：
 python3 <ack-skill-dir>/scripts/launch_worker.py plan \
   --project-root <project-root> --task-id <task-id> \
   --attempt-id <task-id>-A<round> --role <developer-or-test> \
@@ -189,7 +192,9 @@ v0.10 的 full-access 授权与撤销机制仍是 Deferred；launcher 遇到 ful
 4. Coordinator 写回 `fixed_by_dev`，用 `prompt-templates.md` §3 的复测派发模板把任务发给 Test。
 5. Test 独立复测后按复测报告模板回报证据和 `knowledgeChecks`。
 6. Coordinator 做终检并回写 `tasks.yaml`：通过 `verified`，不过 `failed_retest`。
-7. 失败则用「复测失败再派发模板」重新发给 Developer，最多累计三轮。
+7. 产品失败则用「复测失败再派发模板」重新发给 Developer，最多累计三轮有效产品
+   复验；环境失败写入 `dispatch.environmentIncidents`，恢复环境后重新派发 Test，
+   不派 Developer、不消耗产品轮次。
 
 手动模式下同样遵守：worker_done / 复测报告都不等于最终结论、只有 Coordinator
 写 `tasks.yaml` 和 `knowledge.yaml`、三轮失败留档。若本次确认计划还包含交付，所有
@@ -297,3 +302,32 @@ resolution:
   evidence:
     final: "<latest failing evidence>"
 ```
+
+环境失败不进入上面的 `rounds`，单独记录：
+
+```yaml
+status: fixed_by_dev
+dispatch:
+  environmentIncidents:
+    - id: "BUG-001-ENV-1"
+      role: test
+      phase: service
+      status: open
+      summary: "无法访问待测服务"
+      evidence: "preflight connection refused"
+      impact: "未执行产品验收信号"
+      recoveryAction: "启动正确 worktree 的最新服务后重试"
+      userAction: "无需操作；Coordinator 将重启服务"
+      reportedAt: "<timestamp>"
+```
+
+---
+
+## Worker 收尾
+
+Coordinator 写入本轮全部最终状态并完成已确认的 delivery 停止点后，再回收 worker。
+按 terminal handle 聚合所有 receipt 引用：只关闭全部关联任务均为 `verified`、且没有
+未解决环境事件的 handle。任何关联任务仍为 `open`、`dispatched`、`fixed_by_dev`、
+`retesting`、`blocked`、`failed_retest`、`leftover` 或状态不明时都保留该终端，不设置
+TTL。关闭前后按 `orca-adapter.md` 核对 runtime/handle/incarnation 和关闭回执；关闭
+不确定时报告并保留审计记录。