Converge host broker ward binary before dispatch #969

New issue

Closed

opened 2026-07-10 08:29:40 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-10 08:29:40 +00:00

Member

Problem

The director can download a newer ward binary locally, but dispatch still routes through the host broker. During the 2026-07-10 reliability burn-down, the director updated its local ward to v0.569.0, while newly dispatched engineer reservation comments still reported ward v0.555.0.

That means repo-side fixes can be released without becoming active in the component that actually launches engineers. In practice, this kept old dispatch and logging behavior alive after ward#965 released.

This is distinct from harness self-install. Harness install prepares Codex, Claude, OpenCode, or their dependencies inside an engineer run. Broker binary convergence is about the ward executable that accepts the dispatch and creates the engineer container.

Requested change

Add an explicit host-broker ward binary convergence path before dispatch, or an equivalent startup guard that fails loudly when the broker is stale.

The fix should make these facts visible and enforceable:

the director-requested ward version or minimum supported version
the host broker ward version that will launch the engineer
whether the broker updated itself, reused an acceptable binary, or refused to dispatch because it is stale

Acceptance

A newly released ward fix can become active in brokered dispatch without a hidden manual host update step.
ward agent or warded output reports the effective broker ward version.
If the broker is too old to honor required dispatch semantics, dispatch fails before reserving the issue or starting a container.
The implementation does not conflate broker binary convergence with per-harness best-effort install.

## Problem The director can download a newer ward binary locally, but dispatch still routes through the host broker. During the 2026-07-10 reliability burn-down, the director updated its local ward to `v0.569.0`, while newly dispatched engineer reservation comments still reported `ward v0.555.0`. That means repo-side fixes can be released without becoming active in the component that actually launches engineers. In practice, this kept old dispatch and logging behavior alive after `ward#965` released. This is distinct from harness self-install. Harness install prepares Codex, Claude, OpenCode, or their dependencies inside an engineer run. Broker binary convergence is about the ward executable that accepts the dispatch and creates the engineer container. ## Requested change Add an explicit host-broker ward binary convergence path before dispatch, or an equivalent startup guard that fails loudly when the broker is stale. The fix should make these facts visible and enforceable: * the director-requested ward version or minimum supported version * the host broker ward version that will launch the engineer * whether the broker updated itself, reused an acceptable binary, or refused to dispatch because it is stale ## Acceptance * A newly released ward fix can become active in brokered dispatch without a hidden manual host update step. * `ward agent` or `warded` output reports the effective broker ward version. * If the broker is too old to honor required dispatch semantics, dispatch fails before reserving the issue or starting a container. * The implementation does not conflate broker binary convergence with per-harness best-effort install.

coilyco-ops commented

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

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-10T08:29:48Z). 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#969 · branch issue-969 · harness codex · workflow pull-requests
Run: engineer-codex-ward-969 · ward v0.555.0 · dispatched 2026-07-10T08:29:48Z
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-969` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T08:29:48Z). 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#969` · branch `issue-969` · harness `codex` · workflow `pull-requests` - **Run:** `engineer-codex-ward-969` · ward `v0.555.0` · dispatched `2026-07-10T08:29:48Z` - **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 commit

2026-07-10 08:42:39 +00:00

feat: carry ward version through brokered dispatch

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

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

Converge host broker ward binary before dispatch #972

coilyco-ops commented

2026-07-10 08:44:39 +00:00

Author

Member

WARD-OUTCOME: submitted

details

workflow: pull-requests; review summary: review gate skipped because --skip-preflight / --no-preflight also skips review
felt: tight and mechanical, mostly wiring the brokered launch envelope and docs
confidence: high
surprise: the full repo test suite is gated by WARD_CONFIG_REF here, so I used focused broker tests and pre-commit instead
follow-ups: none

WARD-OUTCOME: submitted <details><summary>details</summary> workflow: pull-requests; review summary: review gate skipped because --skip-preflight / --no-preflight also skips review felt: tight and mechanical, mostly wiring the brokered launch envelope and docs confidence: high surprise: the full repo test suite is gated by WARD_CONFIG_REF here, so I used focused broker tests and pre-commit instead follow-ups: none </details>