Access and Roles

Supported public path: GitLab artifact-first

Keep the first rollout narrow: admin-owned setup first, developer-owned review execution second.

This guide covers the supported public SaaS path. Deeper operator, self-hosted, and private-rollout variants are outside this guide.

Admin flow

The admin is responsible for making the first review path real and repeatable:

• Add the developer to the correct GitLab project or group.
• Configure the PatchPatrol review job on merge request pipelines.
• Set the minimum provider and review-path variables for the first run.
• Keep the initial delivery mode artifact-first so the team can confirm the outputs before enabling optional MR feedback.

Minimal blessed-path credential story:

• Provider credentials and endpoint configuration stay with the admin.
• The admin manages CI variables such as the PatchPatrol image, provider endpoint, and model selection.
• A GITLAB_TOKEN is only needed later if the team enables MR feedback delivery beyond the artifact-first baseline.

Developer flow

The developer should enter only after the setup handoff is complete:

• Confirm you can access the correct GitLab project and merge request pipeline.
• Use the existing merge request workflow to trigger the review job.
• Read ai-review.md first, then ai-review.json when you need structured detail.
• Hand any access or setup gap back to the admin instead of trying to patch the CI path yourself.

When to hand off

The handoff is ready when:

• The review job exists on the supported merge request path.
• Readiness checks passed in the same environment the job uses.
• The team knows where the generated artifacts will appear after the run.

Next step: Admin quickstart

Also continue with:

• Developer quickstart
• First review output
• Troubleshooting