fix(miner): check out baseBranch on the fresh-clone path so the first attempt succeeds (#9682)

[kai392]

What

ensureRepoClonedUnlocked's docstring promises both branches land on the base branch, but the fresh-clone branch returned right after git clone. A plain clone creates only origin's default-HEAD local branch, so the consumer's git worktree add -b <attempt> <path> <baseBranch> (worktree-plan.ts:80-84) can't rev-parse a bare non-default <baseBranch>. The first attempt against any repo whose base isn't the origin default fails with fatal: invalid reference: <baseBranch> (surfacing as blocked_worktree_preparation_failed), and only the second attempt — the fetch+reset path that DWIM-creates the local tracking branch — works. Reachable in production (attempt-cli.ts:578 passes the PR's real base; attempt-worktree.ts defaults to "main", failing the first attempt against any master-default repo).

How

• repo-clone.ts: after a successful git clone, run git checkout <baseBranch> and return the identical { ok: false, repoPath, error: stderr || "git_checkout_failed" } shape the existing-clone branch already uses. No fetch/reset is added — a fresh clone is already at origin's tip. The isUnsafeGitArgValue(baseBranch) guard still runs first.
• attempt-worktree.ts: the clone/checkout-failure return now forwards repoPath (which ensureRepoCloned always sets on failure), so a clone/checkout failure and a worktree-add failure surface the same { ok: false, repoPath, error } shape. An unknown base branch now fails at the checkout step, and callers keep getting repoPath on that path.

Tests

• Three named repo-clone regression cases (checkout after clone on the first-use path; a failing checkout returns git_checkout_failed / stderr; the fresh path emits exactly clone then checkout, no fetch/reset).
• The per-repo concurrency test's pinned git-op sequence is updated for the new checkout (its non-overlapping serialization guarantee is unchanged).
• The attempt-worktree unknown-base-branch test now asserts the { ok: false, repoPath, error } shape produced at the checkout step.

All new assertions fail against the current code.

Closes #9682

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-29 21:04:48 UTC}

4 files · 1 AI reviewer · no blockers · readiness 100/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
The change ensures the base branch is checked out after a fresh clone, resolving the issue where the first attempt failed due to an unknown base branch. The error handling and test coverage align with existing patterns, making the fix correct and effective.

Nits — 2 non-blocking

• The `isUnsafeGitArgValue` check is redundant here since the baseBranch is already validated earlier in the code.
• Add a comment explaining the necessity of the `git checkout` step for clarity, especially for future maintainers.

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#9682
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 89 registered-repo PR(s), 43 merged, 7 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	kai392; Gittensor profile; 89 PR(s), 7 issue(s).
Improvement	✅ Minor	risk: clean · value: minor

Linked issue satisfaction

Addressed
The diff adds `git checkout <baseBranch>` after `git clone` in the fresh-clone branch with the exact required error-shape reuse, avoids adding fetch/reset, and includes three named regression tests matching the deliverables (checkout invoked, failing-checkout error shape, and no fetch/reset with exact clone->checkout order).

Review context

• Author: kai392
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Python, Cuda, JavaScript, Kotlin, MDX, Perl, Ruby, TypeScript
• Official Gittensor activity: 89 PR(s), 7 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Keep the PR focused and include validation evidence before maintainer review.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.35%. Comparing base (36dd1c8) to head (a72db59).

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #9904       +/-   ##
===========================================
- Coverage   91.76%   79.35%   -12.42%     
===========================================
  Files         921      283      -638     
  Lines      113203    58734    -54469     
  Branches    27253     8665    -18588     
===========================================
- Hits       103884    46606    -57278     
- Misses       8034    11843     +3809     
+ Partials     1285      285     -1000     

Flag	Coverage Δ
backend	98.80% <100.00%> (+3.11%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
packages/loopover-miner/lib/attempt-worktree.ts	94.59% <100.00%> (-5.41%)	⬇️
packages/loopover-miner/lib/repo-clone.ts	100.00% <100.00%> (ø)

... and 771 files with indirect coverage changes

[loopover-orb]

LoopOver approves — the gate is satisfied and CI is green.