tri t27o-sweep: t27o coverage over a tree, rows reused by the seal hashes of the converter (warm run in seconds) #10543

Goal

A tri command that measures t27o over a whole tree in seconds on a re-run: tri t27o-sweep <paths...> converts every tracked .rs file in-process, prints one line per file and the totals, ranks first-refusal kinds, and reuses every file's recorded result whose key still holds -- the key being the file's SHA-256 and the seal hashes of rust_convert.t27 and rust_std.t27, so a converter change makes every row stale by itself, without a version constant someone must remember to bump. Part of #10522. Owner, 2026-10-18 (translated): "update tri cli with new commands to speed up the work", "use t27b, t27c seal to speed up".

Why this matters

The dogfood of #10527 took about 25 minutes through a shell loop with perl alarm caps, and every loop tick needs the same numbers again after a converter change. Most files do not change between ticks; only the converter does.

Source of truth

• specs/tools/t27o/ledger.t27: key_state already says when a recorded verdict is stale (source digest, converter, std table). The sweep's rules go here: the key from the two seal hashes, fresh or stale, the totals and the coverage share, the root vs cascade split of refusals, the ranking.
• specs/tools/t27o/rust_convert.t27: the counters the converter already keeps in its state vector (NFN, NOK, NTS, NTEST, NSTUB); the glue reads them instead of parsing text.

Deliverable

• Rules in ledger.t27 with tests and a negative control (a stale key must never be reused).
• cli/tri/src/main.rs glue within the 40-line cap: git ls-files, read, t27o::convert, the cache file (default target/t27o-sweep.tsv), the print. A --max-bytes cap that reports skipped files instead of hanging on compiler.rs.
• Regenerated gen/rust/tools/t27o/ledger.rs, re-saved seal.

Done when

• A cold run over this repository's .rs files prints the same per-file counts as tri t27o <file> for every file it converts.
• A warm run with no change reuses every row and takes under 10 % of the cold run; touching one file re-converts only that file; re-sealing rust_convert.t27 makes every row stale.

How to verify

./target/release/tri t27o-sweep . --max-bytes 300000
./target/release/tri t27o-sweep . --max-bytes 300000   # second run: all rows reused
./target/release/t27b test specs/tools/t27o/ledger.t27

Boundary

• May touch: specs/tools/t27o/ledger.t27, gen/rust/tools/t27o/ledger.rs (regenerated), .trinity/seals/t27o_T27oLedger.json, cli/tri/src/main.rs (a new T27oSweep variant, its dispatch line and its fn).
• Must not touch: cmd_t27o and the T27o variant (analog M2a: SPICE front end for t27o -- parse, flatten and inventory an ngspice netlist, or refuse with the line #10509, t27o: --check judges with t27b test first (0.89 s vs 94 s), t27c test-report only when t27b cannot judge #10525), rust_convert.t27 (one lane at a time; t27o: five refusal classes from the roadmap dogfood -- Ok/Err in test asserts, for over &[..], &[] arguments, raw strings, string line continuations #10526 holds it).
• Starts after PR t27o --check: t27b test judges first, t27c test-report only when t27b cannot (Closes #10525) #10538 merges (both edit ledger.t27).

Risks

The in-process converter has no time cap; --max-bytes stands in until the superlinear pass is fixed.

Links

#10522, #10525, #10527, #10486.

User Scenarios

• Given a repository with tracked .rs files and a cold cache, when the user runs tri t27o-sweep . --max-bytes 300000, then every file is converted in-process, one line per file is printed with its counts, totals and a ranked refusal summary appear at the end, and the run completes in N seconds.
• Given the same repository and an unchanged cache from the previous run, when the user runs tri t27o-sweep . --max-bytes 300000 a second time, then every row is reused from the cache, the per-file counts match the cold run exactly, and the warm run finishes in under 10 % of the cold-run time.
• Given a warm cache and a re-sealed rust_convert.t27, when the user runs tri t27o-sweep . --max-bytes 300000, then every row is stale because the converter seal hash changed, all files are re-converted, and the new per-file counts reflect the updated converter.

Requirements

• FR-001: The tri CLI MUST accept a t27o-sweep <paths...> subcommand with a --max-bytes <N> option that skips files larger than N bytes and reports them as skipped.
• FR-002: The sweep MUST enumerate tracked .rs files via git ls-files, read each file, invoke the in-process t27o::convert, and collect the counters NFN, NOK, NTS, NTEST, NSTUB from the converter state vector.
• FR-003: The cache key for a file MUST be the tuple of the file's SHA-256 digest, the seal hash of rust_convert.t27, and the seal hash of rust_std.t27; a recorded row MUST be reused only when all three components match.
• FR-004: The ledger rules in specs/tools/t27o/ledger.t27 MUST define key_state to classify a row as fresh or stale, compute per-file coverage share, split refusals into root vs cascade, and rank first-refusal kinds.
• FR-005: The cache file MUST default to target/t27o-sweep.tsv and store one row per file with the key components, the counters, and the refusal breakdown.
• FR-006: The sweep MUST print one TSV line per file (including skipped files), then a totals line, then a ranked list of first-refusal kinds with counts.
• FR-007: A negative test in ledger.t27 MUST assert that a stale key is never reused.
• FR-008: The generated gen/rust/tools/t27o/ledger.rs and the seal .trinity/seals/t27o_T27oLedger.json MUST be regenerated after the spec changes.
• FR-009: The implementation in cli/tri/src/main.rs MUST stay within the 40-line cap for the new T27oSweep variant, its dispatch line, and its handler function.