coilyco-flight-deck/ward

Fork 0

Make --branch resume existing remote branches #778

New issue

Closed

opened 2026-07-09 07:51:44 +00:00 by coilyco-ops · 5 comments

coilyco-ops commented

2026-07-09 07:51:44 +00:00

Member

Problem

ward agent engineer --branch <name> exists, but it does not currently start the worker from the existing remote branch when one is present. Bootstrap clones the cached mirror, then runs:

git -C <work> checkout -B <branch>

With no start point, that creates or resets the local branch from the clone's current HEAD (normally main). It names the branch correctly, but it does not hydrate origin/<branch> as the starting content.

That means programmatic failed-PR recovery is awkward: a worker can be told to use --branch issue-735, but the container starts from current main instead of the existing PR branch, then has to discover and merge/pull the remote branch itself.

Desired behavior

A worker dispatched with --branch <name> should resume the existing remote branch when origin/<name> exists. If no such remote branch exists, it should keep today's behavior and create the branch from the default checked-out base.

Suggested bootstrap behavior:

if origin/<branch> exists:
  git checkout -B <branch> origin/<branch>
else:
  git checkout -B <branch>

Apply the same behavior to writable extra repos that use the run branch.

Requirements

Detect whether the refreshed mirror/work clone has origin/<branch>.
Checkout from origin/<branch> when present.
Keep the existing create-from-main behavior when the remote branch is absent.
Log which path was used so run logs make branch provenance obvious.
Add tests for both paths in target clone bootstrap and writable extra-repo bootstrap.
Preserve read-only context repo behavior: context repos do not get feature branches.

Acceptance

Dispatching an engineer with --branch issue-735 starts the worker on the remote origin/issue-735 content when that branch exists.
Dispatching with a new branch still starts from the default cloned base.
ward exec test passes.

Filed from the read-only director surface after checking container_bootstrap.go during recovery.

Codex, via ward agent

## Problem `ward agent engineer --branch <name>` exists, but it does not currently start the worker from the existing remote branch when one is present. Bootstrap clones the cached mirror, then runs: ```text git -C <work> checkout -B <branch> ``` With no start point, that creates or resets the local branch from the clone's current `HEAD` (normally `main`). It names the branch correctly, but it does not hydrate `origin/<branch>` as the starting content. That means programmatic failed-PR recovery is awkward: a worker can be told to use `--branch issue-735`, but the container starts from current `main` instead of the existing PR branch, then has to discover and merge/pull the remote branch itself. ## Desired behavior A worker dispatched with `--branch <name>` should resume the existing remote branch when `origin/<name>` exists. If no such remote branch exists, it should keep today's behavior and create the branch from the default checked-out base. Suggested bootstrap behavior: ```text if origin/<branch> exists: git checkout -B <branch> origin/<branch> else: git checkout -B <branch> ``` Apply the same behavior to writable extra repos that use the run branch. ## Requirements * Detect whether the refreshed mirror/work clone has `origin/<branch>`. * Checkout from `origin/<branch>` when present. * Keep the existing create-from-main behavior when the remote branch is absent. * Log which path was used so run logs make branch provenance obvious. * Add tests for both paths in target clone bootstrap and writable extra-repo bootstrap. * Preserve read-only context repo behavior: context repos do not get feature branches. ## Acceptance * Dispatching an engineer with `--branch issue-735` starts the worker on the remote `origin/issue-735` content when that branch exists. * Dispatching with a new branch still starts from the default cloned base. * `ward exec test` passes. Filed from the read-only director surface after checking `container_bootstrap.go` during recovery.  Codex, via `ward agent`

coilyco-ops added the

headless

labels

2026-07-09 07:51:44 +00:00

coilyco-ops commented

2026-07-09 07:51:51 +00:00

Author

Member

🔒 Reserved by ward agent --harness codex — container engineer-codex-ward-778 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-09T07:51:50Z). 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#778 · branch issue-778 · harness codex · workflow pr
Run: engineer-codex-ward-778 · ward v0.480.0 · dispatched 2026-07-09T07:51:50Z
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.480.0).

— Codex, via ward agent

🔒 Reserved by `ward agent --harness codex` — container `engineer-codex-ward-778` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-09T07:51:50Z). 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#778` · branch `issue-778` · harness `codex` · workflow `pr` - **Run:** `engineer-codex-ward-778` · ward `v0.480.0` · dispatched `2026-07-09T07:51:50Z` - **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.480.0). </details>  — Codex, via `ward agent`

coilyco-ops commented

2026-07-09 08:00:33 +00:00

Author

Member

WARD-OUTCOME: blocked - review summary: blocked: codex: exit status 1: Reading additional input from stdin... OpenAI Codex v0.142.5 -------- workdir: /workspace/ward mod...

Review panel verdicts:

codex: ERROR: codex: exit status 1: Reading additional input from stdin... OpenAI Codex v0.142.5 -------- workdir: /workspace/ward model: gpt-5.5 provider: openai approval: never sandbox: read-only reasoning... (conf 0.00)
claude: ERROR: claude: exit status 1: {"type":"system","subtype":"hook_started","hook_id":"05dd86af-cb79-482d-8097-0e69d590313f","hook_name":"SessionStart:startup","hook_event":"SessionStart","uuid":"f44b34bd... (conf 0.00)
goose: ERROR: goose: exit status 1: error: No provider configured. Run 'goose configure' first. (conf 0.00)

— Codex, via ward agent

WARD-OUTCOME: blocked - review summary: blocked: codex: exit status 1: Reading additional input from stdin... OpenAI Codex v0.142.5 -------- workdir: /workspace/ward mod... Review panel verdicts: - codex: ERROR: codex: exit status 1: Reading additional input from stdin... OpenAI Codex v0.142.5 -------- workdir: /workspace/ward model: gpt-5.5 provider: openai approval: never sandbox: read-only reasoning... (conf 0.00) - claude: ERROR: claude: exit status 1: {"type":"system","subtype":"hook_started","hook_id":"05dd86af-cb79-482d-8097-0e69d590313f","hook_name":"SessionStart:startup","hook_event":"SessionStart","uuid":"f44b34bd... (conf 0.00) - goose: ERROR: goose: exit status 1: error: No provider configured. Run 'goose configure' first. (conf 0.00)  — Codex, via `ward agent`

coilyco-ops commented

2026-07-09 08:01:59 +00:00

Author

Member

WARD-OUTCOME: blocked - ward agent review could not get a runnable reviewer, so the PR gate is still closed.
workflow: pr; review summary: blocked: codex: exit status 1: Reading additional input from stdin... OpenAI Codex v0.142.5 -------- workdir: /workspace/ward mod...
Review verdicts: codex blocked on 401 auth, claude blocked, goose had no provider, so the panel ended 0/2 passing.
I implemented the branch-resume bootstrap and tests, but I am not opening a PR while the panel is fail-closed.

WARD-OUTCOME: blocked - ward agent review could not get a runnable reviewer, so the PR gate is still closed. workflow: pr; review summary: blocked: codex: exit status 1: Reading additional input from stdin... OpenAI Codex v0.142.5 -------- workdir: /workspace/ward mod... Review verdicts: codex blocked on 401 auth, claude blocked, goose had no provider, so the panel ended 0/2 passing. I implemented the branch-resume bootstrap and tests, but I am not opening a PR while the panel is fail-closed.

coilyco-ops commented

2026-07-09 17:55:33 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-09T17:55:32Z). 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#778 · branch issue-778 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-ward-778 · ward v0.493.0 · dispatched 2026-07-09T17:55:32Z
Comment thread: 2 included in the pre-flight read, 1 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-09T08:00:33Z), @coilyco-ops (2026-07-09T08:01:59Z)
- stripped: @coilyco-ops (2026-07-09T07:51:51Z)

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-778` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-09T17:55:32Z). 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#778` · branch `issue-778` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-778` · ward `v0.493.0` · dispatched `2026-07-09T17:55:32Z` - **Comment thread:** 2 included in the pre-flight read, 1 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-09T08:00:33Z), @coilyco-ops (2026-07-09T08:01:59Z) - stripped: @coilyco-ops (2026-07-09T07:51:51Z) 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:04:36 +00:00

Make --branch resume existing remote branches #833

coilyco-ops closed this issue

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

coilyco-ops commented

2026-07-09 18:23:46 +00:00

Author

Member

WARD-OUTCOME: done ✅

details

workflow: pull-request-and-merge; review summary: skipped: review gate skipped by --skip-review / --no-review-gate
felt: clean after refreshing the stale base and merging main into the branch
confidence: high
surprises: Forgejo only flipped mergeable after the branch was updated onto current main
follow-ups: none

WARD-OUTCOME: done ✅ <details><summary>details</summary> workflow: pull-request-and-merge; review summary: skipped: review gate skipped by --skip-review / --no-review-gate felt: clean after refreshing the stale base and merging main into the branch confidence: high surprises: Forgejo only flipped mergeable after the branch was updated onto current main follow-ups: none </details>