Conversation
…29 runs `seal-coverage` last passed on master at 588074c, 18:23. The first red is d7ee76d -- #2866, mine -- which changed four emitters, so generated output moved while the specs did not. The `coverage` check was already failing on PR #2866 when I merged it. Twenty-nine runs later the drift is cumulative: 926 seals [gen-drift] 926 gen_hash_rust 62 gen_hash_verilog 33 gen_hash_zig 31 gen_hash_c The gate calls re-sealing a STATEMENT that the new output is wanted and says to read the acceptance columns first. Read: corpus ratchet, master: UNEXPECTED PASSES 1 DISCARD WORSENED 0 GATE FAILURES 0 Red on an improvement -- one more spec passes than the ledger expects, nothing worsened. Acceptance is better than what is recorded, so this records outputs whose acceptance rose. That ledger entry (151 -> 150) belongs to the parallel session's #2906 and is not touched here. After: 1318 seals, 1224 hold, 94 known-broken already in seal_baseline.txt. `check_seal_coverage.py` exits 0, and its --self-check still exits 0, so the green is the gate working rather than the gate skipped. Closes #2908
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
…ith it
The second of master's two red gates, and like the first it is not a regression.
--- Ratchet (W628) ---
ledger: 151 / 151 cap
observed (primary): 150
UNEXPECTED FAILURES: 0
UNEXPECTED PASSES : 1
- specs/pins/emitter_xdc.t27 [typecheck] (fixed -- remove from the ledger)
#2906 fixed it: an integer literal above i64::MAX fell to the float branch, so a
bit mask read as a float initialising an integer. The spec typechecks; the ledger
entry outlived the failure it recorded, and the ratchet named the repair itself.
`max_entries` drops with the entry rather than staying at 151, so the slack
cannot hide the next one. The reason is written into the file beside the number.
Refs #2908
gHashTag
changed the title
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-08-29 22:41:27 UTC
Summary
Seal Status
|
gHashTag
enabled auto-merge (squash)
August 29, 2026 22:45
Contributor
PR DashboardGenerated at: 2026-08-29 22:47:13 UTC
Summary
Seal Status
|
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
This was referenced Aug 29, 2026
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-08-29 22:57:47 UTC
Summary
Seal Status
|
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.
seal-coverageon master:First red is
d7ee76d4— #2866, mine — which changed four emitters, sogenerated output moved while the specs did not. The
coveragecheck wasalready
failon that PR when I merged it. Four hours of both sessions' PRshave carried a red
coverageunrelated to whatever they changed.Before re-sealing, the reading the gate asks for
corpus-ratchetis red on an improvement — one more spec passes than theledger expects. Nothing worsened. Acceptance is better than what is recorded, so
this records outputs whose acceptance rose.
That ledger entry (151 → 150) is the parallel session's #2906 and is not
touched here.
The change
tri seals drift --fix— 926 files under.trinity/seals, no source changes.gen-driftsealscheck_seal_coverage.py--self-checkstill exits 0, so the green is the gate working rather than thegate skipped.
Closes #2908