Repository navigation
chore(specs): untrack specs/scratch -- 455 files, 578 MB, 64.5% of the tracked tree - #2283
Merged
Merged
Conversation
…e tree The repository owner asked for specs/scratch/ to stop being tracked. Added to .gitignore and removed from the index with `git rm -r --cached`. Nothing is deleted from any working tree. 455 files, 606,113,688 bytes at bffd389. 352 of them are one generated family (*_bench_*, 606,058,170 bytes); the other 103 are hand-written witnesses totalling 55,518 bytes. The tracked tree is 939,857,424 bytes, so this is 64.5% of it. The cost is accumulation: each wave committed its drafts on top of every prior wave's. Nothing outside scratch imports it (zero `use scratch` in the tree) and the corpus ratchet already excluded it by construction (bootstrap/src/suite.rs, is_scratch()). Two dependents move in this same commit: - 456 seals .trinity/seals/scratch_*.json are untracked with the specs. check_seal_coverage.py resolves spec_path against the filesystem, so on a fresh clone each would become dangling. None is in tools/seal_baseline.txt (0 of 209 lines), so leaving them would take Seal Coverage from 131 failures to 587. Removing them is the fix the gate's own message prescribes; baselining them would have written 456 lines of permanent debt. - 58 lines of tools/specs_generate_baseline.txt naming scratch specs are dropped (348 -> 290). The Emit Bit-Exact Gate enumerates via `git ls-files *.t27`, so the corpus drops 1196 -> 741 and those 58 would read as fixed, printing a false "58 spec(s) in the baseline now generate". The gate does not fail on fixed, so this is a truth fix, not a red one. Honesty limits, recorded in full in docs/NOW.md: - This does NOT shrink history. The blobs remain in git objects; clone size is unchanged. Only filter-repo plus a rewrite of every branch would reclaim it, at the cost of every open PR, fork, and recorded SHA. This stops growth from here. - Phase 3b gen-verilog yosys smoke silently falls 482 -> 27 targets on a fresh clone and Phase 3d/3e Icarus falls 155 -> 0, because collect_t27 returns an empty vec for a missing directory. Both print green; read them as untested. - 168 of the 455 files have no committed generator and exist only in history. - Seal Coverage is already red on master at 131 seals, unrelated to scratch. This change leaves it at exactly 131 -- measured against CI run 32324107310, whose failing set intersects this branch's exactly, with zero scratch seals in either. Closes #2282
Contributor
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
This was referenced Aug 20, 2026
gHashTag
added a commit
that referenced
this pull request
Aug 20, 2026
…source (#2285) suite.rs has carried a non-empty floor for the ORACLE since W628 and never for the TARGETS. load_expectations returns Ok(None) for a missing ledger, documented as "never an empty ledger", and the ratchet turns that into "RATCHET: FAIL -- Absence is not amnesty (T31)". Ten lines away, collect_t27 returns Ok(Vec::new()) for a directory that is not there; every phase iterates it happily, run_phase returns (0, 0), and the phase prints "0 passed, 0 failed" into a suite that then prints ALL TESTS PASSED. No phase in run_comprehensive checked files.is_empty(), and no test anywhere asserted a phase's target count. It was already live. Untracking specs/scratch (#2283) took icarus-simulate and icarus-cocotb from 155 targets to 0 and gen-verilog-yosys-smoke from 482 to 27. 281 baselines are still tracked under .trinity/icarus-baselines/specs/scratch/ -- golden files whose subject no longer exists and whose comparing phase has no targets. Nothing said a word, and the ratchet could not: its 221 ledger entries include 0 under scratch. Adds require_targets(phase, source, files) and its single-file form require_target_file. Both name where the targets were supposed to come from, because every instance of this bug looks identical from the summary line and completely different at the source. Six call sites: the post-corpus-only spec lists (phases 1-6), phase 1c's gf16 spec (which reported "skipped (spec not found)" for a conformance gate that checked nothing), phase 3b's smoke list, phases 3d and 3e, the relative "specs" root shared by the phase 6 metrics, and phase 7's catalog gate -- which sat behind a bare "if cat.is_file()" with no else and printed "gate failures: 0" followed by "the catalog gate are all clean" for a gate that never ran. collect_t27 is deliberately unchanged: specs/scratch is legitimately absent since #2283, so the walker must keep returning an empty vec. Only the call site knows whether zero is a defect or a configuration. A test pins that division of labour. Four named opt-outs, all "the phase does not run": the standalone specs_scratch binding, phase 3b without yosys, phase 3d without its flag or iverilog, phase 3e without --cocotb. No CI effect today: corpus-ratchet.yml walks 650 corpus specs from the repo root, both fixed specs are tracked, and it installs neither yosys nor iverilog. Every guard passes. Running the suite with --icarus-simulate now fails, naming specs/scratch, which is the honest outcome. Does not restore the coverage the untrack removed, and does not detect a phase that shrank without reaching zero. Not compiled locally; suite.rs was parse-checked with rustfmt only. See docs/NOW.md. Closes #2284 Co-authored-by: Claude <claude@anthropic.com>
This was referenced Aug 20, 2026
gHashTag
added a commit
that referenced
this pull request
Aug 20, 2026
…ero (#2287) #2285 gave suite.rs a floor for the TARGET LIST. Two sites of the same shape on the INPUT side were left, and both reported a clean pass when what they read was missing or unreadable. The discipline was already in the file. load_expectations returns Ok(None) for a missing ledger and never an empty one -- "T31 is the bug where a gate treats 'no oracle' as 'pass'" -- and the ratchet turns that None into "RATCHET: FAIL -- Absence is not amnesty (T31)". Neither site followed it. A. Phase 7 catalog gate asked the working directory, not the tree. require_target_file closed the silent skip in #2285, but both operands stayed RELATIVE, so what the gate examined -- and whether the suite aborted -- depended on the cwd the binary was invoked from, and the failure named a relative path that cannot distinguish a wrong cwd from a lost file. Both are now joined onto the canonicalized repo root. The Err arm also still failed open: with the file proven present, reaching it meant the gate could not READ a file that exists, yet it printed one line, left gate_fail untouched, and the block below still printed "(lexer/parser conformance and the catalog gate are all clean)". It now bails. B. A corrupt baseline was byte-identical to a clean one. load_gen_verilog_smoke_baseline collapsed six conditions into HashSet::new() behind an eprintln!: missing file, unreadable file, invalid JSON, no expected_failures key, that key not an array, a non-string entry inside it. The caller set summary.baseline_failures = 0, which feeds summary.acceptable. The tracked baseline legitimately holds "expected_failures": [], so the fail-open path produced exactly the same output as the real file -- the right answer for the wrong reason on every run to date, which is why nothing caught it. It now returns anyhow::Result<Option<HashSet<String>>>: Ok(None) is absent, Err is present-but-unparseable, Ok(Some) is present-and-valid, and only the third may produce a count. That is load_expectations' signature and its reason. The caller decides in the open, and decides FAIL -- the file is tracked, so absence is a broken path, not a configuration. Tests: a_missing_baseline_is_none_not_an_empty_baseline is the counterpart, for the BASELINE, of a_missing_ledger_is_none_not_an_empty_ledger, which has kept absence out of the ORACLE since W628 while nothing kept it out of the baseline. a_corrupt_baseline_is_an_error_not_an_empty_baseline runs four corrupt payloads and asserts each is an Err naming the file. No criterion moved. CATALOG_ALLOWED, catalog_gate::run, the acceptable formula and the baseline file are untouched. With cwd == repo root -- the only configuration these gates have run in -- the resolved paths are identical and no finding changes. Effect on CI today: none. corpus-ratchet.yml runs from the repo root with both files present, so every guard passes and every printed number is identical. Honesty limits: this does not restore the 482 -> 27 coverage #2283 took from phase 3b, does not detect a phase that shrank without reaching zero, and phase 3b still cannot fail CI because it never calls record(...) -- a separate defect, unfixed. Not compiled: parse-checked with rustfmt only, so types and borrows are unproven until CI's cargo build. Closes #2286. Co-authored-by: Claude <claude@anthropic.com>
gHashTag
pushed a commit
that referenced
this pull request
Aug 21, 2026
…loses #1859) Lands the accumulated W890..W898 wave-loop record. The ten .trinity/seals/scratch_*.json seals and their ten specs/scratch/ witnesses are dropped: #2283 untracked both and .gitignore now matches them, so landing the seals would have made check_seal_coverage.py report ten phantom seals. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gHashTag
pushed a commit
that referenced
this pull request
Aug 21, 2026
…loses #1859) Lands the accumulated W890..W898 wave-loop record. The ten .trinity/seals/scratch_*.json seals and their ten specs/scratch/ witnesses are dropped: #2283 untracked both and .gitignore now matches them, so landing the seals would have made check_seal_coverage.py report ten phantom seals. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gHashTag
added a commit
that referenced
this pull request
Aug 21, 2026
…loses #1859) (#1900) Lands the accumulated W890..W898 wave-loop record. The ten .trinity/seals/scratch_*.json seals and their ten specs/scratch/ witnesses are dropped: #2283 untracked both and .gitignore now matches them, so landing the seals would have made check_seal_coverage.py report ten phantom seals. Co-authored-by: Claude <claude@anthropic.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
gHashTag
added a commit
that referenced
this pull request
Aug 27, 2026
…t were reporting as 1 (#2742) * gen-rust: translate Zig builtins instead of passing them through (Refs #2161) t27's surface is Zig-shaped, so `@as`, `@intCast`, `@min` and friends appear in specs. The Rust emitter passed them through verbatim -- 27 distinct builtins, 281 occurrences -- and `@as(u32, x)` is not Rust. Two groups, and the difference is the point. Where Zig NAMES the target type the translation is exact: `@as(u64, x)` -> `(x as u64)`. Where Zig INFERS it from context the honest Rust is `as _`, which asks rustc to infer from the same context -- a `let` with a declared type, a `return` in a typed fn. Guessing a concrete width would be a silent wrong answer, which is the defect class this backend was just cleared of. Anything not in the table keeps its spelling: a wrong translation is worse than an untranslated one, because the first compiles. @-builtins in generated Rust 281 -> 26 (91% translated) rustc errors 8,834 -> 8,794 AND THAT SECOND ROW IS THE FINDING. I reported these builtins as the reason 43 specs do not compile. They are not. Measured across 141 specs: 499 DISTINCT rustc error classes, ~2,900 errors, and the builtins account for 40 of them. The largest single class is 688 occurrences of `cannot find module or crate serde` -- the emitter derives serde::Serialize on every struct with no manifest to satisfy it -- and removing even that leaves 2,255 errors and zero clean specs. So the Rust backend is not a defect list. It is a backend that has never been compiled, and `corpus` reported two of four precisely so nobody had to see that. Saying "Zig builtins chief among them", as I did in the 0.2.0 notes, understated it by two orders of magnitude; the notes are corrected in the same release. Parse 620/746, tests 1629/6, behavioural 7/7, RATCHET CLEAN -- all unchanged. FROZEN_HASH resealed in the same commit (M5). * parser: a test body may open with `var`, and `const (a, b)` is a statement (Refs #2161, closes #2735) Two changes that only work together. A braceless body that OPENS with `var`/`const` had no earlier clause to take a column from, so the statement arm was skipped and the whole body fell back to the discard -- silently, with no marker. Seeding the column from the opening statement fixes that, and #2735 records why I did not ship it before: it regressed specs/memory/notebooklm.t27 from parsing to not parsing. The regression's cause turned out to be a grammar gap one level out. `const (notebook, err) = f();` is the tuple-destructure STATEMENT, and the corpus writes it inside test bodies. When a braceless block stops on one, the parser hands it to the module dispatcher, where `parse_const_decl` demands a name and dies with "Expected identifier after 'const', got LParen" -- on a form `parse_let_destructuring` has handled all along. Routing `const (` there removes the hard error, and with it the reason the seeding could not land. Three guards keep the arm honest: it seeds only at the start of a block, only when the keyword is followed by a NAME, and `const (` never enters it at all. Measured over 746 tracked specs, against master: discarded top-level tokens 35,070 -> 33,777 (-1,293) assertions in generated Zig 11,712 -> 11,790 (+78) NOT CHECKED markers 1,068 -> 1,065 specs that parse 620 -> 620 t27c tests 1629/6 -> 1629/6 behavioural backend tests 7/7 RATCHET CLEAN The marker count falling by three is the shape to read: three blocks that used to report "not checked" now lower completely. FROZEN_HASH resealed in the same commit (M5). * fix(parser,proofs): one condition parser, and a Lean ledger that reports all 73 A leading `(` was read as proof of the parenthesised condition form. In `if (i >> j) & 1 == 1 {` it is not: the parser took `(i >> j)` for the whole condition and died at the brace. Three byte-identical copies of that code stood in parse_if_stmt, parse_while_stmt and parse_if_expr, so the fix is one parse_condition with a checkpoint that rewinds when what follows the closing paren is neither the body `{` nor a payload capture `|x|`. specs/ar/asp_solver.t27 then reached its next real defect: an unclosed `[` on line 369, a typo in the spec, which had swallowed the remaining 186 lines. With both fixed the spec parses and the Rust/Lean disagreement it was hiding became visible -- and so did 72 more. The test asserted agreement one spec at a time and aborted on the first, so it had been reporting 1 of 73 for as long as it has existed. It now collects every disagreement and holds them in an identity-keyed ledger that moves down only: a name not in the ledger fails as a regression, and a name that starts agreeing must be removed or the stale entry fails. Both directions were checked by breaking them. Forty of the 73 are theorems about an EMPTY module -- no functions, globals or tests -- so `native_decide` proved that nothing is lowerable, which is true and says nothing about the spec. ar_asp_solver is corrected here to the marker convention api_sdk_contract already uses, because Lean's `Stmt.forLoop` has one constructor for both range-for and iterator-for and cannot express the construct that makes that spec non-lowerable. Removing the early abort also surfaced two guards that had been unreachable behind it: specs/scratch envs (untracked since #2283) were counted as Lean-only witnesses, and the >= 245 floor is now held on checked + skipped so a spec may move between the two but neither may evaporate. Refs #2735 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(parser): rewind the condition only where a body must follow The previous commit's checkpoint applied to the `if` EXPRESSION too, where the then-branch is an expression and not a block: `if (c) a else b` is legitimate, the paren really does close the condition, and rewinding re-read `(c) a` as one expression. That cost six specs -- base/ops, base/ternary_add, base/types, numeric/gf16, numeric/gfternary, numeric/tf3 -- all dying on `Unexpected token in expression: KwElse`. The whole test suite was green while this was true. What caught it was parsing all 650 corpus specs with the binary from before the change and with the binary after, and diffing per spec: 558 -> 553. Now 558 -> 559, one spec moved, and it is the one the change was for. The ledger was rebuilt on the corrected parser in case the regression had been baked into it as a known disagreement. It had not: 73 either way, no entry added or removed. Refs #2735 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(parse-conform): a case can now demand "accepted, and nothing dropped" `stray_closing_brace` had been failing for as long as the parser has recovered from a stray `}`. The row demanded Rejected because Rejected was the only way the table could say "this input is not clean": a Case could pin the verdict and the declaration count, and nothing else. Reaching EOF is not the same as reading everything, and the parser already knows the difference -- `parse_ast_accounted` returns the number of top-level tokens recovery discarded, and the corpus-wide `parse-no-discard` phase is built on it. The table just could not ask. So Case gains `discards`, every existing row asserts Some(0), and the stray brace asserts Full with 2 decls and exactly 1 discarded. That is stricter than what it replaced, not weaker: rejecting the input would have thrown `fn b` away, and the requirement -- never a QUIET end of file -- is now checked as a count rather than inferred from a refusal. Both directions were broken to confirm the field is load-bearing: claiming 0 discards on the stray brace fails, and claiming 3 on a clean case fails. Suite: 1629 passed / 6 failed -> 1630 passed / 5 failed. Refs #2735 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(changelog): W699 -- parser condition, asp_solver typo, Lean ledger, discards field Refs #2735 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(now): W699 parser condition, Lean ledger, discards field Refs #2735 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * chore(seals): re-seal asp_solver after closing its unclosed bracket Fixing specs/ar/asp_solver.t27:369 changed what the spec generates, so both of its seal files -- it has two, under different keys -- described output it no longer produces. Stale seals: 420 -> 418. The other 418 are not from this branch. seal-coverage has been red on master for at least five consecutive runs, so the gate is currently reporting debt rather than guarding against it. Refs #2735 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
gHashTag
added a commit
that referenced
this pull request
Aug 30, 2026
…RUN (#2993) * feat(tri): vsim funnel -- how far each spec gets when its Verilog is RUN The one arm that can catch a defect whose nature is that it COMPILES is the one that simulates, and its gate has had no targets since specs/scratch was untracked in #2283 (#2987). Pointing it at the corpus by hand produced four defects in one sitting: #2988, #2989, #2990 and #2869. Repairing the gate is half a line and half a decision about 260 baselines for subjects that no longer exist. The measurement should not wait for it. Measured at 487003f over 650 specs: refused by gen-verilog-for-simulation 69 iverilog rejected the testbench 410 simulation exited non-zero 0 ran and REPORTED FAILURES 10 ran and produced a verdict 106 ran, exit 0, and said NOTHING 55 650 of 650 accounted for. Three properties worth naming: * is its own row. run_icarus_simulate bails only on a line saying FAILED, so `checked everything and passed` and `checked nothing` are the same exit code. A spec there is not passing; nothing asked it anything. * One TMPDIR per spec, because run_icarus_simulate keys its scratch file on the BASENAME alone and this corpus shares stems. * It refuses when iverilog or t27c is absent rather than printing a table it did not earn, and asks the OS rather than matching an error message (ci-gates 426). It reports and never gates: which of the 10 are compiler defects and which are spec defects is not a question a walker may answer. Refs #2987 * docs: correct the previous commit message, and close the backtick class The message for `tri vsim funnel` was passed inline to `git commit -m "..."`. Double quotes do not stop command substitution, so the span naming the `silent` row was executed and removed: * `silent` is its own row. -> * is its own row. zsh printed `command not found: silent`, which is the only reason it was seen. The commit is pushed and this repository forbids force-pushing, so the message stands with the hole and this is the correction. The missing word is `silent` -- the row for a spec that ran, exited 0, and printed no verdict line at all. ci-gates 418 already says to quote a heredoc delimiter when the body carries a backtick. That is too narrow: this went through the argument list instead. 427 names the class -- prose containing a backtick never reaches the shell as an argument; write it to a file or pipe it through a QUOTED heredoc and let git read it with `-F -`. Third occurrence in this repository's log, which by its own rule means the cure was wrong rather than that this is another case. Refs #2987 * docs(now): record that the local NOW preview does not preview the blocking gate Measured with a committed entry in the wrong shape: tri hooks now-gate exit 0 "NOW gate PASSED" t27c check-now exit 0 "build authorized" scripts/verify.sh "gates:OK" check_now_entry_shape exit 1 "FAIL: 1 of 3 entr(y/ies) do not say anything checkable" The last is the REQUIRED `check` context. docs/now/README.md documents the other gate's three conditions and then says the same three are what the local tools enforce; the shape condition -- a `# NOW -- <title> (YYYY-MM-DD)` first line and a `## ` section heading -- is previewed by nothing. The two local tools also name a different entry than the one the change adds: they answer "is the newest entry fresh", not "is the added entry well formed". Found by paying for it: this made `check` red on #2991. Refs #2987 --------- Co-authored-by: Claude <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
2 participants
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.
Closes #2282
The repository owner asked for
specs/scratch/to stop being tracked.Added to
.gitignoreand removed from the index withgit rm -r --cached.Nothing is deleted from any working tree -- every file stays on disk for
anyone who has it, now ignored.
What this removes
Measured against the base commit
bffd38982withgit ls-tree -r -l:specs/scratch/*_bench_*The tracked tree at that commit is 939,857,424 bytes, so this is 64.5% of it,
and 99.99% of those bytes are one generated family. The cost was never one wave's
drafts -- each wave committed its own on top of every prior wave's.
Scratch is where a wave thinks out loud. It is not a source of truth: zero
use scratchappears anywhere in the tree, no spec outside it imports one, and thecorpus ratchet already excluded it by construction (
bootstrap/src/suite.rs,is_scratch()).Files changed: 914
Dspecs/scratch/**-- index onlyD.trinity/seals/scratch_*.json-- index onlyM.gitignore,docs/NOW.md,tools/specs_generate_baseline.txtDependents moved in the same commit
456 seals.
tools/check_seal_coverage.pyresolvesspec_pathagainst thefilesystem, and CI checks out a fresh clone -- so untracking the specs alone
would turn every
.trinity/seals/scratch_*.jsonintodangling. None is intools/seal_baseline.txt(0 of its 209 lines mention scratch). They areuntracked with the specs, which is the fix the gate's own message prescribes:
"the spec was committed and later deleted. Remove the seal with it, or restore
both." They were not baselined -- that would have written 456 lines of
permanent debt.
The two sets coincide exactly: every seal named
scratch_*has aspec_pathunder
specs/scratch/, and every seal with such aspec_pathis namedscratch_*. They cover all 455 specs (one spec,w825_bench_module_469x2p6_aos_var_call_write.t27, carries two seals).58 baseline lines. The Emit Bit-Exact Gate enumerates via
git ls-files *.t27, so the corpus drops 1196 -> 741 and 58 of the 348 lines intools/specs_generate_baseline.txtread asfixed, printingNOTE 58 spec(s) in the baseline now generate. That would be false -- they are gone, not fixed. All58 dropped (348 -> 290); each was verified to name a file in the untracked set.
The gate does not fail on
fixed, so this is a truth fix, not a red one.Gate impact, measured
Seal Coverage is already red on master and stays at exactly the same 131.
Run 32324107310 on
bffd38982-- the exact base of this branch -- reportsFAIL: 131 seal(s) newly do not hold, and the eight most recent master runs all failed.Those 131 are stale/dangling seals in
specs/tri/,specs/fpga/,compiler/and elsewhere; none has anything to do with scratch, and re-sealing them needs a
built
t27c.The delta was measured rather than assumed: CI's failing-seal name set from run
32324107310 was diffed against a run of the same script over this branch's tree.
0 seals fail on master that do not fail here, and 0 scratch seals fail here.
Without the seal removal the count would have gone 131 -> 587.
Corpus ratchet: unchanged, by construction.
docs/reports/suite_expectations.jsonholds 221 entries againstmax_entries: 221, none under scratch. The only difference is the log line741 of 1196->741 of 741.Honesty limits (BINDING)
objects forever.
git clonestill transfers all 578 MB and every existingclone is exactly the size it was. Only
git filter-repoplus a rewrite ofevery branch and tag would reclaim that space, and it would break every open
PR, every fork, and every commit SHA in the tree's own records. This stops
the growth from here. It reclaims nothing already paid for.
collect_t27returnsOk(vec![])for a missing directory rather thanerroring, so on a fresh clone Phase 3b gen-verilog yosys smoke falls from 482
to 27 targets (94.4%; this phase is not filtered by
--corpus-only, so itis the one real coverage loss), and Phase 3d/3e Icarus + cocotb falls 155 -> 0
(local-only; no workflow passes those flags). Both print green. Read them as
untested, not as passing.
generators
scripts/gen_w<NNN>.pyexist and are deterministic -- nonereferences
random,time,datetime,uuid, the environment, or thenetwork -- but they cover 279 of the 383 wave numbers present. The other 168
files exist only in git history. Recoverable, not reproducible.
.trinity/icarus-baselines/specs/scratch/is now unreachable in CI. It is20,248 bytes and removing it would also require editing 5 lines of
tools/json_parse_baseline.txt. Out of scope; it costs nothing and failsnothing.
before and after at the identical 131. It is not one of the four required
contexts (
check-now-freshness,check,validate,check-linked-issue), soit does not block merge -- worth saying out loud, because
docs/BRANCH-PROTECTION.mdlists it as required and the live ruleset does not.docs/CORPUS-RATCHET.md:96, the comment atsuite.rs:39, andcorpus-ratchet.yml:22quote 606,113,688 bytes as a livemeasurement of the tracked tree. Still true of history, no longer true of a
fresh checkout.