DocSpec lint playground

A DocSpec is the token-frugal JSON grammar of pdfnative-react: plain data — positional tuples such as ["h1", "Invoice"] under a handful of top-level fields — that agents emit and a CMS can store, and that compiles to exactly the same document as the equivalent JSX. Paste one below (or pick a preset), click Lint, and the page runs validateSpec then lintSpec in your browser; when the report carries no error, Render PDF hands the very same spec to renderSpecToBytes. Grammar and field reference: Agent authoring — the token-frugal DocSpec; where it fits: use cases.

What lint checks. The authoring model, not the bytes. validateSpec is the shape tier — unknown tuple kind, wrong arity, wrong payload type, path-anchored (blocks[3][1]) and it never throws. lintSpec compiles the spec once and applies 37 rules with stable L_* codes in pdfnative-react 1.3.0: twenty of them pre-empt an exception the engine raises at build time (the eight L_CHART_* errors, print geometry, the six PDF/X coherence rules, the output-intent profile check…), five mirror an engine diagnostic that becomes a throw under layout.strict, and the rest catch accessibility gaps (alt text, header rows, heading hierarchy, link text, field labels) or output that renders but is wrong (an empty document, a PDF/A or PDF/X claim without embedded fonts, overflow, a colour-bar strip too thin to measure). Gate on report.ok, which is true when no finding has severity error.

The rule table

Built at load from the package's own LINT_RULES export — id, severity and description come from pdfnative-react, not from this page. Rows highlighted in yellow fired in the last lint run. Branch on the code, never on the message: messages may be reworded in any release, codes may not.

The same loop in Node

The page calls the three exports below straight from the CDN build; in a project you install pdfnative-react from npm (React 19 is its peer dependency, pdfnative its engine) and run the identical sequence. The snippet tracks the selected preset.