Bake opencode into the dev-base image for ward engineers #342

New issue

Closed

opened 2026-07-08 20:55:27 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-08 20:55:27 +00:00

Member

Goal

Bake the opencode binary into the aos dev-base image so ward's OpenCode engineer harness is available in containers.

Context

This came out of coilyco-flight-deck/ward#692. ward correctly exposes --harness opencode and the engineer container writes OpenCode config, but the image does not contain the opencode binary:

ward-container: wrote qwen-backed opencode config (model ollama/qwen3-coder:30b via http://localhost:11434/v1) to /home/ubuntu/.config/opencode/opencode.json
ward-container: ready: coilyco-flight-deck/ward on issue-691 [mode=opencode]
ward-container: selected agent binary "opencode" is not present in this image; dropping to a shell (reaper runs on exit)

A later Goose postmortem also pointed at the same root cause: ward was mounted as the target repo, but the missing binary belongs to the base image authored in aos.

Do

Inspect docker/dev-base/Dockerfile and the existing agent CLI install pattern.
Add a pinned/installable opencode binary to the dev-base image, using the repo's existing conventions for CLI installation and architecture handling.
Verify opencode lands on PATH as /usr/local/bin/opencode or the existing image convention.
Avoid runtime installation during engineer startup if the image is supposed to carry the binary.
Update docs or image inventory if the dev-base image documents included agent harnesses.

Validate

The dev-base build path succeeds.
A container based on the rebuilt image can run opencode --help or the equivalent version/help command.
ward's --harness opencode no longer fails at binary lookup once the image is published.

coilyco-flight-deck/ward#692 tracks the ward-side symptom/preflight behavior.
coilyco-flight-deck/ward#697 tracks Goose answering in logs instead of carrying the issue.
coilyco-flight-deck/ward#689 tracks stale reservations when launch failures do not comment back.

Filed from the read-only director surface after Kai identified that the engineer was mounted on ward, but the root cause is in aos.

## Goal Bake the `opencode` binary into the aos dev-base image so ward's OpenCode engineer harness is available in containers. ## Context This came out of coilyco-flight-deck/ward#692. ward correctly exposes `--harness opencode` and the engineer container writes OpenCode config, but the image does not contain the `opencode` binary: ```text ward-container: wrote qwen-backed opencode config (model ollama/qwen3-coder:30b via http://localhost:11434/v1) to /home/ubuntu/.config/opencode/opencode.json ward-container: ready: coilyco-flight-deck/ward on issue-691 [mode=opencode] ward-container: selected agent binary "opencode" is not present in this image; dropping to a shell (reaper runs on exit) ``` A later Goose postmortem also pointed at the same root cause: ward was mounted as the target repo, but the missing binary belongs to the base image authored in aos. ## Do * Inspect `docker/dev-base/Dockerfile` and the existing agent CLI install pattern. * Add a pinned/installable `opencode` binary to the dev-base image, using the repo's existing conventions for CLI installation and architecture handling. * Verify `opencode` lands on `PATH` as `/usr/local/bin/opencode` or the existing image convention. * Avoid runtime installation during engineer startup if the image is supposed to carry the binary. * Update docs or image inventory if the dev-base image documents included agent harnesses. ## Validate * The dev-base build path succeeds. * A container based on the rebuilt image can run `opencode --help` or the equivalent version/help command. * ward's `--harness opencode` no longer fails at binary lookup once the image is published. ## Related * coilyco-flight-deck/ward#692 tracks the ward-side symptom/preflight behavior. * coilyco-flight-deck/ward#697 tracks Goose answering in logs instead of carrying the issue. * coilyco-flight-deck/ward#689 tracks stale reservations when launch failures do not comment back. Filed from the read-only director surface after Kai identified that the engineer was mounted on ward, but the root cause is in aos.

coilyco-ops added the

headless

labels

2026-07-09 06:38:30 +00:00

coilyco-ops commented

2026-07-09 21:33:18 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-agentic-os-342 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-09T21:33:15Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h TTL). --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

run seed context — what this run is carrying (ward#609)

Resolved: coilyco-flight-deck/agentic-os#342 · branch issue-342 · harness codex · workflow direct-to-main
Run: engineer-codex-agentic-os-342 · ward v0.493.0 · dispatched 2026-07-09T21:33:15Z
Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.493.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-agentic-os-342` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-09T21:33:15Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (1h TTL). `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh**. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-flight-deck/agentic-os#342` · branch `issue-342` · harness `codex` · workflow `direct-to-main` - **Run:** `engineer-codex-agentic-os-342` · ward `v0.493.0` · dispatched `2026-07-09T21:33:15Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.493.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-09 21:45:52 +00:00

feat: bake opencode into dev-base image

coilyco-ops closed this issue

2026-07-09 21:45:53 +00:00

coilyco-ops commented

2026-07-09 21:46:02 +00:00

Author

Member

WARD-OUTCOME: done ✅

details

workflow: direct-to-main; review summary: skipped by ~/.ward/config.yaml default
felt: straightforward, but container disk pressure and pre-commit cache churn made the land take longer than the code change itself
confidence: high
surprises: origin/main moved during landing, so the branch was merged into fresh upstream before push
follow-ups: none

WARD-OUTCOME: done ✅ <details><summary>details</summary> workflow: direct-to-main; review summary: skipped by ~/.ward/config.yaml default felt: straightforward, but container disk pressure and pre-commit cache churn made the land take longer than the code change itself confidence: high surprises: origin/main moved during landing, so the branch was merged into fresh upstream before push follow-ups: none </details>