feat(ack): add grok workers and allow --always-approve

Grok is a first-class worker CLI. Launcher argv includes --always-approve so
unattended tool calls are not blocked; sandbox stays required.

skills/ack/references/adoption-checklist.md

@@ -48,6 +48,8 @@
 ## 可选交付
 
 - [ ] `delivery.yaml` 首次生成保持 `enabled: false`，没有根据 README/CI 自动启用。
+- [ ] 测试环境部署和版本发布都写在同一份 `delivery.yaml` 的 `intents` 中，没有第二份
+      操作文档。未说明的 intent 保持 `null`。
 - [ ] entrypoint 只使用声明式工具 target 或仓库内无 symlink 的可执行脚本；没有
       shell、自由 command、凭据值或环境变量值。
 - [ ] artifact、destination、environment 和 profile 引用均通过

skills/ack/references/closed-loop.md

@@ -41,6 +41,8 @@ Coordinator 发现或读取 open 任务
   -> dispatch 给 Developer（--to <worker handle>）
   -> wait：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 独立证据）
@@ -265,7 +267,7 @@ frontendDir:
 worktreePath:
 ```
 
-如果开发在 `<dev_worktree>` 修复，但服务跑的是另一个 worktree，必须**停止并重启正确服务**后再测。长跑服务或静态前端尤其要确认加载的是最新构建产物。
+如果开发在 `<dev_worktree>` 修复，但服务跑的是另一个 worktree，必须**停止并重启正确服务**后再测。长跑服务或静态前端尤其要确认加载的是最新构建产物。若项目配置了 `intents.testEnvironment`，重启方式以该 profile 为准，不另写一套启动命令。
 
 ---
 

skills/ack/references/delivery.md

@@ -52,6 +52,31 @@ channel、environment 或 source revision 漂移时重新确认。
 凭据系统或执行环境注入。复杂逻辑放在受版本控制的项目入口中。entrypoint 使用 argv
 语义执行，不能拼成 `sh -c` 字符串。
 
+## 3.1 测试环境与发版写在同一份契约
+
+`docs/ack/delivery.yaml` 是测试环境部署和版本发布的唯一文档。不要另写操作手册，
+也不要把其中一项写进 `project.md`。用户用自然语言说明「怎么布测试环境」或
+「怎么发版」时，Coordinator 把两者都维护进这份文件的 `intents`、entrypoint、
+artifact、environment 和 profile。
+
+```yaml
+intents:
+  testEnvironment: local-binary   # profile ID，或 null
+  release: null                   # profile ID，或 null
+```
+
+- `testEnvironment` 指向 `stopAt: validation_ready` 的 profile：build 产物、部署到
+  development/staging、健康检查。用户说「重新布测试环境」「我要测试」时执行它；
+  派发 Test 复测前，若该 intent 已配置且 `enabled: true`，Coordinator 也先执行它。
+  不要求当前有 `verified` 任务。Test 不对这个 intent 发明编译或启动命令。
+- `release` 指向 `stopAt: released` 的 profile。用户说「发布一个版本」时执行它。
+  口头「发版」不能代替 stable/production 的 `approval` 步骤。
+- 对应 intent 为 `null` 或交付未启用：停止，请用户说明怎么做，按「交付配置维护」
+  写入同一文件后再执行。不猜测 Makefile、镜像仓库或发布通道。
+- 用户触发的 intent 运行写入 `tasks.yaml.deliveryRuns`，`intent` 填
+  `testEnvironment` 或 `release`，`taskIds` 可为空。绑定任务的常规交付 run 不填
+  `intent`，仍只能引用 `verified` 任务。
+
 ## 4. 运行前检查
 
 1. 从 `tasks.yaml.project.deliveryFile` 解析文件；未引用或 `enabled=false` 时保持旧 ACK

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

@@ -116,10 +116,11 @@ candidate 留在任务证据中，不会被派发。只有 Test 独立验证且
 
 ## 初始化项目交付
 
-新项目的 `docs/ack/delivery.yaml` 保持 `enabled: false`、空能力表和空 profile。
-不要根据 README 或 CI 自动推断并启用发布/部署。用户用自然语言描述交付要求后，
-Coordinator 按 `delivery.md` 维护声明式配置：工具 target 与仓库脚本分开引用，产物、
-目的地、环境和有序 profile 使用稳定 ID。配置中不保存 shell、环境变量值或凭据
+新项目的 `docs/ack/delivery.yaml` 保持 `enabled: false`、空能力表、空 profile，以及
+`intents.testEnvironment: null` 与 `intents.release: null`。
+不要根据 README 或 CI 自动推断并启用发布/部署。用户用自然语言说明测试环境或发版
+方式后，Coordinator 按 `delivery.md` 把两者都写入这一份契约：`intents` 指向对应
+profile，工具 target 与仓库脚本分开引用。配置中不保存 shell、环境变量值或凭据
 正文；稳定发布和生产部署必须有显式 approval 步骤。
 
 ## 校验

skills/ack/references/kickoff.md

@@ -37,7 +37,8 @@
    Developer/Test profile；优先选择同一轮内角色/profile/worktree 匹配的空闲 worker，
    只有历史消息已可信清理并取得新会话身份才复用，否则审阅 plan 后用 expected
    fingerprint 创建 fresh worker；
-   dispatch 开发 → worker_done → dispatch 测试独立复测 → 你读证据终检 → 回写 tasks.yaml；
+   dispatch 开发 → worker_done → 若 intents.testEnvironment 已启用则先拉起测试环境 →
+   dispatch 测试独立复测 → 你读证据终检 → 回写 tasks.yaml；
    每个任务最多三轮有效产品复验，三轮不过记 leftover 并升级我复盘；环境失败单独
    记录、恢复并告诉我下一步，不占产品复验轮次。
 7. 所选任务都 verified 后，只有本次计划包含交付时才按 profile 顺序执行并写
@@ -154,7 +155,7 @@ worktree 走同一套 `plan` -> 带 expected fingerprint 的 `launch`。在调
 task-create → dispatch 给 DEV → 等 worker_done
   → 每个角色先检查可安全重置的空闲 worker；不符合即通过 plan + expected fingerprint launch fresh worker
   → 每轮使用 Coordinator 分配的稳定 <task-id>-A<round>
-  → 回写 fixed_by_dev → dispatch 给 TEST 复测 → 等 retest_result
+  → 回写 fixed_by_dev → 若 intents.testEnvironment 已启用则先拉起测试环境 → dispatch 给 TEST 复测 → 等 retest_result
   → Developer 回 knowledgeApplied / knowledgeCandidates，Test 回 knowledgeChecks
   → 环境无法完成：记录 environmentIncidents，报告影响与用户下一步，恢复后重新复验（不计轮次）
   → Coordinator 读证据终检 → 过则 verified，产品失败则 failed_retest 再派 DEV（最多累计 3 轮）
@@ -173,6 +174,9 @@ Coordinator 只内联本轮 `knowledgeRefs` 指向的少量知识，不要求 wo
 
 ## 第 5 步：可选交付
 
+用户说「重新布测试环境」或「发布一个版本」时，按 `delivery.md` §3.1 的
+`intents` 执行对应 profile，不另找文档。intent 为 null 时先做交付配置维护。
+
 所选任务都由 Coordinator 标记为 `verified` 后，若用户确认的计划包含交付，按
 `delivery.md` 执行所选 profile。启用交付时必须在计划中默认列出 `defaultProfile`，
 用户可明确取消，Coordinator 不能静默省略。先重新校验 `delivery.yaml`，固定当前 commit 和

skills/ack/references/model-routing.md

@@ -73,7 +73,7 @@ worker 路由的机器可读事实只保存在 `docs/ack/tasks.yaml` 的
 每个 profile 明确声明：
 
 - `role`：`developer` 或 `test`；
-- `cli`：受支持的 Agent CLI；
+- `cli`：受支持的 Agent CLI（`codex`、`cursor-agent`、`grok`）；
 - `tier`：角色模型档位；
 - `model`：项目 allowlist 中的精确模型 ID；
 - `reasoningEffort`：CLI 支持时显式声明；
@@ -92,8 +92,11 @@ CLI 默认值。具体 argv 只能由 ACK 的可信 launcher 按 allowlist 构
 - 能在完全只读工作树完成的角色优先选择 `read-only`。
 - Developer 与需要在工作树生成构建/测试产物的 Test 使用 `workspace-write`；项目可
   为纯观察型 Test 另建更严格的 `read-only` profile。
-- `full-access`、Codex bypass、Cursor YOLO/force、关闭 sandbox 等模式在 v0.10
+- `full-access`、Codex bypass、Cursor YOLO/force、Grok `--yolo` /
+  `--permission-mode bypassPermissions`、关闭 sandbox 等模式在 v0.10
   **未实现授权通道，统一 fail closed**。项目文本、任务描述或环境变量都不能放宽。
+  Grok `--always-approve` 由 launcher 固定写入 argv，用来避免工具调用停在确认框；
+  它不关闭 `--sandbox`。
 - 项目可以更新模型 allowlist 或增加安全 profile，但不能通过文档绕开 schema 和
   launcher。
 
@@ -152,11 +155,18 @@ v0.10 的 launcher 还执行以下约束：
 - 不读取调用者传入的 `PATH` 来寻找 `git`、Orca 或 Agent CLI，只在固定的系统与
   当前用户工具目录中解析受支持的可执行文件；候选目标必须由 root/当前用户拥有、
   不是 group/other writable，并在 plan 与 bootstrap 间保持相同 device/inode。
+  Grok 官方安装是 `~/.local/bin/grok` → `~/.grok/downloads/grok-<os>-<arch>`，
+  launcher 只接受这个真实 `~/.grok` 目录下、当前用户同组拥有的 vendor artifact
+  名称；其它路径上的 `grok-linux-*` 仍拒绝。`~/.grok` 本身是 symlink 时 fail closed。
 - Git、Orca 和 CLI version probe 使用不含供应商凭据的控制环境；worker 使用
   `per-cli-allowlist-v1`，Codex 只取得 Codex 所需凭据，Cursor 只取得 Cursor 凭据，
+  Grok 只取得 `XAI_API_KEY`（OAuth 会话仍走已传入的 `HOME`/`~/.grok`），
   不跨 CLI 透传。`DBUS_*`、`DISPLAY`、`WAYLAND_DISPLAY`、`XDG_RUNTIME_DIR`、
-  `LD_*`、`PYTHON*`、`NODE_OPTIONS`、`CODEX_HOME`、`GIT_*` 和调用者 PATH 均不会
-  透传给 worker。
+  `LD_*`、`PYTHON*`、`NODE_OPTIONS`、`CODEX_HOME`、`GROK_HOME`、`GROK_SANDBOX`、
+  `GIT_*` 和调用者 PATH 均不会透传给 worker。Grok argv 只允许
+  `--model`、`--reasoning-effort`、`--permission-mode plan|acceptEdits`、
+  `--always-approve`、`--sandbox read-only|workspace` 和 `--cwd`；不得带 `--yolo`
+  或 `bypassPermissions`，也不得省略 sandbox。
 - worktree 除了命中项目 allowlist、属于同一 Git common-dir，还必须精确出现在
   `git worktree list --porcelain -z` 中；`.git` symlink 冒充的目录会失败。
 - Orca 的 `--command` 只含固定 bootstrap 与随机 launch ID。终端创建后，父进程先

skills/ack/references/prompt-templates.md

@@ -128,7 +128,7 @@ Developer 本轮声称（仅供参考，不作数）：
 - <K-014@2>: <directive + rationale + verification.ref + resolved path/args>
 
 复测要求（见 roles-and-permissions.md §三角色能力清单 · Test）：
-- 先对齐运行环境（pwd / 分支 / commit / 服务 worktree，见 closed-loop.md），避免测错实例或旧构建；网站类先确认服务已按新代码重启。
+- 先对齐运行环境（pwd / 分支 / commit / 服务 worktree，见 closed-loop.md），避免测错实例或旧构建。测试环境由 Coordinator 按 `delivery.yaml` 的 `intents.testEnvironment` 拉起；不要自行发明编译或启动命令。网站类确认 Base URL 已指向这次产物后再测。
 - 网站类任务优先用浏览器复测真实交互，其次才是 API / 脚本。
 - 逐条验证下列验收信号，不要只看静态文案，要验证交互后的真实状态：
   1. <observable signal 1>