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.
This commit is contained in:
+36
-16
@@ -9,8 +9,9 @@ ACK 是一个显式调用的 Agent Skill，用三种独立角色运行工程协
|
||||
关键约束是验证者不等于实现者。每个任务最多修复三轮，仍未通过时记录为
|
||||
`leftover`，然后继续处理其它任务。
|
||||
|
||||
项目还可以声明一个可选的交付阶段：任务全部验证后，ACK 按项目维护的 profile
|
||||
构建 DEB 或镜像、发布产物、创建 PR，并在授权范围内部署。交付配置默认关闭，
|
||||
项目还可以在同一份 `docs/ack/delivery.yaml` 里声明测试环境部署和版本发布。
|
||||
用户告诉 ACK 这两件事怎么做之后，再说「重新布测试环境」或「发布一个版本」，
|
||||
ACK 按对应 intent 执行。任务全部验证后仍可按 profile 做常规交付。配置默认关闭，
|
||||
稳定发布与生产部署始终保留人工批准点。
|
||||
|
||||
## 安装
|
||||
@@ -70,8 +71,8 @@ skills/ack/
|
||||
`docs/ack/project.md` 只保存当前项目的命令、路径和权限差异；
|
||||
`docs/ack/tasks.yaml` 保存当前任务状态；`docs/ack/knowledge.yaml` 保存跨任务复用、
|
||||
已经独立验证的项目知识护栏。
|
||||
`docs/ack/delivery.yaml` 声明项目特有的构建、发布和部署能力；每次执行结果另记在
|
||||
`tasks.yaml.deliveryRuns`，配置与运行状态不会混在一起。
|
||||
`docs/ack/delivery.yaml` 是测试环境部署和版本发布的唯一契约，也声明常规构建、
|
||||
发布和部署能力；每次执行结果另记在 `tasks.yaml.deliveryRuns`。
|
||||
|
||||
## 检查项目状态
|
||||
|
||||
@@ -139,16 +140,29 @@ python3 <ack-skill-dir>/scripts/run_verification.py \
|
||||
|
||||
## 配置与运行交付
|
||||
|
||||
用户可以直接向 `/ack` 描述项目差异，例如“这个项目用 `make deb` 构建 DEB，推到
|
||||
preview APT 源，再部署到开发机”。ACK 会把它维护成
|
||||
`docs/ack/delivery.yaml` 中的声明式 entrypoint、artifact、destination、environment
|
||||
和 profile，校验后展示 diff；首次配置保持关闭，确认后才启用。
|
||||
用户可以直接向 `/ack` 说明两件独立操作，并写进同一份契约：
|
||||
|
||||
```text
|
||||
/ack 测试时先 go build -o garden ./cmd/garden，再启动这个二进制；
|
||||
发版方式以后再告诉你。
|
||||
```
|
||||
|
||||
ACK 把它维护成 `docs/ack/delivery.yaml` 的 `intents.testEnvironment` /
|
||||
`intents.release`、entrypoint、artifact、environment 和 profile。首次配置保持
|
||||
关闭，确认后才启用。之后用户可以说：
|
||||
|
||||
```text
|
||||
/ack 重新布一下测试环境，我要测试
|
||||
/ack 发布一个版本
|
||||
```
|
||||
|
||||
对应 intent 未配置时先问清楚并写回同一文件，不猜测。intent 运行不要求当前有
|
||||
`verified` 任务；`deliveryRuns.intent` 记录是测试环境还是发版。
|
||||
|
||||
交付配置只允许声明式工具 target 或仓库内可执行脚本，不接受自由 shell，也不保存
|
||||
凭据值。ACK 在任务进入 `verified` 后，按用户确认的 profile 执行，并把 revision、
|
||||
PR、产物摘要、部署目标、健康检查和日志引用写入 `tasks.yaml.deliveryRuns`。默认
|
||||
profile 只能停在 `review_ready`；稳定发布或生产部署必须经过对应 approval 步骤。
|
||||
具体契约见 `references/delivery.md`。
|
||||
凭据值。任务进入 `verified` 后的常规交付仍按确认过的 profile 执行。默认
|
||||
profile 只能停在 `validation_ready` 或 `review_ready`；稳定发布或生产部署必须经过
|
||||
对应 approval 步骤。具体契约见 `references/delivery.md`。
|
||||
|
||||
## 启动 Worker
|
||||
|
||||
@@ -191,8 +205,10 @@ identity。Coordinator 将 receipt 追加到顶层 `workerReceipts`，再把 rec
|
||||
不能跨任务或跨轮次改挂。
|
||||
|
||||
v0.10 自动 launcher 仅支持 `read-only` 与 `workspace-write`。full-access、
|
||||
Codex bypass、Cursor YOLO/force 和关闭 sandbox 都会 fail closed；在有可信平台
|
||||
审批或独立签发通道之前，不用项目文件伪装成用户授权。旧任务板没有结构化
|
||||
Codex bypass、Cursor YOLO/force、Grok `--yolo` / bypassPermissions 和关闭
|
||||
sandbox 都会 fail closed；在有可信平台审批或独立签发通道之前，不用项目文件
|
||||
伪装成用户授权。Grok worker 由 launcher 固定带 `--always-approve`，避免工具调用
|
||||
停在确认框，sandbox 仍必须启用。v0.17 起 `cli: grok` 是一等 worker CLI。旧任务板没有结构化
|
||||
`project.orchestration` 时仍可读取和手动协作，但不得自动创建 worker。
|
||||
|
||||
持久化 `receiptHash` 是无密钥 checksum，不是 launcher 身份证明。ACK 只复用同一轮
|
||||
@@ -243,5 +259,9 @@ ACK 会自动读取 `delivery.yaml`，无需再逐步提醒它构建、上传、
|
||||
`ackVersion`。从 `0.10.0` 起，`project.orchestration` 与顶层 `workerReceipts` 必须
|
||||
同时存在；从 `0.11.0` 起，新项目还会生成默认关闭的 `delivery.yaml`，并在任务板声明
|
||||
`project.deliveryFile` 与 `deliveryRuns`；从 `0.13.0` 起，Coordinator 使用
|
||||
`select_tasks.py` 获取有预算的任务上下文，不再把完整任务板注入模型。旧项目可以不迁移
|
||||
而继续使用原闭环。旧项目的 `kitVersion` 可以继续读取，但建议迁移为 `ackVersion`。
|
||||
`select_tasks.py` 获取有预算的任务上下文，不再把完整任务板注入模型；从 `0.16.0` 起，
|
||||
`delivery.yaml` 可用 `intents.testEnvironment` 与 `intents.release` 把测试环境部署和
|
||||
版本发布写成用户可单独触发的操作；从 `0.17.0` 起，结构化 worker 路由支持
|
||||
`cli: grok`（与 Codex、Cursor 并列）；从 `0.17.1` 起 Grok worker argv 固定带
|
||||
`--always-approve`，sandbox 仍必开。旧项目可以不迁移而继续使用原闭环。旧项目的
|
||||
`kitVersion` 可以继续读取，但建议迁移为 `ackVersion`。
|
||||
|
||||
Reference in New Issue
Block a user