fix(tri): gates preview asks the contexts the ruleset requires, parse-ratchet among them (Closes #5725) - #5732
Open
dmitrii-f-t27 wants to merge 1 commit into
Open
dmitrii-f-t27 wants to merge 1 commit into
dmitrii-f-t27 wants to merge 1 commit into
Conversation
…-ratchet among them (Closes #5725) `tri gates preview` asked four contexts it called "the four that can block a merge": check, check-now-freshness, validate, check-linked-issue -- the ruleset of 2026-09-06. Since the ruleset's last edit (2026-09-19 15:06 UTC, 21 s after #4277 merged the parse ratchet) it requires validate, check-linked-issue and parse-ratchet. So two rows that cannot block a merge decided the exit code (an empty branch always exited 1), and the one new required context was never asked. - The set is read from the ruleset on every run (`required_contexts`), else from .github/required-contexts.txt, a ledger `tri gates required --write` regenerates only when the set changes. Both commands print drift. With neither readable the preview asks every reader and exits 1. - A required context with no reader prints UNAVAILABLE instead of being left out. A reader is used only when exactly its own workflow posts the context. - parse-ratchet runs its job's own steps, read out of spec-parse-ratchet.yml on every run: --self-test, `cargo build --release -p t27c` (the executable cargo reports), check_specs_still_parse.py over base..HEAD. validate does the same with its two steps, so it now runs its --self-check too. A job whose steps differ from its reader's reads UNAVAILABLE. - check and check-now-freshness print under "NOT REQUIRED BY THE RULESET" and no longer decide the exit code. - docs/BRANCH-PROTECTION.md states the ruleset as read; it listed five required workflows, two of which were. spec-parse-ratchet.yml joins MERGE_CRITICAL (its exclusion reason was "not a required check"). LOOP-RULES, verify.sh, the Makefile, the pre-push hook and two workflow headers point at the ledger instead of naming "the four required checks". - `tri gates --help` showed required's description on preview and unmeasured's on tests; each now sits on its own variant. Census: `fetches` moves gates.rs:3651 -> 3668 (fn unmeasured). A line shift from the doc comments added to GatesCmd above it; the population is unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
This was referenced Oct 3, 2026
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
This was referenced Oct 3, 2026
This was referenced Oct 3, 2026
Merged
This was referenced Oct 3, 2026
Merged
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #5725
tri gates previewasked four contexts it called "the four that can block a merge" (check,check-now-freshness,validate,check-linked-issue), which was the ruleset of 2026-09-06. The ruleset's last edit (2026-09-19 15:06 UTC, 21 s after #4277 merged the parse ratchet) leavesvalidate,check-linked-issueandparse-ratchet(gh api repos/gHashTag/t27/rules/branches/master; classic protection is off:branches/masterreportsprotection.enabled: false). So two rows that cannot block a merge decided the exit code (an empty branch always exited 1), andparse-ratchetwas never asked.What changes
required_contexts, the readertri gates requiredalready used). If it can't be read, the set comes from.github/required-contexts.txt, a ledger thattri gates required --writeregenerates (it writes only when the set changes, so the date never moves by itself). Both commands print drift between the ledger and the ruleset. If neither can be read, the preview says the set is unknown, asks every reader anyway, and exits 1.parse-ratchetruns its job's own steps. The steps are read out ofspec-parse-ratchet.ymlon every run:--self-test, thencargo build --release -p t27c(the checker gets the executable cargo reports, soCARGO_TARGET_DIRcan't hand it a stale binary), thencheck_specs_still_parse.pyover base..HEAD. Exit codes are the checker's: 0 PASS, 1 FAIL (the row names the specs), 2 UNAVAILABLE.validateworks the same way, so it now also runs the--self-checkit used to skip. If a job's steps differ from what its reader runs, the row reads UNAVAILABLE. This takes the idea behindthe_pattern_is_read_out_of_the_gate_that_enforces_itand applies it to whole jobs.checkandcheck-now-freshnessprint under "NOT REQUIRED BY THE RULESET" and no longer decide the exit code. The NOW-gate scratch control (test_now_gate_writes_nothing.py --tri) still sees the preview reach the NOW gate's pass.docs/BRANCH-PROTECTION.mdnow states the ruleset as read. It used to list five required workflows; two of them were.spec-parse-ratchet.ymlmoves intoMERGE_CRITICAL; it had been excluded with the reason "not a required check".tri gates requiredgoes from 6 claims / 4 hollow / 1 unclaimed to 5 / 2 / 0. The two left are the docs/now workflows thatMERGE_CRITICALstill lists (see below).tri gates --helpshowedrequired's description againstpreviewandunmeasured's againsttests; each now sits on its own variant.fetchesmovesgates.rs:3651 -> 3668(fn unmeasured), re-blessed in the same commit. This is a line shift from the doc comments added above it; the population is unchanged.Verified locally
cargo build -p tri --all-targets(no new warnings);cargo test -p tri: 834 passed, 0 failed (13 ingates::preview_tests, 10 of them new).specs/tools/tri/gates.t27givesFAIL parse-ratchet ... specs/tools/tri/gates.t27and exit 1;validatejob each give UNAVAILABLE with the reason;tri skill check,tri census pin --gate,tri gates tests --gate,check_pr_branch_filters.py(and--self-test),test_now_gate_writes_nothing.py --tri,check_now_entry_shape.py,check_fix_carries_source.py: all pass. The shared.git/confighash is unchanged across runs.Not decided here
Whether
checkandcheck-now-freshnessshould be required again is the owner's call. Only an admin can edit the ruleset. Until that's decided they stay inMERGE_CRITICAL, so their pull_request trigger stays unfiltered, andtri gates requiredreports them as claimed but not required.🤖 Generated with Claude Code