ata-validator

Correctness

The engines now report the same errors, not just the same verdict. ata has a
compiler and an interpreter behind one API, and a differential held them to the
same answer. It said nothing about what they report when both reject. A new
differential runs 2816 cases through both and compares keyword, instancePath,
schemaPath and params. It found ten differences, none of which changed a
verdict, so nothing had ever gone red:

• instancePath and schemaPath did not escape / or ~ in property keys on
  the generated path, so a key a/b came back as /a/b and split into two
  pointer segments.

• additionalProperties: false reported keyword not at the key's own path on
  the interpreter, dropping both the keyword consumers switch on and the
  rejected property name in params.

• propertyNames put its subschema errors at /<key> on one engine and at the
  object carrying the name on the other.

• abortEarly promises the frozen ATA9000 stub. Without code generation the
  interpreter ignored the option and returned detailed errors instead.

• maxContains reported its own keyword and pointer on the interpreter rather
  than contains at #/contains.

• type: ["string","null"] put a joined string in params.type instead of the
  array.

• A oneOf matching more than once reported {matched,total} on one engine and
  a bare count on the other. Both now list the passing branch indices.

• A keyword reached through $ref got a different schema pointer from each.

This matters most where code generation is not allowed. The compat entry is
pinned to the reference implementation by a test that can only run where the
reference can compile, which is not a strict CSP or an edge runtime, so the
compat promise was never checked in the environment it is most needed.

isValidObject() no longer throws where code generation is blocked. On a
fresh validator whose schema is not tier-0, the first call ran the code
generator without a guard. new Function is a property of the realm rather
than of the schema, so under a strict CSP it throws instead of declining, and
the EvalError reached the caller of a verdict method. validate() was
unaffected, and so was isValidObject() once validate() had run first, which
is why it stayed hidden. It reproduces on 1.19.0.

It surfaced because the verdict differential was itself broken: it wrote a
large payload to stdout and then called process.exit, truncating a pipe that
had not drained, so it was comparing about 12500 of 18126 cases. It compares
all of them now.

The AOT emitters refuse a validator they cannot represent. withKeywords()
from @ata-project/keywords wraps an instance so instanceof and typeof are
checked after the schema accepts. toStandalone and toStandaloneModule built
their module from the schema alone and emitted one missing those checks, with
nothing to say it had been weakened. They now decline.

Branch collapse on the interpreter. A failing anyOf or oneOf collapses
to one error naming the closest variant on both engines. It was generated-code
only, so the environment without code generation got the worse report.

Specification output format

toOutput(validator, data, { format }) produces the specification's own output
format, with keywordLocation, absoluteKeywordLocation and
instanceLocation. The official suite has tests for this in output-tests/,
separate from the validation tests, and nothing here ran them before. flag and
basic are implemented for draft 2019-09 and 2020-12; 8 of 8 content cases
produce conforming output. detailed, verbose and the v1 list format are
not implemented, and that is stated rather than stubbed.

Size

Helpers that several compiled functions hoist are now declared once per module
and once per bundle instead of once each. The email check alone is about 2.7 KB,
and every module using a format carried two copies.

Five realistic tool schemas, minified and gzipped: separate modules 8038 to 6766
bytes, bundleCompact 6602 to 5561.

Known, not fixed

bundleCompact's ESM output raises ReferenceError: _cpLen is not defined for a
schema whose maxLength crosses the code-point counting threshold. It
reproduces on 1.19.0.

Verified

Suite 1299/1299, 927/927, 1133/1133 across the three dialects, identical with
code generation blocked. Clean install from the packed tarball checked on both
engines.