47 lines
4.0 KiB
Markdown
47 lines
4.0 KiB
Markdown
# ACK OMP Worker 支持规格
|
|
|
|
## 目标
|
|
|
|
让 ACK 的 Developer/Test worker 可以通过当前 Oh My Pi（OMP）CLI 工作，同时保留现有的角色路由、模型 allowlist、审批模式、worktree 和 receipt 校验边界。
|
|
|
|
## 范围
|
|
|
|
1. ACK worker CLI allowlist 增加 `omp`，不增加 `opencode`。
|
|
2. 增加 OMP 的模型 allowlist 与 role/profile 配置能力；模型使用 OMP 要求的精确 `provider/model` 选择器，例如 `opencode-go/gpt-5.6-luna`，不从当前 Coordinator 会话自动推断。
|
|
3. launcher 在固定可信目录中解析 `omp`，探测并记录版本，生成确定性的启动 argv，并把 CLI、模型、thinking、审批模式、worktree 和版本纳入 fingerprint/receipt。
|
|
4. OMP worker 使用交互式 `omp` 命令，通过结构化参数指定模型、thinking、approval mode 和工作目录；Orca 仍负责 terminal orchestration 与任务 dispatch。
|
|
5. OMP profile 不允许写入自由 command、额外 argv、shell、环境变量或凭据值；不使用 `--auto-approve`、`--plan-yolo` 或会话复用；`--approval-mode yolo` 是 OMP workspace-write worker 的默认审批模式，规则层直接允许。
|
|
6. 为 OMP 增加 profile 校验、argv 渲染、环境凭据隔离、可信 executable 解析和 launcher plan 的白盒/黑盒测试。
|
|
7. 保持 Codex、Cursor、Grok 既有行为不变；不修改 ACK 的三角色职责或 delivery 流程。
|
|
|
|
## 非目标
|
|
|
|
- 不把 OMP 替换为新的编排后端；Orca 仍是 ACK 的 terminal orchestration backend。
|
|
- 不支持 OpenCode CLI；本需求只支持 `omp` 可执行文件。
|
|
- 不根据当前 Coordinator 的 provider、模型或环境变量自动选择 worker profile。
|
|
- 不实现 OMP ACP 协议；本轮使用 OMP 的交互式 CLI 入口。
|
|
- 不读取、写入或提交真实 OMP 凭据。
|
|
|
|
## 约束与关键假设
|
|
|
|
- `omp` 可执行文件必须通过 ACK 固定可信目录解析，不能从调用者 PATH 任意拾取。
|
|
- OMP 模型 ID 必须由项目 allowlist 明确声明；当前会话中的 `opencode-go/gpt-5.6-luna` 只有在 profile 明确配置后才可使用。
|
|
- 审批模式由 launcher 固定构造：`workspace-write` → `--approval-mode yolo`、`read-only` → `--approval-mode always-ask`。
|
|
- `workspace-write` 下的 exec 工具是否会因 OMP 审批提示阻塞，由独立 Test 在黑盒环境中验证；若阻塞，必须记录为环境/运行模式问题，不伪报成功。
|
|
|
|
## 可观测验收标准
|
|
|
|
1. `validate_orchestration` 接受合法 `omp` profile，拒绝未知 CLI、未在 `omp/role/tier` allowlist 中的模型、Test strong profile 和危险权限模式。
|
|
2. `render_worker_argv` 对 OMP 只生成固定的 `omp --model {provider/model} --thinking {level} --approval-mode {mode} --cwd {absolute-worktree} --no-session` 形状，并拒绝危险或会话复用参数。
|
|
3. `resolve_executable`/launcher plan 能在可信 OMP 安装下记录 `cli: omp`、版本、精确 argv、环境策略和 worktree identity；非可信同名 executable fail closed。
|
|
4. OMP worker 环境只获得基础运行时变量、代理/证书变量和明确允许的 OMP/provider credential 名称，不继承调用者的任意环境变量、PATH 或其它 CLI 凭据。
|
|
5. 现有 Codex/Cursor/Grok profile 的 argv、allowlist、权限拒绝和 receipt 校验回归测试继续通过。
|
|
6. 在独立临时项目和隔离 OMP 配置目录中，Test 能确认 fresh OMP worker 被正确绑定到指定 worktree，能接收 Orca dispatch 的任务输入，并能回报 ACK lifecycle 证据；无法完成时记录具体协议/环境证据。
|
|
7. 文档明确：OMP 是 worker CLI，Orca 是编排层；两者都不自行决定模型，模型由 `tasks.yaml.project.orchestration` profile 决定。
|
|
|
|
## 建议任务拆分
|
|
|
|
- `ACK-OMP-001`：扩展 ACK worker profile、launcher 与安全环境策略，支持 OMP interactive worker。
|
|
- `ACK-OMP-002`：补充 OMP profile/argv/launcher 白盒测试与既有 CLI 回归测试。
|
|
- `ACK-OMP-003`：在隔离临时环境完成 OMP worker 的 Orca dispatch 黑盒复测并记录证据。
|