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

package/src/exhibits/parsing/json-nan-infinity-not-valid-json.json

@@ -1,54 +0,0 @@
-{
-  "id": "json-nan-infinity-not-valid-json",
-  "title": "Python's json.dumps writes NaN and Infinity, which are not JSON - json.loads reads them back, JSON.parse throws",
-  "category": "parsing",
-  "assumption": "Whatever json.dumps() produces is, by definition, valid JSON that any JSON parser can read back.",
-  "input": {
-    "display": "json.dumps(float(\"nan\")) and json.dumps(float(\"inf\"))",
-    "description": "A computed statistic, average, or ratio that happens to divide by zero or otherwise become NaN/Infinity, serialized directly into an API response or log line without checking first."
-  },
-  "what_goes_wrong": "`json.dumps(float(\"nan\"))` returns the string `\"NaN\"` and `json.dumps(float(\"inf\"))` returns `\"Infinity\"` - neither token exists in the JSON grammar, so a strict JSON parser (including JavaScript's own `JSON.parse`) throws a syntax error reading data that Python itself happily produced and sent.",
-  "why": "The JSON spec (RFC 8259) defines numbers using only digits, an optional sign, decimal point, and exponent - `NaN` and `Infinity` are not part of that grammar. Python's `json.dumps` defaults to `allow_nan=True`, which intentionally emits the non-standard literals `NaN`, `Infinity`, and `-Infinity` for those float values rather than raising an error, prioritizing round-tripping Python floats over strict JSON compliance. `json.loads` on the Python side will happily read its own non-standard output back, which hides the incompatibility until something stricter - a browser's `JSON.parse`, another language's parser, a schema validator - receives it.",
-  "affects": [
-    "python",
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import json\ns_nan = json.dumps(float(\"nan\"))\ns_inf = json.dumps(float(\"inf\"))\nprint(s_nan, s_inf)\nprint(json.loads(s_nan))\ntry:\n    json.dumps(float(\"nan\"), allow_nan=False)\nexcept ValueError as e:\n    print(\"ValueError:\", e)\n",
-      "expected_output": "NaN Infinity\nnan\nValueError: Out of range float values are not JSON compliant: nan",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "try {\n  JSON.parse(\"NaN\");\n} catch (e) {\n  console.log(\"THROWS:\", e.message);\n}\ntry {\n  JSON.parse(\"Infinity\");\n} catch (e) {\n  console.log(\"THROWS:\", e.message);\n}\nconsole.log(JSON.stringify(NaN), JSON.stringify(Infinity));\n",
-      "expected_output": "THROWS: \"NaN\" is not valid JSON\nTHROWS: \"Infinity\" is not valid JSON\nnull null",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Call `json.dumps(value, allow_nan=False)` so Python raises immediately instead of emitting non-standard JSON, and decide explicitly how to represent a NaN/Infinity result (e.g. `null`, a sentinel string, or omit the field) before it reaches a serializer. Note JavaScript's own `JSON.stringify` already does the opposite - it silently turns `NaN`/`Infinity` into `null` rather than erroring - so the two languages fail in different directions here.",
-  "related": [
-    "json-big-integer-precision-loss"
-  ],
-  "sources": [
-    {
-      "title": "RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format",
-      "url": "https://www.rfc-editor.org/rfc/rfc8259"
-    },
-    {
-      "title": "Python docs: json - JSON encoder and decoder (allow_nan)",
-      "url": "https://docs.python.org/3/library/json.html#json.dump"
-    },
-    {
-      "title": "MDN: JSON.stringify()",
-      "url": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify"
-    }
-  ],
-  "tags": [
-    "json",
-    "parsing",
-    "validation",
-    "money"
-  ]
-}

package/src/exhibits/parsing/url-backslash-treated-as-slash-whatwg.json

@@ -1,60 +0,0 @@
-{
-  "id": "url-backslash-treated-as-slash-whatwg",
-  "title": "A backslash in an http(s) URL is silently treated as a forward slash by the browser's URL parser, but not by Python",
-  "category": "parsing",
-  "assumption": "A URL parser only treats \"/\" as a path separator, so a backslash in a URL string stays part of the host or path text it was written in.",
-  "input": {
-    "display": "http://example.com\\evil.com/path",
-    "description": "A URL built by concatenating a trusted base domain with user-controlled text that includes a backslash - deliberately, as an SSRF or open-redirect bypass attempt, or accidentally, from a Windows-style path pasted into a URL field."
-  },
-  "what_goes_wrong": "The WHATWG `URL` parser (used by every modern browser and by Node's global `URL`) treats the backslash exactly like a forward slash for `http`/`https` URLs, splitting the host at it: `new URL(\"http://example.com\\\\evil.com/path\").hostname` is `\"example.com\"` with pathname `\"/evil.com/path\"`. Python's `urllib.parse.urlparse` does not special-case backslashes at all, so it keeps `\"example.com\\\\evil.com\"` as one literal hostname string. The same input string resolves to a completely different host depending on which parser read it - a host-based allowlist check written against one parser's output can disagree with the HTTP client (or browser) that actually makes the request using the other's interpretation.",
-  "why": "The WHATWG URL Standard treats `\\` as equivalent to `/` only for \"special\" schemes (http, https, ws, wss, ftp, file), recording it as a validation error but continuing, because browsers historically normalized backslashes for compatibility with sloppy real-world URLs. For a non-special scheme the backslash is not a separator: `new URL(\"foo://example.com/a\\\\b\").pathname` keeps it as `/a\\\\b`. Python's `urllib.parse` follows the RFC 3986 generic syntax, in which a backslash is not a legal URI character at all - but `urlparse` does no character validation, so it simply leaves the backslash inside whatever component it lands in. Neither parser is misbehaving by its own spec; they just answer \"what host is this?\" differently for the same string.",
-  "affects": [
-    "javascript",
-    "any WHATWG-URL parser (browsers, Node's URL)",
-    "python (as the disagreeing side: urllib.parse keeps the backslash in the host)"
-  ],
-  "repros": [
-    {
-      "language": "javascript",
-      "code": "const u = new URL(\"http://example.com\\\\evil.com/path\");\nconsole.log(u.hostname, u.pathname);\n// only special schemes: a non-special scheme keeps the backslash in the path\nconst f = new URL(\"foo://example.com/a\\\\b\");\nconst h = new URL(\"http://example.com/a\\\\b\");\nconsole.log(f.pathname, h.pathname);\n",
-      "expected_output": "example.com /evil.com/path\n/a\\b /a/b",
-      "verified_with": "Node.js v22.22.2"
-    },
-    {
-      "language": "python",
-      "code": "from urllib.parse import urlparse\nu = urlparse(\"http://example.com\\\\evil.com/path\")\nprint(u.hostname, u.path)\n",
-      "expected_output": "example.com\\evil.com /path",
-      "verified_with": "Python 3.14.2"
-    }
-  ],
-  "fix": "Never build a trust decision (an SSRF allowlist, a same-origin check) against a hostname string parsed by one library if the request will actually be issued by a different URL-parsing implementation (a browser, a different HTTP client, another language's service). Normalize backslashes to forward slashes (or reject URLs containing them) before any parsing happens, consistently across every component that will touch the URL.",
-  "related": [
-    "url-userinfo-trusted-looking-host"
-  ],
-  "sources": [
-    {
-      "title": "WHATWG URL Standard: special schemes and path-segment separators",
-      "url": "https://url.spec.whatwg.org/#url-parsing"
-    },
-    {
-      "title": "Python docs: urllib.parse",
-      "url": "https://docs.python.org/3/library/urllib.parse.html"
-    }
-  ],
-  "tags": [
-    "url",
-    "parsing",
-    "security",
-    "validation"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "http://example.com\\evil.com/path"
-      ],
-      "relation": "no_crash",
-      "note": "their_extract_hostname(url) must be checked against the SAME parser that will actually dereference the URL - a hostname check written against one URL parser can be bypassed by a client that resolves backslashes differently."
-    }
-  ]
-}

package/src/exhibits/parsing/url-urlparse-never-raises-on-garbage.json

@@ -1,60 +0,0 @@
-{
-  "id": "url-urlparse-never-raises-on-garbage",
-  "title": "Python's urlparse doesn't raise on garbage - \"not a url\" parses \"successfully\" into an empty scheme and host",
-  "category": "parsing",
-  "assumption": "If a string isn't a valid URL, the URL-parsing function you call will raise an error, so \"it didn't throw\" is good evidence the input was a real URL.",
-  "input": {
-    "display": "not a url",
-    "description": "User-submitted text in a field that is supposed to be a URL (a profile link, a webhook target, a redirect destination), validated with `urlparse` and a check like `if result.netloc: ...` or simply `try: urlparse(x) except: reject`."
-  },
-  "what_goes_wrong": "`urlparse(\"not a url\")` does not raise - it returns a `ParseResult` with empty `scheme` and `netloc` and the whole input shoved into `.path`. JavaScript's `new URL(\"not a url\")` does the opposite: it throws `TypeError: Invalid URL` immediately, because the WHATWG algorithm requires an absolute URL (or a base to resolve against) and fails loudly otherwise.",
-  "why": "Python's `urllib.parse.urlparse` implements RFC 3986's generic syntax as a permissive, almost mechanical split on delimiter characters (`://`, `@`, `:`, `/`, `?`, `#`) - if the expected delimiters for scheme/netloc aren't present, it doesn't fail, it just leaves those fields empty and puts everything into whichever component comes last in the fallback order (`path`). It was designed to parse URI *references* (which may be relative, schemeless fragments) permissively, not to validate that a string is a complete, dereferenceable URL. The WHATWG `URL` constructor is deliberately the opposite: it exists specifically to parse (and validate) a resolvable URL, so it throws on anything that doesn't resolve to one. (It is not literally exception-free: an unbalanced IPv6 bracket such as `http://[::1` raises ValueError, and reading `.port` raises for an out-of-range port - but ordinary non-URL text goes straight through.)",
-  "affects": [
-    "python"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "from urllib.parse import urlparse\nr = urlparse(\"not a url\")\nprint(r)\nprint(bool(r.scheme), bool(r.netloc))\n",
-      "expected_output": "ParseResult(scheme='', netloc='', path='not a url', params='', query='', fragment='')\nFalse False",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "try {\n  const u = new URL(\"not a url\");\n  console.log(\"parsed\", u.href);\n} catch (e) {\n  console.log(\"THROWS:\", e.message);\n}\n",
-      "expected_output": "THROWS: Invalid URL",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Never treat \"urlparse didn't raise\" as proof of a valid URL in Python. Explicitly check that both `scheme` is one of the schemes you accept (e.g. `http`/`https`) and `netloc` is non-empty, or use a stricter validator before trusting the result.",
-  "related": [
-    "url-backslash-treated-as-slash-whatwg",
-    "url-userinfo-trusted-looking-host"
-  ],
-  "sources": [
-    {
-      "title": "Python docs: urllib.parse",
-      "url": "https://docs.python.org/3/library/urllib.parse.html"
-    },
-    {
-      "title": "WHATWG URL Standard: URL parsing failures",
-      "url": "https://url.spec.whatwg.org/#url-parsing"
-    }
-  ],
-  "tags": [
-    "url",
-    "parsing",
-    "validation",
-    "forms",
-    "security"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "not a url"
-      ],
-      "relation": "no_crash",
-      "note": "their_is_valid_url(text) must explicitly reject this - checking only whether urlparse() raised is not enough, since urlparse never raises on this input."
-    }
-  ]
-}

package/src/exhibits/parsing/url-userinfo-trusted-looking-host.json

@@ -1,60 +0,0 @@
-{
-  "id": "url-userinfo-trusted-looking-host",
-  "title": "\"http://trusted.com@evil.com/\" goes to evil.com, not trusted.com - and both languages' real parsers already know that",
-  "category": "parsing",
-  "assumption": "A URL string that starts with (or contains) \"trusted.com\" points at trusted.com.",
-  "input": {
-    "display": "http://trusted.com@evil.com/",
-    "description": "A link in a phishing email, a redirect parameter, or a webhook target URL that a naive check validates by looking for a trusted domain name somewhere in the string - `url.startsWith(\"http://trusted.com\")` or a regex containing `trusted\\.com`."
-  },
-  "what_goes_wrong": "A substring/prefix check for \"trusted.com\" passes on `http://trusted.com@evil.com/`, but the browser (or any real HTTP client) actually connects to `evil.com` - `trusted.com` here is just userinfo (a username with no password), not the host, and both a proper WHATWG `URL` parse and Python's `urlparse` agree the real host is `evil.com`.",
-  "why": "RFC 3986's authority component has the shape `userinfo@host:port` - everything before an `@` in the authority is credentials, not part of the hostname, and both a real URL parser and the browser's address bar logic strip it before deciding where to connect. A regex or `startsWith` check that only looks for the trusted domain's text anywhere near the front of the string has no concept of URL grammar at all, so it is fooled by a syntax feature (`@`) that every conformant parser already understands correctly. This is not a parser disagreement - it's a gap between \"looks like it mentions the right domain\" and \"actually parses to the right host\".",
-  "affects": [
-    "python",
-    "javascript",
-    "any string-based (non-parsing) URL trust check"
-  ],
-  "repros": [
-    {
-      "language": "javascript",
-      "code": "const u = new URL(\"http://trusted.com@evil.com/\");\nconsole.log(u.hostname, u.username);\nconsole.log(\"http://trusted.com@evil.com/\".startsWith(\"http://trusted.com\"));\n",
-      "expected_output": "evil.com trusted.com\ntrue",
-      "verified_with": "Node.js v22.22.2"
-    },
-    {
-      "language": "python",
-      "code": "from urllib.parse import urlparse\nu = urlparse(\"http://trusted.com@evil.com/\")\nprint(u.hostname, u.username)\nprint(\"http://trusted.com@evil.com/\".startswith(\"http://trusted.com\"))\n",
-      "expected_output": "evil.com trusted.com\nTrue",
-      "verified_with": "Python 3.14.2"
-    }
-  ],
-  "fix": "Never validate a URL's target by substring or prefix matching on the raw string. Parse the URL and compare the parsed `.hostname` against an allowlist of exact hostnames (or a proper suffix match on the hostname component specifically, e.g. ends with `.trusted.com`), never against the whole URL text.",
-  "related": [
-    "url-backslash-treated-as-slash-whatwg"
-  ],
-  "sources": [
-    {
-      "title": "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax, Section 3.2",
-      "url": "https://www.rfc-editor.org/rfc/rfc3986#section-3.2"
-    },
-    {
-      "title": "WHATWG URL Standard",
-      "url": "https://url.spec.whatwg.org/"
-    }
-  ],
-  "tags": [
-    "url",
-    "parsing",
-    "security",
-    "validation"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "http://trusted.com@evil.com/"
-      ],
-      "relation": "no_crash",
-      "note": "their_is_trusted_url(url) must parse the URL and check the hostname field - not check whether the string contains or starts with the trusted domain's text - or this input will pass a check it should fail."
-    }
-  ]
-}

package/src/exhibits/sorting/accented-letters-sort-after-z.json

@@ -1,63 +0,0 @@
-{
-  "id": "accented-letters-sort-after-z",
-  "title": "\"äpple\" sorts after \"zebra\" with a default sort",
-  "category": "sorting",
-  "assumption": "An accented letter sorts next to its unaccented counterpart — \"äpple\" belongs near \"apple\", not off at the end of the alphabet.",
-  "input": {
-    "display": "[\"zebra\", \"äpple\", \"apple\"]",
-    "description": "A product or name list containing a word with a diacritic, sorted with the default (non-locale-aware) string comparison."
-  },
-  "what_goes_wrong": "The default sort returns [\"apple\", \"zebra\", \"äpple\"] — \"äpple\" lands after \"zebra\", not next to \"apple\" where a human alphabetizing by the base letter would put it.",
-  "why": "\"ä\" is U+00E4, a higher value than \"z\" (U+007A): the Latin-1 Supplement block, where most Western European accented letters live, comes entirely after the ASCII lowercase letters. Python's default string comparison orders by code point and JavaScript's by UTF-16 code unit (the same thing for these characters), so neither knows that \"ä\" is a variant of \"a\" in most European alphabets. Only a locale-aware collator knows that relationship.",
-  "affects": [
-    "python",
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "words = [\"zebra\", \"\\u00e4pple\", \"apple\"]\nprint(sorted(words))\n",
-      "expected_output": "['apple', 'zebra', 'äpple']",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const words = [\"zebra\", \"\\u00e4pple\", \"apple\"];\nconsole.log(words.slice().sort());\nconsole.log(words.slice().sort((a, b) => a.localeCompare(b)));\n",
-      "expected_output": "[ 'apple', 'zebra', 'äpple' ]\n[ 'apple', 'äpple', 'zebra' ]",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Use a locale-aware comparator for any text a human will read: Intl.Collator or String.prototype.localeCompare() in JavaScript. Python's standard library has no built-in Unicode collation; it requires either the system locale module (environment-dependent) or a third-party ICU binding.",
-  "related": [
-    "byte-order-caps-before-lowercase",
-    "locale-collation-de-vs-sv"
-  ],
-  "sources": [
-    {
-      "title": "Unicode Standard Annex #10: Unicode Collation Algorithm",
-      "url": "https://www.unicode.org/reports/tr10/"
-    },
-    {
-      "title": "MDN: String.prototype.localeCompare()",
-      "url": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/localeCompare"
-    }
-  ],
-  "tags": [
-    "sorting",
-    "comparison",
-    "names",
-    "i18n",
-    "display"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "zebra",
-        "äpple"
-      ],
-      "relation": "returns",
-      "expected": false,
-      "note": "their_function(a, b) as a human-order \"a sorts before b\" test should return false: äpple belongs before zebra. Raw `a < b` returns true here, which is the trap."
-    }
-  ]
-}

package/src/exhibits/sorting/byte-order-caps-before-lowercase.json

@@ -1,66 +0,0 @@
-{
-  "id": "byte-order-caps-before-lowercase",
-  "title": "\"Zebra\" sorts before \"apple\" by default",
-  "category": "sorting",
-  "assumption": "Sorting a list of names or words alphabetically puts them in the order a person would expect: apple, then zebra.",
-  "input": {
-    "display": "[\"Zebra\", \"apple\", \"Mango\", \"banana\"]",
-    "description": "A list of user-entered names, tags, or product titles with inconsistent capitalization, sorted with the language's default string comparison for a dropdown or report."
-  },
-  "what_goes_wrong": "The default sort returns [\"Mango\", \"Zebra\", \"apple\", \"banana\"] — every capitalized word sorts before every lowercase word, so \"Zebra\" ends up before \"apple\" even though no human alphabetizing this list would ever do that.",
-  "why": "Python's default string comparison orders characters by Unicode code point and JavaScript's by UTF-16 code unit; for ASCII letters both are the same as byte order. The uppercase letters A-Z (U+0041-U+005A) all come before the lowercase letters a-z (U+0061-U+007A), so a word starting with a capital sorts before every word starting with a lowercase ASCII letter, because the comparison is settled at the first character where the two strings differ and here that is the first letter.",
-  "affects": [
-    "python",
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "words = [\"Zebra\", \"apple\", \"Mango\", \"banana\"]\nprint(sorted(words))\nprint(\"Zebra\" < \"apple\")\n",
-      "expected_output": "['Mango', 'Zebra', 'apple', 'banana']\nTrue",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const words = [\"Zebra\", \"apple\", \"Mango\", \"banana\"];\nconsole.log(words.slice().sort());\nconsole.log(\"Zebra\" < \"apple\");\n",
-      "expected_output": "[ 'Mango', 'Zebra', 'apple', 'banana' ]\ntrue",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Sort case-insensitively for anything a human will read: key on the lowercased (or casefolded) string, or use a locale-aware comparator (Intl.Collator in JS; Python has no case-insensitive built-in comparator, so pass key=str.casefold to sorted()).",
-  "related": [
-    "accented-letters-sort-after-z",
-    "case-insensitive-sort-lower-vs-casefold"
-  ],
-  "sources": [
-    {
-      "title": "Unicode Standard: Code Charts, Basic Latin block",
-      "url": "https://www.unicode.org/charts/PDF/U0000.pdf"
-    },
-    {
-      "title": "Python docs: Comparisons (str ordering is by code point)",
-      "url": "https://docs.python.org/3/reference/expressions.html#comparisons"
-    },
-    {
-      "title": "ECMA-262: Array.prototype.sort, default SortCompare",
-      "url": "https://tc39.es/ecma262/#sec-array.prototype.sort"
-    }
-  ],
-  "tags": [
-    "sorting",
-    "comparison",
-    "names",
-    "display"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "Zebra",
-        "apple"
-      ],
-      "relation": "returns",
-      "expected": false,
-      "note": "their_function(a, b) as a display-order \"a sorts before b\" test should return false: apple belongs before Zebra. Raw `a < b` returns true here, which is the trap."
-    }
-  ]
-}

package/src/exhibits/sorting/case-insensitive-sort-lower-vs-casefold.json

@@ -1,56 +0,0 @@
-{
-  "id": "case-insensitive-sort-lower-vs-casefold",
-  "title": "Switching a sort key from .lower() to .casefold() changes the order of unrelated-looking rows",
-  "category": "sorting",
-  "assumption": "lower() and casefold() are interchangeable ways to spell \"case-insensitive sort key\" — swapping one for the other can only change case-sensitivity bugs, never the actual ordering of already-matching rows.",
-  "input": {
-    "display": "[\"Stra\\u00dfe\", \"strasse\", \"Strasse\"] sorted with key=str.lower vs key=str.casefold",
-    "description": "A list of street-name or username variants containing German ß, sorted case-insensitively for display or dedup grouping."
-  },
-  "what_goes_wrong": "sorted(words, key=str.lower) returns [\"strasse\", \"Strasse\", \"Stra\\u00dfe\"]: \"Stra\\u00dfe\" sorts last, after both ASCII spellings. sorted(words, key=str.casefold) returns [\"Stra\\u00dfe\", \"strasse\", \"Strasse\"]: \"Stra\\u00dfe\" now sorts FIRST. The three rows are the same; only the key function changed. JavaScript shows the same flip between a toLowerCase() comparator and an Intl.Collator with sensitivity \"base\".",
-  "why": "str.lower() leaves ß as ß, so the key for \"Straße\" is \"straße\", which differs from \"strasse\" at the fifth character; ß (U+00DF) is a higher code point than \"s\", so it sorts after both ASCII spellings. str.casefold() applies Unicode full case folding (CaseFolding.txt), which maps ß to \"ss\", so the key for \"Straße\" becomes \"strasse\", identical to the other two rows' keys. With all three keys tied, Python's stable sort keeps the rows in input order, which is why \"Straße\" (first in the input) comes out first instead of last. JavaScript has no casefold(), but the same shift happens when a comparator moves from toLowerCase() to an Intl.Collator with sensitivity \"base\", which also treats ß and ss as equal.",
-  "affects": [
-    "python",
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "words = [\"Stra\\u00dfe\", \"strasse\", \"Strasse\"]\nprint(sorted(words, key=str.lower))\nprint(sorted(words, key=str.casefold))\n",
-      "expected_output": "['strasse', 'Strasse', 'Straße']\n['Straße', 'strasse', 'Strasse']",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const words = [\"Stra\\u00dfe\", \"strasse\", \"Strasse\"];\nconst byLower = (a, b) => { const x = a.toLowerCase(), y = b.toLowerCase(); return x < y ? -1 : x > y ? 1 : 0; };\nconsole.log(words.slice().sort(byLower));\nconsole.log(words.slice().sort(new Intl.Collator(\"en\", { sensitivity: \"base\" }).compare));\n",
-      "expected_output": "[ 'strasse', 'Strasse', 'Straße' ]\n[ 'Straße', 'strasse', 'Strasse' ]",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Decide deliberately whether your case-insensitive key should treat folding equivalences like \\u00df\\u2192ss as ties, and know that changing the folding function (lower() vs casefold() in Python, toLowerCase() vs a base-sensitivity Intl.Collator in JavaScript) can change sort order, not just equality. If the final order must be deterministic, add a tiebreaker (for example the original string) after the case-insensitive key: key=lambda s: (s.casefold(), s).",
-  "related": [
-    "german-eszett-case-fold",
-    "byte-order-caps-before-lowercase"
-  ],
-  "sources": [
-    {
-      "title": "Python docs: str.casefold",
-      "url": "https://docs.python.org/3/library/stdtypes.html#str.casefold"
-    },
-    {
-      "title": "Unicode Standard: CaseFolding.txt",
-      "url": "https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt"
-    },
-    {
-      "title": "MDN: Intl.Collator() constructor, sensitivity option",
-      "url": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Collator/Collator"
-    }
-  ],
-  "tags": [
-    "sorting",
-    "comparison",
-    "names",
-    "i18n",
-    "normalization"
-  ]
-}

package/src/exhibits/sorting/comparator-returns-boolean-js.json

@@ -1,49 +0,0 @@
-{
-  "id": "comparator-returns-boolean-js",
-  "title": "arr.sort((a, b) => a > b) can leave an array completely unsorted",
-  "category": "sorting",
-  "assumption": "A sort comparator just needs to return something truthy when the first argument should come after the second.",
-  "input": {
-    "display": "[5, 3, 8, 1, 9, 2, 7, 4, 6].sort((a, b) => a > b)",
-    "description": "A comparator written the way a boolean-returning comparison reads naturally in prose (\"is a bigger than b\"), instead of returning a signed number."
-  },
-  "what_goes_wrong": "In Node.js (V8), sort((a, b) => a > b) on this 9-element array returns it unchanged, [5, 3, 8, 1, 9, 2, 7, 4, 6], while the numeric comparator sort((a, b) => a - b) returns it fully sorted. No error, no warning.",
-  "why": "A sort comparator must return a number: negative if a comes first, positive if b comes first, zero if either order is fine. A boolean is converted with ToNumber to 1 or 0, so this comparator can never say \"a comes first\". That makes it inconsistent (it reports 1 and 5 as equal but 5 and 1 as ordered), and for an inconsistent comparator the ECMAScript spec says the resulting order is implementation-defined, so what you get depends on the engine. V8's TimSort (Node.js 11+, Chrome 70+) only moves an element after a negative result; this comparator never returns one, so in V8 the whole input is treated as one already-sorted run and comes back in its original order. Older V8 versions and other engines use different algorithms and may return a partly sorted array instead, which is harder to notice in testing.",
-  "affects": [
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "data = [5, 3, 8, 1, 9, 2, 7, 4, 6]\nprint(sorted(data))\n",
-      "expected_output": "[1, 2, 3, 4, 5, 6, 7, 8, 9]",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const data = [5, 3, 8, 1, 9, 2, 7, 4, 6];\nconsole.log(data.slice().sort((a, b) => a > b));\nconsole.log(data.slice().sort((a, b) => a - b));\n",
-      "expected_output": "[\n  5, 3, 8, 1, 9,\n  2, 7, 4, 6\n]\n[\n  1, 2, 3, 4, 5,\n  6, 7, 8, 9\n]",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Always return a signed number from a JavaScript sort comparator (a - b for numbers), never a boolean. Python's sorted()/list.sort() sidestep this entirely — Python 3 removed the old cmp= parameter and only accepts a key= function, so there is no comparator-return-type footgun to have.",
-  "related": [
-    "nan-in-sort"
-  ],
-  "sources": [
-    {
-      "title": "ECMA-262: Array.prototype.sort, comparator requirements",
-      "url": "https://tc39.es/ecma262/#sec-array.prototype.sort"
-    },
-    {
-      "title": "MDN: Array.prototype.sort() — description of compareFn",
-      "url": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort#description"
-    }
-  ],
-  "tags": [
-    "sorting",
-    "comparison",
-    "pagination",
-    "display"
-  ]
-}

package/src/exhibits/sorting/js-array-sort-stringifies-numbers.json

@@ -1,68 +0,0 @@
-{
-  "id": "js-array-sort-stringifies-numbers",
-  "title": "[10, 9, 1].sort() returns [1, 10, 9]",
-  "category": "sorting",
-  "assumption": "Calling .sort() on an array of numbers sorts them numerically.",
-  "input": {
-    "display": "[10, 9, 1].sort()",
-    "description": "Sorting a plain JavaScript array of numbers (scores, counts, prices) without passing a comparator — the single most common sort call in JavaScript."
-  },
-  "what_goes_wrong": "[10, 9, 1].sort() returns [1, 10, 9] — not [1, 9, 10]. 10 sorts before 9.",
-  "why": "When no comparator is supplied, the ECMAScript spec has Array.prototype.sort() convert each element to a string and compare the strings (undefined values are set aside and placed at the end). It is never numeric unless you pass a comparator. As strings, \"10\" < \"9\" is true, because \"1\" has a lower code unit than \"9\" and string comparison stops at the first differing character, so 10 sorts before 9. Python's sorted() compares the numbers themselves, so this failure does not exist there.",
-  "affects": [
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "print(sorted([10, 9, 1]))\n",
-      "expected_output": "[1, 9, 10]",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "console.log([10, 9, 1].sort());\nconsole.log([10, 9, 1].sort((a, b) => a - b));\n",
-      "expected_output": "[ 1, 10, 9 ]\n[ 1, 9, 10 ]",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Always pass an explicit numeric comparator to Array.prototype.sort() when sorting numbers: arr.sort((a, b) => a - b). There is no \"numeric mode\" flag — the comparator is the only way to opt out of string comparison.",
-  "related": [
-    "natural-sort-breaks-lexicographic",
-    "typed-array-sort-is-numeric-by-default"
-  ],
-  "sources": [
-    {
-      "title": "ECMA-262: Array.prototype.sort, default SortCompare behavior",
-      "url": "https://tc39.es/ecma262/#sec-array.prototype.sort"
-    },
-    {
-      "title": "MDN: Array.prototype.sort()",
-      "url": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort"
-    }
-  ],
-  "tags": [
-    "sorting",
-    "comparison",
-    "display",
-    "pagination"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        [
-          10,
-          9,
-          1
-        ]
-      ],
-      "relation": "returns",
-      "expected": [
-        1,
-        9,
-        10
-      ],
-      "note": "A numeric sort should return [1, 9, 10]. An implementation that calls arr.sort() with no comparator returns [1, 10, 9]."
-    }
-  ]
-}

package/src/exhibits/sorting/locale-collation-de-vs-sv.json

@@ -1,54 +0,0 @@
-{
-  "id": "locale-collation-de-vs-sv",
-  "title": "The same three letters sort in a different order in German than in Swedish",
-  "category": "sorting",
-  "assumption": "Locale-aware sorting just fixes the \"accents sort wrong\" problem the same way for every language.",
-  "input": {
-    "display": "[\"z\", \"\\u00e4\", \"a\"].sort with localeCompare(..., \"de\") vs localeCompare(..., \"sv\")",
-    "description": "A single sort function applied to the same three-letter list, parameterized only by a BCP 47 locale tag — e.g. a user-preference-driven \"sort my contacts\" feature."
-  },
-  "what_goes_wrong": "localeCompare with locale \"de\" (German) sorts the list as [\"a\", \"\\u00e4\", \"z\"] — ä treated as a minor variant of a, placed right next to it. localeCompare with locale \"sv\" (Swedish) sorts the exact same list as [\"a\", \"z\", \"\\u00e4\"] — ä treated as its own letter, placed after z. There is no single \"correct\" locale-aware order; it depends entirely on which locale you pass.",
-  "why": "German collation in CLDR (the data behind ICU and JavaScript's Intl) uses the Unicode default ordering with no tailoring: ä is an a with an accent difference, so it sorts right next to a, which matches German dictionary order (DIN 5007-1). CLDR also has a German phonebook variant (de-u-co-phonebk) that sorts ä as \"ae\". Swedish treats å, ä and ö as separate letters at the end of the alphabet, after z, and the Swedish CLDR collation tailors them there. Both are correct for their own language; a collator has to be told which one to use through its locale argument, and a wrong or missing locale applies one language's rules to another's text. Python's sorted() in the repro is plain code-point order, which happens to agree with Swedish here only because ä (U+00E4) is numerically after z.",
-  "affects": [
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "words = [\"z\", \"\\u00e4\", \"a\"]\nprint(sorted(words))\n",
-      "expected_output": "['a', 'z', 'ä']",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const words = [\"z\", \"\\u00e4\", \"a\"];\nconsole.log(words.slice().sort((a, b) => a.localeCompare(b, \"de\")));\nconsole.log(words.slice().sort((a, b) => a.localeCompare(b, \"sv\")));\nconsole.log(words.slice().sort());\n",
-      "expected_output": "[ 'a', 'ä', 'z' ]\n[ 'a', 'z', 'ä' ]\n[ 'a', 'z', 'ä' ]",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Always pass the user's actual locale to the collator rather than relying on a default; never assume one European locale's alphabetical order generalizes to another's. JavaScript ships this via Intl.Collator/localeCompare with a locale argument; Python's standard library has no bundled Unicode collation tables, so matching this behavior requires the system's installed locale data (unreliable across machines) or a third-party ICU binding.",
-  "related": [
-    "accented-letters-sort-after-z"
-  ],
-  "sources": [
-    {
-      "title": "Unicode Technical Standard #10: Unicode Collation Algorithm",
-      "url": "https://www.unicode.org/reports/tr10/"
-    },
-    {
-      "title": "MDN: Intl.Collator",
-      "url": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Collator"
-    },
-    {
-      "title": "CLDR collation charts",
-      "url": "https://www.unicode.org/cldr/charts/latest/collation/index.html"
-    }
-  ],
-  "tags": [
-    "sorting",
-    "comparison",
-    "names",
-    "i18n",
-    "display"
-  ]
-}