Structured Output Repair Bench

parsed and valid are the numbers a repair library usually reports. faithful and altered are the two this bench exists for.

This walkthrough uses the tool's public README and checked-in example files. Run the command from a repository checkout with Node.js 22+; inspect the source before using it on your own files.

Run the checked-in example

# a corpus every strategy either repairs faithfully or fails on: exit 0
node bin/structured-output-repair-bench.mjs --corpus examples/corpus.json

# a corpus where a naive repair alters a record's meaning: exit 1
node bin/structured-output-repair-bench.mjs --corpus examples/corpus-altered.json

# custom strategies, in the order you want them compared
node bin/structured-output-repair-bench.mjs \
  --corpus examples/corpus.json \
  --pipelines examples/pipelines.json \
  --strategies strict,span-then-close,commas-only-naive

# the machine-readable report
node bin/structured-output-repair-bench.mjs --corpus examples/corpus.json --json

npm run check   # lint, tests, both runnable examples, and npm pack --dry-run

Read the result

Exit 2 has two shapes on purpose. A configuration error means the run never had a subject, so there is nothing to report about. An unreadable input means the run had a subject and failed to obtain evidence about it, and the consumer needs the report to know which input was not read. A consumer that pipes stdout must handle an empty stdout on exit 2.

Where this check stops

Every limit is enforced, reachable from its own flag, and covered by a test that drives it through the command line.

Before adapting the command to your own workflow, review the accepted inputs, exit codes and safety boundaries in the README.

Compiled with AI assistance from checked-in public documentation and example scripts. Run the example and review the repository's current documentation before relying on its result.