feat(ack): refine intake and validation workflow

skills/ack/references/adoption-checklist.md

@@ -88,8 +88,9 @@
       `--expected-launch-fingerprint`；漂移时重新 plan。
 - [ ] Developer/Test 只使用 `read-only` 或 `workspace-write` profile；
       v0.10 没有 full-access、bypass、YOLO/force 或关闭 sandbox。
-- [ ] v0.10 每次自动派发都启动 fresh worker；没有把历史 receipt checksum 或
-      Orca live metadata 当作自动复用授权。
+- [ ] 只考虑同轮、空闲、角色/profile/worktree/启动身份匹配的复用候选；历史消息必须
+      由受信后端清理并返回新会话身份。任一条件不符或无法确认清理成功时启动 fresh
+      worker；没有把历史 receipt checksum 或 Orca live metadata 当作复用授权。
 - [ ] launcher receipt 已追加到顶层 `workerReceipts`，任务分别引用
       `dispatch.developer` 与 `dispatch.test`；每个引用的 task/role/profile/attempt
       都与当前任务、本轮 receipt 完全一致，没有用单一 handle 混淆两个角色。
@@ -103,6 +104,8 @@
 - [ ] 每轮写入 `dispatch.rounds`。
 - [ ] 三轮失败后标记 `leftover` 并填写原因。
 - [ ] `leftover` 不阻塞其它任务。
+- [ ] Coordinator 标记整轮完成后，已关闭所有只属于 `verified` 任务的 worker；仍关联
+      blocked/failed/leftover、未完成任务或未解决环境事件的终端保留且不设 TTL。
 
 首次接入建议选择一个低风险问题跑完整闭环。项目差异写回
 `docs/ack/project.md`；通用问题回流到 ACK Skill 的 `references/`、`templates/`

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 和关闭回执；关闭
+不确定时报告并保留审计记录。

skills/ack/references/delivery.md

@@ -1,14 +1,15 @@
 # ACK 交付阶段
 
-本文件定义可选的 `verified -> review_ready/released` 交付阶段。开发、独立复测和
+本文件定义可选的 `verified -> validation_ready/review_ready/released` 交付阶段。开发、独立复测和
 Coordinator 终检仍由 ACK 原有闭环负责；只有选中的任务全部 `verified` 后才能进入
 交付。项目配置位于 `docs/ack/delivery.yaml`，运行证据写入
 `docs/ack/tasks.yaml.deliveryRuns`。
 
 ## 1. 配置与授权不是一回事
 
-`delivery.yaml` 描述项目能怎样构建、上传和部署，不能单独授予远端写权限。ACK 在
-kickoff 的既有用户确认点同时展示本次 profile、remote、产物目标、环境和停止点；用户
+`delivery.yaml` 描述项目能怎样构建、上传和部署，不能单独授予远端写权限。启用交付
+时，ACK 在 kickoff 的既有用户确认点默认展示 `defaultProfile`、remote、产物目标、环境
+和停止点，不得静默省略；用户
 确认该任务计划后，才允许执行计划中准确列出的 `review_ready` 步骤。目标、remote、
 channel、environment 或 source revision 漂移时重新确认。
 
@@ -42,8 +43,9 @@ channel、environment 或 source revision 漂移时重新确认。
   stable。
 - `environments`：SSH host、Docker Compose、Kubernetes 或 custom；必须声明环境等级、
   deploy 和 health check，production 还必须声明 rollback。
-- `profiles`：按顺序执行的步骤和停止点。默认 profile 必须停在 `review_ready`，不能
-  发布 stable 或部署 production。
+- `profiles`：按顺序执行的步骤和停止点。默认 profile 必须停在 `validation_ready` 或
+  `review_ready`，不能发布 stable 或部署 production。`validation_ready` profile 必须
+  至少部署一个 development/staging 环境，并对每个部署目标执行健康检查。
 
 配置不允许 `shell`、自由 `command`、`env`、外部 executable、token、密码、私钥路径
 或凭据 URL。entrypoint 的 `requiredSecrets` 只能列大写 secret 名称，值必须由外部
@@ -100,7 +102,9 @@ channel、environment 或 source revision 漂移时重新确认。
 ## 6. 状态与恢复
 
 `task.status=verified` 表示代码正确性通过；交付状态单独记录为 `planned`、`running`、
-`blocked`、`failed`、`review_ready`、`released` 或 `skipped`。部署或 Forge 暂时失败不把
+`blocked`、`failed`、`validation_ready`、`review_ready`、`released` 或 `skipped`。
+`validation_ready` 表示已把不可变产物部署到开发/测试环境并通过健康检查，可以交给
+用户手工验证，不要求存在 PR/MR。部署或 Forge 暂时失败不把
 任务改回 `failed_retest`。
 
 重复运行先核对已有 branch、PR/MR、artifact 和部署目标，复用身份匹配的资源。相同
@@ -110,7 +114,8 @@ ID 指向不同 commit、digest 或目标时停止，不覆盖或另建伪装成
 验证闭环，Test 重新复测后才能创建新的 delivery run。只有外部瞬时失败且 Git 内容未变
 时，才可从失败步骤继续。
 
-`review_ready` 至少记录：source/config revision、PR/MR URL、所有产物引用与 digest、
+`validation_ready` 至少记录：source/config revision、所有产物引用与 digest、部署环境、
+访问地址和用户下一步，以及健康检查证据。`review_ready` 至少记录：source/config revision、PR/MR URL、所有产物引用与 digest、
 部署环境和健康检查证据。最终回复分别报告代码验证、PR、产物、部署和未完成项，不能用
 “完成”掩盖其中某一阶段失败或待审批。
 

skills/ack/references/feishu-bug-intake.md

@@ -1,53 +1,71 @@
 # 飞书 Base Bug 整理与审核
 
-飞书 Base 是 Bug 在**审核通过前的唯一协作区**。用户先在飞书记录 Bug 描述，
-Coordinator 读取记录和项目现状，补全或修改修复逻辑、验收标准，再写回同一条飞书
-记录。用户可以继续在飞书反馈，Coordinator 按反馈反复修订。只有用户明确表示审核
-通过后，Coordinator 才把最终版本写入 `docs/ack/tasks.yaml`，随后启动 ACK 三角色闭环。
+飞书 Base 是 Bug 在审核通过前的唯一协作区。用户只需填写 `标题`，可选填写
+`详细描述`，并把截图、录屏或日志放在 `附件`。Coordinator 结合来源事实、附件和项目
+现状整理 `问题说明`、`期望效果`、`验收标准`，但不在收件箱写修复逻辑。
 
-审核前不创建或刷新 `tasks.yaml` 中的 ACK 任务，不得启动 worker，不得派发
-Developer/Test，也不得修改应用代码。飞书字段已填满、记录进入某个 view、用户暂时没有
-回复，都不等于审核通过。
+审核通过前不创建或刷新 `tasks.yaml` 中的 ACK 任务，不得启动 worker、派发 Developer/Test
+或修改应用代码。字段已填满、记录进入某个 view、用户暂时没有回复，都不等于审核通过。
 
-## 项目配置
+## 项目配置与 Base 结构
 
-项目在 `docs/ack/tasks.yaml` 的 `project.bugIntake` 声明 `provider: feishu-base`、
-`workflow: reviewed-writeback-v1`、显式 `profile`、`baseToken`、`tableId`、用于候选 Bug
-的 `viewId` 和字段映射；不要保存 App Secret、access token 或任何 profile 凭据。
+`docs/ack/tasks.yaml` 的 `project.bugIntake` 必须声明 `provider: feishu-base`、
+`workflow: clarified-writeback-v1`、显式 `profile`、`baseToken`、`tableId`、`viewId` 和字段映射：
 
-原有八字段配置在未声明 `workflow` 时按 `read-only-v1` 兼容读取，不得写回或进入本节
-流程。启用审核前协作必须显式选择 `reviewed-writeback-v1`，并在 `title`、`actual`、
-`expected`、`stepsToReproduce`、`acceptance`、`priority`、`attachments`、`updatedAt`
-之外配置可写文本字段 `fixLogic`。其中 `fixLogic` 和 `acceptance` 由 Coordinator 维护；
-用户提供的标题、实际表现、预期结果和附件属于来源事实，Coordinator 不得覆盖。
+```yaml
+fields:
+  title: 标题
+  details: 详细描述
+  problemStatement: 问题说明
+  expectedOutcome: 期望效果
+  acceptance: 验收标准
+  intakeStatus: 处理状态
+  ackTaskId: ACK任务ID
+  attachments: 附件
+  updatedAt: 更新时间
+```
 
-## 一次性安装与 profile 设置
+人维护 `标题`、`详细描述`、`附件`；ACK 维护 `问题说明`、`期望效果`、`验收标准`；系统字段
+是 `处理状态`、`ACK任务ID`、`更新时间`。状态按
+`待整理 → 需补充/待审核 → 已确认 → 已导入` 流转。优先级在批准后做任务规划时确定，
+不属于收件箱审核内容。原 `read-only-v1` 和 `reviewed-writeback-v1` 继续兼容旧项目。
 
-在账号级可信工具目录安装官方 CLI；ACK 读取器只会搜索账号的 `~/.local/bin`、mise/cargo
-shim 目录和固定系统目录，绝不会采用项目 `PATH` 中的同名文件。它同时识别官方 npm
-包生成的 `lark-cli -> @larksuite/cli/scripts/run.js` wrapper，并校验 package 名与 bin
-映射，然后直接执行该官方包下载的 native binary：
+结构变更必须先执行只读计划，再携带计划指纹应用；适配器只新增目标字段、迁移来源信息并
+调整当前 view 的可见字段，不删除旧列：
+
+```bash
+python3 <ack-skill-dir>/scripts/feishu_bug_intake.py schema-plan docs/ack/tasks.yaml
+python3 <ack-skill-dir>/scripts/feishu_bug_intake.py schema-apply docs/ack/tasks.yaml \
+  --expected-schema-fingerprint <schemaFingerprint>
+```
+
+迁移时，旧 `期望结果` 会以 `用户原始期望：…` 合并进 `详细描述`，旧字段继续保留但从
+当前 view 隐藏；空状态初始化为 `待整理`。不要保存 App Secret、access token 或 profile
+凭据。
+
+## Profile 和安全边界
+
+在账号级可信目录安装官方 CLI：
 
 ```bash
 npm install --global --prefix "$HOME/.local" @larksuite/cli@latest
-```
-
-随后在受控终端中用 stdin 提供 App Secret，选择 Feishu brand，避免 secret 进入 shell
-history、进程参数或项目文件：
-
-```bash
 printf '%s' "$FEISHU_APP_SECRET" | lark-cli profile add \
   --name project-feishu --app-id "$FEISHU_APP_ID" \
   --app-secret-stdin --brand feishu
 ```
 
-项目配置只填写 `profile: project-feishu`。不要执行 `profile use`，也不要依赖 active
-profile；读取、附件下载和写回都必须显式传 `--profile project-feishu`。profile 至少需要
-`base:record:read`、`base:record:write` 和 `docs:document.media:download`。
-不要把 `lark-cli auth check` 当作 app/bot scope 的证明，因为它检查的是当前用户的
-stored user token。
+使用官方 `lark-cli`，项目只保存 profile 名。不要依赖 active profile；所有读取、附件下载、
+写回和结构迁移都显式传配置 profile。profile 需要 Base 读写和附件下载权限。
+所需 scope 至少包括 `base:record:read`、`base:record:write` 和
+`docs:document.media:download`。不要把 `lark-cli auth check` 当作 app/bot scope 的证明，
+它只检查当前用户的 stored user token。
 
-## 读取与整理计划
+适配器只搜索账号和系统的可信工具目录，子进程只收到实际账号 HOME、可信 PATH 和基础
+locale；调用者环境中的凭据和运行时注入变量不会传入。不得绕过适配器直接操作 Base。
+每条记录最多 10 个附件、单批最多 100 个，单个附件最多 20 MiB、合计最多 200 MiB，
+整批下载最多 5 分钟。
+
+## 读取与整理
 
 ```bash
 python3 <ack-skill-dir>/scripts/feishu_bug_intake.py check docs/ack/tasks.yaml
@@ -58,84 +76,73 @@ python3 <ack-skill-dir>/scripts/feishu_bug_intake.py plan docs/ack/tasks.yaml \
   --output-dir "$tmpdir"
 ```
 
-`fetch` 只调用官方 `base +record-list` 和附件下载命令，输出标准化 JSON，并为每条记录
-计算覆盖来源事实、附件元数据和审核字段的 `draftRevision`。`plan` 只生成
-`create` / `refresh` / `unchanged` / `drift` 候选动作，不修改飞书或任务板。**审核通过前
-不得执行这些候选动作**；它们只用于查重和预览最终导入结果。
+`fetch` 输出标准化 JSON，并为每条记录计算覆盖来源事实、附件身份、整理字段和状态的
+`draftRevision`。标题和更新时间是必需来源事实；详细描述和附件可为空。问题说明、期望
+效果、验收标准缺失时返回 `enrichmentRequired`。`plan` 只给出查重和漂移预览，审核前
+不得据此创建任务。
 
-标题、实际表现、预期结果和更新时间属于来源事实，任一缺失时读取失败。复现步骤、
-修复逻辑、验收标准和优先级属于 Coordinator 可整理字段；缺失时记录与 action 返回
-`enrichmentRequired`。没有附件且所有 Bug 内容字段都为空的误建行会跳过，并在批次
-`warnings` 中返回 `blank_record_skipped`。
+Coordinator 对每条 Bug：
 
-子进程只收到实际账号 HOME、可信 PATH 和基础 locale；调用者环境中的
-`LARKSUITE_CLI_*`、`FEISHU_*`、`NODE_OPTIONS` 等变量不会传入。每条记录最多 10 个
-附件、单批最多 100 个，单个附件最多 20 MiB、合计最多 200 MiB，整批下载最多 5 分钟；
-始终使用新的临时目录作为 `--output-dir`。
+1. 读取标题、详细描述、附件及相关产品/代码上下文；证据不足时明确假设，不伪装成用户原文。
+2. 写 `problemStatement`：说清现象、影响范围和边界，不包含修复方案。
+3. 写 `expectedOutcome`：说明正确情况下用户能观察到的行为，不包含实现方式。
+4. 写 `acceptance`：形成可独立复测的、可观察的标准，不扩张用户未表达的产品范围。
+5. 将草案保存为不超过 64 KiB 的 JSON，且只含上述三个键：
 
-## 审核前协作循环
+```json
+{
+  "problemStatement": "非空字符串",
+  "expectedOutcome": "非空字符串",
+  "acceptance": ["非空验收项"]
+}
+```
 
-对每条候选 Bug，Coordinator 按以下顺序工作：
+使用当前 `sourceRef` 和 `draftRevision` 写回：
 
-1. 读取用户填写的来源事实、附件和项目代码/测试，确认问题边界；证据不足时把不确定点
-   明确写成假设，不伪装成用户原文。
-2. 整理复现步骤和优先级，并生成：
-   - `fixLogic`：说明根因判断、计划修改的位置与行为、需要保持的不变量，以及回归风险；
-     它是待审核的实现方向，不宣称代码已经修改。
-   - `acceptance`：写成可观测、可独立复测的标准，至少覆盖用户可见结果、真实状态或 API
-     结果，以及原失败不再出现；不扩张用户没有表达的产品范围。
-3. 把本轮草案保存为不超过 64 KiB 的临时 JSON：只包含非空字符串 `fixLogic` 和非空
-   字符串数组 `acceptance`。通过安全适配器写回当前飞书记录：
+```bash
+python3 <ack-skill-dir>/scripts/feishu_bug_intake.py write-draft \
+  docs/ack/tasks.yaml --record-id <record-id> \
+  --expected-source-ref <sourceRef> \
+  --expected-draft-revision <draftRevision> --input <draft.json>
+```
 
-   ```bash
-   python3 <ack-skill-dir>/scripts/feishu_bug_intake.py write-draft \
-     docs/ack/tasks.yaml --record-id <record-id> \
-     --expected-source-ref <sourceRef> \
-     --expected-draft-revision <draftRevision> --input <draft.json>
-   ```
-
-   `write-draft` 会在写前确认 record 属于配置 view，且 `sourceRef`、`draftRevision` 与调用者
-   看到的版本一致；它只允许覆盖配置映射的 `fixLogic` 和 `acceptance`，拒绝 symlink、超限
-   或多余字段输入，并复用读取器的可信 CLI、显式 profile、最小环境和成功 envelope 校验。
-   不得绕过适配器直接调用 PATH 中的 CLI，也不得改标题、实际表现、预期结果、附件或其它
-   用户字段。
-4. `write-draft` 会回读同一记录、确认落盘值一致并返回当前 `draftRevision`。把这个 revision
-   连同记录交给用户审核；不能只展示没有 revision 的自由文本。
-5. 用户提出意见时，重新读取最新记录和反馈，修订后再次写回、回读、等待审核；不要在
-   本地或聊天中维护一份与飞书分叉的“最终草案”。
-
-任一写回、回读或字段校验失败时停止本轮并报告，不能转入任务板或三角色处理。
+适配器在写前检查记录仍位于配置 view 且 revision 未漂移，只覆盖问题说明、期望效果、
+验收标准和处理状态（设为 `待审核`），随后回读并返回新 revision。把新 revision 连同整理
+结果交给用户审核。用户反馈后重新读取、修订和写回；不要在聊天或本地维护分叉版本。
 
 ## 审核门禁与导入
 
-只有用户针对当前飞书记录的明确 `draftRevision` 表示“审核通过”“可以执行”或等价授权，
-才解除门禁。授权必须发生在最后一次草案写回和回读之后；之后若用户字段、附件、
-`fixLogic` 或 `acceptance` 再次变化，revision 会变化，原授权失效，必须重新审核。
+只有用户针对当前 revision 明确表示审核通过，并由用户本人在飞书把处理状态改为
+`已确认`，才可继续导入。Coordinator 使用的适配器不提供把草案自行标成已确认的命令；
+状态和任务 ID 不参与内容 revision，因此用户确认状态不会改变已批准内容的 revision。
 
-审核通过后，Coordinator 才执行以下动作：
+重新读取并核对状态和 revision 后执行：
 
-1. 通过适配器重新读取并生成规范任务草案；命令会要求当前 `sourceRef` 和
-   `draftRevision` 精确等于用户批准值：
+```bash
+python3 <ack-skill-dir>/scripts/feishu_bug_intake.py import-approved \
+  docs/ack/tasks.yaml --record-id <record-id> \
+  --expected-source-ref <approved-sourceRef> \
+  --expected-draft-revision <approvedDraftRevision>
+```
 
-   ```bash
-   python3 <ack-skill-dir>/scripts/feishu_bug_intake.py import-approved \
-     docs/ack/tasks.yaml --record-id <record-id> \
-     --expected-source-ref <approved-sourceRef> \
-     --expected-draft-revision <approved-draftRevision>
-   ```
+任一来源事实、附件或整理字段变化都会使旧批准失效。导出的 `taskDraft` 把问题说明映射为
+`description`、期望效果映射为 `expected`、验收标准映射为 `acceptanceCriteria`；不包含
+修复逻辑、复现步骤或优先级。Coordinator 在后续任务规划中补充优先级，但不得改写已审核
+字段；校验器会重算 `approvedPayloadHash`。
 
-   不一致时停止并重新审核。输出的 `taskDraft` 包含批准后的规范字段以及
-   `source.workflow`、`source.approvedRevision`、`source.approvedPayloadHash`。
-2. 按 `source.ref` 查重，把 `taskDraft` 原样合并到新的 ACK task，只补任务 ID、状态、
-   dispatch 等 ACK 运行字段；不得手工改写 `fixLogic`、`acceptanceCriteria` 或其它审核字段。
-   可在 `evidence.intakeEnrichment` 标明 Coordinator 推断依据，但它不替代规范字段。
-3. 运行 `validate_tasks.py`。校验器会重算 `approvedPayloadHash`；只有写入和校验都成功，
-   任务才可作为已确认的 `open` 任务
-   进入 ACK 闭环。
-4. 按 Coordinator → Developer → Test 的标准流程派发、实现和独立复测。
+把 `taskDraft` 写入 `tasks.yaml`、补齐任务 ID 和规划字段并通过任务板校验后，再把最终
+任务 ID 与同一批准 revision 写回飞书：
 
-相同来源只更新尚未派发的 `open` 任务；`dispatched`、`fixed_by_dev`、`retesting`、
-`failed_retest`、`verified`、`blocked` 和 `leftover` 任务只告警来源漂移，由用户决定是否
-新建任务。项目启用 reviewed workflow 后，历史 `verified` / `leftover` 只读来源继续保留；
-其它仍可执行的 legacy 飞书任务必须先按当前流程重新整理和审核，不能通过省略或降级
-`source.workflow` 绕过门禁。飞书记录消失、不可访问或同步失败时，已有 ACK 任务一律保留。
+```bash
+python3 <ack-skill-dir>/scripts/feishu_bug_intake.py mark-imported \
+  docs/ack/tasks.yaml --record-id <record-id> --task-id <ack-task-id> \
+  --expected-source-ref <approved-sourceRef> \
+  --expected-draft-revision <approvedDraftRevision>
+```
+
+适配器只在任务板恰有一条 ID 匹配、来源引用、记录 ID、批准 revision 和 payload hash
+全部一致的任务时，写入 `ACK任务ID` 并把状态推进到 `已导入`；回读不一致则失败。重复执行
+同一绑定是幂等的，不能把一条记录改挂到另一个任务。
+
+按 `source.ref` 查重：仅未派发的 `open` 任务可刷新；其它状态只报告来源漂移，不覆盖。
+来源消失、不可访问或同步失败时，不删除已有 ACK 任务。

skills/ack/references/init-new-project.md

@@ -145,7 +145,7 @@ python3 <ack-skill-dir>/scripts/validate_delivery.py docs/ack/delivery.yaml \
   `read-only` 或 `workspace-write`；旧任务板未迁移时保持手动模式。
 - 顶层 `workerReceipts` 和 `dispatch.developer/test` 的 task/role/profile/attempt
   引用一致；`receiptId` 与 `attemptId` 同时为空或同时填写。持久 receipt 只作审计，
-  v0.10 不自动复用旧终端。
+  不能单独授权复用旧终端；复用还需要空闲状态、身份匹配和可信历史清理证明。
 - 网站或 API 项目写清服务启动、重启和 Base URL。
 - 任务中的固定 revision `knowledgeRefs` 都能解析，非 `active` 条目没有被派发。
 

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。

skills/ack/references/model-routing.md

@@ -57,9 +57,8 @@ Coordinator 用强模型但**不亲自跑测试**（测试由 Test 承担），
 - 低档位反复产出表面修复。
 
 升级由 Coordinator 判断并记录原因。升级不是修改一个正在运行的终端：必须选择
-对应强档 profile，重新计算 `profileHash`，再通过 launcher 创建新的 worker。
-v0.10 不自动复用持久化 receipt 指向的旧终端，Test 也不得使用 Developer 的强档
-worker。
+对应强档 profile，重新计算 `profileHash`，再通过 launcher 创建新的 worker。模型或
+profile 升级时不得复用旧 worker，Test 也不得使用 Developer 的强档 worker。
 
 ---
 
@@ -211,10 +210,13 @@ receipt 至少把以下事实绑定在一起：
 
 `receiptHash` 是无密钥的规范 JSON checksum，只能发现意外漂移或未同步修改，**不是
 launcher 身份证明，也不是复用授权**。项目内有写权限的一方可以修改 receipt 后重算
-hash；而当前 Orca metadata 又不能证明终端最初执行的命令、模型和权限。因此 v0.10
-明确禁止根据持久化 receipt 自动复用既有终端：每次需要自动派发 worker，都重新走
-`plan` → 带 expected fingerprint 的 `launch`，只使用该次 launcher 标准输出中的
-fresh handle 完成本次派发。
+hash；而当前 Orca metadata 又不能证明终端最初执行的命令、模型和权限。因此 ACK
+明确禁止根据持久化 receipt 自动复用既有终端。复用只允许发生在同一轮 ACK 内，并且
+必须先证明 worker 空闲、角色/profile/worktree/runtime/incarnation 完全匹配，再由
+受信后端清理历史消息并返回新的 conversation/session identity 与本次 task/attempt
+绑定。正在工作、等待回报、状态不明或关联未完成任务的 worker 都不是空闲候选。任一
+条件不满足、清理失败或清理结果无法确认时，重新走 `plan` → 带 expected fingerprint
+的 `launch`，使用 fresh handle 派发。
 
 `launchFingerprint` 是确定性的完整计划漂移校验，不是一次性授权或幂等键。同一份
 计划重复执行 `launch` 会创建新的 fresh terminal；成功后不得用同一 fingerprint
@@ -223,9 +225,10 @@ fresh handle 完成本次派发。
 提供，而不是把 checksum 冒充成一次性令牌。
 
 持久化 receipt 仍用于审计、dispatch 关联和检测配置漂移；标题、preview、分支名、
-worker 自报或单独的 Orca live metadata 都不能把旧终端提升为可信 worker。未来只有
-在 Orca/ACP 提供启动参数 attestation，或存在项目外可信签发与校验通道后，才开放
-自动复用。CLI / 模型变更仍需更新 allowlist 并重新生成 receipt。
+worker 自报或单独的 Orca live metadata 都不能把旧终端提升为可信 worker。只有
+Orca/ACP 同时提供启动参数 attestation、明确空闲状态、可信历史清理和新会话身份，或
+ACK 接入等价的项目外可信签发与校验通道，才实际启用自动复用。当前 Orca 不满足这些
+条件，所以仍创建 fresh worker。CLI / 模型变更仍需更新 allowlist 并重新生成 receipt。
 
 `ackVersion` 必须使用合法 SemVer。`0.10.0` 及以后版本的任务板必须同时存在
 `project.orchestration` 与顶层 `workerReceipts`；其中任一字段出现，另一个也必须

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 的知识？
 

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 只在后续任务得到验证或用户明确要求清理时回收。

skills/ack/references/prompt-templates.md

@@ -134,6 +134,9 @@ Developer 本轮声称（仅供参考，不作数）：
   1. <observable signal 1>
   2. <observable signal 2>
   3. <observable signal 3>
+- 若 worker、权限、服务、测试数据、浏览器或工具导致验收无法完成，明确回报
+  `environmentFailure`，不要把“未验证”写成产品 `signals-failed`；若已有独立产品失败
+  证据，则分别列出产品信号与环境限制。
 - 需要时把易反复误判的路径沉淀成可执行测试（见 optimization-method.md §8）。
 - 对每条适用的 `knowledgeRef`，把它的 verification.ref 交给
   `<ack-skill-dir>/scripts/run_verification.py docs/ack/knowledge.yaml
@@ -227,6 +230,7 @@ knowledgeCandidates:
     rationale: <why this changes future work>
     evidenceRefs: [<independent evidence reference>]
 conclusion: all-signals-pass / signals-failed
+environmentFailure: null / <phase, evidence, impact, recovery suggestion>
 notes: <observations, suspected cause, and independent candidate validation evidence>
 ```
 
@@ -245,6 +249,9 @@ Orca 模式下用 `orca-adapter.md` §「Test 回报复测结果」的命令发
 已验证（Test 复测通过 + 终检）：
 - <task_id>: <what passed>
 
+环境事件：
+- <task_id>: <原因、影响、是否恢复、Coordinator 下一步、userAction>
+
 遗留：
 - <task_id>: 三轮仍未通过，已记录为 leftover。最后失败证据：<evidence>
 
@@ -257,7 +264,7 @@ Orca 模式下用 `orca-adapter.md` §「Test 回报复测结果」的命令发
 - 待验证 candidate：<remaining candidates or none>
 
 交付（未启用时写 n/a）：
-- run/profile/status：<delivery run id / profile / review_ready|released|blocked|failed>
+- run/profile/status：<delivery run id / profile / validation_ready|review_ready|released|blocked|failed>
 - PR/MR：<URL and head/base>
 - 产物：<reference, digest, destination>
 - 部署：<environment, health/rollback evidence>

skills/ack/references/roles-and-permissions.md

@@ -45,7 +45,8 @@ ACK 默认三个独立 Agent：**Coordinator 只编排、Test 只验证、Develo
     `dispatchId` 代替。
   - gate 时检查 Developer 的 `knowledgeApplied`、Test 的 `knowledgeChecks` 和
     candidate 独立证据；只有证据充分时才由 Coordinator 激活、废弃或替代知识。
-  - 一次派发只针对一个明确问题（`optimization-method.md` §6）；每任务最多三轮。
+  - 一次派发只针对一个明确问题（`optimization-method.md` §6）；每任务最多三轮有效
+    产品复验。环境失败单独记录、恢复和报告，不占轮次。
   - 终检：读 Test 证据，逐条对齐原始意图后才落 `verified`，不亲自复测。
 - **Must Not**：改源码、亲自跑测试、凭 `worker_done` 直接标 `verified`、把多个无关失败塞进一次派发、派发 `candidate` 或全量注入知识库、把知识正文当作 shell 执行。
 - **Evidence**：产品文档、`tasks.yaml` 里的 `expected` + `verification`、Test 回传的复测证据。
@@ -131,6 +132,16 @@ retesting      -> failed_retest -> dispatched
 failed_retest（累计 3 轮） -> leftover
 ```
 
+环境分支不进入 `failed_retest`：
+
+```text
+launch / service / data / browser / tooling environment failure
+  -> dispatch.environmentIncidents
+  -> 有界恢复并告知用户下一步
+  -> fixed_by_dev（待恢复）或 blocked（需外部动作）
+  -> 环境恢复后 retesting
+```
+
 状态定义（所有状态都只由 Coordinator 写入 `tasks.yaml`，来源不同）：
 
 | 状态 | 依据来源 | 含义 |
@@ -139,12 +150,12 @@ failed_retest（累计 3 轮） -> leftover
 | `dispatched` | Coordinator 派发动作 | 已派发给 Developer |
 | `fixed_by_dev` | Developer 的 worker_done | 开发声称已修复并提供白盒验证 |
 | `retesting` | Coordinator 派发动作 | 已派发给 Test，正在黑盒复测 |
-| `failed_retest` | Test 的复测报告 | 复测失败，可继续派发 Developer |
+| `failed_retest` | Test 的产品复测报告 | 环境对齐后观察到产品验收失败，可继续派发 Developer |
 | `verified` | Test 通过 + Coordinator 终检 | 复测通过且符合原始意图 |
 | `blocked` | Coordinator 判断 | 需要用户决策或外部条件 |
 | `leftover` | Coordinator 判断 | 累计 3 轮仍未通过，留给人工或专项处理 |
 
-三轮失败的处理细则见 `optimization-method.md` §「三轮失败策略」。
+有效复验与环境失败的处理细则见 `optimization-method.md` §4。
 
 ## 交付状态（与任务状态正交）
 
@@ -152,11 +163,12 @@ failed_retest（累计 3 轮） -> leftover
 `tasks.yaml.deliveryRuns`：
 
 ```text
-planned -> running -> review_ready | released
+planned -> running -> validation_ready | review_ready | released
                     -> blocked | failed
 planned -> skipped
 ```
 
+`validation_ready` 表示开发/测试环境已部署且健康检查通过，等待用户手工验证；
 `review_ready` 表示 PR、preview 产物和已授权的非生产部署证据已经齐备，等待用户
 审核；`released` 只用于用户明确批准后的 stable 发布或 production 部署。交付失败
 不会否定已经独立验证的任务，但必须保留失败步骤、revision 与日志引用。完整顺序、