coilyco-flight-deck/ward

Fork 0

Always return a log locator for broker-forwarded dispatches #941

New issue

Closed

opened 2026-07-10 04:46:32 +00:00 by coilyco-ops · 4 comments

coilyco-ops commented

2026-07-10 04:46:32 +00:00

Member

A read-only director surface can receive a successful broker-forwarded dispatch response without a host log path, even though a nearly identical dispatch does include one.

Observed from director-codex-aq74 on 2026-07-10:

warded engineer coilyco-flight-deck/ward#900 --harness codex --force ...
ward dispatch broker: forwarded ... to host ward (run output on the host at /Users/kai/.ward/agent-logs/dispatch/20260710T044617Z-director-codex-aq74-coilyco-flight-deck-ward-900.log)

warded engineer coilyco-flight-deck/ward#902 --harness codex --force ...
ward dispatch broker: forwarded ... to host ward

warded engineer coilyco-flight-deck/ward#883 --harness codex ...
ward dispatch broker: forwarded ... to host ward

The second and third responses give the surface no immediate way to inspect or cite the host dispatch log. That is especially painful during an outage/debug loop where the director is explicitly supposed to fire work and exit, not babysit it.

Expected:

Every broker-forwarded dispatch should either print the host log path or print a clear reason no log path is available.
The response shape should be stable across successful forwards.
If the host broker accepts the request asynchronously before the log path exists, return a correlation ID or deterministic lookup command/path instead of a bare forwarded line.
Add regression coverage for the broker response payload/rendering.

Related pain: #900 and #902 both involve director/broker dispatch state being hard to reconcile from a read-only surface.

A read-only director surface can receive a successful broker-forwarded dispatch response without a host log path, even though a nearly identical dispatch does include one. Observed from `director-codex-aq74` on 2026-07-10: ```text warded engineer coilyco-flight-deck/ward#900 --harness codex --force ... ward dispatch broker: forwarded ... to host ward (run output on the host at /Users/kai/.ward/agent-logs/dispatch/20260710T044617Z-director-codex-aq74-coilyco-flight-deck-ward-900.log) warded engineer coilyco-flight-deck/ward#902 --harness codex --force ... ward dispatch broker: forwarded ... to host ward warded engineer coilyco-flight-deck/ward#883 --harness codex ... ward dispatch broker: forwarded ... to host ward ``` The second and third responses give the surface no immediate way to inspect or cite the host dispatch log. That is especially painful during an outage/debug loop where the director is explicitly supposed to fire work and exit, not babysit it. Expected: * Every broker-forwarded dispatch should either print the host log path or print a clear reason no log path is available. * The response shape should be stable across successful forwards. * If the host broker accepts the request asynchronously before the log path exists, return a correlation ID or deterministic lookup command/path instead of a bare `forwarded` line. * Add regression coverage for the broker response payload/rendering. Related pain: #900 and #902 both involve director/broker dispatch state being hard to reconcile from a read-only surface.

coilyco-ops commented

2026-07-10 04:47:02 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

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

2026-07-10 04:50:48 +00:00

Author

Member

WARD-RESERVATION: released 🛑

release details

Run never started. ward container reap released container ward (--harness codex): it exited without launching the agent (smoke-test death, ward#222/#264/#595), so it did no work and the hold it took is retracted. Nothing is running on this issue. It needs re-dispatch. A ward agent director re-queues it automatically. A manual ward agent retry no longer needs --force.

— Codex, via ward agent

WARD-RESERVATION: released 🛑 <details><summary>release details</summary> Run never started. `ward container reap` released container `ward` (`--harness codex`): it exited without launching the agent (smoke-test death, ward#222/#264/#595), so it did no work and the hold it took is retracted. Nothing is running on this issue. It needs re-dispatch. A `ward agent director` re-queues it automatically. A manual `ward agent` retry no longer needs `--force`. </details>  — Codex, via `ward agent`

coilyco-ops commented

2026-07-10 04:52:50 +00:00

Author

Member

WARD-RESERVATION: released 🛑

release details

— Codex, via ward agent

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

2026-07-10 04:57:35 +00:00

Always return a log locator for broker-forwarded dispatches #944

coilyco-ops commented

2026-07-10 04:58:41 +00:00

Author

Member

WARD-OUTCOME: submitted

details

workflow: pull-requests; review summary: skipped (review gate skipped by ~/.ward/config.yaml default)

Implemented a shared forwarded-line renderer so broker-forwarded dispatches always print either the host log path or a deterministic ward agent logs <ref> lookup when the path is not yet available.
Added regressions for the path-present and path-missing cases, plus a launch-success path with no log path.

Confidence: high for the dispatch UX fix.
Surprise: repo-wide go test ./... hit container disk limits here, but the broker-focused regressions passed and PR #944 is green.
Follow-up: none.

WARD-OUTCOME: submitted <details><summary>details</summary> workflow: pull-requests; review summary: skipped (review gate skipped by ~/.ward/config.yaml default) Implemented a shared forwarded-line renderer so broker-forwarded dispatches always print either the host log path or a deterministic `ward agent logs <ref>` lookup when the path is not yet available. Added regressions for the path-present and path-missing cases, plus a launch-success path with no log path. Confidence: high for the dispatch UX fix. Surprise: repo-wide `go test ./...` hit container disk limits here, but the broker-focused regressions passed and PR #944 is green. Follow-up: none. </details>

coilyco-ops closed this issue

2026-07-10 05:08:03 +00:00