music-curator push allowlist: the Actions-app entry applies successfully but never persists

[cpitzi]

Surfaced while applying unrelated changes during the epigaea rename. This has been carried as "an apply still owed" from #98 — it is not. The apply runs, reports success, and the change does not take.

Evidence. terraform apply completes cleanly:

github_branch_protection.merge_gate["music-curator"]: Modifying... [id=BPR_kwDOS60XPc4E3jCB]
github_branch_protection.merge_gate["music-curator"]: Modifications complete after 6s
Apply complete! Resources: 0 added, 2 changed, 0 destroyed.

Live state immediately afterward:

$ gh api repos/lentago/music-curator/branches/main/protection/restrictions
{"apps":[],"teams":[],"users":["cpitzi"]}

And the very next terraform plan proposes the identical change again — a perpetual diff, permanently.

Why it matters beyond plan noise. terraform/README.md documents this allowance as load-bearing: the GitHub Actions app is on music-curator's push allowlist "so follow-fold's documented bot merge (music-curator#9) keeps working." If the entry has never actually been live, then either that bot merge does not work, or it works by some other route and the config encodes a belief about the system that is not true. Both are worth knowing; a config that describes a capability the platform never accepted is worse than an absent one, because it reads as covered.

Likely mechanism (unverified): GitHub's branch-protection restrictions API accepts app entries only for apps installed on the repository with write access, and appears to silently drop entries it will not honor rather than erroring. That would explain an apply that reports success while changing nothing.

Worth checking, in order:

1. Has follow-fold actually been merging its own PRs, or has that quietly required a human all along?
2. Is the github-actions app even addressable in a push allowlist, or is the org-level "Allow GitHub Actions to create and approve pull requests" setting the real control surface?
3. If the capability is unreachable, remove the allowance from protection.tf and correct the README — the perpetual diff is a standing lie in every plan, and eliminating it makes real drift visible again.

Related: #98 (where this was first recorded as owed), and the plan-noise principle — a diff that never clears trains readers to skim plans, which is exactly how a genuine change slips through.

[cpitzi]

Investigated 2026-08-22 against live state. The hypothesis holds, and it goes further than this issue suspected. Fix in #169; the follow-fold decision is music-curator#87.

Answers to the three questions

1. Has follow-fold ever merged its own PRs? No — it has never had the chance. All 59 merged PRs in music-curator were merged by cpitzi; no harvest/follows-* PR has ever been opened; follow-fold.yml has run exactly twice (2026-07-23), both skipped by its own if: startsWith(head.ref, 'harvest/follows-') guard. The "documented bot merge" has only ever existed as a design. (#98's "batches fail their merge step until applied" was a prediction, not an observation.)

2. Is the github-actions app addressable in a push allowlist? No, in any id format. Classic branch protection admits users, teams, and GitHub Apps installed on the repository with write access. The built-in Actions identity is not an installation — gh api orgs/lentago/installations lists claude, lentago-claude-runner, claude-design-import, devin-ai-integration, and nothing else — and GitHub staff have declined to allow it deliberately, since any collaborator could then bypass protection by authoring a workflow (community discussion #25305; docs). The mutation drops an ineligible actor without erroring, the provider reports success, and the next plan re-proposes it. #98's next-format id was a red herring: the entry fails identically with both ids, which is why #98 changed nothing.

3. The diff is still live. Latest apply on main before the fix (run 32280913409, 2026-08-19): Plan: … 1 to change → merge_gate["music-curator"]: Modifications complete → live restrictions.apps still []. Every apply since 2026-08-12 "changed" this resource.

A second blocker this issue didn't see

music-curator's main ruleset requires integrity and docs-check / docs-check (since music-curator#9 closed on 2026-07-25). The fold commits onto the PR branch with GITHUB_TOKEN, and GITHUB_TOKEN pushes do not trigger workflow runs — so the required checks never report on the fold's commit and the PR cannot merge regardless of the allowlist. The NOTE at the top of follow-fold.yml predicted exactly this and still says "main currently has none". So even a working allowance would not have made the bot merge work.

What #169 does

• Removes the allowance (gate_extra_allowances = {}, kept as the extension point with the eligibility rule in its comment). Live state already lacks the actor, so the apply is a no-op at GitHub and the perpetual diff clears — real drift on merge_gate becomes visible again.
• Adds a post-apply convergence check to the apply job (terraform plan -detailed-exitcode, fail on exit 2). This would have turned 2026-08-12's first apply red instead of green-for-ten-days.
• Corrects the wrong root cause everywhere it was recorded: locals.tf, terraform/README.md (merge-gate section + adoption record), ADR-0003 (dated amendment), and the 2026-08-12 incident report (dated correction closing its open item 5).

Side-finding, outside this issue's scope

The n8n stack on LXC 113 was found stopped (n8n and redis containers Exited (0) ~2026-08-18, a clean stop with no recorded reason; osmunda's n8n manifests are still a pre-cutover draft). Producer, follow watcher, drain, and the 2026-09-01 monthly roll-up are all dark until it is back. Not restarted — noted in music-curator#87 as the precondition for any of this mattering.