Broker should comment failed forwarded dispatches back to the issue

coilyco-ops commented

2026-07-08 19:28:41 +00:00

Member

Bug

A director-surface dispatch can fail after the broker reports that it forwarded the run, but the broker does not comment the failure back to the issue. The issue is left looking reserved even though no useful engineer is carrying it.

Reproduction observed on 2026-07-08

From a read-only director surface, the director ran:

warded coilyco-bridge/agentic-os-kai#720

The local output was only:

ward dispatch broker: forwarded `ward agent engineer coilyco-bridge/agentic-os-kai#720 --harness claude` to host ward (run output on the host at /Users/kai/.ward/agent-logs/dispatch/20260708T192521Z-session-codex-12afd722-coilyco-bridge-agentic-os-kai-720.log)

But Claude engineers were down. The issue thread at coilyco-bridge/agentic-os-kai#720 still gained a Claude reservation comment and no failure comment. A later ward agent stop coilyco-bridge/agentic-os-kai#720 found no running engineer by issue labels; ward agent stop engineer-claude-agentic-os-kai-720 also found no running container. The director had to force a Codex rerun manually:

warded coilyco-bridge/agentic-os-kai#720 --harness codex --force

That produced a second reservation comment, this time for engineer-codex-agentic-os-kai-720.

Expected behavior

If the host-side broker or launched harness detects that a dispatch failed after reservation, ward should write a failure comment to the issue and clear or supersede the stale reservation signal. The director surface should not have to infer failure from out-of-band host logs.

At minimum, the issue thread should show:

the attempted harness and run/container name
that the dispatch failed
whether a container was ever created
the host log path if available
the recommended retry shape, such as choosing another harness or using --force when the reservation is stale

Acceptance

Reproduce a host-side harness startup failure after reservation.
Add broker/reaper/error-path handling so the issue gets a visible failure comment when dispatch does not produce a running engineer.
Avoid leaving a reservation comment as the last visible state for a failed launch.
Add regression coverage for the director-surface forwarded-dispatch path.
Validate with ward exec test.

Filed from the read-only director surface after coilyco-bridge/agentic-os-kai#720 exposed the missing failure comment.

## Bug A director-surface dispatch can fail after the broker reports that it forwarded the run, but the broker does not comment the failure back to the issue. The issue is left looking reserved even though no useful engineer is carrying it. ## Reproduction observed on 2026-07-08 From a read-only director surface, the director ran: ```text warded coilyco-bridge/agentic-os-kai#720 ``` The local output was only: ```text ward dispatch broker: forwarded `ward agent engineer coilyco-bridge/agentic-os-kai#720 --harness claude` to host ward (run output on the host at /Users/kai/.ward/agent-logs/dispatch/20260708T192521Z-session-codex-12afd722-coilyco-bridge-agentic-os-kai-720.log) ``` But Claude engineers were down. The issue thread at coilyco-bridge/agentic-os-kai#720 still gained a Claude reservation comment and no failure comment. A later `ward agent stop coilyco-bridge/agentic-os-kai#720` found no running engineer by issue labels; `ward agent stop engineer-claude-agentic-os-kai-720` also found no running container. The director had to force a Codex rerun manually: ```text warded coilyco-bridge/agentic-os-kai#720 --harness codex --force ``` That produced a second reservation comment, this time for `engineer-codex-agentic-os-kai-720`. ## Expected behavior If the host-side broker or launched harness detects that a dispatch failed after reservation, ward should write a failure comment to the issue and clear or supersede the stale reservation signal. The director surface should not have to infer failure from out-of-band host logs. At minimum, the issue thread should show: * the attempted harness and run/container name * that the dispatch failed * whether a container was ever created * the host log path if available * the recommended retry shape, such as choosing another harness or using `--force` when the reservation is stale ## Acceptance * Reproduce a host-side harness startup failure after reservation. * Add broker/reaper/error-path handling so the issue gets a visible failure comment when dispatch does not produce a running engineer. * Avoid leaving a reservation comment as the last visible state for a failed launch. * Add regression coverage for the director-surface forwarded-dispatch path. * Validate with `ward exec test`. Filed from the read-only director surface after coilyco-bridge/agentic-os-kai#720 exposed the missing failure comment.

coilyco-ops commented

2026-07-08 19:28:48 +00:00

Author

Member

🔒 Reserved by ward agent --harness codex — container engineer-codex-ward-689 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-08T19:28:46Z). 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#689 · branch issue-689 · harness codex · workflow direct-main
Run: engineer-codex-ward-689 · ward v0.463.0 · dispatched 2026-07-08T19:28:46Z
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.463.0).

— Codex, via ward agent

🔒 Reserved by `ward agent --harness codex` — container `engineer-codex-ward-689` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-08T19:28:46Z). 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#689` · branch `issue-689` · harness `codex` · workflow `direct-main` - **Run:** `engineer-codex-ward-689` · ward `v0.463.0` · dispatched `2026-07-08T19:28:46Z` - **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.463.0). </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue

2026-07-08 19:38:12 +00:00

Update Codex launch adapter for current codex exec flags #691

coilyco-ops referenced this issue

2026-07-08 19:40:44 +00:00

OpenCode harness is selectable but missing from the engineer image #692

coilyco-ops referenced this issue

2026-07-08 20:43:26 +00:00

Add ward agent logs for director-surface engineer log reads #694

coilyco-ops referenced this issue

2026-07-08 20:54:00 +00:00

Goose engineer can answer in logs and exit clean without carrying the issue #697

coilyco-ops referenced this issue from coilyco-flight-deck/agentic-os

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

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

coilyco-ops commented

2026-07-08 21:56:07 +00:00

Author

Member

🔒 Reserved by ward agent --harness codex — container engineer-codex-ward-689 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-08T21:56:06Z). 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#689 · branch issue-689 · harness codex · workflow direct-main
Run: engineer-codex-ward-689 · ward v0.466.0 · dispatched 2026-07-08T21:56:06Z
Comment thread: 0 included in the pre-flight read, 1 stripped (ward's own automated comments).
- stripped: @coilyco-ops (2026-07-08T19:28:48Z)

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

— Codex, via ward agent

🔒 Reserved by `ward agent --harness codex` — container `engineer-codex-ward-689` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-08T21:56:06Z). 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#689` · branch `issue-689` · harness `codex` · workflow `direct-main` - **Run:** `engineer-codex-ward-689` · ward `v0.466.0` · dispatched `2026-07-08T21:56:06Z` - **Comment thread:** 0 included in the pre-flight read, 1 stripped (ward's own automated comments). - stripped: @coilyco-ops (2026-07-08T19:28:48Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.466.0). </details>  — Codex, via `ward agent`

coilyco-ops added the

headless

P1

labels

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

coilyco-ops commented

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

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-09T21:52: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#689 · branch issue-689 · harness codex · workflow direct-to-main
Run: engineer-codex-ward-689 · ward v0.522.0 · dispatched 2026-07-09T21:52:25Z
Comment thread: 0 included in the pre-flight read, 2 stripped (ward's own automated comments).
- stripped: @coilyco-ops (2026-07-08T19:28:48Z), @coilyco-ops (2026-07-08T21:56:07Z)

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

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-689` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-09T21:52: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#689` · branch `issue-689` · harness `codex` · workflow `direct-to-main` - **Run:** `engineer-codex-ward-689` · ward `v0.522.0` · dispatched `2026-07-09T21:52:25Z` - **Comment thread:** 0 included in the pre-flight read, 2 stripped (ward's own automated comments). - stripped: @coilyco-ops (2026-07-08T19:28:48Z), @coilyco-ops (2026-07-08T21:56:07Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.522.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-09 22:14:44 +00:00

fix broker failure comments

coilyco-ops closed this issue

2026-07-09 22:14:44 +00:00

coilyco-ops commented

2026-07-09 22:15:34 +00:00

Author

Member

WARD-OUTCOME: done

details

workflow: direct-to-main; review summary: skipped because review gate skipped by ~/.ward/config.yaml default retrospective: the fix was narrow, but the commit hook exposed repo-local comment-width rules and temp-space pressure before it landed cleanly. confidence: high surprises: the hook wanted a shorter code comment, and the container had a shared cache that needed cleanup before commit. follow-ups: watch the pushed Forgejo CI run and confirm the broker failure comment shows on a real forwarded-dispatch failure.

WARD-OUTCOME: done <details><summary>details</summary> workflow: direct-to-main; review summary: skipped because review gate skipped by ~/.ward/config.yaml default retrospective: the fix was narrow, but the commit hook exposed repo-local comment-width rules and temp-space pressure before it landed cleanly. confidence: high surprises: the hook wanted a shorter code comment, and the container had a shared cache that needed cleanup before commit. follow-ups: watch the pushed Forgejo CI run and confirm the broker failure comment shows on a real forwarded-dispatch failure. </details>

coilysiren referenced this issue

2026-07-14 15:27:09 +00:00

director should emit colorized, space buffered, visually distinct messages about the categories of actions its performing on startup #1283

Rows
Columns

Broker should comment failed forwarded dispatches back to the issue #689

Bug

Reproduction observed on 2026-07-08

Expected behavior

Acceptance