Add a director queue view for stale reservations and redispatch candidates #977

New issue

Open

opened 2026-07-10 08:54:40 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-10 08:54:40 +00:00

Member

A director usability sweep found that the open ward/aos queue can accumulate two different blocked states that are only visible by manually reading issue comments:

 after a failed forwarded dispatch.
Reservation comments that say the hold goes stale after 1h, but remain the latest visible state long after that TTL.

Observed examples on 2026-07-10:

coilyco-flight-deck/ward#971 and coilyco-flight-deck/agentic-os#419 both have ward-needs-redispatch after bootstrap asset 404s.
coilyco-flight-deck/ward#950, #943, #934, #912, #911, and #632 also have ward-needs-redispatch in the open queue.
Several issues showed reservation comments older than the stated 1h TTL as the latest visible state, including ward#874, #873, #861, #698, #690, and #636.

This is adjacent to, but not the same as:

ward#874 - list currently running engineers.
ward#927 - read broker/dispatch logs naturally from a director/TUI surface.

Requested behavior:

Add a director-facing queue/status command that classifies issue carries into at least:

running/reserved and not stale,
stale reservation,
failed dispatch needing redispatch,
submitted PR awaiting merge/review,
done-but-still-open if detectable.

The command should be issue-aware and should print the next operator action, e.g. redispatch, inspect logs, merge PR, close stale-open done issue, or wait. It should not require manually grepping issue comments or knowing the hidden marker names.

This was discovered while working coilysiren/inbox#188 and the ward/aos usability sweep. Sibling dispatch is currently blocked by ward#905 / PR ward#976 because the bootstrap asset fetch is selecting v0.570.0 before its platform asset exists.

A director usability sweep found that the open ward/aos queue can accumulate two different blocked states that are only visible by manually reading issue comments: * `` after a failed forwarded dispatch. * Reservation comments that say the hold goes stale after 1h, but remain the latest visible state long after that TTL. Observed examples on 2026-07-10: * `coilyco-flight-deck/ward#971` and `coilyco-flight-deck/agentic-os#419` both have `ward-needs-redispatch` after bootstrap asset 404s. * `coilyco-flight-deck/ward#950`, `#943`, `#934`, `#912`, `#911`, and `#632` also have `ward-needs-redispatch` in the open queue. * Several issues showed reservation comments older than the stated 1h TTL as the latest visible state, including `ward#874`, `#873`, `#861`, `#698`, `#690`, and `#636`. This is adjacent to, but not the same as: * `ward#874` - list currently running engineers. * `ward#927` - read broker/dispatch logs naturally from a director/TUI surface. Requested behavior: Add a director-facing queue/status command that classifies issue carries into at least: * running/reserved and not stale, * stale reservation, * failed dispatch needing redispatch, * submitted PR awaiting merge/review, * done-but-still-open if detectable. The command should be issue-aware and should print the next operator action, e.g. `redispatch`, `inspect logs`, `merge PR`, `close stale-open done issue`, or `wait`. It should not require manually grepping issue comments or knowing the hidden marker names. This was discovered while working `coilysiren/inbox#188` and the ward/aos usability sweep. Sibling dispatch is currently blocked by `ward#905` / PR `ward#976` because the bootstrap asset fetch is selecting `v0.570.0` before its platform asset exists.

coilyco-ops commented

2026-07-10 08:56:44 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-10T08:56:44Z). 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#977 · branch issue-977 · harness codex · workflow pull-requests-and-merge
Run: engineer-codex-ward-977 · ward v0.569.0 · dispatched 2026-07-10T08:56:44Z
Comment thread: 1 included in the pre-flight read, 0 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-10T08:54:51Z)

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

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-977` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T08:56:44Z). 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#977` · branch `issue-977` · harness `codex` · workflow `pull-requests-and-merge` - **Run:** `engineer-codex-ward-977` · ward `v0.569.0` · dispatched `2026-07-10T08:56:44Z` - **Comment thread:** 1 included in the pre-flight read, 0 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-10T08:54:51Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.569.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops added the

consult

labels

2026-07-10 09:00:29 +00:00

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

2026-07-10 09:16:37 +00:00

Add a director queue view for stale reservations and redispatch candidates #984

coilyco-ops commented

2026-07-10 09:18:04 +00:00

Author

Member

WARD-OUTCOME: merge-ready

details

workflow: pull-requests-and-merge; review summary: skipped: review gate skipped by ~/.ward/config.yaml default
felt: steady, mostly plumbing and classifier wiring
confidence: high
surprises: Forgejo PR creation and status polling were straightforward; full go test still has unrelated config-source failures without the repo's expected WARD_CONFIG_REF
follow-ups: merge PR #984 and record the final done outcome

WARD-OUTCOME: merge-ready <details><summary>details</summary> workflow: pull-requests-and-merge; review summary: skipped: review gate skipped by ~/.ward/config.yaml default felt: steady, mostly plumbing and classifier wiring confidence: high surprises: Forgejo PR creation and status polling were straightforward; full go test still has unrelated config-source failures without the repo's expected WARD_CONFIG_REF follow-ups: merge PR #984 and record the final done outcome </details>