spec-guards: ring-096-rust disagrees with specs/numeric/formats.t27 on 5 signatures (f32/gf16 vs f64) #7776

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

spec-guards step "Does every ring still agree with the spec it names" (tools/check_ring_spec_drift.py) is red on master. One pair causes it:

DRIFTED      ring-096-rust      specs/numeric/formats.t27
             hand fns 7, spec fns 6, shared 6, differing 5
               differs: f32_to_gf16
               differs: f32_to_ternary
               differs: gf16_to_f32
               differs: quantize_value
               differs: ternary_to_f32

This is old, not new. Master never reached this step while the seal step was red. #5737 made the seal step green, and that exposed it. I reproduced it on a clean master (146321c) with rc 1, and in run 37115950307. #5497 lists it as one row of a larger table: "A numeric-type decision". This issue is that row on its own.

Where they disagree

The spec's own return types do not agree with each other either. For example, gf16_to_f32 returns gf16, not f32.

Decision needed

Which side is the source of truth?

• (a) The spec. Fix the return types in formats.t27 that are clearly wrong (gf16_to_f32 -> f32, etc.), then bring the ring in line with the spec's f32.
• (b) The ring. The f64 signatures are the intended contract. Rewrite the spec signatures to f64 and reseal anything the change touches.

Boundary

• rings/ring-096-rust/
• specs/numeric/formats.t27
• plus the seal(s) for formats.t27 under .trinity/seals/, if the spec changes

Do not touch tools/check_ring_spec_drift.py, and do not raise any ledger to hide the drift.

Acceptance

• python3 tools/check_ring_spec_drift.py no longer reports ring-096 as DRIFTED.
• The spec-guards step "Does every ring still agree with the spec it names" is green on the PR.
• If formats.t27 changes, it is resealed with t27c seal specs/numeric/formats.t27 --save, and its tests pass.

Refs #5497

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.

User Scenarios

• Given the spec-guards drift check runs on master, when it compares ring-096-rust against specs/numeric/formats.t27, then it reports 5 signature mismatches (f32/gf16 vs f64) and the step fails.
• Given a decision is made on whether the spec or the ring is the source of truth, when the chosen side is corrected and the other side is brought into agreement, then python3 tools/check_ring_spec_drift.py no longer lists ring-096-rust as DRIFTED.
• Given formats.t27 is changed to resolve the disagreement, when it is resealed with t27c seal specs/numeric/formats.t27 --save, then the seal step passes and the spec's own tests continue to pass.

Requirements

FR-001: The 5 differing function signatures between specs/numeric/formats.t27 and rings/ring-096-rust/src/lib.rs MUST be reconciled so that tools/check_ring_spec_drift.py reports zero drift for this ring.

FR-002: If option (a) is chosen (spec is source of truth), the spec's return types that are clearly wrong (e.g., gf16_to_f32 returning gf16) MUST be corrected to f32, and the ring MUST be updated to match the corrected f32 signatures.

FR-003: If option (b) is chosen (ring is source of truth), the spec signatures MUST be rewritten to use f64 to match the ring's intended contract.

FR-004: If specs/numeric/formats.t27 is modified, it MUST be resealed using t27c seal specs/numeric/formats.t27 --save and the updated seal under .trinity/seals/ MUST be committed.

FR-005: The tools/check_ring_spec_drift.py script MUST NOT be modified to hide or suppress this drift.