Make director broker-unavailable failures actionable

coilyco-ops commented

2026-07-15 06:39:57 +00:00

Owner

Parent

ward#1013

What to build

When a director surface cannot reach the host dispatch broker, ward should fail with one actionable diagnostic instead of a loaded live-repair problem. This issue does not require proving the current host broker is healthy.

Acceptance criteria

warded ps or the ward-native equivalent reports broker-unavailable errors with the broker address source, connection failure, and one next remediation step.
Engineer/director dispatch attempts fail before creating a reservation when the broker cannot be reached.
The failure output distinguishes broker-unreachable, broker-timeout, and capacity-defer states.
A test or fixture simulates a refused WARD_DISPATCH_BROKER_ADDR connection.
The PR body names any live verification that a sealed engineer cannot perform.

Non-goals

Do not debug or restart the live host broker from a sealed engineer run.
Do not fold global engineer capacity fixes into this issue.
Do not claim broker health without an observable live surface.

Decision for headless carry

Kai confirmed ward#1013 is too loaded and likely to make an engineer miss the goal. This child carries one deliverable: actionable diagnostics for director broker-unavailable failures.

## Parent ward#1013 ## What to build When a director surface cannot reach the host dispatch broker, ward should fail with one actionable diagnostic instead of a loaded live-repair problem. This issue does not require proving the current host broker is healthy. ## Acceptance criteria - [ ] `warded ps` or the ward-native equivalent reports broker-unavailable errors with the broker address source, connection failure, and one next remediation step. - [ ] Engineer/director dispatch attempts fail before creating a reservation when the broker cannot be reached. - [ ] The failure output distinguishes broker-unreachable, broker-timeout, and capacity-defer states. - [ ] A test or fixture simulates a refused `WARD_DISPATCH_BROKER_ADDR` connection. - [ ] The PR body names any live verification that a sealed engineer cannot perform. ## Non-goals - Do not debug or restart the live host broker from a sealed engineer run. - Do not fold global engineer capacity fixes into this issue. - Do not claim broker health without an observable live surface. ## Decision for headless carry Kai confirmed ward#1013 is too loaded and likely to make an engineer miss the goal. This child carries one deliverable: actionable diagnostics for director broker-unavailable failures.

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

2026-07-15 06:39:57 +00:00

coilyco-ops added the

labels

2026-07-15 06:39:57 +00:00

coilyco-ops commented

2026-07-15 07:08:46 +00:00

Author

Owner

P1 clarity note from Kai on 2026-07-15: an advisor pre-flight research step should handle the exact remediation wording and diagnostic taxonomy before implementation. The engineer should not invent a live-repair flow. The deliverable remains actionable broker-unavailable diagnostics, with advisor research used to pin the message shape.

coilyco-ops commented

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

Author

Owner

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 07:16:51 +00:00

Author

Owner

WARD-TRIAGE: coherence-core label

This issue is part of the coherence-core review set for the warded control plane coherence sprint. Treat it as release-spine work: it should directly improve the safety, capacity, configuration coherence, observability, or recovery loop that makes director burndown trustworthy.

Core does not mean broader scope. Keep the implementation narrow, verify current main before reusing prior failed PRs, and split any design fork or lower-confidence follow-up out of the core path.

WARD-TRIAGE: coherence-core label This issue is part of the `coherence-core` review set for the `warded control plane coherence` sprint. Treat it as release-spine work: it should directly improve the safety, capacity, configuration coherence, observability, or recovery loop that makes director burndown trustworthy. Core does not mean broader scope. Keep the implementation narrow, verify current `main` before reusing prior failed PRs, and split any design fork or lower-confidence follow-up out of the core path.

coilyco-ops removed the

autonomy

headless

label

2026-07-15 07:39:26 +00:00

coilyco-ops commented

2026-07-15 07:39:26 +00:00

Author

Owner

WARD-DIRECTOR: demoted from headless

This issue is not immediately dispatchable in the headless lane because the latest clarity note requires advisor pre-flight research to settle the remediation wording and diagnostic taxonomy. The headless label has been removed while the issue remains coherence-core. Re-enter the headless lane after that research leaves a self-contained implementation contract.

WARD-DIRECTOR: demoted from headless This issue is not immediately dispatchable in the headless lane because the latest clarity note requires advisor pre-flight research to settle the remediation wording and diagnostic taxonomy. The `headless` label has been removed while the issue remains `coherence-core`. Re-enter the headless lane after that research leaves a self-contained implementation contract.

coilyco-ops commented

2026-07-15 08:04:29 +00:00

Author

Owner

🔎 ward agent advisor

ward agent advisor --harness codex ran a one-shot standard research pass on this question:

Read the issue title, body, and comment thread below as the research brief. Identify the decisions, options, open questions, and risks, then give a clear advisory recommendation that can be posted back on the issue.

Advisory recommendation

Keep this issue as a narrow same-repo implementation in coilyco-flight-deck/ward. The right fix is a small typed dispatch-broker diagnostic layer, not a host repair flow and not a capacity-system rewrite.

Current behavior to change

The current read-only broker paths already have most of the plumbing, but unreachable broker handling is too fail-open:

maybeForwardAgentDispatchToHostBroker returns (false, nil) when WARD_DISPATCH_BROKER_ADDR is set but hostDispatchBrokerReachable fails, so ref-mode engineer/advisor/QA dispatch can fall through to the local launch path.
forwardFreeformEngineerLaunchToHostBroker has the same fallback after the freeform issue is filed.
prWorkflowForwarded also skips the broker on unreachable address and falls back to the direct PR workflow path.
ward agent list / alias ps and ward agent logs swallow errDispatchBrokerUnavailable and fall back to local host reads, which hides the surface problem.
Existing tests named TestForwardAgentDispatchToHostBrokerSkipsUnreachableBroker and TestPRWorkflowForwardedSkipsUnreachableBroker pin the behavior this issue wants to retire.

Recommended taxonomy

Use three explicit operator-facing states:

broker-unreachable: WARD_DISPATCH_BROKER_ADDR is present, but TCP connect fails immediately, such as connection refused, no route, DNS/host failure, or wrong gateway address.
broker-timeout: dialing or waiting for the broker response exceeds the bounded timeout/context. This is different from refusal because the address may exist but the broker or gateway is wedged.
capacity-defer: the broker is reachable and host ward answered, but the host-side launch refused because the engineer pool is full. This should stay backpressure, not broker failure.

Suggested output shape for broker contact failures:

ward dispatch broker: broker-unreachable
address source: WARD_DISPATCH_BROKER_ADDR=127.0.0.1:54321
connection: dial tcp 127.0.0.1:54321: connect: connection refused
remediation: exit this director surface and start a fresh `warded director ...` session so host ward creates a new dispatch broker address.

For a dial deadline:

ward dispatch broker: broker-timeout
address source: WARD_DISPATCH_BROKER_ADDR=host.docker.internal:54321
connection: timed out dialing TCP after 250ms
remediation: exit this director surface and start a fresh `warded director ...` session so host ward creates a new dispatch broker address.

For capacity:

ward dispatch broker: capacity-defer
capacity: engineer pool full, 10/10 active launches, not dispatched
remediation: wait for one running engineer to finish, then let the director retry.

The remediation should deliberately stop there. Do not tell a sealed engineer to restart or debug the live host broker. The PR body should explicitly say live host-broker health was not verified from the sealed engineer container.

Implementation contract

Recommended option: add a typed helper rather than scattering string-only errors.

Replace or wrap hostDispatchBrokerReachable(ctx, addr) bool with a richer probe/result, for example probeHostDispatchBroker(ctx, addr) dispatchBrokerDiagnostic or (ok bool, diag *dispatchBrokerDiagnostic).
The diagnostic should carry at least kind, addrSource (WARD_DISPATCH_BROKER_ADDR), addr, original connection error text, and one remediation string.
Keep errDispatchBrokerUnavailable as the sentinel if useful, but attach kind/source/detail in a structured type so callers can render consistent text and tests can assert classification without brittle full-string matching.
When WARD_DISPATCH_BROKER_ADDR is set and WARD_READONLY=1, brokered dispatch should be mandatory. If probing or sending fails with broker-unavailable/timeout, return a handled error and do not fall through to local launch.
Keep the no-broker case unchanged: if there is no broker env, host-side direct operation can proceed normally.
warded ps should be satisfied by the existing ward agent list / ps alias. In a read-only surface with broker env set, list should render the broker diagnostic instead of falling back to local renderAgentList.
Apply the same mandatory-broker rule to logs, stop, and PR workflow forwarding for consistency, but the acceptance criteria only require ps/list plus dispatch attempts.
For freeform engineer mode, it is acceptable that the new issue is already filed before broker forwarding is attempted; the hard requirement is that no reservation or launch intent is created when broker contact fails.

Tests to add or update

Replace TestForwardAgentDispatchToHostBrokerSkipsUnreachableBroker with a refused-connection fixture that expects a handled broker diagnostic and proves local launch is not attempted.
Replace TestPRWorkflowForwardedSkipsUnreachableBroker with the same expectation for PR workflow verbs.
Add or update a ward agent list / ps test with WARD_DISPATCH_BROKER_ADDR pointing at a closed listener. It should report broker-unreachable, include WARD_DISPATCH_BROKER_ADDR=<addr>, include the connection failure, and avoid local Docker fallback.
Add a timeout fixture if practical by dialing an unroutable test address under a short context or by injecting a test dialer; assert broker-timeout separately from broker-unreachable.
Add a reservation guard regression: with broker env present but refused, a ref-mode engineer/director dispatch must return before reserveIssue or any launch-intent comment/sentinel can be created.
Keep or extend the existing capacity tests around newEngineerCapacityError / commentDispatchLaunchError so capacity remains capacity-defer and does not look like broker-unreachable.

Open decisions

Timeout value: the existing probe timeout is 250ms. I would keep it for the initial TCP reachability diagnostic unless tests show flakes; if changed, make it a named constant and include the duration in timeout output.
Scope of read surfaces: acceptance names warded ps or equivalent. I recommend fixing list/ps, logs, stop, and PR workflow forwarding together because they share the same broker contract and currently have similar fallback behavior.
Exit code: no new exit code is necessary unless the maintainers want broker-unavailable to become part of docs/agent-dispatch-contract.md. A generic launch failure with a strong diagnostic is enough for this issue.

Risks

The biggest risk is leaving one fallback path in place. A read-only director with a stale broker env must not silently try local Docker or direct Forgejo paths.
Do not post issue comments for broker-unreachable/timeout. Those failures happen before a host-side launch is accepted and should stay local to the director surface.
Do not conflate capacity with broker health. Capacity-defer means the broker and host ward are alive enough to answer.
Be careful with advisor fire-and-forget: it does not need to wait for launch completion, but it must still fail loudly if it cannot connect to the broker at all.

Live verification note for the PR

The PR body should say something like: Live host broker health was not verified from the sealed engineer container; verification was limited to unit fixtures for refused/timeout broker addresses and existing broker response tests. A real host-surface check requires an observable director session on the host.

Researched and posted automatically by ward agent advisor --harness codex (ward#179). This is one-shot research, not a carried change - verify before acting on it.

— Codex, via ward agent

### 🔎 ward agent advisor `ward agent advisor --harness codex` ran a one-shot **standard** research pass on this question: > Read the issue title, body, and comment thread below as the research brief. Identify the decisions, options, open questions, and risks, then give a clear advisory recommendation that can be posted back on the issue. --- ## Advisory recommendation Keep this issue as a narrow same-repo implementation in `coilyco-flight-deck/ward`. The right fix is a small typed dispatch-broker diagnostic layer, not a host repair flow and not a capacity-system rewrite. ### Current behavior to change The current read-only broker paths already have most of the plumbing, but unreachable broker handling is too fail-open: - `maybeForwardAgentDispatchToHostBroker` returns `(false, nil)` when `WARD_DISPATCH_BROKER_ADDR` is set but `hostDispatchBrokerReachable` fails, so ref-mode engineer/advisor/QA dispatch can fall through to the local launch path. - `forwardFreeformEngineerLaunchToHostBroker` has the same fallback after the freeform issue is filed. - `prWorkflowForwarded` also skips the broker on unreachable address and falls back to the direct PR workflow path. - `ward agent list` / alias `ps` and `ward agent logs` swallow `errDispatchBrokerUnavailable` and fall back to local host reads, which hides the surface problem. - Existing tests named `TestForwardAgentDispatchToHostBrokerSkipsUnreachableBroker` and `TestPRWorkflowForwardedSkipsUnreachableBroker` pin the behavior this issue wants to retire. ### Recommended taxonomy Use three explicit operator-facing states: - `broker-unreachable`: `WARD_DISPATCH_BROKER_ADDR` is present, but TCP connect fails immediately, such as connection refused, no route, DNS/host failure, or wrong gateway address. - `broker-timeout`: dialing or waiting for the broker response exceeds the bounded timeout/context. This is different from refusal because the address may exist but the broker or gateway is wedged. - `capacity-defer`: the broker is reachable and host ward answered, but the host-side launch refused because the engineer pool is full. This should stay backpressure, not broker failure. Suggested output shape for broker contact failures: ```text ward dispatch broker: broker-unreachable address source: WARD_DISPATCH_BROKER_ADDR=127.0.0.1:54321 connection: dial tcp 127.0.0.1:54321: connect: connection refused remediation: exit this director surface and start a fresh `warded director ...` session so host ward creates a new dispatch broker address. ``` For a dial deadline: ```text ward dispatch broker: broker-timeout address source: WARD_DISPATCH_BROKER_ADDR=host.docker.internal:54321 connection: timed out dialing TCP after 250ms remediation: exit this director surface and start a fresh `warded director ...` session so host ward creates a new dispatch broker address. ``` For capacity: ```text ward dispatch broker: capacity-defer capacity: engineer pool full, 10/10 active launches, not dispatched remediation: wait for one running engineer to finish, then let the director retry. ``` The remediation should deliberately stop there. Do not tell a sealed engineer to restart or debug the live host broker. The PR body should explicitly say live host-broker health was not verified from the sealed engineer container. ### Implementation contract Recommended option: add a typed helper rather than scattering string-only errors. - Replace or wrap `hostDispatchBrokerReachable(ctx, addr) bool` with a richer probe/result, for example `probeHostDispatchBroker(ctx, addr) dispatchBrokerDiagnostic` or `(ok bool, diag *dispatchBrokerDiagnostic)`. - The diagnostic should carry at least `kind`, `addrSource` (`WARD_DISPATCH_BROKER_ADDR`), `addr`, original connection error text, and one remediation string. - Keep `errDispatchBrokerUnavailable` as the sentinel if useful, but attach kind/source/detail in a structured type so callers can render consistent text and tests can assert classification without brittle full-string matching. - When `WARD_DISPATCH_BROKER_ADDR` is set and `WARD_READONLY=1`, brokered dispatch should be mandatory. If probing or sending fails with broker-unavailable/timeout, return a handled error and do not fall through to local launch. - Keep the no-broker case unchanged: if there is no broker env, host-side direct operation can proceed normally. - `warded ps` should be satisfied by the existing `ward agent list` / `ps` alias. In a read-only surface with broker env set, `list` should render the broker diagnostic instead of falling back to local `renderAgentList`. - Apply the same mandatory-broker rule to `logs`, `stop`, and PR workflow forwarding for consistency, but the acceptance criteria only require `ps`/list plus dispatch attempts. - For freeform engineer mode, it is acceptable that the new issue is already filed before broker forwarding is attempted; the hard requirement is that no reservation or launch intent is created when broker contact fails. ### Tests to add or update - Replace `TestForwardAgentDispatchToHostBrokerSkipsUnreachableBroker` with a refused-connection fixture that expects a handled broker diagnostic and proves local launch is not attempted. - Replace `TestPRWorkflowForwardedSkipsUnreachableBroker` with the same expectation for PR workflow verbs. - Add or update a `ward agent list` / `ps` test with `WARD_DISPATCH_BROKER_ADDR` pointing at a closed listener. It should report `broker-unreachable`, include `WARD_DISPATCH_BROKER_ADDR=<addr>`, include the connection failure, and avoid local Docker fallback. - Add a timeout fixture if practical by dialing an unroutable test address under a short context or by injecting a test dialer; assert `broker-timeout` separately from `broker-unreachable`. - Add a reservation guard regression: with broker env present but refused, a ref-mode engineer/director dispatch must return before `reserveIssue` or any launch-intent comment/sentinel can be created. - Keep or extend the existing capacity tests around `newEngineerCapacityError` / `commentDispatchLaunchError` so capacity remains `capacity-defer` and does not look like broker-unreachable. ### Open decisions - Timeout value: the existing probe timeout is `250ms`. I would keep it for the initial TCP reachability diagnostic unless tests show flakes; if changed, make it a named constant and include the duration in timeout output. - Scope of read surfaces: acceptance names `warded ps` or equivalent. I recommend fixing `list`/`ps`, `logs`, `stop`, and PR workflow forwarding together because they share the same broker contract and currently have similar fallback behavior. - Exit code: no new exit code is necessary unless the maintainers want broker-unavailable to become part of `docs/agent-dispatch-contract.md`. A generic launch failure with a strong diagnostic is enough for this issue. ### Risks - The biggest risk is leaving one fallback path in place. A read-only director with a stale broker env must not silently try local Docker or direct Forgejo paths. - Do not post issue comments for broker-unreachable/timeout. Those failures happen before a host-side launch is accepted and should stay local to the director surface. - Do not conflate capacity with broker health. Capacity-defer means the broker and host ward are alive enough to answer. - Be careful with advisor fire-and-forget: it does not need to wait for launch completion, but it must still fail loudly if it cannot connect to the broker at all. ### Live verification note for the PR The PR body should say something like: `Live host broker health was not verified from the sealed engineer container; verification was limited to unit fixtures for refused/timeout broker addresses and existing broker response tests. A real host-surface check requires an observable director session on the host.` --- Researched and posted automatically by `ward agent advisor --harness codex` (ward#179). This is one-shot research, not a carried change - verify before acting on it.   — Codex, via `ward agent`

coilyco-ops added the

autonomy

headless

label

2026-07-15 08:15:21 +00:00

coilyco-ops commented

2026-07-15 08:15:41 +00:00

Author

Owner

QA/ops director re-entered this issue into the headless lane after the advisor posted a self-contained implementation contract, then attempted dispatch at 2026-07-15T08:15Z.

Command attempted: warded engineer coilyco-flight-deck/ward#1342 --harness codex --workflow pull-request-and-merge.

Broker response: repo engineer limit reached for coilyco-flight-deck/ward, 3 active engineer(s), limit 3. Retry when a Ward engineer slot frees.

QA/ops director re-entered this issue into the headless lane after the advisor posted a self-contained implementation contract, then attempted dispatch at 2026-07-15T08:15Z. Command attempted: `warded engineer coilyco-flight-deck/ward#1342 --harness codex --workflow pull-request-and-merge`. Broker response: repo engineer limit reached for `coilyco-flight-deck/ward`, 3 active engineer(s), limit 3. Retry when a Ward engineer slot frees.

coilyco-ops commented

2026-07-15 08:17:47 +00:00

Author

Owner

WARDED_WORKFLOW: reservation-held

reservation details

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

Accepted by ward agent --harness codex (reserved 2026-07-15T08:17:46Z). 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#1342 · branch issue-1342 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-ward-1342 · ward v0.710.0 · dispatched 2026-07-15T08:17:38Z
Comment thread: 6 included in the pre-flight read, 0 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-15T07:08:46Z), @coilyco-ops (2026-07-15T07:16:46Z), @coilyco-ops (2026-07-15T07:16:51Z), @coilyco-ops (2026-07-15T07:39:26Z), @coilyco-ops (2026-07-15T08:04:29Z), @coilyco-ops (2026-07-15T08:15:41Z)

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-1342` on host `kais-macbook-pro-2.local`. Accepted by `ward agent --harness codex` (reserved 2026-07-15T08:17:46Z). 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#1342` · branch `issue-1342` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-1342` · ward `v0.710.0` · dispatched `2026-07-15T08:17:38Z` - **Comment thread:** 6 included in the pre-flight read, 0 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-15T07:08:46Z), @coilyco-ops (2026-07-15T07:16:46Z), @coilyco-ops (2026-07-15T07:16:51Z), @coilyco-ops (2026-07-15T07:39:26Z), @coilyco-ops (2026-07-15T08:04:29Z), @coilyco-ops (2026-07-15T08:15:41Z) 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 08:30:40 +00:00

Make broker-unavailable failures actionable #1354

coilyco-ops closed this issue

2026-07-15 08:33:26 +00:00

coilyco-ops commented

2026-07-15 08:34:35 +00:00

Author

Owner

QA verification after merged PR #1354 on 2026-07-15.

Checked the merged diff on current origin/main (fe8514ff29c6e1127a0a15841c6d5258a68c9b2c) against this issue acceptance:

ward agent list / ps now probes the read-only broker and returns a typed broker diagnostic instead of falling back to local Docker when WARD_DISPATCH_BROKER_ADDR is unreachable.
Ref-mode engineer dispatch now treats unreachable broker contact as handled and returns a diagnostic before falling into local launch/reservation behavior.
PR workflow and stop paths also use the same broker probe; freeform engineer forwarding is fail-closed after issue filing.
Diagnostics distinguish broker-unreachable, broker-timeout, and capacity backpressure now renders as capacity-defer.
The PR body explicitly says live host broker health was not verified from the sealed engineer container.

Focused verification run:

go test ./cmd/ward -run 'Test.*DispatchBroker|Test.*Broker|TestAgentList|TestAgentStop|TestPRWorkflowForwarded|TestForwardFreeformEngineerLaunch' -count=1

Result: passed. This satisfies #1342; no replacement issue needed for this acceptance.

QA verification after merged PR #1354 on 2026-07-15. Checked the merged diff on current `origin/main` (`fe8514ff29c6e1127a0a15841c6d5258a68c9b2c`) against this issue acceptance: - `ward agent list` / `ps` now probes the read-only broker and returns a typed broker diagnostic instead of falling back to local Docker when `WARD_DISPATCH_BROKER_ADDR` is unreachable. - Ref-mode engineer dispatch now treats unreachable broker contact as handled and returns a diagnostic before falling into local launch/reservation behavior. - PR workflow and stop paths also use the same broker probe; freeform engineer forwarding is fail-closed after issue filing. - Diagnostics distinguish `broker-unreachable`, `broker-timeout`, and capacity backpressure now renders as `capacity-defer`. - The PR body explicitly says live host broker health was not verified from the sealed engineer container. Focused verification run: ```bash go test ./cmd/ward -run 'Test.*DispatchBroker|Test.*Broker|TestAgentList|TestAgentStop|TestPRWorkflowForwarded|TestForwardFreeformEngineerLaunch' -count=1 ``` Result: passed. This satisfies #1342; no replacement issue needed for this acceptance.

coilyco-ops commented

2026-07-15 08:35:01 +00:00

Author

Owner

WARDED_WORKFLOW: #1354

details

workflow: pull-request-and-merge; review summary: skipped (review gate intentionally skipped because temporary ward default pending brokered QA)

felt: steady but broad enough to touch the dispatch gate, read surfaces, and diagnostics together; the only surprise was the lint pass forcing the diagnostic kind switch and a flatter list path.

confidence: high
surprises: Forgejo's merge API returned a blank JSON stub even though the PR merged cleanly.
follow-ups: none unless you want the same broker diagnostic wording mirrored in other read-only surfaces.

WARDED_WORKFLOW: https://forgejo.coilysiren.me/coilyco-flight-deck/ward/pulls/1354 <details><summary>details</summary> workflow: pull-request-and-merge; review summary: skipped (review gate intentionally skipped because temporary ward default pending brokered QA) felt: steady but broad enough to touch the dispatch gate, read surfaces, and diagnostics together; the only surprise was the lint pass forcing the diagnostic kind switch and a flatter list path. confidence: high surprises: Forgejo's merge API returned a blank JSON stub even though the PR merged cleanly. follow-ups: none unless you want the same broker diagnostic wording mirrored in other read-only surfaces. </details>

coilyco-ops referenced this issue

2026-07-15 10:12:56 +00:00

Exclude closed issues from director dispatch proposals #1381

Rows
Columns

Make director broker-unavailable failures actionable #1342

Parent

What to build

Acceptance criteria

Non-goals

Decision for headless carry

🔎 ward agent advisor

Advisory recommendation

Current behavior to change

Recommended taxonomy

Implementation contract

Tests to add or update

Open decisions

Risks

Live verification note for the PR