Promote the backlog-loop WARD-OUTCOME marker into the ward headless seed #310

New issue

Closed

opened 2026-06-25 05:38:35 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-06-25 05:38:35 +00:00

Member

Context

ward exec backlog-loop (agentic-os, shipped in ffd33ec) drives a supervised ralph loop over a repo backlog. Its return path needs a first-class signal from a headless run - today there is none (a detached ward agent headless is fire-and-forget with no host-side completion or blocker channel; outcomes are only inferable from main-moved / salvage-issue / retro-comment).

The loop adds one: at dispatch it posts a protocol comment telling the agent to end with a final comment whose first line is one of:

WARD-OUTCOME: done
WARD-OUTCOME: blocked - <the single decision or fact it needs from a human>
WARD-OUTCOME: failed - <why>

poll parses that line to classify the run (done / blocked / failed) and drive the unblock conversation. This works today with zero ward change because resolveAgentWork folds issue comments into the seed, so the agent reads the instruction.

The ask

Promote the WARD-OUTCOME: instruction into the ward headless seed so it is native and the loop's injected dispatch comment can drop.

The natural home is right next to the existing retrospective instruction: headlessReflectionAction (cmd/ward/agent.go ~line 149), appended to the headless seed in agentSeedPrompt (~line 196). Fold the structured outcome line into that same final comment - lead the retro with WARD-OUTCOME: <status> then the candid prose - so #281's retro and this channel are one comment, one final action.

Acceptance

A headless run's final issue comment leads with a WARD-OUTCOME: done|blocked|failed line, no loop-injected protocol comment required.
backlog-loop's poll classifies it unchanged (the parser is already marker-based).
The retro (#281) is preserved as the body of that same comment.

Refs

backlog-loop backbone + protocol: coilyco-flight-deck/agentic-os scripts/backlog-loop.py, docs/backlog-loop.md, skill tooling-backlog-loop (ffd33ec).
Consumes the heartbeat loop (agentic-os#237) and dispatch ceiling gate (agentic-os#246) axes.
Retro seed instruction to fold into: ward#281.

## Context `ward exec backlog-loop` (agentic-os, shipped in ffd33ec) drives a supervised ralph loop over a repo backlog. Its return path needs a first-class signal from a headless run - today there is none (a detached `ward agent headless` is fire-and-forget with no host-side completion or blocker channel; outcomes are only inferable from main-moved / salvage-issue / retro-comment). The loop adds one: at dispatch it posts a protocol comment telling the agent to end with a final comment whose first line is one of: ``` WARD-OUTCOME: done WARD-OUTCOME: blocked - <the single decision or fact it needs from a human> WARD-OUTCOME: failed - <why> ``` `poll` parses that line to classify the run (done / blocked / failed) and drive the unblock conversation. This works **today with zero ward change** because `resolveAgentWork` folds issue comments into the seed, so the agent reads the instruction. ## The ask Promote the `WARD-OUTCOME:` instruction into the ward **headless seed** so it is native and the loop's injected dispatch comment can drop. The natural home is right next to the existing retrospective instruction: `headlessReflectionAction` (cmd/ward/agent.go ~line 149), appended to the headless seed in `agentSeedPrompt` (~line 196). Fold the structured outcome line into that same final comment - lead the retro with `WARD-OUTCOME: <status>` then the candid prose - so #281's retro and this channel are one comment, one final action. ## Acceptance - A headless run's final issue comment leads with a `WARD-OUTCOME: done|blocked|failed` line, no loop-injected protocol comment required. - backlog-loop's `poll` classifies it unchanged (the parser is already marker-based). - The retro (#281) is preserved as the body of that same comment. ## Refs - backlog-loop backbone + protocol: coilyco-flight-deck/agentic-os `scripts/backlog-loop.py`, `docs/backlog-loop.md`, skill `tooling-backlog-loop` (ffd33ec). - Consumes the heartbeat loop (agentic-os#237) and dispatch ceiling gate (agentic-os#246) axes. - Retro seed instruction to fold into: ward#281.

coilysiren referenced this issue

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

agent: implement basic 'ward agent backlog' - an autonomous supervised loop (first slice of ward#324, subsumes ward#310) #346

coilysiren commented

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

Owner

Subsumed by ward#346 (basic ward agent backlog): that run bakes the WARD-OUTCOME line into the headless seed (folded into the ward#281 retro comment), which is exactly this ask. Close this when ward#346 lands.

coilysiren added the

headless

labels

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

coilyco-ops commented

2026-07-01 04:41: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.

latest maintainer comment marks this subsumed by ward#346 with instructions to "close when #346 lands" - a human must confirm whether #346 already shipped the seed change (making this a close, not an implement) before any unattended run.

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 read

Context to front-load: The work touches the ward headless seed assembly - headlessReflectionAction and agentSeedPrompt in cmd/ward/agent.go (folding a WARD-OUTCOME: line into the existing retro instruction), plus the dispatch/seed wiring documented in docs/agent.md, docs/agent-preflight.md, and .agents/skills/tooling-ward-agent/SKILL.md, and the dev-verb surface in docs/exec-verb.md / .ward/ward.yaml. I would read each of these in the fresh clone before the first edit, and specifically diff the current headlessReflectionAction against what #346 may have already landed.

Main risk / unknown: The maintainer's own latest comment (coilysiren, 2026-06-25) supersedes the original ask: this issue is subsumed by ward#346, which "bakes the WARD-OUTCOME line into the headless seed (folded into the ward#281 retro comment), which is exactly this ask," with the explicit instruction to "Close this when ward#346 lands." So the terminal action here is a close, not an implementation - and if #346 has already landed, the seed change is already present and an unattended run would either no-op, duplicate, or conflict with it. Whether #346 has landed is exactly the human decision this hinges on, and it is not answerable from the issue text alone. Dispatching detached risks re-implementing work that already exists or churning a marker that's already native.

NO-GO: latest maintainer comment marks this subsumed by ward#346 with instructions to "close when #346 lands" - a human must confirm whether #346 already shipped the seed change (making this a close, not an implement) before any unattended run.

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. > latest maintainer comment marks this subsumed by ward#346 with instructions to "close when #346 lands" - a human must confirm whether #346 already shipped the seed change (making this a close, not an implement) before any unattended run. 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 read **Context to front-load:** The work touches the ward headless seed assembly - `headlessReflectionAction` and `agentSeedPrompt` in `cmd/ward/agent.go` (folding a `WARD-OUTCOME:` line into the existing retro instruction), plus the dispatch/seed wiring documented in `docs/agent.md`, `docs/agent-preflight.md`, and `.agents/skills/tooling-ward-agent/SKILL.md`, and the dev-verb surface in `docs/exec-verb.md` / `.ward/ward.yaml`. I would read each of these in the fresh clone before the first edit, and specifically diff the current `headlessReflectionAction` against what #346 may have already landed. **Main risk / unknown:** The maintainer's own latest comment (coilysiren, 2026-06-25) supersedes the original ask: this issue is **subsumed by ward#346**, which "bakes the WARD-OUTCOME line into the headless seed (folded into the ward#281 retro comment), which is exactly this ask," with the explicit instruction to "Close this when ward#346 lands." So the terminal action here is a close, not an implementation - and if #346 has already landed, the seed change is already present and an unattended run would either no-op, duplicate, or conflict with it. Whether #346 has landed is exactly the human decision this hinges on, and it is not answerable from the issue text alone. Dispatching detached risks re-implementing work that already exists or churning a marker that's already native. NO-GO: latest maintainer comment marks this subsumed by ward#346 with instructions to "close when #346 lands" - a human must confirm whether #346 already shipped the seed change (making this a close, not an implement) before any unattended run. </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:35:21 +00:00