A forge token is a user's credential, not an instance's. The single
admin-settings config is replaced by per-user keyring rows (one per forge
host), and every server-side forge read runs on the PROJECT OWNER's keyring:
- forge_connections table + projects.forge_connection_id pin (migration 0078,
which also carries the existing admin config into the first admin's row and
deletes the old setting keys — no legacy dual-read)
- get_forge() replaced by get_forges(owner_id, project_id) -> ForgeSelector;
resolve(repo) picks the connection whose host serves the repo. A pinned
project uses ONLY its pinned connection; a stale pin (ownership moved) is
ignored, never honored across users
- env FORGE_* config survives as an implicit entry for admin owners only;
a stored row for the same host beats it
- consumers threaded: pull-time freshness (owner of the note), coverage
(owner of the project), coverage routes' configured flag
- routes: /api/settings/forge-connections CRUD + per-connection test
(own-rows only, tokens never returned); /api/admin/forge shrinks to
/api/admin/forge-webhook (secret only); PUT /api/projects/<id>/forge pins,
owner-or-admin asking, owner's connections only
- UI: Git Forges card moves to Settings -> Integrations as a connection
list; webhook secret stays in the admin Config tab; owner-only forge
select on the project coverage card
- backups exclude forge_connections (credentials, api_keys precedent) and
the pin, so restores fall back to keyring resolution
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
bvandeusenandClaude Fable 5
1faf8f3ece