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.
In short There is one registry of capabilities. Every repository's CI publishes its test results; a nightly job, and every finished test run on a main branch, joins them to the registry and exports one record. These docs and paged.media are built from that record, so a number on these pages is never typed by hand.
The registry
Each capability is one row with a stable chapter.feature id, a lifecycle
(stable, experimental, planned) and a claim per layer: which parts of the
system implement it, and whether fully or partly. The layers are the matrix
columns: the engine's parser, renderer, mutation, canvas and SDK; the editor's
canvas, shell, panels, gestures and scripting; the plugin API; and one column per
content plugin.
A claim says what is built. It is never counted as proof.
The evidence
Tests name the capabilities they prove: a tag in the test name
(@feat:chapter.feature), or a mapping file for suites that cannot carry one.
The registry reads the newest test results each repository's CI uploaded and
gives every capability a health:
- verified — a passing test run newer than the capability's latest code change.
- re-test pending — its tests passed, but before the latest change.
- failing — a linked test is red.
- untested — no test names it yet.
A test that names a capability the registry does not have is an error in the nightly run, so a new feature cannot hide behind a mistyped tag.
Why these pages stay current
The registry's export, the engine's scripting catalog and CLI surface, the
plugin registries and each package's licence are pulled at build time and
projected into the components you see. Counts in prose (functions, kernels,
operations, the protocol version, licences) come from the same sources through a
<Fact> component, and the build fails a page that types one of them by hand. The
build also fails when the record is more than a week old or a source cannot be
pulled, so a broken pipeline shows up as a red build rather than as quietly old
numbers.
The record itself is public: capabilities.json and facts.json.
Capability matrix
Every paged capability across every implementation layer, with its status and the health its latest CI test runs give it.
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.