Summary

When `archon-implement` runs inside a workflow, it picked up a pre-existing branch from a completely different, earlier task instead of creating a fresh branch from `main`. Two separate develop workflow runs (for two different issues) both ended up working on the same pre-existing branch, producing a code review for the wrong codebase change and no implementation for either of the intended issues.

Context

• Running `kanban-develop` workflow via Archon web API (HTTP trigger from a kanban board)
• Two develop runs fired ~1 minute apart for two different GitHub issues (issue [Discussion] Visuals for the Archon codebase #144 and issue Bump litellm from 1.57.8 to 1.72.2 #145 in a target repo)
• Target repo had a pre-existing local branch `codex/subscriber-billing-receipt-method-lookup` with one commit, created days earlier by a different tool (Codex), with a draft PR ([BUG] Bug Summary: Port 8100 Already in Use #123) open against it

What happened

1. Both develop runs completed with status `completed` in Archon (8.1m and 8.7m duration)
2. Both produced a code review comment on the GitHub issues referencing PR [BUG] Bug Summary: Port 8100 Already in Use #123 (the pre-existing draft PR) — not a new PR for either issue
3. Archon's History UI showed both runs as `kanban-develop` with their correct issue descriptions, but clicking View Logs on both showed identical log content — the code review for the pre-existing branch's changes
4. No new branch or PR was created for issue [Discussion] Visuals for the Archon codebase #144 (Cartesian Join bug) or issue Bump litellm from 1.57.8 to 1.72.2 #145 (Cursor Leak bug)
5. The `archon-implement` step inside each run apparently found the pre-existing `codex/subscriber-billing-receipt-method-lookup` branch and continued work on it rather than creating a new branch from `main`

Confirmed findings

• Target repo `main` branch was the active checkout in the main working directory
• 48 stale `archon/thread-*` worktrees existed on disk (separate cleanup issue — see bug(isolation): archon complete reports success but leaves git worktree on disk #964) — all pointing to `fdc27d7` or `8de8024` (main-equivalent commits)
• After manually removing all stale worktrees and branches, the only remaining local branch besides `main` was `codex/subscriber-billing-receipt-method-lookup`
• Both develop runs fired within 1 minute of each other

Suspected root cause

`archon-implement` does not enforce that it starts from a clean branch based on `main`. It appears to either:

• Search for an existing branch related to the issue and match incorrectly against an unrelated branch, or
• Detect that a branch already exists in the worktree context and continue from it rather than resetting, or
• When two runs fire concurrently, the second run's worktree picks up state left by the first

The consequence is silent: the workflow reports `completed`, a code review runs, a comment is posted — but the wrong code was reviewed and the intended implementation never happened.

Impact

• Correctness: two issues sent to AI Develop received no implementation; a third unrelated branch received a spurious code review
• Trust: the workflow appeared to succeed (green status, comments posted, code review run) with no indication anything was wrong
• Recovery: required manual DB edits to move cards back to Human Design Review, and manual worktree/branch cleanup

Suggested fix

`archon-implement` should:

1. Always create a new branch from the latest `main` (or configured base branch) with a name derived from the issue/run ID — never reuse an existing branch unless explicitly instructed
2. Verify the worktree is clean and on the correct base before beginning implementation
3. If a branch with a conflicting name already exists, either error clearly or use a unique suffix (e.g. run ID)

Related

• bug(isolation): archon complete reports success but leaves git worktree on disk #964 — worktrees not removed on disk after `archon complete` (likely contributed to the environment that triggered this bug)