feat: add Gitea source-control provider - #8232

💭 I'm checking the current PR head to see if earlier findings were resolved, focusing on the changed files within scope—CommandPalette.tsx and the GitActionsControl logic files. Going through the list, the previous concerns look addressed: the login-add phrasing in SourceControlSettings is now neutral, the pulls-claim comment in openPullRequestLink is clarified, GitActionsControl now uses a null host with fallback logic instead of a hardcoded placeholder, and pullRequestReference has been extended. With those resolved, I want to look for any new issues, so I'm reviewing GitActionsControl.tsx's publishHost rendering for UI consistency around border styling.

1. git_tools — apps/web/src/** 16d32bc..d1b9069

2. browse_code — apps/web/src/components/GitActionsControl.tsx

💭 Let me check how the host prefix renders around lines 700-760.

3. browse_code — apps/web/src/components/GitActionsControl.tsx

💭 I'm considering whether the "Gitea" prefix chip without a trailing slash or separator looks visually odd when publishHost is null, but concluding it's a minor aesthetic detail rather than an actual issue worth flagging. Now I want to check SourceControlSettings.tsx again — the earlier markdown backtick rendering issue seems resolved since the helper text is now neutral and executables render in a proper code chip. I should look at how the item summary renders host/detail suffixes for consistency, so I'll view the file around lines 200-260.

4. browse_code — apps/web/src/components/settings/SourceControlSettings.tsx

💭 I'm checking whether the container uses flex with a gap, since the suffix string already has a leading space—if the container also adds gap spacing, that could produce doubled spacing before "on git.example.com".

5. browse_code — apps/web/src/components/settings/SourceControlSettings.tsx

💭 I'm reasoning through how flex layout handles the leading whitespace in that suffix span—since it starts a new line box as a flex item, the leading space likely collapses, and combined with the gap-x-1 spacing, the visible result would render as "Authenticated as" followed by the gap before "on git.example.com". I want to check the diff history for this section to confirm whether the host/detail info was previously rendered at all before this suffix logic was added, since it looks like it wasn't shown before. I also want to verify how the "gitea" source control type maps to its icon in sourceControlPresentation.ts, since CommandPalette.tsx references a pull-request icon for it.

6. browse_code — apps/web/src/sourceControlPresentation.ts

💭 I'm checking where each file imports GitPullRequestIcon from to confirm they're all pulling it from lucide-react consistently.

7. git_tools — GitPullRequestIcon

💭 I'm checking how CommandPalette now marks gitea readiness as unavailable and adds it to the remote project sources list, plus tracing where the imports for AddProjectCloneFlow moved to client-runtime instead of local definitions.

8. browse_code — apps/web/src/components/CommandPalette.tsx

💭 I want to check line ~1562 in OpenCommandPaletteDialog where "gitea" was added to a list.

9. browse_code — apps/web/src/components/CommandPalette.tsx

💭 I'm checking whether the add-project flow resolves short gitea paths correctly, though that's mostly server-side. I'm also reviewing the pull request link matching logic to make sure the github and bitbucket rules properly guard against false matches before falling through to other patterns. That's fine and consistent with the prior request — the dialog still accepts Gitea URLs and the checkout flow now works through GiteaCli. Looking at GitActionsControl, the "description" field on gitea's publish option seems unused since provider cards only render icon and label, so that's pre-existing dead code, not something I introduced. The host field changing to allow null across all provider options means I should check other places in the file referencing .host or publishHost to make sure nothing breaks.

10. git_tools — publishHost|currentPublishProvider|.host

💭 I'm considering the prefix chip behavior when publishHost is null—it shows "Gitea" without a border-r separator, which is a debatable but intentional stylistic choice rather than a bug. I'm also checking whether there's an edge case where publishHost is null but the user is authenticated with a Gitea host, in which case the chip should display that host instead. Looking at the raw input element at line 738, it's pre-existing and unchanged, so I won't flag it for cleanup unrelated to this diff. I'm now reviewing the new SourceControlSettings.logic.ts file, where formattedAuthSuffix combines the "on host — detail" text into a single string rendered as one flex item, which could change how it wraps compared to the previous multi-span layout. Since the span is still a flex item with normal text wrapping, leading whitespace collapses and gap-x-1 handles the spacing, so cases like "Authenticated as mario on git.example.com" or just "Authenticated on git.example.com" render fine either way. I also see the pull request logic and context menu files correctly add Gitea to noise-filtering regexes and provider labels, and the state actions type union has been widened appropriately. Now I want to check whether there's an exhaustive switch statement elsewhere in the web UI enumerating provider kinds that might have missed adding Gitea.

11. git_tools — "azure-devops"

💭 I'm checking whether the add-project flow's clone resolution handles Gitea repositories with short "owner/repository" paths consistently, similar to how the publish dialog displays provider-specific host info. I confirm the endpoint resolution works correctly for short paths, and the unauthenticated setup guidance messaging in SourceControlSettings matches expectations from earlier. Now I want to look at openPullRequestLink.ts to verify the guard changes there are correct since that file is in scope.

12. browse_code — apps/web/src/lib/openPullRequestLink.ts

💭 I'm checking whether the leftover /pulls/\d+ regex in changeRequestRepositoryUrl is actually dead code, since none of the supported hosts (GitHub, GitLab, Bitbucket, Azure) produce a path matching that pattern. It's harmless but a bit inconsistent given the comment stating Gitea is intentionally unclaimed — likely too minor to flag as a real violation, so I'll keep searching for something more substantive. That's fine since gitlab wouldn't match anyway. I want to check where parsePullRequestReference gets consumed downstream, whether the routing per provider handles it correctly, and whether any UI placeholder text listing supported formats needs updating for Gitea.

13. browse_code — apps/web/src/pullRequestReference.ts

💭 I'm checking the fallback ordering for the Gitea checkout match against Azure DevOps, and noting the Gitea URL pattern might be too permissive since it allows loose protocol matching that could overlap with GitLab-style paths. There's a mild regression concern: pasting a Gitea-style URL into a non-Gitea repo would now pass client-side validation but fail server-side, whereas before it would be rejected upfront. I want to check whether any consumer UI lists supported URL formats or help text that should be updated to mention Gitea support.

14. git_tools — parsePullRequestReference

💭 The UI seems consistent now that the parser accepts Gitea shapes, so a Gitea repo correctly shows terminology like PR URL or checkout command. I'm checking whether the dead /pulls/\d+ alternative in changeRequestRepositoryUrl is actually unreachable, tracing through how it first requires parsing the change request. Confirming it's dead code, but I'm weighing whether it's worth flagging given the instruction to only report concrete violations, not aesthetic nits — it's a minor inconsistency with the stated intent that could mislead future readers, but maybe non-blocking. I'm also noticing a conflict between instructions: one says respond with schema-conformant JSON, another says if there are no findings, the entire response should be exactly "All clear" — I'll try to reconcile by using the JSON schema but setting the summary field to "All clear". I also want to check whether CommandPalette still duplicates readiness-building logic that now exists in client-runtime, rather than importing it, which could be a separate consistency issue worth noting. But flagging it would be scope creep since it's pre-existing duplication, and both implementations were updated consistently in this PR so there's no divergence risk right now. Let me verify the removed local AddProjectCloneFlow type in CommandPalette actually matches the client-runtime version being imported, particularly around the SourceControlRepositoryInfo nullability.

15. browse_code — packages/client-runtime/src/operations/projects.ts

💭 I'm checking where normalizePastedCloneUrl is actually invoked—it looks like it's meant for the "url" source type, converting owner/repo shorthand to a GitHub HTTPS URL. I want to verify that the gitea clone flow in CommandPalette resolves owner/repo paths through the provider's repository lookup RPC instead, since if it accidentally ran through normalizePastedCloneUrl it would silently point to GitHub rather than the intended Gitea instance.

16. git_tools — normalizePastedCloneUrl|repositoryLookup|source === "url"

💭 The gitea source correctly uses the provider lookup RPC path, so I'm confident there are no concrete UI-consistency violations remaining—all prior findings have been addressed. Given the instruction to make the final response exactly "All clear," I'll set the title and summary fields to that phrase while satisfying the schema's four required fields with empty details.