[beta.2.1] Define Element / Router core boundaries, standalone delivery and shared route records

[SisyphusZheng]

Outcome

Two core products: Element (compiled Web Components execution) and Router (Route Mode / Framework Mode). UI supplies selected dogfood/reference components. Product names do not require immediate package renames; app/adapter-vite/create remain distribution/tooling until migration is justified.

Work

• Keep Element independent; UI depends on Element, not Router.
• Route Mode accepts explicit records and does not require Element, Vite, Hono or filesystem access in its matching core.
• Framework Mode defaults to file routing, generating the same records; file paths own their URL paths, with no duplicate route.path declaration.
• Define record composition, mount boundaries, deterministic order and collision diagnostics. Explicit declaration order stays stable; file generation emits a deterministic documented order.
• Use one RouteTable and one RouteResolution for both inputs. Separate pathname captures and URLSearchParams.
• Group methods on the selected route record; URL winner precedes method dispatch. POST /products/new returns 405 when the selected record only supports GET, even if a later /products/:id supports POST.
• Separate server and public browser projections; no server handlers or host bindings enter browser manifests.
• Remove superseded declarations, conversions, exports and compatibility layers in the same change as their replacement; preserve required behavior with regression tests.

Acceptance

Explicit-record and generated-record integration tests exercise the same matcher. No second routing implementation. Existing selected UI only; no broad component expansion. Startup table construction and atomic replacement suffice; fine-grained dynamic mutation is deferred.

Part of #1320. Depends on the contract agreed with #1324/#1325. Authority: maintainer-approved 2026-09-07 plan, ADR-0152 and docs/current/VERSION_PLAN.md (documentation PR linked on the train root). Planning is not implementation or release evidence.

Two-core-product refinement (2026-09-07)

• Establish Element and Router as the two core products; UI is dogfood/reference and may retain its package without a separate design-system roadmap.
• Specify standalone Element author/build/pack/plain-HTML consumption independent of Router.
• Deliver the private compiler through an explicit Element tooling entry; published packages must not depend on unpublished workspaces.
• Keep versioned compiler/runtime artifacts and source diagnostics/maps; Framework tooling reuses this path rather than owning Element semantics or duplicating the compiler.
• Separate browser, server, build and type entry graphs. Keep Vite/compiler/Node-only code out of browser JS and declarations.
  Tooling subpaths are permitted; exact export names are implementation decisions. Do not require two physical npm packages, a public compiler API or a full directory relocation.

Accepted refinement — 2026-09-08 (supersedes conflicting earlier scope)

• Complete standalone Element author/compile/pack/plain-HTML proof in Beta.2.1, not merely an export contract.
• Keep Element compiler private and reuse tooling; no Router/App/UI dependency in standalone consumer.
• Native/Lit share Router semantics as target; do not require Lit to import Native compiled artifacts. Beta.2.2 flow is [beta.2.2] Prove Native and Lit Framework Mode end-to-end #1339.

Governing plan (2026-09-08)

Maintainer-approved: ADR-0152, docs/current/VERSION_PLAN.md and #1341. Execution: https://github.com/orgs/open-element/projects/3. Acceptance checkpoints replace the three-day schedule. No automatic beta.2.4. Native/Lit are formal Framework Mode targets, not already-shipped support. Existing release records/versions remain unchanged; no closure without final-SHA evidence. examples/** stays frozen.