coilyco-flight-deck/ward

Fork 0

Define broker and pre-flight check placement matrix #1334

New issue

Closed

opened 2026-07-15 06:33:59 +00:00 by coilyco-ops · 3 comments

coilyco-ops commented

2026-07-15 06:33:59 +00:00

Member

Parent

ward#1077

What to build

Define the check-placement matrix for broker-time and pre-flight validation. The goal is to make each dispatch guard explicit and decide whether it belongs at the broker, at pre-flight, or at both layers when state can drift while work is queued.

Acceptance criteria

The broker/pre-flight check set is enumerated in a committed docs or help surface.
Each check is marked broker-only, pre-flight-only, or both.
Checks that guard driftable state, such as reservations, PR pressure, branch state, or capacity, are duplicated intentionally.
The documented matrix explains why duplicated checks are defense against queue-time drift.
Existing dispatch/pre-flight tests or docs are updated to match the matrix.

Decision for headless carry

This was split out of ward#1077 so an engineer can land the placement contract without also implementing log routing.

## Parent ward#1077 ## What to build Define the check-placement matrix for broker-time and pre-flight validation. The goal is to make each dispatch guard explicit and decide whether it belongs at the broker, at pre-flight, or at both layers when state can drift while work is queued. ## Acceptance criteria - [ ] The broker/pre-flight check set is enumerated in a committed docs or help surface. - [ ] Each check is marked broker-only, pre-flight-only, or both. - [ ] Checks that guard driftable state, such as reservations, PR pressure, branch state, or capacity, are duplicated intentionally. - [ ] The documented matrix explains why duplicated checks are defense against queue-time drift. - [ ] Existing dispatch/pre-flight tests or docs are updated to match the matrix. ## Decision for headless carry This was split out of ward#1077 so an engineer can land the placement contract without also implementing log routing.

coilyco-ops added this to the warded control plane coherence milestone

2026-07-15 06:33:59 +00:00

coilyco-ops added the

headless

labels

2026-07-15 06:33:59 +00:00

coilyco-ops commented

2026-07-15 07:16:42 +00:00

Author

Member

WARD-TRIAGE: warded control plane coherence milestone

This issue is part of the warded control plane coherence sprint. The release thesis is to make warded feel like one dependable control plane for agent work: higher safe parallelism, coherent config defaults, reliable broker/container behavior, human-feedback gates, and enough structured evidence for the next actor after a paused or failed run.

For this sprint, headless means an engineer should be able to carry the issue from current issue context to a merged change without new human decisions. If the issue discovers a missing decision, split or demote the unclear part instead of guessing.

WARD-TRIAGE: warded control plane coherence milestone This issue is part of the `warded control plane coherence` sprint. The release thesis is to make `warded` feel like one dependable control plane for agent work: higher safe parallelism, coherent config defaults, reliable broker/container behavior, human-feedback gates, and enough structured evidence for the next actor after a paused or failed run. For this sprint, `headless` means an engineer should be able to carry the issue from current issue context to a merged change without new human decisions. If the issue discovers a missing decision, split or demote the unclear part instead of guessing.

coilyco-ops commented

2026-07-15 11:18:45 +00:00

Author

Member

WARDED_WORKFLOW: reservation-held

reservation details

Holder: launch intent for container engineer-codex-ward-1334 on host kais-macbook-pro-2.local.

Accepted by ward agent --harness codex (reserved 2026-07-15T11:18:44Z). Concurrent ward agent runs are blocked until this intent becomes visible or the intent is released. The stale-intent fallback is still TTL-bounded (3h TTL). --override-reservation 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#1334 · branch issue-1334 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-ward-1334 · ward v0.710.0 · dispatched 2026-07-15T11:18:38Z
Comment thread: 1 included in the pre-flight read, 0 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-15T07:16:42Z)

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

— Codex, via ward agent

WARDED_WORKFLOW: reservation-held <details><summary>reservation details</summary> Holder: launch intent for container `engineer-codex-ward-1334` on host `kais-macbook-pro-2.local`. Accepted by `ward agent --harness codex` (reserved 2026-07-15T11:18:44Z). Concurrent `ward agent` runs are blocked until this intent becomes visible or the intent is released. The stale-intent fallback is still TTL-bounded (3h TTL). `--override-reservation` 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#1334` · branch `issue-1334` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-1334` · ward `v0.710.0` · dispatched `2026-07-15T11:18:38Z` - **Comment thread:** 1 included in the pre-flight read, 0 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-15T07:16:42Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.710.0). </details> </details>  — Codex, via `ward agent`

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

2026-07-15 11:24:55 +00:00

Define broker and pre-flight check placement matrix #1404

coilyco-ops closed this issue

2026-07-15 11:27:44 +00:00

coilyco-ops commented

2026-07-15 11:28:11 +00:00

Author

Member

QA PASS after merge of PR #1404.

Verified against the acceptance criteria on main commit 511cbc093f:

docs/agent-check-placement.md enumerates the broker-time and pre-flight launch guard set.
Each documented row is grouped as broker-only, pre-flight-only, or both.
The both section names reservation conflict, open-PR backpressure, branch-state / continuation-branch checks, repo engineer capacity, and the global engineer pool ceiling as duplicated launch guards.
The duplicated-row explanation explicitly frames those checks as defense against queue-time drift.
Existing dispatch/pre-flight docs are cross-linked from docs/README.md, docs/agent.md, docs/agent-lifecycle.md, docs/agent-dispatch-broker.md, and docs/agent-preflight.md.

Evidence:

PR #1404 merged at 2026-07-15T11:27:43Z with merge commit 511cbc093f.
Forgejo test run 8502 succeeded for pull_request #1404.
Local scratch review confirmed the docs-only diff. A broad local go test ./cmd/ward/... run is not counted as a failure for this PR because it hit existing ambient read-only/director-sensitive test failures outside the docs diff.

QA PASS after merge of PR #1404. Verified against the acceptance criteria on main commit 511cbc093f7050646f4c105711310d306995e199: - docs/agent-check-placement.md enumerates the broker-time and pre-flight launch guard set. - Each documented row is grouped as broker-only, pre-flight-only, or both. - The both section names reservation conflict, open-PR backpressure, branch-state / continuation-branch checks, repo engineer capacity, and the global engineer pool ceiling as duplicated launch guards. - The duplicated-row explanation explicitly frames those checks as defense against queue-time drift. - Existing dispatch/pre-flight docs are cross-linked from docs/README.md, docs/agent.md, docs/agent-lifecycle.md, docs/agent-dispatch-broker.md, and docs/agent-preflight.md. Evidence: - PR #1404 merged at 2026-07-15T11:27:43Z with merge commit 511cbc093f7050646f4c105711310d306995e199. - Forgejo test run 8502 succeeded for pull_request #1404. - Local scratch review confirmed the docs-only diff. A broad local go test ./cmd/ward/... run is not counted as a failure for this PR because it hit existing ambient read-only/director-sensitive test failures outside the docs diff.

coilyco-ops referenced this issue

2026-07-15 11:30:35 +00:00

Repair failed promote run after PR #1404 #1406