coilyco-flight-deck/ward

Fork 0

Require PR mergeability before pull-requests-and-merge can be done #853

New issue

Closed

opened 2026-07-09 18:43:32 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

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

Member

Bug

A pull-requests-and-merge run can mark its issue WARD-OUTCOME: done while the opened PR is not mergeable because it conflicts with the target branch.

Concrete example:

Issue: #723
PR: #848
Checks: passing
Forgejo PR state: "This pull request has changes conflicting with the target branch."
Conflicting files shown by Forgejo include cmd/ward/agent_director_merge.go, cmd/ward/agent_workflow.go, cmd/ward/container_bootstrap.go, and multiple docs.

The issue thread has final WARD-OUTCOME: done comments for workflow: pull-requests-and-merge, so the current done/merge-eligibility criteria are too weak. CI green is not enough. A PR that cannot merge into its base branch is not done.

Expected behavior

For pull-requests-and-merge, done-ness and director merge eligibility must require the PR to be mergeable against the current base branch.

If the PR has conflicts:

The engineer should not post WARD-OUTCOME: done as the final state.
The issue should remain blocked or failed with a reason naming the merge conflict.
Director merge should refuse the PR even if CI is green and the issue thread says done.
The comment should make clear that the engineer must rebase/merge base and resolve conflicts before the PR can be considered done.

Implementation notes

Current code evidence:

cmd/ward/agent_director_merge.go describes eligibility as issue outcome done, workflow: pull-request-and-merge, passed review summary, and not draft/salvage noise.
directorMergeEligibility reads the linked issue and WARD-OUTCOME metadata, but there is no visible merge-conflict or mergeable-state gate.
forgejoClient.listOpenPullRequests projects PRs into a lean issue shape, likely dropping Forgejo fields such as mergeability or conflict state.

Scope

Extend the Forgejo PR read/list projection enough to know whether the PR can merge cleanly into its base branch.
Add mergeability/conflict state to directorMergeEligibility and the autonomous pull-requests-and-merge done condition.
If Forgejo does not expose reliable mergeability in the list response, add a focused PR-detail call or attempt a dry merge check through the safest available API path.
Add tests where a PR has green checks and valid WARD-OUTCOME: done metadata but is not mergeable. The director must refuse it and explain why.
Update docs for pull-requests-and-merge and director merge criteria.

Acceptance

A conflicting PR cannot be considered done for pull-requests-and-merge.
Director merge refuses a conflicting PR with an explicit reason.
Tests cover conflict refusal independently of CI success.
ward exec test passes.

Filed from the read-only director surface after Kai reported PR #848 / issue #723.

## Bug A `pull-requests-and-merge` run can mark its issue `WARD-OUTCOME: done` while the opened PR is not mergeable because it conflicts with the target branch. Concrete example: * Issue: #723 * PR: #848 * Checks: passing * Forgejo PR state: "This pull request has changes conflicting with the target branch." * Conflicting files shown by Forgejo include `cmd/ward/agent_director_merge.go`, `cmd/ward/agent_workflow.go`, `cmd/ward/container_bootstrap.go`, and multiple docs. The issue thread has final `WARD-OUTCOME: done` comments for `workflow: pull-requests-and-merge`, so the current done/merge-eligibility criteria are too weak. CI green is not enough. A PR that cannot merge into its base branch is not done. ## Expected behavior For `pull-requests-and-merge`, done-ness and director merge eligibility must require the PR to be mergeable against the current base branch. If the PR has conflicts: * The engineer should not post `WARD-OUTCOME: done` as the final state. * The issue should remain blocked or failed with a reason naming the merge conflict. * Director merge should refuse the PR even if CI is green and the issue thread says done. * The comment should make clear that the engineer must rebase/merge base and resolve conflicts before the PR can be considered done. ## Implementation notes Current code evidence: * `cmd/ward/agent_director_merge.go` describes eligibility as issue outcome done, `workflow: pull-request-and-merge`, passed review summary, and not draft/salvage noise. * `directorMergeEligibility` reads the linked issue and `WARD-OUTCOME` metadata, but there is no visible merge-conflict or mergeable-state gate. * `forgejoClient.listOpenPullRequests` projects PRs into a lean issue shape, likely dropping Forgejo fields such as mergeability or conflict state. ## Scope * Extend the Forgejo PR read/list projection enough to know whether the PR can merge cleanly into its base branch. * Add mergeability/conflict state to `directorMergeEligibility` and the autonomous `pull-requests-and-merge` done condition. * If Forgejo does not expose reliable mergeability in the list response, add a focused PR-detail call or attempt a dry merge check through the safest available API path. * Add tests where a PR has green checks and valid `WARD-OUTCOME: done` metadata but is not mergeable. The director must refuse it and explain why. * Update docs for `pull-requests-and-merge` and director merge criteria. ## Acceptance * A conflicting PR cannot be considered done for `pull-requests-and-merge`. * Director merge refuses a conflicting PR with an explicit reason. * Tests cover conflict refusal independently of CI success. * `ward exec test` passes. Filed from the read-only director surface after Kai reported PR #848 / issue #723.

coilyco-ops added the

headless

labels

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

coilyco-ops referenced this issue

2026-07-09 18:43:40 +00:00

Split pull-request workflow modes and use spelled-out workflow names #723

coilyco-ops commented

2026-07-09 18:43:44 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-09T18:43:42Z). 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#853 · branch issue-853 · harness codex · workflow pull-request
Run: engineer-codex-ward-853 · ward v0.493.0 · dispatched 2026-07-09T18:43:42Z
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.493.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-853` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-09T18:43:42Z). 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#853` · branch `issue-853` · harness `codex` · workflow `pull-request` - **Run:** `engineer-codex-ward-853` · ward `v0.493.0` · dispatched `2026-07-09T18:43:42Z` - **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.493.0). </details> </details>  — Codex, via `ward agent`

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

2026-07-09 18:54:49 +00:00

Require PR mergeability before pull-requests-and-merge can be done #859

coilyco-ops commented

2026-07-09 18:56:11 +00:00

Author

Member

WARD-OUTCOME: done ✅

details

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

felt: straightforward after the mergeability seam was found.
confidence: high
surprises: Forgejo exposes mergeable on PR detail, not the issue list.
follow-ups: none.

WARD-OUTCOME: done ✅ <details><summary>details</summary> workflow: pull-request-and-merge; review summary: review gate skipped by ~/.ward/config.yaml default felt: straightforward after the mergeability seam was found. confidence: high surprises: Forgejo exposes mergeable on PR detail, not the issue list. follow-ups: none. </details>

coilyco-ops closed this issue

2026-07-09 19:01:29 +00:00