feat(forge): pluggable forge abstraction + GitLab and Gitea/Forgejo/Codeberg (#1913)

* refactor(forge): forge-neutral foundation (GitHub-only)

Decouple git-hosting from GitHub behind a neutral abstraction (issue #1616), GitHub-only for now; existing GitHub behaviour is unchanged.

- Forge manifest, neutral ForgeService contract, forge registry + resolver, and a client forge-module registry.
- GitHub code renamed to the neutral shape; PR/Issue attachment wording preserved.
- forge.search.response enums parse tolerantly (unknown kind/auth state degrade instead of breaking the client).
- createPullRequest reports typed CLI/auth errors instead of a generic message.
- forge-resolver host/remote caches are LRU-bounded.
- Forge host trust is explicit: only a known cloud host or a CLI-authenticated host is ever talked to; an unauthenticated GitHub Enterprise host fails resolution instead of routing to github.com.
- Docs: forge-providers guide, glossary and i18n forge-copy conventions, architecture and rpc-namespacing terminology.
- Vitest React Native mocks (unistyles, svg, linking, lucide) consolidated into shared aliased test-stubs.

* feat(forge): GitLab adapter, forge-aware UI, pipelines and approvals

GitLab adapter over the glab CLI on the neutral contracts: MR status, forge-aware UI, pipeline tree, and N-of-M approvals.

- threadIsResolved is part of the neutral timeline item.
- Pipeline load failures show an error instead of an empty section.
- Manual pipeline jobs render as pending.
- Fork/detached MR head pipelines are fetched by MR iid (glab ci get --merge-request).

* feat(forge): Gitea family adapter (Gitea, Forgejo, Codeberg)

One adapter over the tea CLI serving Gitea, Forgejo, and Codeberg on the neutral contracts.

- CI status aggregates commit statuses and Actions runs together.
- Gitea's terminal "warning" state maps to failure on server and client.
- Gitea Actions check details are reachable from the PR pane by workflowRunId.

* refactor(forge): localize compatibility handling

* test(forge): expect normalized GitLab facts

---------

Co-authored-by: Mohamed Boudra <boudra.moha@gmail.com>

docs/architecture.md

@@ -189,7 +189,7 @@ Client liveness checks use the top-level JSON `ping`/`pong` envelope, not a sess
 
 Client session RPC waits default to 60s so slow relay or mobile networks do not turn a live but delayed daemon response into a false operation failure. Keep connect timeouts, app-level grace windows, explicit diagnostic latency probes, liveness ping timers, and genuinely long-running RPCs separate from this default.
 
-New session RPCs use dotted names with `.request` and `.response` suffixes, such as `checkout.github.set_auto_merge.request` and `checkout.github.set_auto_merge.response`. See [rpc-namespacing.md](rpc-namespacing.md) for the convention and migration rules for older flat RPC names.
+New session RPCs use dotted names with `.request` and `.response` suffixes, such as `checkout.forge.set_auto_merge.request` and `checkout.forge.set_auto_merge.response`. See [rpc-namespacing.md](rpc-namespacing.md) for the convention and migration rules for older flat RPC names.
 
 **Notable session message types:**
 
@@ -271,14 +271,14 @@ Two workspaces can share the same `cwd` (e.g. a `directory` workspace and a `loc
 
 **Directory-backed (shared by same-`cwd` workspaces) — keyed by `(serverId, cwd)`, never by `workspaceId`:**
 
-| Surface                | Key                                                      | Source                                                  |
-| ---------------------- | -------------------------------------------------------- | ------------------------------------------------------- |
-| Git status             | `checkoutStatusQueryKey(serverId, cwd)`                  | `packages/app/src/git/query-keys.ts`                    |
-| Git diff               | `checkoutDiffQueryKey(serverId, cwd, mode, baseRef, ws)` | `packages/app/src/git/query-keys.ts`                    |
-| GitHub PR status       | `checkoutPrStatusQueryKey(serverId, cwd)`                | `packages/app/src/git/query-keys.ts`                    |
-| PR pane timeline       | `prPaneTimelineQueryKey({ serverId, cwd, prNumber })`    | `packages/app/src/git/pull-request-panel/query-keys.ts` |
-| File preview content   | `["workspaceFile", serverId, cwd, path]`                 | `packages/app/src/components/file-pane.tsx`             |
-| File explorer listings | fetched via `listDirectory(workspaceRoot, path)`         | `packages/app/src/hooks/use-file-explorer-actions.ts`   |
+| Surface                 | Key                                                      | Source                                                  |
+| ----------------------- | -------------------------------------------------------- | ------------------------------------------------------- |
+| Git status              | `checkoutStatusQueryKey(serverId, cwd)`                  | `packages/app/src/git/query-keys.ts`                    |
+| Git diff                | `checkoutDiffQueryKey(serverId, cwd, mode, baseRef, ws)` | `packages/app/src/git/query-keys.ts`                    |
+| Forge change request    | `checkoutPrStatusQueryKey(serverId, cwd)`                | `packages/app/src/git/query-keys.ts`                    |
+| Change request timeline | `prPaneTimelineQueryKey({ serverId, cwd, prNumber })`    | `packages/app/src/git/pull-request-panel/query-keys.ts` |
+| File preview content    | `["workspaceFile", serverId, cwd, path]`                 | `packages/app/src/components/file-pane.tsx`             |
+| File explorer listings  | fetched via `listDirectory(workspaceRoot, path)`         | `packages/app/src/hooks/use-file-explorer-actions.ts`   |
 
 **Workspace-owned (independent per workspace) — keyed by `workspaceId` (falling back to `cwd` only when no `workspaceId` exists):**
 

docs/forge-providers.md

@@ -0,0 +1,176 @@
+# Adding a Git Forge to Paseo
+
+Paseo's forge layer is a registry/manifest system. A forge is a runtime concern:
+shared protocol messages carry neutral/open facts, the server adapter owns
+behavior, and the app owns bundled presentation/runtime interpretation.
+
+The maintainer litmus test is the rule of thumb:
+
+> Adding a new forge means adding files in a new directory/module that implement
+> an interface, plus one entry in the centralized registry/manifest for that
+> package.
+
+## The Three Registrations
+
+For forge `acme`, the expected end state is:
+
+1. **Protocol manifest** - optional, only when the forge should be presented by
+   shared manifest data. Add one `ForgeDefinition` to
+   `packages/protocol/src/forge-manifest.ts`.
+
+2. **Server adapter** - add `packages/server/src/services/acme-service.ts`
+   implementing `ForgeService`, any adapter-owned fact types/guards/constants
+   beside it, and one `defaultForgeRegistry` entry in
+   `packages/server/src/services/forge-registry.ts`.
+
+3. **App modules** - a forge splits into a pure logic half and a view half so
+   logic consumers (URL builders, merge-capability, native checks, and the
+   Node-based e2e harness) never pull the client rendering stack:
+   - `packages/app/src/git/forges/acme.ts` - logic: `id`, optional `urlGrammar`,
+     optional `facts` (schema, merge-capability, native-check fallbacks). No
+     React/React-Native imports. Register in `CLIENT_FORGE_LOGIC_MODULES` in
+     `packages/app/src/git/forges/index.ts`.
+   - `packages/app/src/git/forges/acme.view.tsx` - view: `icon` (SVG component
+     under `packages/app/src/components/icons/`), optional `brandColor`, optional
+     `paneContributions`. Register in `CLIENT_FORGE_VIEW_MODULES` in
+     `packages/app/src/git/forges/view.ts`.
+
+There should be no protocol typed-union arm, no central app icon/color/url/facts
+map, and no central server union of known forge facts.
+
+## Protocol
+
+`forgeSpecific` on PR status is an open envelope:
+
+```ts
+z.object({ forge: z.string() }).passthrough();
+```
+
+The `forgeSpecific.forge` field is a **facts-family tag**, not the workspace
+brand id. Gitea, Forgejo, and Codeberg can all emit `forgeSpecific.forge ===
+"gitea"` when they share the same facts shape, while top-level `status.forge`
+keeps the brand id (`"gitea"`, `"forgejo"`, `"codeberg"`).
+
+Protocol does not validate per-forge fact fields. Consumers that understand a
+facts family validate at runtime with their own schema/guard. Unknown or
+schema-mismatched facts render neutrally instead of failing the whole message
+parse. This is the version-skew win: an old client can receive facts from a
+newer forge and still show the PR/MR in a neutral state.
+
+Shipped GitHub compatibility stays separate:
+
+- `status.github` remains accepted for released peers.
+- The server keeps the `COMPAT(forgeSpecific)` mirror that copies GitHub facts
+  into `status.github` for older clients.
+- Do not add a compatibility shim unless a released peer (<= 0.1.102) can
+  actually produce the state.
+
+## Server
+
+The server-wide status type only promises:
+
+```ts
+type ForgeSpecificStatusFacts = { forge: string } & Record<string, unknown>;
+```
+
+Adapter-owned files define the typed shapes and guards, for example
+`github-facts.ts`, `gitlab-facts.ts`, and `gitea-facts.ts`. The adapter can keep
+strong internal types for construction and command guards, but shared server
+code must not grow a central list of forge fact arms.
+
+Register the adapter in `defaultForgeRegistry` with:
+
+- `createService`
+- `matchesHost` from manifest `cloudHosts`
+- `probeHost` when self-hosted/Enterprise detection is supported
+
+Cloud hosts in the manifest are a bounded public-host list, not a self-host
+allowlist. Self-hosted detection is a trust gate: Paseo only talks to a forge
+host that is either a known cloud host or one the CLI is already authenticated
+to. Adapter probes must not make anonymous HTTP requests to remote-derived
+hosts, and adapters must not route credentials to an unauthenticated host.
+
+## App
+
+Each app forge splits into two modules so pure logic never imports the client
+rendering stack:
+
+`acme.ts` exports a `ClientForgeLogicModule`:
+
+- `id`
+- optional `urlGrammar`
+- optional `facts` registration (schema, merge-capability, native-check fallbacks)
+
+`acme.view.tsx` exports a `ClientForgeViewModule`:
+
+- `id`
+- `icon`
+- `brandColor` (`null` for neutral; GitHub intentionally uses `null`)
+- optional `paneContributions`
+
+Two registries live under `packages/app/src/git/forges/`:
+`CLIENT_FORGE_LOGIC_MODULES` (`index.ts`) drives URL grammar, merge-capability
+derivation, and native fallback checks; `CLIENT_FORGE_VIEW_MODULES` (`view.ts`)
+drives icon/color lookup and PR-pane contributions. Logic consumers must import
+the logic registry only — importing the view registry (or a `.view.tsx` module)
+from a logic path pulls react-native and breaks the Node-based e2e harness.
+
+Per-forge brand colors live on the module, not in `styles/theme.ts`. Use the
+Unistyles-safe pattern from `docs/unistyles.md`: no `useUnistyles()`. Brand icon
+call sites use `withUnistyles` and a `uniProps` mapping such as:
+
+```ts
+(theme) => ({ color: theme.colorScheme === "light" ? colors.light : colors.dark });
+```
+
+Facts modules use one source of truth: a Zod schema. Helpers like
+`defineForgeFacts`, `defineNativeFallbackCheck`, and `definePaneContribution`
+derive guards from `schema.safeParse` and re-parse before invoking typed
+derivers/renderers. That keeps typed derivers away from the open wire envelope.
+
+## Checklist
+
+To add `acme`:
+
+1. Add `acme` to `FORGE_DEFINITIONS` if the shared manifest should know its
+   label, nouns, icon kind, sign-in CLI, or cloud hosts.
+2. Add `acme-service.ts` implementing `ForgeService`.
+3. Add `acme-facts.ts` beside the adapter if it reports native facts.
+4. Add one `defaultForgeRegistry` entry.
+5. Add `packages/app/src/git/forges/acme.ts` (logic) and
+   `packages/app/src/git/forges/acme.view.tsx` (view).
+6. Add one `CLIENT_FORGE_LOGIC_MODULES` entry (`index.ts`) and one
+   `CLIENT_FORGE_VIEW_MODULES` entry (`view.ts`).
+7. Add/update the icon component only if the client bundle should show a brand
+   mark.
+8. If the forge's CI/data model does not fit an existing required
+   `ForgeService` field, widen the shared interface (plus the protocol schema
+   and its guards) instead of faking a value — e.g. Gitea Actions runs carry no
+   check-run id, so `GetCheckDetailsOptions.checkRunId` became optional with
+   `workflowRunId` as the alternative address. Expect this step to touch
+   `forge-service.ts`, `messages.ts`, and the call-site guards of the other
+   adapters. Widening a shared field is not forge-local: it also affects the
+   already-shipped forges/GitHub call sites and the capability-gated RPC (e.g.
+   `forgeCheckDetails`), so verify every consumer rather than assuming the change
+   only reaches the new adapter.
+9. Run targeted tests: manifest/registry/resolver, the adapter test, protocol
+   checkout PR schema, app forge URL/presentation tests, app merge capability,
+   and any PR-pane native data tests touched.
+
+Run `npm run typecheck` after each implementation slice. If protocol or client
+declarations are stale, run `npm run build:client`; if server/CLI declarations
+are stale, run `npm run build:server`.
+
+## Gotchas
+
+- GitHub is a normal registry entry plus released compatibility shims. Keep all
+  real shims tagged with `COMPAT(name)`.
+- Gitea-family facts use `forgeSpecific.forge === "gitea"` even when the
+  top-level brand is Forgejo or Codeberg.
+- Brand icons are bundled React components, so they cannot come from protocol
+  manifest data.
+- Source URL grammars are app-side because blob/tree path syntax is
+  forge-specific. If a forge has no grammar, omit the "Open on ..." source link
+  rather than constructing a wrong URL.
+- GitLab pipeline status constants belong to the GitLab adapter/client module,
+  not protocol.

docs/glossary.md

@@ -13,9 +13,12 @@ Authoritative terminology. UI label wins. Don't invent synonyms; use what's here
 - **Project host entry** — One row in a project for a single (project, daemon) pair, aggregating that daemon's workspaces in the project. Internal. Code: `ProjectHostEntry` (`packages/app/src/utils/projects.ts:11`). Don't introduce "Checkout" as a synonym.
 - **Placement** — One workspace's relationship to its project (projectKey, projectName, git checkout snapshot). Internal. Code: `ProjectPlacementPayload` (`packages/protocol/src/messages.ts:2113`).
 - **Branch** — Plain git branch. UI: "Switch branch". Code: `currentBranch` in `WorkspaceGitRuntimePayloadSchema` (`packages/protocol/src/messages.ts:2136`); `BranchSwitcher` (`packages/app/src/components/branch-switcher.tsx`).
+- **Forge** — Git hosting service behind Paseo's change-request features: GitHub, GitLab, Gitea, Forgejo, or a future registered adapter. Code: `ForgeService`, `forge-registry`, `forge-resolver`. Use `forge` for internal abstraction and registry IDs; use concrete forge names only when a behavior or RPC is forge-specific.
+- **Change request** — Forge-neutral term for a proposed branch-to-branch code change. UI normally renders the forge noun instead: GitHub/Gitea/Forgejo "PR", GitLab "MR". Code: `forge_change_request` attachments, `checkoutSource: { kind: "change_request" }`, and PR/MR status payloads.
+- **MR** — GitLab merge request. UI label for GitLab change requests only; do not use MR for GitHub/Gitea/Forgejo.
 - **Worktree** — Paseo-managed git worktree (`~/.paseo/worktrees/{name}`); also a `workspaceKind` value. UI: CLI + `paseo.json` keys (`worktree.setup`, `worktree.teardown`) only. Code: `ProjectCheckoutLiteGitPaseoPayload` (`packages/protocol/src/messages.ts:2092`); CLI `paseo worktree` (`packages/cli/src/commands/worktree/index.ts:8`). Forbidden: "Checkout" as a synonym.
 - **Repository / Remote** — Internal git inputs (`remoteUrl`, `mainRepoRoot`) used to derive `projectKey`. No UI label.
-- **Directory-backed surface** — A right-sidebar surface whose content is determined by the workspace's `cwd`, so two workspaces on the same directory see identical content: git diff/status, GitHub PR info, file preview/explorer contents. Keyed by `(serverId, cwd)`, never `workspaceId`. See [architecture.md](architecture.md#right-sidebar-boundary-directory-backed-vs-workspace-owned).
+- **Directory-backed surface** — A right-sidebar surface whose content is determined by the workspace's `cwd`, so two workspaces on the same directory see identical content: git diff/status, forge change-request info, file preview/explorer contents. Keyed by `(serverId, cwd)`, never `workspaceId`. See [architecture.md](architecture.md#right-sidebar-boundary-directory-backed-vs-workspace-owned).
 - **Workspace-owned state** — Per-workspace state that never leaks to a same-`cwd` sibling: tabs, agents, terminals, panes, title, plus review drafts, diff-mode overrides, composer attachments, and file-explorer open/expand state. Keyed by `workspaceId` (`cwd` only as a fallback for old payloads). See [architecture.md](architecture.md#right-sidebar-boundary-directory-backed-vs-workspace-owned).
 - **Workspace status bucket** — Aggregate activity signal for a workspace row. Same-`cwd` workspaces intentionally share agent and terminal status buckets, while tab, agent, and terminal visibility remains scoped by `workspaceId`.
 - **Agent session** — One running instance of an agent inside a workspace (one provider, one model, one cwd, one timeline). The conceptual unit; in the UI this opens as a tab. Moving toward this as the canonical term over "Agent". Code: `AgentSnapshotPayload` (`packages/protocol/src/messages.ts:608`).
@@ -28,7 +31,7 @@ Authoritative terminology. UI label wins. Don't invent synonyms; use what's here
 - **Schedule** — Cron-style trigger that creates new agents. UI: CLI/MCP (`paseo schedule`, `create_schedule`). Don't confuse with: Heartbeat (cron prompt back into the same agent) or Loop (iterative re-execution of one agent).
 - **Heartbeat** — Cron-style prompt sent back into the same agent/conversation. MCP: `create_heartbeat`. Use for reminders and babysitting where the status should return inline.
 - **Mode** — Provider-specific operational mode (plan, default, full-access, …). UI: icon-only. Code: `modeId` in `AgentSessionConfig` (`packages/protocol/src/messages.ts:257`).
-- **Attachment** — GitHub PR or Issue bound to an agent prompt. UI: "Attach issue or PR". Code: `AgentAttachment` (`packages/protocol/src/messages.ts:782`).
+- **Attachment** — External or local context bound to an agent prompt: forge issue/change request, review context, uploaded file, text, or image. UI: "Attach issue or PR/MR". Code: `AgentAttachment` (`packages/protocol/src/messages.ts:782`).
 - **Composer** — The whole prompt surface for sending work to an agent. Code: `Composer` (`packages/app/src/composer/index.tsx`). Don't call this "message input" except for the text-entry subcomponent.
 - **Composer input** — The text-entry surface inside the composer. Code: `MessageInput` (`packages/app/src/composer/input/input.tsx`).
 - **Composer toolbar** — The bottom control row inside the composer input. Contains agent controls, attachment button, voice controls, and stop/send controls. Code: `leftContent`, `beforeVoiceContent`, and `rightContent` slots in `MessageInput` (`packages/app/src/composer/input/input.tsx`). Forbidden: "Status bar".

docs/i18n.md

@@ -37,6 +37,15 @@ npx vitest run packages/app/src/i18n/resources.test.ts --bail=1
 
 The parity test catches missing keys across English and every supported locale resource.
 
+## Forge-Variant Copy
+
+Strings that vary by git forge follow a two-tier rule:
+
+- **Indeclinable tokens** — brand names ("GitHub", "GitLab"), the PR/MR initialism, number prefixes (`#`/`!`) — are interpolated into a single key (`"Refresh git and {{brand}} state"`). These tokens stay latin and uninflected in every supported locale, so one string per locale suffices. The value comes from the forge manifest via `getForgePresentation`.
+- **Sentences containing the full change-request noun** ("pull request" / "merge request" inflects and takes gender/case in translation) use the i18next `context` mechanism: the base key carries the pull-request wording and an `_mr` sibling carries the merge-request wording (`pullRequest` / `pullRequest_mr`). Call sites pass `t(key, { context: getForgePresentation(forge).changeRequestContext })`; an undefined or unknown context falls back to the base key.
+
+Keys scale per vocabulary family (PR vs MR), not per forge: a new forge picks an existing family in its manifest entry and needs zero locale edits.
+
 ## Migration Order
 
 Client UI translation is staged so each pass can migrate complete local copy clusters and keep reviews focused.

docs/rpc-namespacing.md

@@ -3,14 +3,14 @@
 New WebSocket session RPCs use dotted names with the direction as the final segment:
 
 ```ts
-checkout.github.set_auto_merge.request;
-checkout.github.set_auto_merge.response;
+checkout.forge.set_auto_merge.request;
+checkout.forge.set_auto_merge.response;
 ```
 
 The namespace reads left to right:
 
 - Domain: `checkout`
-- Provider or subsystem: `github`
+- Namespace segment: `forge`
 - Operation: `set_auto_merge`; this segment is a verb, not a noun. If you would name an RPC `noun.request`, name it `get_noun.request` instead.
 - Direction: `request` or `response`
 
@@ -21,8 +21,8 @@ Use dots, not slashes. Dots are protocol namespaces; slashes imply paths or tran
 For ordinary correlated RPCs, a `.request` has a matching `.response` with the same prefix. The daemon client may derive the response type mechanically:
 
 ```ts
-checkout.github.set_auto_merge.request;
-// -> checkout.github.set_auto_merge.response
+checkout.forge.set_auto_merge.request;
+// -> checkout.forge.set_auto_merge.response
 ```
 
 Most new RPCs should follow this shape. If a request does not have a one-to-one response, call that out in the code near the schema.
@@ -33,7 +33,7 @@ Requests keep their parameters at the top level:
 
 ```ts
 {
-  type: "checkout.github.set_auto_merge.request",
+  type: "checkout.forge.set_auto_merge.request",
   cwd: "/repo",
   enabled: true,
   mergeMethod: "squash",
@@ -45,7 +45,7 @@ Responses put correlated result data under `payload`:
 
 ```ts
 {
-  type: "checkout.github.set_auto_merge.response",
+  type: "checkout.forge.set_auto_merge.response",
   payload: {
     cwd: "/repo",
     enabled: true,
@@ -58,14 +58,16 @@ Responses put correlated result data under `payload`:
 
 Keep `requestId` in both request and response payloads. It is the correlation key.
 
-## Provider Namespacing
+## Forge Namespacing
 
-Provider-specific behavior belongs under the provider segment:
+Forge-neutral behavior currently uses `checkout.forge.*` for checkout-scoped operations and `forge.search.*` for forge search; forge-specific names belong here only after schema and session handlers exist:
 
-- `checkout.github.*` for GitHub-specific checkout operations
-- `checkout.gitlab.*` for future GitLab-specific checkout operations
+- `checkout.forge.*` for operations whose request/response shape is genuinely
+  forge-neutral and whose implementation dispatches through the forge resolver.
+- `checkout.github.*` for existing GitHub-specific compatibility RPCs while
+  callers migrate to the neutral `checkout.forge.*` shape
 
-Do not put GitHub-specific enums or semantics into generic checkout RPC names. A generic RPC should only exist when the behavior is genuinely provider-neutral.
+Do not put GitHub-specific enums or semantics into `checkout.forge.*` RPC names. A generic forge RPC should only exist when the behavior is genuinely forge-neutral.
 
 ## Compatibility