feat(ack): add structured worker model routing

skills/ack/references/closed-loop.md

@@ -2,8 +2,8 @@
 
 本文件定义**与具体编排工具无关**的三角色协作闭环。运行时调度可以用 Orca（见 `orca-adapter.md`），也可以手动跑（见下方「手动模式」）。
 
-原则：调度消息只是运行时载体，任务结论必须回写到 `tasks.yaml`；跨任务复用、已经
-验证的项目经验必须由 Coordinator 回写到 `knowledge.yaml`。不要把消息当最终记录。
+原则：调度消息只是运行时载体，任务结论必须回写到 `tasks.yaml`；已经验证且可跨
+任务使用的项目经验必须由 Coordinator 回写到 `knowledge.yaml`。不要把消息当最终记录。
 角色定义见 `roles-and-permissions.md`：Coordinator 只编排、Test 只验证、
 Developer 只实现。
 
@@ -34,10 +34,13 @@ Coordinator 发现或读取 open 任务
   -> 从 knowledge.yaml 按 scope 推荐 active 知识，Coordinator 确认固定 revision 的 knowledgeRefs
   -> 为新轮次生成稳定 attemptId（<task-id>-A<round>），Developer 与 Test 共用
   -> 决定 worktree：当前 worktree 起子 agent，还是新建隔离 worktree（见下节「子任务放哪」）
-  -> 解析 worker：先复用同 worktree、同角色的空闲 worker；没有可复用项时才校验命令并新建（见 orca-adapter.md）
+  -> 解析安全 profile：机器配置只读 tasks.yaml.project.orchestration
+  -> 运行 launcher plan 并审阅 launchFingerprint
+  -> 带 expected fingerprint 启动 fresh worker，把 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
   -> dispatch 给 Test（retesting）
   -> wait：Test 的 retest_result（含 knowledgeChecks 和 candidate 独立证据）
   -> Test 通过：gate（Coordinator 读证据对齐意图）
@@ -48,7 +51,9 @@ Coordinator 发现或读取 open 任务
 ```
 
 一次派发只修一个明确问题（细则见 `optimization-method.md` §「每轮派发只修一个明确问题」）。
-「决定 worktree」「解析 worker」两步的决策见下节与 `model-routing.md` / `orca-adapter.md`。
+「决定 worktree」「解析 profile/receipt」几步的决策见下节与 `model-routing.md` /
+`orca-adapter.md`。v0.10 不自动复用历史 receipt 或既有终端；标题、preview、分支名、
+worker 自报和无密钥 receipt checksum 都不能代替可信启动 attestation。
 Coordinator 默认给新逻辑轮次生成 `<task-id>-A<round>`，并在记录轮次结果时写入
 `tasks[].dispatch.rounds[].attemptId`。它独立于编排工具产生的 `taskId` 和
 `dispatchId`：前者用于知识来源追溯，后两者只用于查询运行时。0.9.0 之前的历史
@@ -101,23 +106,48 @@ Test 对显式引用回报 `not_applicable` 时，说明 Coordinator 的选择
 
 Coordinator 派发前先决定 Developer/Test 在哪工作。两种方式：
 
-**方式 1：当前 worktree 复用或起子 agent（终端）**
+**方式 1：当前 worktree 起 fresh 子 agent（终端）**
 
 ```bash
-# 先按 orca-adapter.md 的 worker 复用流程查找空闲终端；没有时才创建
-orca terminal create --worktree active --command "cursor-agent --yolo --model auto" --title "ACK-DEV-CURSOR-AUTO-1" --json
+# v0.10 不自动复用既有终端；先审阅 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> \
+  --profile-id <profile-id> --worktree <absolute-current-worktree> --slot <1..99>
+python3 <ack-skill-dir>/scripts/launch_worker.py launch \
+  --project-root <project-root> --task-id <task-id> \
+  --attempt-id <task-id>-A<round> --role <developer-or-test> \
+  --profile-id <profile-id> --worktree <absolute-current-worktree> --slot <1..99> \
+  --expected-launch-fingerprint <plan 中的 sha256:...>
 ```
 
 - 适合：串行闭环、一次一个 Developer 任务、小改动、Test 要复测的正是 Developer 改的那棵树。
 - 优点：单一服务实例、无跨 worktree 对齐困扰、开销小。
 - 风险：多个 agent 同时改同一棵树会互相踩（半构建状态、git 冲突）。
+- 记录：`launch` 成功后把 receipt 追加到权威 `tasks.yaml.workerReceipts`，并把
+  `receipt.id` 写入 `dispatch.<role>.receiptId`、把 `profileId` 写入
+  `dispatch.<role>.profileId`、把本轮稳定 ID 写入 `dispatch.<role>.attemptId`；
+  receipt 的 task/role/profile/attempt 必须与当前 dispatch 完全一致，不能只记录
+  一个裸 handle，也不能引用旧任务或旧轮次 receipt。
 
 **方式 2：新建隔离 worktree，再在其中起子 agent**
 
+创建成功后，先把 Orca 返回的绝对路径加入权威任务板的
+`project.orchestration.allowedWorktrees` 并重新运行 `validate_tasks.py`；未进入
+allowlist 的路径不能交给 launcher。
+
 ```bash
 orca worktree create --name <feature> --base-branch <base> --json
-# 然后先查该 worktree 的同角色空闲终端；没有时才创建
-orca terminal create --worktree path:<new> --command "cursor-agent --yolo --model auto" --title "ACK-DEV-CURSOR-AUTO-1"
+# 对返回的绝对路径调用 ACK launcher
+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> \
+  --profile-id <profile-id> --worktree <absolute-new-worktree> --slot <1..99>
+python3 <ack-skill-dir>/scripts/launch_worker.py launch \
+  --project-root <project-root> --task-id <task-id> \
+  --attempt-id <task-id>-A<round> --role <developer-or-test> \
+  --profile-id <profile-id> --worktree <absolute-new-worktree> --slot <1..99> \
+  --expected-launch-fingerprint <plan 中的 sha256:...>
 ```
 
 - 适合：并行多个互不依赖的子任务、大/高风险/实验性改动、要保持基线分支干净（如 prod 不动、feature 走独立分支）、要独立 build 或跑独立服务实例、best-of-N 尝试。
@@ -136,8 +166,13 @@ orca terminal create --worktree path:<new> --command "cursor-agent --yolo --mode
 
 **项目状态（SSOT）只落一处**：无论开几个 worktree，`tasks.yaml` 和
 `knowledge.yaml` 都只认一个权威副本（通常在基线/协调所在 worktree），由
-Coordinator 单写。不要每个 worktree 各留一份会分叉的项目状态。模型固定方式见
-`model-routing.md` 与 `orca-adapter.md`。
+Coordinator 单写。`project.orchestration`、顶层 `workerReceipts` 和任务 dispatch
+也只写入这个副本；不要每个 worktree 各留一份会分叉的项目状态。profile 解析、
+launcher 与 receipt 规则见 `model-routing.md` 和 `orca-adapter.md`。
+
+两种 worktree 方式都只允许 profile 中的 `read-only` / `workspace-write` 安全权限。
+v0.10 的 full-access 授权与撤销机制仍是 Deferred；launcher 遇到 full-access 或等价
+的 sandbox 绕过请求必须 fail closed。
 
 ---
 
@@ -158,6 +193,10 @@ Coordinator 单写。不要每个 worktree 各留一份会分叉的项目状态
 手动模式下同样遵守：worker_done / 复测报告都不等于最终结论、只有 Coordinator
 写 `tasks.yaml` 和 `knowledge.yaml`、三轮失败留档。
 
+手动交给用户已打开的会话不等于产生 ACK receipt。该会话可以完成本次显式 handoff，
+但不能因此进入 Orca 自动派发信任路径；后续自动派发仍需重新通过 ACK launcher
+创建 fresh worker。
+
 ---
 
 ## Test 复测（编排无关）