Surface broker dispatch logs to every dispatcher path #1336

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

Parent

ward#1077

What to build

Make broker dispatch logs reach the dispatcher consistently. The dispatcher may be a director or an engineer requesting a downstream run, and both paths should receive the broker acceptance, deferral, or refusal reason without digging through host logs.

Acceptance criteria

  • Director dispatch sees the broker log for its request.
  • Engineer-requested downstream dispatch sees the broker log for its request.
  • Broker log output includes enough context to act: accepted, deferred, refused, target issue or PR, and the gate that decided it.
  • Tests or fixtures cover both dispatcher paths.
  • Host-only log output is not the only copy of the dispatch decision.

Decision for headless carry

This was split out of ward#1077 so broker-to-dispatcher log routing can be verified independently from pre-flight-to-dispatchee routing.

## Parent ward#1077 ## What to build Make broker dispatch logs reach the dispatcher consistently. The dispatcher may be a director or an engineer requesting a downstream run, and both paths should receive the broker acceptance, deferral, or refusal reason without digging through host logs. ## Acceptance criteria - [ ] Director dispatch sees the broker log for its request. - [ ] Engineer-requested downstream dispatch sees the broker log for its request. - [ ] Broker log output includes enough context to act: accepted, deferred, refused, target issue or PR, and the gate that decided it. - [ ] Tests or fixtures cover both dispatcher paths. - [ ] Host-only log output is not the only copy of the dispatch decision. ## Decision for headless carry This was split out of ward#1077 so broker-to-dispatcher log routing can be verified independently from pre-flight-to-dispatchee routing.
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.
Author
Member

WARDED_WORKFLOW: reservation-held

reservation details

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

Accepted by ward agent --harness codex (reserved 2026-07-15T11:17:42Z). 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#1336 · branch issue-1336 · harness codex · workflow pull-request-and-merge
  • Run: engineer-codex-ward-1336 · ward v0.710.0 · dispatched 2026-07-15T11:17:35Z
  • Comment thread: 1 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.710.0).

— Codex, via ward agent

<!-- ward-agent-reservation --> WARDED_WORKFLOW: reservation-held <details><summary>reservation details</summary> Holder: launch intent for container `engineer-codex-ward-1336` on host `kais-macbook-pro-2.local`. Accepted by `ward agent --harness codex` (reserved 2026-07-15T11:17:42Z). 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#1336` · branch `issue-1336` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-1336` · ward `v0.710.0` · dispatched `2026-07-15T11:17:35Z` - **Comment thread:** 1 included in the pre-flight read, 0 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-15T07:16:44Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.710.0). </details> </details> <!-- ward-agent-signature --> — Codex, via `ward agent`
Author
Member

WARDED_WORKFLOW: #1405

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

felt: narrow and mechanical. The advisor broker branch already had the right launch-response primitive; the fix was mostly aligning it with the structured log line. confidence: high. surprise: the dead helper vanished immediately once lint ran. follow-ups: none.

WARDED_WORKFLOW: https://forgejo.coilysiren.me/coilyco-flight-deck/ward/pulls/1405 <details><summary>details</summary> workflow: pull-request-and-merge; review summary: skipped (in-container review gate intentionally skipped because the temporary ward default pending brokered QA) felt: narrow and mechanical. The advisor broker branch already had the right launch-response primitive; the fix was mostly aligning it with the structured log line. confidence: high. surprise: the dead helper vanished immediately once lint ran. follow-ups: none. </details> <!-- ward-agent-signature -->
Author
Member

QA PASS after merge of PR #1405.

Verified against the acceptance criteria on main commit 541c5c1fa1:

  • Director-surface engineer dispatch already used sendDispatchBrokerRequest and dispatchBrokerForwardedLine, so the dispatcher receives the broker response line and host log path when available.
  • Advisor ref-dispatch no longer uses the old fire-and-forget helper. It now waits for sendDispatchBrokerLaunchRequest, preserves broker errors with dispatch log paths, and prints dispatchBrokerForwardedLine on success.
  • The visible line includes the forwarded ward agent command with the target issue/ref plus either the host dispatch log path or a deterministic ward agent logs lookup.
  • Existing broker paths still surface deferred/refused gate context, including capacity-defer, reservation-collision, release-assets-not-ready, and launch failure/refusal messages.
  • Tests cover the existing engineer dispatch line helper and the newly fixed advisor ref-dispatch path, including the host log path on success and broker-response waiting.

Evidence:

  • PR #1405 merged at 2026-07-15T11:27:26Z with merge commit 541c5c1fa1.
  • Forgejo test run 8503 succeeded for pull_request #1405.
  • Local scratch verification passed: go test ./cmd/ward -run Test.*Broker|Test.*Advisor|Test.*Dispatch.
QA PASS after merge of PR #1405. Verified against the acceptance criteria on main commit 541c5c1fa1ee8e6461343109488aa1dff6a632c9: - Director-surface engineer dispatch already used sendDispatchBrokerRequest and dispatchBrokerForwardedLine, so the dispatcher receives the broker response line and host log path when available. - Advisor ref-dispatch no longer uses the old fire-and-forget helper. It now waits for sendDispatchBrokerLaunchRequest, preserves broker errors with dispatch log paths, and prints dispatchBrokerForwardedLine on success. - The visible line includes the forwarded ward agent command with the target issue/ref plus either the host dispatch log path or a deterministic ward agent logs lookup. - Existing broker paths still surface deferred/refused gate context, including capacity-defer, reservation-collision, release-assets-not-ready, and launch failure/refusal messages. - Tests cover the existing engineer dispatch line helper and the newly fixed advisor ref-dispatch path, including the host log path on success and broker-response waiting. Evidence: - PR #1405 merged at 2026-07-15T11:27:26Z with merge commit 541c5c1fa1ee8e6461343109488aa1dff6a632c9. - Forgejo test run 8503 succeeded for pull_request #1405. - Local scratch verification passed: go test ./cmd/ward -run Test.*Broker|Test.*Advisor|Test.*Dispatch.
Sign in to join this conversation.
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
coilyco-flight-deck/ward#1336
No description provided.