policy: estate settings standard — merge opts, protection, required-checks = 🔴 Gate set (WS4)

[hyperpolymath]

Goal

Define the canonical GitHub settings every repo should converge to, and realign the stale required-check contexts that deadlock PRs estate-wide.

Do

• Specify: merge-button options, branch-protection shape, feature toggles, and the required status checks = the 🔴 Gate tier (see CI-CRITICALITY promotion issue).
• Realign stale required contexts: the governance / * group is stale on ~190 repos (renamed/regrouped → context no longer matches emitted name). Define the rename mapping.
• Confirm true deadlocks via the farm ci-deadlock-audit union signal before writes. Branch-protection writes are owner-gated.

Context

WS2 audit: 336/373 protected, 234 with required checks, 102 toothless. Report in dev-notes/estate-settings-audit-2026-06-22/. Execution/automation tracked in reposystem.

[hyperpolymath]

Re-verified 2026-08-26 — the numbers are wrong and the stated root cause is false

Full census of 420 repos (hyperpolymath 384 + metadatastician 36), not a sample.

claim in this thread	measured today
336 / 373 protected	390 protected, 30 unprotected
234 with required checks	157
102 "toothless"	233
governance / * stale on ~190	context present on 85; not emitted on 39

Why the original figures were probably wrong

Classic branch protection exists on exactly 1 repo out of 420. The estate is entirely ruleset-driven. Any audit reading /repos/{r}/branches/{b}/protection sees essentially nothing — which is the most likely source of the original counts.

⚠️ Two tool-reach traps worth recording, either of which produces a confident wrong answer here:

• gh api prints 404 bodies to stdout, so a naive 2>/dev/null census scores every repo as "protected".
• /commits/HEAD/check-runs caps at 100 per page — without --paginate it manufactures false "stale context" hits.

The root cause in this issue does not hold

This issue attributes the problem to "renamed/regrouped → context no longer matches the emitted name". The job name never changed. standards/.github/workflows/governance-reusable.yml still declares name: Validate Hypatia Baseline, both at main and at the SHA callers pin (d5fe075a).

Of the 36 hyperpolymath repos not emitting it: 27 are startup_failure, 8 failure, 1 success. They do not emit the context because the workflow never starts — that is the allowlist / actions: read programme (see #399), not a naming problem.

Exactly one genuine context-name defect exists estate-wide: affinescript requires governance / Validate Hypatia **b**aseline (lowercase b) against an emitted capital B.

So the "define the rename mapping" deliverable is a one-repo case fix. The other 38 belong to the startup_failure programme.

Inferred, not measured: the 8 failure repos ran on current HEAD yet produced no governance / * check-run, consistent with the reusable being rejected before job creation — I did not read those logs.

What remains genuinely yours

One sentence: approve the canonical merge-options / branch-protection shape, and name which check tier is required. That is still a real decision — it is simply decoupled from the false ~190 premise.

Not checked: non-default branches; org-level rulesets applying above the repo; whether the 233 toothless repos should be toothless.