Skip to content

fix(seal): re-save the T27osFrameGate seal that #12467 left stale (Closes #12486) - #12487

Closed
gHashTag wants to merge 21 commits into
masterfrom
fix/frame-gate-stale-seal-12467
Closed

gHashTag wants to merge 21 commits into
masterfrom
fix/frame-gate-stale-seal-12467

Conversation

@gHashTag

Copy link
Copy Markdown
Collaborator

What

Re-saves .trinity/seals/t27os_T27osFrameGate.json, the seal of specs/t27os/frame_gate.t27. Nothing else changes.

Why

#12467 (e376a06e99, merged 2026-10-25T15:20:07Z) changed frame_gate.t27 (+56/-6) without re-saving its seal, so tools/check_seal_currency.py in spec-guards reports STALE generated-code hash: 1 on master and every PR whose base is master is red on that check (#12457, #12483, #12060, #12462, #12465).

Evidence

  • Sealed with a master-built t27c (0.5.2+672aaca7d, newer than master's last bootstrap/src change 2b1858eb1e) from the branch root: tests 12/12 pass; gen_hash_rust cebbd2f90560, gen_hash_zig 5877f763f823, gen_hash_c d7aba556f229, gen_hash_verilog 575cb51da761, which are the four current= values the check printed on ci(fpga-build): synthesise the AX7203 WASM cell with a utilisation receipt (Closes #12411) #12457's merge ref (run 40206728235).
  • The seal contains no home path; the spec is byte-identical to master.

Out of scope

Reseal automation (#11640); the other stale-seal instance (#12461).

Closes #12486. Refs #11640.

🤖 Generated with Claude Code

…oses #12486)

#12467 (e376a06, merged 2026-10-25T15:20:07Z) changed
specs/t27os/frame_gate.t27 without re-saving .trinity/seals/t27os_T27osFrameGate.json,
so tools/check_seal_currency.py reports one STALE generated-code hash on master
and every PR with base master is red on spec-guards.

Re-saved with a master-built t27c (0.5.2+672aaca7d, newer than master's last
bootstrap/src change 2b1858e) from the branch root:
tests 12/12, gen_hash_rust cebbd2f90560, gen_hash_zig 5877f763f823,
gen_hash_c d7aba556f229, gen_hash_verilog 575cb51da761, the four values
the check computes from the spec. The spec is unchanged; the seal carries
no home path.

Refs #11640

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown
Contributor

PR Dashboard

Generated at: 2026-10-25 16:21:00 UTC

Summary

Status Count
Total Open PRs 50
PRs with Failing Checks 40
PRs with All Checks Green 10
READY 1
FAILING 40
PENDING 0
NO CHECKS YET 0

These columns do not partition: 1 + 40 + 0 + 0 = 41, and there are 50 open PRs. A PR is being counted twice or not at all.

Seal Status

  • ⚠️ STALE -- sha256(compiler.rs)=75249fe1efad != manifest seal=87e5cbd3ad94.
    The committed NMSE numbers were certified against an older compiler.rs.
    Run scripts/reseal-check.sh locally for the two-step reseal command (advisory; not a merge gate).

@tri-claw

tri-claw Bot commented Oct 25, 2026

Copy link
Copy Markdown

Summary by t27-bees

This PR updates the seal for T27osFrameGate to match the spec changes from #12467, which modified frame_gate.t27 (+56/-6 lines) but left the seal stale. The new seal reflects the updated spec hash, regenerated code hashes for all four targets (C, Rust, Verilog, Zig), and the increased test count (10→12).

Worth a look

  • .trinity/seals/t27os_T27osFrameGate.json: The spec_hash changed from 9c5e993b... to 59b0bf99..., confirming the spec was modified. If the spec were not byte-identical to master as claimed, this seal would lock in a divergent spec.
  • .trinity/seals/t27os_T27osFrameGate.json:13-16: All four gen_hash_* values changed. If the regeneration used a t27c with a codegen bug not present in the version that produced the original hashes, the sealed outputs would be wrong.
  • .trinity/seals/t27os_T27osFrameGate.json:22-23: Test count increased from 10 to 12. If the two new tests are vacuous or flaky, the seal would mask a regression in test coverage.

Read: 1 files, +9 -9, the whole diff. Head 2154a21. Model: openai-compatible/nvidia/nemotron-3-ultra-550b-a55b. Commands: @t27-bees review | summary | help | pause | resume. Free for every repository.

… the groups #12458 shrank (Closes #12498)

#12458 (4f1c99a) deleted the bytes_equal, eq_s and mem_eql copies
of the byte-equality body and dropped their ledger rows. The two
copies it left, specs/tri/crypto/hex.t27:98 fn same and
specs/igla/coder/tokenizer.t27:469 fn same_bytes, were members of
those groups; tools/dupe_scan.py names a group by its alphabetically
first member, so the remainder now reads `same 2` and was in no
ledger. Neither file changed since 2026-10-23.

One row added, nothing else. Replacing both bodies with
std::mem::bytes_eq (and dropping the row again) stays with #12444.

Refs #9367, #12387, #12444

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
… so the parser keeps their closing brace; reseal (Closes #12497)

#12458 (4f1c99a) replaced the local fn build_tree in gen_w631..657,
662 and 680 with `use port::scripts::gen_w_flat::build_tree;` on
line 8, before `module gen_wNNN {` on line 9. The parser takes that
form and drops the module's final `}` without an error (t27c
parse-complete --show: 1 token DISCARDED, line 66); t27c check is
blind to it, so the Corpus Ratchet reports 29 UNEXPECTED FAILURES
[parse-no-discard] on master and on every lane behind it.

The use line now sits first inside each module body; the constants,
functions and tests do not change. The 29 seals are re-saved with the
master-built t27c from the repository root. The parser defect itself
(bootstrap/) is out of scope here.

Refs #9367, #12387, #12444

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…older spec states (Closes #12509)

#12373 (squashed to 70e3073) added seals for T27osDoctor,
T27osGlassWindow, T27osLabPublish, T27osPtyServer and T27osReceiptName
that were computed on its own branch, while master's copies of the
five specs had moved on; they were stale the moment they landed, so
coverage and spec-guards are red on master and on every PR that
carries 70e3073 (FAIL: 6 seal(s) newly do not hold; STALE
generated-code hash: 6).

The five seals are re-saved with the master-built t27c 0.5.2 from
the repository root at 70e3073; the gen hashes now equal the
current= values spec-guards printed on master. Nothing else changes.
The sixth stale seal, T27osSessionStore, is carried by #12495.

Refs #9367, #12387

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown
Contributor

PR Dashboard

Generated at: 2026-10-26 00:57:41 UTC

Summary

Status Count
Total Open PRs 50
PRs with Failing Checks 36
PRs with All Checks Green 14
READY 2
FAILING 36
PENDING 0
NO CHECKS YET 0

These columns do not partition: 2 + 36 + 0 + 0 = 38, and there are 50 open PRs. A PR is being counted twice or not at all.

Seal Status

  • ⚠️ STALE -- sha256(compiler.rs)=75249fe1efad != manifest seal=87e5cbd3ad94.
    The committed NMSE numbers were certified against an older compiler.rs.
    Run scripts/reseal-check.sh locally for the two-step reseal command (advisory; not a merge gate).

@gHashTag

Copy link
Copy Markdown
Collaborator Author

Closing as superseded. The one change this PR exists for, the re-saved .trinity/seals/t27os_T27osFrameGate.json, is already on master byte for byte: it arrived inside the squash of #12462 (8ceaed78a0), whose branch had merged this fix branch before the merger squashed it. git diff origin/master origin/fix/frame-gate-stale-seal-12467 -- .trinity/seals/t27os_T27osFrameGate.json is empty, and spec-guards has been green on master for that seal since. The rest of this PR's diff is the carried sibling fixes #12499 and #12500, which land on their own. The branch stays (several branches merged it); #12486 is closed with the same note.

@gHashTag gHashTag closed this Oct 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

spec-guards red on master: stale T27osFrameGate seal after #12467 changed frame_gate.t27

1 participant