PR-pressure redispatch should accept PR refs without hidden branch flags

coilyco-ops commented

2026-07-13 04:04:14 +00:00

Member

When open PR backpressure is engaged, ward currently rejects an existing PR ref and tells the operator to continue with --branch instead. That forces director surfaces and operators to know a hidden branch-dispatch path while the documented command surface already accepts owner/repo!N PR refs.

Observed from a director surface on 2026-07-13:

warded engineer coilyco-flight-deck/ward!1148 --harness codex ... resolved the PR ref to coilyco-flight-deck/ward#1148, then rejected the dispatch with open PR backpressure is engaged ... continue with --branch on an existing PR or wait for the queue to drain.
ward agent engineer --help documents owner/repo!N, but does not list --branch.
The installed binary contains --branch, so the broker hint points at an available but hidden interface.
A probe using ward agent engineer coilyco-flight-deck/ward#988 --harness codex --branch issue-1141 --print attempted a broker launch instead of behaving like a print-only plan, which makes the hidden escape hatch risky to discover interactively.

Wanted behavior:

A PR ref such as owner/repo!1148 should count as an existing-branch continuation for the open-PR backpressure gate.
If --branch remains a supported escape hatch, it should be documented in ward agent engineer --help with clear semantics.
--print must remain non-launching when combined with branch-continuation options.
The backpressure error should suggest documented, safe command forms only.

This is distinct from normal capacity pressure: the goal is to keep director surfaces draining existing PR branches without opening more PRs and without relying on hidden flags.

When open PR backpressure is engaged, ward currently rejects an existing PR ref and tells the operator to continue with `--branch` instead. That forces director surfaces and operators to know a hidden branch-dispatch path while the documented command surface already accepts `owner/repo!N` PR refs. Observed from a director surface on 2026-07-13: * `warded engineer coilyco-flight-deck/ward!1148 --harness codex ...` resolved the PR ref to `coilyco-flight-deck/ward#1148`, then rejected the dispatch with `open PR backpressure is engaged ... continue with --branch on an existing PR or wait for the queue to drain`. * `ward agent engineer --help` documents `owner/repo!N`, but does not list `--branch`. * The installed binary contains `--branch`, so the broker hint points at an available but hidden interface. * A probe using `ward agent engineer coilyco-flight-deck/ward#988 --harness codex --branch issue-1141 --print` attempted a broker launch instead of behaving like a print-only plan, which makes the hidden escape hatch risky to discover interactively. Wanted behavior: * A PR ref such as `owner/repo!1148` should count as an existing-branch continuation for the open-PR backpressure gate. * If `--branch` remains a supported escape hatch, it should be documented in `ward agent engineer --help` with clear semantics. * `--print` must remain non-launching when combined with branch-continuation options. * The backpressure error should suggest documented, safe command forms only. This is distinct from normal capacity pressure: the goal is to keep director surfaces draining existing PR branches without opening more PRs and without relying on hidden flags.

coilyco-ops commented

2026-07-13 09:23:26 +00:00

Author

Member

Status note from the burn-down session: unblocked but unchanged. The session cleared the PR pressure that was refusing redispatch, so this lane works again in practice. The ergonomic fix this issue asks for, accepting PR refs without hidden branch flags, is still wanted and still open.

coilyco-ops added the

P2

headless

labels

2026-07-14 06:50:07 +00:00

coilysiren referenced this issue

2026-07-14 15:27:09 +00:00

director should emit colorized, space buffered, visually distinct messages about the categories of actions its performing on startup #1283

coilyco-ops commented

2026-07-15 01:22:00 +00:00

Author

Member

WARDED_WORKFLOW: reservation-held

reservation details

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

Accepted by ward agent --harness codex (reserved 2026-07-15T01:21:59Z). 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#1166 · branch issue-1166 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-ward-1166 · ward v0.693.0 · dispatched 2026-07-15T01:21:42Z
Comment thread: 1 included in the pre-flight read, 0 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-13T09:23:26Z)

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

— Codex, via ward agent

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

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

2026-07-15 05:14:53 +00:00

coilyco-ops commented

2026-07-15 06:55:18 +00:00

Author

Member

Release triage note from Kai on 2026-07-15: headless carry is valid. PR-pressure redispatch should accept a PR ref directly, resolve the branch internally, and stop requiring hidden branch flags or operator knowledge of continuation internals.

coilyco-ops commented

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

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.

coilyco-ops commented

2026-07-15 12:54:50 +00:00

Author

Member

WARDED_WORKFLOW: reservation-held

reservation details

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

Accepted by ward agent --harness codex (reserved 2026-07-15T12:54:49Z). 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#1166 · branch issue-1166 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-ward-1166 · ward v0.710.0 · dispatched 2026-07-15T12:54:41Z
Comment thread: 3 included in the pre-flight read, 1 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-13T09:23:26Z), @coilyco-ops (2026-07-15T06:55:18Z), @coilyco-ops (2026-07-15T07:16:34Z)
- stripped: @coilyco-ops (2026-07-15T01:22:00Z)

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-1166` on host `kais-macbook-pro-2.local`. Accepted by `ward agent --harness codex` (reserved 2026-07-15T12:54:49Z). 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#1166` · branch `issue-1166` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-1166` · ward `v0.710.0` · dispatched `2026-07-15T12:54:41Z` - **Comment thread:** 3 included in the pre-flight read, 1 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-13T09:23:26Z), @coilyco-ops (2026-07-15T06:55:18Z), @coilyco-ops (2026-07-15T07:16:34Z) - stripped: @coilyco-ops (2026-07-15T01:22:00Z) 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 13:01:09 +00:00

Preserve PR refs through brokered engineer dispatch #1442

coilyco-ops referenced this issue

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

Resolve PR #1442 merge conflict after main advanced #1444

coilyco-ops referenced this issue

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

Recover PR #1442 merge 405 after green checks #1445

coilyco-ops referenced this issue

2026-07-15 13:09:25 +00:00

Resolve PR #1442 merge conflict after main advanced #1444