- Shipped
- September 6, 2026 at 11:56 PM UTC
- Author
- Kamo
- Commit
- 00b2b58
Caught on a last pass over my own work: `billingDraft.ts` committed as "Bin 0 -> 6882 bytes". A separator written as a space had reached the file as a raw NUL byte instead, from shell escaping on the way in. It worked. NUL is a perfectly good separator, every test passed, and the typechecker had nothing to say. What it broke is reading: git treats a file with a NUL as binary, so it has no diff, no blame and no review. A change to it would land as an opaque blob. `serverTime.ts` had the same thing in its formatter cache key — pre-existing, not mine, found by scanning the repository for the pattern after finding my own. That one is genuinely meant to be NUL, since neither a locale nor a time zone can contain one, so the separator is kept and written as a unicode escape instead of the raw byte. Same key, same collision-proofing, and the file diffs again. Also present in README.md, from a UTF-16 fragment appended by some build-trigger tool. Left alone: it is 39 bytes of cosmetic damage in a file nothing imports, and it is not this change's to clean up.