Repository identity has no forge dimension, so a repository that moves keeps answering from the host it left

[jakewan]

Context

Surfaced while planning a repository migration off GitHub onto a self-hosted forge, by an operator who drives this server from project-management skills that pass owner/repo. The question that produced it was what those skills would report once a repository no longer lives on GitHub. Deferred out of that planning work — nothing here has been observed in production.

Problem

A repository is addressed as owner/repo and resolved against exactly one host, and that host is not part of the address. The README states both halves: tools "resolve a single explicit owner/repo against that repo's manifest conventions", and issues are fetched "in-process from the GitHub GraphQL API" using "the operator's existing gh credentials". No host, base URL, or forge appears anywhere in a repository's identity.

Two consequences follow, and the second is the one worth filing.

No coverage for a repository hosted anywhere else. A repository on a self-hosted forge cannot be surveyed at all. This is the obvious gap, and it announces itself — a call fails, or returns nothing.

A repository that moves keeps answering, from a copy that stopped changing. This one does not announce itself. Where a migration leaves the GitHub repository in place — archived, or simply abandoned — the slug still resolves, and GitHub serves reads against an archived repository. So the server returns a complete, well-formed issue graph: milestones, dependency edges, staleness signals, recommendation inputs. Every field is populated. Every field is frozen at the moment that repository stopped being the live one. A consumer cannot distinguish that reading from a reading of the live project, because the two have identical shape.

The first consequence is a failure. The second is a wrong answer wearing a correct answer's clothes, which is the one that survives review.

Evidence

• Tools "resolve a single explicit owner/repo against that repo's manifest conventions" (README).
• Issues are fetched "in-process from the GitHub GraphQL API", authenticated with "the operator's existing gh credentials" (README).
• Neither the README nor the tool surface exposes a host, base URL, or forge parameter.

What bounds any approach

Stated as constraints rather than as a design, because they change what each option costs:

• The query layer is GraphQL. Forgejo and Gitea expose REST only, so a second backend is not a base-URL swap — composite reads become several calls each.
• The credential path is gh. The GitHub CLI's host override targets GitHub Enterprise, so it does not reach a Forgejo instance; a second backend needs its own auth path rather than a redirected one.
• The two halves separate cleanly. Knowing which forge a repository is on is a much smaller change than being able to talk to a second one — and it is the half that stops the silent-stale answer, since a repository marked as living elsewhere can be refused rather than answered wrongly, before any second backend exists.

Suggested approaches (options, not a prescription)

• Carry the forge in a repository's identity — a host or forge field on the manifest entry — and refuse rather than answer when a repository is marked as living somewhere this server cannot reach.
• Add a second backend behind the existing tool surface, so the reductions keep their shape across forges.
• Neither, and document the boundary instead: state that a slug is resolved against GitHub unconditionally, so a consumer knows a stale-but-complete answer is possible.

[jakewan]

Direction taken, recorded against the three options above rather than leaving them open.

The first option is the one being pursued, and it is pursued first. Carrying the forge in a repository's identity and refusing rather than answering needs no second backend, no second credential path, and no client — and it is the half that closes the silent-stale reading this issue was filed about. The third option, documenting the boundary instead, is declined: a documented boundary does not stop a consumer from receiving a complete, well-formed, frozen answer.

The second option stays open, and it is larger than "composite reads become several calls each." That framing above is right but incomplete. Measured 2026-09-06 against a live Forgejo instance's published API specification, the reads split into three kinds rather than one:

• Decomposition. Native dependency edges exist (/issues/{index}/dependencies and its /blocks inverse), but per issue, so a repository-wide dependency graph becomes one call per issue rather than a field inside the composite read. Cross-references decompose the same way, through the per-issue timeline.
• No carrier at all. There is no sub-issue hierarchy in the specification, and no upstream date to wait for. Issue body text has no rendered-plaintext equivalent, only raw markdown — which matters because the quality reduction measures prose length on it, so the measurement changes meaning rather than merely changing source. Commits carry no author filter, so one authored-activity count has no reconstruction.
• Inverted shape. The maintenance-activity read assumes a repository-wide event stream. The nearest equivalent is a repository activity feed whose operation vocabulary carries close and reopen but not labelling, milestoning, assignment or renaming — two of the eight mutation types that reduction filters on — and which pages by a single date with no cursor and no monotonic event id, so neither the truncation flag nor the cross-page deduplication has an analogue.

The useful correction for anyone sizing this: the newest tools are the worst served, not the oldest. The authored- and maintenance-activity reads have the weakest carriers, because they rest on GitHub's author-filtered search and its repository-wide events stream.

One prerequisite surfaced that is worth doing on GitHub alone. A second backend supplying fewer inputs than the reductions expect reproduces this issue's own failure one level down — a verdict computed without a seam is indistinguishable from one computed with it clear. That is filed separately as #134. It is not gated on this issue and this issue is not gated on it; they are independent, and #134 is the one that has to land before any second backend, or the backend ships a degraded answer wearing a correct answer's clothes.

The credential bound stated above is unchanged: a second backend needs its own auth path rather than a redirected one.

[jakewan]

The second option now has a design: design/forge-backends.md, landed in #138. It is non-normative and nothing is built. Checking the per-read gaps in the comment above against the published Forgejo API specifications (v15.0.8 and v16.0.4) corrects part of that classification:

• Maintenance activity decomposes; its shape is not inverted. Each issue's /timeline carries label, milestone, assignee and title changes with the actor, so the read lists items updated since the window start and then reads each one's timeline. That rests on every counted mutation bumping the item's updated_at. Label and title changes were observed doing so on a public instance; milestone and assignee changes are unconfirmed.
• The authored commit count is rebuilt with divergence, not absent. /commits has no author or date filter, but walking the default branch and filtering locally reconstructs the count. It has no clean date stop, and attribution works only through commit emails, so migrated no-reply addresses resolve to no one.
• Forgejo's search person filters answer about the wrong person. created, reviewed, assigned and mentioned on /repos/issues/search filter by the authenticated user, so authored counts use the repository issue list's created_by instead.

Unchanged: no sub-issue hierarchy, raw-markdown bodies, and no repository-wide events stream. The design also lists the inputs that need an availability signal before a backend ships, including TotalOpen wherever a list declares no total.