coilyco-flight-deck/agentic-os

Fork 0

feat(backlog-loop): add a `run` supervisor verb + --max-inflight dispatch ceiling #276

New issue

Closed

opened 2026-06-25 08:55:31 +00:00 by coilyco-ops · 4 comments

coilyco-ops commented

2026-06-25 08:55:31 +00:00

Member

The verbs are select / dispatch / poll / unblock, but there is no driver that chains them - the thing literally named in "backlog-loop" is missing. Driving it by hand this session, I had to write a throwaway bash watcher to poll-on-a-timer.

Add a run (or watch) verb that drives the supervised loop end to end:

select -> dispatch queued headless issues up to a ceiling -> poll until containers exit -> re-select -> repeat until the headless lane drains.
--max-inflight N: count running ward-<repo>-issue-* containers via docker ps before each dispatch and never exceed N. This session I dispatched ward#269 + ward#270 blind while ward#320 + ward#322 were already running from explore - nothing enforced a cap. Honor the dispatch-ceiling concept (agentic-os#246).
Surface each transition (dispatched / done / blocked / failed) so the operator supervises instead of polling.

This deletes the hand-rolled watcher and makes the loop runnable unattended. It is also the surface that graduates into ward agent backlog (ward tracking issue).

The verbs are `select / dispatch / poll / unblock`, but there is **no driver that chains them** - the thing literally named in "backlog-**loop**" is missing. Driving it by hand this session, I had to write a throwaway bash watcher to poll-on-a-timer. **Add** a `run` (or `watch`) verb that drives the supervised loop end to end: - `select` -> `dispatch` queued headless issues up to a ceiling -> `poll` until containers exit -> re-`select` -> repeat until the headless lane drains. - `--max-inflight N`: count running `ward-<repo>-issue-*` containers via `docker ps` before each dispatch and never exceed N. This session I dispatched ward#269 + ward#270 blind while ward#320 + ward#322 were already running from explore - nothing enforced a cap. Honor the dispatch-ceiling concept (agentic-os#246). - Surface each transition (dispatched / done / blocked / failed) so the operator supervises instead of polling. This deletes the hand-rolled watcher and makes the loop runnable unattended. It is also the surface that graduates into `ward agent backlog` (ward tracking issue).

coilyco-ops added the

consult

labels

2026-06-25 09:08:57 +00:00

coilysiren added

headless

and removed

consult

labels

2026-07-01 04:29:19 +00:00

coilysiren commented

2026-07-01 04:32:00 +00:00

Owner

this moved into ward (I'm pretty sure???)

coilyco-ops commented

2026-07-01 04:39:43 +00:00

Author

Member

🛫 ward pre-flight: NO-GO

ward agent engineer --driver claude ran a pre-flight feasibility read on this issue before detaching a fire-and-forget run, and the agent judged it NO-GO - it should not be carried unattended until a human weighs in.

author's latest comment says this likely moved into the ward repo ("I'm pretty sure???") — a human should confirm the correct home before dispatch, since the whole verb surface is ward-domain and may not exist in agentic-os at all.

No container was launched. Review the issue (clarify the scope, resolve the unknown, or split it), then re-dispatch - ward agent engineer --driver claude <ref> --no-preflight skips this gate once you've decided it's good to go.

full pre-flight read

Pre-flight: agentic-os#276

Context to front-load: This work would touch the backlog-loop verb surface (select / dispatch / poll / unblock), its command wiring (a .ward/ward.yaml verb declaration plus the underlying script/module implementing each verb), the docker ps container-naming convention (ward-<repo>-issue-*), and the ward agent headless dispatch path that these verbs orchestrate. I'd read each of those in the clone before editing — but I can't confirm any of them even live in this repo, which is the crux.

Main risk / unknown: The author's own latest comment — "this moved into ward (I'm pretty sure???)" — says the subject matter has migrated out of agentic-os, and everything the issue names (ward agent backlog, the ward-<repo>-issue-* containers, the dispatch-ceiling concept, the select/dispatch/poll/unblock lane) is ward-domain, graduating into ward agent backlog per a ward tracking issue. That hedged "I'm pretty sure???" is genuine uncertainty from the person who filed it, and I can't resolve it from the issue text alone: I don't know whether the backlog-loop verbs currently live in agentic-os or in ward, and I can't confidently name the ward repo's owner/slug to redirect. Because the author herself is unsure the issue even belongs in this repo, launching an unattended run risks implementing against a surface that isn't here.

NO-GO: author's latest comment says this likely moved into the ward repo ("I'm pretty sure???") — a human should confirm the correct home before dispatch, since the whole verb surface is ward-domain and may not exist in agentic-os at all.

Posted automatically by ward agent engineer --driver claude pre-flight (ward#147, ward#149).

— Claude (she/her), via ward agent

### 🛫 ward pre-flight: NO-GO `ward agent engineer --driver claude` ran a pre-flight feasibility read on this issue before detaching a fire-and-forget run, and the agent judged it **NO-GO** - it should not be carried unattended until a human weighs in. > author's latest comment says this likely moved into the ward repo ("I'm pretty sure???") — a human should confirm the correct home before dispatch, since the whole verb surface is ward-domain and may not exist in agentic-os at all. No container was launched. Review the issue (clarify the scope, resolve the unknown, or split it), then re-dispatch - `ward agent engineer --driver claude <ref> --no-preflight` skips this gate once you've decided it's good to go. <details><summary>full pre-flight read</summary> ## Pre-flight: agentic-os#276 **Context to front-load:** This work would touch the `backlog-loop` verb surface (`select / dispatch / poll / unblock`), its command wiring (a `.ward/ward.yaml` verb declaration plus the underlying script/module implementing each verb), the `docker ps` container-naming convention (`ward-<repo>-issue-*`), and the `ward agent` headless dispatch path that these verbs orchestrate. I'd read each of those in the clone before editing — but I can't confirm any of them even live in this repo, which is the crux. **Main risk / unknown:** The author's own latest comment — "this moved into ward (I'm pretty sure???)" — says the subject matter has migrated out of agentic-os, and everything the issue names (`ward agent backlog`, the `ward-<repo>-issue-*` containers, the dispatch-ceiling concept, the `select/dispatch/poll/unblock` lane) is ward-domain, graduating into `ward agent backlog` per a ward tracking issue. That hedged "I'm pretty sure???" is genuine uncertainty from the person who filed it, and I can't resolve it from the issue text alone: I don't know whether the `backlog-loop` verbs currently live in agentic-os or in ward, and I can't confidently name the ward repo's owner/slug to redirect. Because the author herself is unsure the issue even belongs in this repo, launching an unattended run risks implementing against a surface that isn't here. NO-GO: author's latest comment says this likely moved into the ward repo ("I'm pretty sure???") — a human should confirm the correct home before dispatch, since the whole verb surface is ward-domain and may not exist in agentic-os at all. </details> --- Posted automatically by `ward agent engineer --driver claude` pre-flight (ward#147, ward#149).   — Claude (she/her), via `ward agent`

coilysiren closed this issue

2026-07-01 05:34:24 +00:00

coilyco-ops commented

2026-07-01 07:04:36 +00:00

Author

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-agentic-os-276 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-01T07:04:34Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-agentic-os-276` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-01T07:04:34Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilysiren commented

2026-07-01 07:07:32 +00:00

Owner

WARD-OUTCOME: blocked - the surface this issue asks for lives in (and already shipped in) the ward repo as ward agent director; there is nothing to implement in agentic-os, and ward is read-only substrate not granted to this container.

Candid retrospective, she/her:

The work here fought back before the first edit, in the honest way: there was no edit to make. I went in expecting a backlog-loop verb with select / dispatch / poll / unblock living somewhere under agentic_os/ or .ward/ward.yaml, and it simply isn't in this repo. ward.yaml is only a per-repo command allowlist - it wraps existing commands, it doesn't host the supervised-loop implementation - so there was no backlog-loop.py to bolt a run verb onto.

Tracing it into /substrate/ward closed the loop fast, and this is the part that surprised me: the feature is already built, end to end. ward agent director (ward#347, was backlog; ward#346 ported backlog-loop.py; ward#351 made it an LLM-in-the-loop heartbeat) is exactly the requested supervisor: poll+reconcile -> refresh/rank into lanes -> decide -> dispatch -> sleep, looping until the headless lane drains. The --max-inflight ceiling is there as --max-parallel N (default 2, "in-flight container cap"), enforced by avail := cfg.maxParallel - inflight. Transitions surface via the WARD-OUTCOME marker (ward#310) and the heartbeat reporter. That matches the issue's own closing line - "the surface that graduates into ward agent backlog" - and this issue is already closed as superseded.

So confidence is high on the finding, zero on any deliverable: there is nothing correct to push to agentic-os main. I deliberately did not fabricate a run verb in ward.yaml just to have something to land - that would be a non-functional stub in the wrong repo. The June pre-flight NO-GO called this exactly right; the dispatch overrode it, but the wall is real - ward is /substrate read-only and not in this container's granted set, so I can't (and shouldn't) push the real fix there either.

Follow-up worth filing: nothing code-wise. The one human decision is bookkeeping - confirm agentic-os#276 stays closed as superseded-by-ward agent director, and optionally drop a cross-link from #276 to the ward director issues so the graduation is traceable. If any residual --max-inflight naming or the agentic-os#246 dispatch-ceiling framing should be reconciled against ward's --max-parallel, that belongs as a fresh issue in ward, not here.

Claude (she/her), via ward agent

WARD-OUTCOME: blocked - the surface this issue asks for lives in (and already shipped in) the `ward` repo as `ward agent director`; there is nothing to implement in agentic-os, and `ward` is read-only substrate not granted to this container. Candid retrospective, she/her: The work here fought back before the first edit, in the honest way: there was no edit to make. I went in expecting a `backlog-loop` verb with `select / dispatch / poll / unblock` living somewhere under `agentic_os/` or `.ward/ward.yaml`, and it simply isn't in this repo. `ward.yaml` is only a per-repo command allowlist - it wraps existing commands, it doesn't host the supervised-loop implementation - so there was no `backlog-loop.py` to bolt a `run` verb onto. Tracing it into `/substrate/ward` closed the loop fast, and this is the part that surprised me: the feature is already built, end to end. `ward agent director` (ward#347, was `backlog`; ward#346 ported `backlog-loop.py`; ward#351 made it an LLM-in-the-loop heartbeat) is exactly the requested supervisor: poll+reconcile -> refresh/rank into lanes -> decide -> dispatch -> sleep, looping until the headless lane drains. The `--max-inflight` ceiling is there as `--max-parallel N` (default 2, "in-flight container cap"), enforced by `avail := cfg.maxParallel - inflight`. Transitions surface via the WARD-OUTCOME marker (ward#310) and the heartbeat reporter. That matches the issue's own closing line - "the surface that graduates into `ward agent backlog`" - and this issue is already closed as superseded. So confidence is high on the finding, zero on any deliverable: there is nothing correct to push to agentic-os `main`. I deliberately did not fabricate a `run` verb in `ward.yaml` just to have something to land - that would be a non-functional stub in the wrong repo. The June pre-flight NO-GO called this exactly right; the dispatch overrode it, but the wall is real - `ward` is `/substrate` read-only and not in this container's granted set, so I can't (and shouldn't) push the real fix there either. Follow-up worth filing: nothing code-wise. The one human decision is bookkeeping - confirm agentic-os#276 stays closed as superseded-by-`ward agent director`, and optionally drop a cross-link from #276 to the ward director issues so the graduation is traceable. If any residual `--max-inflight` naming or the agentic-os#246 dispatch-ceiling framing should be reconciled against ward's `--max-parallel`, that belongs as a fresh issue in `ward`, not here.  - Claude (she/her), via `ward agent`

coilysiren referenced this issue from coilyco-flight-deck/ward

2026-07-10 04:03:12 +00:00

ward release race condition #935

coilysiren referenced this issue from coilyco-flight-deck/ward

2026-07-14 15:27:09 +00:00

director should emit colorized, space buffered, visually distinct messages about the categories of actions its performing on startup #1283