seal: fpga_ZeroDSP_BPSK.json is stale — #1874 edited specs/fpga/bpsk.t27 without re-sealing

[gHashTag]

.trinity/seals/fpga_ZeroDSP_BPSK.json no longer describes the spec it names. Recomputed against origin/master @ 4ea72c322fa5572fc0c33fb5deedb739b7ad6c6a:

sha256(specs/fpga/bpsk.t27) on master  = b03d87fec868d2aa28f16a77d0dc77dd068c98b1443f9a2408896c72d4a3c227
seal spec_hash                          = c03511cef14c6a38652f65fdc0852cfc638dec039a96c9dc4cb6f04f49643228

Both digests were recomputed for this issue, from git cat-file blob and independently from the GitHub contents API (Accept: application/vnd.github.raw); the two agree. They differ from the first byte, so this is a real content difference and not a transcription slip.

The gate already reports it

tools/check_seal_coverage.py:89 hashes the spec exactly this way:

got = hashlib.sha256(full.read_bytes()).hexdigest()
if got != digest:
    bad.append((name, "stale", f"{sp} changed since sealing"))

so the gate emits:

  fpga_ZeroDSP_BPSK.json  [stale]
      specs/fpga/bpsk.t27 changed since sealing

It is not in tools/seal_baseline.txt (207 entries; no line matches bpsk case-insensitively), so it is counted as new breakage rather than recorded debt.

I replayed scan() over master's tree (read from the object DB, so no checkout was needed and no working tree was touched) and reproduced the gate's headline number:

seals scanned      : 1317
do not hold        :  281   (187 stale, 89 spec-not-in-tree, 5 no-spec-path)
baseline entries   :  207
NEWLY do not hold  :  132   (all stale)  <- matches "FAIL: 132 seal(s) newly do not hold"

fpga_ZeroDSP_BPSK.json is one of those 132. (The replay collapses the gate's dangling/phantom split into one bucket, because that distinction needs full history and this clone is shallow. It cannot affect the 132: membership in the "newly" set is decided by seal name against the baseline, not by kind.)

Cause

PR #1874, merge commit 10e3d5e71a970351d5d1c63f0dd88b77210dbffc (merged 2026-08-21T08:02:23Z), "chore: civilian mesh positioning — drop drone wording (bpsk.t27)". It changed one line of specs/fpga/bpsk.t27 and did not touch the seal:

-// ZeroDSP BPSK modem core (TRI-NET 5.8 GHz drone-mesh radio PHY).
+// ZeroDSP BPSK modem core (TRI-NET 5.8 GHz mesh radio PHY).

That PR is the sole cause, and it is checkable rather than inferred: at its parent e756e8c3300e96b35682f8394b405f529683e78c the spec hashes to

c03511cef14c6a38652f65fdc0852cfc638dec039a96c9dc4cb6f04f49643228

which is exactly the spec_hash the seal records. The seal itself was last written by cde40d9cae69bad6bc0d892402ab2500c53e8347 (sealed_at: 2026-08-19T13:19:43Z), two days before #1874 landed.

Ask: re-seal ZeroDSP_BPSK

Deliberately not done as part of filing this, and not baselined either. Both omissions are the point:

• Re-sealing rewrites more than spec_hash. The seal also carries gen_hash_c, gen_hash_rust, gen_hash_verilog and gen_hash_zig. Re-sealing without diffing the regenerated targets against the sealed ones blesses whatever changed, which is the one thing a seal exists to prevent. A comment-only edit should leave all four byte-identical — but "should" is precisely the claim the seal is there to check, so the diff is the evidence and it has not been produced here.
• Adding it to tools/seal_baseline.txt would record it as accepted debt, and that is a decision, not a cleanup. Seals: 0 of 1072 specs verify, 928 with an unchanged spec_hash — gate it or remove it #2150 has the prior question open — re-seal the corpus and make the phase a gate, or remove the mechanism — and baselining a two-day-old breakage while that is open would quietly pre-empt it.

Related

• Seals: 0 of 1072 specs verify, 928 with an unchanged spec_hash — gate it or remove it #2150 — Seals: 0 of 1072 specs verify … gate it or remove it (the open decision above)
• Post-ladder master drift: seal-coverage red (dangling+phantom) and 'Every spec still generates' red (bigint.t27 et al.) #2232 — Post-ladder master drift: seal-coverage red (same gate, dangling/phantom drift from 2026-08-19; this one is stale and post-dates it)

Verified against origin/master @ 4ea72c322fa5572fc0c33fb5deedb739b7ad6c6a.