How paged is tested
The verification system across paged — unit suites, end-to-end and DTP journeys, the fidelity gate against InDesign, the conformance corpus, and how all that evidence flows into the capability registry.
In short Paged is verified at four tiers, and every tier's results flow into the capability registry as evidence. The registry claims what's implemented; the tests verify it; this documentation renders both. That's why a green badge here means a passing test exists — not someone's say-so.
40 chapters · from the capability record of 2026-10-18 (cockpit @ e53a7a52), built from the newest CI test runs.
The four tiers
1. Unit (per repo, language-native)
The engine runs Rust cargo nextest across its
crates (parse, layout, mutation, color, export). The
editor and server
run TypeScript suites; the plugins run vitest (TS) and,
where they're Rust/WASM, nextest. Several plugins enforce a registry-driven
coverage gate — every kernel/function declared must have at least one test.
2. End-to-end & DTP journeys
The editor runs Playwright across three sub-tiers: isolated gesture/op specs, journey tests (real desktop-publishing workflows built from a blank document), and per-page fidelity specs. Plugin journeys exercise each plugin in the real editor.
3. The fidelity gate
The decisive correctness check: render a corpus document and diff it against an InDesign-exported PDF using ΔE2000 + SSIM, with hard thresholds. The rule is never loosen a threshold to hide a regression — fix it first. This runs on both the engine's own fixtures and the editor's canvas.
4. Corpus fidelity
The corpus (deterministic generated fixtures and real InDesign exports) is rendered by the engine and compared with InDesign's own PDFs, page by page, by colour difference (ΔE2000) and structural similarity (SSIM). Thresholds only tighten: a fixture that regresses is fixed, never re-baselined to pass. See InDesign compatibility.
How evidence becomes status
Each repository's CI uploads its results. Tests name the capabilities they prove
(an inline @feat: tag, or a test map for suites that cannot carry one), and the
cockpit registry joins the newest runs with its claims
into the record the capability state pages and every
<SupportBadge> render.
A claim with no linked test renders as untested, not green; a linked test going red renders as failing; a pass older than the latest code change renders as re-test pending. See how the capability state works.
How the capability state works
The capability registry, where its test evidence comes from, and the pipeline that rebuilds these pages from CI test runs instead of by hand.
Recent activity
A live, interleaved feed of the latest commits across every paged repository — pulled from GitHub at build time, refreshed nightly.