🤖 Generated by the Agentic Engineer
Evidence
The repository drift check (#140) cannot read the settings it compares. Two live runs, 2026-08-07:
| Run |
Token scope |
Outcome |
| 10:46Z |
metadata: read |
aborted on the first repository — the live repository object has no "allow_auto_merge" field |
| 10:53Z |
metadata: read + administration: read |
token step failed — 422 The permissions requested are not granted to this installation |
GitHub returns a repository's merge-policy and feature settings — allow_squash_merge,
allow_merge_commit, allow_rebase_merge, allow_auto_merge, allow_update_branch,
delete_branch_on_merge, web_commit_signoff_required — only to a caller with administrative read.
Under metadata alone it omits them entirely rather than returning them empty. There is no
finer-grained permission for these fields.
The App used by this repository's workflows does not currently have that permission, so requesting it
fails before the check runs at all.
Impact
These seven fields are exactly where the check earned its keep: its first run found that
world-at-ruin allows merge commits and rebase merges though the config declares squash-only
(#141) — a divergence in the merge policy the release pipeline depends on, which nothing else had
surfaced. Without administrative read, that class of drift is invisible again.
The remaining declared fields (visibility, description, homepageUrl, topics, archived,
hasIssues, …) are readable with metadata alone, so a narrowed check would still catch the drift
#123 was originally opened about. That narrowing is deliberately not what this proposes: silently
checking fewer fields than the config declares is the failure mode the whole check exists to prevent.
What is needed
Grant the App Repository permissions → Administration: Read-only. Read-only: it permits reading
repository settings and no writes. The workflow's token is additionally restricted to the
repositories declared in deploy/, so the effective scope is read access to settings on exactly the
repositories whose settings are under management here.
This is an App permission change, which only an organisation owner can make — it is not something
deploy/ can express.
Until then
repository-drift-check.yaml runs on workflow_dispatch only; its schedule: trigger is removed so
main does not carry a permanently failing scheduled run that no change in this repository can fix.
Restoring the schedule is a one-line change once the permission is granted.
Acceptance criteria
Evidence
The repository drift check (#140) cannot read the settings it compares. Two live runs, 2026-08-07:
metadata: readthe live repository object has no "allow_auto_merge" fieldmetadata: read+administration: read422 The permissions requested are not granted to this installationGitHub returns a repository's merge-policy and feature settings —
allow_squash_merge,allow_merge_commit,allow_rebase_merge,allow_auto_merge,allow_update_branch,delete_branch_on_merge,web_commit_signoff_required— only to a caller with administrative read.Under metadata alone it omits them entirely rather than returning them empty. There is no
finer-grained permission for these fields.
The App used by this repository's workflows does not currently have that permission, so requesting it
fails before the check runs at all.
Impact
These seven fields are exactly where the check earned its keep: its first run found that
world-at-ruinallows merge commits and rebase merges though the config declares squash-only(#141) — a divergence in the merge policy the release pipeline depends on, which nothing else had
surfaced. Without administrative read, that class of drift is invisible again.
The remaining declared fields (
visibility,description,homepageUrl,topics,archived,hasIssues, …) are readable with metadata alone, so a narrowed check would still catch the drift#123 was originally opened about. That narrowing is deliberately not what this proposes: silently
checking fewer fields than the config declares is the failure mode the whole check exists to prevent.
What is needed
Grant the App Repository permissions → Administration: Read-only. Read-only: it permits reading
repository settings and no writes. The workflow's token is additionally restricted to the
repositories declared in
deploy/, so the effective scope is read access to settings on exactly therepositories whose settings are under management here.
This is an App permission change, which only an organisation owner can make — it is not something
deploy/can express.Until then
repository-drift-check.yamlruns onworkflow_dispatchonly; itsschedule:trigger is removed somaindoes not carry a permanently failing scheduled run that no change in this repository can fix.Restoring the schedule is a one-line change once the permission is granted.
Acceptance criteria
Administration: Read-only.workflow_dispatchrun ofrepository-drift-check.yamlcompletes and reportsDRIFTlines(or none) rather than aborting on a missing field.
schedule:trigger is restored.