Support for multiple forges (not just GitHub)

[ic4-y]

Context

Kolu's PR metadata integration is hardcoded to GitHub. The kolu-github package shells out to gh pr view, which only resolves PRs on repositories whose remotes point to a known GitHub host. When a terminal's repo is hosted on any other forge (Forgejo, GitLab, Gitea, SourceHut, etc.), gh pr view fails with:

none of the git remotes configured for this repository point to a known GitHub host.

This is classified as not-authenticated and logged as WARN on every 30s poll cycle — noisy and misleading for users who simply aren't on GitHub.

Current Architecture

• packages/integrations/github/ — gh-CLI-based PR resolution, tightly coupled to GitHub's API surface
• packages/server/src/terminalBackend/providers.ts:startGitHubPrProvider — wires the GitHub watcher into the terminal metadata pipeline
• Remote forge detection does not exist — the provider is always github-pr regardless of the actual remote URL

Proposed Direction

Introduce a forge abstraction so kolu can resolve PR metadata across multiple forges:

1. Forge detection — parse the remote URL's host to identify the forge type (GitHub, GitLab, Forgejo/Gitea, etc.). Fall back to absent when the remote is not a recognized forge, and suppress PR-related logging in that case.

2. Provider interface — define a common PrProvider interface (resolve PR by repo+branch, return number/title/url/state/checks) that each forge adapter implements. The existing kolu-github package becomes the GitHub adapter.

3. Dispatch — subscribeGitHubPr (or its successor) picks the right adapter based on the detected forge, or emits absent when no adapter matches.

4. Forgejo/Gitea — these expose a GitHub-compatible API surface, so the existing gh-based approach may work with --host configuration, or a lightweight adapter using the Forgejo API directly.

5. GitLab — requires a separate adapter using the GitLab REST/GraphQL API.

Motivation

Self-hosted forges (Forgejo, Gitea, GitLab) are common in the Nix/NixOS ecosystem. Kolu's user base skews technical and many will not be on GitHub. PR metadata is a visible part of the terminal dock (the PR pill), and losing it entirely on non-GitHub repos degrades the experience.

Scope

This is a feature request, not a bug report. The immediate log noise could be papered over by reclassifying the "no GitHub remote" error as absent, but the right fix is forge abstraction. Happy to help with implementation or testing against a Forgejo instance.

[srid]

@ic4-y Let's start with a 2nd forge that you yourself use—what's the concrete CLI usage for that like?

[ic4-y]

Yeah that is the idea I had. I am using forgejo-cli fj which is sadly not as smooth as using gh on github and creates issues for agents again and again.

I could try to let opencode code something up and then open a draft PR maybe?

[srid]

I could try to let opencode code something up and then open a draft PR maybe?

Sure; point me to your branch.

(contributors PRs disabled temporarily on this repo)

[ic4-y]

I have a first draft: ic4-y#1

It's a pretty hefty one

I haven't tested everything, but showing open PRs on my forgejo works. I have not checked codeberg and whether github has any regressions, and whether anything else is working.

Maybe tomorrow.

[ic4-y]

Nice, we're making massive progress I see!

[srid]

@ic4-y #1257 lays the foundation; could you open a PR here for foregejo support? Post screenshots of features that you can get working.

Note that if there's a runtime dependency, you want to bake it Nix; gh example: https://github.com/search?q=repo%3Ajuspay%2Fkolu+pkgs.gh&type=code

[ic4-y]

Okay, I'll check this tomorrow. So opening PRs against this repo is now possible again?