coilyco-flight-deck/ward

Fork 0

Preserve workflow and details through director dispatch broker #763

New issue

Closed

opened 2026-07-09 05:04:22 +00:00 by coilyco-ops · 5 comments

coilyco-ops commented

2026-07-09 05:04:22 +00:00

Member

The director surface dispatched repair runs with explicit --workflow direct-main and --details ..., but the host broker forwarded only ward agent engineer <ref> --harness codex --force.

Observed from a read-only director surface on 2026-07-09:

Command attempted for agentic-os#356: warded engineer coilyco-flight-deck/agentic-os#356 --harness codex --workflow direct-main --force --details "Repair after PR #357 landed..."
Broker output: forwarded \ward agent engineer coilyco-flight-deck/agentic-os#356 --harness codex --force` to host ward`
Reservation comment confirms workflow pr, not direct-main.
Same behavior reproduced for agentic-os#362 and ward#760.

Impact: a director trying to repair a PR pile cannot select the landing workflow or pass fresh repair instructions through the broker. The launched agents may run the wrong landing policy and miss the critical correction context.

Acceptance criteria:

Preserve explicit --workflow through the director/surface dispatch broker.
Preserve --details or fail loudly if the broker cannot forward it.
Add coverage for at least one broker-forwarded engineer command carrying both flags.
Keep secret-bearing args out of logs, but non-secret workflow/details should not silently disappear.

The director surface dispatched repair runs with explicit `--workflow direct-main` and `--details ...`, but the host broker forwarded only `ward agent engineer <ref> --harness codex --force`. Observed from a read-only director surface on 2026-07-09: * Command attempted for `agentic-os#356`: `warded engineer coilyco-flight-deck/agentic-os#356 --harness codex --workflow direct-main --force --details "Repair after PR #357 landed..."` * Broker output: `forwarded \`ward agent engineer coilyco-flight-deck/agentic-os#356 --harness codex --force\` to host ward` * Reservation comment confirms `workflow pr`, not `direct-main`. * Same behavior reproduced for `agentic-os#362` and `ward#760`. Impact: a director trying to repair a PR pile cannot select the landing workflow or pass fresh repair instructions through the broker. The launched agents may run the wrong landing policy and miss the critical correction context. Acceptance criteria: * Preserve explicit `--workflow` through the director/surface dispatch broker. * Preserve `--details` or fail loudly if the broker cannot forward it. * Add coverage for at least one broker-forwarded engineer command carrying both flags. * Keep secret-bearing args out of logs, but non-secret workflow/details should not silently disappear.

coilyco-ops commented

2026-07-09 05:04:26 +00:00

Author

Member

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

— Codex, via ward agent

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

coilyco-ops commented

2026-07-09 05:12:40 +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 commented

2026-07-09 05:13:40 +00:00

Author

Member

WARD-OUTCOME: blocked - review gate failed closed on auth-unavailable reviewers
workflow: pr; review summary: blocked: codex: exit status 1

The broker fix landed, but the in-container review gate could not run a usable panel. Codex failed to authenticate, the fallback reviewers failed the same way, and the gate correctly blocked instead of passing on a non-review.
Review verdict: WARD-REVIEW: block - 0/2 passing (class default)
Reviewer reasons: codex: exit status 1; claude: exit status 1; goose: exit status 1

WARD-OUTCOME: blocked - review gate failed closed on auth-unavailable reviewers workflow: pr; review summary: blocked: codex: exit status 1 The broker fix landed, but the in-container review gate could not run a usable panel. Codex failed to authenticate, the fallback reviewers failed the same way, and the gate correctly blocked instead of passing on a non-review. Review verdict: WARD-REVIEW: block - 0/2 passing (class default) Reviewer reasons: codex: exit status 1; claude: exit status 1; goose: exit status 1

coilyco-ops commented

2026-07-09 05:28:08 +00:00

Author

Member

🔒 Reserved by ward agent --harness codex — container engineer-codex-ward-763 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-09T05:28:07Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h TTL); --force overrides.

run seed context — what this run is carrying (ward#609)

Resolved: coilyco-flight-deck/ward#763 · branch issue-763 · harness codex · workflow pr
Run: engineer-codex-ward-763 · ward v0.474.0 · dispatched 2026-07-09T05:28:07Z
Comment thread: 2 included in the pre-flight read, 1 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-09T05:12:40Z), @coilyco-ops (2026-07-09T05:13:40Z)
- stripped: @coilyco-ops (2026-07-09T05:04:26Z)

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

— Codex, via ward agent

🔒 Reserved by `ward agent --harness codex` — container `engineer-codex-ward-763` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-09T05:28:07Z). 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#763` · branch `issue-763` · harness `codex` · workflow `pr` - **Run:** `engineer-codex-ward-763` · ward `v0.474.0` · dispatched `2026-07-09T05:28:07Z` - **Comment thread:** 2 included in the pre-flight read, 1 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-09T05:12:40Z), @coilyco-ops (2026-07-09T05:13:40Z) - stripped: @coilyco-ops (2026-07-09T05:04:26Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.474.0). </details>  — Codex, via `ward agent`

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

2026-07-09 05:32:44 +00:00

Preserve workflow and details through director dispatch broker #765

coilyco-ops commented

2026-07-09 05:32:59 +00:00

Author

Member

WARD-OUTCOME: done - preserved workflow and details through the director broker
workflow: pr; review summary: review gate skipped by --skip-review / --no-review-gate

The change stayed small and local. The only part that fought back was the broker logging path, because once workflow/details were threaded through I also had to keep secret-shaped argv out of the surface and host logs, so I added a redaction helper and a test for that boundary.

Confidence is high. I don’t see a follow-up in this patch, but it would be worth checking whether any other broker-forwarded argv surfaces should reuse the same redacted display helper.

WARD-OUTCOME: done - preserved workflow and details through the director broker workflow: pr; review summary: review gate skipped by --skip-review / --no-review-gate The change stayed small and local. The only part that fought back was the broker logging path, because once workflow/details were threaded through I also had to keep secret-shaped argv out of the surface and host logs, so I added a redaction helper and a test for that boundary. Confidence is high. I don’t see a follow-up in this patch, but it would be worth checking whether any other broker-forwarded argv surfaces should reuse the same redacted display helper.

coilyco-ops closed this issue

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