[factory] Implementer pushed to another issue's branch, producing a conflicted PR (cloud#3024)

[khaliqgant]

Summary

A Factory implementer pushed its work onto a branch belonging to a different, already-closed issue, producing a conflicted PR. Nothing detects or prevents this, and it is invisible unless someone reads the PR's head ref and compares it to the issue being worked.

Evidence

AgentWorkforce/cloud#3024, opened 2026-08-14T13:41:34Z by app/agent-relay-code:

title: 3021: [factory] Fix 2 failing CI checks on PR #3017 (deployment objective metadata)
head:  factory/3022-chief-org-live-population      ← branch belongs to cloud#3022
base:  main
mergeable: CONFLICTING     mergeStateStatus: dirty

The PR implements cloud#3021. Its head branch is named for cloud#3022 — "[factory] Fix the Chief org-chart population: 893 rows down to real live agents" — which is CLOSED, and whose branch still exists on the remote:

$ gh api repos/AgentWorkforce/cloud/branches --jq '.[].name' | grep '^factory/'
factory/2787-agentworkforce-cloud-31f929d3
factory/2788-agentworkforce-cloud-55c9ea97
factory/2794-agentworkforce-cloud-5af0ba84
factory/2918-fleet-production-proof
factory/3022-chief-org-live-population        ← reused by the 3021 implementer

The ar-3021-impl-cloud agent was dispatched at approximately 12:46Z and opened this PR ~55 minutes later. Stale factory/* branches from prior dispatches accumulate on the remote and are never pruned, so the collision surface grows with every completed issue.

Why this matters

• The conflict is an artifact, not real work. Reviewers will attempt to resolve a conflict that exists only because the branch was wrong.
• It corrupts attribution. The branch name says 3022, the title says 3021. Anyone auditing which branch belongs to which issue gets a false answer.
• It risks resurrecting abandoned work. Building on a closed issue's branch can silently re-introduce commits that were deliberately never merged.
• It is invisible. Nothing in the dispatch path validates that the branch an implementer pushes to corresponds to the issue it was dispatched for.

Asked-for behaviour

1. Derive and enforce the branch name from the dispatched issue. An implementer for issue N must work on a branch keyed to N. If a branch for a different issue key is selected, that is an error.
2. Refuse to reuse an existing branch belonging to another issue. If the derived branch already exists and its issue key does not match, fail loudly rather than pushing onto it.
3. Validate at PR-open. Before opening the PR, assert the head ref's issue key matches the dispatched issue; abort and report if not.
4. Prune or ignore branches from closed issues so the collision surface does not grow without bound.

Definition of done

• An implementer dispatched for issue N cannot open a PR whose head branch is keyed to a different issue; attempting it fails with a clear error.
• Regression test covering the collision case: pre-create a branch for a different issue key and assert the implementer refuses it rather than pushing onto it.
• cloud#3024 is re-cut onto a correct factory/3021-* branch from origin/main, or the conflict is confirmed to be genuine and unrelated to the branch reuse. Determine which before changing anything — do not assume.

Constraints

• Branch from origin/main. The local checkout sits on codex/222-routed-pr-babysitter-v2 with an unrelated WIP commit (b2ad725) — do not build on it and do not disturb it.
• mergePolicy: never. Open the PR and stop at review.
• Do not delete factory/3022-chief-org-live-population or force-push it as part of this work; cloud#3024 currently depends on it and is under review. Pruning stale branches is item 4 and should be proposed separately, not executed here.

[khaliqgant]

Factory dispatch for 244
Implementers: ar-244-impl-factory
Reviewer: ar-244-review-factory