Repository navigation
chore(seals): re-seal the 3 stale gen-hash seals that keep spec-guards red - #6546
Merged
Merged
Conversation
…r spec changes Refs #6092 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Oct 5, 2026
Closed
Contributor
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 #6092
Closes #6256
This supersedes #6257. It reseals the same files, plus the twin seal of runtime/process.
spec-guards has been red on master since efc7d3c because its seal-currency step finds 3 seal files with stale generated-code hashes. This PR re-seals those three files and nothing else. It changes only generated seal data, plus a NOW entry.
automation_automation::kanban_card_chat.jsonruntime-process.jsonprocess_continuetest (3d73d51) landed without a resealruntime_runtime-process.jsonSpec meaning changes. Neither spec changed by accident. Both are reviewed, merged edits whose seals were never refreshed: the
spec_hashmoves in all three files, and the new seals describe the specs exactly as merged. A reviewer who does not want a seal to follow a spec edit should drop that file from this PR.How. I re-sealed on the Railway t27c lab with
t27c seal <spec> --save, using t27c built from master. bootstrap/ is unchanged since 682564f. No--forceand no baseline edit.Measured on the lab:
check_seal_currency.py: STALE generated-code hash 3 -> 0.check_seal_coverage.py: OK, 1330 of 1454 seals hold.Not touched. The 30 seals listed as
stale, already ledgeredin tools/seal_baseline.txt do not fail the gate. Each needs its spec fixed first, and ledger moves are owner-only.What spec-guards shows after this PR. The seal step ("Does every seal still describe what the compiler emits") is green on this PR. The job still fails, one step later, at "Does every ring still agree with the spec it names" (ring-096 vs formats.t27). After that,
published_figures.py --checkreports 8 drifted pins. Both failures are already on master. Master's run never reached them because the seal step failed first. I measured them on the lab at master a406f41 and filed them as #6553. They need non-t27 edits, or a change to what formats.t27 means, so they are out of scope for this data-only PR.File classification: 3 generated seal JSON files (tool-written) and 1 prose NOW entry. No hand-written code.
🤖 Generated with Claude Code