CAPABILITY STATUS

Know what is built.
See what is next.

A documentation snapshot—not a release certification or a dated delivery promise. We keep the implemented foundation separate from the design direction.

How to read the labels.

Every capability card on this site carries one of four labels. They are information architecture, not decoration.

Documented foundation
The project documents describe the capability as implemented, and the verification record backs it.
Design preview
A proposal, not implemented behaviour. Nothing on this site presents it as available.
Confirm scope
The implementation or verification evidence is conflicting, incomplete or missing. Check it against the release you select.
Owner-stated
A fact supplied by the project owner, such as the licensing direction, that still needs release-level confirmation.

SNAPSHOT · 18 SEPTEMBER 2026

Documented foundation.

Documented foundation

Core runtime and assembly

One process, Felix, Sling and one Oak repository; explicit features; HTL and static content. The README records this as the implemented foundation.

Documented foundation

Typed HTTP API

The API document reports implementation through step 8, including identity, content and public site modules. Individual assembly inclusion still matters.

Documented foundation

Request boundary and provisioning

Security controls and the file-installer hardened lock are described as implemented. Starter defaults still require hardening.

Confirm against the selected release.

Confirm scope

Site and authoring scope

The site-framework header says not implemented, while later sections and the API document describe parts as present. Verify the exact delivered modules and editor behavior.

Confirm scope

Runtime verification gaps

The API lists browser authorization, mid-swap continuity and duplicate operationId testing as open. STATUS.md is the verification record; read it with the release you select.

Confirm scope

Assembly and storage details

Bundle counts and some feature-inclusion statements differ across documents. Reconcile the selected aggregate and boot evidence rather than treating a marketing number as truth.

The lifecycle direction.

PAGE-LIFECYCLE-DESIGN.md is explicitly marked design, not implemented. It proposes a persistent main draft, parallel drafts, explicit publication, retained immutable versions and transactional extension points - ordered reactors, final validators and outbox-driven subscribers. Recoverable deletion, guarded unpublish dispositions and workflow records belong to the same proposal. Nothing on this site presents any of it as available behaviour, and no delivery date is implied.

The lifecycle direction.

Design preview

Persistent drafts and publication

The newer design keeps a main draft after publication and separates immutable versions from editable work.

Read the proposal
Design preview

Transactions and events

Ordered reactors, final validators and outbox-driven subscribers are proposed extension points.

Explore the event model
Design preview

Recovery and workflow

Recoverable deletion, guarded unpublish dispositions and workflow records are designed but not implemented in the implementation record.

Review the boundaries

What supersedes what.

The page-lifecycle proposal explicitly overrides parts of DRAFTS-DESIGN.md: publication copies rather than consumes the draft, draft containers use page identity rather than mirrored paths, and immutable versions replace archived-draft history. The website uses the newer model only as a design preview. It does not present the proposal as a change already delivered.

The older architecture says no typed API; the README and API-DESIGN.md explicitly describe the typed API as built. The website uses those explicit API statements, with their remaining test gaps, rather than repeating the obsolete omission. This is a documented editorial choice, not independent code verification.

No dates invented.

No public release schedule, long-term-support policy or delivery dates have been published. Clustering, a separate author/publish topology, built-in full-text search and complete approval workflows must not be inferred from the project’s long-term direction.

Help turn a requirement into evidence.

Bring a focused use case, a reproducible test or a careful documentation correction when public collaboration opens.