coilyco-flight-deck/ward

Fork 0

Show pre-flight and reserved agent launches in warded list #1033

New issue

Closed

opened 2026-07-10 16:52:35 +00:00 by coilyco-ops · 3 comments

coilyco-ops commented

2026-07-10 16:52:35 +00:00

Member

Problem

warded list only reports engineer containers once they are running. That leaves a recurring observability gap after a dispatch succeeds but before the agent container appears, probably while pre-flight is still running. A director cannot verify whether the broker accepted launch is progressing, stalled in pre-flight, or lost.

Live evidence from the read-only director surface on 2026-07-10 UTC:

The director dispatched coilyco-flight-deck/ward#1031 successfully:

ward dispatch broker: forwarded `ward agent engineer coilyco-flight-deck/ward#1031 ...` to host ward

An immediate warded list still reported 7 running containers and did not include ward#1031 at all:

ward agent: running engineer containers (7/12, 5 slots free)

That makes the director report a false uncertainty window even when the broker returned success.

Proposed change

Make the command that lists warded agents include launches that are reserved, accepted, or in pre-flight before their container reaches the running state. The listing should distinguish at least:

broker accepted / queued
pre-flight running
container starting
container running
failed before container start

The count should make capacity semantics explicit, for example by showing running containers separately from pre-flight or reserved launches if those consume different resources.

Acceptance

Immediately after a successful broker-forwarded warded engineer ..., warded list shows the launch before the Docker container appears.
The entry names the target issue, harness, role, host, reservation timestamp, and current phase.
If pre-flight fails before a container starts, warded list or warded logs shows the failure instead of the launch disappearing.
The capacity line no longer implies a slot is free if the launch is already accepted and will consume one.
Tests or fixtures cover the accepted/pre-flight state and the pre-container failure state.

Filed from the read-only director surface (she/her).

## Problem `warded list` only reports engineer containers once they are running. That leaves a recurring observability gap after a dispatch succeeds but before the agent container appears, probably while pre-flight is still running. A director cannot verify whether the broker accepted launch is progressing, stalled in pre-flight, or lost. Live evidence from the read-only director surface on 2026-07-10 UTC: 1. The director dispatched `coilyco-flight-deck/ward#1031` successfully: ```text ward dispatch broker: forwarded `ward agent engineer coilyco-flight-deck/ward#1031 ...` to host ward ``` 2. An immediate `warded list` still reported 7 running containers and did not include `ward#1031` at all: ```text ward agent: running engineer containers (7/12, 5 slots free) ``` That makes the director report a false uncertainty window even when the broker returned success. ## Proposed change Make the command that lists warded agents include launches that are reserved, accepted, or in pre-flight before their container reaches the running state. The listing should distinguish at least: * broker accepted / queued * pre-flight running * container starting * container running * failed before container start The count should make capacity semantics explicit, for example by showing running containers separately from pre-flight or reserved launches if those consume different resources. ## Acceptance * Immediately after a successful broker-forwarded `warded engineer ...`, `warded list` shows the launch before the Docker container appears. * The entry names the target issue, harness, role, host, reservation timestamp, and current phase. * If pre-flight fails before a container starts, `warded list` or `warded logs` shows the failure instead of the launch disappearing. * The capacity line no longer implies a slot is free if the launch is already accepted and will consume one. * Tests or fixtures cover the accepted/pre-flight state and the pre-container failure state. Filed from the read-only director surface (she/her).

coilyco-ops added the

headless

labels

2026-07-10 16:52:35 +00:00

coilyco-ops commented

2026-07-10 16:52:45 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-10T16:52:45Z). 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#1033 · branch issue-1033 · harness codex · workflow pull-requests-and-merge
Run: engineer-codex-ward-1033 · ward v0.584.0 · dispatched 2026-07-10T16:52:45Z
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.584.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-1033` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T16:52:45Z). 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#1033` · branch `issue-1033` · harness `codex` · workflow `pull-requests-and-merge` - **Run:** `engineer-codex-ward-1033` · ward `v0.584.0` · dispatched `2026-07-10T16:52:45Z` - **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.584.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue

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

Report Codex residual commits that produce no PR or outcome #1039

coilyco-ops commented

2026-07-10 22:59:29 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-ward-1033 on host KAI-DESKTOP-TOWER.

Reserved by ward agent --harness codex (reserved 2026-07-10T22:59:29Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h TTL). --force overrides.

run seed context — what this run is carrying (ward#609)

Resolved: coilyco-flight-deck/ward#1033 · branch issue-1033 · harness codex · workflow pull-requests-and-merge
Run: engineer-codex-ward-1033 · ward v0.605.0 · dispatched 2026-07-10T22:59:29Z
Comment thread: 0 included in the pre-flight read, 1 stripped (ward's own automated comments).
- stripped: @coilyco-ops (2026-07-10T16:52:45Z)

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

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-1033` on host `KAI-DESKTOP-TOWER`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T22:59:29Z). 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#1033` · branch `issue-1033` · harness `codex` · workflow `pull-requests-and-merge` - **Run:** `engineer-codex-ward-1033` · ward `v0.605.0` · dispatched `2026-07-10T22:59:29Z` - **Comment thread:** 0 included in the pre-flight read, 1 stripped (ward's own automated comments). - stripped: @coilyco-ops (2026-07-10T16:52:45Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.605.0). </details> </details>  — Codex, via `ward agent`

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

2026-07-10 23:24:15 +00:00

Show pre-flight and reserved agent launches in warded list #1099

coilyco-ops closed this issue

2026-07-10 23:25:20 +00:00

coilyco-ops commented

2026-07-10 23:26:17 +00:00

Author

Member

WARD-OUTCOME: submitted

details

workflow: pull-request-and-merge; review summary: skip (temporary ward default pending brokered QA)

The implementation felt clean after splitting active reservations from running containers and making dispatch-log phase parsing pure. Confidence is high. Surprise: the reservation scan initially pointed at the log tree, and the lint budget wanted the phase logic broken into smaller helpers. Follow-up: watch PR #1099 if the action status changes.

WARD-OUTCOME: submitted <details><summary>details</summary> workflow: pull-request-and-merge; review summary: skip (temporary ward default pending brokered QA) The implementation felt clean after splitting active reservations from running containers and making dispatch-log phase parsing pure. Confidence is high. Surprise: the reservation scan initially pointed at the log tree, and the lint budget wanted the phase logic broken into smaller helpers. Follow-up: watch PR #1099 if the action status changes. </details>