Introducing extreme mode: correct data in a hostile encoding

We already ship edge mode for the awkward-but-valid corners and invalid mode for broken checksums. Today we are adding a third, sharper tool: extreme mode. It occupies a space neither of the others reaches — data that is entirely correct, with passing checksums and real values, but presented in the most disturbing encoding a production system ever actually encounters.

This is the failure mode nobody writes a fixture for, because nobody can be bothered to type a zero-width space by hand. And yet it arrives constantly in the wild: a name copy-pasted from a PDF drags along a non-breaking space; a form field picks up a trailing newline; a username uses a Cyrillic "а" that is visually identical to the Latin one. These records are not invalid — they are correct data wearing a hostile costume, and they are exactly what breaks an equality check or slips past a filter.

What "hostile encoding" means

Every generator that already takes `edge` now also accepts `extreme=true`. The value is wrapped with one hostile class per record, so a batch (via `count`) rotates across all four:

• Untrimmed whitespace — leading and trailing spaces, non-breaking spaces, and a trailing newline that your TRIM never anticipated.
• Invisible and zero-width characters — zero-width spaces and joiners with a leading byte-order mark, present in the string but absent on screen.
• Homoglyphs — Cyrillic, Greek, and fullwidth lookalikes that read as Latin letters but are entirely different code points.
• Right-to-left overrides and stacked combining marks — direction-flipping controls and characters that pile diacritics past what a renderer expects.

{
  "data": {
    "name": "\u00A0Magdalena",     // leading non-breaking space
    "surname": "Wróbel\n",         // trailing newline
    "initials": "MW"                // left clean — see below
  }
}

// The bug this finds:
storedName === submittedName   // false — one has a NBSP the eye can't see

This is the data that breaks an equality check when a zero-width space sneaks into one copy of a string but not the other, or that slips a homoglyph past a blocklist because "Аdmin" (Cyrillic А) is not the "Admin" you were guarding against.

Correct, and still recoverable

The mangling is deliberate but never destructive, because the point is to test your handling, not to hand you garbage. Two rules keep the data usable:

• Only the human-facing string is touched. Identifiers — PESEL, NIP, IBAN, CPR, codice fiscale, BSN — keep their digits ASCII (homoglyphs are excluded), so they still parse and checksum after normalisation.
• On composite records, only the name or assembled value is mangled. Initials, legal forms, birth dates, and national identifiers stay clean, so you always have a pristine reference to compare against.

The `lorem` and custom-regex endpoints opt out entirely — mangling would break their length and pattern-match contracts, and there is no meaningful "correct value underneath" to recover. Everywhere else, run the mangled string through `String.prototype.normalize("NFKC")` and a trim, and you should land back on the clean value. If you do not, you have found a bug — which is the whole idea.

The question it answers

extreme mode exists to answer one question: how should your system behave here? Does your pipeline trim, normalise to NFKC, and compare values safely — or does an invisible character break a login, a homoglyph slip through a moderation filter, and a right-to-left override scramble a rendered invoice? These are not hypothetical; they are the long tail of real-world Unicode that every text-handling system eventually meets.

edge asks "is your code ready for the unusual?" invalid asks "does it reject the wrong?" extreme asks "does it survive the correct-but-hostile?" — the case teams most often forget exists.

Output stays reproducible from the `seed`, so a failure you find today replays exactly tomorrow. The flag is live now in the docs playground, the MCP server, and the Playwright addon, and it composes with `count` to sweep all four hostile classes in a single batch. extreme mode is available on the Pro plan and above — go point it at your normalisation layer and see what falls out.