feat(ack): refine intake and validation workflow

skills/ack/references/kickoff.md

@@ -34,11 +34,15 @@
 5. 先把「产品文档 + 任务拆分 + 验收信号 + 适用知识引用」给我确认；若启用了交付，
    同时列明本次 profile、目标、停止点与审批步骤。不要急着派发或交付。
 6. 我确认后，按 ack 闭环循环：先用 `scripts/launch_worker.py` 校验结构化
-   Developer/Test profile，审阅 plan 后用 expected fingerprint 创建 fresh worker，
+   Developer/Test profile；优先选择同一轮内角色/profile/worktree 匹配的空闲 worker，
+   只有历史消息已可信清理并取得新会话身份才复用，否则审阅 plan 后用 expected
+   fingerprint 创建 fresh worker；
    dispatch 开发 → worker_done → dispatch 测试独立复测 → 你读证据终检 → 回写 tasks.yaml；
-   每个任务最多三轮，三轮不过记 leftover 并升级我复盘。
+   每个任务最多三轮有效产品复验，三轮不过记 leftover 并升级我复盘；环境失败单独
+   记录、恢复并告诉我下一步，不占产品复验轮次。
 7. 所选任务都 verified 后，只有本次计划包含交付时才按 profile 顺序执行并写
-   deliveryRuns；默认停在 review_ready，stable/production 步骤再次向我确认。
+   deliveryRuns；启用 delivery 时不能省略 defaultProfile，默认停在 validation_ready
+   或 review_ready，stable/production 步骤再次向我确认。
 ```
 
 ---
@@ -89,9 +93,11 @@ python3 <ack-skill-dir>/scripts/select_tasks.py docs/ack/tasks.yaml \
 
 ## 第 3 步：审阅并启动 worker
 
-先读 `tasks.yaml.project.orchestration` 的结构化 profiles。v0.10 不把历史 receipt
-或既有 Orca terminal 当作自动复用授权；每次自动派发都创建 fresh worker。原因和
-边界见 `model-routing.md` §「Receipt、审计与复用边界」。
+先读 `tasks.yaml.project.orchestration` 的结构化 profiles。历史 receipt 或既有 Orca
+terminal 不能单独授权复用。复用候选必须属于同一轮 ACK、处于空闲状态，且角色、
+profile、worktree 与启动身份仍完全匹配；还必须通过受信后端清理历史消息并取得可核对
+的新会话身份。当前 Orca 接口缺少该清理证明，所以 Orca 派发仍创建 fresh worker。
+原因和边界见 `model-routing.md` §「Receipt、审计与复用边界」。
 
 先查看目标 profile hash，确认本次结构化配置。这个 hash 只用于审计和漂移比较，
 不能用于匹配或复用旧 receipt / 既有终端：
@@ -128,7 +134,7 @@ receipt 原样追加到 `tasks.yaml.workerReceipts`，把 `receipt.id` 写入该
 task/role/profile/attempt 完全绑定；不得把旧任务或旧轮次的 receipt 改挂到当前
 dispatch。后续
 紧随其后的本次 Orca dispatch 只使用这次 fresh receipt binding 中的 handle；持久化
-receipt 仅用于审计，不能在后续轮次自动复用。不要自行拼装 Agent CLI 或 Orca 的
+receipt 仅用于审计，不能在后续轮次单独授权复用。不要自行拼装 Agent CLI 或 Orca 的
 底层创建命令。
 
 新 worktree 时可先运行
@@ -146,12 +152,13 @@ worktree 走同一套 `plan` -> 带 expected fingerprint 的 `launch`。在调
 
 ```text
 task-create → dispatch 给 DEV → 等 worker_done
-  → 每个角色都通过 plan + expected fingerprint launch fresh worker 并写回 receipt
+  → 每个角色先检查可安全重置的空闲 worker；不符合即通过 plan + expected fingerprint launch fresh worker
   → 每轮使用 Coordinator 分配的稳定 <task-id>-A<round>
   → 回写 fixed_by_dev → dispatch 给 TEST 复测 → 等 retest_result
   → Developer 回 knowledgeApplied / knowledgeCandidates，Test 回 knowledgeChecks
-  → Coordinator 读证据终检 → 过则 verified，不过则 failed_retest 再派 DEV（最多累计 3 轮）
-  → 三轮失败：leftover，升级复盘，继续下一个
+  → 环境无法完成：记录 environmentIncidents，报告影响与用户下一步，恢复后重新复验（不计轮次）
+  → Coordinator 读证据终检 → 过则 verified，产品失败则 failed_retest 再派 DEV（最多累计 3 轮）
+  → 三轮有效产品失败：leftover，升级复盘，继续下一个
 ```
 
 具体命令见 `orca-adapter.md`（Orca）或 `closed-loop.md` §「手动模式」（无 Orca）；派发文案见 `prompt-templates.md`。
@@ -167,15 +174,22 @@ Coordinator 只内联本轮 `knowledgeRefs` 指向的少量知识，不要求 wo
 ## 第 5 步：可选交付
 
 所选任务都由 Coordinator 标记为 `verified` 后，若用户确认的计划包含交付，按
-`delivery.md` 执行所选 profile。先重新校验 `delivery.yaml`，固定当前 commit 和
+`delivery.md` 执行所选 profile。启用交付时必须在计划中默认列出 `defaultProfile`，
+用户可明确取消，Coordinator 不能静默省略。先重新校验 `delivery.yaml`，固定当前 commit 和
 config revision，然后按有序步骤调用项目入口与已安装的低层 skill。每一步证据写入
-`tasks.yaml.deliveryRuns`；默认 profile 到 `review_ready` 即停止，stable 发布和
-production 部署必须在 approval 步骤再次确认。失败时保留任务的 `verified`，把
+`tasks.yaml.deliveryRuns`；默认 profile 到 `validation_ready` 或 `review_ready` 即停止。
+前者必须把测试环境地址和用户下一步交付出来；stable 发布和 production 部署必须在
+approval 步骤再次确认。失败时保留任务的 `verified`，把
 delivery run 标为 `blocked` 或 `failed`。
 
 ## 第 6 步：收尾
 
-一轮结束时 Coordinator 必须能回答 `optimization-method.md` §「结束条件」的问题：哪些 verified、哪些 leftover、各失败几轮、工作树是否干净、还有没有未处理项。
+一轮结束时 Coordinator 必须能回答 `optimization-method.md` §「结束条件」的问题：
+哪些 verified、哪些 leftover、各失败几轮、工作树是否干净、还有没有未处理项。
+Coordinator 最后标记整轮任务完成后，关闭所有只关联 `verified` 任务的 Developer/Test
+终端并核对关闭回执；receipt 和落盘证据继续保留。仍关联 `blocked`、`failed_retest`、
+`leftover` 或其它未完成任务/未解决环境事件的终端保留，不设置 TTL。一个终端只要仍被
+任一这类任务引用，就不能因为同时关联了 verified 任务而关闭。
 
 ---
 
@@ -185,4 +199,5 @@ delivery run 标为 `blocked` 或 `failed`。
 `tasks.yaml.project.orchestration` 解析安全 profile → 审阅 plan 并用 expected
 fingerprint 启动 fresh DEV/TEST → dispatch / 复测 / 终检循环 → 任务结论落
 `tasks.yaml` → 可选 delivery profile 到审核点，验证后的
-跨任务知识由 Coordinator 落 `knowledge.yaml`。
+跨任务知识由 Coordinator 落 `knowledge.yaml` → 整轮完成后回收仅属于 verified
+任务的 worker，保留 blocked/failed/leftover worker。