Retry branch auto-rename when metadata is pending

[agusmdev]

Background

First-work branch auto-rename intentionally dedupes each worktree after it reaches a terminal verdict. That is important because agent hook working events can fire repeatedly, and branch-name generation is comparatively expensive.

The bug is that the existing eligibility check used a boolean:

canRenameOrcaCreatedBranch(worktreeId) => boolean

In production that boolean is derived from worktree metadata:

• orcaCreationSource means Orca created the worktree and may rename the initial creature branch.
• preserveBranchOnDelete means the worktree came from an existing/user branch and must not be auto-renamed.

A missing metadata read was therefore indistinguishable from a true permanent ineligible case. If an early hook event arrived before the worktree metadata was available through the store, auto-rename returned “not eligible” and the worktree was added to settledWorktreeIds. Later valid working events for the same worktree were ignored before any retry could happen.

That explains the observed failure mode: the branch remains a creature name, no user-facing rename error is recorded, and manual replaying a valid hook event still does nothing because the process-level settled cache has already poisoned the worktree.

Change

This PR splits auto-rename eligibility into three states:

• eligible: Orca-created worktree, safe to rename.
• transient-unknown: metadata is not available yet, so retry on a later hook event.
• permanent-ineligible: user/imported/preserved worktree, so settle and stop retrying.

The production caller now treats missing metadata as transient-unknown, while preserving the permanent skip for missing orcaCreationSource or preserveBranchOnDelete === true.

Regression Coverage

Adds a test for the failure pattern directly:

1. First working event sees transient unknown eligibility and does not generate a branch name.
2. Second working event sees eligibility become available.
3. Auto-rename proceeds instead of being blocked by settledWorktreeIds.

Tests

• pnpm test src/main/agent-hooks/first-work-branch-rename.test.ts
• pnpm run typecheck:node
• pnpm exec oxlint src/main/agent-hooks/first-work-branch-rename.ts src/main/agent-hooks/first-work-branch-rename.test.ts src/main/index.ts

[coderabbitai]

📝 Walkthrough

Walkthrough

The PR adds a new eligibility classification for first-work branch renaming, exposes an optional eligibility callback on the rename dependency contract, wires a metadata-based classifier into the main entrypoint, and changes rename gating to retry when eligibility is still unknown. Tests add coverage for the transition from transient-unknown to eligible.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The PR description covers the change and tests, but it omits several required template sections: Summary, Screenshots, AI Review Report, Security Audit, and Notes.	Add the missing sections, or explicitly mark screenshots as "No visual change" and include the AI review, security audit, and any platform-specific notes.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly matches the main change: retrying branch auto-rename while metadata is pending.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

🧹 Nitpick comments (1)

src/main/index.ts (1)

258-267: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Eligibility rule is duplicated with canRenameOrcaCreatedBranch.

Both canRenameOrcaCreatedBranch (Lines 252-256) and this callback encode the same orcaCreationSource + preserveBranchOnDelete rule. Only the transient-unknown (missing meta) case is new here. If the eligibility rule changes later, the two can silently diverge. Consider deriving the permanent verdict from the shared predicate so the rule lives in one place.

♻️ Optional: share the eligibility predicate

       getAutoRenameBranchEligibility: (worktreeId) => {
         const meta = currentStore.getWorktreeMeta(worktreeId)
         if (!meta) {
           return 'transient-unknown'
         }
-        if (!meta.orcaCreationSource || meta.preserveBranchOnDelete === true) {
-          return 'permanent-ineligible'
-        }
-        return 'eligible'
+        const orcaRenamable = !!meta.orcaCreationSource && meta.preserveBranchOnDelete !== true
+        return orcaRenamable ? 'eligible' : 'permanent-ineligible'
       },

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 4b53383f-7426-4c88-86da-6e1e5d18810f

📥 Commits

Reviewing files that changed from the base of the PR and between f6ad569 and 8ebb634.

📒 Files selected for processing (3)

• src/main/agent-hooks/first-work-branch-rename.test.ts
• src/main/agent-hooks/first-work-branch-rename.ts
• src/main/index.ts