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

package/src/exhibits/float-money/tofixed-2-345-inconsistent-rounding.json

@@ -1,64 +0,0 @@
-{
-  "id": "tofixed-2-345-inconsistent-rounding",
-  "title": "2.345 rounds UP to 2.35 while 1.005 rounds DOWN to 1.00 - same \"x.xx5\" shape, opposite outcome",
-  "category": "float-money",
-  "assumption": "Any price ending in exactly half a cent (x.xx5) rounds the same way - either always up, or always down.",
-  "input": {
-    "display": "(2.345).toFixed(2) vs (1.005).toFixed(2)",
-    "description": "Two different prices that both look like a clean half-cent boundary, rounded to cents for display."
-  },
-  "what_goes_wrong": "2.345 rounds to \"2.35\" (up) but 1.005 rounds to \"1.00\" (down), even though both are written with the same \"value.value5\" shape - there is no way to predict which direction a given half-cent literal will round without checking its actual binary value.",
-  "why": "Neither 2.345 nor 1.005 is exactly representable in IEEE-754 double. 2.345's nearest double happens to be a hair above 2.345 (2.34500000000000019540...), so it's not actually a tie and rounds up; 1.005's nearest double happens to be a hair below 1.005 (1.00499999999999989341...), so it rounds down. Both languages round the true stored binary value, not the decimal text you typed, and whether a given literal lands slightly above or below its decimal value is essentially unpredictable without inspecting the bits.",
-  "affects": [
-    "javascript",
-    "python",
-    "any IEEE-754 double formatted by rounding its true binary value"
-  ],
-  "repros": [
-    {
-      "language": "javascript",
-      "code": "console.log((2.345).toFixed(2), (2.345).toFixed(20));\nconsole.log((1.005).toFixed(2), (1.005).toFixed(20));\n",
-      "expected_output": "2.35 2.34500000000000019540\n1.00 1.00499999999999989342",
-      "verified_with": "Node.js v22.22.2"
-    },
-    {
-      "language": "python",
-      "code": "for x in (2.345, 1.005):\n    print(f\"{x:.2f}\", f\"{x:.20f}\")\n",
-      "expected_output": "2.35 2.34500000000000019540\n1.00 1.00499999999999989342",
-      "verified_with": "Python 3.14.2"
-    }
-  ],
-  "fix": "Never treat float literals as exact decimal values for money. Round and store amounts as integer minor units, or construct a Decimal from the original decimal string (not from a float), so rounding operates on the number you actually meant.",
-  "related": [
-    "tofixed-1-005-rounds-down-not-up",
-    "python-round-2-675-float-imprecision"
-  ],
-  "sources": [
-    {
-      "title": "ECMA-262: Number.prototype.toFixed",
-      "url": "https://tc39.es/ecma262/#sec-number.prototype.tofixed"
-    },
-    {
-      "title": "Python docs: 15.1. Floating-Point Arithmetic: Issues and Limitations",
-      "url": "https://docs.python.org/3/tutorial/floatingpoint.html"
-    }
-  ],
-  "tags": [
-    "money",
-    "rounding",
-    "price",
-    "currency",
-    "invoice",
-    "display"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "1.005"
-      ],
-      "relation": "returns",
-      "expected": "1.01",
-      "note": "A money-rounding function that takes the exact decimal string \"1.005\" and rounds half-cents up should return \"1.01\" - if it instead parses to a float first and formats with toFixed, it will silently return \"1.00\"."
-    }
-  ]
-}

package/src/exhibits/integers/array-index-above-2-32-2-not-an-index.json

@@ -1,42 +0,0 @@
-{
-  "id": "array-index-above-2-32-2-not-an-index",
-  "title": "arr[4294967295] = x does not grow a JavaScript array's length, but arr[4294967294] = x does",
-  "category": "integers",
-  "assumption": "Any non-negative integer you assign as an array subscript is a real array index that updates .length.",
-  "input": {
-    "display": "arr[2**32 - 2] = \"a\" updates .length to 2**32 - 1; arr[2**32 - 1] = \"b\" does NOT update .length at all",
-    "description": "Computing a very large array index programmatically (from a hash, an offset calculation, or a bug) and writing to it, expecting ordinary array growth semantics."
-  },
-  "what_goes_wrong": "Writing to what looks like 'one past the last valid huge index' silently creates an ordinary (non-index) property on the array object instead of extending the array, so `.length`, `for` loops bounded by `.length`, and array methods like `.forEach` never see that value at all.",
-  "why": "The ECMAScript spec defines an 'array index' as a string that is a canonical numeric representation of an integer in the range 0 to 2^32 - 2 inclusive -- 2^32 - 1 is deliberately excluded, because an array's `.length` is always an integer from 0 to 2^32 - 1 (setting it to 2^32 throws `RangeError`) and must be able to hold 'one past the largest index'. So the largest valid index is 2^32 - 2; assigning to 2^32 - 1 is legal (arrays allow arbitrary property keys) but does not count as an array index and therefore never triggers the `.length`-update behavior that real index assignment does.",
-  "affects": [
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "javascript",
-      "code": "const arr = [];\narr[4294967294] = \"a\"; // 2**32 - 2, the largest valid array index\nconsole.log(\"after valid index:\", arr.length);\narr[4294967295] = \"b\"; // 2**32 - 1, NOT a valid array index\nconsole.log(\"after 2**32 - 1:\", arr.length);\nconsole.log(\"both keys present:\", (4294967294 in arr), (4294967295 in arr));\nconsole.log(\"own enumerable keys:\", Object.keys(arr).length);\n",
-      "expected_output": "after valid index: 4294967295\nafter 2**32 - 1: 4294967295\nboth keys present: true true\nown enumerable keys: 2",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Never compute an array index without bounds-checking it against 2^32 - 2 first; if a value might legitimately be that large, use a Map or plain object keyed by string/number instead of relying on native array index semantics.",
-  "related": [
-    "max-safe-integer-plus-one-equals-plus-two"
-  ],
-  "sources": [
-    {
-      "title": "ECMA-262: Array index definition",
-      "url": "https://tc39.es/ecma262/#array-index"
-    },
-    {
-      "title": "ECMA-262: Array Exotic Objects (length invariants)",
-      "url": "https://tc39.es/ecma262/#sec-array-exotic-objects"
-    }
-  ],
-  "tags": [
-    "validation",
-    "database"
-  ],
-  "test_cases": []
-}

package/src/exhibits/integers/bigint-number-mixing-typeerror.json

@@ -1,49 +0,0 @@
-{
-  "id": "bigint-number-mixing-typeerror",
-  "title": "10n + 5 throws TypeError instead of just giving you 15",
-  "category": "integers",
-  "assumption": "Any two things that look like numbers can be added together directly.",
-  "input": {
-    "display": "10n + 5",
-    "description": "Mixing a value that came from a BigInt-returning source (e.g. a large parsed id, `Number.MAX_SAFE_INTEGER` workaround, or a library that returns BigInt) with an ordinary numeric literal elsewhere in arithmetic."
-  },
-  "what_goes_wrong": "Introducing a single `BigInt` value into a codebase that otherwise uses plain `number` breaks at the first arithmetic operation that mixes the two, with a runtime `TypeError` rather than a silent or compile-time-caught issue.",
-  "why": "`BigInt` and `Number` are deliberately kept as separate, non-interoperable types in JavaScript: implicitly coercing one to the other would either lose a BigInt's exactness (converting to Number) or silently change comparison/arithmetic semantics, so the spec requires an explicit conversion (`BigInt(5)` or `Number(10n)`) before the two can be combined with `+`, `-`, `*`, etc. (Comparison operators like `<` and `==` are a deliberate exception and do work across the two types.)",
-  "affects": [
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "javascript",
-      "code": "try {\n  console.log(10n + 5);\n} catch (e) {\n  console.log(e.constructor.name + ':', e.message);\n}\nconsole.log(10n + BigInt(5));\nconsole.log(10n < 20); // comparison operators DO mix the types\n",
-      "expected_output": "TypeError: Cannot mix BigInt and other types, use explicit conversions\n15n\ntrue",
-      "verified_with": "Node.js v22.22.2"
-    },
-    {
-      "language": "python",
-      "code": "# Python has only one built-in integer type, so there is nothing to mix:\n# int already has unlimited precision, no separate 'big integer' type exists.\nprint(10 + 5, type(10 + 5))\n",
-      "expected_output": "15 <class 'int'>",
-      "verified_with": "Python 3.14.2"
-    }
-  ],
-  "fix": "Convert explicitly at the boundary where a value becomes a BigInt (or stays a Number) and keep the two types from mixing in arithmetic; don't let a single BigInt-returning call silently propagate into number-typed code.",
-  "related": [
-    "max-safe-integer-plus-one-equals-plus-two"
-  ],
-  "sources": [
-    {
-      "title": "MDN: BigInt",
-      "url": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt"
-    },
-    {
-      "title": "ECMA-262: BigInt operators",
-      "url": "https://tc39.es/ecma262/#sec-ecmascript-language-expressions"
-    }
-  ],
-  "tags": [
-    "id",
-    "parsing",
-    "validation"
-  ],
-  "test_cases": []
-}

package/src/exhibits/integers/bitwise-32-bit-truncation.json

@@ -1,56 +0,0 @@
-{
-  "id": "bitwise-32-bit-truncation",
-  "title": "~~ and |0 quietly turn a large number negative",
-  "category": "integers",
-  "assumption": "~~x and x|0 are safe, fast shortcuts for 'truncate x to an integer' that work for any number.",
-  "input": {
-    "display": "(2**31) | 0 === -2147483648; ~~(2**31) === -2147483648",
-    "description": "A common micro-optimization idiom (`~~x` or `x | 0` instead of `Math.trunc(x)` / `Math.floor(x)`) applied to a value that turns out to be at or above 2^31, such as a pixel coordinate, a large counter, or a computed array size."
-  },
-  "what_goes_wrong": "A value that should just be truncated toward zero (like `Math.trunc` would do) instead flips to a large negative number once it reaches 2^31, because the 'fast truncate' idiom is secretly doing 32-bit signed integer conversion, not generic truncation.",
-  "why": "The bitwise operators `~`, `|`, `&`, `^`, `<<` and `>>` first convert their (left) operands to a 32-bit signed integer (via ToInt32, which wraps modulo 2^32 and then reinterprets the top bit as the sign). `~~x` is just `~(~x)`, double bitwise-NOT, which forces this same 32-bit conversion twice and happens to cancel the bit-flip, leaving the ToInt32 result -- so both idioms silently wrap any value outside the 32-bit signed range [-2^31, 2^31 - 1] instead of just dropping its fractional part. The unsigned shift `>>>` uses ToUint32 instead, so `x >>> 0` wraps into [0, 2^32 - 1] rather than going negative (`-1 >>> 0` is 4294967295).",
-  "affects": [
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "javascript",
-      "code": "console.log((2 ** 31) | 0);\nconsole.log(~~(2 ** 31));\nconsole.log(Math.trunc(2 ** 31)); // the actually-safe way to truncate\nconsole.log((-5.7) | 0, ~~(-5.7)); // for in-range values, both idioms do look like truncation\n",
-      "expected_output": "-2147483648\n-2147483648\n2147483648\n-5 -5",
-      "verified_with": "Node.js v22.22.2"
-    },
-    {
-      "language": "python",
-      "code": "# Python has no implicit 32-bit integer conversion; ints are arbitrary precision\n# unless you explicitly wrap them (see the struct/ctypes exhibit).\nprint(2**31)\nprint(int(2**31))  # no truncation needed, no wraparound\n",
-      "expected_output": "2147483648\n2147483648",
-      "verified_with": "Python 3.14.2"
-    }
-  ],
-  "fix": "Use `Math.trunc()` (or `Math.floor()`/`Math.round()` as appropriate) to truncate a number, and reserve bitwise operators for values you know fit in 32 bits (e.g. actual bit flags, not general arithmetic results).",
-  "related": [
-    "python-unbounded-int-vs-fixed-width-wrap"
-  ],
-  "sources": [
-    {
-      "title": "ECMA-262: ToInt32",
-      "url": "https://tc39.es/ecma262/#sec-toint32"
-    },
-    {
-      "title": "MDN: Bitwise NOT (~)",
-      "url": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Bitwise_NOT"
-    }
-  ],
-  "tags": [
-    "validation",
-    "parsing"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        2147483648
-      ],
-      "relation": "no_crash",
-      "note": "A 'truncate to integer' helper should not flip sign for inputs at or above 2^31; compare against Math.trunc."
-    }
-  ]
-}

package/src/exhibits/integers/bool-is-int-subclass-dict-key-collision.json

@@ -1,58 +0,0 @@
-{
-  "id": "bool-is-int-subclass-dict-key-collision",
-  "title": "{1: \"a\", True: \"b\"} has only one key in Python, because True equals 1",
-  "category": "integers",
-  "assumption": "A boolean key and an integer key in a dictionary are always distinct entries, since booleans and integers are different types.",
-  "input": {
-    "display": "{1: \"a\", True: \"b\"}  ->  {1: \"b\"}, a dict with exactly one entry",
-    "description": "Building a lookup table or counter dict keyed partly by integers and partly by booleans from mixed data (e.g. a CSV or JSON blob where some flag fields were coerced to 0/1 and others stayed as true/false)."
-  },
-  "what_goes_wrong": "Inserting entries keyed `1` and `True` (or `0` and `False`) into the same dict overwrites one with the other instead of creating two entries, silently losing data with no error.",
-  "why": "`bool` is a subclass of `int` in Python (`class bool(int)`), specifically so that `True` and `1` behave identically wherever an integer is expected. As a consequence, `True == 1` is `True`, and `hash(True) == hash(1)`, and Python dicts (and sets) de-duplicate keys by equality-and-hash together -- so `1` and `True` are, as far as a dict is concerned, the exact same key, and whichever value was assigned last wins.",
-  "affects": [
-    "python"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "print(isinstance(True, int), True == 1, hash(True) == hash(1))\nprint(True + True)  # arithmetic coercion, unsurprising on its own\nd = {1: \"a\", True: \"b\"}\nprint(d, len(d))\n",
-      "expected_output": "True True True\n2\n{1: 'b'} 1",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "// JS booleans are not a number subtype: object keys coerce to strings, and\n// Map uses SameValueZero (no type coercion), so 1 and true never collide.\nconst obj = { 1: \"a\", true: \"b\" };\nconsole.log(obj, Object.keys(obj));\nconst m = new Map([[1, \"a\"], [true, \"b\"]]);\nconsole.log(m.size, [...m.keys()]);\nconsole.log(true + true); // arithmetic coercion still matches Python here\n",
-      "expected_output": "{ '1': 'a', true: 'b' } [ '1', 'true' ]\n2 [ 1, true ]\n2",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Never key a dict/set by a mix of booleans and small integers if you need them distinct; normalize flag values to a single consistent type (e.g. always `int`, or always `bool`) before using them as keys.",
-  "related": [],
-  "sources": [
-    {
-      "title": "Python docs: bool -- Boolean Type",
-      "url": "https://docs.python.org/3/library/stdtypes.html#boolean-type-bool"
-    },
-    {
-      "title": "Python docs: Built-in Types -- Mapping Types (dict)",
-      "url": "https://docs.python.org/3/library/stdtypes.html#mapping-types-dict"
-    }
-  ],
-  "tags": [
-    "database",
-    "validation",
-    "json"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        [
-          1,
-          true
-        ]
-      ],
-      "relation": "no_crash",
-      "note": "Any dict-building code keyed by mixed int/bool values should decide explicitly whether 1 and True are the same key."
-    }
-  ]
-}

package/src/exhibits/integers/floor-div-mod-sign-python-vs-js.json

@@ -1,48 +0,0 @@
-{
-  "id": "floor-div-mod-sign-python-vs-js",
-  "title": "-7 // 2 is -4 and -7 % 2 is 1 in Python, but Math.trunc(-7 / 2) is -3 and -7 % 2 is -1 in JavaScript",
-  "category": "integers",
-  "assumption": "Integer division of a negative number by a positive one rounds the same way in every language -- toward zero.",
-  "input": {
-    "display": "Python: -7 // 2 == -4, -7 % 2 == 1.  JavaScript: Math.trunc(-7 / 2) == -3, -7 % 2 == -1.",
-    "description": "Any pagination, bucketing, or hashing logic computed with integer division or modulo on a value that can be negative -- e.g. 'which page is item index i on' or 'which bucket does this signed offset fall into'."
-  },
-  "what_goes_wrong": "The same division expression applied to a negative dividend gives a different quotient AND a different-signed remainder depending on the language, so a bucketing or pagination formula ported between a Python backend and a JS frontend (or vice versa) silently puts negative-offset items in a different bucket on each side.",
-  "why": "Python's `//` is floor division: it rounds the mathematical quotient toward negative infinity, so -7 // 2 = -4 (since -3.5 floors to -4), and `%` is defined to satisfy `a == (a // b) * b + a % b`, which forces the remainder to take the sign of the divisor, giving -7 % 2 = 1. JavaScript's `/` followed by `Math.trunc` (or the legacy `~~`/`|0` truncation idioms) rounds toward zero instead, so -7/2 truncates to -3, and `%` in JS is a remainder operation (not a true modulo) that takes the sign of the DIVIDEND, giving -7 % 2 = -1. (JavaScript's `/` itself returns -3.5; `Math.floor(-7 / 2)` gives -4 and matches Python's `//`, so the quotient only diverges if you truncate. The `%` sign difference is built into the operator.)",
-  "affects": [
-    "python",
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "print(-7 // 2, -7 % 2)\nprint(7 // -2, 7 % -2)\n",
-      "expected_output": "-4 1\n-4 -1",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "console.log(Math.trunc(-7 / 2), -7 % 2);\nconsole.log(Math.trunc(7 / -2), 7 % -2);\n// A true floor-mod, matching Python, has to be written out explicitly:\nfunction floorMod(a, b) { return ((a % b) + b) % b; }\nconsole.log(floorMod(-7, 2));\n",
-      "expected_output": "-3 -1\n-3 1\n1",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Never port a division/modulo-based formula between Python and JavaScript without checking the sign convention explicitly; if you need Python's floor-mod behavior in JS, write it out as `((a % b) + b) % b` rather than relying on `%` alone.",
-  "related": [],
-  "sources": [
-    {
-      "title": "Python docs: binary arithmetic operations (floor division)",
-      "url": "https://docs.python.org/3/reference/expressions.html#binary-arithmetic-operations"
-    },
-    {
-      "title": "ECMA-262: Remainder operator semantics",
-      "url": "https://tc39.es/ecma262/#sec-numeric-types-number-remainder"
-    }
-  ],
-  "tags": [
-    "validation",
-    "pagination",
-    "database"
-  ],
-  "test_cases": []
-}

package/src/exhibits/integers/json-parse-loses-id-precision.json

@@ -1,58 +0,0 @@
-{
-  "id": "json-parse-loses-id-precision",
-  "title": "JSON.parse silently rounds a 64-bit id to the nearest value a JS number can hold",
-  "category": "integers",
-  "assumption": "Parsing a JSON number and then stringifying it again gives back the exact same digits you started with.",
-  "input": {
-    "display": "JSON.parse(\"9007199254740993\")  (a Twitter/Discord/Snowflake-style 64-bit id, one more than Number.MAX_SAFE_INTEGER)",
-    "description": "Any API that returns large integer ids as bare JSON numbers (not strings) -- Twitter/X status ids, Discord snowflakes, some database auto-increment ids -- consumed by a JavaScript client."
-  },
-  "what_goes_wrong": "An id of 9007199254740993 round-trips through `JSON.parse` as 9007199254740992 -- a different, smaller, EVEN number -- so looking that id up, comparing it, or sending it back to the server can silently hit the wrong record or none at all.",
-  "why": "The JSON specification defines numbers as an abstract decimal value with no size limit, but JavaScript's `JSON.parse` converts every JSON number into a 64-bit double, which (per IEEE 754) represents every integer exactly only up to 2^53; above that, neighbouring integers start sharing a double, which is why 2^53 - 1 is the largest 'safe' integer. 9007199254740993 (2^53 + 1) has no exact double representation; the nearest one is 2^53 (9007199254740992), and ties-to-even rounding picks that over 2^53 + 2. This is exactly why large-id APIs increasingly send such ids as JSON strings instead of bare numbers.",
-  "affects": [
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "javascript",
-      "code": "const id = JSON.parse(\"9007199254740993\");\nconsole.log(id);\nconsole.log(id === 9007199254740992);\nconsole.log(JSON.stringify(id));\n",
-      "expected_output": "9007199254740992\ntrue\n9007199254740992",
-      "verified_with": "Node.js v22.22.2"
-    },
-    {
-      "language": "python",
-      "code": "import json\n\n# Python's json module parses integers into arbitrary-precision int, so no\n# precision is lost here -- the gotcha is specific to a 64-bit-double parser.\nid_value = json.loads(\"9007199254740993\")\nprint(id_value, id_value == 9007199254740993)\n",
-      "expected_output": "9007199254740993 True",
-      "verified_with": "Python 3.14.2"
-    }
-  ],
-  "fix": "Never transmit an id that could exceed 2^53 - 1 as a bare JSON number; encode it as a JSON string on the wire, and parse/compare it as a string or BigInt on the JavaScript side, never as a plain `number`. If you cannot change the wire format, V8-based runtimes (Node 22, recent Chrome) pass the raw source text to a reviver as a third argument: `JSON.parse(text, (k, v, ctx) => typeof v === 'number' && !Number.isSafeInteger(v) ? BigInt(ctx.source) : v)`.",
-  "related": [
-    "max-safe-integer-plus-one-equals-plus-two"
-  ],
-  "sources": [
-    {
-      "title": "RFC 8259: The JSON Data Interchange Format (numbers have no size limit)",
-      "url": "https://www.rfc-editor.org/rfc/rfc8259#section-6"
-    },
-    {
-      "title": "MDN: JSON.parse",
-      "url": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse"
-    }
-  ],
-  "tags": [
-    "id",
-    "json",
-    "parsing",
-    "database"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "9007199254740993"
-      ],
-      "relation": "no_crash",
-      "note": "Parsing a large id from JSON must not silently change its value; compare as string or BigInt."
-    }
-  ]
-}

package/src/exhibits/integers/max-safe-integer-plus-one-equals-plus-two.json

@@ -1,58 +0,0 @@
-{
-  "id": "max-safe-integer-plus-one-equals-plus-two",
-  "title": "Number.MAX_SAFE_INTEGER + 1 === Number.MAX_SAFE_INTEGER + 2",
-  "category": "integers",
-  "assumption": "Adding 1 to a number and adding 2 to the same number always give different results.",
-  "input": {
-    "display": "Number.MAX_SAFE_INTEGER + 1 === Number.MAX_SAFE_INTEGER + 2  -- both equal 9007199254740992",
-    "description": "An auto-incrementing counter, row id, or 'view count' stored as a plain JS number that has climbed past 2^53."
-  },
-  "what_goes_wrong": "A counter that increments a plain JS `number` past 2^53 - 1 stops being able to tell consecutive values apart: incrementing by 1 does nothing some of the time, so a counter can appear to stall or two different logical events can be recorded with the identical numeric id.",
-  "why": "JS numbers are IEEE 754 double-precision floats, which have 53 bits of mantissa and so they represent every integer exactly only up to 2^53. `Number.MAX_SAFE_INTEGER` is 2^53 - 1 because it is the largest n for which n and n + 1 are both exact. Between 2^53 and 2^54 the representable doubles are 2 apart, so `MAX_SAFE_INTEGER + 1` is exactly 2^53, and `MAX_SAFE_INTEGER + 2` (2^53 + 1) sits halfway between 2^53 and 2^53 + 2 and rounds, ties-to-even, down to 2^53 as well.",
-  "affects": [
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "javascript",
-      "code": "console.log(Number.MAX_SAFE_INTEGER);\nconsole.log(Number.MAX_SAFE_INTEGER + 1 === Number.MAX_SAFE_INTEGER + 2);\nconsole.log(Number.MAX_SAFE_INTEGER + 1, Number.MAX_SAFE_INTEGER + 2);\nconsole.log(Number.isSafeInteger(Number.MAX_SAFE_INTEGER + 1));\n",
-      "expected_output": "9007199254740991\ntrue\n9007199254740992 9007199254740992\nfalse",
-      "verified_with": "Node.js v22.22.2"
-    },
-    {
-      "language": "python",
-      "code": "# Python ints are arbitrary precision, so the same arithmetic never collides.\nmax_safe = 2**53 - 1\nprint(max_safe + 1 == max_safe + 2)\nprint(max_safe + 1, max_safe + 2)\n",
-      "expected_output": "False\n9007199254740992 9007199254740993",
-      "verified_with": "Python 3.14.2"
-    }
-  ],
-  "fix": "Use `BigInt` (or a string) for any counter, id, or accumulated value that could exceed 2^53 - 1 in JavaScript; check `Number.isSafeInteger()` before trusting equality/ordering on a large computed number.",
-  "related": [
-    "json-parse-loses-id-precision"
-  ],
-  "sources": [
-    {
-      "title": "MDN: Number.MAX_SAFE_INTEGER",
-      "url": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER"
-    },
-    {
-      "title": "IEEE 754-2019 (floating-point arithmetic)",
-      "url": "https://ieeexplore.ieee.org/document/8766229"
-    }
-  ],
-  "tags": [
-    "id",
-    "counter",
-    "database",
-    "validation"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        9007199254740991
-      ],
-      "relation": "no_crash",
-      "note": "A safe-integer check should flag this value's successor as unsafe, not silently accept it."
-    }
-  ]
-}

package/src/exhibits/integers/number-empty-and-whitespace-string-equals-zero.json

@@ -1,55 +0,0 @@
-{
-  "id": "number-empty-and-whitespace-string-equals-zero",
-  "title": "Number(\"\") and Number(\" \") both equal 0",
-  "category": "integers",
-  "assumption": "An empty or blank string can't be converted to a valid number -- it should fail or return NaN.",
-  "input": {
-    "display": "Number(\"\") === 0  and  Number(\"   \") === 0",
-    "description": "Converting a form field or query-string parameter that the user left blank, using `Number(value)` as a validation/conversion step."
-  },
-  "what_goes_wrong": "A blank form field, passed through `Number()` as part of 'sanitize to a number', becomes the perfectly valid number 0 instead of failing validation, so an unanswered quantity/price/age field silently records as zero rather than being rejected as missing.",
-  "why": "The ECMAScript string-to-number grammar defines the empty string (and a string containing only whitespace, since leading/trailing whitespace is trimmed first) as a valid `StringNumericLiteral` whose value is 0 -- this is an explicit rule in the spec, not an accidental byproduct of trimming. `parseInt` and `parseFloat`, by contrast, both return `NaN` for the same inputs, because they don't follow this grammar rule.",
-  "affects": [
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "javascript",
-      "code": "console.log(Number(\"\"), Number(\"   \"), Number(\"\\t\\n\"));\nconsole.log(parseInt(\"\"), parseFloat(\"   \"));\n",
-      "expected_output": "0 0 0\nNaN NaN",
-      "verified_with": "Node.js v22.22.2"
-    },
-    {
-      "language": "python",
-      "code": "# Python's numeric constructors raise on an empty or blank string rather than defaulting to 0.\nfor s in (\"\", \"   \"):\n    try:\n        int(s)\n    except ValueError as e:\n        print(repr(s), \"-> ValueError:\", e)\n",
-      "expected_output": "'' -> ValueError: invalid literal for int() with base 10: ''\n'   ' -> ValueError: invalid literal for int() with base 10: '   '",
-      "verified_with": "Python 3.14.2"
-    }
-  ],
-  "fix": "Check for an empty/whitespace-only string explicitly before calling `Number()` on user input; don't rely on it to reject blanks, since by spec it treats them as a valid zero.",
-  "related": [],
-  "sources": [
-    {
-      "title": "ECMA-262: ToNumber applied to the String type (StringNumericLiteral)",
-      "url": "https://tc39.es/ecma262/#sec-tonumber-applied-to-the-string-type"
-    },
-    {
-      "title": "MDN: Number()",
-      "url": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number"
-    }
-  ],
-  "tags": [
-    "parsing",
-    "validation",
-    "forms"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        ""
-      ],
-      "relation": "no_crash",
-      "note": "A numeric-field validator must treat an empty string as missing, not silently accept it as zero."
-    }
-  ]
-}

package/src/exhibits/integers/parseint-null-radix36-digit-soup.json

@@ -1,57 +0,0 @@
-{
-  "id": "parseint-null-radix36-digit-soup",
-  "title": "parseInt(null, 36) returns 1112745",
-  "category": "integers",
-  "assumption": "Passing null where a string is expected is harmless, or at worst gives you 0 or NaN.",
-  "input": {
-    "display": "parseInt(null, 36) === 1112745",
-    "description": "A missing or unset form field, config value, or optional function argument that falls through to `parseInt` without a guard, combined with a non-default radix such as base36 (used for compact id encoding)."
-  },
-  "what_goes_wrong": "A missing value that should produce 0, NaN, or an error instead silently produces a real-looking, nonzero integer -- 1112745 -- which can pass a `typeof x === 'number' && !isNaN(x)` guard and flow deep into the system before anyone notices the input was never actually a number.",
-  "why": "`parseInt`'s first argument is coerced to a string before parsing, and `String(null)` is the literal string `\"null\"`. In base 36, digits run 0-9 then a-z representing 10-35, so every character of \"null\" (n, u, l, l) is a valid base-36 digit, and the whole string parses successfully as a number -- specifically 1112745. Nothing about this path raises an error or returns NaN, because from `parseInt`'s point of view it was simply handed a valid base-36 numeral.",
-  "affects": [
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "javascript",
-      "code": "console.log(String(null));\nconsole.log(parseInt(null, 36));\nconsole.log(parseInt(\"null\", 36));\nconsole.log(parseInt(undefined, 36)); // String(undefined) === 'undefined', also all valid base-36 digits\n",
-      "expected_output": "null\n1112745\n1112745\n86464843759093",
-      "verified_with": "Node.js v22.22.2"
-    },
-    {
-      "language": "python",
-      "code": "# Python's int() with an explicit base requires an actual string and rejects None outright.\ntry:\n    int(None, 36)\nexcept TypeError as e:\n    print(\"TypeError:\", e)\n",
-      "expected_output": "TypeError: int() can't convert non-string with explicit base",
-      "verified_with": "Python 3.14.2"
-    }
-  ],
-  "fix": "Guard against `null`/`undefined` before calling `parseInt` rather than relying on it to fail loudly; it won't, for any radix where the stringified sentinel's letters happen to be valid digits.",
-  "related": [
-    "parseint-stops-at-first-invalid-char-vs-number"
-  ],
-  "sources": [
-    {
-      "title": "MDN: parseInt()",
-      "url": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt"
-    },
-    {
-      "title": "ECMA-262: parseInt (string coercion of the first argument)",
-      "url": "https://tc39.es/ecma262/#sec-parseint-string-radix"
-    }
-  ],
-  "tags": [
-    "parsing",
-    "validation",
-    "forms"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        null
-      ],
-      "relation": "no_crash",
-      "note": "A function wrapping parseInt with a non-10 radix should explicitly reject null/undefined rather than let String() coercion through."
-    }
-  ]
-}

package/src/exhibits/integers/parseint-number-argument-scientific-notation.json

@@ -1,48 +0,0 @@
-{
-  "id": "parseint-number-argument-scientific-notation",
-  "title": "parseInt(0.0000005) returns 5, not 0",
-  "category": "integers",
-  "assumption": "parseInt() reads the digits of the number you gave it, in the order you wrote them.",
-  "input": {
-    "display": "parseInt(0.0000005)  -- note: the NUMBER 0.0000005, not the string \"0.0000005\"",
-    "description": "Calling parseInt on a small decimal number directly (rather than on a string), e.g. while sanitizing a computed fractional value into an integer."
-  },
-  "what_goes_wrong": "`parseInt(0.0000005)` returns 5 -- not 0, and not an error -- because the number gets stringified to scientific notation before parseInt ever sees a digit of the original decimal.",
-  "why": "`parseInt` only accepts a string; when given a `number`, JavaScript first coerces it to a string via the Number-to-String algorithm. That algorithm switches to exponent notation for any magnitude below 1e-6 (and at or above 1e21), so 0.000001 stringifies as \"0.000001\" but 0.0000005 becomes \"5e-7\", not \"0.0000005\". `parseInt` then reads the string from the start, parsing digits until it hits the first character that isn't part of an integer -- which is \"e\" -- so it returns 5, the only digit it saw before stopping. Calling `parseInt(\"0.0000005\")` on the literal string instead returns 0, because the string parse stops at the \".\". The large end bites the same way: `parseInt(1e21)` is 1, because 1e21 stringifies as \"1e+21\".",
-  "affects": [
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "javascript",
-      "code": "console.log((0.0000005).toString());       // what parseInt actually sees\nconsole.log(parseInt(0.0000005));           // number argument -> stringified first\nconsole.log(parseInt(\"0.0000005\"));         // string argument -> no scientific notation\n",
-      "expected_output": "5e-7\n5\n0",
-      "verified_with": "Node.js v22.22.2"
-    },
-    {
-      "language": "python",
-      "code": "# Python's int() refuses a float string outright rather than guessing a prefix.\ntry:\n    int(\"0.0000005\")\nexcept ValueError as e:\n    print(\"ValueError:\", e)\nprint(int(0.0000005))  # int() of an actual float truncates toward zero instead\n",
-      "expected_output": "ValueError: invalid literal for int() with base 10: '0.0000005'\n0",
-      "verified_with": "Python 3.14.2"
-    }
-  ],
-  "fix": "Never pass a `number` directly to `parseInt`; convert deliberately with `Math.trunc()`/`Math.floor()` for numbers, and reserve `parseInt` for strings whose format you've already validated.",
-  "related": [
-    "parseint-stops-at-first-invalid-char-vs-number"
-  ],
-  "sources": [
-    {
-      "title": "MDN: parseInt()",
-      "url": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt"
-    },
-    {
-      "title": "ECMA-262: Number::toString",
-      "url": "https://tc39.es/ecma262/#sec-numeric-types-number-tostring"
-    }
-  ],
-  "tags": [
-    "parsing",
-    "validation"
-  ],
-  "test_cases": []
-}