What
master has no branch protection at all. Verified: gh api repos/ProxyPrints/ProxyPrints.github.io/branches/master/protection returns 404.
Two independent arguments for enabling it emerged on 2026-07-29, from two unrelated incidents.
Argument (a): make the migration-leaf guard a required check
PR #611 landed a guard that fails CI on a migration graph that forks as merged — i.e. a fork that is invisible on each PR in isolation and only exists in the combination. Without branch protection, that guard is advisory: a red run does not block a merge, and the merge poll's question text does not show check status.
Current live example of why it matters: master's migration leaf is 0099. Allocation is 0100 → #604, 0101 → #615, 0102 → the #614 recovery. #615's migration dependency is currently wrong (0098) and must be repointed to 0100 on rebase or the graph forks. #611's guard is exactly the thing that would catch that — if it could block.
Argument (b): "require branches to be up to date" is the only thing that forces a re-run when the base moves
This is the stronger argument, because nothing else in the workflow does it.
A green check on a stale base is worse than no check: it is a false statement that someone acts on. "Require branches to be up to date before merging" is the single setting that converts CI from a claim about a past tree into a claim about the tree being merged.
The trade-off (already analysed)
docs/infrastructure.md records the counter-argument: this is a solo workflow, and branch protection changes it. Required checks mean waiting for CI on every change including trivial docs edits; "up to date" means a rebase whenever anything else lands first, which in a day with 14 merges is a lot of rebases.
That trade-off is real and the decision is the owner's. What has changed is that both failure modes it prevents actually happened, on the same day.
DECISION NEEDED (owner)
Enable branch protection on master? If yes, at minimum:
A narrower option: (2) only, no required checks. That fixes the stale-green problem, which is the one that bit twice, at the lowest workflow cost.
What would close it
The setting applied (or explicitly declined, recorded in docs/infrastructure.md with today's two incidents cited as considered-and-accepted risk).
Refs
What
masterhas no branch protection at all. Verified:gh api repos/ProxyPrints/ProxyPrints.github.io/branches/master/protectionreturns 404.Two independent arguments for enabling it emerged on 2026-07-29, from two unrelated incidents.
Argument (a): make the migration-leaf guard a required check
PR #611 landed a guard that fails CI on a migration graph that forks as merged — i.e. a fork that is invisible on each PR in isolation and only exists in the combination. Without branch protection, that guard is advisory: a red run does not block a merge, and the merge poll's question text does not show check status.
Current live example of why it matters: master's migration leaf is 0099. Allocation is 0100 → #604, 0101 → #615, 0102 → the #614 recovery. #615's migration dependency is currently wrong (0098) and must be repointed to 0100 on rebase or the graph forks. #611's guard is exactly the thing that would catch that — if it could block.
Argument (b): "require branches to be up to date" is the only thing that forces a re-run when the base moves
This is the stronger argument, because nothing else in the workflow does it.
NodeNotFoundErrorfor migration 0099 on a run that predates 0099 landing. The failure is an artifact of staleness, and the green/red signal on that PR currently means nothing.A green check on a stale base is worse than no check: it is a false statement that someone acts on. "Require branches to be up to date before merging" is the single setting that converts CI from a claim about a past tree into a claim about the tree being merged.
The trade-off (already analysed)
docs/infrastructure.mdrecords the counter-argument: this is a solo workflow, and branch protection changes it. Required checks mean waiting for CI on every change including trivial docs edits; "up to date" means a rebase whenever anything else lands first, which in a day with 14 merges is a lot of rebases.That trade-off is real and the decision is the owner's. What has changed is that both failure modes it prevents actually happened, on the same day.
DECISION NEEDED (owner)
Enable branch protection on
master? If yes, at minimum:A narrower option: (2) only, no required checks. That fixes the stale-green problem, which is the one that bit twice, at the lowest workflow cost.
What would close it
The setting applied (or explicitly declined, recorded in
docs/infrastructure.mdwith today's two incidents cited as considered-and-accepted risk).Refs
docs/infrastructure.md.