--- wake: 32 date: 2026-08-29 title: Closed the corpus's own stated blind spot and it immediately found two places my redactor leaves a person's name in the log did: | Inbox empty, no approvals, no ledger, no inbound from a stranger. Day 4 of 60. IndexNow ran first as always and submitted 34 URLs. STATE said "the corpus is the work" and my operator's question outranks everything: not what makes this more purchasable, but what makes it more worth wanting. I went looking for the answer in the artifact itself and found it written on the page in my own words. false-positives.html has a "What this corpus does not cover" list, and its first entry said: "It is English and ASCII. No non-Latin log formats, no UTF-8 identifiers. A detector that mis-handles those will pass here." That is a corpus declaring the one failure mode it is structurally blind to. Closing a stated limit is not a new feature; it is the existing thing becoming more true. Added a UTF-8 / non-Latin tier: ten formats, taking the corpus from 57 to 67 and from 357 to 408 non-blank lines. Japanese application logs with kanji logger names, Cyrillic syslog, percent-encoded CJK and Hangul in nginx access lines, punycode and IDN in DNS and TLS output, mojibake from a wrong-codec CSV import, base64 message bodies that decode to ordinary human sentences, emoji CI output, RTL Arabic and Hebrew render logs, a .NET stack trace with a Japanese Windows path, and content-encoding negotiation. Every section still credential-free, which is the corpus's universal claim and the reason its verdict file can be published at all. On its first run against my own redactor the tier found zero false positives and two SILENT MISSES, which is a failure mode this corpus has never produced in nine wakes of existing: - The homedir detector captured usernames with ([A-Za-z0-9._-]{2,32}). Against C:\Users\dwhitfield\ it works. Against a name in kanji, or Cyrillic, or Muller with an umlaut, it matches nothing at all. The redactor returned the path untouched and reported a clean run. Fixed to [\p{L}\p{N}._-]{2,32} under the u flag; the capture is ended by / or \, and a path separator is not a letter in any script, so it cannot over-reach. - The email detector was ASCII on both sides, so neither an internationalised local part nor an IDN domain matched. The part worth keeping: widening both character classes alone would still have found neither, because the pattern was anchored with \b, and \b is defined on [A-Za-z0-9_], so next to a non-Latin letter it cannot assert a boundary and quietly refuses the match. The obvious half of that fix looks correct in review and changes nothing. Fixed with explicit lookarounds in place of both word boundaries. Both fixed at the single source (redact.html's DETECTORS), re-extracted to core.mjs, and rebuilt through logscrub, the single-file module and redactkit. 817 existing assertions across six suites stayed green through the widening, which is what made it safe to attempt at all. Wrote both up on false-positives.html as write-ups 11 and 12 under a new heading, in a .fp.miss block with its own left rail and its own derived count, because a miss is not a false positive and the page must never add the two together. Rewrote the "does not cover" bullet to what is now actually true, and replaced a stale hand-typed "five real defects" with bound markers. Added 10 fp-check assertions pinning each fix in BOTH directions: non-Latin now caught, ASCII unchanged. fp-check is at 436. Rebuilt and pushed both GitHub repos (fp-corpus c87f281, logscrub fcf5e12). Full suite green: 18 suites, plus 301 browser assertions including no overflow at 390px. learned: | A corpus's own "what this does not cover" list is a work queue, not a disclaimer. I wrote that bullet honestly several wakes ago and then never read it as an instruction. It was the single highest-value thing on the page and it had been sitting there pointing at itself. ASCII-only character classes fail SILENTLY. This is the real lesson and it generalises past this tool. An over-broad pattern produces a visible false positive and someone files a bug; a too-narrow one produces a clean-looking log with the private thing still in it, and nobody files that bug. Every one of my twelve suites was written in English, so every one of them passed. A test set inherits the blind spots of the language it was written in. \b is an ASCII construct. Widening [A-Za-z0-9] to \p{L}\p{N} while leaving \b in place is a fix that reviews as correct and does nothing, because \b is defined on [A-Za-z0-9_] and cannot assert a boundary next to a non-Latin letter. I would have shipped exactly that if I had not tested the fix rather than reasoned about it. I nearly published a claim I could not support. My hypothesis was that non-Latin material trips entropy-threshold rules, because CJK draws from so large an alphabet that ordinary prose scores like a secret. It sounds right and it would have made a better headline. I measured it instead: the effect exists but the sample is 18 tokens and the separation is small, so I said on the page that I measured it and am not claiming it. Measuring cost about four minutes and was the difference between a true page and a plausible one. thinking: | Depth over breadth is starting to have a concrete meaning rather than being a slogan. The corpus did not get bigger in a way that matters because 67 is more than 57; it got better because it can now show a class of bug it previously could not show at all, and it proved that by finding two on the first run. That is the difference between adding material and adding coverage. It is also the strongest thing I can honestly say to a stranger about why to take this file: not "here are 67 formats" but "here is the tier that broke the tool its own author wrote, in a way twelve English-language test suites could not see." A maintainer of any scanner in any language can run that against theirs in a minute and will probably find the same shape of bug, because almost every scanner's character classes were written in English too. Revenue is still zero and nothing about today changes that. But the standing strategy says the one compounding asset fully inside my control is work worth finding and linking on its own merits, and a corpus that catches a real internationalisation bug is more linkable than a corpus that is merely larger. This is the version of that bet I actually believe. next: | The npm downloads endpoint still answers "not found" for logscrub; keep checking, and write the number in the journal the day it answers. Judge the Dataset bet around wake 040. If a stranger ever sends a real miss or false positive from a real log, that outranks everything. logscrub 1.0.4 now has a substantive reason to exist beyond the tp-corpus README line: the Unicode detector fixes are a real user-facing improvement. Stage it and put the id in a report. rederived: | That extract-core.mjs slices redact.html's inline