@pipeworx/mcp-edge-case-museum 0.1.0 → 0.2.0

package/src/exhibits/unicode/cyrillic-homoglyph-paypal-spoof.json

@@ -1,67 +0,0 @@
-{
-  "id": "cyrillic-homoglyph-paypal-spoof",
-  "title": "\"paypal\" with one Cyrillic letter looks identical and NFKC does not catch it",
-  "category": "unicode",
-  "assumption": "Two strings that render identically are either literally equal, or become equal after Unicode normalization.",
-  "input": {
-    "display": "\"payp\\u0430l\" (Cyrillic \\u0430, CYRILLIC SMALL LETTER A, in place of the fourth letter) vs \"paypal\"",
-    "description": "An impersonation username, support-ticket display name, or phishing domain label built by swapping one Latin letter for a visually identical letter from another script."
-  },
-  "what_goes_wrong": "The spoofed string has the same length as the real word and looks the same in most fonts, but == and a database UNIQUE constraint treat it as a different value, and NFKC normalization leaves it unchanged, so it does not merge with the real spelling.",
-  "why": "Unicode gives Cyrillic \\u0430 and Latin \"a\" separate code points because they are different letters in different scripts, even though most fonts draw them the same; UTS #39's confusables data lists exactly this kind of pair. Normalization (NFC, NFKC) only replaces a character with an equivalent that Unicode's decomposition data declares, such as a ligature, a fullwidth form or a superscript; there is no such mapping from Cyrillic \\u0430 to Latin a, so NFKC leaves the lookalike in place. UTS #39 provides the checks that catch it: comparing \"skeletons\" built from confusables.txt (which maps \\u0430 to a), or mixed-script detection, which flags a single word that mixes Latin and Cyrillic letters.",
-  "affects": [
-    "python",
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import unicodedata\na = \"paypal\"\nb = \"payp\\u0430l\"\nprint(a == b, len(a), len(b))\nprint(unicodedata.normalize(\"NFKC\", a) == unicodedata.normalize(\"NFKC\", b))\nprint([hex(ord(c)) for c in b])\n",
-      "expected_output": "False 6 6\nFalse\n['0x70', '0x61', '0x79', '0x70', '0x430', '0x6c']",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const a = \"paypal\";\nconst b = \"payp\\u0430l\";\nconsole.log(a === b, a.length, b.length);\nconsole.log(a.normalize(\"NFKC\") === b.normalize(\"NFKC\"));\n",
-      "expected_output": "false 6 6\nfalse",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "For security-sensitive comparisons (brand names, support impersonation, domain labels), run Unicode's confusables skeleton algorithm (UTS #39) in addition to normalization, or restrict the field to a single script/ASCII where the context allows it, rather than trusting that normalization catches lookalikes.",
-  "related": [
-    "zero-width-space-username",
-    "fullwidth-bypasses-keyword-filter"
-  ],
-  "sources": [
-    {
-      "title": "UTS #39: Unicode Security Mechanisms, Confusable Detection",
-      "url": "https://www.unicode.org/reports/tr39/#Confusable_Detection"
-    },
-    {
-      "title": "UTS #39: Mixed-Script Detection",
-      "url": "https://www.unicode.org/reports/tr39/#Mixed_Script_Detection"
-    },
-    {
-      "title": "confusables.txt",
-      "url": "https://www.unicode.org/Public/security/latest/confusables.txt"
-    }
-  ],
-  "tags": [
-    "username",
-    "uniqueness",
-    "security",
-    "login",
-    "validation",
-    "i18n"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "paypal",
-        "paypаl"
-      ],
-      "relation": "equal",
-      "note": "A confusable-aware key for impersonation checks (for example the UTS #39 skeleton) should map both strings to the same key. Plain equality and NFKC both say they differ, which is the gap."
-    }
-  ]
-}

package/src/exhibits/unicode/fullwidth-bypasses-keyword-filter.json

@@ -1,61 +0,0 @@
-{
-  "id": "fullwidth-bypasses-keyword-filter",
-  "title": "A fullwidth \"select\" slips past a keyword filter, then reappears as literal \"select\" after normalization",
-  "category": "unicode",
-  "assumption": "If a blocklist check on the raw input says a dangerous keyword isn't present, it isn't present anywhere downstream either.",
-  "input": {
-    "display": "\"\\uff53\\uff45\\uff4c\\uff45\\uff43\\uff54\" (FULLWIDTH LATIN letters spelling \"select\")",
-    "description": "User input containing a blocked keyword spelled with fullwidth Unicode letters (common in East Asian input methods, and a known WAF/filter-bypass technique), which is later normalized for display or by a downstream system/collation before being used."
-  },
-  "what_goes_wrong": "\"select\" in payload.lower() is False on the raw fullwidth string, so a naive keyword blocklist lets it through. Once the same string is NFKC-normalized (for display, by a second validation layer, or by a downstream service), it becomes the literal ASCII word \"select\", and the keyword the filter was supposed to catch is present after all. Some database collations also compare fullwidth and ASCII letters as equal without changing the stored text.",
-  "why": "FULLWIDTH LATIN SMALL LETTER <X> code points (U+FF41-U+FF5A) are compatibility characters: Unicode's own decomposition mapping, used by NFKC, defines each one as equivalent to its ordinary ASCII letter, specifically so systems that care about the abstract text (rather than its East-Asian-typesetting width) can fold them together. A substring/equality check on the un-normalized string sees entirely different code points and finds no match; the moment anything in the pipeline normalizes before the keyword check runs, the two representations become the same string. This is why normalize-then-validate is safe and validate-then-normalize is not — order matters.",
-  "affects": [
-    "python",
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import unicodedata\npayload = \"\\uff53\\uff45\\uff4c\\uff45\\uff43\\uff54\"\nprint(\"select\" in payload.lower())\nnormalized = unicodedata.normalize(\"NFKC\", payload)\nprint(normalized, \"select\" in normalized.lower())\n",
-      "expected_output": "False\nselect True",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const payload = \"\\uff53\\uff45\\uff4c\\uff45\\uff43\\uff54\";\nconsole.log(payload.toLowerCase().includes(\"select\"));\nconst normalized = payload.normalize(\"NFKC\");\nconsole.log(normalized, normalized.toLowerCase().includes(\"select\"));\n",
-      "expected_output": "false\nselect true",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Normalize (NFKC) untrusted text BEFORE running any keyword, blocklist, or validation check against it, never after. If anything later in the pipeline normalizes or compares width-insensitively (a display layer, another service, a database collation), the filter in front of it must assume the same folding. Keyword blocklists are a weak defence against injection anyway; parameterized queries are the real fix for SQL.",
-  "related": [
-    "nfkc-compatibility-folding",
-    "cyrillic-homoglyph-paypal-spoof"
-  ],
-  "sources": [
-    {
-      "title": "Unicode Standard Annex #15: Unicode Normalization Forms (NFKC)",
-      "url": "https://www.unicode.org/reports/tr15/"
-    },
-    {
-      "title": "Unicode Technical Standard #39: Unicode Security Mechanisms",
-      "url": "https://www.unicode.org/reports/tr39/"
-    }
-  ],
-  "tags": [
-    "security",
-    "validation",
-    "normalization",
-    "parsing",
-    "forms"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "ｓｅｌｅｃｔ"
-      ],
-      "relation": "no_crash",
-      "note": "A keyword blocklist must reject this string if it would reject \"select\" after any normalization step anywhere later in the system — check both forms, or normalize first."
-    }
-  ]
-}

package/src/exhibits/unicode/german-eszett-case-fold.json

@@ -1,72 +0,0 @@
-{
-  "id": "german-eszett-case-fold",
-  "title": "\"STRASSE\".lower() is not \"straße\" — uppercasing and lowercasing aren't inverses",
-  "category": "unicode",
-  "assumption": "If a.upper() == b, then a == b.lower().",
-  "input": {
-    "display": "\"stra\\u00dfe\" (German for \"street\", with ß U+00DF) vs \"STRASSE\"",
-    "description": "A German street name or surname containing ß, compared against an all-caps form from a passport, an old database export, or a form that forces uppercase input."
-  },
-  "what_goes_wrong": "\"stra\\u00dfe\".upper() correctly equals \"STRASSE\", but \"STRASSE\".lower() comes back as \"strasse\", not \"stra\\u00dfe\" — so the round trip breaks and a plain .lower()-keyed uniqueness check treats the two spellings as different strings.",
-  "why": "Unicode's default full uppercase mapping of ß is the two letters \"SS\" (a capital ẞ, U+1E9E, exists but is not the default mapping), which is why \"stra\\u00dfe\".upper() == \"STRASSE\" and why this case operation changes string length. The mapping only goes one way: lowercasing \"SS\" gives \"ss\", because plenty of words have a real double s. Python's str.casefold() (added in Python 3.3) applies Unicode case folding, which maps ß to \"ss\", so casefold() == casefold() succeeds where lower() == lower() fails. JavaScript has no casefold(); toLowerCase() and toUpperCase() show the same asymmetry, and the built-in caseless comparison is Intl.Collator or localeCompare with sensitivity \"base\", which treats \"straße\" and \"STRASSE\" as equal.",
-  "affects": [
-    "python",
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "a = \"STRASSE\"\nb = \"stra\\u00dfe\"\nprint(b.upper() == a, a.lower() == b)\nprint(a.casefold() == b.casefold())\nprint(\"\\u00df\".upper(), len(\"\\u00df\".upper()))\n",
-      "expected_output": "True False\nTrue\nSS 2",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const a = \"STRASSE\";\nconst b = \"stra\\u00dfe\";\nconsole.log(b.toUpperCase() === a, a.toLowerCase() === b);\nconsole.log(\"\\u00df\".toUpperCase(), \"\\u00df\".toUpperCase().length);\n",
-      "expected_output": "true false\nSS 2",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "For caseless comparison, use Python's str.casefold() rather than str.lower(). In JavaScript, compare with new Intl.Collator(undefined, { sensitivity: \"base\" }).compare(a, b) === 0 (note that \"base\" also ignores accents), or normalize ß to \"ss\" explicitly before comparing. For stored uniqueness keys, also normalize (NFKC or NFC) before folding.",
-  "related": [
-    "turkish-dotless-i-case-mapping",
-    "greek-final-sigma-casefold"
-  ],
-  "sources": [
-    {
-      "title": "Unicode Standard: SpecialCasing.txt (ß → SS uppercase mapping)",
-      "url": "https://www.unicode.org/Public/UCD/latest/ucd/SpecialCasing.txt"
-    },
-    {
-      "title": "Python docs: str.casefold",
-      "url": "https://docs.python.org/3/library/stdtypes.html#str.casefold"
-    },
-    {
-      "title": "Unicode Technical Standard #10 / TR21: Case Mappings",
-      "url": "https://www.unicode.org/notes/tn21/"
-    },
-    {
-      "title": "MDN: Intl.Collator() constructor, sensitivity option",
-      "url": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Collator/Collator"
-    }
-  ],
-  "tags": [
-    "username",
-    "uniqueness",
-    "login",
-    "addresses",
-    "i18n",
-    "validation",
-    "comparison"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "STRASSE",
-        "straße"
-      ],
-      "relation": "equal",
-      "note": "A caseless-match key should map both to the same value (Python's casefold() does; lower() does not)."
-    }
-  ]
-}

package/src/exhibits/unicode/grapheme-vs-codepoint-length.json

@@ -1,57 +0,0 @@
-{
-  "id": "grapheme-vs-codepoint-length",
-  "title": "One family emoji, three different \"lengths\": 1, 5, and 8",
-  "category": "unicode",
-  "assumption": "A string's length property tells you how many characters a person sees on screen.",
-  "input": {
-    "display": "\"\\u{1F468}\\u200D\\u{1F469}\\u200D\\u{1F467}\" (man + ZWJ + woman + ZWJ + girl = one family emoji)",
-    "description": "Any emoji picker's \"family\"/\"couple with heart\"/skin-tone-modified emoji, typed into a bio, nickname, or chat message with a character-count limit."
-  },
-  "what_goes_wrong": "The single glyph a user sees as ONE character reports length 8 in JavaScript's .length, 5 via JavaScript's [...s].length or Python's len(), and 1 via JavaScript's Intl.Segmenter grapheme count. A \"max 10 characters\" bio limit enforced with .length rejects two family emoji (16 code units) that the user sees as two characters, and truncating by any of the non-grapheme measures can cut the glyph apart (see the truncation exhibits).",
-  "why": "JavaScript strings are sequences of UTF-16 code units, and .length counts those units; each of the three emoji here is outside the Basic Multilingual Plane, so it needs a surrogate pair (2 code units), giving 3×2 + 2 ZWJ = 8. Python strings are sequences of Unicode code points, and len() counts those; the same string is 3 emoji + 2 ZWJ = 5 code points (the spread operator [...s] in JavaScript iterates by code point too, also giving 5). But a person perceives the whole ZWJ-joined sequence as a single \"grapheme cluster\" — exactly one visual unit — which is what JavaScript's Intl.Segmenter({granularity: \"grapheme\"}) counts, and what Python's standard library has no built-in equivalent for.",
-  "affects": [
-    "python",
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "s = \"\\U0001F468\\u200D\\U0001F469\\u200D\\U0001F467\"\nprint(len(s))\n",
-      "expected_output": "5",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const s = \"\\u{1F468}\\u200D\\u{1F469}\\u200D\\u{1F467}\";\nconsole.log(s.length);\nconsole.log([...s].length);\nconst seg = new Intl.Segmenter(\"en\", { granularity: \"grapheme\" });\nconsole.log([...seg.segment(s)].length);\n",
-      "expected_output": "8\n5\n1",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Enforce user-facing length limits with a grapheme-cluster counter, not raw .length/len(). In JavaScript use Intl.Segmenter (built in, no dependency); Python's standard library has no grapheme-cluster segmenter, so either accept code-point length as an approximation (it undercounts far less often than UTF-16 length) or add a UAX #29-compliant library.",
-  "related": [
-    "truncation-splits-surrogate-pair",
-    "zalgo-combining-mark-stacking"
-  ],
-  "sources": [
-    {
-      "title": "Unicode Standard Annex #29: Unicode Text Segmentation (grapheme clusters)",
-      "url": "https://www.unicode.org/reports/tr29/"
-    },
-    {
-      "title": "MDN: Intl.Segmenter",
-      "url": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Segmenter"
-    },
-    {
-      "title": "Unicode Emoji ZWJ Sequences",
-      "url": "https://www.unicode.org/Public/emoji/latest/emoji-zwj-sequences.txt"
-    }
-  ],
-  "tags": [
-    "length validation",
-    "forms",
-    "display",
-    "truncation",
-    "i18n",
-    "validation"
-  ]
-}

package/src/exhibits/unicode/greek-final-sigma-casefold.json

@@ -1,54 +0,0 @@
-{
-  "id": "greek-final-sigma-casefold",
-  "title": "lower() and casefold() disagree on the same Greek word",
-  "category": "unicode",
-  "assumption": "casefold() is just a more aggressive lower(), so it can only make more strings equal, never fewer, and never disagree with lower() about how to spell an individual word.",
-  "input": {
-    "display": "\"\\u039f\\u0394\\u03a5\\u03a3\\u03a3\\u0395\\u03a5\\u03a3\" (Greek \"ODYSSEUS\", all-capital sigma \\u03a3)",
-    "description": "Comparing a Greek name typed in all caps against its lowercase spelling, or canonicalizing Greek text for a search index."
-  },
-  "what_goes_wrong": "word.lower() produces \"\\u03bf\\u03b4\\u03c5\\u03c3\\u03c3\\u03b5\\u03c5\\u03c2\" (ending in final sigma \\u03c2, the form Greek orthography requires at the end of a word), but word.casefold() produces \"\\u03bf\\u03b4\\u03c5\\u03c3\\u03c3\\u03b5\\u03c5\\u03c3\" (ending in plain sigma \\u03c3) — two different strings from the exact same input, so lower() == casefold() is False for this word.",
-  "why": "Greek has two lowercase forms of sigma: \\u03c3 inside a word and \\u03c2 at the end of a word. Python's str.lower() applies the Final_Sigma rule from SpecialCasing.txt, a context condition (the sigma follows a cased letter and is not followed by one) that picks \\u03c2 for the last letter here. str.casefold() exists for caseless MATCHING and uses CaseFolding.txt, which maps \\u03a3, \\u03c3 and \\u03c2 all to \\u03c3 with no context, so that words differing only in sigma form compare equal. JavaScript has no casefold(), so it has no built-in way to show this disagreement; its toLowerCase() applies the same Final_Sigma rule and matches Python's lower().",
-  "affects": [
-    "python"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "word = \"\\u039f\\u0394\\u03a5\\u03a3\\u03a3\\u0395\\u03a5\\u03a3\"\nprint(word.lower())\nprint(word.casefold())\nprint(word.lower() == word.casefold())\n",
-      "expected_output": "οδυσσευς\nοδυσσευσ\nFalse",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const word = \"\\u039f\\u0394\\u03a5\\u03a3\\u03a3\\u0395\\u03a5\\u03a3\";\nconsole.log(word.toLowerCase());\n",
-      "expected_output": "οδυσσευς",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Do not assume casefold() is a strict superset of lower()'s equalities, or that it preserves orthographic rules — it is only guaranteed to make caseless comparison consistent, not to produce \"correctly spelled\" lowercase text. For display, use lower(); for comparison, use casefold(); never mix the two results together or assert they're interchangeable.",
-  "related": [
-    "german-eszett-case-fold"
-  ],
-  "sources": [
-    {
-      "title": "Unicode Standard: SpecialCasing.txt (Greek final sigma rule)",
-      "url": "https://www.unicode.org/Public/UCD/latest/ucd/SpecialCasing.txt"
-    },
-    {
-      "title": "Unicode Standard: CaseFolding.txt",
-      "url": "https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt"
-    },
-    {
-      "title": "Python docs: str.casefold",
-      "url": "https://docs.python.org/3/library/stdtypes.html#str.casefold"
-    }
-  ],
-  "tags": [
-    "comparison",
-    "sorting",
-    "i18n",
-    "normalization",
-    "search"
-  ]
-}

package/src/exhibits/unicode/js-word-regex-ascii-only.json

@@ -1,64 +0,0 @@
-{
-  "id": "js-word-regex-ascii-only",
-  "title": "The same regex \\w+ accepts \"café\" in Python and rejects it in JavaScript",
-  "category": "unicode",
-  "assumption": "\\w in a regex means \"letters\", in whichever language you're running it, maybe with an extra flag for Unicode.",
-  "input": {
-    "display": "/^\\w+$/ applied to \"caf\\u00e9\" and to \"\\u65e5\\u672c\\u8a9e\" (Japanese for \"Japanese language\")",
-    "description": "A \"letters and numbers only\" validator applied to a name field, reused as-is between a Python backend and a JavaScript frontend."
-  },
-  "what_goes_wrong": "Python's re.fullmatch(r\"\\w+\", \"caf\\u00e9\") matches, and even matches \"\\u65e5\\u672c\\u8a9e\". The textually identical /^\\w+$/ in JavaScript rejects both — and adding the /u (Unicode) flag, which people reach for specifically to fix Unicode regex problems, does not change the result at all.",
-  "why": "In JavaScript, \\w is defined by the ECMAScript spec as the ASCII class [A-Za-z0-9_]. The u flag does not turn it into a Unicode letter class; the only change is that with both u and i set it also matches U+017F (long s) and U+212A (Kelvin sign), because they case-fold to s and k. To match non-ASCII letters in JavaScript you need a Unicode property escape such as \\p{L}, which requires the u (or v) flag. Python's re module makes \\w Unicode-aware by default for str patterns (letters, digits and underscore in the Unicode sense) unless you pass re.ASCII. Same regex syntax, opposite default behaviour.",
-  "affects": [
-    "python",
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import re\nprint(bool(re.fullmatch(r\"\\w+\", \"caf\\u00e9\")))\nprint(bool(re.fullmatch(r\"\\w+\", \"\\u65e5\\u672c\\u8a9e\")))\nprint(bool(re.fullmatch(r\"\\w+\", \"caf\\u00e9\", re.ASCII)))\n",
-      "expected_output": "True\nTrue\nFalse",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const name = \"caf\\u00e9\";\nconsole.log(/^\\w+$/.test(name), /^\\w+$/u.test(name));\nconsole.log(/^[\\p{L}]+$/u.test(name));\nconst name2 = \"\\u65e5\\u672c\\u8a9e\";\nconsole.log(/^\\w+$/.test(name2), /^[\\p{L}]+$/u.test(name2));\n",
-      "expected_output": "false false\ntrue\nfalse true",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Never port a \\w-based regex between Python and JavaScript expecting matching behavior. In JavaScript, use /^[\\p{L}\\p{N}_]+$/u for a Unicode-aware \"word characters\" check; in Python, pass re.ASCII explicitly if you actually want \\w restricted to [A-Za-z0-9_].",
-  "related": [
-    "arabic-indic-digit-parses"
-  ],
-  "sources": [
-    {
-      "title": "ECMA-262: RegExp \\w class definition (CharacterClassEscape)",
-      "url": "https://tc39.es/ecma262/#sec-characterclassescape"
-    },
-    {
-      "title": "MDN: Unicode property escapes",
-      "url": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions/Unicode_character_class_escape"
-    },
-    {
-      "title": "Python docs: re module, \\w and re.ASCII",
-      "url": "https://docs.python.org/3/library/re.html#re.ASCII"
-    }
-  ],
-  "tags": [
-    "validation",
-    "forms",
-    "parsing",
-    "names",
-    "i18n"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "café"
-      ],
-      "relation": "no_crash",
-      "note": "A \"letters and numbers only\" validator ported between a Python backend and a JS frontend must not accept this on one side and reject it on the other."
-    }
-  ]
-}

package/src/exhibits/unicode/nfc-nfd-same-name-two-accounts.json

@@ -1,70 +0,0 @@
-{
-  "id": "nfc-nfd-same-name-two-accounts",
-  "title": "Two usernames that look identical, compare unequal, and both register",
-  "category": "unicode",
-  "assumption": "If two strings render the same, they are the same string.",
-  "input": {
-    "display": "\"Jos\\u00e9\" (precomposed é, 4 code points) vs \"Jose\\u0301\" (e + combining acute, 5 code points)",
-    "description": "The same visible name typed on two different systems: macOS file APIs and some keyboards produce the decomposed form, most web forms produce the precomposed form."
-  },
-  "what_goes_wrong": "A uniqueness check with == or a plain UNIQUE index lets both through, so two accounts share one visible name.",
-  "why": "Unicode allows the same abstract character to be encoded either as one precomposed code point (U+00E9) or as a base letter plus a combining mark (U+0065 U+0301). The two sequences are canonically equivalent, so every renderer draws them identically, but their code points differ and every byte- or code-point comparison says they are different. Normalizing both sides to the same form (NFC or NFD) before comparing or storing makes them equal.",
-  "affects": [
-    "python",
-    "javascript",
-    "postgres",
-    "mysql",
-    "any byte-wise comparison"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import unicodedata\na = \"Jos\\u00e9\"\nb = \"Jose\\u0301\"\nprint(a == b, len(a), len(b))\nprint(unicodedata.normalize(\"NFC\", a) == unicodedata.normalize(\"NFC\", b))\n",
-      "expected_output": "False 4 5\nTrue",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const a = \"Jos\\u00e9\";\nconst b = \"Jose\\u0301\";\nconsole.log(a === b, a.length, b.length);\nconsole.log(a.normalize(\"NFC\") === b.normalize(\"NFC\"));\n",
-      "expected_output": "false 4 5\ntrue",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Normalize to NFC (or NFKC for identifiers, which also folds compatibility forms) at the boundary where the value enters your system, and store the normalized form; compare normalized forms only.",
-  "related": [],
-  "sources": [
-    {
-      "title": "Unicode Standard Annex #15: Unicode Normalization Forms",
-      "url": "https://www.unicode.org/reports/tr15/"
-    },
-    {
-      "title": "Python docs: unicodedata.normalize",
-      "url": "https://docs.python.org/3/library/unicodedata.html#unicodedata.normalize"
-    },
-    {
-      "title": "MDN: String.prototype.normalize()",
-      "url": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/normalize"
-    }
-  ],
-  "tags": [
-    "username",
-    "uniqueness",
-    "login",
-    "normalization",
-    "nfc",
-    "nfd",
-    "unicode",
-    "string comparison",
-    "database unique index"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "José",
-        "José"
-      ],
-      "relation": "equal",
-      "note": "Your username canonicalizer should map both spellings to the same key."
-    }
-  ]
-}

package/src/exhibits/unicode/nfkc-compatibility-folding.json

@@ -1,63 +0,0 @@
-{
-  "id": "nfkc-compatibility-folding",
-  "title": "A superscript \"\\u00b2\" says isdigit() but int() refuses it",
-  "category": "unicode",
-  "assumption": "If isdigit() returns True (or a /\\d/ regex matches), the value is safe to pass to a numeric parser.",
-  "input": {
-    "display": "\"\\u00b2\" (SUPERSCRIPT TWO, U+00B2), fullwidth \"\\uff46\\uff4f\\uff4f\" (\"foo\"), ligature \"\\ufb01le\" (\"file\")",
-    "description": "Fullwidth letters pasted from CJK input methods, a superscript exponent copied from a web page into a quantity field, or a ligature character from a PDF copy-paste landing in a filename or search box."
-  },
-  "what_goes_wrong": "\"\\u00b2\".isdigit() is True, but int(\"\\u00b2\") raises ValueError; meanwhile fullwidth \"\\uff46\\uff4f\\uff4f\" does not equal \"foo\" and the 3-character ligature \"\\ufb01le\" has length 4 after normalization even though no character was literally inserted.",
-  "why": "Python's str.isdigit() is true for any character whose Numeric_Type is Digit or Decimal, which includes superscript and subscript digits, but int() only accepts Numeric_Type=Decimal (General_Category Nd) characters, so isdigit() cannot predict whether int() will succeed; str.isdecimal() is the check that matches int(). NFKC (UAX #15) replaces compatibility characters, such as fullwidth letters, ligatures and superscripts, with their ordinary equivalents, which is why NFKC turns \"\\u00b2\" into \"2\" and makes the fullwidth string equal \"foo\". It does not fix every case: ETHIOPIC DIGIT ONE (U+1369) is isdigit() but not isdecimal(), has no compatibility decomposition, and still fails int() after NFKC. A single compatibility character can also expand: \"\\ufb01\" (the fi ligature) becomes two letters, so the 3-code-point \"\\ufb01le\" normalizes to 4.",
-  "affects": [
-    "python",
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import unicodedata\nsup = \"\\u00b2\"\nprint(sup.isdigit(), sup.isdecimal())\ntry:\n    int(sup)\nexcept ValueError as e:\n    print(\"ValueError\")\nn = unicodedata.normalize(\"NFKC\", sup)\nprint(n, n.isdecimal(), int(n))\n\nfullwidth = \"\\uff46\\uff4f\\uff4f\"\nprint(fullwidth == \"foo\", unicodedata.normalize(\"NFKC\", fullwidth) == \"foo\")\n\nlig = \"\\ufb01le\"\nprint(len(lig), len(unicodedata.normalize(\"NFKC\", lig)))\n",
-      "expected_output": "True False\nValueError\n2 True 2\nFalse True\n3 4",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const sup = \"\\u00b2\";\nconsole.log(/^\\d+$/.test(sup), Number(sup));\nconst n = sup.normalize(\"NFKC\");\nconsole.log(n, /^\\d+$/.test(n), Number(n));\n\nconst fullwidth = \"\\uff46\\uff4f\\uff4f\";\nconsole.log(fullwidth === \"foo\", fullwidth.normalize(\"NFKC\") === \"foo\");\n\nconst lig = \"\\ufb01le\";\nconsole.log(lig.length, lig.normalize(\"NFKC\").length);\n",
-      "expected_output": "false NaN\n2 true 2\nfalse true\n3 4",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Normalize untrusted text with NFKC at the input boundary before validating it as an identifier, filename, or number, and when checking \"is this parseable as an integer\" use str.isdecimal() in Python (not isdigit()) or attempt-and-catch the parse — never trust isdigit()/regex \\d alone to predict int()/Number() success.",
-  "related": [
-    "arabic-indic-digit-parses",
-    "fullwidth-bypasses-keyword-filter",
-    "nfc-nfd-same-name-two-accounts"
-  ],
-  "sources": [
-    {
-      "title": "Unicode Standard Annex #15: Unicode Normalization Forms (NFKC)",
-      "url": "https://www.unicode.org/reports/tr15/"
-    },
-    {
-      "title": "Python docs: str.isdigit / str.isdecimal",
-      "url": "https://docs.python.org/3/library/stdtypes.html#str.isdigit"
-    }
-  ],
-  "tags": [
-    "username",
-    "validation",
-    "normalization",
-    "parsing",
-    "length validation",
-    "forms"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "²"
-      ],
-      "relation": "raises",
-      "note": "A strict integer parser should reject this (Python's int() raises ValueError) even though isdigit() returns True; validate with isdecimal() or attempt-and-catch, or NFKC-normalize first if you intend to accept it as 2."
-    }
-  ]
-}

package/src/exhibits/unicode/truncation-orphans-combining-mark.json

@@ -1,62 +0,0 @@
-{
-  "id": "truncation-orphans-combining-mark",
-  "title": "\"Take the last character of the name\" for an avatar initial can return a bare accent mark",
-  "category": "unicode",
-  "assumption": "The last character of a person's name is always a letter you can use as an initial.",
-  "input": {
-    "display": "\"Jose\\u0301\" (decomposed \\u00e9: \"e\" + COMBINING ACUTE ACCENT, 5 code points) and name[-1] / name.slice(-1)",
-    "description": "Generating a one-letter avatar/initial from a user's display name by taking its first or last character, where the name arrived in decomposed (NFD) form from a different system or keyboard."
-  },
-  "what_goes_wrong": "name[-1] (Python) and name.slice(-1) (JavaScript) both return a single COMBINING ACUTE ACCENT by itself — not the letter \"e\" or the letter \"\\u00e9\" a person would expect — because in a decomposed string the accent is its own trailing code point. The result is not even classified as a letter.",
-  "why": "Unicode represents an accented letter either as one precomposed code point (U+00E9) or as a base letter followed by a separate combining mark (U+0065 U+0301). A combining mark always comes AFTER the base character it modifies, so taking the last code point (Python) or code unit (JavaScript) of a decomposed string can return the mark alone. That isolated mark has General Category Mn (\"Mark, nonspacing\"), not a letter category, which is why isalpha() and \\p{L} both reject it. Shown on its own it has no base to attach to; depending on the renderer it appears floating over nothing, over a dotted-circle placeholder, or attached to whatever text precedes it.",
-  "affects": [
-    "python",
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import unicodedata\nname = \"Jose\\u0301\"\ninitial = name[-1]\nprint(name, len(name))\nprint(repr(initial), initial.isalpha(), unicodedata.category(initial))\n",
-      "expected_output": "José 5\n'́' False Mn",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const name = \"Jose\\u0301\";\nconst initial = name.slice(-1);\nconsole.log(name, name.length);\nconsole.log(JSON.stringify(initial), /\\p{L}/u.test(initial));\n",
-      "expected_output": "José 5\n\"́\" false",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Normalize to NFC before taking a single character for display (so the accent recombines into one code point with its base), or better, take the first/last grapheme cluster (Intl.Segmenter in JS) rather than the first/last code point/code unit.",
-  "related": [
-    "grapheme-vs-codepoint-length",
-    "nfc-nfd-same-name-two-accounts",
-    "truncation-splits-surrogate-pair"
-  ],
-  "sources": [
-    {
-      "title": "Unicode Standard Annex #15: Unicode Normalization Forms",
-      "url": "https://www.unicode.org/reports/tr15/"
-    },
-    {
-      "title": "Unicode Technical Report #44: General Category values (Mn)",
-      "url": "https://www.unicode.org/reports/tr44/#General_Category_Values"
-    }
-  ],
-  "tags": [
-    "names",
-    "display",
-    "truncation",
-    "normalization",
-    "i18n"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "José"
-      ],
-      "relation": "no_crash",
-      "note": "An avatar-initial function should not return an isolated combining mark for this (valid, real-world) decomposed name."
-    }
-  ]
-}