feat(ack): refine intake and validation workflow

skills/ack/references/optimization-method.md

@@ -62,7 +62,49 @@ Coordinator 不亲自复测，但要做终检：读 Test 的证据，确认它
 
 ---
 
-## 4. 三轮失败策略（SSOT）
+## 4. 有效复验、环境失败与三轮策略（SSOT）
+
+### 4.1 什么才计算一轮
+
+三轮预算只计算**有效产品复验**：Test 已确认正确 worktree、最新服务、必要测试数据和
+可用验证工具，并实际执行目标验收信号；结果要么全部通过，要么观察到由待测产品行为
+导致的信号失败。
+
+以下情况属于环境失败，不是产品失败，也不占复验轮次：worker 未启动或消息未投递、
+sandbox/权限阻止访问待测服务、服务实例或构建不匹配、必要测试数据缺失、浏览器或测试
+工具不可用、编排 IPC 失败。若已有独立的产品信号明确失败，只把该产品失败计入轮次；
+其余环境问题另行记录，不能用“环境失败”掩盖产品证据。
+
+环境失败写入 `dispatch.environmentIncidents`，不要追加到 `dispatch.rounds`，也不要把
+任务写成 `failed_retest`。实现已经完成时保持 `fixed_by_dev`；恢复后再进入
+`retesting`。确实需要用户或外部条件才能继续时可暂时写 `blocked`，环境恢复后回到
+原闭环状态。
+
+每条环境事件必须包含：
+
+```yaml
+dispatch:
+  environmentIncidents:
+    - id: "BUG-001-ENV-1"
+      attemptId: "BUG-001-A1"
+      role: test
+      phase: browser
+      status: resolved
+      summary: "测试环境没有可用浏览器"
+      evidence: "chromium/playwright lookup 均为空"
+      impact: "没有执行点击级验收，不能据此判断产品失败"
+      recoveryAction: "改用受支持的浏览器运行时并启动 fresh Test"
+      userAction: "无需操作；Coordinator 继续恢复"
+      reportedAt: "<timestamp>"
+      resolvedAt: "<timestamp>"
+```
+
+`userAction` 必须明确：无需用户操作时写清 Coordinator 下一步；需要用户介入时给出一个
+具体决定、命令或外部条件，不能只写“请处理环境”。Coordinator 可以先做一次不扩大权限、
+不改变产品数据的有界恢复；仍未解决、需要用户动作或阻断本轮时，在当前会话立即报告。
+即使事件已自动恢复，最终报告也必须列出环境事件、影响和恢复结果，让用户知道发生过什么。
+
+### 4.2 三轮有效产品失败
 
 每个任务最多自动派发三轮：
 
@@ -73,7 +115,9 @@ round 3: 明确指出重复失败点，要求 worker 自己复现完整路径
 failed after round 3: 标记 leftover，继续下一个任务
 ```
 
-三轮失败后不要继续消耗同一个 worker。常见原因：验收标准需要重新设计、Worker 对问题模型理解错了、UI 自动化与实际浏览器状态有差异、需要人工观察或调试工具介入。
+三轮有效产品失败后不要继续消耗同一个 worker。常见原因：验收标准需要重新设计、
+Worker 对问题模型理解错了，或需要人工观察和专项调试。环境事件数量不受三轮预算限制，
+但必须有界恢复和透明报告，不能无限重试。
 
 留档字段（结构见 `templates/tasks.schema.json`）：
 
@@ -180,6 +224,7 @@ Developer 回报实际采用的 `knowledgeApplied` 和带当前观测证据的
 - 每个 leftover 失败了几轮？最后一轮失败证据是什么？
 - 当前工作树有哪些未提交改动？
 - 是否还有 open / failed_retest 未处理？
+- 本轮有哪些环境事件？是否已解决？用户下一步是“无需操作”还是一个明确动作？
 - 本轮显式 `knowledgeRefs` 是否都有必要的 `knowledgeChecks`？
 - 是否有待验证 candidate，或因依赖、路径、版本变化需要转为 stale 的知识？