fix: upstream ancestry merge + address review findings

[aaditagrawal]

Summary

• Ancestry merge with upstream/main to sync fork divergence history
• Addresses all 4 CodeRabbit review findings from PR Upstream sync batch 3: flatten git layer, resizable sidebar, PTY runtime loading #31:
  • pr-size.yml: Force size:XXL label when GitHub's 3,000-file API truncation is hit, instead of applying a potentially undercounted label
  • GitCore.fetchUpstreamRefForStatus: Propagate non-zero exit codes as failures so the cache doesn't retain stale "success" entries for 15 seconds
  • GitCore.listRemoteNames/resolvePrimaryRemoteName: Remove arbitrary .toReversed() call; prefer "upstream" remote when "origin" is absent
  • GitCore.prepareCommitContext: Treat an explicit empty filePaths array as "stage nothing" instead of falling through to git add -A
• Fix duplicate replaceProviderModelOptions function from merge artifact

Test plan

• bun typecheck passes across all 7 packages
• Verify status polling handles fetch failures gracefully (no stale cache)
• Verify selective file staging with empty array doesn't stage everything
• Verify PR size labeling with large PRs

Summary by CodeRabbit

Release Notes

• Bug Fixes
  • Improved error handling for upstream git fetch operations
  • Enhanced primary remote selection logic
  • Refined commit staging behavior for edge cases

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 83af8764-d298-431a-ab14-303cd58a8bfb

📥 Commits

Reviewing files that changed from the base of the PR and between 4d3c8bf and a3185a7.

📒 Files selected for processing (2)

• .github/workflows/pr-size.yml
• apps/server/src/git/Layers/GitCore.ts

🚧 Files skipped from review as they are similar to previous changes (1)

• .github/workflows/pr-size.yml

---

📝 Walkthrough

Walkthrough

Two distinct changes: a workflow file now detects truncated PR file lists and forces size label sizing when truncation occurs; a git core module adds error checking to upstream ref fetching, adjusts remote name ordering and selection logic, and refines file staging behavior for empty paths.

Changes

Cohort / File(s)	Summary
PR Size Detection Workflow .github/workflows/pr-size.yml	Added truncation detection (files.length >= 3000) that skips per-file iteration and forces changedLines to 1000 and label to "size:XXL". Non-truncated flow preserves existing per-file summing logic.
Git Operations Core apps/server/src/git/Layers/GitCore.ts	Enhanced error handling in fetchUpstreamRefForStatus to throw on non-zero exit codes. Modified listRemoteNames to preserve original order (removed reversal). Updated resolvePrimaryRemoteName to prefer "upstream" remote. Refined prepareCommitContext to skip git add when filePaths is explicitly empty.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Poem

🐰 When files pile high beyond the count,
The workflow trumpets its truncation shout—
While Git commands learn to check their way,
And remotes find their proper place to stay.
Order restored, errors caught with care,
A rabbit's refactor, precise and fair! 🌿

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main changes: addressing CodeRabbit review findings and syncing fork ancestry, which directly match the changeset objectives.
Description check	✅ Passed	The description covers all required sections (What Changed, Why) with clear detail about the four review findings being addressed and the test plan, aligning well with the template requirements.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

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

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch upstream-ancestry-sync-fixes

---

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 and usage tips.}

[coderabbitai]

Actionable comments posted: 3

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

apps/server/src/git/Layers/GitCore.ts (1)

643-656: ⚠️ Potential issue | 🟠 Major

remotes[0] is still not the first listed remote.

The new comment says this falls back to the first listed remote, but listRemoteNames() still goes through parseRemoteNames(), which reorders names by descending length at Lines 115-120. In repos without origin or upstream, this now picks the longest remote name instead, so resolvePushRemoteName() / fetchPullRequestBranch() can target the wrong remote.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/server/src/git/Layers/GitCore.ts` around lines 643 - 656, The fallback
in resolvePrimaryRemoteName incorrectly uses listRemoteNames which calls
parseRemoteNames that reorders remotes by descending length; this causes
remotes[0] to be the longest name, not the first-listed remote. Fix by
retrieving remotes in their original git-listed order for
resolvePrimaryRemoteName (and callers like resolvePushRemoteName /
fetchPullRequestBranch): either call runGitStdout("GitCore.listRemoteNames",
cwd, ["remote"]) and parse the stdout without the length-based reordering, or
add a new helper (e.g., parseRemoteNamesPreserveOrder) and use that in
listRemoteNames or directly in resolvePrimaryRemoteName so the fallback truly
uses the first listed remote.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.github/workflows/pr-size.yml:
- Around line 182-187: The early return when files.length >= 3000 (the line
returning "size:XXL" after core.warning) bypasses the downstream label
reconciliation logic, so change the flow to set a variable/flag indicating the
computed label ("size:XXL") instead of returning early and allow the normal
label reconciliation/path to run; locate the block that currently calls
core.warning and returns "size:XXL", replace the return with assignment to the
label result or a flag, and ensure the subsequent reconciliation routine still
runs to add or remove size labels accordingly.

In `@apps/server/src/git/Layers/GitCore.ts`:
- Around line 960-973: The branch that treats an explicit empty filePaths array
skips resetting the index and leaves prior staged files; change
prepareCommitContext so that whenever filePaths is not null/undefined you first
run the reset step (use the existing GitCore.prepareCommitContext.reset
invocation) and only run GitCore.prepareCommitContext.addSelected when
filePaths.length > 0; this ensures the index is cleared for explicit []
selections and prevents stale stagedSummary/stagedPatch/commit() from including
unintended files.

In `@packages/shared/src/model.test.ts`:
- Around line 271-333: The file contains a duplicated test suite for
resolveSelectableModel; remove the second describe("resolveSelectableModel",
...) block (the duplicate that includes tests referencing
resolveSelectableModel) so the tests only exist once. Locate the duplicate
describe block that repeats the tests for resolveSelectableModel (the one with
cases like "resolves exact slug matches", "resolves case-insensitive
display-name matches", "returns null for empty input", etc.) and delete that
entire block, leaving the original test suite and any other unique tests intact.

---

Outside diff comments:
In `@apps/server/src/git/Layers/GitCore.ts`:
- Around line 643-656: The fallback in resolvePrimaryRemoteName incorrectly uses
listRemoteNames which calls parseRemoteNames that reorders remotes by descending
length; this causes remotes[0] to be the longest name, not the first-listed
remote. Fix by retrieving remotes in their original git-listed order for
resolvePrimaryRemoteName (and callers like resolvePushRemoteName /
fetchPullRequestBranch): either call runGitStdout("GitCore.listRemoteNames",
cwd, ["remote"]) and parse the stdout without the length-based reordering, or
add a new helper (e.g., parseRemoteNamesPreserveOrder) and use that in
listRemoteNames or directly in resolvePrimaryRemoteName so the fallback truly
uses the first listed remote.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 846c83b1-c85c-45b9-b8bc-35c92e3098b8

📥 Commits

Reviewing files that changed from the base of the PR and between 3549c0f and 4d3c8bf.

📒 Files selected for processing (3)

• .github/workflows/pr-size.yml
• apps/server/src/git/Layers/GitCore.ts
• packages/shared/src/model.test.ts