fix: link PRs from non-Git workspaces

[Gigioxx]

A thread under a non-Git parent workspace could not link a child repository PR because the client required every URL to match a registered Git project. The sidebar also hid the persisted PR number until a live summary loaded.

This keeps the existing project-backed path and lets capable servers use a non-Git thread project as read-only provider context. The server re-parses and validates the URL before fetching a summary; PR mutations remain restricted to registered Git projects. The sidebar now renders the persisted PR number immediately.

Verification

• Reproduced on origin/main: issue [Bug]: PR URLs cannot be linked to threads in non-Git parent workspaces #9435 parsed correctly but had no matching project, so the link action was omitted
• vp test run packages/contracts/src/pullRequest.test.ts apps/web/src/lib/openPullRequestLink.test.ts apps/web/src/components/ChatMarkdown.test.tsx apps/web/src/components/ChatMarkdown.workspace-images.test.tsx apps/web/src/components/ThreadStatusIndicators.test.ts apps/server/src/environment/ServerEnvironment.test.ts apps/server/src/pullRequest/PullRequestService.test.ts apps/server/src/orchestration/ThreadSettlementReactor.test.ts (277 tests)
• vp run --filter @t3tools/web typecheck
• vp run --filter t3 typecheck
• Targeted lint on all changed files (no errors)

Fixes #9435

Implemented with GPT-5.6 Sol via Codex in T3 Code.

---

Note

Medium Risk
Touches PR resolution, caching, and thread linking across server and clients; URL-only reads are restricted to public GitHub/Bitbucket hosts, so self-hosted or enterprise URLs remain unavailable by design.

Overview
Threads in non-Git parent workspaces can now link a change request from a pasted URL when the server advertises threadPullRequestUrlLinking. The client no longer requires a matching checked-out Git project; it uses resolveThreadPullRequestLink (with the existing project-match path unchanged) and gates URL-only linking on that capability.

Contracts and plumbing: PullRequestRef gains an optional url, and mobile/web/settlement paths forward it into PR detail and summary queries. Settlement dedupe keys include the URL so linked lookups stay distinct.

Server: PullRequestService.summary can resolve references for projects without repositoryIdentity by re-parsing the URL, validating repo/number against the ref, and calling a provider only when canReadChangeRequestSummaryWithoutCheckout allows it (github.com and bitbucket.org today). Summary/detail held-cache keys incorporate URL/provider/host so different links do not share state; detail refreshes can update URL-keyed summaries.

Shared parsing: Change-request URL parsing (with provider metadata) moves to @t3tools/shared/sourceControl for web and server.

UI: The sidebar shows the persisted PR number and link from thread.linkedPullRequest before live summary loads; chat markdown uses the centralized resolver instead of inline project matching.

^{Reviewed by Cursor Bugbot for commit 3dad101. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix PR linking from non-Git workspaces via URL-only references

• Adds a shared change-request URL parser with provider metadata and canReadChangeRequestSummaryWithoutCheckout to sourceControl.ts; only public GitHub and Bitbucket hosts qualify for checkout-independent summary reads
• PullRequestService.requireProject gains an opt-in URL-reference path: when no supported project match exists, it validates the parsed URL, requires a selected project without repository identity, and resolves the provider by parsed kind
• Summary cache keys and held-summary recorders now distinguish URL-bearing references while sharing compatible results between URL-less and URL-bearing refs for the same parsed provider and host
• New threadPullRequestUrlLinking capability in environment.ts gates the feature server-side; web and mobile clients pass the stored URL into linked-PR detail queries and resolve URL-only links for eligible non-Git projects
• Risk: unsupported URL-only hosts (GitLab, Azure DevOps, self-hosted Bitbucket, GitHub Enterprise) return PullRequestUnavailableError; URL-sensitive cache keys in PullRequestService.ts mean existing URL-less cached summaries will not be reused for URL-bearing lookups

^{Macroscope summarized 3dad101.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds a cross-cutting production capability for linking and reading pull requests from non-Git workspaces, including new URL-aware resolution, caching, settlement, and UI behavior. The capability is enabled by default on live servers, so the change warrants human review.

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

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 0cc3732. Configure here.}

[shivamhwp]

Note: GPT-6 on behalf of shivam (@shivamhwp).

The rebase needs to carry this behavior into the current multiple-PR path. ChatMarkdown now delegates eligibility and mutations to usePullRequestLinking; that hook also serves the PR dialog and link buttons. Its canLink still requires a registered checkout on the host, so the non-Git-only environment remains blocked. Updating the former inline resolver alone will not enable the current entry points.

Current links are host/repository/number keys, and PullRequestSyncReactor refreshes their snapshots through that hosted reference. Preserve the existing PullRequestRef.host, host-aware requireProject routing, and refCacheKey/refOfCacheKey layout when adding URL-only context. The patch's older project/repository/number cache layout would discard the newer host distinction if ported verbatim. The new sync path needs a summary lookup that succeeds when no Git checkout is registered; keep the deliberate restriction on URL-only provider mutations.

[juliusmarminge]

Thanks for the PR. We're not taking changes to the orchestration and provider layers right now: that part of the server is being rewritten for V2, and merging into the current code would either conflict with or be thrown away by that work.

Closing for now. If this is still an issue once V2 lands, please reopen (or open a fresh PR against the new code) and we'll take a proper look.