docs(corpus): the real compile-failure count, with an honest denominator (#112)
The clean re-run after the harness fixes. Three numbers have now been attached
to this question and the first two were both about the tool:
#112 said 14 (a baseline taken during the mute migration)
pre-fix run 128 (the column-0 `$` artifact, ~49 of them fake)
clean run 79 BROKEN + 30 CRASH, out of 799 files
And 799 is the wrong denominator too. Split by scope:
OPAL setlist 13 files 0 BROKEN 0 CRASH
live/ 694 files 51 BROKEN 21 CRASH ~10%
study/ 59 files 13 BROKEN 3 CRASH
sandbox/blocks/test 21 files 5 BROKEN 3 CRASH
`study/` is Tidal DOCUMENTATION with inline examples — prose that was never
meant to compile as a track. Counting it inflates the figure the same way the
harness bug did, just more quietly. The number worth quoting is 51+21 of 694.
THE GIG IS UNAFFECTED. Zero setlist tracks in either category, and gig-up is GO.
The CRASH class is new and it is the valuable one. These tracks COMPILE, then
throw when queried — invalid mini-notation inside a string, which is exactly why
the type checker waved them through:
"[d d] <d d d*2 d*4>]" unbalanced bracket
"~ ulgab?:1" `?` before `:`
"[0 .. 7 0]" a range with a trailing element
"<0.75 .. 0.8 0.8 .. 0.65>" a sequence on the left of `..`
Every one would fail live, because the scheduler queries every cycle. Until this
run they were all reported as "FAIL — 0 orbit(s) SILENT".
Deliberately NOT fixed here. None are in the set, and each one needs a decision
about what PLN meant — "[0 .. 7 0]" has at least two readings and only he knows
which. Triage is the deliverable; the edits are his call.
Also records a counting caveat rather than hiding it: silent-eval prints a
track's STEM, not its path, so stems that exist in several directories are
marked as ambiguous instead of guessed. The real fix is repo-relative paths in
silent-eval's output — noted on #112, not silently papered over.
Showing
docs/2026-07-31-corpus-compile-failures.md
0 → 100644
Please
register
or
sign in
to comment