ci: cli-tri red on master since #7320 -- the quiet census moved 167 -> 181 and was not re-blessed #9882

Re-filed from #7384. An attempt claimed that issue on 2026-10-07 and left an empty branch, and a dispatch row that has spent its retry ceiling keeps its issue for good - so no bee could take it again, however much the brief improved. The work below is carried over unchanged.

What is wrong

cli-tri on master has failed at the step "No census moved without saying so" since 33756b3 (#7320, merged 2026-10-07T07:07:50Z):

FAIL: quiet moved:
      was: named a path but not quiet    167   (--excluded prints them)
      now: named a path but not quiet    181   (--excluded prints them)

Master runs with this failure: 37587848858 (54603df), 37589145938 (d2b20bd), 37593133584 (f8ad9e7). The same failure is on every PR based on master since then (for example #7366, run 37594210788). cli-tri is not a required check, so it blocks no merge. That is also why nobody saw it.

Which commit

git bisect --first-parent from 899717f (last green cli-tri, 06:38Z) to 54603df, running tri census pin --gate at each step: the first bad commit is 33756b3. 33756b3da^1 prints PASS: no pinned census moved., and 33756b3 prints the failure above. The commit message does not mention the census.

tri census explain at 33756b3:

quiet    MOVED since blessed at 31ad9dfbf (tools/census/quiet.txt)
    named a path but not quiet 167->181 (--excluded prints them)
    a tracked path, present 10->12
    no path ANYWHERE in the step 9->7 cannot be checked -- NOT the same as absent
  which change moves it -- each changed file put back to 31ad9dfbf alone, the census run again:
    .github/workflows/auto-merge-ready-prs.yml   moves 3 line(s)
    specs/queen/merger_gate.t27   moves 8 line(s)
        a tracked path, ABSENT 2->0 <- guarding nothing right now
        gone: auto-merge-ready-prs.yml:152 specs/queen/merger_gate.t27 [FailureBranchPasses, subject named on the Step]
        gone: auto-merge-ready-prs.yml:230 specs/queen/merger_gate.t27 [FailureBranchPasses, subject named on the Step]

So the move is partly good news: the two steps that named a missing specs/queen/merger_gate.t27 now find it (ABSENT 2 -> 0). The 14 new "named a path but not quiet" lines come from the steps #7320 added to auto-merge-ready-prs.yml.

What to do

The lane that owns #7320 (the merger gate) reads the 14 new lines with tri census pin --gate and --excluded, decides whether each step should be quiet, then re-blesses tools/census/quiet.txt with tri census pin --bless in a commit that names the move (167 -> 181, present 10 -> 12, absent 2 -> 0, and why). I have not blessed it: the census belongs to that lane, and a bless from an unrelated PR is exactly the silent move this gate exists to catch.

Checks

• tri census pin --gate on master prints PASS: no pinned census moved.
• cli-tri on master is green at the step "No census moved without saying so".

Refs #7317, #7320.

Boundary

• specs/queen/merger_gate.t27
• .github/workflows/auto-merge-ready-prs.yml
• tools/census/quiet.txt

User Scenarios

• Given the cli-tri check runs on master, when the census gate evaluates tools/census/quiet.txt, then it must report PASS: no pinned census moved.

Requirements

• FR-001: The quiet census in tools/census/quiet.txt MUST be re-blessed to reflect the current counts (181 named but not quiet, 12 tracked present, 0 absent).
• FR-002: The re-bless commit MUST document the move (167→181, 10→12, 2→0) and the reason (steps added by merger: a bee's discount holds only on a completed master failure (Closes #7317) #7320 in auto-merge-ready-prs.yml).
• FR-003: After re-blessing, tri census pin --gate on master MUST print PASS: no pinned census moved.

Success Criteria

• tri census pin --gate on master prints PASS: no pinned census moved. (exit 0)
• cli-tri on master passes the step "No census moved without saying so" (exit 0)
• tools/census/quiet.txt contains the updated blessed counts (181, 12, 0)

The instruments

Every one of these reads and prints; none of them writes. Run them from the repository root, with <spec> replaced by the file in ## Boundary:

.t27 is not Rust and not Zig, and a bee fluent in either writes one by
accident. Measured 2026-09-20: a bee filled eight bodies in
specs/file/watcher.t27 with return Ok(());, Err(FileError::WatcherNotFound)
and for i in 0..watchers.length. The parse ratchet refused the whole file --
Unexpected token in expression: RParen, line 123 -- and a spec that does not
parse generates nothing, so every test it already carried stopped running.

At the top level the parser accepts exactly these eight forms, with an optional
pub, and no others:

const   var   fn   enum   struct   test   invariant   bench

There is no trait, no impl, no type X = ..., no generics, no macro. What
a bee reaches for from another language, and what happens:

• Rust's result sugar (Ok(()), Err(E::V), ?) is not a construct here.
• Rust macros (println!, format!, vec!) are not constructs here.
• A range loop (for i in 0..n) is Rust and Zig, not this language.
• Zig builtins (catch unreachable, @intCast, @constCast) are not constructs here.
• Cross-module reuse (use other::fn;) parses and then generates a comment and an unqualified call, so the Zig fails with use of undeclared identifier (use a::b; generates no import, so no spec can reuse a function from another spec #4298). It does not work yet.

t27c parse <spec> answers in one line whether what you wrote is the language.
Run it before you report, every time.

• t27c spec-status <spec> - the compiler's one-word verdict: IMPLEMENTED, PARTIAL, UNWRITTEN, NOPARSE, NOFN. Exit code is 0 whatever it says, so read the word.
• t27c symbols <spec> - every name the file declares, with its kind. Answers "does this already exist here?" before you add it.
• t27c outline <spec> - per function: its locals, what it calls, what it returns. The contract you are implementing against.
• t27c coverage <spec> - which functions have a test and which do not. The issue asks for tests; this is how you check you wrote them.
• t27c lint <spec> - style and shape warnings. It OVER-REPORTS has no test or invariant: measured 2026-09-20 over 60 specs it printed 677 of those where coverage found 190 untested functions, disagreeing on 59 of the 60 - it warns about bit_to_trit_pair in specs/base/ternary_encoding.t27, which test bit_to_trit_pair_zero calls on line 249. Read it as a hint; coverage is the answer.
• t27c typecheck <spec> - types, before generation. Prints Typecheck OK (0 errors, 0 warnings) or the errors.
• t27c test-report <spec> - builds this spec and runs its own tests, which is what the oracle does. BLOCKED means the generated Zig does not compile, with the error beside it.
• python3 tools/dupe_scan.py --name <function> - where that function already lives, if it does. 576 of 4021 bodies here are byte-identical copies.

The rest of the toolbelt is in docs/BEE_TOOLBELT.md.