* ci: run the gate before the deploy, not after it
master is the live branch — every app fetches its config from
raw.githubusercontent.com/.../master/... — and the flow was arranged so that content
reached it first and was checked afterwards.
auto-pr.yml fired on a push to *master* and opened a master → main PR. Code Quality ran
on that PR, i.e. on the way into the mirror, long after the config was already being
served. A check that reports "the live config is broken" is not a gate.
The same inversion made master unwritable by the front door: five required status
checks, and no workflow triggering on a PR into master, so the only way to change the
live branch was to bypass its own protection. That is not a hypothetical — it was
bypassed twice on 2026-08-10, and the second time was to undo the first.
Now: work lands on main, Code Quality decides, and promote-to-live moves master to the
exact commit that passed. It refuses anything that is not an ancestor of main, and uses
--force-with-lease so a master that moved underneath it is a failure rather than a
silent overwrite. main already ran Code Quality on push, so no trigger change is needed.
Also: each daily sync opened a PR and nothing closed the previous one. Thirty-one
branches spanning 2026-02-10 to 2026-08-08 were cleared by hand on 2026-08-11, every one
superseded by the next day's run. A sync is a snapshot of upstream, so an older open
sync PR is never the right thing to merge — it is noise that hides whether anything is
genuinely waiting. The sync now closes what it supersedes.
Branch protection still needs moving in the same direction and cannot be done from a
commit: main requires no PR, no approvals and no checks, while master carries the five
checks that can never run there. The settings change is proposed separately.
* ci: require an admin's approval before anything reaches the live branch
main is where work lands and where Code Quality decides; promote-to-live then moves
master to whatever passed, and every app reads master directly. An approval on main is
therefore the last human judgement before a change is served to wallets in the field —
and until now main required no review at all.
One approval, from either admin. Requiring two would mean two of two, which stalls
whenever one of them is the author.