Add qa as an opt-in dispatch broker role #812

New issue

Closed

opened 2026-07-09 16:16:38 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-09 16:16:38 +00:00

Member

Goal

Add qa as a dispatch broker role for ward agent containers.

This is the first implementation slice after the brokered QA discussion in ward#792. The important behavior for this slice is intentionally modest:

qa is a dispatch broker role, alongside the existing brokered roles such as engineer, director, and advisor.
QA is opt-in for the initial implementation. Do not make ordinary engineer/director flows require QA by default yet.
QA failure should be recorded and surfaced, but it should not block landing or otherwise fail closed in this first slice. Proceed on QA failure until the later gating design is implemented deliberately.

Desired shape

A user or orchestrator should be able to dispatch something like:

ward agent qa coilyco-flight-deck/ward#N --harness codex

The exact CLI spelling should follow the existing role parsing and broker conventions in ward. The role should launch as a brokered container with a QA-oriented seed prompt and durable issue output.

Scope

Add qa to the role vocabulary accepted by the dispatch broker and local ward agent command path.
Add seed/context wording appropriate for a QA container: inspect the candidate issue/branch/PR/checks, report a structured QA verdict, and avoid implementation edits unless the existing role model requires otherwise.
Preserve current role behavior for engineer, director, and advisor.
Keep QA opt-in. No automatic director merge gate should require QA yet.
Initial QA failures should be non-blocking. The caller should be able to see the failure, but the workflow should proceed by default.
Add tests for role parsing, broker forwarding, prompt/seed role selection, and non-blocking failure behavior where that surface exists.
Update docs and docs/FEATURES.md if the role becomes a user-facing capability.

Acceptance

ward agent qa <owner/repo>#<N> is accepted and reaches the dispatch broker/container planning path.
The dispatched container is identifiable as role qa in names, labels, logs, or whatever role markers ward already uses.
QA is never required by default for existing engineer/director workflows.
A failed QA run does not block the original landing workflow in this initial implementation.
Tests cover the new role and the opt-in/proceed-on-failure contract.
Repo validation passes through ward.

Context

Kai specifically called out that the engineer may not infer the important constraints: QA should be opt-in, and the initial implementation should proceed on failure. Those constraints are part of this issue, not follow-up polish.

Related: ward#792.

## Goal Add `qa` as a dispatch broker role for ward agent containers. This is the first implementation slice after the brokered QA discussion in ward#792. The important behavior for this slice is intentionally modest: * `qa` is a dispatch broker role, alongside the existing brokered roles such as `engineer`, `director`, and `advisor`. * QA is opt-in for the initial implementation. Do not make ordinary engineer/director flows require QA by default yet. * QA failure should be recorded and surfaced, but it should not block landing or otherwise fail closed in this first slice. Proceed on QA failure until the later gating design is implemented deliberately. ## Desired shape A user or orchestrator should be able to dispatch something like: ```sh ward agent qa coilyco-flight-deck/ward#N --harness codex ``` The exact CLI spelling should follow the existing role parsing and broker conventions in ward. The role should launch as a brokered container with a QA-oriented seed prompt and durable issue output. ## Scope * Add `qa` to the role vocabulary accepted by the dispatch broker and local `ward agent` command path. * Add seed/context wording appropriate for a QA container: inspect the candidate issue/branch/PR/checks, report a structured QA verdict, and avoid implementation edits unless the existing role model requires otherwise. * Preserve current role behavior for `engineer`, `director`, and `advisor`. * Keep QA opt-in. No automatic director merge gate should require QA yet. * Initial QA failures should be non-blocking. The caller should be able to see the failure, but the workflow should proceed by default. * Add tests for role parsing, broker forwarding, prompt/seed role selection, and non-blocking failure behavior where that surface exists. * Update docs and `docs/FEATURES.md` if the role becomes a user-facing capability. ## Acceptance * `ward agent qa <owner/repo>#<N>` is accepted and reaches the dispatch broker/container planning path. * The dispatched container is identifiable as role `qa` in names, labels, logs, or whatever role markers ward already uses. * QA is never required by default for existing engineer/director workflows. * A failed QA run does not block the original landing workflow in this initial implementation. * Tests cover the new role and the opt-in/proceed-on-failure contract. * Repo validation passes through ward. ## Context Kai specifically called out that the engineer may not infer the important constraints: QA should be opt-in, and the initial implementation should proceed on failure. Those constraints are part of this issue, not follow-up polish. Related: ward#792.

coilyco-ops commented

2026-07-09 16:16:48 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-ward-812 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-09T16:16:46Z). 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#812 · branch issue-812 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-ward-812 · ward v0.493.0 · dispatched 2026-07-09T16:16:46Z
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.493.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-812` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-09T16:16:46Z). 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#812` · branch `issue-812` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-812` · ward `v0.493.0` · dispatched `2026-07-09T16:16:46Z` - **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.493.0). </details> </details>  — Codex, via `ward agent`

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

2026-07-09 16:38:46 +00:00

Add qa as an opt-in dispatch broker role #816

coilyco-ops closed this issue

2026-07-09 16:40:02 +00:00

coilyco-ops commented

2026-07-09 16:40:22 +00:00

Author

Member

WARD-OUTCOME: done ✅

details

workflow: pull-request-and-merge; review summary: skipped; review gate skipped by --skip-review / --no-review-gate

felt: straightforward once the QA role wiring matched the existing advisor/broker patterns

confidence: high

surprises: the repo's commit hooks required a small docs size trim outside the feature surface

follow-ups: none

WARD-OUTCOME: done ✅ <details><summary>details</summary> workflow: pull-request-and-merge; review summary: skipped; review gate skipped by --skip-review / --no-review-gate felt: straightforward once the QA role wiring matched the existing advisor/broker patterns confidence: high surprises: the repo's commit hooks required a small docs size trim outside the feature surface follow-ups: none </details>