fix(claude): fetch and resolve stale branches before spawn-quest triages - #3405
Conversation
Two more review findings, both in the triage half rather than the spawning half. git fetch origin was documented in the Spawning section, which runs after the claim scan. The remote branch is the coordination mechanism, so a stale remote-tracking ref means offering a quest another agent already holds, and the spawned agent discovers it only when its push is rejected. Moved the fetch ahead of the scan. A stale branch was something to mention, with no instruction to resolve it. Left in place it makes the agent's claim push fail as non-fast-forward, which the agent then reports as a lost claim race that never happened, and a local stale branch blocks branch creation outright. The skill now says to inspect the tip and either reuse the work or delete the ref, and only when it is confirmed stale, not checked out, and carries no unmerged commits. Anything else is treated as claimed. This matches what start-quest already does, and it is not hypothetical here: six stale quest/m1/perf/* branches exist right now. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Warning Review limit reachedNext included review available in 20 minutes. View limit detailsLimit details: You’ve used all 4 included reviews currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 25582909b9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| never happened. Inspect its tip: reuse the work, or delete the ref only when it | ||
| is confirmed stale, is not checked out, and has no unmerged commits. Otherwise | ||
| treat the quest as claimed and take it out of the pool. |
There was a problem hiding this comment.
When an agent abandons a quest before opening a PR, its required UUID placeholder commit is itself an unmerged commit, so the branch can never satisfy this deletion condition. The fallback then treats the stale branch as claimed and removes the quest from the pool indefinitely, while the vague “reuse the work” path conflicts with the later instruction to cut a fresh branch from the base. Explicitly allow a confirmed placeholder-only branch to be deleted or specify how the spawned agent should resume it. (Written by GPT-5.6 Sol)
Useful? React with 👍 / 👎.
1 participant
What
Follow-up to #3403, which merged before these two review findings were addressed. Both are in the skill's triage half rather than its spawning half.
git fetch originran too late. It was documented in the Spawning section, which comes after the claim scan. The remote branch is the coordination mechanism, so a stale remote-tracking ref means offering the user a quest another agent already holds, and the spawned agent finds out only when its claim push is rejected. That wastes the user's selection and an agent slot. The fetch now comes before the scan.A stale branch was something to mention, not something to resolve. The skill said to say when a branch is stale so it could be reused or deleted, then never told anyone to do it. Left in place, the agent's instruction to cut the same branch fresh and push without force fails as non-fast-forward, and the agent reports that as a lost claim race that never happened. A stale local branch blocks branch creation even earlier. The skill now says to inspect the tip and either reuse the work or delete the ref, and only when it is confirmed stale, not checked out, and carrying no unmerged commits; anything else is treated as claimed and leaves the pool.
The second rule is what
start-questalready does, so this brings the two skills into agreement rather than inventing a policy. It is also not hypothetical in this repository: there are six stalequest/m1/perf/*branches right now, and a/spawn-quest m1run that offered one of them would have produced exactly the false race report described above.Checks
just fixandjust checkboth exit 0. The diff is one Markdown file under.claude/, so the dispatch correctly reportsjs: no JS changes; skippingand runs no Rust, Python, or quest validation.🤖 Generated with Claude Code
(Written by Claude Opus 5)