Make PR workflow create, wait, and merge pull requests #706

New issue

Closed

opened 2026-07-08 22:12:26 +00:00 by coilyco-ops · 3 comments

coilyco-ops commented

2026-07-08 22:12:26 +00:00

Member

Goal

Change --workflow pr from a branch-and-human-gate prompt into a complete ward landing workflow for Forgejo engineers.

Today PR workflow only tells the container agent to push a branch and open a pull request, then it stops. The requested default change needs PR mode to be a real autonomous path first: create the PR, wait for Forgejo Actions or required status checks to finish, run the existing review gate after CI is green, then merge the PR with a merge commit.

Context read before filing

cmd/ward/agent_workflow.go currently documents pr as branch + PR with a human or follow-up loop landing it.
docs/agent-workflow.md says the same and names this as a first-slice limitation.
docs/ward-kdl/ward-kdl.forgejo.write.guardfile.md currently denies PR view/list and says PRs are read through the web UI.
The Forgejo swagger lock already contains pull request, action task, branch protection, and merge related shapes, so this is a product/guarded-surface gap rather than an API absence.

Desired behavior

Forgejo pr workflow opens a real pull request against main from the feature branch.
Ward waits for CI/status checks for that PR branch/head before review and merge.
Ward runs the existing in-container review gate only after CI is green.
Ward merges with a merge commit, not squash, rebase, or fast-forward.
The issue close path is preserved through the PR body or merge commit message using closes #N.
Failure to create the PR, green CI, pass review, or merge is reported as blocked/failed with useful context on the issue.
GitHub behavior stays compatible with the existing GitHub PR lane.

Notes

This should not rely on the agent improvising hidden curl calls. Prefer a ward-owned helper or guarded Forgejo verbs with tests around request shape, polling behavior, and failure classification.

## Goal Change `--workflow pr` from a branch-and-human-gate prompt into a complete ward landing workflow for Forgejo engineers. Today PR workflow only tells the container agent to push a branch and open a pull request, then it stops. The requested default change needs PR mode to be a real autonomous path first: create the PR, wait for Forgejo Actions or required status checks to finish, run the existing review gate after CI is green, then merge the PR with a merge commit. ## Context read before filing * `cmd/ward/agent_workflow.go` currently documents `pr` as branch + PR with a human or follow-up loop landing it. * `docs/agent-workflow.md` says the same and names this as a first-slice limitation. * `docs/ward-kdl/ward-kdl.forgejo.write.guardfile.md` currently denies PR view/list and says PRs are read through the web UI. * The Forgejo swagger lock already contains pull request, action task, branch protection, and merge related shapes, so this is a product/guarded-surface gap rather than an API absence. ## Desired behavior * Forgejo `pr` workflow opens a real pull request against `main` from the feature branch. * Ward waits for CI/status checks for that PR branch/head before review and merge. * Ward runs the existing in-container review gate only after CI is green. * Ward merges with a merge commit, not squash, rebase, or fast-forward. * The issue close path is preserved through the PR body or merge commit message using `closes #N`. * Failure to create the PR, green CI, pass review, or merge is reported as blocked/failed with useful context on the issue. * GitHub behavior stays compatible with the existing GitHub PR lane. ## Notes This should not rely on the agent improvising hidden `curl` calls. Prefer a ward-owned helper or guarded Forgejo verbs with tests around request shape, polling behavior, and failure classification.

coilyco-ops commented

2026-07-08 22:13:05 +00:00

Author

Member

🔒 Reserved by ward agent --harness goose — container engineer-goose-ward-706 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-08T22:13:03Z). 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#706 · branch issue-706 · harness goose · workflow direct-main
Run: engineer-goose-ward-706 · ward v0.466.0 · dispatched 2026-07-08T22:13:03Z
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.466.0).

— Goose, via ward agent

🔒 Reserved by `ward agent --harness goose` — container `engineer-goose-ward-706` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-08T22:13:03Z). 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#706` · branch `issue-706` · harness `goose` · workflow `direct-main` - **Run:** `engineer-goose-ward-706` · ward `v0.466.0` · dispatched `2026-07-08T22:13:03Z` - **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.466.0). </details>  — Goose, via `ward agent`

coilyco-ops commented

2026-07-09 07:39:15 +00:00

Author

Member

🔒 Reserved by ward agent --harness codex — container engineer-codex-ward-706 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-09T07:39:14Z). 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#706 · branch issue-706 · harness codex · workflow pr
Run: engineer-codex-ward-706 · ward v0.480.0 · dispatched 2026-07-09T07:39:14Z
Comment thread: 0 included in the pre-flight read, 1 stripped (ward's own automated comments).
- stripped: @coilyco-ops (2026-07-08T22:13:05Z)

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

— Codex, via ward agent

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

coilyco-ops added the

headless

labels

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

coilyco-ops commented

2026-07-09 18:16:34 +00:00

Author

Member

Validation pass: this broad PR-workflow ticket has been superseded by the more precise workflow split and outcome tickets. PR workflows now have later scoped work in ward#723 (spelled-out workflow modes), ward#777 (PR submission is not done), ward#778 (branch resume), ward#804 (open PRs in director scope), and ward#813 (PR-side failure comments). Keeping this older --workflow pr framing open would duplicate the active/specific queue.

— Codex, via director surface

Validation pass: this broad PR-workflow ticket has been superseded by the more precise workflow split and outcome tickets. PR workflows now have later scoped work in ward#723 (spelled-out workflow modes), ward#777 (PR submission is not done), ward#778 (branch resume), ward#804 (open PRs in director scope), and ward#813 (PR-side failure comments). Keeping this older `--workflow pr` framing open would duplicate the active/specific queue.  — Codex, via director surface

coilyco-ops closed this issue

2026-07-09 18:16:34 +00:00