T-G1NZ-forgejo-adapter-for-the-forge-port

State: closed/done · Impact: low · Complexity: medium

Goal

The Forge port (T-DVLT) is only worth building if a second adapter actually plugs in with no change elsewhere. docs/planning/notes/N-G3HA-forges-forgejo.md already documents Forgejo’s REST API and its gaps against GitHub (notably no merge-state field), so this task is the proof.

Approach

1. Implement the Forgejo adapter against the same Forge interface, using docs/planning/notes/N-G3HA-forges-forgejo.md for the REST surface.
2. Map Forgejo’s weaker merge-state fields onto PrFacts using the same locally-computed behind/ahead as GitHub, since Forgejo exposes no equivalent field at all.
3. Add per-repo forge selection from the remote URL, with a config override.
4. Run pr-update’s and classify’s existing behavior against a Forgejo fixture repo.

Areas

Area	Note
packages/ts/pr-update/ (or wherever T-DVLT lands the port)	Forgejo adapter
docs/planning/notes/N-G3HA-forges-forgejo.md	REST surface and gaps vs. GitHub

Acceptance criteria

• AC-1: A repo with a Forgejo remote resolves to the Forgejo adapter automatically.
• AC-2: pr-update and pr classify produce equivalent verdicts against a Forgejo fixture PR as against an equivalent GitHub one.
• AC-3: No code outside the adapter branches on forge name.

Out of scope

• additional forges beyond GitHub and Forgejo

Known Gaps

• sdlc pr review (solutions/ontological/lib/services/pr/ops/review.ts) still fetches PR state via a hand-built Gh.prView call instead of Forge/selectForge, so it stays GitHub-only — unlike classify and the prs tick, which both already go through the port. Routing it through Forge.getPr is a separate follow-up, out of scope here.

Dependencies

• T-DVLT

Depends on

T-DVLT

---

← Back to Tasks