@particle-academy/fancy-conformance 0.17.0 → 0.18.0

package/VERSION

@@ -1 +1 @@
-0.17.0
+0.18.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@particle-academy/fancy-conformance",
-  "version": "0.17.0",
+  "version": "0.18.0",
   "description": "Shared cross-language conformance fixtures for the Fancy suite. One contract, N implementations, and a single table that every implementation asserts in its own CI \u2014 so 'parity' is a test result rather than a claim. Ships the fixture data itself, so a Rust, Go or Python runner can consume it without a JavaScript toolchain.",
   "repository": {
     "type": "git",

package/suites/expr/evaluate/cases.json

@@ -1545,6 +1545,43 @@
         "ok": true,
         "value": ""
       }
+    },
+    {
+      "id": "1101-loose-spelling-does-not-coerce",
+      "title": "The LOOSE spelling does not coerce either -- '3' == 3 is false.",
+      "since": "0.18.0",
+      "tags": [
+        "expr",
+        "equality"
+      ],
+      "notes": "BELONGS WITH 0501-0504 and is numbered here only because ids are never renumbered. It exists because the mutant harness found the table could not do what this manifest claimed it did. 0503 pins no-coercion using the STRICT spelling ('3' === in.count) and 0502 compares two values that are equal anyway -- so a runtime whose `==` coerced, which is PHP's and JavaScript's native behaviour and the single most likely port mistake, passed every row. The manifest said a coercing probe 'must fail 0503'. It failed nothing. Prose beside a check, asserting what the check could not express.",
+      "input": {
+        "expression": "'3' == in.count",
+        "context": {
+          "in": {
+            "content": "hello",
+            "count": 3,
+            "deal_id": "D-1",
+            "transcript": null,
+            "items": [
+              1,
+              2
+            ],
+            "empty": [],
+            "obj": {},
+            "flag": true,
+            "zero": 0,
+            "blank": ""
+          },
+          "user": {
+            "name": "Ada"
+          }
+        }
+      },
+      "expected": {
+        "ok": true,
+        "value": false
+      }
     }
   ]
 }

package/suites/expr/evaluate/manifest.json

@@ -35,8 +35,9 @@
     "`==` AND `===` ARE THE SAME OPERATOR (0501-0503), and neither coerces. Both spellings are accepted because authors write both. Two equality operators that differ subtly is a language that generates bug reports, and there are three runtimes to keep in step.",
     "`&&` AND `||` RETURN THE OPERAND, NOT A BOOLEAN (0401-0404). That is what makes `in.transcript || in.content` a useful fallback rather than merely `true` — and the reported production case wrote exactly that shape.",
     "MALFORMED EXPRESSIONS FAIL (0801-0805) and never return null. A null there would be indistinguishable from an absent path, which is the defect being removed. 0805 pins that a function call does not parse: sandboxing is a security property here, not a style preference, because these expressions arrive from end users and from agents over the wire.",
-    "This suite needs DISCRIMINATION PROBES before it can claim more than drift-guarding — deliberately-wrong evaluators that must each fail an exact set of ids. Notably: one that uses native truthiness (must fail 0301/0302), one that coerces on `==` (must fail 0503), and one that returns booleans from `&&`/`||` (must fail 0401/0403/0404). Not yet written; recorded so a green tick is not read as the stronger claim.",
+    "DISCRIMINATION PROBES NOW EXIST, in `tests/discrimination-expr.test.ts`, and writing them found this manifest making a claim the table could not support. It used to say a probe that coerces on `==` \"must fail 0503\". It failed NOTHING: 0503 pins no-coercion using the STRICT spelling ('3' === in.count) and 0502 compares two values that are equal either way, so a runtime whose `==` coerced -- PHP's and JavaScript's native behaviour, and the single likeliest port mistake -- passed every row in the suite. 1101 is the row that makes the claim true. The other two predictions were merely INCOMPLETE rather than wrong: boolean `&&`/`||` also breaks 0402 and 1002, and the probes now assert the EXACT id set, so a row that stops doing the catching cannot be deleted unnoticed.",
     "`.length` (0901-0905) IS the one pseudo-property, and it is load-bearing rather than convenient. Because `[]` is TRUTHY, a consumer with no `.length` would have no way to ask whether a collection is EMPTY -- the grammar would assert that an array which exists is a value and then leave nobody able to test the thing they care about. It is a computed count, not host reach: nothing is called and no prototype is walked, and 0905 pins that nothing else on the chain resolves. Objects deliberately have none (0904), since no count would survive three languages. These rows were added after writing the reference implementation's discrimination tests found the SPEC contradicting the CODE -- the truthiness rule was justified with `.length` while `.length` returned null.",
-    "THE TABLE EARNED ITS KEEP ON THE FIRST INDEPENDENT IMPLEMENTATION, exactly as this manifest predicted it would. The PHP port -- written against these rows rather than against the TypeScript source -- failed 1 of 44 on its first run: 0904, that an object has no `.length`. It is not a bug in the port. json_decode('{}', true) and json_decode('[]', true) produce the IDENTICAL value in PHP and array_is_list() calls both a list, so an EMPTY object is indistinguishable from an empty array and the length the array legitimately has is returned. A genuine cross-language expressiveness limit, the same one shared/value-equality/0210 records. Skipped there with the reason attached, and 0906 pins the identical rule with a NON-EMPTY object that every runtime can express -- the same two-row shape as flow/workflow-props 0106/0109."
+    "THE TABLE EARNED ITS KEEP ON THE FIRST INDEPENDENT IMPLEMENTATION, exactly as this manifest predicted it would. The PHP port -- written against these rows rather than against the TypeScript source -- failed 1 of 44 on its first run: 0904, that an object has no `.length`. It is not a bug in the port. json_decode('{}', true) and json_decode('[]', true) produce the IDENTICAL value in PHP and array_is_list() calls both a list, so an EMPTY object is indistinguishable from an empty array and the length the array legitimately has is returned. A genuine cross-language expressiveness limit, the same one shared/value-equality/0210 records. Skipped there with the reason attached, and 0906 pins the identical rule with a NON-EMPTY object that every runtime can express -- the same two-row shape as flow/workflow-props 0106/0109.",
+    "0502 AND 1101 ARE NOT DUPLICATES, and the difference is the whole point. 0502 asks whether the loose SPELLING is accepted at all; 1101 asks whether it COERCES. A table with only the first reads as covering equality and covers half of it."
   ]
 }