Harden the main ruleset: no pull-request requirement, non-strict status checks, and a duplicate ruleset

[wormeyman]

Branch protection went live on main on 2026-07-30, as repository rulesets rather than classic branch protection (the classic /branches/main/protection endpoint 404s - worth knowing, because that 404 reads like "unprotected" and is not).

Current state, read from the API rather than the UI:

Ruleset EJ (id 20021316, enforcement: active, targets ~DEFAULT_BRANCH):

• deletion
• non_fast_forward
• required_status_checks: context verify (integration 15368 = GitHub Actions), strict_required_status_checks_policy: false
• bypass_actors: [] - nobody can override, including the owner. That is the right call and should stay.

Ruleset EJNOFORCE (id 19839107, enforcement: active, same target): deletion + non_fast_forward only.

This already does the main job: #55 and #57 were correctly blocked as soon as it turned on, because their branches predate .github/workflows/verify.yml and therefore had no verify run at all. Three follow-ups, in descending order of how much they matter.

1. There is no "require a pull request" rule

EJ requires the verify check but does not require changes to arrive via a pull request. A direct push to main is not structurally forbidden.

Whether that matters depends on intent. The required check makes a direct push awkward but the repo's own history says the risk is real: a commit meant for a feature branch has landed on main here before (see the note in CLAUDE.md about verifying git branch --show-current in the same command as a commit). If PR-only is the intent, add a pull_request rule. If direct pushes for docs-only fixes are wanted, leave it and this can be closed as deliberate.

2. strict_required_status_checks_policy is false

So a branch does not have to be up to date with main to merge. A PR can pass verify against an older main and land on a main it was never tested against.

That is not hypothetical here - it happened twice this week in the same afternoon:

• ci: the repo's first .github/ - a verify workflow plus Renovate with the holds encoded #56 changed vite.config.ts (testTimeout) and CLAUDE.md
• chore(types): close the .vue type-check gap - adopt vue-tsc in verify #52 changed what verify itself means, adding a check:vue phase (verify is now vp check && pnpm run check:vue && vp test && pnpm run preview:test)

A PR whose green check predates either of those was measured against a different gate.

Leaving it false is defensible while several PRs are open, since true forces every branch to rebase and re-run before it can merge. But it should be a decision, not a default. Suggestion: flip it to true once the current queue (#55, #57) is drained, when the cost is near zero.

3. EJNOFORCE is fully subsumed by EJ

Both are active, both target the default branch, and EJNOFORCE's two rules (deletion, non_fast_forward) are both already in EJ. Two overlapping active rulesets is a state where a future edit to one looks effective and is not. Fold it in and delete it, or rename it to say what it is for.

Why this is worth writing down rather than just doing

The prerequisite relationship runs the other way from how it looks: narrow automerge is only safe because this ruleset exists (see the separate issue), so weakening any of it later silently weakens that too.

[wormeyman]

All three items are done. Final state, read back from GET /repos/wormeyman/FactorioMapWebUI/rules/branches/main (the effective-rules view, not the ruleset definition):

deletion
non_fast_forward
required_status_checks   strict: true   checks: [verify]
pull_request             required_approving_review_count: 0

One ruleset, EJ, enforcement: active, bypass_actors: [].

1. Pull request now required

Added a pull_request rule, so changes reach main only through a PR. Direct pushes are blocked for everyone, owner included.

required_approving_review_count is deliberately 0, and that is load-bearing on a solo repo. GitHub does not let you approve your own pull request, so a count of 1 here would have made main unmergeable by its only maintainer - a self-inflicted lockout that looks exactly like correct hardening until the first PR. allowed_merge_methods is left at all three (squash, merge, rebase).

The rule still does the thing worth having: no accidental direct commit. This repo has had a commit land on main that was meant for a feature branch, which is why the note about checking git branch --show-current in the same command as a commit exists in CLAUDE.md.

2. strict_required_status_checks_policy flipped to true

A branch must now be up to date with main before it can merge, so a PR can no longer pass verify against an older tree than the one it lands on. Done while the queue was empty, so the cost was zero - with open PRs it would have forced every one of them to rebase and re-run.

This closes the gap the issue described concretely rather than hypothetically: on 2026-07-30, #56 changed vite.config.ts and #52 changed what verify itself means by adding a check:vue phase, both inside an hour. Under the old setting a check that passed before either could still merge after both.

Two live consequences, both mild:

• Renovate PRs will need updating when main moves under them. Its rebaseWhen default handles that automatically.
• It strengthens the case in Now that verify is a required check, allow automerge for GitHub Action digest re-pins only #62 (automerge for Action digest re-pins), since "the PR was tested against a different main" was the specific objection that made me say "not yet" there.

3. EJNOFORCE deleted

Verified containment before removing rather than trusting the earlier read: identical target, identical ref_name conditions (~DEFAULT_BRANCH), both with empty bypass_actors, and EJ's rules a strict superset (deletion, non_fast_forward both present). Its full JSON was backed up first so it can be recreated verbatim if that judgement turns out wrong.

Not tested, and worth being honest about

I confirmed the configuration via the API, not the enforcement. Proving the block would mean attempting a real direct push to main, which is not worth the mess for a rule GitHub's own semantics make unambiguous. The first PR after this will demonstrate the pull_request and strict-check rules in passing; a direct push would only ever be attempted by accident, which is the case the rule exists for.