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

package/src/exhibits/integers/parseint-stops-at-first-invalid-char-vs-number.json

@@ -1,58 +0,0 @@
-{
-  "id": "parseint-stops-at-first-invalid-char-vs-number",
-  "title": "parseInt(\"1e3\") is 1, but Number(\"1e3\") is 1000",
-  "category": "integers",
-  "assumption": "parseInt and Number agree on what a numeric string means; parseInt is just 'the integer version'.",
-  "input": {
-    "display": "parseInt(\"1e3\") === 1  while  Number(\"1e3\") === 1000",
-    "description": "Converting a user-entered or CSV-sourced numeric string that happens to be in scientific notation (common in spreadsheet exports of large or small numbers)."
-  },
-  "what_goes_wrong": "Switching a 'parse this numeric string' call from `Number()` to `parseInt()` (e.g. 'because I want an integer') silently truncates any value written in scientific notation to just its leading digit, turning 1000 into 1 with no error.",
-  "why": "`parseInt` parses a string by reading characters strictly left to right and stopping at the first character that cannot extend a valid integer literal in the given radix -- it has no concept of an exponent, so it stops at the \"e\". `Number()` instead parses the whole string against ECMA-262's StringNumericLiteral grammar (similar to, but not the same as, source-code numeric literals: it allows surrounding whitespace and \"Infinity\", and rejects numeric separators and the `n` BigInt suffix), which does understand exponents, so it parses \"1e3\" as 1 * 10^3 = 1000. The two are not interchangeable string-to-number converters.",
-  "affects": [
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "javascript",
-      "code": "console.log(parseInt(\"1e3\"), Number(\"1e3\"));\nconsole.log(parseInt(\"3.14\"), Number(\"3.14\"));\nconsole.log(parseInt(\"1,000\"), Number(\"1,000\"));\n",
-      "expected_output": "1 1000\n3 3.14\n1 NaN",
-      "verified_with": "Node.js v22.22.2"
-    },
-    {
-      "language": "python",
-      "code": "# Python's int() rejects scientific notation strings outright rather than truncating.\ntry:\n    int(\"1e3\")\nexcept ValueError as e:\n    print(\"int('1e3') ValueError:\", e)\nprint(float(\"1e3\"))  # the float constructor does understand exponents\n",
-      "expected_output": "int('1e3') ValueError: invalid literal for int() with base 10: '1e3'\n1000.0",
-      "verified_with": "Python 3.14.2"
-    }
-  ],
-  "fix": "Use `Number()` (and then validate/round) to parse a numeric string that might contain an exponent, decimals, or thousands separators; reserve `parseInt` for strings you know are plain digit sequences in a known radix.",
-  "related": [
-    "parseint-number-argument-scientific-notation",
-    "parseint-null-radix36-digit-soup"
-  ],
-  "sources": [
-    {
-      "title": "MDN: parseInt()",
-      "url": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt"
-    },
-    {
-      "title": "ECMA-262: ToNumber applied to the String type",
-      "url": "https://tc39.es/ecma262/#sec-tonumber-applied-to-the-string-type"
-    }
-  ],
-  "tags": [
-    "parsing",
-    "validation",
-    "csv"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "1e3"
-      ],
-      "relation": "no_crash",
-      "note": "Decide explicitly whether a numeric-string parser should understand scientific notation; don't silently truncate at the exponent."
-    }
-  ]
-}

package/src/exhibits/integers/python-int-accepts-fullwidth-unicode-digits.json

@@ -1,56 +0,0 @@
-{
-  "id": "python-int-accepts-fullwidth-unicode-digits",
-  "title": "int(\"４２\") works -- those are fullwidth Unicode digits, not the ASCII characters they look like",
-  "category": "integers",
-  "assumption": "int() only accepts the ASCII digits 0-9.",
-  "input": {
-    "display": "int(\"\\uff14\\uff12\") == 42  (U+FF14 FULLWIDTH DIGIT FOUR, U+FF12 FULLWIDTH DIGIT TWO)",
-    "description": "User input copy-pasted from a source using fullwidth characters (common in East Asian text contexts, or a sneaky/naughty-string test input), or any other Unicode script's decimal digits (Arabic-Indic, Devanagari, etc.) submitted to a form field."
-  },
-  "what_goes_wrong": "A validator that checks `s.isdigit()` or `re.fullmatch(r'\\d+', s)` and then calls `int(s)` happily accepts fullwidth, Arabic-Indic, Devanagari and other Unicode digits (both checks are Unicode-aware for str), while a check anchored to `[0-9]` rejects the same input that `int()` would accept -- so two layers of the same form can disagree about what a number is.",
-  "why": "Python's `int()` (and `float()`) accepts any character with the Unicode general category Nd ('decimal digit'), which covers fullwidth forms (U+FF10-FF19), Arabic-Indic, Devanagari and dozens of other scripts' 0-9, and maps each to its decimal value; it also strips any Unicode whitespace around the number. This is documented, deliberate internationalisation in the string-to-number conversion, not in the language's source parser: `x = ４２` in source code is a SyntaxError. Python's regex `\\d` is likewise Unicode-aware for str patterns unless you pass `re.ASCII`. And the sets do not line up: `'²'.isdigit()` is True for superscript two, but it is not Nd, so `int('²')` raises.",
-  "affects": [
-    "python"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import re\nfullwidth = \"\\uff14\\uff12\"  # looks like \"42\"\nprint(repr(fullwidth), \"->\", int(fullwidth))\nprint(\"matches [0-9]+:\", bool(re.fullmatch(r\"[0-9]+\", fullwidth)))\nprint(\"matches \\\\d+:\", bool(re.fullmatch(r\"\\d+\", fullwidth)), \"| with re.ASCII:\", bool(re.fullmatch(r\"\\d+\", fullwidth, re.ASCII)))\nsup = \"\\u00b2\"  # SUPERSCRIPT TWO\ntry:\n    int(sup)\nexcept ValueError as e:\n    print(repr(sup), \"isdigit():\", sup.isdigit(), \"| int() ->\", e)",
-      "expected_output": "'４２' -> 42\nmatches [0-9]+: False\nmatches \\d+: True | with re.ASCII: False\n'²' isdigit(): True | int() -> invalid literal for int() with base 10: '²'",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "// Number() and parseInt() do NOT extend digit recognition past ASCII 0-9,\n// so the same fullwidth string fails to parse at all in JavaScript.\nconst fullwidth = \"\\uff14\\uff12\";\nconsole.log(Number(fullwidth), parseInt(fullwidth, 10));\n",
-      "expected_output": "NaN NaN",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "If you need ASCII digits only, say so explicitly: `s.isascii() and s.isdigit()`, `re.fullmatch(r'[0-9]+', s)` or `re.fullmatch(r'\\d+', s, re.ASCII)`, and run `int()` on the same string you validated. If you want to accept other scripts' digits, normalise them deliberately (e.g. `str(int(s))`) before storing or passing the value to systems that only understand ASCII.",
-  "related": [
-    "python-int-accepts-underscores-and-whitespace"
-  ],
-  "sources": [
-    {
-      "title": "Unicode Standard: General Category Values (Nd = Decimal Number)",
-      "url": "https://www.unicode.org/reports/tr44/#General_Category_Values"
-    },
-    {
-      "title": "Python docs: int() constructor",
-      "url": "https://docs.python.org/3/library/functions.html#int"
-    },
-    {
-      "title": "Python docs: numeric types (int/float accept digits with the Unicode Nd property)",
-      "url": "https://docs.python.org/3/library/stdtypes.html#numeric-types-int-float-complex"
-    }
-  ],
-  "tags": [
-    "parsing",
-    "validation",
-    "i18n",
-    "forms",
-    "normalization",
-    "security"
-  ],
-  "test_cases": []
-}

package/src/exhibits/integers/python-int-accepts-underscores-and-whitespace.json

@@ -1,48 +0,0 @@
-{
-  "id": "python-int-accepts-underscores-and-whitespace",
-  "title": "int(\" 42 \") and int(\"1_000\") both just work",
-  "category": "integers",
-  "assumption": "int() only accepts exactly what you could type as an integer literal in source code, with nothing extra around it.",
-  "input": {
-    "display": "int(\" 42 \") == 42;  int(\"1_000\") == 1000",
-    "description": "Converting a number pulled from a config file, environment variable, or user-pasted value that has incidental surrounding whitespace, or a number formatted with underscore thousands-separators (a format Python itself started allowing in source literals in 3.6)."
-  },
-  "what_goes_wrong": "A validation routine that assumes `int()` will reject anything that isn't a bare run of digits lets through both leading/trailing whitespace and underscore-separated digit groups, silently accepting input shapes the developer never intended to allow.",
-  "why": "`int()`'s string-to-integer conversion strips leading and trailing whitespace before parsing, by design, and that means any Unicode whitespace (tabs, newlines, U+3000 IDEOGRAPHIC SPACE), not just spaces. Separately, since Python 3.6 (PEP 515), the integer literal grammar allows a single underscore between digits as a visual separator (`1_000`), and `int()`'s string parsing follows that same grammar, so it accepts underscore-separated digit strings too -- as long as the underscores are singly placed between digits, not leading, trailing, or doubled.",
-  "affects": [
-    "python"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "print(int(\" 42 \"))\nprint(int(\"1_000\"))\ntry:\n    int(\"_1000\")\nexcept ValueError as e:\n    print(\"leading underscore rejected:\", e)\n",
-      "expected_output": "42\n1000\nleading underscore rejected: invalid literal for int() with base 10: '_1000'",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "// Number() also trims surrounding whitespace. JavaScript's numeric separators\n// (1_000, ES2021, the same single-underscore-between-digits rule as Python)\n// exist only in source-code literals, never in string parsing.\nconsole.log(Number(\" 42 \"));       // 42: whitespace is trimmed here too\nconsole.log(Number(\"1_000\"));      // NaN: Number() does not accept separators in strings\nconsole.log(parseInt(\"1_000\"));    // 1: parseInt stops at the underscore\nconsole.log(1_000);                // 1000: but the literal is fine",
-      "expected_output": "42\nNaN\n1\n1000",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Don't assume `int()` validates format as strictly as a literal; if you need to reject whitespace or separators, check the string's shape explicitly (e.g. a regex) before calling `int()`.",
-  "related": [
-    "python-int-accepts-fullwidth-unicode-digits"
-  ],
-  "sources": [
-    {
-      "title": "Python docs: int() constructor",
-      "url": "https://docs.python.org/3/library/functions.html#int"
-    },
-    {
-      "title": "PEP 515 -- Underscores in Numeric Literals",
-      "url": "https://peps.python.org/pep-0515/"
-    }
-  ],
-  "tags": [
-    "parsing",
-    "validation"
-  ],
-  "test_cases": []
-}

package/src/exhibits/integers/python-unbounded-int-vs-fixed-width-wrap.json

@@ -1,49 +0,0 @@
-{
-  "id": "python-unbounded-int-vs-fixed-width-wrap",
-  "title": "Python's int never overflows -- until you explicitly ask for a fixed-width one",
-  "category": "integers",
-  "assumption": "An integer type has some maximum size, and adding to it eventually overflows or errors.",
-  "input": {
-    "display": "struct.pack(\"i\", 2**31) raises; ctypes.c_int32(2**31).value wraps to -2147483648",
-    "description": "Serializing a Python int into a fixed-width binary format (a network protocol, a C-compatible struct, a file format) where the field is a 32-bit signed integer, after the value has grown past what that field can hold."
-  },
-  "what_goes_wrong": "Code that works fine for years because Python's `int` just keeps growing starts failing (or, worse, silently wraps to a negative number) the moment that same value has to be packed into a fixed-width field for serialization, networking, or C interop -- and which of those two happens depends entirely on which API you used to do the packing.",
-  "why": "Python's built-in `int` is arbitrary-precision: it has no fixed bit width and never overflows on its own. Fixed-width behavior only appears when you explicitly convert to one -- `struct.pack` with a format like `\"i\"` (the platform's C `int`, signed 32-bit on all mainstream platforms) validates the range and raises `struct.error` if the value doesn't fit, while `ctypes.c_int32` instead performs a real two's-complement modulo-2^32 wraparound, silently producing a negative value with no error at all. The two standard-library tools for 'give this a fixed width' disagree on whether out-of-range is an error or a wraparound.",
-  "affects": [
-    "python"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import struct\nimport ctypes\n\ntry:\n    struct.pack(\"i\", 2**31)\nexcept struct.error as e:\n    print(\"struct.pack raises:\", e)\n\nprint(\"ctypes.c_int32 wraps silently:\", ctypes.c_int32(2**31).value)\nprint(\"plain python int, unaffected:\", 2**31)\n",
-      "expected_output": "struct.pack raises: 'i' format requires -2147483648 <= number <= 2147483647\nctypes.c_int32 wraps silently: -2147483648\nplain python int, unaffected: 2147483648",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "// JS has no arbitrary-precision integer type by default (Number is a double),\n// but a typed array shows the same silent-wrap behavior as ctypes.c_int32.\nconst a = new Int32Array(1);\na[0] = 2 ** 31;\nconsole.log(\"Int32Array wraps silently:\", a[0]);\n",
-      "expected_output": "Int32Array wraps silently: -2147483648",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "When serializing a Python int into a fixed-width field, validate the range yourself first (or use `struct.pack` and handle the `struct.error`) rather than reaching for `ctypes`, whose wraparound is silent and easy to miss in a code review.",
-  "related": [
-    "bitwise-32-bit-truncation"
-  ],
-  "sources": [
-    {
-      "title": "Python docs: struct -- Format Characters",
-      "url": "https://docs.python.org/3/library/struct.html#format-characters"
-    },
-    {
-      "title": "Python docs: ctypes -- Fundamental data types",
-      "url": "https://docs.python.org/3/library/ctypes.html#fundamental-data-types"
-    }
-  ],
-  "tags": [
-    "validation",
-    "parsing",
-    "database"
-  ],
-  "test_cases": []
-}

package/src/exhibits/names-addresses/address-with-no-street-number.json

@@ -1,54 +0,0 @@
-{
-  "id": "address-with-no-street-number",
-  "title": "A rural route, a PO box, and a named lot all have an address with no street number at all",
-  "category": "names-addresses",
-  "assumption": "Every valid street address begins with a number.",
-  "input": {
-    "display": "\"Rural Route 2\", \"PO Box 445\", \"Lot 7 Orchard Lane\"",
-    "description": "An address-line validator that requires the first token to be numeric, used on a shipping or billing form."
-  },
-  "what_goes_wrong": "Entirely legitimate, deliverable addresses are rejected because they don't start with digits — rural routes, PO boxes, and named-lot rural properties are all real addressing conventions with no house number.",
-  "why": "A leading street number is just one of several addressing schemes in common use; postal systems also deliver to rural route numbers, post office boxes, and named lots or stations that never had a house number assigned at all. A regex that hard-requires a leading digit encodes 'suburban street address' as if it were the only valid addressing format, when it is only one of several.",
-  "affects": [
-    "any address validator requiring a leading street number"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import re\npattern = re.compile(r\"^\\d+\\s\")\nfor addr in [\"Rural Route 2\", \"PO Box 445\", \"Lot 7 Orchard Lane\"]:\n    print(addr, bool(pattern.match(addr)))\n",
-      "expected_output": "Rural Route 2 False\nPO Box 445 False\nLot 7 Orchard Lane False",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const pattern = /^\\d+\\s/;\nfor (const addr of [\"Rural Route 2\", \"PO Box 445\", \"Lot 7 Orchard Lane\"]) {\n  console.log(addr, pattern.test(addr));\n}\n",
-      "expected_output": "Rural Route 2 false\nPO Box 445 false\nLot 7 Orchard Lane false",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Don't require an address to start with a number; if you need structured address fields, make the house-number field optional and let 'address line 1' accept free text, which is how postal services themselves treat it.",
-  "related": [
-    "house-number-suffix-collapsed-by-digit-extraction"
-  ],
-  "sources": [
-    {
-      "title": "Michael Tandy: Falsehoods Programmers Believe About Addresses",
-      "url": "https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/"
-    }
-  ],
-  "tags": [
-    "addresses",
-    "validation",
-    "forms",
-    "parsing"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "PO Box 445"
-      ],
-      "relation": "no_crash",
-      "note": "A PO Box is a deliverable address with no street number; your form should accept it."
-    }
-  ]
-}

package/src/exhibits/names-addresses/ascii-regex-rejects-accented-and-hyphenated-names.json

@@ -1,55 +0,0 @@
-{
-  "id": "ascii-regex-rejects-accented-and-hyphenated-names",
-  "title": "[A-Za-z ]+ rejects \"Anne-Marie\", \"O'Brien\", and anyone with an accent in their name",
-  "category": "names-addresses",
-  "assumption": "A simple letters-and-spaces regex is a reasonable baseline check for 'is this a real name'.",
-  "input": {
-    "display": "\"Zo\\u00eb Navarro-Pe\\u00f1a\" (invented), \"Anne-Marie\", \"O'Brien\"",
-    "description": "A 'name must contain only letters' validator on a signup or checkout form, written against the ASCII alphabet."
-  },
-  "what_goes_wrong": "Entirely ordinary names are rejected outright: an accented letter, a hyphen joining two given names, or an apostrophe in a surname all fail a check that was only ever tested against plain ASCII names.",
-  "why": "The character class [A-Za-z] matches only the 26 unaccented Latin letters in each case; it has no entries for accented Latin letters, hyphens, apostrophes, or any non-Latin script at all. Any name that uses punctuation that is a normal part of that name, or any letter outside the ASCII range, fails the match even though the input is a perfectly ordinary name.",
-  "affects": [
-    "any regex validator built on [A-Za-z] or similar ascii-only classes"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import re\npattern = re.compile(r\"^[A-Za-z ]+$\")\nfor name in [\"Zo\\u00eb Navarro-Pe\\u00f1a\", \"Anne-Marie\", \"O'Brien\", \"Jose Luis\"]:\n    print(name, bool(pattern.match(name)))\n",
-      "expected_output": "Zoë Navarro-Peña False\nAnne-Marie False\nO'Brien False\nJose Luis True",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const pattern = /^[A-Za-z ]+$/;\nfor (const name of [\"Zo\\u00eb Navarro-Pe\\u00f1a\", \"Anne-Marie\", \"O'Brien\", \"Jose Luis\"]) {\n  console.log(name, pattern.test(name));\n}\n",
-      "expected_output": "Zoë Navarro-Peña false\nAnne-Marie false\nO'Brien false\nJose Luis true",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Don't validate names against a character allowlist at all if you can avoid it; if you must reject something, reject on length or control characters, not on script or punctuation — a name field should accept Unicode letters, marks, hyphens, and apostrophes at minimum.",
-  "related": [
-    "title-case-mangles-mixed-case-and-apostrophes"
-  ],
-  "sources": [
-    {
-      "title": "Patrick McKenzie: Falsehoods Programmers Believe About Names",
-      "url": "https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/"
-    }
-  ],
-  "tags": [
-    "names",
-    "validation",
-    "forms",
-    "signup",
-    "i18n"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "Zoë Navarro-Peña"
-      ],
-      "relation": "no_crash",
-      "note": "Your name validator should accept this; if it's built on an ASCII letter class, it won't."
-    }
-  ]
-}

package/src/exhibits/names-addresses/house-number-suffix-collapsed-by-digit-extraction.json

@@ -1,55 +0,0 @@
-{
-  "id": "house-number-suffix-collapsed-by-digit-extraction",
-  "title": "\"221B Baker Street\" and \"221 Baker Street\" extract to the same house number",
-  "category": "names-addresses",
-  "assumption": "Pulling the leading digits off an address line gives you a unique house-number key.",
-  "input": {
-    "display": "\"221B Baker Street\" vs \"221 Baker Street\"; \"12\\u00bd Main Street\" vs \"12 Main Street\"",
-    "description": "A geocoding or dedup step that extracts 'the house number' from an address line with a leading-digits regex, to compare or key addresses."
-  },
-  "what_goes_wrong": "Two genuinely different addresses — a subdivided unit \"221B\" and the plain \"221\" — collapse to the identical extracted number \"221\", silently merging two different physical locations in any system that keys on the extracted value.",
-  "why": "A leading-digit regex like ^(\\d+) stops at the first non-digit character, so it captures only \"221\" and discards the trailing letter suffix \"B\" — which is not decoration: it typically marks a separate property created by subdividing or infilling, and is what distinguishes it from plain 221. The same problem affects fractional house numbers like \"12½\", where the regex captures \"12\" and silently drops the ½ that distinguishes it from plain \"12\".",
-  "affects": [
-    "any 'extract leading digits as the house number' parser"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import re\ndef house_number(addr):\n    m = re.match(r\"^(\\d+)\", addr)\n    return m.group(1) if m else None\n\nfor a in [\"221B Baker Street\", \"221 Baker Street\", \"12\\u00bd Main Street\", \"12 Main Street\"]:\n    print(a, \"->\", house_number(a))\n",
-      "expected_output": "221B Baker Street -> 221\n221 Baker Street -> 221\n12½ Main Street -> 12\n12 Main Street -> 12",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "function houseNumber(addr) {\n  const m = addr.match(/^(\\d+)/);\n  return m ? m[1] : null;\n}\nfor (const a of [\"221B Baker Street\", \"221 Baker Street\", \"12\\u00bd Main Street\", \"12 Main Street\"]) {\n  console.log(a, \"->\", houseNumber(a));\n}\n",
-      "expected_output": "221B Baker Street -> 221\n221 Baker Street -> 221\n12½ Main Street -> 12\n12 Main Street -> 12",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Keep the full house-number token, including any letter suffix or fraction, as the key, instead of truncating to the leading digits; treat \"221\" and \"221B\" as different addresses unless you've confirmed otherwise.",
-  "related": [
-    "address-with-no-street-number"
-  ],
-  "sources": [
-    {
-      "title": "Michael Tandy: Falsehoods Programmers Believe About Addresses",
-      "url": "https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/"
-    }
-  ],
-  "tags": [
-    "addresses",
-    "parsing",
-    "validation",
-    "database"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "221B Baker Street",
-        "221 Baker Street"
-      ],
-      "relation": "not_equal",
-      "note": "These are two different addresses; your house-number extraction should not treat them as the same key."
-    }
-  ]
-}

package/src/exhibits/names-addresses/mononym-fails-first-last-required.json

@@ -1,56 +0,0 @@
-{
-  "id": "mononym-fails-first-last-required",
-  "title": "A one-word name fails 'first and last name required' — because it IS one word, correctly",
-  "category": "names-addresses",
-  "assumption": "Every person has both a first name and a last name to put in two separate required fields.",
-  "input": {
-    "display": "\"Wulandari\" (an invented single-word legal name, no space)",
-    "description": "A signup, shipping, or ID-verification form with separate required 'First Name' and 'Last Name' fields, applied to someone who legally has one name only."
-  },
-  "what_goes_wrong": "The validator rejects the whole name as incomplete, forcing the person to invent a fake last name, or re-type their one name into both boxes, just to get past the form.",
-  "why": "Single-word names are a real, legally recognized naming convention: many Indonesians are registered with one name only, and the pattern occurs in other cultures too. A validator that REQUIRES a 'last' component after splitting on whitespace will always reject a single-word name, because there is nothing to split; the assumption that a name has two parts is false for this input, not a formatting mistake to be corrected.",
-  "affects": [
-    "any 'first + last required' form validator"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "def validate_two_part_name(name):\n    parts = name.split(\" \")\n    if len(parts) < 2:\n        raise ValueError(\"first and last name are both required\")\n    return True\n\ntry:\n    validate_two_part_name(\"Wulandari\")\nexcept ValueError as e:\n    print(\"rejected:\", e)\n",
-      "expected_output": "rejected: first and last name are both required",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "function validateTwoPartName(name) {\n  const parts = name.split(\" \");\n  if (parts.length < 2) throw new Error(\"first and last name are both required\");\n  return true;\n}\ntry {\n  validateTwoPartName(\"Wulandari\");\n} catch (e) {\n  console.log(\"rejected:\", e.message);\n}\n",
-      "expected_output": "rejected: first and last name are both required",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Collect a single 'full name' field (or make the family-name field explicitly optional) instead of hard-requiring two parts; let the person tell you how their name is structured rather than inferring it from word count.",
-  "related": [
-    "split-surname-on-last-space-loses-particle",
-    "single-letter-surname-fails-min-length"
-  ],
-  "sources": [
-    {
-      "title": "Patrick McKenzie: Falsehoods Programmers Believe About Names",
-      "url": "https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/"
-    }
-  ],
-  "tags": [
-    "names",
-    "forms",
-    "validation",
-    "signup",
-    "i18n"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "Wulandari"
-      ],
-      "relation": "no_crash",
-      "note": "Your signup form should accept a single-word legal name without forcing a fake second word."
-    }
-  ]
-}

package/src/exhibits/names-addresses/naive-lowercase-breaks-greek-final-sigma.json

@@ -1,64 +0,0 @@
-{
-  "id": "naive-lowercase-breaks-greek-final-sigma",
-  "title": "Build your own per-letter lowercase table and Greek \"ΟΔΥΣΣΕΥΣ\" lowercases to the wrong letter at the end",
-  "category": "names-addresses",
-  "assumption": "Lowercasing a string is just mapping each character to its lowercase equivalent, independent of its neighbors.",
-  "input": {
-    "display": "\"ΟΔΥΣΣΕΥΣ\" (Greek, 'ODYSSEUS')",
-    "description": "A hand-rolled case-folding table (common in custom search normalizers, or a simple transliteration helper) that maps each character independently, rather than calling the language's real lowercasing routine."
-  },
-  "what_goes_wrong": "A search-index normalizer built this way produces a lowercase form that disagrees with the one str.lower() / toLowerCase() produces, so a lookup built against one and compared against the other silently fails to match at the end of every Greek word ending in capital sigma.",
-  "why": "Greek has two lowercase forms of sigma: σ in the middle of a word and ς (final sigma) at the end of a word — which form is correct depends on the character's POSITION in the word, not just its identity. Unicode's SpecialCasing rules encode that context-sensitive mapping, and both Python's str.lower() and JavaScript's toLowerCase() correctly apply it. A naive table that maps Σ to σ unconditionally, character by character with no notion of 'end of word', can never produce the final form, so it disagrees with the correct, built-in result precisely where a word ends in sigma.",
-  "affects": [
-    "any hand-rolled per-character case table (no word-context)",
-    "python str.lower (correctly context-sensitive)",
-    "javascript toLowerCase (correctly context-sensitive)"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "naive_map = {\"\\u03a3\": \"\\u03c3\"}\ndef naive_lower(s):\n    return \"\".join(naive_map.get(c, c.lower()) for c in s)\n\nword = \"\\u039f\\u0394\\u03a5\\u03a3\\u03a3\\u0395\\u03a5\\u03a3\"\nprint(naive_lower(word) == word.lower())\nprint(naive_lower(word))\nprint(word.lower())\n",
-      "expected_output": "False\nοδυσσευσ\nοδυσσευς",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const naiveMap = { \"\\u03a3\": \"\\u03c3\" };\nfunction naiveLower(s) {\n  return [...s].map((c) => naiveMap[c] ?? c.toLowerCase()).join(\"\");\n}\nconst word = \"\\u039f\\u0394\\u03a5\\u03a3\\u03a3\\u0395\\u03a5\\u03a3\";\nconsole.log(naiveLower(word) === word.toLowerCase());\nconsole.log(naiveLower(word));\nconsole.log(word.toLowerCase());\n",
-      "expected_output": "false\nοδυσσευσ\nοδυσσευς",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Never build a custom per-character case-folding table for a script you haven't checked for context-sensitive rules; use the language's built-in Unicode-aware lower()/toLowerCase() (or ICU) and only post-process it if you have a specific, tested reason to.",
-  "related": [],
-  "sources": [
-    {
-      "title": "Unicode SpecialCasing.txt (Final_Sigma condition)",
-      "url": "https://www.unicode.org/Public/UCD/latest/ucd/SpecialCasing.txt"
-    },
-    {
-      "title": "Python docs: str.lower()",
-      "url": "https://docs.python.org/3/library/stdtypes.html#str.lower"
-    },
-    {
-      "title": "ECMAScript spec: String.prototype.toLowerCase",
-      "url": "https://tc39.es/ecma262/#sec-string.prototype.tolowercase"
-    }
-  ],
-  "tags": [
-    "names",
-    "i18n",
-    "normalization",
-    "search",
-    "database"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "ΟΔΥΣΣΕΥΣ"
-      ],
-      "relation": "returns",
-      "expected": "οδυσσευς",
-      "note": "If you built your own per-character lowercase table, verify it against this: the correct result ends in final sigma (ς), not plain sigma (σ)."
-    }
-  ]
-}

package/src/exhibits/names-addresses/null-surname-coerced-to-null-value.json

@@ -1,58 +0,0 @@
-{
-  "id": "null-surname-coerced-to-null-value",
-  "title": "A surname that is literally the word \"Null\" gets cleaned away to an actual null",
-  "category": "names-addresses",
-  "assumption": "A string-cleaning step that treats the text 'null' as a sign of missing data is harmless.",
-  "input": {
-    "display": "\"Null\" (a real surname)",
-    "description": "A 'sanitize this field' helper applied to a last-name input, written to catch forms that leak the literal word null/NULL as placeholder text for an empty field."
-  },
-  "what_goes_wrong": "A person whose actual surname is Null has their name replaced with an actual missing value, because the cleaning function cannot tell the difference between the placeholder string and the real data.",
-  "why": "Some input pipelines add a defensive check (if the trimmed, lowercased field equals the text \"null\", treat it as empty) to guard against a template or export rendering the literal word when a field is unset. That check is a string comparison with no awareness that \"Null\" is also a real, if uncommon, surname, so it deletes a correct answer precisely because it looks like the sentinel. People with that surname have publicly described forms and systems rejecting their name or treating it as missing.",
-  "affects": [
-    "any 'treat the string null as empty' sanitizer"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "def clean_field(name):\n    if not name or name.strip().lower() == \"null\":\n        return None\n    return name.strip()\n\nprint(clean_field(\"Null\"))\nprint(clean_field(\"O'Null\"))\n",
-      "expected_output": "None\nO'Null",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "function cleanField(name) {\n  if (!name || name.toLowerCase() === \"null\") return null;\n  return name;\n}\nconsole.log(cleanField(\"Null\"));\nconsole.log(cleanField(\"O'Null\"));\n",
-      "expected_output": "null\nO'Null",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Never infer 'this field is empty' from its text content matching a sentinel word; use an explicit null/empty marker from the data layer (an actual null, not the string \"null\") so a real value can never collide with it.",
-  "related": [],
-  "sources": [
-    {
-      "title": "WIRED (2015): Hello, I'm Mr. Null. My Name Makes Me Invisible to Computers",
-      "url": "https://www.wired.com/2015/11/null/"
-    },
-    {
-      "title": "Patrick McKenzie: Falsehoods Programmers Believe About Names",
-      "url": "https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/"
-    }
-  ],
-  "tags": [
-    "names",
-    "validation",
-    "forms",
-    "database",
-    "parsing"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "Null"
-      ],
-      "relation": "returns",
-      "expected": "Null",
-      "note": "A sanitizer that strips the literal word 'null' will fail this for a real person named Null."
-    }
-  ]
-}

package/src/exhibits/names-addresses/single-letter-surname-fails-min-length.json

@@ -1,55 +0,0 @@
-{
-  "id": "single-letter-surname-fails-min-length",
-  "title": "A 'name must be at least 2 characters' rule rejects a real, single-letter surname",
-  "category": "names-addresses",
-  "assumption": "No legitimate name is only one character long.",
-  "input": {
-    "display": "\"O\" (a one-letter surname)",
-    "description": "A form validator's minimum-length rule applied to a surname field."
-  },
-  "what_goes_wrong": "A person whose surname genuinely is a single letter is rejected by a length check that has nothing to do with whether the name is real — it's purely a guess about how short a name 'should' be.",
-  "why": "Single-character surnames exist in multiple naming traditions (for example, several Korean surnames romanize to a single letter), and a minimum-length rule has no way to distinguish a genuinely short name from a placeholder like \"x\" someone typed to get past the form. The rule enforces an assumption about length that is simply false for this input, not a check that catches bad data.",
-  "affects": [
-    "any 'minimum name length' validator"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "def validate_name(name):\n    if len(name) < 2:\n        raise ValueError(\"name must be at least 2 characters\")\n    return True\n\nfor name in [\"Yu\", \"O\"]:\n    try:\n        print(name, validate_name(name))\n    except ValueError as e:\n        print(name, \"rejected:\", e)\n",
-      "expected_output": "Yu True\nO rejected: name must be at least 2 characters",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "function validateName(name) {\n  if (name.length < 2) throw new Error(\"name must be at least 2 characters\");\n  return true;\n}\nfor (const name of [\"Yu\", \"O\"]) {\n  try {\n    console.log(name, validateName(name));\n  } catch (e) {\n    console.log(name, \"rejected:\", e.message);\n  }\n}\n",
-      "expected_output": "Yu true\nO rejected: name must be at least 2 characters",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Don't impose a minimum name length unless you have a specific, documented reason to; if you need to catch empty or placeholder input, check for that directly (empty string, all the same character) rather than guessing a length threshold.",
-  "related": [
-    "mononym-fails-first-last-required"
-  ],
-  "sources": [
-    {
-      "title": "Patrick McKenzie: Falsehoods Programmers Believe About Names",
-      "url": "https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/"
-    }
-  ],
-  "tags": [
-    "names",
-    "validation",
-    "forms",
-    "length validation",
-    "i18n"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "O"
-      ],
-      "relation": "no_crash",
-      "note": "A real single-letter surname should not be rejected purely on length."
-    }
-  ]
-}