[tracking] graduate backlog-loop into `ward agent backlog` #324

New issue

Closed

opened 2026-06-25 08:55:30 +00:00 by coilyco-ops · 3 comments

coilyco-ops commented

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

Member

Surfaced while driving ward exec backlog-loop over ward + cli-guard for the first time. The loop is already just a supervisor wrapped around ward agent headless, and several of its load-bearing pieces are admitted hacks in the script's own docstring. This tracks promoting it from a ward exec python script in agentic-os into a first-class ward agent backlog <scope> (or warded supervisor) command.

Why graduate

The WARD-OUTCOME outcome protocol is injected as an issue comment at dispatch time because v1 needed no ward change. The clean home is the ward headless seed - already filed as ward#310.
All forgejo I/O shells back out to ward ops forgejo; dispatch shells ward agent headless with a 600s timeout and string-parses the error. A native command owns the dispatch fork directly.
Arg ergonomics today: ward exec backlog-loop -- --repo X select - the -- wall, --repo having to precede the verb, no default verb. All of these evaporate under a native command with real flag parsing.

End state

ward agent backlog <scope> with native flags.
The outcome marker baked into the headless seed (ward#310) instead of an injected issue comment.
The dispatch ceiling enforced at the native dispatch fork (agentic-os#246), not bolted on.
Scope as a ward type: one supervised view across a set of repos (e.g. {ward, cli-guard}) instead of one --repo string at a time. ward routinely pushes issues down into cli-guard (ward#269 extracts helpers there), so the loop should span both.

Incremental path - the quick-win issues filed on agentic-os (run-verb + ceiling, select re-queue fix, triage coupling, multi-repo scope) are the exact surface that graduates cleanly. Land them in the script now, move the surface into ward when it stabilizes. Links: ward#310, agentic-os#237 (heartbeat loop), agentic-os#246 (dispatch ceiling).

Surfaced while driving `ward exec backlog-loop` over ward + cli-guard for the first time. The loop is already just a supervisor wrapped around `ward agent headless`, and several of its load-bearing pieces are admitted hacks in the script's own docstring. This tracks promoting it from a `ward exec` python script in agentic-os into a first-class `ward agent backlog <scope>` (or `warded` supervisor) command. **Why graduate** - The `WARD-OUTCOME` outcome protocol is injected as an **issue comment** at dispatch time because v1 needed no ward change. The clean home is the ward headless seed - already filed as ward#310. - All forgejo I/O shells back out to `ward ops forgejo`; dispatch shells `ward agent headless` with a 600s timeout and string-parses the error. A native command owns the dispatch fork directly. - Arg ergonomics today: `ward exec backlog-loop -- --repo X select` - the `--` wall, `--repo` having to precede the verb, no default verb. All of these evaporate under a native command with real flag parsing. **End state** - `ward agent backlog <scope>` with native flags. - The outcome marker baked into the headless seed (ward#310) instead of an injected issue comment. - The dispatch ceiling enforced at the native dispatch fork (agentic-os#246), not bolted on. - **Scope as a ward type**: one supervised view across a set of repos (e.g. {ward, cli-guard}) instead of one `--repo` string at a time. ward routinely pushes issues down into cli-guard (ward#269 extracts helpers there), so the loop should span both. **Incremental path** - the quick-win issues filed on agentic-os (run-verb + ceiling, select re-queue fix, triage coupling, multi-repo scope) are the exact surface that graduates cleanly. Land them in the script now, move the surface into ward when it stabilizes. Links: ward#310, agentic-os#237 (heartbeat loop), agentic-os#246 (dispatch ceiling).

coilyco-ops commented

2026-06-25 09:58:44 +00:00

Author

Member

🛫 ward pre-flight: NO-GO

ward agent headless --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.

tracking/umbrella issue with unbuilt design (scope-as-ward-type, native flag set) gated on unlanded prerequisites (ward#310, agentic-os#246) whose source surface still lives in agentic-os - needs a human to slice a concrete first deliverable before unattended work.

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

full pre-flight read

Pre-flight read: ward#324

This is a [tracking] issue, and that label is doing real work here. It is not a single discrete deliverable but an umbrella that explicitly chains prerequisites - ward#310 (bake the outcome marker into the headless seed), agentic-os#246 (dispatch ceiling at the native fork), agentic-os#237 (heartbeat loop), plus the live source script that currently lives in agentic-os, not ward. The issue's own "incremental path" sets the sequencing: "Land them in the script now, move the surface into ward when it stabilizes" - i.e. the graduation is gated on prerequisite quick-wins landing in another repo first, and "scope as a ward type" is an unbuilt type design, not a coded surface to port. There is no settled spec for the native flag set, the dispatch-fork ownership, or the scope type, and no comments narrowing any of it.

Context to front-load: ward agent dispatch + headless pre-flight seed (docs/agent.md, docs/agent-preflight.md, .agents/skills/tooling-ward-agent/SKILL.md - where the outcome marker would be baked per ward#310); ward exec dev-verb surface and .ward/ward.yaml (docs/exec-verb.md - the current backlog-loop home and the flag-parsing target); ward-kdl guardfile generator (docs/ward-kdl.md, docs/ward-kdl-surface.md, docs/ward-kdl-in-ward.md - how a new ward agent backlog verb gets admitted). I would read each in the clone before any edit. But the binding problem is upstream of the read: the source script and the quick-win surface live in agentic-os and the tracking issue defers the ward move until they stabilize, so front-loading ward conventions does not close the gap that the graduate-able surface is not yet here.

The main risk is that an unattended run would have to invent the missing spec - native flag grammar, the scope ward-type, dispatch-fork wiring - and pick among open design forks the issue deliberately left to sequencing, while the prerequisites (ward#310, agentic-os#246) are not confirmed landed. That is exactly the costly-to-undo, multi-path fork that wants a human to scope and sequence first.

NO-GO: tracking/umbrella issue with unbuilt design (scope-as-ward-type, native flag set) gated on unlanded prerequisites (ward#310, agentic-os#246) whose source surface still lives in agentic-os - needs a human to slice a concrete first deliverable before unattended work.

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

— Claude (she/her), via ward agent

### 🛫 ward pre-flight: NO-GO `ward agent headless --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. > tracking/umbrella issue with unbuilt design (scope-as-ward-type, native flag set) gated on unlanded prerequisites (ward#310, agentic-os#246) whose source surface still lives in agentic-os - needs a human to slice a concrete first deliverable before unattended work. No container was launched. Review the issue (clarify the scope, resolve the unknown, or split it), then re-dispatch - `ward agent headless --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 read: ward#324 This is a **`[tracking]`** issue, and that label is doing real work here. It is not a single discrete deliverable but an umbrella that explicitly chains prerequisites - ward#310 (bake the outcome marker into the headless seed), agentic-os#246 (dispatch ceiling at the native fork), agentic-os#237 (heartbeat loop), plus the live source script that currently lives in **agentic-os**, not ward. The issue's own "incremental path" sets the sequencing: "Land them in the script now, move the surface into ward **when it stabilizes**" - i.e. the graduation is gated on prerequisite quick-wins landing in another repo first, and "scope as a ward type" is an unbuilt type design, not a coded surface to port. There is no settled spec for the native flag set, the dispatch-fork ownership, or the scope type, and no comments narrowing any of it. **Context to front-load:** ward agent dispatch + headless pre-flight seed (docs/agent.md, docs/agent-preflight.md, .agents/skills/tooling-ward-agent/SKILL.md - where the outcome marker would be baked per ward#310); ward exec dev-verb surface and .ward/ward.yaml (docs/exec-verb.md - the current backlog-loop home and the flag-parsing target); ward-kdl guardfile generator (docs/ward-kdl.md, docs/ward-kdl-surface.md, docs/ward-kdl-in-ward.md - how a new `ward agent backlog` verb gets admitted). I would read each in the clone before any edit. But the binding problem is upstream of the read: the source script and the quick-win surface live in agentic-os and the tracking issue defers the ward move until they stabilize, so front-loading ward conventions does not close the gap that the graduate-able surface is not yet here. The main risk is that an unattended run would have to **invent** the missing spec - native flag grammar, the scope ward-type, dispatch-fork wiring - and pick among open design forks the issue deliberately left to sequencing, while the prerequisites (ward#310, agentic-os#246) are not confirmed landed. That is exactly the costly-to-undo, multi-path fork that wants a human to scope and sequence first. NO-GO: tracking/umbrella issue with unbuilt design (scope-as-ward-type, native flag set) gated on unlanded prerequisites (ward#310, agentic-os#246) whose source surface still lives in agentic-os - needs a human to slice a concrete first deliverable before unattended work. </details> --- Posted automatically by `ward agent headless --driver claude` pre-flight (ward#147, ward#149).   — Claude (she/her), via `ward agent`

coilysiren commented

2026-06-25 18:56:17 +00:00

Owner

First concrete slice sliced + specced with Kai: ward#346 - the basic ward agent backlog as an AUTONOMOUS loop (sub-verbs not exposed on the CLI), comma-list scope, reusing ward native dispatch internals, baking the WARD-OUTCOME marker into the headless seed (subsumes ward#310). This is the spec this umbrella lacked when it bounced pre-flight NO-GO. Deferred to later layers: named scope-as-a-ward-type, the chatty auto-unblock conversation, the full dispatch-ceiling axis, retiring the agentic-os script.

coilysiren added the

interactive

labels

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

coilyco-ops referenced this issue

2026-07-02 00:17:07 +00:00

warded director: consult-to-headless conversion flow (decision interview that upgrades tickets to dispatchable) #493

coilyco-ops referenced this issue

2026-07-02 00:17:56 +00:00

Warded burn down that starts with a triage pass then walks an issue tracker until it's complete #295

coilysiren referenced this issue

2026-07-03 18:15:54 +00:00

warded director: consult-to-headless conversion flow (decision interview that upgrades tickets to dispatchable) #493

coilysiren commented

2026-07-06 18:59:35 +00:00

Owner

Re-spec: the graduation already landed as 'ward agent director' (agent_director.go, ward#347/#346/#310), so the 'ward agent backlog' name/marker premise is void. The deferred layers (scope-as-ward-type, auto-unblock, dispatch-ceiling) stay valid but need fresh framing against the landed director. Re-triage 2026-07-06.

coilysiren closed this issue

2026-07-06 20:10:07 +00:00