chore(renovate): automerge GitHub Action digest re-pins, and only those (#62) (#65)

A digest re-pin moves a SHA and the `# vX.Y.Z` comment beside it, together, and
there is nothing else in the diff to read. It also recurs forever. Reviewing it by
hand teaches nobody anything and trains the habit of skimming bot PRs, which is
worse than automating the boring case. Renovate has one queued already.

**Why this is safe now and was not this morning.** Ruleset `EJ` makes `verify` a
required check on `main` with no bypass actors AND
`strict_required_status_checks_policy: true`, so an automerged PR can neither land
red nor land having been tested against a different `main` than the one it merges
into. Both had to be true. The strict flip arrived last (#60) and was the actual
blocker - it is the specific objection recorded against doing this earlier.

The rule is therefore NOT independently safe, and both the config and CLAUDE.md now
say so: if bypass actors are added, `verify` dropped, or strict turned off, this
rule must be removed in the same change.

`platformAutomerge` hands the merge to GitHub's auto-merge so the required check
gates it, rather than Renovate polling and merging itself.

Everything else stays manual under the global `automerge: false`. The reason is on
the record rather than a preference: `verify` proves the repo is CONSISTENT, not
that a bump is CORRECT. pako 3.0.0 flipped `legacyHash` to false, which passes a
green suite while silently breaking the codec's byte-exactness, and the wrong
belief that produced survived about a year.

Also corrects CLAUDE.md, which still said branch protection was not configured, and
records that it is a RULESET - `gh api .../branches/main/protection` returns 404 for
a protected branch here, which reads like "unprotected" and is not.


Claude-Session: https://claude.ai/code/session_01F3a2HLJ4beKARi7SPmaM54

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: wormeyman

.github/renovate.json5

@@ -100,6 +100,42 @@
 
   packageRules: [
     {
+      // The ONE automerge exception (#62), and it is narrow on purpose.
+      //
+      // Why this category and nothing else: a digest re-pin moves a SHA and the
+      // `# vX.Y.Z` comment beside it, together, and there is nothing else in the
+      // diff to read. It also recurs forever. Reviewing it by hand teaches
+      // nobody anything and trains the habit of skimming bot PRs, which is worse
+      // than automating the boring case.
+      //
+      // Why it is safe NOW and was not on 2026-07-30 morning: ruleset `EJ` makes
+      // `verify` a required check on `main` with `bypass_actors: []` AND
+      // `strict_required_status_checks_policy: true`. So an automerged PR cannot
+      // land red, and cannot land having been tested against a different `main`
+      // than the one it merges into. Both of those had to be true; the second
+      // arrived last and was the actual blocker.
+      //
+      // `platformAutomerge` hands the merge to GitHub's own auto-merge so the
+      // required check gates it, rather than Renovate polling and merging itself.
+      //
+      // If branch protection is ever loosened - bypass actors added, `verify`
+      // dropped, strict turned off - THIS RULE MUST GO WITH IT. It is not
+      // independently safe.
+      matchManagers: ["github-actions"],
+      matchUpdateTypes: ["digest", "pin", "pinDigest"],
+      automerge: true,
+      automergeType: "pr",
+      platformAutomerge: true,
+    },
+    {
+      // Everything below stays manual, and the global `automerge: false` above is
+      // the default for anything not named here. The load-bearing reason is that
+      // `pnpm run verify` proves the repo is CONSISTENT, not that a bump is
+      // CORRECT - and this repo has the counterexample on record: pako 3.0.0
+      // flipped `legacyHash` to false, which passes a green suite while silently
+      // breaking the codec's byte-exactness, and the resulting wrong belief
+      // survived about a year. Version bumps of real dependencies get read.
+      //
       // THE ONE THAT MATTERS MOST. Without it a bot proposes 6.0.3 -> 7.x every
       // single week and someone re-derives the refusal every time (see #48, #52).
       // TypeScript 7 exposes no programmatic API yet, the official migration is

CLAUDE.md

@@ -257,8 +257,36 @@ Two settings whose reasoning is not guessable from the outside:
   whole section exists to prevent. 25 hours clears pnpm and still drops the wait
   from 3 days to ~1.
 
-Branch protection on `main` is **not** configured. It is the natural follow-up
-now that a check exists, but it is a repository setting rather than a file.
+### Branch protection is a **ruleset**, and one Renovate rule depends on it
+
+`main` is protected by a repository ruleset named **`EJ`** (2026-07-30, issue
+#60), not by classic branch protection. Read it with
+`gh api repos/wormeyman/FactorioMapWebUI/rules/branches/main` - the classic
+`/branches/main/protection` endpoint returns **404**, which looks exactly like
+"unprotected" and is not.
+
+| rule                           |                                      |
+| ------------------------------ | ------------------------------------ |
+| `pull_request`                 | `required_approving_review_count: 0` |
+| `required_status_checks`       | `verify`, `strict: true`             |
+| `deletion`, `non_fast_forward` | blocked                              |
+| `bypass_actors`                | **empty** - binds the owner too      |
+
+Two things here are load-bearing and easy to break by "tidying":
+
+- **The review count is 0 on purpose.** GitHub does not let you approve your own
+  PR, so `1` would make `main` unmergeable by its only maintainer - a lockout
+  that looks like correct hardening until the first PR.
+- **`strict: true` is what makes the Renovate automerge rule safe.** With strict
+  checks a PR cannot merge having passed against a different `main` than the one
+  it lands on. `.github/renovate.json5` automerges GitHub **Action digest
+  re-pins** and only those; if bypass actors are ever added, `verify` dropped, or
+  strict turned off, **that rule must be removed in the same change.** It is not
+  independently safe, and the config says so at the rule.
+
+Everything else stays `automerge: false`, because `verify` proves the repo is
+consistent, not that a bump is correct - see the pako table above for the year-long
+wrong belief that a green suite endorsed.
 
 #### `testTimeout` is 30s, deliberately, and retries are not used