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

package/src/exhibits/names-addresses/sort-by-surname-particle-convention-mismatch.json

@@ -1,57 +0,0 @@
-{
-  "id": "sort-by-surname-particle-convention-mismatch",
-  "title": "Sorting people by their stored surname puts \"van der Berg\" after \"de Vries\"; a Dutch phone book would put it before",
-  "category": "names-addresses",
-  "assumption": "Sorting a list of surnames alphabetically, exactly as the strings are stored, produces the one correct order.",
-  "input": {
-    "display": "[\"Bakker\", \"van der Berg\", \"de Vries\"]",
-    "description": "A directory, address book, or customer list sorted by a 'last name' field that stores the full surname including any leading particle."
-  },
-  "what_goes_wrong": "Sorting the raw strings files \"van der Berg\" under V, after \"de Vries\"; the Dutch convention drops a leading particle (van, der, de) when computing the sort key, filing \"van der Berg\" under B, ahead of \"de Vries\" under V. The two conventions put these two names in a different relative order.",
-  "why": "There is no single universal rule for sorting a surname with a leading particle. The Dutch convention, followed by Dutch directories and by library cataloging rules for Dutch names, drops the particle to compute the sort key; Belgian (Flemish) practice and many other systems keep it. A system that just lowercases and sorts the stored string whole keeps the particle in place. The conventions simply disagree, and most software picks the whole-string sort without ever deciding to.",
-  "affects": [
-    "any 'sort by last name' feature using the raw stored string",
-    "library/bibliographic cataloging convention for particles (documented, not universally applied by software)"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "people = [(\"Pieter\", \"Bakker\"), (\"Joost\", \"van der Berg\"), (\"Anna\", \"de Vries\")]\nnaive_order = sorted(people, key=lambda p: p[1].lower())\nprint([p[1] for p in naive_order])\n\nPARTICLES = {\"van\", \"der\", \"de\", \"von\", \"del\", \"la\"}\ndef catalog_key(surname):\n    words = surname.split(\" \")\n    while words and words[0].lower() in PARTICLES:\n        words.pop(0)\n    return \" \".join(words).lower()\n\ncatalog_order = sorted(people, key=lambda p: catalog_key(p[1]))\nprint([p[1] for p in catalog_order])\nprint(naive_order == catalog_order)\n",
-      "expected_output": "['Bakker', 'de Vries', 'van der Berg']\n['Bakker', 'van der Berg', 'de Vries']\nFalse",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const people = [[\"Pieter\", \"Bakker\"], [\"Joost\", \"van der Berg\"], [\"Anna\", \"de Vries\"]];\nconst naiveOrder = [...people].sort((a, b) => a[1].toLowerCase().localeCompare(b[1].toLowerCase()));\nconsole.log(naiveOrder.map((p) => p[1]));\n\nconst PARTICLES = new Set([\"van\", \"der\", \"de\", \"von\", \"del\", \"la\"]);\nfunction catalogKey(surname) {\n  const words = surname.split(\" \");\n  while (words.length && PARTICLES.has(words[0].toLowerCase())) words.shift();\n  return words.join(\" \").toLowerCase();\n}\nconst catalogOrder = [...people].sort((a, b) => catalogKey(a[1]).localeCompare(catalogKey(b[1])));\nconsole.log(catalogOrder.map((p) => p[1]));\nconsole.log(JSON.stringify(naiveOrder) === JSON.stringify(catalogOrder));\n",
-      "expected_output": "[ 'Bakker', 'de Vries', 'van der Berg' ]\n[ 'Bakker', 'van der Berg', 'de Vries' ]\nfalse",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Pick a sort-key convention explicitly (whole string vs. particle-dropped) and apply it consistently, rather than sorting by whatever happens to be stored in the surname field, and don't assume there's one universally 'correct' convention; it varies by language and institution.",
-  "related": [
-    "split-surname-on-last-space-loses-particle"
-  ],
-  "sources": [
-    {
-      "title": "Patrick McKenzie: Falsehoods Programmers Believe About Names",
-      "url": "https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/"
-    }
-  ],
-  "tags": [
-    "names",
-    "sorting",
-    "display",
-    "i18n",
-    "database"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "van der Berg",
-        "de Vries"
-      ],
-      "relation": "no_crash",
-      "note": "Decide and document which sort-key convention your directory uses for particled surnames; the two common ones disagree."
-    }
-  ]
-}

package/src/exhibits/names-addresses/spanish-double-surname-treated-as-single.json

@@ -1,55 +0,0 @@
-{
-  "id": "spanish-double-surname-treated-as-single",
-  "title": "Taking the last word of \"Lucía Ferrer Montalbán\" as 'the' surname drops a whole surname",
-  "category": "names-addresses",
-  "assumption": "A person has exactly one surname, which is whichever word comes last in their full name.",
-  "input": {
-    "display": "\"Lucía Ferrer Montalbán\" (an invented name)",
-    "description": "A full-name field for someone from a Spanish-naming-convention culture, where a person carries both a paternal and a maternal surname, split with a 'last word = surname' heuristic."
-  },
-  "what_goes_wrong": "The system records \"Montalbán\" as the surname and silently drops \"Ferrer\", the first (traditionally paternal) surname, which breaks any later attempt to match this person against relatives who share it, or against official documents that list both.",
-  "why": "In Spain and most of Spanish-speaking Latin America, a person normally carries TWO surnames, both legally part of the name and neither a middle name; traditionally the first is the father's first surname and the second is the mother's first surname (Spain has let parents choose the order since 1999). A 'last word is the surname' rule, which works for a simple two-part name, discards the first of the two surnames because it has no way to know that this particular name has three meaningful parts, not two.",
-  "affects": [
-    "any 'last word is the surname' name parser applied to a spanish-convention full name"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "full = \"Luc\\u00eda Ferrer Montalb\\u00e1n\"\nparts = full.split(\" \")\ngiven, surname = parts[0], parts[-1]\nprint(\"given:\", given, \"| recorded surname:\", surname, \"| dropped:\", parts[1:-1])\n",
-      "expected_output": "given: Lucía | recorded surname: Montalbán | dropped: ['Ferrer']",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const full = \"Luc\\u00eda Ferrer Montalb\\u00e1n\";\nconst parts = full.split(\" \");\nconst given = parts[0];\nconst surname = parts[parts.length - 1];\nconsole.log(\"given:\", given, \"| recorded surname:\", surname, \"| dropped:\", parts.slice(1, -1));\n",
-      "expected_output": "given: Lucía | recorded surname: Montalbán | dropped: [ 'Ferrer' ]",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Don't assume a fixed name structure derived from word position; ask for given name(s) and surname(s) as separate, explicitly-labeled fields, and allow more than one surname.",
-  "related": [
-    "split-surname-on-last-space-loses-particle"
-  ],
-  "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",
-    "database",
-    "i18n"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "Lucía Ferrer Montalbán"
-      ],
-      "relation": "no_crash",
-      "note": "Check whether your surname extraction keeps both 'Ferrer' and 'Montalbán', or silently drops one."
-    }
-  ]
-}

package/src/exhibits/names-addresses/split-surname-on-last-space-loses-particle.json

@@ -1,59 +0,0 @@
-{
-  "id": "split-surname-on-last-space-loses-particle",
-  "title": "Splitting a name on the last space doesn't find the surname — it finds the last WORD",
-  "category": "names-addresses",
-  "assumption": "The text after the last space in a full name is the surname.",
-  "input": {
-    "display": "\"Joost van der Berg\" (an invented name)",
-    "description": "A 'full name' text field being split into given/surname for a database or a form, using the common 'last word = surname' heuristic."
-  },
-  "what_goes_wrong": "The surname field ends up holding just \"Berg\", and \"van der\" — which is part of the actual family name \"van der Berg\" — gets silently folded into the given-name field instead.",
-  "why": "Splitting on the last whitespace boundary only knows about whitespace, not about which words belong to the family name. Dutch, German, and other surnames routinely include lowercase particles (van, der, von, de) that are grammatically and legally part of the surname, not separate given names, and a position-based split has no way to know where the surname actually starts.",
-  "affects": [
-    "any 'split full name on whitespace' form handler",
-    "python str.rsplit",
-    "javascript lastIndexOf-based split"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "def naive_split(full_name):\n    given, surname = full_name.rsplit(\" \", 1)\n    return given, surname\n\nprint(naive_split(\"Joost van der Berg\"))\n",
-      "expected_output": "('Joost van der', 'Berg')",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "function naiveSplit(fullName) {\n  const i = fullName.lastIndexOf(\" \");\n  return [fullName.slice(0, i), fullName.slice(i + 1)];\n}\nconsole.log(naiveSplit(\"Joost van der Berg\"));\n",
-      "expected_output": "[ 'Joost van der', 'Berg' ]",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Collect given-name and family-name as separate fields entered directly by the person instead of inferring the split from word position; if you must infer it, maintain an explicit list of known lowercase surname particles to fold into the family-name side.",
-  "related": [
-    "mononym-fails-first-last-required",
-    "spanish-double-surname-treated-as-single"
-  ],
-  "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",
-    "database",
-    "i18n",
-    "display"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "Joost van der Berg"
-      ],
-      "relation": "no_crash",
-      "note": "Check whether your surname field comes out as 'Berg' or 'van der Berg' — most systems get this wrong."
-    }
-  ]
-}

package/src/exhibits/names-addresses/title-case-mangles-mixed-case-and-apostrophes.json

@@ -1,60 +0,0 @@
-{
-  "id": "title-case-mangles-mixed-case-and-apostrophes",
-  "title": "str.title() turns \"mcdonald\" into \"Mcdonald\" and \"they're\" into \"They'Re\"",
-  "category": "names-addresses",
-  "assumption": "A built-in title-case function always produces the conventionally correct capitalization of a name.",
-  "input": {
-    "display": "\"mcdonald\", \"they're\"",
-    "description": "A lowercase or all-caps name from a legacy database or a careless import, being 'fixed up' for display with a generic title-casing function."
-  },
-  "what_goes_wrong": "\"mcdonald\" displays as \"Mcdonald\" instead of \"McDonald\", and a word containing an apostrophe like \"they're\" gets a capital letter injected right after the apostrophe, becoming \"They'Re\".",
-  "why": "Python's str.title() capitalizes the first letter of every maximal run of alphabetic characters and lowercases the rest; it has no dictionary of surname conventions, so it has no way to know the 'D' in McDonald should also be capitalized, and it treats an apostrophe as a word boundary just like a space — which happens to look right for a name like \"o'neil\" but is wrong for a contraction like \"they're\", capitalizing the letter right after the apostrophe either way. The common hand-rolled JavaScript equivalent (capitalize the first character of each whitespace-separated token) fails differently: it also gives \"Mcdonald\", but treats \"o'neil\" as one token and returns \"O'neil\", missing the capital that name needs.",
-  "affects": [
-    "python str.title()"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "print(\"mcdonald\".title())\nprint(\"o'neil\".title())\nprint(\"they're\".title())\n",
-      "expected_output": "Mcdonald\nO'Neil\nThey'Re",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "function titleCase(s) {\n  return s.replace(/\\w\\S*/g, (t) => t[0].toUpperCase() + t.slice(1).toLowerCase());\n}\nconsole.log(titleCase(\"mcdonald\"));\nconsole.log(titleCase(\"o'neil\"));\n",
-      "expected_output": "Mcdonald\nO'neil",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Don't auto-capitalize a name with a generic title-casing function; either store and display the name exactly as the person entered it, or maintain an explicit exception list for known patterns (Mc/Mac, O', particles) and accept that no automatic rule covers every name.",
-  "related": [
-    "ascii-regex-rejects-accented-and-hyphenated-names"
-  ],
-  "sources": [
-    {
-      "title": "Python docs: str.title()",
-      "url": "https://docs.python.org/3/library/stdtypes.html#str.title"
-    },
-    {
-      "title": "Patrick McKenzie: Falsehoods Programmers Believe About Names",
-      "url": "https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/"
-    }
-  ],
-  "tags": [
-    "names",
-    "display",
-    "validation",
-    "forms",
-    "i18n"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "mcdonald"
-      ],
-      "relation": "returns",
-      "expected": "McDonald",
-      "note": "A generic title-case function will almost certainly fail this — decide whether you want to auto-capitalize names at all before relying on one."
-    }
-  ]
-}

package/src/exhibits/names-addresses/uk-canada-postal-code-assumed-numeric.json

@@ -1,55 +0,0 @@
-{
-  "id": "uk-canada-postal-code-assumed-numeric",
-  "title": "A 'postal code must be 5 digits' check rejects every UK and Canadian address",
-  "category": "names-addresses",
-  "assumption": "A postal/zip code is always a short string of digits.",
-  "input": {
-    "display": "\"SW1A 1AA\" (UK), \"K1A 0B1\" (Canada)",
-    "description": "A postal code field validated against a fixed numeric pattern, written with only US ZIP codes in mind."
-  },
-  "what_goes_wrong": "Perfectly valid UK and Canadian postal codes are rejected outright because they mix letters and digits and don't match a 5-digit pattern at all.",
-  "why": "US ZIP codes happen to be exactly 5 digits, but that's a US-specific format, not a property of 'postal codes' in general. UK postcodes (like SW1A 1AA) and Canadian postal codes (like K1A 0B1) are alphanumeric by design, with letter-digit structures that a 5-digit-only regex has no way to match.",
-  "affects": [
-    "any postal-code validator hard-coded to \\d{5}"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import re\npattern = re.compile(r\"^\\d{5}$\")\nfor code in [\"02134\", \"SW1A 1AA\", \"K1A 0B1\"]:\n    print(code, bool(pattern.match(code)))\n",
-      "expected_output": "02134 True\nSW1A 1AA False\nK1A 0B1 False",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const pattern = /^\\d{5}$/;\nfor (const code of [\"02134\", \"SW1A 1AA\", \"K1A 0B1\"]) {\n  console.log(code, pattern.test(code));\n}\n",
-      "expected_output": "02134 true\nSW1A 1AA false\nK1A 0B1 false",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Validate postal codes per-country using that country's actual format (or accept any reasonably short alphanumeric string if the country isn't known), never a single 5-digit pattern applied worldwide.",
-  "related": [
-    "us-zip-code-leading-zero-lost-as-integer"
-  ],
-  "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",
-    "i18n",
-    "database"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "SW1A 1AA"
-      ],
-      "relation": "no_crash",
-      "note": "A valid UK postcode should be accepted by your postal-code field."
-    }
-  ]
-}

package/src/exhibits/names-addresses/us-zip-code-leading-zero-lost-as-integer.json

@@ -1,58 +0,0 @@
-{
-  "id": "us-zip-code-leading-zero-lost-as-integer",
-  "title": "A Boston ZIP code, \"02134\", becomes 2134 the moment anything parses it as a number",
-  "category": "names-addresses",
-  "assumption": "A ZIP code can be safely stored or parsed as an integer; it's 'just a number' after all.",
-  "input": {
-    "display": "\"02134\" parsed with int() / parseInt()",
-    "description": "A US ZIP code stored in a numeric database column, or passed through a spreadsheet import / schema that infers 'number' for a 5-digit-looking string."
-  },
-  "what_goes_wrong": "The leading zero silently disappears, turning a real, valid ZIP code into a 4-digit number that fails every later format check and no longer matches the original address.",
-  "why": "A ZIP code is an identifier made of digit CHARACTERS, not a numeric quantity; there's no meaningful arithmetic anyone would do with it. int()/parseInt()/Number() all discard leading zeros because they parse decimal numeric VALUE, and the value of 02134 is mathematically identical to 2134 — the leading zero carries no numeric information, but it is semantically part of the identifier.",
-  "affects": [
-    "python int()",
-    "javascript parseInt()/Number()",
-    "any database column typed as an integer for a zip/postal code"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "zip_code = \"02134\"\nas_int = int(zip_code)\nprint(as_int, str(as_int))\nprint(str(as_int) == zip_code)\n",
-      "expected_output": "2134 2134\nFalse",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const zipCode = \"02134\";\nconst asInt = parseInt(zipCode, 10);\nconsole.log(asInt, String(asInt));\nconsole.log(String(asInt) === zipCode);\n",
-      "expected_output": "2134 2134\nfalse",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Store postal codes as strings, never as a numeric type, and never round-trip them through int()/parseInt()/Number() — there is nothing numeric about an identifier that happens to look like digits.",
-  "related": [
-    "uk-canada-postal-code-assumed-numeric"
-  ],
-  "sources": [
-    {
-      "title": "Michael Tandy: Falsehoods Programmers Believe About Addresses",
-      "url": "https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/"
-    }
-  ],
-  "tags": [
-    "addresses",
-    "parsing",
-    "database",
-    "validation",
-    "forms"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "02134"
-      ],
-      "relation": "returns",
-      "expected": "02134",
-      "note": "Round-tripping a ZIP code through your storage layer should preserve the leading zero."
-    }
-  ]
-}

package/src/exhibits/names-addresses/varchar-truncation-splits-name-mid-grapheme.json

@@ -1,63 +0,0 @@
-{
-  "id": "varchar-truncation-splits-name-mid-grapheme",
-  "title": "Truncating a name to a fixed length can cut a letter in half, dropping its accent silently",
-  "category": "names-addresses",
-  "assumption": "Truncating a string to N characters always leaves N valid, complete characters.",
-  "input": {
-    "display": "\"Nguy\\u1ec5n V\\u0103n H\\u01b0ng\" (an invented, common-pattern Vietnamese name) normalized to NFD, truncated to 11 code points",
-    "description": "A name stored in decomposed Unicode form (common after certain input methods or normalization steps) being cut down to fit a fixed-width column or display field."
-  },
-  "what_goes_wrong": "The cut lands between a base letter and its combining accent mark, silently dropping the accent and turning \"Văn\" into \"Va\", with no error, warning, or visible corruption in the truncation step itself.",
-  "why": "In NFD (decomposed) form, an accented letter like ă is represented as TWO code points: the base letter 'a' followed by a separate combining breve mark. A length-based slice has no concept of 'this code point belongs with the previous one'; it just counts positions, so a cut that lands exactly between the base letter and its combining mark keeps the bare base letter and discards the accent, producing a different, valid-looking string that is quietly wrong rather than visibly broken.",
-  "affects": [
-    "any code-point-count truncation (string slicing, SQL LEFT()/SUBSTRING(), an explicit cast to varchar(n)) applied to NFD text",
-    "python string slicing",
-    "javascript string slicing"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import unicodedata\nname = unicodedata.normalize(\"NFD\", \"Nguy\\u1ec5n V\\u0103n H\\u01b0ng\")\nprint(\"full (NFC):\", unicodedata.normalize(\"NFC\", name))\ntruncated = name[:11]\nprint(\"truncated (NFC):\", unicodedata.normalize(\"NFC\", truncated))\n",
-      "expected_output": "full (NFC): Nguyễn Văn Hưng\ntruncated (NFC): Nguyễn Va",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const name = \"Nguy\\u1ec5n V\\u0103n H\\u01b0ng\".normalize(\"NFD\");\nconsole.log(\"full (NFC):\", name.normalize(\"NFC\"));\nconst truncated = name.slice(0, 11);\nconsole.log(\"truncated (NFC):\", truncated.normalize(\"NFC\"));\n",
-      "expected_output": "full (NFC): Nguyễn Văn Hưng\ntruncated (NFC): Nguyễn Va",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Normalize to NFC before storing or measuring length (precomposed accented letters are single code points, far less likely to be split), and when you must truncate, cut at a grapheme-cluster boundary, not a raw code-point or UTF-16-unit count.",
-  "related": [
-    "nfc-nfd-same-name-two-accounts",
-    "nfc-nfd-filename-lookup-mismatch"
-  ],
-  "sources": [
-    {
-      "title": "Unicode Standard Annex #29: Unicode Text Segmentation (grapheme clusters)",
-      "url": "https://www.unicode.org/reports/tr29/"
-    },
-    {
-      "title": "Unicode Standard Annex #15: Unicode Normalization Forms",
-      "url": "https://www.unicode.org/reports/tr15/"
-    }
-  ],
-  "tags": [
-    "names",
-    "truncation",
-    "length validation",
-    "database",
-    "i18n",
-    "unicode"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "Nguyễn Văn Hưng"
-      ],
-      "relation": "no_crash",
-      "note": "Feed your truncation helper this name in NFD form with a limit of 11: a grapheme-aware truncation keeps \"Nguyễn V\" or \"Nguyễn Vă\", never a bare \"a\" stripped of its breve."
-    }
-  ]
-}

package/src/exhibits/parsing/csv-crlf-trailing-blank-line.json

@@ -1,87 +0,0 @@
-{
-  "id": "csv-crlf-trailing-blank-line",
-  "title": "A trailing blank line in a CSV file parses as a real (empty) row, and indexing into it throws",
-  "category": "parsing",
-  "assumption": "A CSV file's trailing newline (or a blank line left at the end by whatever produced it) just gets dropped, so the number of parsed rows always equals the number of visible data lines.",
-  "input": {
-    "display": "a,b\\n1,2\\n\\n (note the extra blank line before end of file)",
-    "description": "A CSV generated by exporting from a spreadsheet or database tool that leaves one truly empty line at the end of the file, as opposed to a single ordinary trailing newline after the last data row (which is harmless)."
-  },
-  "what_goes_wrong": "A single trailing line ending after the last row (`a,b\\r\\n1,2\\r\\n3,4\\r\\n`) parses cleanly as three rows - but an extra blank line (`a,b\\n1,2\\n\\n`) parses as three rows in Python where the last one is a genuinely empty list `[]`, so `rows[-1][0]` raises `IndexError: list index out of range`. The JS naive `split(\"\\n\")` equivalent doesn't crash on this particular shape, but produces two phantom `[\"\"]` rows.",
-  "why": "A CSV reader has to distinguish \"the file ends after a newline\" (no extra row) from \"there is a genuinely empty line in the data\" (a zero-field row). Python's `csv` module does the former correctly and represents the latter faithfully as `[]`, which is correct behavior but a shape callers rarely expect to handle, so indexing into the last row without checking its length crashes. Plain `text.split(\"\\n\")` in JavaScript produces a trailing empty string element whenever the text ends in a newline at all, so naive code gets an extra `[\"\"]`-shaped phantom row even for the harmless single-trailing-newline case that Python's real parser handles cleanly.",
-  "affects": [
-    "python",
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import csv, io\nclean = 'a,b\\r\\n1,2\\r\\n3,4\\r\\n'\nprint(list(csv.reader(io.StringIO(clean))))\nwith_blank = 'a,b\\n1,2\\n\\n'\nrows = list(csv.reader(io.StringIO(with_blank)))\nprint(rows)\ntry:\n    print(rows[-1][0])\nexcept IndexError as e:\n    print(\"IndexError:\", e)\n",
-      "expected_output": "[['a', 'b'], ['1', '2'], ['3', '4']]\n[['a', 'b'], ['1', '2'], []]\nIndexError: list index out of range",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const withBlank = \"a,b\\n1,2\\n\\n\";\nconst naiveRows = withBlank.split(\"\\n\").map(line => line.split(\",\"));\nconsole.log(JSON.stringify(naiveRows));\nconsole.log(naiveRows[naiveRows.length - 1][0]);\n",
-      "expected_output": "[[\"a\",\"b\"],[\"1\",\"2\"],[\"\"],[\"\"]]",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Filter out zero-length rows (Python: `if row` after reading) or trailing empty lines before splitting (JS), and never index into the last parsed row without checking it has the expected number of fields first.",
-  "related": [
-    "csv-utf8-bom-first-header"
-  ],
-  "sources": [
-    {
-      "title": "Python docs: csv - CSV File Reading and Writing",
-      "url": "https://docs.python.org/3/library/csv.html"
-    },
-    {
-      "title": "RFC 4180: Common Format and MIME Type for Comma-Separated Values (CSV) Files",
-      "url": "https://www.rfc-editor.org/rfc/rfc4180"
-    }
-  ],
-  "tags": [
-    "csv",
-    "upload",
-    "parsing",
-    "validation"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "a,b\n1,2\n\n"
-      ],
-      "relation": "returns",
-      "expected": [
-        [
-          "a",
-          "b"
-        ],
-        [
-          "1",
-          "2"
-        ],
-        []
-      ],
-      "note": "A CSV-parsing function given a file with a genuinely blank trailing line should represent it as an empty row (as Python's csv.reader does) rather than crashing - callers must then check row length before indexing."
-    },
-    {
-      "inputs": [
-        "a,b\r\n1,2\r\n"
-      ],
-      "relation": "returns",
-      "expected": [
-        [
-          "a",
-          "b"
-        ],
-        [
-          "1",
-          "2"
-        ]
-      ],
-      "note": "A single CRLF after the last row is just the line terminator: exactly two rows, no phantom empty row and no stray \\r in the last field."
-    }
-  ]
-}

package/src/exhibits/parsing/csv-doubled-quote-escaping.json

@@ -1,70 +0,0 @@
-{
-  "id": "csv-doubled-quote-escaping",
-  "title": "A literal quote mark inside a CSV field is written as two quote marks, not a backslash-escaped one",
-  "category": "parsing",
-  "assumption": "A quote character inside a CSV field is escaped the way it is in most languages, with a backslash.",
-  "input": {
-    "display": "name,quote\\n\"Say \"\"hello\"\"\",5\\n",
-    "description": "A CSV export of a field whose text contains a literal double-quote character, e.g. a product name like `Say \"hello\"` or a quoted phrase inside a review."
-  },
-  "what_goes_wrong": "A field containing a literal `\"` is represented in CSV as `\"\"` (two quote characters) inside the surrounding quoted field, not `\\\"` - code that naively strips a single leading/trailing quote and un-escapes backslash-quote sequences (a common pattern borrowed from JSON/string literals) will mangle the field instead of recovering `Say \"hello\"`.",
-  "why": "RFC 4180's escape mechanism for a literal double-quote inside a quoted field is to double it - `\"\"` means one literal `\"` - with no backslash involved anywhere in the format. A real CSV parser (Python's `csv` module) recognizes a `\"\"` sequence while inside a quoted field as an escaped quote and collapses it to one `\"` in the field's value; it is a dialect-specific rule that has nothing to do with how any programming language escapes string literals.",
-  "affects": [
-    "javascript",
-    "any backslash-escape-based CSV handling"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import csv, io\ntext = 'name,quote\\n\"Say \"\"hello\"\"\",5\\n'\nprint(list(csv.reader(io.StringIO(text))))\n",
-      "expected_output": "[['name', 'quote'], ['Say \"hello\"', '5']]",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const text = 'name,quote\\n\"Say \"\"hello\"\"\",5\\n';\n// naive: strip outer quotes, un-escape backslash-quote (wrong model for CSV)\nconst line = text.split(\"\\n\")[1];\nconst naiveFields = line.split(\",\");\nconsole.log(JSON.stringify(naiveFields));\n",
-      "expected_output": "[\"\\\"Say \\\"\\\"hello\\\"\\\"\\\"\",\"5\"]",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Use a real CSV parser that implements RFC 4180's doubled-quote escaping, rather than any backslash-based unescaping borrowed from another format. If writing CSV by hand, double every `\"` inside a field and wrap the whole field in quotes.",
-  "related": [
-    "csv-quoted-field-with-comma",
-    "csv-quoted-field-with-newline"
-  ],
-  "sources": [
-    {
-      "title": "RFC 4180: Common Format and MIME Type for Comma-Separated Values (CSV) Files",
-      "url": "https://www.rfc-editor.org/rfc/rfc4180"
-    },
-    {
-      "title": "Python docs: csv - CSV File Reading and Writing",
-      "url": "https://docs.python.org/3/library/csv.html"
-    }
-  ],
-  "tags": [
-    "csv",
-    "upload",
-    "parsing",
-    "validation"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "name,quote\n\"Say \"\"hello\"\"\",5\n"
-      ],
-      "relation": "returns",
-      "expected": [
-        [
-          "name",
-          "quote"
-        ],
-        [
-          "Say \"hello\"",
-          "5"
-        ]
-      ],
-      "note": "A CSV-parsing function given this text must collapse the doubled quotes into one literal quote character inside the field value."
-    }
-  ]
-}