Complete the native Grok (xAI) path so grok-build-0.1 runs as a real
RoboCo agent, not just the provider seam.
- roboco-agent-grok image (docker/agent-grok.Dockerfile): FROM agent-base
+ opencode (the OpenAI-protocol runtime). One image serves every role;
role behaviour comes from the mounted manifest / mcp-config / system
prompt, exactly as on the Claude path.
- Entrypoint renders opencode.json at spawn from the GrokProvider env
contract + the mounted Claude Code mcp-config.json
(roboco.llm.providers.opencode_config): translates RoboCo's gateway
servers (roboco-flow / roboco-do / ...) into opencode's mcp block,
declares the xAI OpenAI-compatible provider + model, and wires
permissions + instructions. Pure, unit-tested translation.
- Orchestrator registers GrokProvider with the registry-qualified image
(_qualify_agent_image) so it resolves in local and registry deploys.
- Compose (both files + the registry compose) gain an agent-grok-image
builder service.
- Panel: a Grok (xAI) API key card on the AI Providers page, plus the
grok ModelProvider value.
KNOWN PARITY GAP (opencode runtime): the bash-guard PAT-scrub and the
transcript-based usage/cost capture are Claude Code hooks and do not
transfer to opencode. bash permission is operator-tunable
(ROBOCO_GROK_BASH_PERMISSION) so a deployment can fail closed until a
security/usage-parity opencode plugin lands. That plugin and live E2E
validation are the remaining work to finalize with xAI.
All three compose files must carry the same app env; the registry one had
external-PR but was missing the self-heal block. Add it (identical to the build
compose) so docker-compose.yml / .yaml / .registry.yml agree — the registry
file still differs only in image source (registry pulls) and host-env paths.
The build compose got ROBOCO_EXTERNAL_PR_ENABLED (default true) but the
registry compose's orchestrator env was missed, so a pull-based deploy would
have defaulted it off — inconsistent. Add the same external-PR block so both
deploy paths behave identically.
pr-reviewer-1 was the one agent with no dedicated image and no compose
builder service — it reused roboco-agent-base, which left it absent from the
compose files entirely (so it looked like the PR reviewer simply was not
there). Make it first-class for parity: add docker/agent-pr-reviewer.Dockerfile
(FROM the base — read-only reviewer, no extra toolchain), an
agent-pr-reviewer-image builder service in both compose files and the registry
compose, the image in the release workflow's publish list, and map
pr-reviewer-1 -> roboco-agent-pr-reviewer in the orchestrator plus its
lazy-build dockerfile map. Supersedes the earlier base-reuse mapping.
The orchestrator spawned agents only by bare image names and built any
missing image from source on the host, so a deployment had to carry the
build context and a toolchain — there was no way to just pull and run the
images the release workflow publishes.
Add two settings (default empty = unchanged local-build behavior):
ROBOCO_AGENT_IMAGE_REGISTRY and ROBOCO_AGENT_IMAGE_TAG. When a registry is
set, the orchestrator spawns and ensures {registry}/roboco-agent-*[:tag] and
pulls (never builds) any image it lacks. Also adds the previously-missing
agent-secretary image to the lazy-build map.
Ship docker-compose.registry.yml: a standalone compose that pulls every
published image (GHCR or Docker Hub, pinnable version) and wires the
orchestrator to spawn the matching pre-built agent images. The existing
build compose files are unchanged.
Renn F