coilyco-flight-deck/ward

Fork 0

Support issue-scoped warded director runs #980

New issue

Closed

opened 2026-07-10 09:05:53 +00:00 by coilyco-ops · 3 comments

coilyco-ops commented

2026-07-10 09:05:53 +00:00

Member

Problem

Infrastructure#520 requires a director invocation that is scoped to one exact issue, not a whole repo backlog:

warded director coilysiren/inbox#123 \
  --harness goose \
  --engineer-harness goose \
  --max-parallel 1 \
  --no-triage \
  --poll-interval 5s

The current ward agent director help and implementation are repo-scoped: scope is provided by --repo, --org, or cwd origin, and docs mention warded director #98 even though the live director path is backlog-oriented. For the first-run acceptance loop, that is too broad: the evaluation issue must be the only candidate exposed to the dispatch decision, and the director must never select a different backlog item.

A Goose engineer on infrastructure#520 is currently building the broader k3s acceptance harness. This ward child issue isolates the core Ward behavior that harness depends on.

Do

Teach ward agent director / warded director to accept an issue ref or full Forgejo issue URL as its positional scope.
Derive the repository scope from that ref.
Fetch and validate exactly that issue before entering the heartbeat.
Require the issue to be open, eligible for autonomous/headless execution, and not already reserved.
Expose only that issue to the director dispatch decision.
Refuse or exit cleanly if the issue is closed, ineligible, already reserved, or cannot be resolved.
Ensure --no-triage leaves labels untouched in this mode.
Update help/docs that currently imply warded director #N support so they match the implementation.

Acceptance

A focused test proves warded director owner/repo#N --harness goose --engineer-harness goose --max-parallel 1 --no-triage --poll-interval 5s considers only issue N.
A full Forgejo issue URL follows the same path.
Closed, non-headless/ineligible, and already-reserved issues fail with explicit messages and do not dispatch anything else.
Repo backlog issues beside the target issue are not fetched into or selected by the dispatch decision.
ward exec test passes, or a comment names the exact failing check.

## Problem Infrastructure#520 requires a director invocation that is scoped to one exact issue, not a whole repo backlog: ```bash warded director coilysiren/inbox#123 \ --harness goose \ --engineer-harness goose \ --max-parallel 1 \ --no-triage \ --poll-interval 5s ``` The current `ward agent director` help and implementation are repo-scoped: scope is provided by `--repo`, `--org`, or cwd origin, and docs mention `warded director #98` even though the live director path is backlog-oriented. For the first-run acceptance loop, that is too broad: the evaluation issue must be the only candidate exposed to the dispatch decision, and the director must never select a different backlog item. A Goose engineer on infrastructure#520 is currently building the broader k3s acceptance harness. This ward child issue isolates the core Ward behavior that harness depends on. ## Do * Teach `ward agent director` / `warded director` to accept an issue ref or full Forgejo issue URL as its positional scope. * Derive the repository scope from that ref. * Fetch and validate exactly that issue before entering the heartbeat. * Require the issue to be open, eligible for autonomous/headless execution, and not already reserved. * Expose only that issue to the director dispatch decision. * Refuse or exit cleanly if the issue is closed, ineligible, already reserved, or cannot be resolved. * Ensure `--no-triage` leaves labels untouched in this mode. * Update help/docs that currently imply `warded director #N` support so they match the implementation. ## Acceptance * A focused test proves `warded director owner/repo#N --harness goose --engineer-harness goose --max-parallel 1 --no-triage --poll-interval 5s` considers only issue `N`. * A full Forgejo issue URL follows the same path. * Closed, non-headless/ineligible, and already-reserved issues fail with explicit messages and do not dispatch anything else. * Repo backlog issues beside the target issue are not fetched into or selected by the dispatch decision. * `ward exec test` passes, or a comment names the exact failing check. Related: coilyco-flight-deck/infrastructure#520.

coilyco-ops added the

headless

labels

2026-07-10 09:05:53 +00:00

coilyco-ops commented

2026-07-10 09:06:03 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-goose-ward-980 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness goose (reserved 2026-07-10T09:06:02Z). 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#980 · branch issue-980 · harness goose · workflow pull-requests-and-merge
Run: engineer-goose-ward-980 · ward v0.573.0 · dispatched 2026-07-10T09:06:02Z
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.573.0).

— Goose, via ward agent

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

coilyco-ops referenced this issue from coilyco-flight-deck/infrastructure

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

Make the Ward director evaluation executable, not a blueprint #523

coilyco-ops referenced this issue

2026-07-10 09:27:46 +00:00

Implement issue-scoped director behavior, not parse-only acceptance #988

coilyco-ops commented

2026-07-10 23:34:06 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

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

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-980` on host `KAI-DESKTOP-TOWER`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T23:34:06Z). 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#980` · branch `issue-980` · harness `codex` · workflow `pull-requests-and-merge` - **Run:** `engineer-codex-ward-980` · ward `v0.605.0` · dispatched `2026-07-10T23:34:06Z` - **Comment thread:** 0 included in the pre-flight read, 1 stripped (ward's own automated comments). - stripped: @coilyco-ops (2026-07-10T09:06:03Z) 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:43:10 +00:00

Support issue-scoped warded director runs #1107

coilyco-ops commented

2026-07-10 23:44:18 +00:00

Author

Member

WARD-OUTCOME: submitted

details

workflow: pull-request-and-merge; review summary: review gate was intentionally skipped because the temporary ward default pending brokered QA
feel: the implementation was mostly a narrow refactor, with one real bug where the heartbeat refresh widened back to the repo backlog
confidence: high
surprise: the live director merge sweep needed an explicit issue-scope guard too
follow-up: the PR is green and ready for director merge

WARD-OUTCOME: submitted <details><summary>details</summary> workflow: pull-request-and-merge; review summary: review gate was intentionally skipped because the temporary ward default pending brokered QA feel: the implementation was mostly a narrow refactor, with one real bug where the heartbeat refresh widened back to the repo backlog confidence: high surprise: the live director merge sweep needed an explicit issue-scope guard too follow-up: the PR is green and ready for director merge </details>

coilyco-ops closed this issue

2026-07-10 23:45:07 +00:00