coilyco-flight-deck/ward

Fork 0

Director burn-down should rebase or update green nonmergeable PR branches above the PR cap #1172

New issue

Closed

opened 2026-07-13 04:23:51 +00:00 by coilyco-ops · 4 comments

coilyco-ops commented

2026-07-13 04:23:51 +00:00

Member

Problem

The director burn-down lane can reach a state where every open PR is CI-green but Forgejo reports mergeable: false for all of them. Open-PR backpressure then blocks new issue dispatch, and today the branch-continuation path is also blocked by ward#1073/ward#1166, so the lane cannot reduce pressure.

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

Open ward PRs: #1169, #1167, #1165, #1162, #1161, #1158, #1154, #1153, #1148, #987.
ward agent pr status reported success for the checked heads.
ward ops forgejo pr view ... --query mergeable reported mergeable: false for every open PR.
Dispatch health showed queued ward work but new dispatches were refused by open-PR pressure.

Do

Add a deterministic director burn-down step for this exact state:

Detect the repo state: open PR count over cap, required checks green, PRs nonmergeable.
For each safe candidate, update/rebase the PR branch onto current main through the Forgejo update-branch endpoint or an existing-branch engineer path.
Do not open replacement PRs while over the cap.
Prefer oldest/least risky PRs first and re-check after each update so the queue drains one branch at a time.
Surface clear reasons when a PR cannot be updated automatically.

Acceptance

A repo with many CI-green but nonmergeable PRs no longer idles under PR pressure.
The director either updates one existing PR branch toward mergeability or records a concrete blocker for that PR.
No new PR branch is opened as part of this burn-down path.
The behavior is covered by tests around the director PR/backpressure logic.

Related: ward#1069, ward#1073, ward#1166, ward#1168, ward#1170.

## Problem The director burn-down lane can reach a state where every open PR is CI-green but Forgejo reports `mergeable: false` for all of them. Open-PR backpressure then blocks new issue dispatch, and today the branch-continuation path is also blocked by ward#1073/ward#1166, so the lane cannot reduce pressure. Observed on 2026-07-13 from a director surface: * Open ward PRs: #1169, #1167, #1165, #1162, #1161, #1158, #1154, #1153, #1148, #987. * `ward agent pr status` reported success for the checked heads. * `ward ops forgejo pr view ... --query mergeable` reported `mergeable: false` for every open PR. * Dispatch health showed queued ward work but new dispatches were refused by open-PR pressure. ## Do Add a deterministic director burn-down step for this exact state: * Detect the repo state: open PR count over cap, required checks green, PRs nonmergeable. * For each safe candidate, update/rebase the PR branch onto current main through the Forgejo update-branch endpoint or an existing-branch engineer path. * Do not open replacement PRs while over the cap. * Prefer oldest/least risky PRs first and re-check after each update so the queue drains one branch at a time. * Surface clear reasons when a PR cannot be updated automatically. ## Acceptance * A repo with many CI-green but nonmergeable PRs no longer idles under PR pressure. * The director either updates one existing PR branch toward mergeability or records a concrete blocker for that PR. * No new PR branch is opened as part of this burn-down path. * The behavior is covered by tests around the director PR/backpressure logic. Related: ward#1069, ward#1073, ward#1166, ward#1168, ward#1170.

coilyco-ops commented

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

Author

Member

The burn-down session cleared the open PR pressure this issue was filed under. All ten open PRs are resolved: eight landed on main as sequential merge commits (31f07f3, d57c2c6, b4d1a2b, 5f1570b, 5dad59b, e226d57, 7a59b48, da115f5), PR#987 closed as superseded by main, and PR#1158 is being replaced by a corrected direct landing for ward#1139. Each push got its release tag, v0.641.0 through v0.649.0, and the release branch tracks the tip. The dispatch gate should pass again. The native rebase-or-update-above-cap capability this issue asks for is still wanted - the session had to re-resolve conflicts on every slot because each land reshuffled the conflict set for the remaining PRs, which is exactly the burn-down loop worth automating.

The burn-down session cleared the open PR pressure this issue was filed under. All ten open PRs are resolved: eight landed on main as sequential merge commits (31f07f3, d57c2c6, b4d1a2b, 5f1570b, 5dad59b, e226d57, 7a59b48, da115f5), PR#987 closed as superseded by main, and PR#1158 is being replaced by a corrected direct landing for ward#1139. Each push got its release tag, v0.641.0 through v0.649.0, and the release branch tracks the tip. The dispatch gate should pass again. The native rebase-or-update-above-cap capability this issue asks for is still wanted - the session had to re-resolve conflicts on every slot because each land reshuffled the conflict set for the remaining PRs, which is exactly the burn-down loop worth automating.

coilyco-ops added the

headless

labels

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

coilyco-ops commented

2026-07-14 10:22:24 +00:00

Author

Member

WARDED_WORKFLOW: reservation-released

release details

Run never started. ward container reap released container engineer-codex-ward-1172 (--harness codex): it exited without launching the agent (smoke-test death, ward#222/#264/#595), so it did no work and the launch intent it took is retracted. Nothing is running on this issue. It needs re-dispatch. A ward agent director re-queues it automatically. A manual ward agent retry no longer needs --override-reservation.

— Codex, via ward agent

WARDED_WORKFLOW: reservation-released <details><summary>release details</summary> Run never started. `ward container reap` released container `engineer-codex-ward-1172` (`--harness codex`): it exited without launching the agent (smoke-test death, ward#222/#264/#595), so it did no work and the launch intent it took is retracted. Nothing is running on this issue. It needs re-dispatch. A `ward agent director` re-queues it automatically. A manual `ward agent` retry no longer needs `--override-reservation`. </details>  — Codex, via `ward agent`

coilyco-ops commented

2026-07-14 10:45:23 +00:00

Author

Member

WARDED_WORKFLOW: reservation-held

reservation details

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

Accepted by ward agent --harness codex (reserved 2026-07-14T10:45:22Z). 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#1172 · branch issue-1172 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-ward-1172 · ward v0.679.0 · dispatched 2026-07-14T10:45:20Z
Comment thread: 2 included in the pre-flight read, 0 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-13T09:23:15Z), @coilyco-ops (2026-07-14T10:22:24Z)

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

— Codex, via ward agent

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

coilyco-ops commented

2026-07-14 11:16:14 +00:00

Author

Member

WARDED_WORKFLOW: #1278

details

workflow: pull-request-and-merge; review summary: skipped (review gate skipped by ~/.ward/config.yaml default)

Merged the PR-pressure burn-down path, Forgejo branch-update client, and dispatch filtering.

Confidence: high. Surprise: Forgejo's update endpoint reported a real conflict, so the branch needed a local merge with main before the PR turned green.

Follow-up: none.

WARDED_WORKFLOW: https://forgejo.coilysiren.me/coilyco-flight-deck/ward/pulls/1278 <details><summary>details</summary> workflow: pull-request-and-merge; review summary: skipped (review gate skipped by ~/.ward/config.yaml default) Merged the PR-pressure burn-down path, Forgejo branch-update client, and dispatch filtering. Confidence: high. Surprise: Forgejo's update endpoint reported a real conflict, so the branch needed a local merge with main before the PR turned green. Follow-up: none. </details>

coilyco-ops closed this issue

2026-07-14 11:16:43 +00:00