coilyco-flight-deck/ward

Fork 0

Make dispatch logs point to or include engineer container logs #696

New issue

Closed

opened 2026-07-08 20:51:17 +00:00 by coilyco-ops · 3 comments

coilyco-ops commented

2026-07-08 20:51:17 +00:00

Member

Bug

The per-dispatch broker log under ~/.ward/agent-logs/dispatch/ does not include the engineer container's in-container console/reap logs, nor does it clearly point to where those logs can be read.

Concrete example

Kai checked this host-side dispatch log after the Goose engineer for ward#692 died:

/Users/kai/.ward/agent-logs/dispatch/20260708T194107Z-session-codex-12afd722-coilyco-flight-deck-ward-692.log

The expected in-container output/reap logs were not present there. From the director surface, that path was the only log location emitted by the broker, so it read as the place to look for the failed run.

Problem

A dispatch log that only captures the broker/host wrapper output is not enough for postmortem use when the engineer dies during bootstrap. The operator needs either the actual container console/reap stream there, or a clear pointer from the dispatch log to the container log/drain source.

This is related to, but distinct from:

coilyco-flight-deck/ward#693 - reaper should print the durable flush destination into container logs.
coilyco-flight-deck/ward#694 - add ward agent logs so director surfaces can read logs ergonomically.

Do

Inspect how the dispatch broker writes ~/.ward/agent-logs/dispatch/*.log.
Decide whether broker dispatch logs should tee or append the engineer container console/reap stream, or instead print an explicit container logs at ... / drained logs at ... pointer.
Ensure the dispatch log is useful when the container dies before useful work starts.
Preserve the distinction between broker logs and raw/redacted engineer logs if needed for secret handling, but make that distinction visible in the dispatch log.

Acceptance

For a failed engineer launch, the emitted dispatch log path lets the operator find the in-container console/reap logs without guessing.
The dispatch log either contains the relevant in-container failure stream or contains an explicit durable/log-readable location.
Tests cover the broker log content contract where practical.
ward exec test passes.

Filed from the read-only director surface after Kai found that the ward#692 dispatch log did not contain the in-container logs.

## Bug The per-dispatch broker log under `~/.ward/agent-logs/dispatch/` does not include the engineer container's in-container console/reap logs, nor does it clearly point to where those logs can be read. ## Concrete example Kai checked this host-side dispatch log after the Goose engineer for ward#692 died: ```text /Users/kai/.ward/agent-logs/dispatch/20260708T194107Z-session-codex-12afd722-coilyco-flight-deck-ward-692.log ``` The expected in-container output/reap logs were not present there. From the director surface, that path was the only log location emitted by the broker, so it read as the place to look for the failed run. ## Problem A dispatch log that only captures the broker/host wrapper output is not enough for postmortem use when the engineer dies during bootstrap. The operator needs either the actual container console/reap stream there, or a clear pointer from the dispatch log to the container log/drain source. This is related to, but distinct from: * coilyco-flight-deck/ward#693 - reaper should print the durable flush destination into container logs. * coilyco-flight-deck/ward#694 - add `ward agent logs` so director surfaces can read logs ergonomically. ## Do * Inspect how the dispatch broker writes `~/.ward/agent-logs/dispatch/*.log`. * Decide whether broker dispatch logs should tee or append the engineer container console/reap stream, or instead print an explicit `container logs at ...` / `drained logs at ...` pointer. * Ensure the dispatch log is useful when the container dies before useful work starts. * Preserve the distinction between broker logs and raw/redacted engineer logs if needed for secret handling, but make that distinction visible in the dispatch log. ## Acceptance * For a failed engineer launch, the emitted dispatch log path lets the operator find the in-container console/reap logs without guessing. * The dispatch log either contains the relevant in-container failure stream or contains an explicit durable/log-readable location. * Tests cover the broker log content contract where practical. * `ward exec test` passes. Filed from the read-only director surface after Kai found that the ward#692 dispatch log did not contain the in-container logs.

coilyco-ops commented

2026-07-08 21:55:57 +00:00

Author

Member

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

— Codex, via ward agent

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

coilyco-ops added the

headless

labels

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

coilyco-ops commented

2026-07-09 21:53:07 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

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

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-696` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-09T21:53:04Z). 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#696` · branch `issue-696` · harness `codex` · workflow `direct-to-main` - **Run:** `engineer-codex-ward-696` · ward `v0.522.0` · dispatched `2026-07-09T21:53:04Z` - **Comment thread:** 0 included in the pre-flight read, 1 stripped (ward's own automated comments). - stripped: @coilyco-ops (2026-07-08T21:55:57Z) 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:03:28 +00:00

fix: point dispatch logs at engineer logs

coilyco-ops closed this issue

2026-07-09 22:03:28 +00:00

coilyco-ops commented

2026-07-09 22:05:16 +00:00

Author

Member

WARD-OUTCOME: done

details

workflow: direct-to-main; review summary: skipped (review gate skipped by ~/.ward/config.yaml default)
retrospective: small code change, but the environment cost most of the time on disk pressure and Forgejo push plumbing
confidence: high
surprises: the clone used a read-only pushurl, and CI needed explicit cache redirection to run in this full overlay
follow-ups: none

WARD-OUTCOME: done <details><summary>details</summary> workflow: direct-to-main; review summary: skipped (review gate skipped by ~/.ward/config.yaml default) retrospective: small code change, but the environment cost most of the time on disk pressure and Forgejo push plumbing confidence: high surprises: the clone used a read-only pushurl, and CI needed explicit cache redirection to run in this full overlay follow-ups: none </details>