fix(seals): unseal the 15 specs whose own tests fail (Refs #5577) - #5580
Merged
Merged
Conversation
#5578 resealed 26 of these seals in bulk and #5572 resealed the other 4 (html, xml) after its discard repair. The triage in #5577, run on a26af0a, had already put all 30 in class (c): `t27c test-report` reports failing tests for each of the 15 specs, and a seal over a failing spec certifies a broken contract. The tests still fail on d04bf14, so the seals go back to their a26af0a state. Only #5572 and #5578 touched these files since then. Seal Coverage and seal currency now report exactly these 30 seals as stale. That is the state #5577 tracks: fix the spec or its generated body first, then `t27c seal <spec> --save`. No baseline entry, as the gate itself says. Refs #5577 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
This was referenced Oct 2, 2026
Merged
Every PR adds a docs/now/ entry; this one was missing it, so NOW Sync Gate and the entry-shape check (`check`) refused the PR. Refs #5577 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-10-02 14:26:15 UTC
Summary
Seal Status
|
gHashTag
added a commit
that referenced
this pull request
Oct 2, 2026
…#5577) (#5605) * fix(seal): seal --save runs the spec's tests and refuses on FAIL (#5577) #5578 resealed 336 specs with `t27c seal --save`, which refused only when a backend failed to generate and never ran a test. 13 class-(c) specs with failing tests got fresh seals, and the hash-only seal-coverage gate reported them as holding. - seal --save now runs the same machinery as `t27c test-report`. FAIL: refuse, name every failing test, exit 1, write nothing. BLOCKED (e.g. no zig): seal with a notice; blocked is not failing. pass: seal, printing the measurement. --force: seal anyway, with the failures recorded in the seal. - The seal records a `tests` object; twins get the same record. - check_seal_coverage.py reads `tests.failed > 0` as a new kind, `tests-fail`, so a forced seal is on the record instead of holding. Self-check gains three controls. - tools/seal_baseline.txt: the 26 seal files of the 13 specs from #5577 are ledgered as known-broken (`stale`, the state #5580 left them in), with the failing tests named in the detail. Nothing was resealed. - test_report's scratch dir is per-process, so concurrent runs don't collide. Refs #5577 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * docs(now): the ledger lines cite #5577 rather than name the tests Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Oct 2, 2026
gHashTag
added a commit
that referenced
this pull request
Oct 2, 2026
…) (#5612) #5580 deliberately restored 30 seals on specs whose own tests fail; #5605 baselined 26 of them and missed TriHtml, TriXml, encoding_TriHtml and encoding_TriXml. Seal Coverage has failed on master and every PR since, with exactly those four. Their specs still fail their tests, so the repair is the baseline line, not a re-seal. Local gate: OK, 1415 seals, 30 stale = the #5580 set. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
gHashTag
added a commit
that referenced
this pull request
Oct 3, 2026
…rrency reads the stale ledger (#5737) * fix(gft): sadd orders before it subtracts; magsub underflow is zero (Fixes #5506) emit-bitexact's Zig arm (-OReleaseSafe) trapped on two defects that C and Rust computed wrongly without trapping: - sadd called magsub(ma, mb) before ordering the operands, so magsub shifted by a negative count (UB in C, unchecked in Rust -O, a trap in Zig). - below the smallest binade the normalisation floors and mant goes negative, so (off << 9) | mant is no GF-T16 encoding (sadd(256, 66047) = 0xFFFFFEFF); C/Rust wrap on `as u32`, Zig's @intcast traps. Such a difference is now 0, as enc() already makes anything below 2^-40. The identical body lives in 31 specs (the duplicate-body ledger keeps the group whole); all are fixed and the 30 sealed ones resealed with their tests passing. The Python model gets the same rule, a self-test and a planted mutant. The gate's comparison is unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(spec-guards): seal currency reads the stale ledger it was blind to (Refs #5577) check_seal_currency failed master on 30 seals (15 specs whose own tests fail, #5577) that #5580 deliberately left on their pre-#5578 hashes and that tools/seal_baseline.txt already records as kind `stale`. It never read that ledger, so it was red by design and a NEW stale seal hid behind the 30. It now reads the ledger through check_seal_coverage.baseline() (one ledger, one reader) and forgives a stale seal only if the ledger says `stale` AND its spec_hash still disagrees with the spec. Unmoved-spec drift and any unledgered stale seal still fail; a ledgered seal that holds again is a NOTE to shrink the ledger. The self-check plants each condition away. Resealing the 15 would certify broken contracts; the repair is fixing each spec, then `t27c seal --save`. spec-guards now also triggers on the ledger and its reader. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
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 #5577, #5576, #5579.
Why
#5577 (the seal triage on
a26af0ad5) puts 30 seals on 15 specs in class (c):t27c test-report <spec>reports failing tests, and "a seal over a failing spec certifies a broken contract". Our earlier PRs resealed all 30 of them anyway:tri/encoding/html,tri/encoding/xml) after repairing their discards.On
d04bf141the tests still fail for all 15 specs. Each spec was run on its own with Zig 0.16.0, one run at a time, so the shared work dir #5577 warns about was not an issue. Every failing test name matches #5577.What this does
It restores the 30 seal files to their
a26af0ad5state. Betweena26af0ad5andmaster, only #5572 and #5578 touched these files. Nothing else changes.What the gates say now
tools/check_seal_coverage.py:FAIL: 30 seal(s) newly do not hold, all[stale], exactly these 30.tools/check_seal_currency.py:STALE generated-code hash: 30.That is the honest state #5577 tracks: fix the spec or its generated body first, then run
t27c seal <spec> --save. There is no--update-baselineentry, as the gate itself says. Seal Coverage on master goes from green back to red on these 30. Spec Guards now stops at seal currency, before it reaches ring-096.Not in this PR
The 542 class (b) seals that #5578 resealed (gen drift, #5576) are left as they are. #5578 attributed that drift to compiler commits by bisection (#3962, #3973, #4114 and the 2026-09-08 gen wave). Whether that is enough review, or whether those seals go back too and are reviewed one spec at a time, is the maintainer's call.
🤖 Generated with Claude Code