seals: refresh the 102 the last two backend repairs invalidated - #3441
Merged
Conversation
Refs #3440 `Spec Guards` has been red on master since #3435 and red again after #3437. Both merged, because it is not a required context -- so `--auto` never looked at it, and neither did I. It was wired one pass earlier precisely because three checks only ran when someone typed them. The guard is right. #3435 changed C parameter emission and #3437 changed the Rust `Copy` derive, so the seals recording what those backends emit no longer described the output. Measured on b519f90: seals scanned 1318 current 953 STALE generated-code hash 102 across 57 specs sealed with gen_hash=none 169 spec file no longer present 94 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, one merge later. This is a cycle rather than rot: the previous `sealed_at` on the affected files was 2026-09-07T21:07:04Z, hours old. Every backend change invalidates seals and nothing in the merge path refreshes them or blocks on them. The diff is 102 files and exactly 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, the gate exits 0. Two neighbouring populations are deliberately left alone and named in #3440 rather than folded in: 94 seals whose spec file no longer exists, and 169 recording `gen_hash=none`. Conflating them is how the last batch stayed invisible. The cure for the cycle is the owner's call and is not in this commit. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gHashTag
enabled auto-merge (squash)
September 8, 2026 00:34
Contributor
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refs #3440
Spec Guardshas been red on master since #3435, and red again after#3437. Both merged, because it is not a required context — so
--autoneverlooked at it, and neither did I. It was wired one pass earlier precisely
because three checks only ran when someone typed them.
The guard is right
#3435 changed C parameter emission and #3437 changed the Rust
Copyderive,so the seals recording what those backends emit stopped describing the output.
Measured on
b519f902e:gen_hash=noneBy field: 88
gen_hash_rust, 19gen_hash_c.spec_hashstale forzero — which is why every coverage and freshness gate stayed green, the
same shape as #3415, one merge later.
A cycle, not rot
The previous
sealed_aton the affected files was2026-09-07T21:07:04Z—hours old. Every backend change invalidates seals, and nothing in the merge
path refreshes them or blocks on them.
The diff
102 files, and exactly three keys move:
sealed_atgen_hash_rustgen_hash_cspec_hash,gen_hash_verilogandgen_hash_zigare untouched. After thereseal: 0 stale, gate exits 0.
What this deliberately does not do
The repair is one-time and the condition recurs. Three cures, and picking one
is the owner's call, not mine — they are laid out in #3440:
Spec Guardsrequired (needs thepaths:filter dealt with first — arequired paths-filtered workflow hangs every PR it does not match, Ten constants declare a type they cannot fit; three of four backends emit them verbatim #2925);
artefact rather than a record;
Two neighbouring populations are left alone and named rather than folded in:
94 seals whose spec file no longer exists, and 169 recording
gen_hash=none. Conflating them is how the last batch stayed invisible.