main is red: world-at-ruin's live merge settings drift from the declared squash-only policy

[devantler]

🤖 Generated by the Agentic Engineer

Blocker: maintainer authority — two-field repository settings change on world-at-ruin | authority | last-verified 2026-09-08: still required; the GitOps alternative is independently blocked (see #189), provider-upjet-github v0.19.1 is the latest release and embeds terraform-provider-github v6.6.0 | asked pr 2026-09-08

Evidence

main is red on 🔍 Repository drift check, and it stayed red after #187 merged. Run 34214240250 executed at 2026-09-08T10:12:54Z against head a8ccdb3bd1 — which is #187's own merge commit — and failed:

DRIFT world-at-ruin.allowMergeCommit: declared=false live=true
DRIFT world-at-ruin.allowRebaseMerge: declared=false live=true
repository-drift: declared and live GitHub state disagree

This is the third consecutive failure of that workflow. #187 restored the drift check's schedule; it did not resolve the drift the check reports, and those are separate things. The check is working exactly as intended — it is reporting a real divergence.

Why the declared side is the correct one

Every repository in the portfolio squash-merges, and the squash subject is the PR title, which feeds Conventional Commits into the changelog and the release version. A merge-commit or rebase merge on world-at-ruin bypasses that: the release notes lose the curated subject and the version bump is computed from whatever the branch's commits happened to say. So declared=false is the policy, and the live setting is the defect.

Fixing this the other way — editing the declaration to true so the check goes green — would codify the drift and quietly remove world-at-ruin from the release contract the rest of the portfolio relies on. It would turn a red check into a silent capability loss, which is worse than the red check.

Why this is not being fixed autonomously

The remedy is a mutation of world-at-ruin's repository settings, not a code change: scripts/check-repository-drift.sh is detect-only and has no apply mode. An unattended agent run changes repository configuration only with explicit authorization, so this is being recorded rather than applied. It is a small, reversible action for someone with settings access.

Acceptance criteria

• world-at-ruin has allowMergeCommit=false and allowRebaseMerge=false, matching the declaration (gh api -X PATCH repos/devantler-tech/world-at-ruin -F allow_merge_commit=false -F allow_rebase_merge=false).
• 🔍 Repository drift check is green on .github's main.
• Confirm no other repository carries the same divergence — the check reports every drifting repo, and only world-at-ruin appeared in this run.

Rough size: XS. Whether the drift check should also apply the declared state rather than only report it is a separate question worth its own issue.

[devantler]

🤖 Generated by the Agentic Engineer

The GitOps alternative to the settings mutation does not exist, and attempting it would make things worse. Recording this because the obvious reading of world-at-ruin.yaml invites exactly that attempt.

That file says to promote the resource to the full management set "once Synced/Ready shows the observed state". That precondition is now met — the managed resource reports Synced=True/ReconcileSuccess, Ready=True/Available, and status.atProvider mirrors live (allowMergeCommit: true, allowRebaseMerge: true). So the instruction reads as actionable, and promoting looks like the way to fix this issue inside deploy/ rather than out of band.

It is not. The shared patch in deploy/repositories/kustomization.yaml adds webCommitSignoffRequired: true to every Repository, and provider-upjet-github v0.19.1 sends that field on every update PATCH. GitHub rejects such a PATCH while the organization enforces signoff, even when the requested value is true. Promoting would therefore not apply the merge policy — it would leave a failed asynchronous update, which is the state platform-tenant-template already carries and which tests/repository-update-policy.sh documents and pins against.

Live-verified today, via package registries rather than the upstream repository:

• terraform-provider-github v6.12.0 has shipped (v6.13.0 is current) — the upstream fix exists.
• provider-upjet-github v0.19.1 is still the latest release on ghcr.io/crossplane-contrib/provider-upjet-github, and it is what the cluster runs. No release yet embeds v6.12.0+.

So the acceptance criteria here stand as written: the remedy is the two-field settings change, and it needs someone with settings access. #189 records the constraint in the declaration itself so the next reader does not promote the resource and wedge it.

One correction to this issue's third acceptance criterion, which I checked: world-at-ruin is the only divergence, but it is not the only Observe-only repository. ascoachingogvaner and wedding-app are also Observe-only and already match the declared squash-only policy — so this is a real conformance gap on one repository, not an artifact of the Observe-only pattern. Excluding Observe-only resources from the drift check would silence a true finding and drop those two from coverage.