Register publication-gate / gitleaks / history-check as required status checks on main (branch protection)

[shojikumaru]

Why

GLM + Opus seats on PR #29 (convergent MAJOR): main has no branch protection (gh api .../branches/main/protection → 404), so the adopted gates can go red without blocking a merge. Template README's own contract: required 登録で初めて「保護済み」。

Done when

• Branch protection (or ruleset) on main requiring: publication-gate / gitleaks / history-check
• Family merge flow (local merge + push by caty2) verified against the protection — fma#155 の確立フロー（staging→同一SHA 受理）を先例として適用
• 実機3観測（拒否/赤=failure/同一SHA 受理）を本 Issue に記録

順序・依存

Owner/admin 専決（設定は PR にできない）。#22 マージ後いつでも。

---

Campaign adjacency: family-os#56 B5/B9 follow-up. Origin: PR #29 review ledger on #22.

🤖 Generated with Claude Code

[shojikumaru]

Measured 2026-08-21 — item 1 is done; items 2 and 3 are not. Staying open, with the gap named exactly.

The premise that opened this issue (branches/main/protection → 404) no longer holds.

$ gh api repos/caty-ai/.github/branches/main/protection \
    --jq '{checks: [.required_status_checks.checks[].context], enforce_admins: .enforce_admins.enabled, strict: .required_status_checks.strict}'
{"checks":["gitleaks / gitleaks","history-check / history-check","publication-gate"],
 "enforce_admins":false,"strict":false}

Done when ① — branch protection requiring publication-gate / gitleaks / history-check: PASS.
All three, exactly as specified, no more and no less.

Done when ② — family merge flow verified against the protection: NOT RECORDED.
Done when ③ — 実機3観測 (拒否 / 赤=failure / 同一SHA 受理): NOT RECORDED.

These two are the reason this issue stays open, and I want to be precise about why rather
than close on the strength of ①.

One data point exists but was never written down here: PR #34 was merged locally and pushed
as ab74c98, and that push carried 1 of the 3 required contexts at the moment it
landed. That is a partial observation of "同一SHA 受理", and it lands that way because
enforce_admins: false — the admin push is not evaluated against the required contexts at
all. So what #34 demonstrates is not "the protection accepted a green SHA"; it is "the
protection was not consulted". Recording it as the ③ observation would be recording the
wrong thing.

The remaining two observations — a 拒否 and a 赤=failure — both require deliberately
pushing a state that should be refused, on a public org repository whose profile README is
the org's front door. That is a live experiment, not a measurement, so I am not running it
unannounced. Options, cheapest first:

1. Observe them on the next real PR that happens to go red, rather than manufacturing
   one. Costs nothing, but the timing is not ours.
2. Run them on a throwaway branch with a PR that is never merged — a red check on a PR
   branch exercises the gate without touching main.
3. Manufacture them on main — not recommended.

Related, and deliberately not folded in here: enforce_admins: false is not a
configuration gap. It is the foundation of the current merge procedure — every required
workflow is pull_request-triggered, so a locally-made merge commit carries none of the
required contexts at push time. Turning it on stops merges in all eleven repositories.
The owner ruled on this in family-dev-handbook#119 and closed it.