Spec Guards has been red on master since #3435, and two PRs merged past it #3440

What

Spec Guards — the workflow wired in #3427 to run three checks that previously only ran when someone typed them — has been failing on master since #3435, and again after #3437. Both merged anyway, because it is not a required context.

success  Self-check -- seal currency
success  Self-check -- ring/spec drift
success  Self-check -- differential harness
failure  Does every seal still describe what the compiler emits
skipped  Does every ring still agree with the spec it names
skipped  Run each CONVERGED pair on the same inputs

The guard is right. It is doing exactly what it was built for: #3435 changed C parameter emission and #3437 changed the Rust Copy derive, so the seals recording what those backends emit no longer describe the output.

Measured on b519f902e:

By field: 88 gen_hash_rust, 19 gen_hash_c. spec_hash stale for zero — which is why every coverage and freshness gate stayed green, the same shape as #3415.

The previous sealed_at on the affected files was 2026-09-07T21:07:04Z, hours old. So this is not rot; it is a cycle: every backend change invalidates seals, and nothing in the merge path refreshes them or blocks on them.

What this PR-adjacent change does

Reseals the 57 specs. Diff is 102 files, and only three keys move: sealed_at (102), gen_hash_rust (88), gen_hash_c (19). spec_hash, gen_hash_verilog and gen_hash_zig are untouched. After: 0 stale, gate exits 0.

What it does not do — owner's call

The reseal is a one-time repair of a recurring condition. Three ways to stop the cycle, none of which I should pick alone:

1. Make Spec Guards a required context. Blocks the merge until seals are current. Note the constraint from Ten constants declare a type they cannot fit; three of four backends emit them verbatim #2925: it is paths:-filtered, and a required workflow that does not match a PR's paths hangs that PR forever on a check that never posts. So this needs the paths filter removed or an always-posting skip job first.
2. Reseal automatically in the same commit as a backend change, via the pre-commit hook. Cheap, but it makes the seal a derived artefact rather than a record, which is arguably the point of having it.
3. Leave it advisory and accept that someone must read it. That is the status quo, and it failed twice in two days — I merged past a red guard I had wired myself one pass earlier.

Not measured

Whether the 94 seals whose spec file no longer exists should be deleted, and whether the 169 recording gen_hash=none are still refused by the backends that refused them. Both are separate populations and neither is touched here.

User Scenarios

• Given backend changes have invalidated generated-code hashes in seal files, when the reseal operation updates gen_hash_rust, gen_hash_c, and sealed_at for the affected specs, then the Spec Guards workflow passes with zero stale seals.

Requirements

• FR-001: The 102 stale seal files MUST have their gen_hash_rust (88 files), gen_hash_c (19 files), and sealed_at (102 files) updated to match current compiler output.
• FR-002: The spec_hash, gen_hash_verilog, and gen_hash_zig fields MUST remain unchanged.
• FR-003: After reseal, the Spec Guards workflow MUST report zero stale generated-code hashes and exit successfully.

Success Criteria

• t27c spec-guard (or the command that runs the three Spec Guards checks) exits 0.
• Stale generated-code hash count is 0 (down from 102).
• All 102 updated seal files show current sealed_at timestamps and matching gen_hash_rust/gen_hash_c.

Boundary

• compiler/cli/spec.t27
• dataset/igla-coder/v0.1/pairs/0001-experience-format/spec.tri
• dataset/igla-coder/v0.1/pairs/0002-mozg-state-machine/spec.tri
• dataset/igla-coder/v0.1/pairs/0003-dna-schema/spec.tri
• dataset/igla-coder/v0.1/pairs/0004-git-orchestrator/spec.tri
• dataset/igla-coder/v0.1/pairs/0005-mcp-tool-registry/spec.tri
• dataset/igla-coder/v0.1/pairs/0006-scene-schema/spec.tri
• dataset/igla-coder/v0.1/pairs/0007-ring-runtime/spec.tri
• dataset/igla-coder/v0.1/pairs/0008-igla-manifest/spec.tri