Roadmap

OpenElement roadmap labels describe the public product surface, tied to package truth, docs truth and CI evidence rather than a wish list.

01 / release line

From shipped evidence to v1.0 freeze.

The line is deliberately narrow: only claims that can survive docs, package exports and build validation stay visible.

ADR-0143 — v0.44 alpha active

0.43.3 remains stable while the compiled OpenElement train begins.

v0.43.3 is the published stable maintenance line. ADR-0143 explicitly opens the 0.44 alpha line for the compiled Element architecture; the Version Plan owns every numbered alpha and the RC gate.

v0.43.3CURRENTrenderer-owned light DOM hydration — robustness audit closure

The published stable line remains available while 0.44 is prerelease. It proves Universal WC SSR, in-place light-DOM activation and the application delivery baseline that the compiled architecture must preserve.

v0.44 alphaNEXTcompiled OpenElement foundations

Architecture constitution, governance offload, unified Content Graph and a production-shaped TSX-to-Part Program compiler spike.

active

compiler → claimElement, Parts and claim

Standard decorators, the OpenElement kernel, replaceable Signals, fixed Parts, dynamic Regions, DSD serialization and existing-DOM claim converge on one program.

planned sequence

delivery → qualificationdelivery, migration and qualification

Zero-runtime static output, generated Island delivery, App/build convergence, old-path removal, ecosystem interop and real-application qualification.

planned sequence

v0.44 release candidatefrozen candidate

Entered only after the complete architecture, correctness, delivery, portability, documentation, governance and real-application gate passes. Any public or architecture change returns to alpha.

gated

v1.0.0stable five-package product

Release only after external production users prove that the Element, App and Build interfaces need no further architecture change.

direction

02 / product boundary

Scope is explicit.

Current capability, excluded promises and the visual contract are kept separate.

in product

In product

JSX-first application API
Declarative Shadow DOM rendering
Routes, layouts, content, islands, and i18n
Loaders and actions with progressive-enhancement forms
CSRF floor on the action surface
Nitro server output (Node + Workers) and SPA mode
Preact adapter and Hono API routes via adapter-vite
Verified package and release boundaries

out of current scope

Out of current scope

Hub product language
Registry Hub as a current product promise
RPC, CEM, and interop adapter package promises
Generic auth, ORM, or database platform claims
Old package-count public graph language

design rule

Design rule

The public website should read like a Web Standards Lab: dark-first, diagrammatic, useful, and grounded in artifacts users can inspect.

03 / decision matrix

Roadmap language stays inside the product boundary.

Ship, prove and freeze are evidence states rather than marketing labels.

ShipOnly public contracts reflected in docs, generated pages, and package surfaces.

ProveUse CI, build checks, and docs scans as release evidence before expanding claims.

FreezeMove toward v1.0 after the WC fullstack framework and Basic Element line is stable, readable, and boring to verify.

04 / system visual

The package graph is part of the release artifact.

Published package ownership and the public architecture must remain mechanically identical.

package matrixproduct boundary

Elementscustom elements, DSD rendering, and component contracts

UIOpen Props primitives used by this website and consumers

Frameworkroutes, layouts, content, islands, i18n, and adapter-vite

Protocolspublic boundary declarations and package compatibility language

release disciplinev1.0 posture

No driftMarketing language, docs, package exports, and CI gates must agree.
No ghostsArchived Hub-era promises and No webpack-era shortcuts stay out of the current public product line.
No fogUsers should understand what is shipped, current, planned, and explicitly out of scope.