The 15 hollow MERGE_CRITICAL claims: 10 can be required today, 5 cannot #5410

Re-filed from #3169. An attempt claimed that issue on 2026-09-24 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.

The 15 hollow MERGE_CRITICAL claims split into two groups, and only one of them is a real choice

tri gates required has reported 19 claims, 15 of them hollow unchanged for this entire
session: check_pr_branch_filters.py marks 19 workflows MERGE_CRITICAL, the ruleset requires four
contexts, and 15 of the claims are not among them. The tool names why it persists:

A required check is named in repository SETTINGS. No file in the tree can read it, so a comment
claiming a gate blocks cannot go stale against anything — this is the only drift here with no
detector.

I have offered to prepare this decision three passes running without doing it. Here it is prepared.
The decision is the owner's; nothing below has been applied.

The 15 are not one group

That distinction is the whole difficulty and it had not been measured. A required context that
does not post is not "passed", it is pending forever, so making a paths-filtered check required
blocks every pull request that does not touch its paths.

Group A — safe to require today

Verified twice: the workflow declares pull_request: with no paths: filter, and the context
actually appeared on 7 of 7 recently merged pull requests.

Corpus ratchet (expected-failure ledger)      corpus-ratchet.yml
Damage negatives (false-positive fixtures)    damage-negatives.yml
Documented t27c subcommands exist             documented-commands.yml
No test binary shares one scratch directory   harness-scratch.yml
🔒 NotebookLM notebook required               notebook-gate.yml
phi-loop-check                                phi-loop-ci.yml
coverage                                      seal-coverage.yml
scan                                          secret-scan.yml
Verilog widths (absurd-width ledger)          verilog-widths.yml
withdrawn-live                                withdrawn-live-gate.yml

Adding these to the ruleset's required_status_checks makes ten claims true. It also makes them
blocking, which is the point and the cost: today a red one of these merges anyway.

Group B — cannot be required without more work

build-paper.yml          Build LaTeX PDF                        1 path pattern
catalog-count-gate.yml   count-invariant                        6 patterns
coq-kernel.yml           build                                  6 patterns
emit-bitexact-gate.yml   emit-bitexact                         20 patterns
fpga-build.yml           fpga-smoke, fpga-lint, fpga-synthesis 14 patterns

Three ways out, all of them changes rather than settings: drop the paths: filter and pay the CI
(#3134 prices a cycle at ~17.6 minutes); or add a cheap always-running job that posts the context
as a skip; or delete the claim, which is honest and free.

The other option, in full

Deleting all 15 from MERGE_CRITICAL in scripts/ci/check_pr_branch_filters.py costs nothing and
makes the file true immediately. It is not a lesser option: a comment that says a gate blocks,
over a gate that does not, is worse than no comment — it is the shape this repository has spent
the session finding, in the one place that legislates about it.

What I would do, and what I will not

I would require Group A — ten claims become true, ten gates start blocking, and the cost is
visible immediately. Then delete the five Group-B claims and reopen them one at a time as each
workflow earns an always-running context.

I will not do either: both are ruleset or policy changes. What is now done is the measurement that
turns one hard question into ten easy ones and five real ones.

Measured at origin/master 2b67acbc8, 2026-09-04. Group-A membership from tri gates required
plus the pull_request: trigger of each workflow, confirmed against the check lists of seven
merged pull requests.

Boundary

• scripts/ci/check_pr_branch_filters.py

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.