fix(server): keep forks separate from their upstream repository in project grouping

[Project516]

Problem

With repository grouping on (the default), a renamed fork that has the original repository as its upstream remote collapses into the same project as a checkout of the original. The draft header and the draft project picker label the fork with the upstream name, so users can't tell which repository they are working in. Reported in #4880 and reproduced by a maintainer on September 5 (comment).

Reproduction: one checkout with origin set to example-org/widget, and two checkouts of a renamed fork with origin set to someone/gadget and upstream set to example-org/widget. Add all three as projects and open a new draft on a fork checkout.

Expected: the fork checkouts group together under someone/gadget, apart from the original.
Actual: all three checkouts form one group named example-org/widget.

Change

The canonical repository identity is unchanged. It still follows upstream, so pull request lookup and linking target the repository the fork tracks. When the checkout's own origin names a different repository, the resolver now adds it as an optional origin field on RepositoryIdentity.

Two small contract helpers pick the grouping key and the label from origin when it is present, falling back to the canonical identity. Client grouping in packages/client-runtime and the mobile new-task environment matching use those helpers, so web, desktop, and mobile agree. Checkouts without an upstream remote resolve to the same identity as before. docs/internals/remote.md gets a short note on why the grouping key differs from the canonical key.

This replaces #11011, which was closed for missing before/after screenshots. The code is the same apart from a rebase onto current main. It also keeps the fallback from that PR's review that labels a fork by its canonical key when the origin has no display name.

Scope and approval

Fixes #4880. A maintainer confirmed the bug on current main and set the constraint that a display fix must preserve repository identity (comment). That constraint is why the earlier attempt in #7686 was closed. This change leaves canonicalKey, locator, owner, name, and provider as they were. Only grouping and labels read the new field.

Verification

Focused tests, run on this branch before I rebased onto main as of October 5. The rebase had no conflicts. I did not rerun these locally afterward, so CI covers the rebased commit.

• vp test run apps/server/src/project/RepositoryIdentityResolver.test.ts packages/client-runtime/src/state/projectGrouping.test.ts: 25 passed. The new cases cover a fork reporting its own origin next to the upstream identity, fork checkouts grouping apart from an upstream checkout under the fork's label, and an origin with no display name.
• vp test run apps/mobile/src/features/threads/new-task-project-selection.test.ts: 13 passed.
• tsc --noEmit in packages/contracts, packages/client-runtime, and apps/mobile: clean.

Manual check in the Linux web client against a fresh dev state directory, using the three disposable repositories from the reproduction above. I ran the same state twice: once with the changed files reverted to main, and once on this branch with the server restarted so identities resolved again. Screenshots show a new draft on the gadget-2 fork checkout with the project picker open.

Before (main): one picker entry, example-org/widget, covers all three checkouts, and the fork's draft is labelled with the upstream name.

After (this branch): the two fork checkouts share one entry, someone/gadget, and the draft header names the fork. The original is its own entry. It shows as widget because a single-checkout group uses the project title, which is existing label behavior.

Not checked: the server package typecheck (it ran out of memory on the Raspberry Pi I used, so CI covers it), the packaged desktop build, and the mobile app on a device. Mobile shares the grouping helpers, and its selection logic is covered by the test above.

Claude Opus 5.5 via Claude Code in T3 Code.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository: pingdotgg/t3code/.coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: bc3017ed-e87a-4fe5-a414-1c8a88b6e999

📥 Commits

Reviewing files that changed from the base of the PR and between 5a574a7 and 35407c5.

📒 Files selected for processing (8)

• apps/mobile/src/features/threads/new-task-flow-provider.tsx
• apps/mobile/src/features/threads/new-task-project-selection.ts
• apps/server/src/project/RepositoryIdentityResolver.test.ts
• apps/server/src/project/RepositoryIdentityResolver.ts
• docs/internals/remote.md
• packages/client-runtime/src/state/projectGrouping.test.ts
• packages/client-runtime/src/state/projectGrouping.ts
• packages/contracts/src/environment.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

---

📝 Walkthrough

Walkthrough

Repository identities now include optional origin-repository metadata. Client grouping, labels, and mobile project matching use origin-based helpers when that metadata is present.

Changes

Fork Repository Identity and Grouping

Layer / File(s)	Summary
Origin identity contract and resolution packages/contracts/src/environment.ts, apps/server/src/project/RepositoryIdentityResolver.ts, apps/server/src/project/RepositoryIdentityResolver.test.ts, docs/internals/remote.md	The repository identity schema adds optional origin metadata. The resolver records a distinct origin remote when present, with tests and documentation covering fork identity.
Fork grouping and labels packages/client-runtime/src/state/projectGrouping.ts, packages/client-runtime/src/state/projectGrouping.test.ts	Repository grouping uses the origin key and display name when available. Tests cover fork separation, matching worktrees, and display-name fallback.
Mobile environment project matching apps/mobile/src/features/threads/new-task-flow-provider.tsx, apps/mobile/src/features/threads/new-task-project-selection.ts	Selected and candidate projects use the repository grouping key for matching. Existing fallback matching remains unchanged.

Priority: ➖ Normal

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Bug fix · Severity of issue fixed: Medium

Suggested reviewers: juliusmarminge, maria-rcks

Merge Risk: ⚪ Minimal · up to 35407

Forks should now group and label separately from their upstream repository. Checkouts without a distinct origin keep their previous behavior. No merge-blocking risk was found in the supplied changes.

Security Architecture Review

Security architecture risk: 🔵 Low · up to 35407

Fork-aware grouping remains separate from the canonical repository used for pull requests. Task destinations still use explicit project and environment identifiers, and existing draft protections remain intact. No introduced security concern was established, but mixed-version compatibility and end-to-end authorization coverage remain incomplete.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — The demonstrated exposure is project grouping and draft destination selection among projects already available to the client. The inspected change does not itself introduce new credentials or execution authority; downstream server authorization and broader tenant isolation were not established by this review.

Trust Boundaries and Controls

• observed — Repository keys originate from configurable Git remotes, not authenticated repository ownership. In the inspected flow they are matching hints rather than execution identities. The normal environment picker passes only entries from the provider’s filtered environment list, and known key mismatches are excluded from weaker basename and title matching.

Resilience and Maintainability Implications

• observed — The matching helper retains a pre-existing first-project fallback when no stronger match exists. It is not an authorization control. The origin-aware change modifies matching keys but does not add that fallback or change draft and queued-task recovery mechanisms.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 30.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 10 functions across 7 files. (1 skipped: …	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Issue #4880 requires a renamed fork to display distinctly from its upstream repository. The resolver now records an optional origin identity. The grouping and display helpers use that identity when …
Out of Scope Changes check	✅ Passed	The changes stay within issue #4880. Server identity resolution, contract helpers, client and mobile grouping use, documentation, and automated tests directly support distinct fork grouping and labeli…
Title check	✅ Passed	The title clearly summarizes the main change: keeping fork repositories separate from their upstream in project grouping.
Description check	✅ Passed	The description covers the required Problem, Change, Scope and approval, and Verification sections. It explains the behavior, scope, tests, manual check, and checks not completed.

Full details: Docstring Coverage

Explanation

Docstring coverage is 30.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 10 functions across 7 files. (1 skipped: 1 unsupported.)

• Fix all pre-merge checks with AI

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Autopilot is currently an internal CodeRabbit preview.

---

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

[macroscopeapp]

Approvability

Verdict: Approved at 35407c5

Macroscope's review found this PR approvable — This is a contained repository-grouping bug fix: forks retain upstream identity for pull-request operations while grouping and labels use their own origin. The optional contract change is backward-compatible, and focused server, client-runtime, and mobile tests cover the affected paths.

^{You can add or adjust custom eligibility rules. Learn more.}

[t3dotgg]

Note

🤖 Claude Opus 5.5 responding on behalf of Theo

Landed as #16353 (squash commit 017c9a0). The code is unchanged from this PR, rebased onto current main. Your commit authorship and a Co-authored-by trailer are preserved in the merge.

I opened a new PR only because updating this fork branch onto main needed GitHub workflow scope, since main had changed workflow files. Closing this in favor of #16353. Thanks for the fix and the clear repro.