feat(ack): supervise worker liveness after dispatch instead of blind wait

skills/ack/references/closed-loop.md

@@ -39,13 +39,17 @@ Coordinator 发现或读取 open 任务
   -> 检查同轮空闲 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）
+  -> 确认 Developer 已开始执行（terminal read 确认任务注入；未开始按环境失败处理）
+  -> wait：滚动 check --wait + 定期 worker_probe（识别审批/未回车/额度停滞）
+     直到 Developer 的 worker_done / escalation（含 knowledgeApplied / knowledgeCandidates）
   -> writeback fixed_by_dev
   -> 若 delivery.yaml intents.testEnvironment 已启用：Coordinator 先执行该 profile
      拉起待测服务，再派 Test；Test 不发明编译或启动命令
   -> 为 Test 独立解析安全 profile；安全重置同角色空闲 worker，或重新 plan/launch fresh worker
   -> dispatch 给 Test（retesting）
-  -> wait：Test 的 retest_result（含 knowledgeChecks 和 candidate 独立证据）
+  -> 确认 Test 已开始执行（terminal read 确认任务注入；未开始按环境失败处理）
+  -> wait：滚动 check --wait + 定期 worker_probe（识别审批/未回车/额度停滞）
+     直到 Test 的 retest_result（含 knowledgeChecks 和 candidate 独立证据）
   -> Test 通过：gate（Coordinator 读证据对齐意图）
         -> 通过 gate：writeback verified
         -> gate 不满足意图：writeback failed_retest，带意图差异再派发 Developer

skills/ack/references/kickoff.md

@@ -152,7 +152,7 @@ worktree 走同一套 `plan` -> 带 expected fingerprint 的 `launch`。在调
 ## 第 4 步：跑闭环（每个任务）
 
 ```text
-task-create → dispatch 给 DEV → 等 worker_done
+task-create → dispatch 给 DEV → 先确认 DEV 已开始执行（read/probe；未开始按环境失败处理）→ 滚动 wait 等 worker_done
   → 每个角色先检查可安全重置的空闲 worker；不符合即通过 plan + expected fingerprint launch fresh worker
   → 每轮使用 Coordinator 分配的稳定 <task-id>-A<round>
   → 回写 fixed_by_dev → 若 intents.testEnvironment 已启用则先拉起测试环境 → dispatch 给 TEST 复测 → 等 retest_result

skills/ack/references/optimization-method.md

@@ -75,6 +75,11 @@ sandbox/权限阻止访问待测服务、服务实例或构建不匹配、必要
 工具不可用、编排 IPC 失败。若已有独立的产品信号明确失败，只把该产品失败计入轮次；
 其余环境问题另行记录，不能用“环境失败”掩盖产品证据。
 
+Coordinator 派发后必须确认消息已投递且 worker 已开始执行：只凭 `check --wait`
+超时无法区分慢任务与未执行，等待期间要用终端活性探测（`scripts/worker_probe.py`）
+定期检查。检测到卡在审批提示、投递后未回车或命中额度限制时，按环境失败记录并做
+有界恢复，不消耗产品复验轮次。
+
 环境失败写入 `dispatch.environmentIncidents`，不要追加到 `dispatch.rounds`，也不要把
 任务写成 `failed_retest`。实现已经完成时保持 `fixed_by_dev`；恢复后再进入
 `retesting`。确实需要用户或外部条件才能继续时可暂时写 `blocked`，环境恢复后回到

skills/ack/references/orca-adapter.md

@@ -204,18 +204,45 @@ EOF
 
 ---
 
-## 等待结果
+## 等待结果：派发后的活性监督
+
+派发或手动投递后**不能只依赖 `check --wait` 盲等**：卡在审批提示、投递后未回车、
+命中额度限制的 worker 不会自己发 `worker_done`。先确认 worker 真的开始执行，等待
+期间周期性探测活性。
+
+1. 投递后立即确认开始执行：
+   - `--inject` 路径：`orca terminal read --terminal <handle>`，确认 TASK 段已出现
+     且终端进入工作指示（Working / Running）。
+   - 手动投递路径：`orca terminal send` 必须带 `--enter`；投递后同样 read 确认。
+   - 确认失败或终端仍停在欢迎提示：按「消息未投递」记录环境失败，不消耗产品轮次。
+2. 等待期间滚动 probe（每 60–120 秒一次）：
+
+   ```bash
+   python3 <ack-skill-dir>/scripts/worker_probe.py \
+     --task-id <task_id> --terminal <worker_handle>
+   ```
+
+   输出 JSON `status`：`running` / `progress` / `stall` / `not-started` / `unknown`。
+3. 探测结果处理：
+   - `stall`：读 terminal tail 确认原因（审批 / 模型切换 / 额度限制），按环境失败
+     记录 `environmentIncidents` 并做有界恢复；需要用户决定时立即报告。
+   - `not-started`：检查是否漏投递或未回车；重新投递或记录环境失败，不占轮次。
+   - `running` / `progress`：继续滚动 wait。
+   - `unknown`：按 `dispatch-show` 与 Orca live state 人工核对，不自动重试。
+4. `check --wait` 使用短窗口（60–90 秒）而不是 15 分钟：窗口超时是检查点，先 probe
+   再决定继续等待、恢复或上报。
 
 ```bash
 orca orchestration check \
   --terminal <coordinator_handle> \
   --wait \
   --types worker_done,retest_result,escalation,decision_gate \
-  --timeout-ms 900000 \
+  --timeout-ms 90000 \
   --json
 ```
 
-等待超时不等于失败。长任务可继续等待，或检查 worker 终端活性。`worker_done` 来自 Developer，`retest_result`（无该类型时用 `worker_done` + subject 区分）来自 Test。
+`worker_done` 来自 Developer，`retest_result`（无该类型时用 `worker_done` + subject
+区分）来自 Test。
 
 ---