Skip to content

Remove emitter_xdc from the corpus ledger; it passes now - #2913

Merged
gHashTag merged 3 commits into
masterfrom
corpus-ledger-emitter-xdc
Aug 29, 2026
Merged

Remove emitter_xdc from the corpus ledger; it passes now#2913
gHashTag merged 3 commits into
masterfrom
corpus-ledger-emitter-xdc

Conversation

@gHashTag

Copy link
Copy Markdown
Owner

The corpus ratchet has been red on master for at least three consecutive runs,
and the reason is mine.

#2897 fixed the string-literal
inference bug and specs/pins/emitter_xdc.t27 began to typecheck. I updated
tools/specs_generate_baseline.txt — and did not know about
docs/reports/suite_expectations.json, which still listed the spec as
expected-to-fail.

An UNEXPECTED PASS is a ratchet failure by design.
docs/CORPUS-RATCHET.md: "you fixed something. Remove the entry and lower
max_entries."

entries      151 -> 150
max_entries  151 -> 150      (down — the only direction the cap may move)
RATCHET: CLEAN

Controls

control expected got
entry removed exit 0, UNEXPECTED PASSES: 0 RATCHET: CLEAN
entry restored exit 1, UNEXPECTED PASSES: 1 reproduced
max_entries direction down only 151 → 150

Why it was missed

This is #2892's lesson one level
up. That day I found a fix that had not travelled from one command to the
neighbouring function in the same file; here it did not travel from one ledger
to its sibling.

When a repair makes a spec pass, grep every file that names the spec — not
only the ledger you happen to know about.

Refs #2864

The corpus ratchet has been red on master for at least three consecutive runs
and the reason is mine. #2897 fixed the string-literal inference bug and
`specs/pins/emitter_xdc.t27` began to typecheck. I updated
`tools/specs_generate_baseline.txt` and did not know about
`docs/reports/suite_expectations.json`, which still listed the spec as
expected-to-fail.

An UNEXPECTED PASS is a ratchet failure by design: docs/CORPUS-RATCHET.md says
"you fixed something. Remove the entry and lower max_entries".

  entries      151 -> 150
  max_entries  151 -> 150      (down, the only direction the cap may move)
  RATCHET: CLEAN

Control both ways: with the entry restored the ratchet reports
`UNEXPECTED PASSES: 1` and exits 1; without it, exit 0.

This is #2892's lesson one level up. That day I found a fix that had not
travelled from one command to its neighbour; here it did not travel from one
LEDGER to its sibling. When a repair makes a spec pass, grep every file that
names the spec -- not only the ledger you happen to know.

Refs #2864

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@gHashTag
gHashTag enabled auto-merge (squash) August 29, 2026 23:05
@github-actions

Copy link
Copy Markdown
Contributor

📓 NotebookLM Notebook linked to this PR

This notebook contains session context, decisions, and artifacts for this work.

@github-actions

Copy link
Copy Markdown
Contributor

PR Dashboard

Generated at: 2026-08-29 23:05:28 UTC

Summary

Status Count
Total Open PRs 9
PRs with Failing Checks 8
PRs with All Checks Green 1
READY 0
FAILING 8
PENDING 0

Seal Status

  • ⚠️ STALE -- sha256(compiler.rs)=82e020cf95b2 != 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).

@github-actions

Copy link
Copy Markdown
Contributor

📓 NotebookLM Notebook linked to this PR

This notebook contains session context, decisions, and artifacts for this work.

@github-actions

Copy link
Copy Markdown
Contributor

PR Dashboard

Generated at: 2026-08-29 23:08:21 UTC

Summary

Status Count
Total Open PRs 9
PRs with Failing Checks 8
PRs with All Checks Green 1
READY 0
FAILING 8
PENDING 0

Seal Status

  • ⚠️ STALE -- sha256(compiler.rs)=82e020cf95b2 != 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
gHashTag merged commit e276c02 into master Aug 29, 2026
24 checks passed
gHashTag added a commit that referenced this pull request Aug 30, 2026
…2924)

The census's work queue had two rows needing no owner decision: a closing brace
with nothing open (4 specs) and a statement terminated twice (2). Both probed
first -- `struct X { };`, `} else { };` and `print(x);;` each fail, and each
parses with the extra semicolon removed.

The census names only the FIRST occurrence, because that is all the compiler
reports. Fixing that one line moved each error a few lines forward and recovered
nothing. Fixing every occurrence of the same form:

  specs/bus/pubsub.t27              2
  specs/fpga/testbench/mac_tb.t27   6
  specs/fpga/testbench/uart_tb.t27  5

  specs that parse   615 -> 618, zero regressions
  21 lines changed, every one exactly one character shorter, no declaration
  touched

TWO EDITS WITHDRAWN. `hybrid_arithmetic.t27` and `relay_observer.t27` took the
same repair, advanced seven lines each, and still do not parse -- they hit a
different construct. The edits also made their seals stale and turned
`check_seal_coverage.py` red. An edit that buys no measurable change and costs a
re-seal is not a repair, so both are reverted. The gate caught that, not my
judgement.

The corpus ratchet caught the three fixed specs immediately as UNEXPECTED PASS
-- #2913's lesson working. Entries removed, max_entries 150 -> 147, RATCHET
CLEAN. `git grep` over the three names found four more files that mention them;
none is read by any gate, so they are snapshots rather than ledgers.

`tri ledgers audit` refuses to run while a ledger is uncommitted, which it did
mid-iteration. That is the guard, not a failure.

`bootstrap/src/compiler.rs` untouched; FROZEN_HASH does not move.

Refs #2864

Co-authored-by: Claude <noreply@anthropic.com>
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.

2 participants