Seal Coverage has been red on master since #2841: four gen-c fixes changed generated output without re-sealing #5557

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

Not my change — reporting it precisely because it is easy to lose in a run list.

When

success  ee44cbe6  15:51
failure  89b0a8b0  16:11      <- #2841
failure  0d07822a  16:15
failure  36a148fd  16:27
failure  a65da9d1  16:42
failure  89a5ab94  16:43
failure  ff0b657f  16:51

Six consecutive failures. 89b0a8b0 is #2841, gen-c: the bound set was seeded empty, so every local was re-declared once — 21 lines added to bootstrap/src/compiler.rs, FROZEN_HASH re-sealed, and no spec seal touched.

What it says

  vsa_core.json  [gen-drift]
      specs/vsa/vsa_core.t27 still hashes the same, but gen_hash_c, gen_hash_rust do not
  zig_codegen.json  [gen-drift]
      compiler/codegen/zig/codegen.t27 still hashes the same, but gen_hash_rust do not
  ... (20+ more)

Exactly what a correct gen-c fix looks like from the seal gate's side: the spec is unchanged and its generated output is not, which is the whole point of the change. The gate is right, and it is doing its job.

Four PRs compounded it: #2841, #2844, #2845, #2849 — every one a genuine emitter fix.

Why this needs saying rather than fixing

Re-sealing is t27c seal --save and it is mechanical, but the seals belong to the changes that moved them: whoever lands an emitter fix knows which drift is intended. Re-sealing all of it from outside would put my name on a bit-exactness claim about four changes I did not make.

The thing worth naming

Seal Coverage is not a required check — required_status_checks.contexts on master is []. So six red runs in forty minutes blocked nothing, and my own unrelated PR merged straight past it. The gate that catches exactly this class of drift cannot stop the drift, and its redness is only visible to whoever thinks to look at the run list.

That is the same shape as the four workflows in #2783: real signal, no consequence. Filed separately from the repair so the repair does not bury it.

Boundary

• specs/vsa/vsa_core.t27
• bootstrap/src/compiler.rs

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 Seal Coverage gate has been failing on master since PR The bound set was seeded empty, so every local was re-declared once #2841 landed, When an agent runs t27c seal --save on the drifted spec files, Then the generated-output hashes in those specs match the current compiler output and the Seal Coverage gate passes on the next run.

• Given four gen-c fixes (The bound set was seeded empty, so every local was re-declared once #2841, The division was dropped, and the loop ran once #2844, A declaration that states its type is not a type alias #2845, The for loop that ran its body once (relanded) #2849) changed emitted code without updating spec seals, When the affected specs are re-sealed, Then each spec's gen_hash_c, gen_hash_rust, and gen_hash_zig fields reflect the post-fix compiler output while the spec source hash remains unchanged.

Requirements

• FR-001: The spec files reported with gen-drift (specs/vsa/vsa_core.t27, compiler/codegen/zig/codegen.t27) MUST be re-sealed using t27c seal --save so their generated-output hashes match current compiler output.
• FR-002: The re-seal operation MUST NOT modify the spec source (the spec hash must stay the same); only the gen_hash_* fields may change.
• FR-003: After re-sealing, t27c seal-check <spec> for each updated spec MUST report no drift (exit 0 with no drift output).

Success Criteria

• t27c seal-check specs/vsa/vsa_core.t27 prints no drift and exits 0
• t27c seal-check compiler/codegen/zig/codegen.t27 prints no drift and exits 0
• t27c seal-check bootstrap/src/compiler.rs (if applicable) prints no drift and exits 0
• Seal Coverage workflow on master shows green (passing) on the next CI run