coilyco-flight-deck/ward

Fork 0

Preserve WARD_CONFIG_REF in read-only director surfaces #971

New issue

Closed

opened 2026-07-10 08:42:42 +00:00 by coilyco-ops · 3 comments

coilyco-ops commented

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

Member

A read-only Codex director surface for coilyco-flight-deck/agentic-os came up without an active coilyco WARD_CONFIG_REF, so in-container warded could not dispatch sibling engineers until the agent manually supplied a repo ref.

Observed during Forgejo performance triage on 2026-07-10:

warded engineer #419 --harness codex ... failed with:
WARD_CONFIG_REF: active config source is baked neutral default (no external config source active); expected WARD_CONFIG_REF to point at the coilyco bundle for target coilyco-flight-deck/agentic-os
warded list failed the same way.
The container env included WARD_READONLY=1, WARD_ROLE=director, WARD_TARGET_REPO=coilyco-flight-deck/agentic-os, and other ward metadata, but no WARD_CONFIG_REF.
A filesystem override did not work, as expected: WARD_CONFIG_REF=/workspace/agentic-os/.ward was rejected because ward expects <host>/<owner>/<repo>[@<ref>]//<subpath>.
Supplying the current target commit manually worked:
WARD_CONFIG_REF="forgejo.coilysiren.me/coilyco-flight-deck/agentic-os@$(git rev-parse HEAD)//.ward" warded engineer '#419' ...
With that manual override, the dispatch broker accepted the engineer run.

Why this matters:

The read-only director doctrine requires capture-and-dispatch. A director surface that can file issues but cannot run warded without manual WARD_CONFIG_REF repair violates that workflow and makes every sibling dispatch look broken until the agent knows the override trick.

Expected behavior:

Director surfaces should enter with the same resolved coilyco config ref that ward expects for the target repo, or warded should be able to recover it from the target repo metadata/config already present in the surface.

Tracking context:

This was encountered while responding to coilysiren/inbox#188 and while filing/dispatching coilyco-flight-deck/agentic-os#419.

A read-only Codex director surface for `coilyco-flight-deck/agentic-os` came up without an active coilyco `WARD_CONFIG_REF`, so in-container `warded` could not dispatch sibling engineers until the agent manually supplied a repo ref. Observed during Forgejo performance triage on 2026-07-10: * `warded engineer #419 --harness codex ...` failed with: `WARD_CONFIG_REF: active config source is baked neutral default (no external config source active); expected WARD_CONFIG_REF to point at the coilyco bundle for target coilyco-flight-deck/agentic-os` * `warded list` failed the same way. * The container env included `WARD_READONLY=1`, `WARD_ROLE=director`, `WARD_TARGET_REPO=coilyco-flight-deck/agentic-os`, and other ward metadata, but no `WARD_CONFIG_REF`. * A filesystem override did not work, as expected: `WARD_CONFIG_REF=/workspace/agentic-os/.ward` was rejected because ward expects `<host>/<owner>/<repo>[@<ref>]//<subpath>`. * Supplying the current target commit manually worked: `WARD_CONFIG_REF="forgejo.coilysiren.me/coilyco-flight-deck/agentic-os@$(git rev-parse HEAD)//.ward" warded engineer '#419' ...` * With that manual override, the dispatch broker accepted the engineer run. Why this matters: The read-only director doctrine requires capture-and-dispatch. A director surface that can file issues but cannot run `warded` without manual `WARD_CONFIG_REF` repair violates that workflow and makes every sibling dispatch look broken until the agent knows the override trick. Expected behavior: Director surfaces should enter with the same resolved coilyco config ref that ward expects for the target repo, or `warded` should be able to recover it from the target repo metadata/config already present in the surface. Tracking context: This was encountered while responding to `coilysiren/inbox#188` and while filing/dispatching `coilyco-flight-deck/agentic-os#419`.

coilyco-ops commented

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

Author

Member

WARD-DISPATCH: failed ❌

failure details

This forwarded dispatch failed after the issue was already reserved.

Attempted harness: codex
Attempted run: ward agent engineer coilyco-flight-deck/ward#971 --harness codex --details Fix the director-surface WARD_CONFIG_REF propagation bug. Reproduce from ward#971: read-only director containers can have WARD_TARGET_REPO metadata but no WARD_CONFIG_REF, causing in-container warded dispatch/list to fail with the baked neutral default. Preserve or reconstruct the resolved config ref for director surfaces so capture-and-dispatch works without manual env override.
Container: engineer-codex-ward-971
Container created: no running engineer was observed.
Host log: /Users/kai/.ward/agent-logs/dispatch/20260710T084251Z-director-codex-zv99-coilyco-flight-deck-ward-971.log
Failure: ward container: download Go bootstrap binary https://forgejo.coilysiren.me/coilyco-flight-deck/ward/releases/download/v0.570.0/ward-linux-arm64: unexpected status 404 Not Found: Not Found

Retry: choose another harness if the first one is down, or rerun with --force if the reservation is stale.

— Codex, via ward agent

WARD-DISPATCH: failed ❌ <details><summary>failure details</summary> This forwarded dispatch failed after the issue was already reserved. Attempted harness: `codex` Attempted run: `ward agent engineer coilyco-flight-deck/ward#971 --harness codex --details Fix the director-surface WARD_CONFIG_REF propagation bug. Reproduce from ward#971: read-only director containers can have WARD_TARGET_REPO metadata but no WARD_CONFIG_REF, causing in-container warded dispatch/list to fail with the baked neutral default. Preserve or reconstruct the resolved config ref for director surfaces so capture-and-dispatch works without manual env override.` Container: `engineer-codex-ward-971` Container created: no running engineer was observed. Host log: `/Users/kai/.ward/agent-logs/dispatch/20260710T084251Z-director-codex-zv99-coilyco-flight-deck-ward-971.log` Failure: `ward container: download Go bootstrap binary https://forgejo.coilysiren.me/coilyco-flight-deck/ward/releases/download/v0.570.0/ward-linux-arm64: unexpected status 404 Not Found: Not Found` Retry: choose another harness if the first one is down, or rerun with `--force` if the reservation is stale. </details>  — Codex, via `ward agent`

coilyco-ops commented

2026-07-10 08:56:32 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-10T08:56:31Z). 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#971 · branch issue-971 · harness codex · workflow pull-requests-and-merge
Run: engineer-codex-ward-971 · ward v0.569.0 · dispatched 2026-07-10T08:56:31Z
Comment thread: 1 included in the pre-flight read, 0 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-10T08:42:54Z)

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

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-971` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T08:56:31Z). 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#971` · branch `issue-971` · harness `codex` · workflow `pull-requests-and-merge` - **Run:** `engineer-codex-ward-971` · ward `v0.569.0` · dispatched `2026-07-10T08:56:31Z` - **Comment thread:** 1 included in the pre-flight read, 0 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-10T08:42:54Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.569.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops added the

consult

labels

2026-07-10 09:00:30 +00:00

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

2026-07-10 09:10:59 +00:00

Preserve WARD_CONFIG_REF in read-only director surfaces #981

coilyco-ops closed this issue

2026-07-10 09:12:17 +00:00

coilyco-ops commented

2026-07-10 09:12:50 +00:00

Author

Member

WARD-OUTCOME: merge-ready

details

workflow: pull-requests-and-merge; review summary: skipped (review gate skipped by ~/.ward/config.yaml default)
felt: straightforward once the config-ref fallback was narrowed to the read-only surface lane.
confidence: high
surprises: the host ward exec path also needed the fallback to stay read-only-gated, and the helper had to use the canonical host form.
follow-ups: none

WARD-OUTCOME: merge-ready <details><summary>details</summary> workflow: pull-requests-and-merge; review summary: skipped (review gate skipped by ~/.ward/config.yaml default) felt: straightforward once the config-ref fallback was narrowed to the read-only surface lane. confidence: high surprises: the host `ward exec` path also needed the fallback to stay read-only-gated, and the helper had to use the canonical host form. follow-ups: none </details>