Make harness install behavior required, not just the interface #970

New issue

Closed

opened 2026-07-10 08:31:15 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-07-10 08:31:15 +00:00

Member

Problem

ward#968 made the agents API interface require an Install hook, but kept the important behavior optional by satisfying missing harness implementations with no-op methods. That preserves the failure mode ward#956 was meant to remove: an engineer can start without the harness setup behavior actually existing.

This issue is the corrected implementation scope for ward#956.

Requested behavior

Make harness install behavior part of the agents API contract, not just the Go interface shape.

Each supported harness should provide real install behavior, or explicitly declare that no install step is required because the harness is already self-contained. Empty no-op methods should not be used to satisfy the interface unless the implementation documents and proves why no action is needed.

The install path should be invoked by the agent startup path in a way that makes failures visible before the run is treated as started. Best-effort can apply to optional supporting tools, but the harness itself must either be usable afterward or fail with a clear diagnostic.

Acceptance

Codex, Claude, Goose, and OpenCode have concrete install behavior or explicit self-contained declarations backed by tests.
The agent startup path calls the install hook before launching the harness command.
A missing harness binary or failed required install produces a clear failure instead of silently continuing.
Tests cover at least one failing required install and one harness with no install needed.
ward#968's interface-only/no-op shape is not reintroduced.

Notes

This is distinct from ward#969, which is about converging the host broker's ward binary before dispatch. This issue is only about installing the engineer harness runtime inside the agent lifecycle.

## Problem ward#968 made the agents API interface require an `Install` hook, but kept the important behavior optional by satisfying missing harness implementations with no-op methods. That preserves the failure mode ward#956 was meant to remove: an engineer can start without the harness setup behavior actually existing. This issue is the corrected implementation scope for ward#956. ## Requested behavior Make harness install behavior part of the agents API contract, not just the Go interface shape. Each supported harness should provide real install behavior, or explicitly declare that no install step is required because the harness is already self-contained. Empty no-op methods should not be used to satisfy the interface unless the implementation documents and proves why no action is needed. The install path should be invoked by the agent startup path in a way that makes failures visible before the run is treated as started. Best-effort can apply to optional supporting tools, but the harness itself must either be usable afterward or fail with a clear diagnostic. ## Acceptance * Codex, Claude, Goose, and OpenCode have concrete install behavior or explicit self-contained declarations backed by tests. * The agent startup path calls the install hook before launching the harness command. * A missing harness binary or failed required install produces a clear failure instead of silently continuing. * Tests cover at least one failing required install and one harness with no install needed. * ward#968's interface-only/no-op shape is not reintroduced. ## Notes This is distinct from ward#969, which is about converging the host broker's ward binary before dispatch. This issue is only about installing the engineer harness runtime inside the agent lifecycle.

coilyco-ops commented

2026-07-10 08:31:26 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-ward-970 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-10T08:31:25Z). 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/ward#970 · branch issue-970 · harness codex · workflow pull-requests
Run: engineer-codex-ward-970 · ward v0.555.0 · dispatched 2026-07-10T08:31:25Z
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.555.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-970` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T08:31:25Z). 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/ward#970` · branch `issue-970` · harness `codex` · workflow `pull-requests` - **Run:** `engineer-codex-ward-970` · ward `v0.555.0` · dispatched `2026-07-10T08:31:25Z` - **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.555.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a pull request that will close it,

2026-07-10 08:49:00 +00:00

fix(agent): require harness install #973