patchwork json parity dashboard
Differential survey of @knowvah/dot-engine patchwork json output vs the native dot -K patchwork oracle (test/corpus/json-walk.ts), semantic comparison per docs/conformance.md (±0.01 deterministic tolerance, ±0.5 for the iterative engines). Regenerate: npx tsx test/corpus/json-walk.ts patchwork && npx tsx test/corpus/parity-report.ts.
Summary
- Surveyed: 762
- pass: 760 (99.7%) · diverged (tracked): 0 · accepted (documented, won't-fix): 2
- errors (oracle/port/timeout, excluded from scoring): 0
Diverged (0)
(none)
Accepted (2) — documented, not chased
| id | #diffs | firstDiff | reason |
|---|---|---|---|
share-Latin1 | 1 | node:a/label | Input is Latin-1 with NO charset declaration, so the bytes are invalid UTF-8. Native dot's -Tjson then emits a MIXED-ENCODING document: attribute values (e.g. node label) are echoed as RAW Latin-1 bytes (0xe1 0xe2 ... unconverted), while the DRAWN label text (ldraw T op, via make_label) is UTF-8 (0xc3 0xa1 ...). No single decode reads both halves correctly: Latin-1 recovers the attribute but mojibakes the text, UTF-8 does the reverse (and the attribute bytes are not valid UTF-8). The port decodes the input once (utils.c latin1ToUTF8 fallback) and is internally consistent valid UTF-8 on BOTH surfaces, so it cannot reproduce the oracle's split encoding. A4 class: the oracle output is an encoding bug; the port declines to emit invalid/mixed-encoding JSON. The DECLARED charset=latin1 case (graphs-Latin1/b60) IS handled via the stoj double-encode fix; only the UNDECLARED-charset case is irreducible. |
windows-Latin1 | 1 | node:a/label | Identical mechanism to share-Latin1: undeclared-charset Latin-1 input makes native -Tjson emit raw-Latin-1 attribute bytes alongside UTF-8 drawn text (mixed, invalid). The port's consistent-UTF-8 output cannot match both halves. A4 class. |
Errors and timeouts (0)
(none)
Passing ids (760) are omitted for brevity — the full roster is in json-parity-patchwork.json.