Make director-surface advisor dispatch fire-and-forget like engineer dispatch

coilyco-ops commented

2026-07-09 00:36:06 +00:00

Member

Problem

Director-surface advisor dispatch has drifted into a synchronous watched launch through the broker. In practice the surface agent runs warded advisor ..., then sits on that process waiting for broker/launch output instead of firing the advisor and returning control to the director heartbeat.

That is the opposite of the desired capture-and-dispatch behavior. Advisors, like engineers, should be fire-and-forget from a read-only director surface unless the operator explicitly asks for a watched or one-shot answer.

Observed

From a Codex director surface on 2026-07-09:

The agent filed coilyco-flight-deck/ward#721 as a consult/design issue.
The agent ran HOME=/scratch/home warded advisor coilyco-flight-deck/ward#721 --harness codex.
The command printed only issue-ref resolution, then blocked with no detach confirmation for multiple minutes.
Kai had to point out that advisor dispatch should be dispatched and backgrounded like engineer dispatch, not watched through the broker.
The surface interrupted the command with Ctrl-C.

Desired behavior

From a director surface:

warded advisor <ref> --harness <harness> should dispatch through the broker and return promptly once the sibling advisor run is launched or refused.
The default should be fire-and-forget, with the issue comment as the durable output.
A watched/synchronous advisor path should require an explicit flag or a different role/mode, not be the default from the director surface.
Engineer and advisor dispatch should have consistent broker UX for issue-ref runs: launch, print the host log path or dispatch id, return.

Acceptance

A director-surface advisor issue-ref dispatch returns promptly after launch, like engineer dispatch.
The command surfaces a useful launch/refusal result without requiring the director agent to keep polling stdout.
Existing freeform advisor one-shot behavior remains available where intentionally synchronous.
Tests cover broker/director advisor issue-ref dispatch so this does not regress again.

Filed from the read-only director surface after Kai corrected the behavior while warded advisor coilyco-flight-deck/ward#721 --harness codex was blocking.

## Problem Director-surface advisor dispatch has drifted into a synchronous watched launch through the broker. In practice the surface agent runs `warded advisor ...`, then sits on that process waiting for broker/launch output instead of firing the advisor and returning control to the director heartbeat. That is the opposite of the desired capture-and-dispatch behavior. Advisors, like engineers, should be fire-and-forget from a read-only director surface unless the operator explicitly asks for a watched or one-shot answer. ## Observed From a Codex director surface on 2026-07-09: * The agent filed `coilyco-flight-deck/ward#721` as a consult/design issue. * The agent ran `HOME=/scratch/home warded advisor coilyco-flight-deck/ward#721 --harness codex`. * The command printed only issue-ref resolution, then blocked with no detach confirmation for multiple minutes. * Kai had to point out that advisor dispatch should be dispatched and backgrounded like engineer dispatch, not watched through the broker. * The surface interrupted the command with Ctrl-C. ## Desired behavior From a director surface: * `warded advisor <ref> --harness <harness>` should dispatch through the broker and return promptly once the sibling advisor run is launched or refused. * The default should be fire-and-forget, with the issue comment as the durable output. * A watched/synchronous advisor path should require an explicit flag or a different role/mode, not be the default from the director surface. * Engineer and advisor dispatch should have consistent broker UX for issue-ref runs: launch, print the host log path or dispatch id, return. ## Acceptance * A director-surface advisor issue-ref dispatch returns promptly after launch, like engineer dispatch. * The command surfaces a useful launch/refusal result without requiring the director agent to keep polling stdout. * Existing freeform advisor one-shot behavior remains available where intentionally synchronous. * Tests cover broker/director advisor issue-ref dispatch so this does not regress again. Filed from the read-only director surface after Kai corrected the behavior while `warded advisor coilyco-flight-deck/ward#721 --harness codex` was blocking.

coilyco-ops added the

headless

P1

labels

2026-07-09 00:36:06 +00:00

coilyco-ops commented

2026-07-09 00:36:14 +00:00

Author

Member

🔒 Reserved by ward agent --harness codex — container engineer-codex-ward-722 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-09T00:36:12Z). 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#722 · branch issue-722 · harness codex · workflow pr
Run: engineer-codex-ward-722 · ward v0.470.0 · dispatched 2026-07-09T00:36:12Z
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.470.0).

— Codex, via ward agent

🔒 Reserved by `ward agent --harness codex` — container `engineer-codex-ward-722` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-09T00:36:12Z). 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#722` · branch `issue-722` · harness `codex` · workflow `pr` - **Run:** `engineer-codex-ward-722` · ward `v0.470.0` · dispatched `2026-07-09T00:36:12Z` - **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.470.0). </details>  — Codex, via `ward agent`

coilyco-ops commented

2026-07-09 00:44:59 +00:00

Author

Member

WARD-OUTCOME: blocked - review summary: blocked: codex: exit status 1

Review panel verdicts:

codex: ERROR: codex: exit status 1 (conf 0.00)
claude: ERROR: claude: exit status 1 (conf 0.00)
goose: ERROR: goose: exit status 1 (conf 0.00)

— Codex, via ward agent

WARD-OUTCOME: blocked - review summary: blocked: codex: exit status 1 Review panel verdicts: - codex: ERROR: codex: exit status 1 (conf 0.00) - claude: ERROR: claude: exit status 1 (conf 0.00) - goose: ERROR: goose: exit status 1 (conf 0.00)  — Codex, via `ward agent`

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

2026-07-09 00:46:30 +00:00

ward salvage: ward-salvage/ward-d18595f6 #725

coilyco-ops commented

2026-07-09 00:46:31 +00:00

Author

Member

⚠️ Reopened: this run's work did not land on `main`

An ephemeral ward container (codex mode) dispatched for this issue finished but its work was not merged to main, so the reaper preserved it on a branch before teardown and reopened the issue (a closing reference for #722 never reached main). Recover from the salvage branch below.

Repo: coilyco-flight-deck/ward
Salvage branch: ward-salvage/ward-d18595f6
Pull request: not opened - PR creation failed: forgejo: parse created pull request: unexpected end of JSON input
Reason: run workflow does not land on main (--workflow pr/patch-only)
Container uptime at reap: 10m (age of the baked Forgejo PAT snapshot; a long-lived container is likelier to carry a rotated token)

Reap diagnostics

--- reap diagnostics ---
ward version:      v0.470.0
version source:    pinned via WARD_VERSION/--ward-version (v0.470.0)
HEAD:              94e03f35fe54
origin/main:       a2a544f1a892
ancestry:          HEAD is NOT yet on origin/main - residual work remains to land
decision gate:     workflow does not land on main (--workflow pr/patch-only)
reason:            run workflow does not land on main (--workflow pr/patch-only)
provenance:        not read (workflow hold)
run-owned landed:  no
working tree:      clean
container uptime:  10m (baked Forgejo PAT age proxy)
--- end reap diagnostics ---

Recover

git fetch https://forgejo.coilysiren.me/coilyco-flight-deck/ward.git ward-salvage/ward-d18595f6
git checkout -b ward-salvage/ward-d18595f6 FETCH_HEAD

— Codex, via ward agent

## ⚠️ Reopened: this run's work did not land on `main` An ephemeral `ward container` (codex mode) dispatched for this issue finished but its work was **not merged to `main`**, so the reaper preserved it on a branch before teardown and reopened the issue (a closing reference for #722 never reached `main`). Recover from the salvage branch below. - **Repo:** `coilyco-flight-deck/ward` - **Salvage branch:** `ward-salvage/ward-d18595f6` - **Pull request:** not opened - PR creation failed: forgejo: parse created pull request: unexpected end of JSON input - **Reason:** run workflow does not land on main (--workflow pr/patch-only) - **Container uptime at reap:** 10m (age of the baked Forgejo PAT snapshot; a long-lived container is likelier to carry a rotated token) ## Reap diagnostics ``` --- reap diagnostics --- ward version: v0.470.0 version source: pinned via WARD_VERSION/--ward-version (v0.470.0) HEAD: 94e03f35fe54 origin/main: a2a544f1a892 ancestry: HEAD is NOT yet on origin/main - residual work remains to land decision gate: workflow does not land on main (--workflow pr/patch-only) reason: run workflow does not land on main (--workflow pr/patch-only) provenance: not read (workflow hold) run-owned landed: no working tree: clean container uptime: 10m (baked Forgejo PAT age proxy) --- end reap diagnostics --- ``` ## Recover ```bash git fetch https://forgejo.coilysiren.me/coilyco-flight-deck/ward.git ward-salvage/ward-d18595f6 git checkout -b ward-salvage/ward-d18595f6 FETCH_HEAD ```  — Codex, via `ward agent`

coilyco-ops commented

2026-07-09 17:55:38 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-09T17:55:37Z). 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#722 · branch issue-722 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-ward-722 · ward v0.493.0 · dispatched 2026-07-09T17:55:37Z
Comment thread: 2 included in the pre-flight read, 1 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-09T00:44:59Z), @coilyco-ops (2026-07-09T00:46:31Z)
- stripped: @coilyco-ops (2026-07-09T00:36:14Z)

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-722` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-09T17:55:37Z). 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#722` · branch `issue-722` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-722` · ward `v0.493.0` · dispatched `2026-07-09T17:55:37Z` - **Comment thread:** 2 included in the pre-flight read, 1 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-09T00:44:59Z), @coilyco-ops (2026-07-09T00:46:31Z) - stripped: @coilyco-ops (2026-07-09T00:36:14Z) 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 commit

2026-07-09 18:06:36 +00:00

fix: broker director-surface advisor refs fire-and-forget

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

2026-07-09 18:07:24 +00:00

Make director-surface advisor dispatch fire-and-forget like engineer dispatch #835

coilyco-ops closed this issue

2026-07-09 18:08:14 +00:00

coilyco-ops commented

2026-07-09 18:08:48 +00:00

Author

Member

WARD-OUTCOME: done ✅

details

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

The implementation felt routine after the broker path was isolated. Confidence: high. Surprise: the remote salvage branch already carried an older version of the same fix, so I merged it into the feature branch before landing. Follow-ups: none.

WARD-OUTCOME: done ✅ <details><summary>details</summary> workflow: pull-request-and-merge; review summary: skipped because review gate skipped by --skip-review / --no-review-gate The implementation felt routine after the broker path was isolated. Confidence: high. Surprise: the remote salvage branch already carried an older version of the same fix, so I merged it into the feature branch before landing. Follow-ups: none. </details>