cli-tri: retire deleted-workflow test and refresh measured census pins #9634

Title: cli-tri is red on master: a unit test include_str!s the deleted brain-seal-refresh.yml, and the census pins moved

Summary

cargo build -p tri --all-targets exits 101 on master cd8a656 at cli/tri/src/gates.rs:9012:
couldn't read .github/workflows/brain-seal-refresh.yml. CI run 38758247650 (job 116502336619) shows the same on PR #9630. PRs #9622 and #9630 fail cli-tri for this reason.
The workflow was deleted in 9a092df (#9117); #3324 only removed its push step. Derived-record PRs are now opened by derived-records in .github/workflows/queen-publish.yml.

With that one test removed, the next CLI step fails: tri census pin --gate. The census ledgers were blessed at older workflow sets. tri census explain names the workflow files whose changes move them
(brain-seal-refresh.yml removed; issue-gate.yml, queen-publish.yml, t27o-golden.yml, t27o-release.yml, gate-topology.yml, spec-guards.yml changed). The new counts are the real current counts:
quiet: workflow files read 65 -> 66, named a path but not quiet 185 -> 198; shell: workflow files read 65 -> 66, jobs 85 -> 87, run steps 305 -> 313, runner shell 284 -> 292.

Two pieces, kept apart

1. The fix (this issue): three paths, 19 deletions in one Rust file plus the two census files.
2. The activation record of the owner's exception: PR policy: record approval for the 19-line gates test deletion (Refs #9634) #9639 (draft, Refs #9634, head c4ca0a9, one file tools/policy/foreign-exceptions.txt, 8 lines added, 0 Rust). It must land on master first, because the local hook and CI read the exception list from the base.
   This issue is closed only by the fix PR (Closes #9634), not by the activation record.

Boundary of the fix

Exactly these three paths and no others:

cli/tri/src/gates.rs
tools/census/quiet.txt
tools/census/shell.txt

gates.rs: deletion of the one test the_motivating_workflow_records_its_own_reason (19 lines deleted, 0 added; the five inline-string tests of the cause_removed mechanism stay). The census files: re-recorded by tri census pin --bless from the current tree, not edited by hand.

Owner permission (received) and what it covers

On 2026-10-15 the project owner gave this permission directly in a chat with the coordinator (English translation of the Russian original): "I allow the exception for deleting 19 lines of an obsolete test in gates.rs, without adding Rust."
It covers exactly 0 added and 19 deleted lines in cli/tri/src/gates.rs. It does not cover any other Rust, compiler.rs, FROZEN_HASH, a guard, or a weaker test, and it is not a standing permission for future edits.
Status of the permission versus the GitHub action: the owner's permission is received; the GitHub action is pending. The user account dmitrii-f-t27 has pull rights only on gHashTag/t27 (push, admin, maintain and triage are false). The label attempt on #9639 failed with exactly
GraphQL: dmitrii-f-t27 does not have the correct permissions to execute AddLabelsToLabelable (addLabelsToLabelable), so the label owner-approved-foreign and the merge of #9639 need @gHashTag. No approval by @gHashTag is claimed here, and the permission is not asked again.
The own-language check of #9639 is red until the label exists: https://github.com/gHashTag/t27/actions/runs/38772157615/job/116550480148.

Measured: why an exception on the same branch is not enough

Before the permission, the real hook was run: lefthook install, then only the 19 deletions of cli/tri/src/gates.rs staged, then lefthook run pre-commit --command own-language. Result: exit 1, DENY cli/tri/src/gates.rs
(log /tmp/t27-ci-cli-own-language.log); the index was returned to empty afterwards. lefthook.yml reads the exception list from origin/master in both hooks, and .github/workflows/own-language.yml reads it from the pull request's BASE.
So the order is fixed: (1) the data-only change that adds cli/tri/src/gates.rs to tools/policy/foreign-exceptions.txt, with the label, merged; (2) the 19-line deletion through the ordinary hooks. Or the owner applies the 19-line patch.
No --no-verify, no LEFTHOOK=0, no rewritten origin/master ref.

User Scenarios

Scenario 1: the tri crate builds with all targets

• Given the fix
• When cargo build -p tri --all-targets runs
• Then it exits 0.

Scenario 2: the crate tests pass

• Given the fix
• When cargo test -p tri -- --nocapture --test-threads=1 runs
• Then it exits 0 with no failure. Measured on a clean worktree of master with the three-path fix: 886 passed, 0 failed, 0 ignored, 3 of them runtime Lean skips because lake is absent (the skip-watch baseline of 3 holds, no new skip). That is not 886 unrestricted executed checks, and it is not CI.

Scenario 3: the census pins agree with the tree

• Given the re-recorded ledgers (tools/census/quiet.txt 2 lines changed, shell.txt 4, by tri census pin --bless)
• When tri census pin --gate runs
• Then it passes, and tri census explain reports fetches, quiet and shell unchanged.

Scenario 4: no regression is blessed

• Given the diff of tools/census
• When it is read
• Then every changed line is a count that equals the current workflow files; no count was lowered to hide a missing subject.

Scenario 5: the ordinary hook accepts the deletion once the base has the entry

• Given master contains the exception entry for cli/tri/src/gates.rs
• When the fix is committed and pushed with the ordinary hooks
• Then own-language and foreign-budget exit 0 (0 added, 19 deleted).

Requirements

• FR-001: The test the_motivating_workflow_records_its_own_reason MUST be deleted and nothing MUST be added to cli/tri/src/gates.rs.
• FR-002: The # tri:cause-removed mechanism (cause_removed, its marker and the print-site guard) MUST stay covered by the existing inline-string tests.
• FR-003: tools/census/quiet.txt and tools/census/shell.txt MUST be written only by tri census pin --bless from the real current tree, in the same commit as the deletion.
• FR-004: The fix MUST NOT restore .github/workflows/brain-seal-refresh.yml and MUST NOT touch tools/policy/foreign-exceptions.txt; the one entry for cli/tri/src/gates.rs is the separate data-only PR policy: record approval for the 19-line gates test deletion (Refs #9634) #9639, which MUST land on master first, carries a comment naming the owner permission, its date, this issue and its exact boundary, and is not a standing permission. The label waives the path check only, never the foreign-line budget.
• FR-005: The fix MUST NOT touch any other path, and MUST NOT use --no-verify or LEFTHOOK=0.
• FR-006: No pull request here MUST be described as green or merge-ready before CI on its last SHA is green and, for the data-only change, the label and merge by @gHashTag exist.
• FR-007: The fix MUST NOT be committed with --no-verify or LEFTHOOK=0; on the staged three-path fix the ordinary own-language hook currently exits 1 (DENY gates.rs, because the base has no entry yet) and foreign-budget exits 0. That is the expected bootstrapping state, not a reason to bypass.

Success Criteria

Run from the repository root.

• cargo build -p tri --all-targets exits 0.
• cargo test -p tri -- --nocapture --test-threads=1 exits 0.
• ./target/debug/tri census pin --gate exits 0.
• ./target/debug/tri census explain exits 0 and its quiet and shell sections print unchanged.
• git diff --name-only origin/master prints exactly the three paths of Boundary.
• git diff --numstat origin/master -- cli/tri/src/gates.rs shows 0 added and 19 deleted lines.
• After the base has the entry: lefthook run pre-commit --command own-language and lefthook run pre-commit --command foreign-budget exit 0 on the staged fix.

Dmitrii Fedorov (@dmitrii-f-t27)