coilyco-flight-deck/ward

Watch

Bound logs reads for fresh container-starting engineers with no transcript yet #1594

New issue

Closed

opened 2026-07-28 08:52:04 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-28 08:52:04 +00:00

Member

Problem

During the 2026-07-28 read-only burndown surface, freshly dispatched engineers for coilyco-flight-deck/ward#1464 and coilyco-flight-deck/ward#1478 reached reservation/container-starting state before producing readable Docker logs or Codex session transcript bytes.

ward agent logs coilyco-flight-deck/ward#1464 --tail 12 and the equivalent for coilyco-flight-deck/ward#1478 did not return promptly while the launch was still fresh. Interrupting one read eventually showed a useful message for #1464: Docker logs had no readable bytes and the live transcript tree was empty. The other interrupt returned no message.

That is rough operator UX during a burndown: a director checking whether a launch is healthy can get stuck in a log read instead of receiving a bounded status such as “container exists, no stdout yet, no transcript yet, reservation age N”.

Desired behavior

A non-following ward agent logs ... --tail N read should be bounded when the target exists but has not emitted logs or transcripts yet. It should return a concise status rather than waiting indefinitely.

Acceptance

ward agent logs <ref> --tail N returns promptly for a fresh container-starting engineer with no Docker log bytes and no harness transcript.
The output states the container/ref, phase if known, reservation age or start age if known, and that no readable transcript exists yet.
Follow mode, if supported, remains explicitly opt-in and can still wait.
Tests cover the no-Docker-logs/no-transcript path without requiring a real long wait.
Existing successful log reads and archived log reads keep their current behavior.

Observed while dispatching coilyco-flight-deck/ward#1464 and coilyco-flight-deck/ward#1478 from a read-only director surface. This complements the broader artifact/logging work in coilyco-flight-deck/ward#1469 and coilyco-flight-deck/ward#1551, but is a narrower bounded-read UX fix.

## Problem During the 2026-07-28 read-only burndown surface, freshly dispatched engineers for coilyco-flight-deck/ward#1464 and coilyco-flight-deck/ward#1478 reached reservation/container-starting state before producing readable Docker logs or Codex session transcript bytes. `ward agent logs coilyco-flight-deck/ward#1464 --tail 12` and the equivalent for coilyco-flight-deck/ward#1478 did not return promptly while the launch was still fresh. Interrupting one read eventually showed a useful message for #1464: Docker logs had no readable bytes and the live transcript tree was empty. The other interrupt returned no message. That is rough operator UX during a burndown: a director checking whether a launch is healthy can get stuck in a log read instead of receiving a bounded status such as “container exists, no stdout yet, no transcript yet, reservation age N”. ## Desired behavior A non-following `ward agent logs ... --tail N` read should be bounded when the target exists but has not emitted logs or transcripts yet. It should return a concise status rather than waiting indefinitely. ## Acceptance - `ward agent logs <ref> --tail N` returns promptly for a fresh container-starting engineer with no Docker log bytes and no harness transcript. - The output states the container/ref, phase if known, reservation age or start age if known, and that no readable transcript exists yet. - Follow mode, if supported, remains explicitly opt-in and can still wait. - Tests cover the no-Docker-logs/no-transcript path without requiring a real long wait. - Existing successful log reads and archived log reads keep their current behavior. ## Related evidence Observed while dispatching coilyco-flight-deck/ward#1464 and coilyco-flight-deck/ward#1478 from a read-only director surface. This complements the broader artifact/logging work in coilyco-flight-deck/ward#1469 and coilyco-flight-deck/ward#1551, but is a narrower bounded-read UX fix.

coilyco-ops added the

autonomy

headless

priority

labels

2026-07-28 08:52:04 +00:00

coilyco-ops commented

2026-07-28 08:52:30 +00:00

Author

Member

WARD-WORKFLOW: reservation-held

reservation details

Holder: launch intent for container engineer-codex-ward-1594 on host 89600efad9e2.

Accepted by ward agent --harness codex (reserved 2026-07-28T08:52:30Z). Concurrent ward agent runs are blocked until this intent becomes visible or the intent is released. The stale-intent fallback is still TTL-bounded (3h TTL). --override-reservation 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#1594 · branch issue-1594 · harness codex · workflow merge-remote-main
Run: engineer-codex-ward-1594 · ward v0.823.0 · dispatched 2026-07-28T08:52:23Z
Reservation: held
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.823.0).

— Codex, via ward agent

WARD-WORKFLOW: reservation-held <details><summary>reservation details</summary> Holder: launch intent for container `engineer-codex-ward-1594` on host `89600efad9e2`. Accepted by `ward agent --harness codex` (reserved 2026-07-28T08:52:30Z). Concurrent `ward agent` runs are blocked until this intent becomes visible or the intent is released. The stale-intent fallback is still TTL-bounded (3h TTL). `--override-reservation` 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#1594` · branch `issue-1594` · harness `codex` · workflow `merge-remote-main` - **Run:** `engineer-codex-ward-1594` · ward `v0.823.0` · dispatched `2026-07-28T08:52:23Z` - **Reservation:** held - **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.823.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-28 09:04:34 +00:00

Bound fresh agent log reads

coilyco-ops closed this issue

2026-07-28 09:04:34 +00:00

coilyco-ops referenced this issue

2026-07-28 09:07:46 +00:00

Inspect failed promote run 2491 after bounded log reads landed #1596

coilyco-ops commented

2026-07-28 09:08:09 +00:00

Author

Member

WARD-WORKFLOW: done ✅

details

skip state: The in-container review gate was intentionally skipped because the temporary ward default pending brokered QA.
workflow: merge-remote-main; review summary: skipped - in-container review gate intentionally skipped because the temporary ward default pending brokered QA
implementation felt: straightforward once the logs path was mapped; the timeout needed a second pass because merely setting a context deadline did not make the fake docker cp return promptly.
confidence: medium-high. Focused validation passed: go test ./cmd/ward -run Logs -count=1 and ward exec build. Full ward exec test still fails at the pre-existing TestBuildUpPlanTailnet host-net expectation, outside this logs change.
surprises: aosguard ops forgejo tasks list could not authenticate because SSM/IMDS credentials were unavailable in this container. Public Forgejo API showed latest gate-and-promote for 22f80d6a failed at 2026-07-28T09:06:21Z.
follow-ups: inspect the promote run failure and the existing TestBuildUpPlanTailnet environment mismatch separately.

WARD-WORKFLOW: done ✅ <details><summary>details</summary> skip state: The in-container review gate was intentionally skipped because the temporary ward default pending brokered QA. workflow: merge-remote-main; review summary: skipped - in-container review gate intentionally skipped because the temporary ward default pending brokered QA implementation felt: straightforward once the logs path was mapped; the timeout needed a second pass because merely setting a context deadline did not make the fake docker cp return promptly. confidence: medium-high. Focused validation passed: `go test ./cmd/ward -run Logs -count=1` and `ward exec build`. Full `ward exec test` still fails at the pre-existing `TestBuildUpPlanTailnet` host-net expectation, outside this logs change. surprises: `aosguard ops forgejo tasks list` could not authenticate because SSM/IMDS credentials were unavailable in this container. Public Forgejo API showed latest gate-and-promote for `22f80d6a` failed at 2026-07-28T09:06:21Z. follow-ups: inspect the promote run failure and the existing `TestBuildUpPlanTailnet` environment mismatch separately. </details>

coilyco-ops referenced this issue

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

Provide a concise issue-scoped asynchronous status summary #1601

coilyco-ops referenced this issue

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

Inspect failed promote run 2491 after bounded log reads landed #1596