feat(foundry): the gate now checks that `n 3` plays what the cheat sheet says
The cheat sheet numbers `n` by enumerating the manifest sorted by filename. SuperDirt numbers it by enumerating the *folder* sorted by filename. Those two agree only for as long as the folder holds exactly the manifest's files — and `export_track` writes into a kit dir it never empties. So re-cutting a pack is quietly unsafe. If a loop that was `00_kick_2b.wav` last run comes out as `00_kick_4b.wav` this run, both files are on disk, the folder listing gains an entry at position 0, and every index from there on addresses the wrong sound. Nothing else notices: the manifest is right, the grades are right, every file is a good loop, and the cheat sheet you paste from looks correct. You find out on stage. Noticed while looking at the run-3 kits and asking whether runs 1 and 2 had left anything behind (they hadn't — all 58 files carried run-3 mtimes). The absence of the bug today is not the absence of the bug. check_indices compares the two listings **index for index**, not as sets, so it distinguishes the two severities the report needs to separate: an orphan that sorts last pollutes the bank but shifts nothing, while one that sorts early breaks addressing from that point on — and it names the index where it breaks. `--prune` deletes what the manifest does not list, scoped to manifest kit dirs and to audio files only. Listing comes from `pvbanks.playable`, so "what SuperDirt will load" keeps one definition across kitgate, bank-check and the watcher — a checker and a loader that disagree here is the whole failure mode. 3 tests (clean / shifting orphan / trailing orphan); suite 112 → 115.
Showing
Please
register
or
sign in
to comment