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

package/src/exhibits/sorting/localecompare-numeric-option.json

@@ -1,50 +0,0 @@
-{
-  "id": "localecompare-numeric-option",
-  "title": "There's a one-word fix for natural sort in JavaScript, and it's off by default",
-  "category": "sorting",
-  "assumption": "Fixing \"file10 sorts before file2\" requires writing your own digit-splitting comparator.",
-  "input": {
-    "display": "[\"file10.txt\", \"file2.txt\", \"file1.txt\"].sort((a, b) => a.localeCompare(b, undefined, { numeric: true }))",
-    "description": "The same filename-sorting problem as the plain natural-sort exhibit, this time looking for the fix rather than the bug."
-  },
-  "what_goes_wrong": "Passing { numeric: true } as an option to localeCompare correctly returns [\"file1.txt\", \"file2.txt\", \"file10.txt\"] with no custom parsing code at all — but it is not the default for localeCompare, not the default for Array.prototype.sort(), and has no equivalent option anywhere in Python's standard library sorted(); Python's locale.strxfrm (the one built-in collation hook Python has) does not implement it either and returns the same wrong lexicographic order as a plain sort.",
-  "why": "ECMA-402 (the Intl part of JavaScript) defines a numeric collation option (the Unicode locale extension \"kn\") that makes the collator compare runs of decimal digits by their numeric value instead of character by character, and String.prototype.localeCompare accepts the same options object as Intl.Collator. It is opt-in because it is a tailoring on top of the default Unicode Collation Algorithm ordering, not the default. Python ships no Unicode collation implementation: locale.strxfrm only applies whatever collation the operating system's locale provides, and the common C-library locales have no numeric-run option, so in Python the digit-run comparison has to be hand-written.",
-  "affects": [
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import locale\nfiles = [\"file10.txt\", \"file2.txt\", \"file1.txt\"]\nprint(sorted(files, key=locale.strxfrm))\n",
-      "expected_output": "['file1.txt', 'file10.txt', 'file2.txt']",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const files = [\"file10.txt\", \"file2.txt\", \"file1.txt\"];\nconsole.log(files.slice().sort((a, b) => a.localeCompare(b, undefined, { numeric: true })));\n",
-      "expected_output": "[ 'file1.txt', 'file2.txt', 'file10.txt' ]",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "In JavaScript, pass { numeric: true } to localeCompare (or construct one Intl.Collator with that option and reuse its compare for the whole sort, which is faster). It only treats runs of digits as non-negative integers: signs, decimal points and thousands separators are still compared as characters. In Python, write a natural-sort key that splits each string on digit runs with re.split(r\"(\\d+)\", s) and converts the digit groups to int, since there is no built-in numeric collation to opt into.",
-  "related": [
-    "natural-sort-breaks-lexicographic"
-  ],
-  "sources": [
-    {
-      "title": "ECMA-402: Intl.Collator, the numeric option",
-      "url": "https://tc39.es/ecma402/#sec-intl-collator-constructor"
-    },
-    {
-      "title": "MDN: String.prototype.localeCompare()",
-      "url": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/localeCompare"
-    }
-  ],
-  "tags": [
-    "sorting",
-    "comparison",
-    "names",
-    "display",
-    "pagination"
-  ]
-}

package/src/exhibits/sorting/nan-in-sort.json

@@ -1,59 +0,0 @@
-{
-  "id": "nan-in-sort",
-  "title": "One NaN can leave the rest of the list unsorted",
-  "category": "sorting",
-  "assumption": "A NaN in a numeric list just ends up somewhere predictable, and every other value still gets sorted.",
-  "input": {
-    "display": "sorted([1, 2, 3, nan]), sorted([nan, 1, 2, 3]) and sorted([3, nan, 1])",
-    "description": "A numeric column (a score, a computed ratio, a percentage with a 0/0 somewhere) that can legitimately contain NaN, sorted for a leaderboard or report."
-  },
-  "what_goes_wrong": "Where NaN lands depends on where it started ([1, 2, 3, nan] stays as is, [nan, 1, 2, 3] stays as is), and worse, sorted([3, nan, 1]) returns [3, nan, 1]: the numbers 3 and 1 are left out of order. JavaScript's sort with (a, b) => a - b returned [3, NaN, 1] for the same input in Node.js.",
-  "why": "IEEE 754 makes every ordered comparison with NaN false, so to Python's sort NaN looks equal to everything (neither NaN < x nor x < NaN). In JavaScript, a - b is NaN whenever either side is NaN, and the spec turns a NaN comparator result into 0, which also means \"equal\". Equality with everything breaks transitivity: 3 \"equals\" NaN and NaN \"equals\" 1, but 3 is not equal to 1. Sorting algorithms rely on transitivity to avoid comparing every pair, so they can conclude [3, nan, 1] is already in order. Python's sort makes no promise for inconsistent comparisons, and the ECMAScript spec says the order is implementation-defined when the comparator is not consistent.",
-  "affects": [
-    "python",
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "nan = float(\"nan\")\nprint(sorted([1, 2, 3, nan]))\nprint(sorted([nan, 1, 2, 3]))\nprint(sorted([3, nan, 1]))\n",
-      "expected_output": "[1, 2, 3, nan]\n[nan, 1, 2, 3]\n[3, nan, 1]",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const byNum = (a, b) => a - b;\nconsole.log([3, 1, NaN, 2].sort(byNum));\nconsole.log([NaN, 3, 1, 2].sort(byNum));\nconsole.log([3, NaN, 1].sort(byNum));\n",
-      "expected_output": "[ 1, 2, 3, NaN ]\n[ NaN, 1, 2, 3 ]\n[ 3, NaN, 1 ]",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Remove or partition NaN before sorting rather than letting it reach the comparison. Decide whether NaN goes first, last, or is excluded, and encode that directly: in Python, key=lambda x: (math.isnan(x), x) puts NaN last; in JavaScript, a comparator that checks Number.isNaN() on both sides before subtracting.",
-  "related": [
-    "comparator-returns-boolean-js"
-  ],
-  "sources": [
-    {
-      "title": "Python docs: Sorting Techniques",
-      "url": "https://docs.python.org/3/howto/sorting.html"
-    },
-    {
-      "title": "Python docs: math.isnan",
-      "url": "https://docs.python.org/3/library/math.html#math.isnan"
-    },
-    {
-      "title": "ECMAScript spec: SortIndexedProperties (implementation-defined order for inconsistent comparators)",
-      "url": "https://tc39.es/ecma262/#sec-sortindexedproperties"
-    },
-    {
-      "title": "ECMAScript spec: CompareArrayElements (NaN result treated as +0)",
-      "url": "https://tc39.es/ecma262/#sec-comparearrayelements"
-    }
-  ],
-  "tags": [
-    "sorting",
-    "comparison",
-    "display",
-    "pagination"
-  ],
-  "test_cases": null
-}

package/src/exhibits/sorting/natural-sort-breaks-lexicographic.json

@@ -1,63 +0,0 @@
-{
-  "id": "natural-sort-breaks-lexicographic",
-  "title": "\"file10.txt\" sorts before \"file2.txt\"",
-  "category": "sorting",
-  "assumption": "Sorting a list of filenames (or any strings with embedded numbers) alphabetically also puts them in numeric order for the number part.",
-  "input": {
-    "display": "[\"file10.txt\", \"file2.txt\", \"file1.txt\"]",
-    "description": "A directory listing, a set of uploaded files (page-01.jpg, page-02.jpg, ..., page-10.jpg), or any auto-numbered set of names sorted with a plain string comparison."
-  },
-  "what_goes_wrong": "A plain sort returns [\"file1.txt\", \"file10.txt\", \"file2.txt\"] — \"file10.txt\" is placed between \"file1.txt\" and \"file2.txt\", because standard string comparison never looks at the embedded number as a number at all.",
-  "why": "String comparison walks the two strings character by character until it finds a difference. \"file1\" and \"file10\" and \"file2\" all share the prefix \"file\"; comparing position by position, \"1\" < \"2\" decides \"file10\" < \"file2\" before the comparison ever reaches the second digit of \"10\" — the strings are compared as sequences of characters, not parsed into a text part and a numeric part the way a human reads them. This is true identically in Python and JavaScript, because both default to the same kind of character-by-character comparison; neither treats a run of digits as a single unit unless you tell it to.",
-  "affects": [
-    "python",
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "files = [\"file10.txt\", \"file2.txt\", \"file1.txt\"]\nprint(sorted(files))\n",
-      "expected_output": "['file1.txt', 'file10.txt', 'file2.txt']",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const files = [\"file10.txt\", \"file2.txt\", \"file1.txt\"];\nconsole.log(files.slice().sort());\n",
-      "expected_output": "[ 'file1.txt', 'file10.txt', 'file2.txt' ]",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Use a \"natural sort\": split each string into alternating text/number runs and compare the number runs numerically (JavaScript has this built into localeCompare's {numeric: true} option; Python's standard library has no equivalent and needs a hand-written key function, e.g. splitting on digit runs with re.split and converting the digit groups to int).",
-  "related": [
-    "js-array-sort-stringifies-numbers",
-    "localecompare-numeric-option"
-  ],
-  "sources": [
-    {
-      "title": "Unicode Technical Standard #10: Unicode Collation Algorithm",
-      "url": "https://www.unicode.org/reports/tr10/"
-    },
-    {
-      "title": "Python docs: sorted() / list.sort()",
-      "url": "https://docs.python.org/3/library/stdtypes.html#list.sort"
-    }
-  ],
-  "tags": [
-    "sorting",
-    "comparison",
-    "names",
-    "display",
-    "pagination"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "file10.txt",
-        "file2.txt"
-      ],
-      "relation": "returns",
-      "expected": false,
-      "note": "their_function(a, b) as a natural-order \"a sorts before b\" test should return false: file2 belongs before file10. Plain `a < b` returns true, which is the bug."
-    }
-  ]
-}

package/src/exhibits/sorting/postgres-collation-documented.json

@@ -1,61 +0,0 @@
-{
-  "id": "postgres-collation-documented",
-  "title": "ORDER BY in Postgres can return a different row order than the exact same query on a different server",
-  "category": "sorting",
-  "assumption": "ORDER BY on a text column is a property of the SQL and the data, so the same query against the same rows always returns the same order.",
-  "input": {
-    "display": "SELECT name FROM users ORDER BY name;",
-    "description": "A plain text ORDER BY on a column using the database's default collation, run against two Postgres instances whose cluster was initialized with different default collations (e.g. \"C\" vs \"en_US.utf8\" vs an ICU collation)."
-  },
-  "what_goes_wrong": "The identical query on identical rows returns a different order on a database whose collation is \"C\" (byte order: case-sensitive, uppercase before lowercase, accented letters after z) than on one using an \"en_US\" libc or ICU collation (a, ä, Z interleaved by letter). Restoring or migrating into a database with a different default collation, or upgrading the operating system's locale data under the same collation name, can change ORDER BY results without changing a row of data or a line of SQL.",
-  "why": "Postgres orders text using a collation. Each text column has one, which defaults to the database's collation, and a query can override it with COLLATE. The database default is fixed when the database is created, and the actual ordering comes from either the C library's locale data (the libc provider) or ICU (supported since PostgreSQL 10). So the same SQL orders differently in databases with different collations, and even the same collation name, such as en_US.utf8, can order differently after an operating-system upgrade changes the C library's locale data (the glibc 2.28 change is the best-known case, and it also left existing text indexes inconsistent). A pg_dump made without --create does not carry the database's default collation, so restoring it into a database created with a different default changes every un-pinned text sort.",
-  "affects": [
-    "postgres"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "words = [\"a\", \"Z\", \"\\u00e4\"]\nprint(sorted(words))\n",
-      "expected_output": "['Z', 'a', 'ä']",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const words = [\"a\", \"Z\", \"\\u00e4\"];\nconsole.log(words.slice().sort());\nconsole.log(words.slice().sort((a, b) => a.localeCompare(b, \"en-US\")));\n",
-      "expected_output": "[ 'Z', 'a', 'ä' ]\n[ 'a', 'ä', 'Z' ]",
-      "verified_with": "Node.js v22.22.2"
-    },
-    {
-      "language": "postgres",
-      "status": "documented",
-      "note": "SELECT name FROM (VALUES ('a'),('Z'),('ä')) AS t(name) ORDER BY name COLLATE \"C\"; returns Z, a, ä (UTF-8 byte order, matching the plain code-point sorts in the Python/JS repros above). The same query with COLLATE \"en-US-x-icu\" (available when PostgreSQL is built with ICU) returns a, ä, Z, matching the localeCompare repro above. Without a COLLATE clause the result depends on the database's collation, which you can see with SELECT datcollate FROM pg_database WHERE datname = current_database();",
-      "source": "https://www.postgresql.org/docs/current/collation.html"
-    }
-  ],
-  "fix": "Pin collation explicitly with COLLATE in any ORDER BY whose result order matters across environments (tests comparing row order, pagination cursors, anything exported and diffed). Check the database collation with SELECT datcollate FROM pg_database WHERE datname = current_database();. Treat a restore onto a server with different locale or ICU data, or an OS upgrade that changes glibc, as a behaviour change for every un-pinned text sort, and reindex text indexes after such an upgrade.",
-  "related": [
-    "accented-letters-sort-after-z",
-    "byte-order-caps-before-lowercase"
-  ],
-  "sources": [
-    {
-      "title": "PostgreSQL docs: Collation Support",
-      "url": "https://www.postgresql.org/docs/current/collation.html"
-    },
-    {
-      "title": "PostgreSQL wiki: Locale data changes",
-      "url": "https://wiki.postgresql.org/wiki/Locale_data_changes"
-    },
-    {
-      "title": "PostgreSQL docs: pg_dump (--create)",
-      "url": "https://www.postgresql.org/docs/current/app-pgdump.html"
-    }
-  ],
-  "tags": [
-    "sorting",
-    "comparison",
-    "database",
-    "pagination",
-    "i18n"
-  ]
-}

package/src/exhibits/sorting/python-cannot-compare-str-int.json

@@ -1,70 +0,0 @@
-{
-  "id": "python-cannot-compare-str-int",
-  "title": "Python crashes sorting [2, \"10\", 1]; JavaScript quietly reshuffles it",
-  "category": "sorting",
-  "assumption": "A list with mixed number and numeric-string types is a data-cleanliness smell, not something that changes which language's sort crashes versus which one silently gives you a wrong-looking answer.",
-  "input": {
-    "display": "[2, \"10\", 1, \"3\"] — a list mixing actual numbers and numbers-as-strings",
-    "description": "A column assembled from two sources that disagree on type — one API returns numeric IDs as JSON numbers, another returns them as strings — merged into one list and sorted without normalizing types first."
-  },
-  "what_goes_wrong": "Python's sorted([2, \"10\", 1, \"3\"]) raises TypeError: Python 3 has no ordering between int and str. JavaScript's [2, \"10\", 1, \"3\"].sort() runs with no error and returns [1, \"10\", 2, \"3\"], an order that is neither numeric nor meaningful, produced silently.",
-  "why": "For a < b, Python first tries a.__lt__(b) and, if that returns NotImplemented, the reflected b.__gt__(a). int.__lt__ does not accept a str and str.__gt__ does not accept an int, so both return NotImplemented and Python raises TypeError rather than guess. (Python 2 did order mixed types, by type name; Python 3 removed that.) JavaScript's default Array.prototype.sort() converts every element with ToString before comparing, so 2 becomes \"2\" and the comparison is ordinary string comparison. By the time anything is compared there is no type mismatch left to object to.",
-  "affects": [
-    "python",
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "data = [2, \"10\", 1, \"3\"]\ntry:\n    sorted(data)\n    print(\"no error\")\nexcept TypeError:\n    print(\"TypeError\")\n",
-      "expected_output": "TypeError",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const data = [2, \"10\", 1, \"3\"];\nconsole.log(data.slice().sort());\n",
-      "expected_output": "[ 1, '10', 2, '3' ]",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Normalize types before sorting a mixed collection — decide whether everything should be a number or everything a string, and convert explicitly, rather than relying on either language's comparison machinery to make that decision for you (one will refuse to run at all; the other will run and hand you an answer that looks plausible while meaning nothing).",
-  "related": [
-    "sorting-mixed-none-null",
-    "js-array-sort-stringifies-numbers"
-  ],
-  "sources": [
-    {
-      "title": "Python docs: Comparisons",
-      "url": "https://docs.python.org/3/reference/expressions.html#comparisons"
-    },
-    {
-      "title": "Python docs: object.__lt__ and reflected comparison methods",
-      "url": "https://docs.python.org/3/reference/datamodel.html#object.__lt__"
-    },
-    {
-      "title": "ECMAScript spec: Array.prototype.sort",
-      "url": "https://tc39.es/ecma262/#sec-array.prototype.sort"
-    }
-  ],
-  "tags": [
-    "sorting",
-    "comparison",
-    "database",
-    "json",
-    "parsing"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        [
-          2,
-          "10",
-          1,
-          "3"
-        ]
-      ],
-      "relation": "no_crash",
-      "note": "A sort over mixed-type input should normalize types first (for example convert everything to int, giving 1, 2, 3, 10 in numeric order) rather than raise TypeError (Python's sorted) or silently return string order (JavaScript's default sort)."
-    }
-  ]
-}

package/src/exhibits/sorting/reverse-sort-vs-reverse-after-sort-ties.json

@@ -1,48 +0,0 @@
-{
-  "id": "reverse-sort-vs-reverse-after-sort-ties",
-  "title": "Sorting descending and \"sort ascending then reverse the list\" give different answers when there are ties",
-  "category": "sorting",
-  "assumption": "sorted(data, reverse=True) is exactly the same as list(reversed(sorted(data))) — descending sort and \"sort then flip the list\" are interchangeable.",
-  "input": {
-    "display": "[(\"a\",1), (\"b\",1), (\"c\",2)] sorted descending by the second element, two different ways",
-    "description": "Showing the highest-scoring rows first, where some rows tie on score and the tiebreaker is \"whoever was already first stays first\" (e.g. insertion order, or an earlier sort by name)."
-  },
-  "what_goes_wrong": "sorted(data, key=..., reverse=True) returns [(\"c\",2), (\"a\",1), (\"b\",1)] — among the tied score-1 rows, \"a\" still comes before \"b\", matching their original order. list(reversed(sorted(data, key=...))) returns [(\"c\",2), (\"b\",1), (\"a\",1)] — the SAME tied rows now come out with \"b\" before \"a\", the opposite of their original order. The non-tied row (\"c\",2) ends up in the same place either way; only the ties disagree.",
-  "why": "A stable sort keeps elements that compare equal in their original relative order. Python documents reverse=True as sorting \"as if each comparison were reversed\" while staying stable, so tied rows keep their input order, and a JavaScript comparator that negates the ascending comparison does the same. Reversing an already-sorted list flips every position, including the order inside each group of ties. The two only agree when there are no ties.",
-  "affects": [
-    "python",
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "data = [(\"a\", 1), (\"b\", 1), (\"c\", 2)]\nby_reverse_flag = sorted(data, key=lambda t: t[1], reverse=True)\nby_sort_then_reverse = list(reversed(sorted(data, key=lambda t: t[1])))\nprint(by_reverse_flag)\nprint(by_sort_then_reverse)\nprint(by_reverse_flag == by_sort_then_reverse)\n",
-      "expected_output": "[('c', 2), ('a', 1), ('b', 1)]\n[('c', 2), ('b', 1), ('a', 1)]\nFalse",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const data = [[\"a\", 1], [\"b\", 1], [\"c\", 2]];\nconst byReverseComparator = data.slice().sort((x, y) => y[1] - x[1]);\nconst bySortThenReverse = data.slice().sort((x, y) => x[1] - y[1]).reverse();\nconsole.log(JSON.stringify(byReverseComparator));\nconsole.log(JSON.stringify(bySortThenReverse));\nconsole.log(JSON.stringify(byReverseComparator) === JSON.stringify(bySortThenReverse));\n",
-      "expected_output": "[[\"c\",2],[\"a\",1],[\"b\",1]]\n[[\"c\",2],[\"b\",1],[\"a\",1]]\nfalse",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "If tie order matters for a descending sort, use the language's actual descending sort (reverse=True in Python, or a comparator that negates the ascending comparison in JS) rather than sorting ascending and reversing the whole list afterward — they are not equivalent whenever ties exist.",
-  "related": [],
-  "sources": [
-    {
-      "title": "Python docs: Sorting HOW TO (stability, reverse)",
-      "url": "https://docs.python.org/3/howto/sorting.html#sort-stability-and-complex-sorts"
-    },
-    {
-      "title": "ECMA-262: Array.prototype.sort (stability requirement)",
-      "url": "https://tc39.es/ecma262/#sec-array.prototype.sort"
-    }
-  ],
-  "tags": [
-    "sorting",
-    "comparison",
-    "pagination",
-    "display"
-  ]
-}

package/src/exhibits/sorting/sorting-mixed-none-null.json

@@ -1,56 +0,0 @@
-{
-  "id": "sorting-mixed-none-null",
-  "title": "Python refuses to sort a list with a missing value; JavaScript sorts it two different ways depending on how you ask",
-  "category": "sorting",
-  "assumption": "A missing value (None/null/undefined) in a list of numbers sorts to a predictable, consistent place, or fails loudly the same way everywhere.",
-  "input": {
-    "display": "[3, None, 1] in Python; [3, null, 1, undefined, 2] in JavaScript",
-    "description": "A numeric column from a database or API response where some rows legitimately have no value (an unset score, an optional field), sorted for a leaderboard or table."
-  },
-  "what_goes_wrong": "Python's sorted([3, None, 1]) raises TypeError. JavaScript's default sort compares elements as strings, so null sorts where the string \"null\" would (after the digits here), while undefined always goes to the very end. With a numeric comparator (a, b) => a - b, null behaves as 0 (Number(null) === 0) and moves to the front, and undefined is still last: the comparator is never called with undefined, so no comparator logic can move it.",
-  "why": "Python's < raises TypeError when neither operand's comparison method supports the other type, and None has no ordering against int. In JavaScript, the default sort uses ToString (String(null) is \"null\"), while a subtraction comparator relies on numeric conversion, where Number(null) is 0. undefined never reaches the comparator: the spec's CompareArrayElements returns \"undefined goes after\" before calling it, so undefined values always end up after every other value (and array holes after those).",
-  "affects": [
-    "python",
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "data = [3, None, 1]\ntry:\n    sorted(data)\n    print(\"sorted without error\")\nexcept TypeError:\n    print(\"TypeError\")\n",
-      "expected_output": "TypeError",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const data = [3, null, 1, undefined, 2];\nconsole.log(data.slice().sort());\nconsole.log(data.slice().sort((a, b) => a - b));\n",
-      "expected_output": "[ 1, 2, 3, null, undefined ]\n[ null, 1, 2, 3, undefined ]",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Decide explicitly where missing values belong (first, last, or filtered out) and partition or key for that before sorting, rather than letting None/null/undefined flow into the comparison — in JavaScript especially, don't assume your comparator controls where undefined ends up; it doesn't.",
-  "related": [
-    "python-cannot-compare-str-int",
-    "nan-in-sort"
-  ],
-  "sources": [
-    {
-      "title": "ECMAScript spec: CompareArrayElements",
-      "url": "https://tc39.es/ecma262/#sec-comparearrayelements"
-    },
-    {
-      "title": "ECMAScript spec: Array.prototype.sort",
-      "url": "https://tc39.es/ecma262/#sec-array.prototype.sort"
-    },
-    {
-      "title": "Python docs: Comparisons",
-      "url": "https://docs.python.org/3/reference/expressions.html#comparisons"
-    }
-  ],
-  "tags": [
-    "sorting",
-    "comparison",
-    "database",
-    "pagination",
-    "display"
-  ]
-}

package/src/exhibits/sorting/typed-array-sort-is-numeric-by-default.json

@@ -1,48 +0,0 @@
-{
-  "id": "typed-array-sort-is-numeric-by-default",
-  "title": "Int32Array.prototype.sort() sorts numerically by default; Array.prototype.sort() on the same numbers doesn't",
-  "category": "sorting",
-  "assumption": "sort() means the same thing on every array-like object in JavaScript — if plain arrays sort numbers as strings by default, typed arrays must too.",
-  "input": {
-    "display": "[10, 9, 1, 2].sort() vs Int32Array.from([10, 9, 1, 2]).sort()",
-    "description": "Converting a plain array of numbers to a typed array (common when passing data to WebGL, audio buffers, or any binary-protocol code) and calling the same-named .sort() method on it with no comparator."
-  },
-  "what_goes_wrong": "The plain array's default sort() returns [1, 10, 2, 9] (string order, the usual trap). The typed array's default sort() on the identical numbers returns [1, 2, 9, 10] — correctly ascending numeric order — with no comparator passed at all. The exact same method name, called the same way, defaults to opposite comparison strategies depending only on which kind of array it's called on.",
-  "why": "The ECMAScript spec gives %TypedArray%.prototype.sort its own default comparison, defined numerically: smaller values first, -0 before +0, and NaN (possible in Float32Array/Float64Array) at the end. Typed arrays can only hold numbers (or BigInts), so there is no need for the string fallback. Array.prototype.sort's default has to work for arrays holding any mix of values, and the spec defines it with ToString instead. Python's sorted() on a list of ints always compares the integer values, so there is no equivalent split.",
-  "affects": [
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "data = [10, 9, 1, 2]\nprint(sorted(data))\n",
-      "expected_output": "[1, 2, 9, 10]",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const arr = [10, 9, 1, 2];\nconsole.log(arr.slice().sort());\nconst typed = Int32Array.from(arr);\ntyped.sort();\nconsole.log(Array.from(typed));\n",
-      "expected_output": "[ 1, 10, 2, 9 ]\n[ 1, 2, 9, 10 ]",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Don't assume .sort()'s default behavior transfers between plain arrays and typed arrays, or rely on that difference — pass an explicit numeric comparator to Array.prototype.sort() regardless, so the code reads the same way (and behaves the same way) whichever kind of array it ends up operating on.",
-  "related": [
-    "js-array-sort-stringifies-numbers"
-  ],
-  "sources": [
-    {
-      "title": "ECMA-262: %TypedArray%.prototype.sort",
-      "url": "https://tc39.es/ecma262/#sec-%typedarray%.prototype.sort"
-    },
-    {
-      "title": "MDN: TypedArray.prototype.sort()",
-      "url": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/TypedArray/sort"
-    }
-  ],
-  "tags": [
-    "sorting",
-    "comparison",
-    "display"
-  ]
-}

package/src/exhibits/unicode/arabic-indic-digit-parses.json

@@ -1,73 +0,0 @@
-{
-  "id": "arabic-indic-digit-parses",
-  "title": "Python's int(\"\\u0663\") is 3; JavaScript's Number(\"\\u0663\") is NaN",
-  "category": "unicode",
-  "assumption": "A \"digits only\" check (\\d or isdigit) and a numeric parser agree on what counts as a digit, and that agreement is the same in every language.",
-  "input": {
-    "display": "\"\\u0663\" (ARABIC-INDIC DIGIT THREE, from Arabic-script keyboards/locales)",
-    "description": "A quantity, price, or phone-number field filled in using a non-Latin numeral system that is still, by Unicode's own definition, a decimal digit."
-  },
-  "what_goes_wrong": "In Python, \"\\u0663\".isdigit() is True, \"\\u0663\".isdecimal() is True, int(\"\\u0663\") == 3, and a bare regex r\"\\d\" matches it. In JavaScript, the ASCII-only /\\d/ regex does NOT match it, and both Number(\"\\u0663\") and parseInt(\"\\u0663\", 10) return NaN — the identical character is \"a valid number\" in one language's standard library and \"not a number at all\" in the other's.",
-  "why": "ARABIC-INDIC DIGIT THREE has General_Category Nd and Numeric_Type=Decimal, exactly like ASCII \"3\": it is a real decimal digit in its own numeral system. Python's int() accepts strings made of any Unicode decimal digits (category Nd), so int(\"\\u0663\") is 3 and int(\"\\u0663\\u0661\") is 31, and the re module's \\d matches any Nd character for str patterns unless re.ASCII is set. In JavaScript, \\d is defined as exactly [0-9], with or without the u or v flag, and Number()/parseInt() only accept ASCII digits in their string grammar, so the same character is rejected.",
-  "affects": [
-    "python",
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import re\ns = \"\\u0663\"\nprint(s.isdigit(), s.isdecimal())\nprint(int(s), int(s) == 3)\nprint(re.match(r\"^\\d+$\", s) is not None)\n",
-      "expected_output": "True True\n3 True\nTrue",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const s = \"\\u0663\";\nconsole.log(/^\\d+$/.test(s));\nconsole.log(Number(s), parseInt(s, 10));\n",
-      "expected_output": "false\nNaN NaN",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "If you intend \"ASCII digits only\", say so explicitly (Python: re.match(r\"\\d+\", s, re.ASCII); JavaScript's \\d already is ASCII-only). If you intend to accept any script's digits, normalize non-ASCII decimal digits to ASCII before further processing (Python's unicodedata.decimal() per character, or NFKC for digits that have compatibility decompositions) rather than relying on int()/Number() to agree across languages — they don't.",
-  "related": [
-    "nfkc-compatibility-folding",
-    "js-word-regex-ascii-only"
-  ],
-  "sources": [
-    {
-      "title": "UAX #44: Numeric_Type",
-      "url": "https://www.unicode.org/reports/tr44/#Numeric_Type"
-    },
-    {
-      "title": "ECMAScript spec: ToNumber applied to the String type",
-      "url": "https://tc39.es/ecma262/#sec-tonumber-applied-to-the-string-type"
-    },
-    {
-      "title": "ECMAScript spec: CharacterClassEscape (\\d)",
-      "url": "https://tc39.es/ecma262/#sec-characterclassescape"
-    },
-    {
-      "title": "Python docs: int()",
-      "url": "https://docs.python.org/3/library/functions.html#int"
-    },
-    {
-      "title": "Python docs: re (\\d)",
-      "url": "https://docs.python.org/3/library/re.html#regular-expression-syntax"
-    }
-  ],
-  "tags": [
-    "validation",
-    "forms",
-    "parsing",
-    "i18n",
-    "money"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "٣"
-      ],
-      "relation": "no_crash",
-      "note": "A \"digits only\" validator should either accept this consistently in both Python and JS or reject it consistently in both — not one and not the other, by accident of which language's \\d it used."
-    }
-  ]
-}

package/src/exhibits/unicode/bidi-override-filename-spoof.json

@@ -1,62 +0,0 @@
-{
-  "id": "bidi-override-filename-spoof",
-  "title": "A filename that ends in \".exe\" can display as if it ends in \".png\"",
-  "category": "unicode",
-  "assumption": "What a filename's extension check says and what a user sees when they look at the filename are the same thing.",
-  "input": {
-    "display": "\"invoice\\u202egnp.exe\" (RIGHT-TO-LEFT OVERRIDE, U+202E, inserted before the reversed tail \"gnp.exe\")",
-    "description": "An email attachment or download named by an attacker to look safe: a real file ending in a blocked extension, disguised by an embedded bidi control character."
-  },
-  "what_goes_wrong": "name.endswith(\".exe\") is True — the raw string genuinely ends in \".exe\" and a naive extension blocklist correctly flags it — but when this exact string is rendered by an OS file browser, email client, or terminal that honors bidi control characters, everything after U+202E is displayed right-to-left, so \"gnp.exe\" is painted in reverse as \"exe.png\": a human looking at the file sees what appears to be a harmless PNG, not the executable the code just correctly identified.",
-  "why": "U+202E (RIGHT-TO-LEFT OVERRIDE) is a Unicode bidirectional formatting control: it tells a bidi-aware renderer to lay out everything that follows as if it were right-to-left text, purely for display, with no effect on the underlying code point sequence or on any string method. This is the classic \"Unicode RLO\" spoof used to disguise malware extensions in the wild: the code's view of the string (and any endswith/regex check on it) is accurate and unaffected, which is precisely why the attack works on humans rather than on code — the mismatch is between what is stored and what a bidi-rendering surface draws, not a parsing bug.",
-  "affects": [
-    "python",
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "name = \"invoice\\u202egnp.exe\"\nprint(len(name), name.endswith(\".exe\"))\nprint(name.encode(\"unicode_escape\"))\n",
-      "expected_output": "15 True\nb'invoice\\\\u202egnp.exe'",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const name = \"invoice\\u202egnp.exe\";\nconsole.log(name.length, name.endsWith(\".exe\"));\nconsole.log(JSON.stringify(name));\n",
-      "expected_output": "15 true\n\"invoice‮gnp.exe\"",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Strip or reject Unicode bidirectional format characters (U+202A-U+202E, U+2066-U+2069) from filenames and other security-relevant display strings at the point of upload/creation, and never trust a rendered filename's apparent extension — always resolve the extension from the raw code point sequence.",
-  "related": [
-    "zalgo-combining-mark-stacking"
-  ],
-  "sources": [
-    {
-      "title": "Unicode Standard Annex #9: Unicode Bidirectional Algorithm",
-      "url": "https://www.unicode.org/reports/tr9/"
-    },
-    {
-      "title": "Big List of Naughty Strings (MIT)",
-      "url": "https://github.com/minimaxir/big-list-of-naughty-strings"
-    }
-  ],
-  "tags": [
-    "filename",
-    "upload",
-    "security",
-    "display",
-    "validation"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "invoice‮gnp.exe",
-        ".exe"
-      ],
-      "relation": "returns",
-      "expected": true,
-      "note": "their_function(name, ext) checking name.endsWith(ext) correctly returns true on the raw string — the vulnerability is that a human reading the rendered name will disagree with this correct answer."
-    }
-  ]
-}