coilyco-flight-deck/ward

Fork 0

Let engineer input accept a PR ref and start from that PR branch #913

New issue

Closed

opened 2026-07-10 00:56:45 +00:00 by coilyco-ops · 4 comments

coilyco-ops commented

2026-07-10 00:56:45 +00:00

Member

Goal

ward agent engineer should support a pull-request input mode. When the operator gives a PR URL or PR ref, the engineer should start from that PR's branch automatically instead of treating the linked issue as fresh work.

Problem

Merge-queue repair work currently has to be described indirectly through a new issue, even when the actual task is "repair this existing PR branch". That is error-prone: an engineer seeded only from the linked issue can reimplement from main or ignore the branch state that needs conflict repair.

Desired behavior

Examples:

ward agent engineer https://forgejo.coilysiren.me/coilyco-flight-deck/ward/pulls/877
ward agent engineer coilyco-flight-deck/ward!877
ward agent engineer coilyco-flight-deck/ward#877 --pr

The exact syntax can follow ward conventions, but the behavior should be:

Resolve the PR and its source branch.
Fresh-clone the repo as usual, then checkout the PR branch as the working branch.
Seed the agent with PR metadata, linked issue/thread context, mergeability state, and current base branch.
Preserve the normal reservation, audit, workflow, review, and reaper behavior.
Make the seed explicit that this is PR repair / continuation work, not fresh issue implementation.

Acceptance

A PR URL/ref input starts the engineer on the PR branch automatically.
The seeded prompt includes the PR title/body/comments and linked issue context where available.
A test covers PR URL/ref parsing and branch checkout planning.
Existing issue-ref behavior is unchanged.
ward exec test passes, or the issue comment names the exact failing check.

Closes this issue when merged.

## Goal `ward agent engineer` should support a pull-request input mode. When the operator gives a PR URL or PR ref, the engineer should start from that PR's branch automatically instead of treating the linked issue as fresh work. ## Problem Merge-queue repair work currently has to be described indirectly through a new issue, even when the actual task is "repair this existing PR branch". That is error-prone: an engineer seeded only from the linked issue can reimplement from `main` or ignore the branch state that needs conflict repair. ## Desired behavior Examples: ```text ward agent engineer https://forgejo.coilysiren.me/coilyco-flight-deck/ward/pulls/877 ward agent engineer coilyco-flight-deck/ward!877 ward agent engineer coilyco-flight-deck/ward#877 --pr ``` The exact syntax can follow ward conventions, but the behavior should be: - Resolve the PR and its source branch. - Fresh-clone the repo as usual, then checkout the PR branch as the working branch. - Seed the agent with PR metadata, linked issue/thread context, mergeability state, and current base branch. - Preserve the normal reservation, audit, workflow, review, and reaper behavior. - Make the seed explicit that this is PR repair / continuation work, not fresh issue implementation. ## Acceptance - A PR URL/ref input starts the engineer on the PR branch automatically. - The seeded prompt includes the PR title/body/comments and linked issue context where available. - A test covers PR URL/ref parsing and branch checkout planning. - Existing issue-ref behavior is unchanged. - `ward exec test` passes, or the issue comment names the exact failing check. Closes this issue when merged.

coilyco-ops added the

headless

labels

2026-07-10 00:56:52 +00:00

coilyco-ops commented

2026-07-10 17:17:45 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-10T17:17:45Z). 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#913 · branch issue-913 · harness codex · workflow pull-requests-and-merge
Run: engineer-codex-ward-913 · ward v0.584.0 · dispatched 2026-07-10T17:17:45Z
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.584.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-913` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T17:17:45Z). 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#913` · branch `issue-913` · harness `codex` · workflow `pull-requests-and-merge` - **Run:** `engineer-codex-ward-913` · ward `v0.584.0` · dispatched `2026-07-10T17:17:45Z` - **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.584.0). </details> </details>  — Codex, via `ward agent`

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

2026-07-10 17:40:58 +00:00

Let engineer input accept a PR ref and start from that PR branch #1061

coilyco-ops commented

2026-07-10 18:02:54 +00:00

Author

Member

WARD-DISPATCH: failed ❌

failure details

This forwarded dispatch failed after the issue was already reserved.

Attempted harness: codex
Attempted run: ward agent engineer coilyco-flight-deck/ward#913 --harness codex --ward-version v0.584.0 --details Repair existing PR #1061 on head branch issue-913. Start from the existing PR branch, update it against current main, resolve file conflicts, push the same branch, and do not create a replacement PR. This PR adds PR/ref input support needed for future repair dispatches, so preserve that scope and run the repo's allowed tests.
Container: engineer-codex-ward-913
Container created: no running engineer was observed.
Host log: /Users/kai/.ward/agent-logs/dispatch/20260710T180225Z-director-codex-cz57-coilyco-flight-deck-ward-913.log
Failure: ward agent engineer --harness codex: issue coilyco-flight-deck/ward#913 is already reserved remotely (by @coilyco-ops at 2026-07-10T17:17:45Z); wait for it to finish or pass --force to override

Retry: choose another harness if the first one is down, or rerun with --force if the reservation is stale.

— Codex, via ward agent

WARD-DISPATCH: failed ❌ <details><summary>failure details</summary> This forwarded dispatch failed after the issue was already reserved. Attempted harness: `codex` Attempted run: `ward agent engineer coilyco-flight-deck/ward#913 --harness codex --ward-version v0.584.0 --details Repair existing PR #1061 on head branch issue-913. Start from the existing PR branch, update it against current main, resolve file conflicts, push the same branch, and do not create a replacement PR. This PR adds PR/ref input support needed for future repair dispatches, so preserve that scope and run the repo's allowed tests.` Container: `engineer-codex-ward-913` Container created: no running engineer was observed. Host log: `/Users/kai/.ward/agent-logs/dispatch/20260710T180225Z-director-codex-cz57-coilyco-flight-deck-ward-913.log` Failure: `ward agent engineer --harness codex: issue coilyco-flight-deck/ward#913 is already reserved remotely (by @coilyco-ops at 2026-07-10T17:17:45Z); wait for it to finish or pass --force to override` Retry: choose another harness if the first one is down, or rerun with `--force` if the reservation is stale. </details>  — Codex, via `ward agent`

coilyco-ops commented

2026-07-10 18:38:15 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-claude-ward-913 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness claude (reserved 2026-07-10T18:38: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#913 · branch issue-913 · harness claude · workflow pull-requests-and-merge
Run: engineer-claude-ward-913 · ward v0.584.0 · dispatched 2026-07-10T18:38:14Z
Comment thread: 1 included in the pre-flight read, 1 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-10T18:02:54Z)
- stripped: @coilyco-ops (2026-07-10T17:17:45Z)

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

— Claude (she/her), via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-claude-ward-913` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness claude` (reserved 2026-07-10T18:38: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#913` · branch `issue-913` · harness `claude` · workflow `pull-requests-and-merge` - **Run:** `engineer-claude-ward-913` · ward `v0.584.0` · dispatched `2026-07-10T18:38:14Z` - **Comment thread:** 1 included in the pre-flight read, 1 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-10T18:02:54Z) - stripped: @coilyco-ops (2026-07-10T17:17:45Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.584.0). </details> </details>  — Claude (she/her), via `ward agent`

coilyco-ops commented

2026-07-10 18:45:08 +00:00

Author

Member

WARD-OUTCOME: merge-ready

details

workflow: pull-requests-and-merge; review summary: skipped (the in-container review gate was intentionally skipped by the ~/.ward/config.yaml default)

What landed. PR #1061 (head issue-913) carries the PR-ref engineer input feature and is now updated against current post-#1009 main: merged origin/main (9a3164c2) into issue-913, resolved the one conflict (cmd/ward/configsource.go, a doc-comment collision - took main's wording since the branch's edit was comment-only trimming), and pushed 2d29740d. Per the operator note, the deleted .ward/ward-kdl bundle was not restored - git diff origin/main -- .ward/ is empty, so the bundle tree is byte-identical to main. Forgejo Actions test / test on the new head is green, and the PR reports mergeable.

Verification. ward exec build, ward exec vet, ward exec lint (0 issues), and ward exec test all pass in-container. One flaky first-run failure in the cmd/ward gitsync scratch tests (TestSyncGitRef*) did not reproduce across two forced uncached reruns. The feature's own tests (TestParseGitHubPullRequestRef, TestParseForgejoPullRequestRef, TestAgentWorkBranchPrefersPullRequestBranch, TestEngineerPRDetailsIncludesPRAndLinkedIssueContext, and the seed-prompt failure-commenting tests) all pass on the merged head.

Retrospective. This was a repair run on an existing implementation, not fresh work - the prior engineer's commit (83d30222) survived the 39-commit main advance almost untouched; git auto-merged everything except one comment block. Confidence is high: the surface between the feature (agent dispatch/forge parsing) and main's churn (config-bundle loading, merge-gate outcomes) barely overlaps, and the full suite passes uncached. Surprise: the merge brought main's re-expanded .ward/ward-kdl tree in cleanly with zero interaction with the feature. Follow-up: none filed - the flaky gitsync scratch test predates this branch and did not reproduce; worth a separate issue only if it recurs in CI. This unblocks branch-repair burn-down (ward#1073).

WARD-OUTCOME: merge-ready <details><summary>details</summary> workflow: pull-requests-and-merge; review summary: skipped (the in-container review gate was intentionally skipped by the ~/.ward/config.yaml default) **What landed.** PR #1061 (head `issue-913`) carries the PR-ref engineer input feature and is now updated against current post-#1009 main: merged `origin/main` (9a3164c2) into `issue-913`, resolved the one conflict (`cmd/ward/configsource.go`, a doc-comment collision - took main's wording since the branch's edit was comment-only trimming), and pushed `2d29740d`. Per the operator note, the deleted `.ward/ward-kdl` bundle was not restored - `git diff origin/main -- .ward/` is empty, so the bundle tree is byte-identical to main. Forgejo Actions `test / test` on the new head is green, and the PR reports mergeable. **Verification.** `ward exec build`, `ward exec vet`, `ward exec lint` (0 issues), and `ward exec test` all pass in-container. One flaky first-run failure in the `cmd/ward` gitsync scratch tests (`TestSyncGitRef*`) did not reproduce across two forced uncached reruns. The feature's own tests (`TestParseGitHubPullRequestRef`, `TestParseForgejoPullRequestRef`, `TestAgentWorkBranchPrefersPullRequestBranch`, `TestEngineerPRDetailsIncludesPRAndLinkedIssueContext`, and the seed-prompt failure-commenting tests) all pass on the merged head. **Retrospective.** This was a repair run on an existing implementation, not fresh work - the prior engineer's commit (`83d30222`) survived the 39-commit main advance almost untouched; git auto-merged everything except one comment block. Confidence is high: the surface between the feature (agent dispatch/forge parsing) and main's churn (config-bundle loading, merge-gate outcomes) barely overlaps, and the full suite passes uncached. Surprise: the merge brought main's re-expanded `.ward/ward-kdl` tree in cleanly with zero interaction with the feature. Follow-up: none filed - the flaky gitsync scratch test predates this branch and did not reproduce; worth a separate issue only if it recurs in CI. This unblocks branch-repair burn-down (ward#1073). </details>