O6 propagation: four contradictions between the ruling and the committed rulesets

[hyperpolymath]

What

Owner decision O6 (hyperpolymath/standards#787 row D17) is ruled and its
body is committed at config/rulesets/gates-only.json. But the ruling's intent
and what the committed artefacts actually encode disagree in four places, and the
applier is deliberately not the thing that decides them.

The four contradictions, each measured on origin/main

1. bypass_mode: pull_request vs always — the one config/README.adoc promises this issue for

gates-only.json's bypass list is RepositoryRole:5 plus Integrations
1236702 (claude), 29110 (dependabot), 15368 (github-actions) and
2538504 (oikosbot) — and every one is bypass_mode: pull_request, not always.

D17's elegance arm reads "the AI actors are held to the gates, not exempt."
bypass_mode: pull_request means those five actors can still merge a PR past a
failing required check. What the short list does buy is real — base.json's much
wider bypass set cannot — but it is not "held to the gates".

The question: should the four Integration entries be bypass_mode: never
(i.e. removed from the bypass list entirely), leaving only RepositoryRole:5?

2. base.json carries required_status_checks of its own

Bypass binds a whole ruleset, never a single rule. That is the entire reason O6
exists: a checks rule living inside a ruleset with a wide always bypass is a
fake gate. If base.json still carries a required_status_checks rule, the
estate ships exactly the shape O6 was ruled to eliminate — in the object O6 was
ruled to route around.

The question: should required_status_checks be stripped from base.json
now that the gates-only ruleset is the canonical home for it?

3. config/README.adoc's ruleset identification rule omitted source_type

Now fixed for the branch side (this issue's sibling PR). The old text —
"the active ruleset whose target is tag and whose include list is exactly
["~ALL"]. Exactly one must exist; zero or two is a verifier failure" — matches
org-level and repo-level rulesets alike, and an org-level ruleset is not
writable through the repo endpoint.

Measured 2026-09-23: metadatastician/paint-type and metadatastician/berrywiki
both reported the same org ruleset 18225024 (EstateBranching) as their
own under the unfiltered selector. One org object, claimed as two different
repositories' property.

The question: the tag side (apply-tag-ruleset-canon.sh) carries the same
omission from the same canon text and is not fixed by the branch-side PR. Should it
be fixed in the same shape, or is the tag side's ~ALL include list doing enough
discrimination in practice?

4. "ZERO is a verifier failure" is wrong post-O6

The canon text calls zero rulesets a verifier failure. After O6, zero repo-level
branch rulesets is the normal state of a healthy repo that has not yet been given a
gates ruleset — paint-type was exactly this. The branch-side README is corrected;
the tag-side text is not.

Acceptance criteria

• A ruling on (1) recorded on Owner decision sheet D1–D72: one answerable place for #637 + #715 + #709 + #658 and this week's unfiled decisions #787 as a new row, and gates-only.json's
  bypass_actors made to match it.
• A ruling on (2); if strip, base.json updated and every repo carrying the old
  shape re-converged by the applier, not by hand.
• (3) and (4) propagated to apply-tag-ruleset-canon.sh and to the tag-side
  passages of config/README.adoc, with the same two-sided mutation test the
  branch side now has (scripts/tests/branch-gates-apply-test.sh, mutants F–I).
• config/README.adoc's "filed as an issue" pointer updated to name this issue.

Not in scope

The mechanism — apply-branch-gates.sh's source_type filter, its shape
discriminator and its schema-surprise guard — is a separate, already-proven change.
This issue is policy only, per the owner's 2026-09-22 ruling: "do NOT override a
concurrent actor on POLICY — settle policy in standards then propagate."

🤖 Generated with Claude Code

https://claude.ai/code/session_01YSq3UodR3CjsuAK5yoTzHF