[gorlix]

Closes #2

What

Classifies each access token at setup (project, group, service account or personal) and uses what it covers when resolving repositories.

• CompleteIdentitySetup stores token_type, resource_id and resource_path. Project and group tokens are told by the bot user name GitLab gives them (project_<id>_bot…, group_<id>_bot…) and the path is looked up via GET /projects/:id or GET /groups/:id (if the lookup fails the type is kept and the path stays empty). Any other bot user is a service account (its name may be chosen by its creator, so it is told by GitLab's bot flag); a human user holds a personal token.
• identityOf sets DisplayName: "Project token · acme/ui", "Group token · acme/frontend", "Service account · ", "Personal token · ".
• ResolveRepository skips a project token whose project doesn't match and a group token whose path doesn't contain the repo, then requires access_level >= Developer, so a public repo is never bound to a non-member token. When every connection is skipped, the error says what each one covers (or that its role is too low) and asks for a token that is a member of the repository.
• MintCredential now also refuses AccessWrite at access level 0.
• Identities stored before this change are classified lazily from the stored username and bot flag on first load and then persisted.

Migration

New 0003_identity_token_reach.sql adds the three columns, leaving existing rows empty. 0002 is untouched. If you'd rather fold it into 0002 (v0.6.0 is not released yet), say so and I'll change it.

Verification

• Unit tests extend the fake GitLab with project/group bot users, /groups/:id and per-token roles.
• Verified against a real GitLab CE in Docker, Postgres 16, TinyGo 0.41.1 and golangci-lint (0 issues). The real-GitLab run covers project, group, personal and service-account tokens, a group token and a sibling group sharing a name prefix, a public repository, a Reporter-level token, candidate order, lazy classification of existing rows and writes at level 0.
• Verified in a real Paca core with a real GitLab CE: migrations 0001–0003, display names, project/group token linking, rejection of repos outside a token's reach, and webhook ingestion.
• Verified against gitlab.com with a personal token and a group service account (Developer on the group): the connections are named "Personal token · " and "Service account · ", repositories in the group resolve, a repository outside it and a public one it is not a member of are refused, and a write credential is refused for the latter.

Notes

• Project and group access tokens are available on GitLab.com only with Premium or Ultimate (and on self-managed with any licence). On GitLab.com Free the common cases are a personal token or a service account, which the same rules handle.
• The plugin's coverage messages ("The connected project token covers only …") currently do not reach the user: core maps NotFound/Forbidden from ResolveRepository to a generic ErrNotVisible. The generic UI text is acceptable; surfacing the detail would need a core change, which is out of scope here.
• Not covered in the core run: Reporter-level project tokens, service accounts and the public-repo case against a non-member; these are covered by the unit tests and the real-GitLab runs above.

🤖 Generated with Claude Code

[pikann]

LGTM! Thank you for the contribution! 🚀