tri gates preview asks four contexts; the ruleset requires validate, check-linked-issue and parse-ratchet #5725

tri gates preview (cli/tri/src/gates.rs, fn preview) prints "THE FOUR CONTEXTS THAT CAN BLOCK A MERGE, ASKED HERE" and asks check, check-now-freshness, validate and check-linked-issue.

Measured 2026-10-03. gh api repos/gHashTag/t27/rules/branches/master: the only active ruleset on master, t27-master-protection (id 14813367), requires exactly validate, check-linked-issue and parse-ratchet. Classic branch protection is off: gh api repos/gHashTag/t27/branches/master reports "protection": {"enabled": false} (the 404 from branches/master/protection proves nothing, since non-admins always get it). The ruleset's last edit is 2026-09-19 15:06 UTC, 21 seconds after #4277 merged the parse ratchet. On 2026-09-06 the required set was check, check-now-freshness, validate, check-linked-issue, which is the set the preview still asks.

Consequences on master 8fdf715:

• Two previewed rows (check, check-now-freshness) cannot block a merge, but a FAIL on either makes the preview exit 1 with "a required context would refuse this change". On a branch with no commits it does exactly that.
• parse-ratchet can block every merge and is not previewed at all.
• docs/BRANCH-PROTECTION.md lists five required workflows (PHI Loop CI, Seal Coverage, Schema Validation, Issue Gate, NOW Sync Gate); two of them post a required context. tri gates required reports 6 claims, 4 of them hollow, and parse-ratchet claimed by nothing. scripts/ci/check_pr_branch_filters.py lists spec-parse-ratchet.yml under NOT_MERGE_CRITICAL with the reason "not a required check".
• tri gates --help shows required's description against preview and none against required.

Wanted:

• the preview's set read from the ruleset, or from a committed ledger regenerated from it, not written into the command;
• a parse-ratchet row that runs that job's own steps (self-test, cargo build --release -p t27c, tools/ci/check_specs_still_parse.py);
• contexts the ruleset does not require printed as information, not as merge-blocking;
• a row that cannot run still reads UNAVAILABLE, never PASS;
• docs/BRANCH-PROTECTION.md matching the ruleset.

Open question for the owner, not decided here: whether check and check-now-freshness should be required again. That is a ruleset change only an admin can make.

Original file list

• cli/tri/src/gates.rs
• scripts/ci/check_pr_branch_filters.py
• tools/ci/check_specs_still_parse.py

Queen-runnable restatement (2026-10-05)

Part of this is done on master 13e212a: the check and check-now-freshness rows were removed from fn preview with the NOW gate (#5935, see cli/tri/src/gates.rs:5679). Still open: the required set is written into the command rather than read from a committed ledger, no row previews parse-ratchet (grep -c parse-ratchet cli/tri/src/gates.rs is 0), and docs/BRANCH-PROTECTION.md lists four workflows without naming the three required contexts. The Rust and Python files in the original list cannot be edited under the only-t27 rule; the t27 part is the committed ledger itself, as a spec the preview (and anyone) can read, plus the prose fix. Whether check and check-now-freshness become required again stays an admin ruleset decision and is not part of this.

Boundary

• specs/policy/required_contexts.t27
• docs/BRANCH-PROTECTION.md

User Scenarios & Testing

• Given master, where the set of contexts that can block a merge lives only in the ruleset (t27-master-protection, id 14813367: validate, check-linked-issue, parse-ratchet) and in hand-written code, when this lands, then specs/policy/required_contexts.t27 states those three names as the committed ledger, with a function is_required_context(name: str) -> bool whose tests return true for the three and false for check and check-now-freshness.
• Given docs/BRANCH-PROTECTION.md, when this lands, then its Required Status Checks section names parse-ratchet among the three required contexts and points to the spec as the ledger.

Requirements

• FR-001: The spec MUST declare the three required contexts and is_required_context, and a test per name plus negative tests for check and check-now-freshness; a comment MUST say the ledger is regenerated from gh api repos/gHashTag/t27/rules/branches/master when the ruleset changes.
• FR-002: docs/BRANCH-PROTECTION.md MUST match the ruleset (three required contexts, including parse-ratchet).
• FR-003: The change MUST NOT add or modify non-t27 hand-written code (specs/policy/own_language.t27): cli/tri/src/gates.rs and the Python checkers are not edited here.

Success Criteria

• grep -c 'parse-ratchet' specs/policy/required_contexts.t27 prints at least 1
• grep -cE '^\s*(pub )?fn is_required_context\(' specs/policy/required_contexts.t27 prints 1
• t27c test-report specs/policy/required_contexts.t27 | grep -cE '^ FAIL +0$' prints 1
• grep -c 'parse-ratchet' docs/BRANCH-PROTECTION.md prints at least 1