t27b-native ratchet is red on every master run since it landed: ledger 099ac2224 predates 16 improvements and 40+ new specs #9600

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

Problem

t27b-native-ratchet (.github/workflows/t27b-native.yml, landed in #6846 at 31ad9df) has been red on master on every run since it landed, and so it is red on every PR. The ledger docs/reports/t27b_expectations.json was last blessed at 099ac22 (#6646), before the workflow existed.

UNEXPECTED FAILURE is 0 on all three: nothing regressed. The red is two kinds of good news nobody recorded:

• 16 UNEXPECTED PASS: pass_vacuous in the ledger, a real pass now (14 specs/crons/*, specs/isa/ternary_encoding.t27, specs/tools/trinity/tri/wallet.t27).
• 40-42 UNLISTED: specs the reference passes and the ledger does not name (specs/verified/*, specs/isa/t27a*.t27, specs/port/*, specs/queen/actors.t27, specs/queen/control.t27, specs/tri/t27b/{fuzz,fuzz_oracle,reduce}.t27, ...).

The UNLISTED count grows by one with every merged PR that adds a spec (40 -> 41 -> 42 above). PR #7001's run 37506279886 at dbf97e9 has exactly master's 58 findings (set difference empty both ways), so it adds nothing. The check is not a required context, so it blocks no merge, but a check that is red on every head reads as noise and stops being looked at.

Proposal

1. Bless the ledger on master from a master run (tri t27b ratchet --run <master run.json> --bless), in its own PR under this epic's lane, with the run ID in the body.
2. Decide how a spec-adding PR stays green, so UNLISTED does not grow again. Either the PR adds its own ledger row (and the check says so in its failure text), or an UNLISTED path that the head itself adds is reported as a notice instead of red.

Acceptance criteria

• t27b-native-ratchet is green on a master run after the bless.
• A PR that adds one new reference-passing spec and nothing else gets a defined result (green, or red with the exact ledger line to add), written down in the ratchet's help text.

Refs #6063

Boundary

• specs/isa/ternary_encoding.t27
• specs/queen/actors.t27
• specs/queen/control.t27
• specs/tools/trinity/tri/wallet.t27
• .github/workflows/t27b-native.yml

User Scenarios

• Given the t27b-native-ratchet workflow has been red on every master run since landing, When the ledger docs/reports/t27b_expectations.json is blessed from a clean master run, Then the workflow reports green on the subsequent master run.
• Given a contributor opens a PR that adds exactly one new spec under specs/ which passes the reference implementation, When the ratchet runs on that PR, Then the check result is defined: either green, or red with the exact ledger line the PR must add to become green.

Requirements

FR-001: The ledger docs/reports/t27b_expectations.json MUST be updated via tri t27b ratchet --run <master-run.json> --bless from a passing master run so that all 16 UNEXPECTED PASS entries become expected passes and all 40-42 UNLISTED entries become listed.
FR-002: The ratchet tool MUST classify a newly added spec that passes the reference implementation as a notice (not a failure) when the spec path is introduced by the same PR, or MUST emit the exact ledger line the PR must add to make the check green.
FR-003: The workflow .github/workflows/t27b-native.yml MUST run the updated ratchet logic and exit 0 on master after the bless PR merges.
FR-004: The ratchet's help text (or failure output) MUST document the defined result for a spec-adding PR so contributors know whether to add a ledger row or expect green.

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.