Why a PAT, not a GitHub App, in v1
Pilot v1 ships using a customer-supplied personal access token because installing a GitHub App requires your security team to review marketplace permissions, an OAuth flow, and webhook delivery before anyone can write a draft PR. For a four-minute install, that review is the bottleneck. A PAT confines the trust to a single token your reviewers already understand — they can grant it, scope it, and revoke it from the GitHub UI without any new audit document.
Required scopes
Mint the token at github.com/settings/tokens. logomesh needs exactly two scopes:
repo— read the diff, push the branch, open the draft pull request that carries the failing pytest and the sealed artifact.workflow— only required if your repository’s CI runs the generated pytest as part of an Actions workflow. Skip it if your pipeline runs elsewhere.
Use a fine-grained PAT scoped to the single repository you’re piloting on. We never read code outside that repository, and we don’t enumerate other repos via the token.
How to rotate or revoke
- Open github.com/settings/tokens and either delete or regenerate the token.
- In your logomesh dashboard, open the GitHub row in the configuration panel and paste the new token. The old one stops working immediately.
- Audit pull requests labelled
logomesh:autoif you want a record of what was opened while the previous token was live.
The v1.1 migration
v1.1 (target Q3 2026) replaces the PAT path with a proper GitHub App install. The App will request the same contents:write + pull_requests:write permissions a PAT carries today, but with per-installation key material, narrower webhook delivery, and a one-click uninstall. Existing PAT installations will continue to work; we’ll prompt on the dashboard when the App is available so you can migrate when your reviewers have time.