@ccslabs/xtend 0.1.0-rc.1 → 0.1.2

package/docs/en/xtendrmt-parsedown-scheduling.md

@@ -0,0 +1,301 @@
+# XTendRMT Parsedown Scheduling Pilot
+
+- Status: active Docs App pilot since `ER-WP-40`, shell-first refactor active
+- Contract: `xtend.docs.parsedown-rmt-scheduling.v1`
+- Pilot Contract: `xtend.docs.parsedown-rmt-pilot.v1`
+- Production-Hardening Contract: `xtend.epic13.docs-rmt-production-hardening.v1`
+- Pilot document: `docs/xtendrmt-parsedown-docs.rmt`
+- Current runtime: `docs/index.php` + `docs/utils/parsedown.php` + `docs/utils/pageloader.js`
+
+## Purpose
+
+The official XTend documentation is itself an XTend app. Markdown files in the `docs` folder are converted to HTML server-side through Parsedown and displayed client-side as an SPA through XRouter. The host now mirrors only the initially required HTML page into `window.xtendDocsPages`; additional Parsedown payloads are loaded per route through `window.xtendDocsPageEndpoint`.
+
+The current state is shell-first: the visible page shell is no longer built purely imperatively in PageLoader, but rendered as a `dom_descriptor` from `docs.app.shell` in the RMT pilot document. Parsedown remains the host adapter and only fills the content slot. This lets the Docs App later load rich HTML or XPlayer tutorial content alongside Markdown as RMT-planned slots; the machine-readable content kind for this is `xplayerTutorial`. Parsedown and XTend are not embedded into the RMT kernel.
+
+## ER-WP-40 Pilot Artifacts
+
+| Artifact | Role |
+|----------|------|
+| `docs/xtendrmt-parsedown-docs.rmt` | RMT pilot document for shell-first templates, docs routes, Parsedown templates, schedules, rich-content slots and host adapter |
+| `docs/index.php` | active parser host, sets `Parsedown::setSafeMode(true)` and mirrors `window.xtendDocsRmtDocument`, `window.xtendDocsRmtPilot` and `window.xtendDocsPagesMeta` |
+| `docs/utils/pageloader.js` | renders `docs.app.shell` and `docs.header.search` from RMT `dom_descriptor` templates, marks content slots with `data-rmt-template`, `data-rmt-parse-schedule`, `data-rmt-trust-boundary` and `xtend.docs.parsedown-rmt-render.v1` |
+| `tests/rmt/docs_rmt_pilot_suite.js` | gate for RMT normalization, runtime registry, Trusted DOM boundary and Docs App wiring |
+| `package.json` | metadata under `xtend.docsRmtPilot` and script `npm run test:docs-rmt-pilot` |
+
+The pilot is deliberately host-neutral: `docs/index.php` remains the parser host while RMT describes the shell, search UI, schedules and future content slots. PageLoader is therefore a host adapter for RMT descriptors.
+
+Starting with `WP-E13-10`, the same path also has the production-hardening layer `xtend.epic13.docs-rmt-production-hardening.v1`. It stabilizes `docs.slot.content`, `docs.slot.rich-content`, `docs.slot.media` and `docs.slot.diagnostics` so Parsedown HTML, rich HTML through `docs.rich-content.prepare`, XPlayer tutorials through `docs.media.lazy` and diagnostics can be scheduled separately. The gate is `node scripts/run_xtend_tests.js epic13-docs-rmt-production-hardening --json`.
+
+Since skeleton hardening, the pilot uses the native `xtend.loader.skeleton-loader.v1` and `xtend.loader.style-registry.v1`: the loader registry covers undefined XTend Custom Elements with declarative skeletons or hidden Light DOM, XRouter shows a per-route skeleton fallback during import and hydration, and `xtend-doc-page` uses the same loader for the Parsedown content slot. This keeps the app shell visible and stable while the heavy HTML commit happens only after first paint. `xtend.css` remains usable as the standard file name for host theming, but it is no longer a hard requirement for this FOUC protection.
+
+## Current Docs App Flow
+
+1. `docs/index.php` finds all `.md` files recursively.
+2. `docs/utils/parsedown.php` converts only the initial or route-requested Markdown file to HTML.
+3. `window.xtendDocsPagesMeta` contains SEO, schedule and RMT metadata by slug; `window.xtendDocsPages` contains only existing HTML payloads.
+4. `<x-router mode="hash" skeleton="article">` routes to `xtend-doc-page`, lazy-loads its module and hydrates the route subtree through the loader.
+5. `docs/utils/pageloader.js` reads `window.xtendDocsRmtDocument` and renders `docs.app.shell` shell-first.
+6. The `data-rmt-slot="content"` slot shows a native SkeletonLoader until Parsedown HTML has been sanitized and inserted after first paint.
+7. `docs.header.search` provides header search as an RMT descriptor for the `search` slot of `x-header`.
+8. `docs/menu.json` defines the visible navigation hierarchy; `pageloader.js` groups and prioritizes it for drawer navigation.
+
+Since the document-title rewrite, additional RMT route records are generated for every Markdown file and mirrored into `window.xtendDocsRmtDocument.routes`. `docs/index.php` extracts the first H1 as `title`, creates `documentTitle`, `titleTemplate`, `metaDescription` and `metaKeywords`, and renders the visible `<x-route>` attributes `title`, `document-title`, `title-template`, `meta-description` and `meta-keywords` from them. XRouter then performs the actual writes to `document.title` and the SEO meta tags. This keeps the use case declarative in RMT while browser side effects remain in the XRouter adapter.
+
+This flow remains a host flow. RMT provides the shell and schedule records; DOM sinks, Parsedown and concrete event bindings remain in the Docs host adapter.
+
+After sanitizing, the host adapter also normalizes inline code from Parsedown SafeMode. SafeMode escapes backtick content such as `` `<x-code>` `` twice in some cases (`&amp;lt;...&amp;gt;`). `pageloader.js` decodes these entities only inside `<code>` nodes and writes them back as `textContent`. This keeps the Trusted DOM boundary intact while component and API names remain readable in the documentation.
+
+## Navigation Hierarchy
+
+Since hierarchy hardening, docs navigation uses stable metadata per article:
+
+- `id`: canonical article ID, for example `docs.components.xcode`
+- `group`: visible navigation area such as `core`, `components`, `rmt` or `release`
+- `parent`: optional parent slug for deep-dive branches
+- `tier`: classification such as `basic`, `deep-dive`, `component-reference` or `release-deep-dive`
+- `rank`: PageRank-like visibility value where high values appear first and directly visible
+
+This means users first see foundations such as the start page, manifest, API, component overview or XTendRMT overview. Specific articles are offered cascaded under the respective entry point as deep dives.
+
+## RMT Target Shape
+
+Parsedown is described as its own host adapter:
+
+```json
+{
+  "id": "docs.parsedown",
+  "kind": "template_adapter",
+  "runtimeSurface": ["server", "browser_classic"],
+  "providedCapabilities": ["markdown", "htmlFragments", "slugIndex", "scheduleRefs"],
+  "kernelVisible": false
+}
+```
+
+The Docs App remains XTend UI:
+
+```json
+{
+  "id": "docs.page",
+  "kind": "custom_element",
+  "adapter": "xtend.component",
+  "tag": "xtend-doc-page",
+  "schedule": "docs.page.hydrate"
+}
+```
+
+The shell itself is an RMT template:
+
+```json
+{
+  "id": "docs.app.shell",
+  "mode": "dom_descriptor",
+  "schedule": "docs.shell.render",
+  "nodes": [
+    {
+      "tag": "x-section",
+      "attributes": {
+        "data-rmt-shell": "docs.app.shell",
+        "data-rmt-shell-mode": "shell-first"
+      }
+    }
+  ]
+}
+```
+
+Parsedown work is planned as a schedule policy:
+
+```json
+{
+  "id": "docs.markdown.parse",
+  "endpointName": "xtendrmt.docs.parsedown.parse",
+  "scope": "docs.markdown",
+  "lane": "background",
+  "priority": 35,
+  "preferIdle": true,
+  "budgetClass": "background"
+}
+```
+
+## Pilot Document
+
+The production pilot document lives at `docs/xtendrmt-parsedown-docs.rmt`. It contains three real docs routes:
+
+- `/readme`
+- `/enterprise-adoption`
+- `/xtendrmt-parsedown-scheduling`
+
+Abbreviated structure:
+
+```json
+{
+  "kind": "rmt_document",
+  "version": "1.0",
+  "documentId": "docs.xtend.developer-center",
+  "namespace": "docs",
+  "adapters": [
+    {
+      "id": "docs.parsedown",
+      "kind": "template_adapter",
+      "runtimeSurface": ["server"],
+      "providedCapabilities": ["markdown", "htmlFragments", "slugIndex", "scheduleRefs"],
+      "kernelVisible": false
+    },
+    {
+      "id": "xtend.xrouter",
+      "kind": "router_adapter",
+      "runtimeSurface": ["browser_classic"],
+      "providedCapabilities": ["routes", "navigation", "scheduleRefs"],
+      "kernelVisible": false
+    },
+    {
+      "id": "xtend.component",
+      "kind": "component_adapter",
+      "runtimeSurface": ["browser_classic"],
+      "providedCapabilities": ["components", "customElements", "hydration", "scheduleRefs"],
+      "kernelVisible": false
+    }
+  ],
+  "components": [
+    {
+      "id": "docs.page",
+      "kind": "custom_element",
+      "adapter": "xtend.component",
+      "tag": "xtend-doc-page",
+      "schedule": "docs.page.hydrate"
+    },
+    {
+      "id": "docs.shell",
+      "kind": "template_component",
+      "adapter": "docs.rich-content",
+      "tag": "x-section",
+      "schedule": "docs.shell.render"
+    },
+    {
+      "id": "docs.media.player",
+      "kind": "custom_element",
+      "adapter": "xtend.component",
+      "tag": "x-player",
+      "schedule": "docs.media.lazy"
+    }
+  ],
+  "routes": [
+    {
+      "id": "docs.readme",
+      "path": "/readme",
+      "router": "xtend.xrouter",
+      "component": "docs.page",
+      "title": "XTend Developer Documentation",
+      "documentTitle": "XTend Developer Documentation | XTend Dokumentation",
+      "titleTemplate": "{{title}} | XTend Dokumentation",
+      "metaDescription": "Developer Documentation fuer XTend UI und XTendRMT.",
+      "template": "docs.readme.markdown",
+      "schedule": "docs.route.render"
+    }
+  ],
+  "schedules": [
+    {
+      "id": "docs.shell.render",
+      "endpointName": "xtendrmt.shell.render",
+      "scope": "docs.shell",
+      "lane": "visible",
+      "priority": 90
+    },
+    {
+      "id": "docs.markdown.parse",
+      "endpointName": "xtendrmt.docs.parsedown.parse",
+      "scope": "docs.markdown",
+      "lane": "background",
+      "priority": 35,
+      "preferIdle": true
+    },
+    {
+      "id": "docs.route.render",
+      "endpointName": "xtendrmt.route.render",
+      "scope": "docs.route.render",
+      "lane": "visible",
+      "priority": 80
+    },
+    {
+      "id": "docs.page.hydrate",
+      "endpointName": "xtendrmt.component.hydrate",
+      "scope": "docs.page.hydrate",
+      "lane": "idle",
+      "priority": 40,
+      "preferIdle": true
+    },
+    {
+      "id": "docs.media.lazy",
+      "endpointName": "xtendrmt.docs.media.lazy",
+      "scope": "docs.media",
+      "lane": "idle",
+      "preferIdle": true
+    }
+  ],
+  "templates": [
+    {
+      "id": "docs.readme.markdown",
+      "mode": "html_fragment",
+      "source": "docs/README.md",
+      "adapter": "docs.parsedown",
+      "security": {
+        "markupClass": "parsedownHtml",
+        "trustBoundary": "xtend.security.sanitizing-boundary.v1",
+        "sink": "trustedDomBoundary"
+      },
+      "hydration": {
+        "mode": "hydrate_prerendered",
+        "metadata": {
+          "endpointHint": "xtendrmt.docs.parsedown.parse"
+        }
+      }
+    }
+  ]
+}
+```
+
+## Responsibility Boundaries
+
+| Responsibility | Location |
+|----------------|----------|
+| Read Markdown | Docs App or Docs host adapter |
+| Execute Parsedown | `docs.parsedown` adapter |
+| Provide HTML fragments | Docs App host boundary with `xtend.security.sanitizing-boundary.v1` |
+| Render shell-first app shell | `docs.app.shell` through Docs host adapter |
+| Render header search | `docs.header.search` through Docs host adapter |
+| Prepare rich HTML and tutorial videos | `docs.rich-content` and `docs.media.lazy` |
+| Register routes | `createRmtXRouterAdapter` |
+| Hydrate page | `createRmtXtendComponentAdapter` |
+| Mirror scheduling and diagnostics | `createRmtStateSchedulerDiagnosticsBridge` |
+
+The RMT kernel receives only records, policies and diagnostics. It parses no Markdown, calls no PHP and sanitizes no HTML. Parsedown output counts as `parsedownHtml` despite `Parsedown::setSafeMode(true)` and must pass through the Trusted DOM policy from [Trusted DOM and Sanitizing](./trusted-dom-sanitizing.md).
+
+## Implemented Pilot Steps
+
+| Step | Status |
+|------|--------|
+| Convert Docs App flow to shell-first RMT shell | `done` |
+| Create `.rmt` pilot for docs routes and Parsedown schedules | `done` |
+| Describe `docs.parsedown` adapter as host layer | `done` |
+| Render `docs.app.shell` as production RMT app shell | `done` |
+| Render `docs.header.search` as RMT header-search template | `done` |
+| Prepare rich-content and `x-player` slots as future-ready RMT schedules | `done` |
+| Prove `xtend.security.sanitizing-boundary.v1` for Parsedown HTML in the host adapter | `done` |
+| Use `createRmtFormat().normalizeDocument(...)` and `createRuntimeRegistries(...)` for docs routes | `done` |
+| Add per-page RMT metadata to the Docs App | `done` |
+| Make Parsedown parse jobs schedulable through `xtendrmt.docs.parsedown.parse` | `done` |
+| Extend reference and RMT pilot gates | `done` |
+
+Not yet part of the pilot: production XRouter routes are not registered from the RMT document. That remains a later runtime expansion. Also not active yet: rich HTML and XPlayer content are only prepared as slots and schedules, but not filled with external tutorial payloads.
+
+## Minimum Gates
+
+```bash
+php -l docs/index.php
+node scripts/run_xtend_tests.js docs-rmt-pilot --json
+node scripts/run_xtend_tests.js references --json
+node scripts/run_xtend_tests.js browser --json
+node scripts/run_xtend_tests.js rmt-compatibility --json
+```
+
+The pilot is shell-first, but remains framework-agnostic. Until a production `docs.parsedown` runtime adapter replaces the PHP side, `docs/index.php` remains the active parser host.

package/docs/en/xtendrmt-runtime-bridge.md

@@ -0,0 +1,155 @@
+# XTendRMT Runtime Bridge
+
+- Status: current after Epic 05 completion
+- Contract: `xtend.docs.xtendrmt-runtime-bridge.v1`
+- Core contracts:
+  - `xtend.rmt.xrouter-adapter.v1`
+  - `xtend.rmt.xtend-component-adapter.v1`
+  - `xtend.rmt.state-scheduler-diagnostics-bridge.v1`
+  - `xtend.rmt.artifact-parity.v1`
+
+## Purpose
+
+The Runtime Bridge connects normalized RMT App DSL data with real host runtimes. It is deliberately adapter-based:
+
+- RMT normalizes and indexes.
+- XRouter registers and navigates routes.
+- XTend Components mount and hydrate UI.
+- The bridge mirrors adapter results, scheduler endpoints and diagnostics.
+
+This keeps the RMT kernel host-neutral.
+
+## Artifacts and Entry Points
+
+| Artifact | Use |
+|----------|-----|
+| `xtendrmt/rmt-core.esm.js` | ESM Core, tests and build reference |
+| `xtendrmt/rmt-runtime.esm.js` | ESM Runtime with production factories |
+| `xtendrmt/rmt-runtime.browser.js` | Browser Classic bundle, installs `window.xtend.rmt` |
+| `xtendrmt/rmt-core.d.ts` | TypeScript contract for public factories |
+| `xtendrmt/rmt-manifest.json` | Product manifest and artifact-parity contract |
+
+The browser bundle also provides `window.AppModules`. The production Classic surface is installed under `window.xtend.rmt`.
+
+## ESM Usage
+
+```js
+import {
+  createRmtFormat,
+  createRmtXRouterAdapter,
+  createRmtXtendComponentAdapter,
+  createRmtStateSchedulerDiagnosticsBridge
+} from './xtendrmt/rmt-runtime.esm.js';
+
+const format = createRmtFormat();
+const normalizedDocument = format.normalizeDocument(rmtDocument);
+const registry = format.createRuntimeRegistries(normalizedDocument);
+```
+
+## Browser Classic Usage
+
+```html
+<script src="/xtendrmt/rmt-runtime.browser.js"></script>
+<script type="module">
+  const appModules = window.AppModules;
+  const format = appModules.createRmtFormat();
+  const normalizedDocument = format.normalizeDocument(window.appRmtDocument);
+</script>
+```
+
+The browser smoke `tests/browser/fixtures/rmt-xrouter-xtend-smoke.html` uses this path.
+
+## XRouter Adapter
+
+```js
+const routeAdapter = createRmtXRouterAdapter({
+  routerElement: document.querySelector('x-router'),
+  xstate: window.xstate
+});
+
+const routeResult = routeAdapter.registerRoutes(registry);
+routeAdapter.navigate({ routeId: 'settings' }, {
+  mapping: routeResult.handle.mapping
+});
+```
+
+The adapter consumes `routeRegistry.byRouter["xtend.xrouter"]` and creates XRouter-compatible route records. RMT information remains visible as `data-rmt-*` attributes and route details.
+
+## XTend Component Adapter
+
+```js
+const componentAdapter = createRmtXtendComponentAdapter({
+  document,
+  customElements,
+  manifest: {
+    'x-card': '/components/xcards.js'
+  }
+});
+
+const mapping = componentAdapter.mapComponents(registry);
+componentAdapter.registerComponent(mapping);
+componentAdapter.mountComponent(rootElement, 'settings.card', {
+  label: 'Settings'
+});
+componentAdapter.hydrateComponent(rootElement, 'settings.card');
+```
+
+The adapter is responsible for manifest lookup, Custom Element registration, DOM creation, props, attributes, slots, events and hydration.
+
+## State/Scheduler/Diagnostics Bridge
+
+```js
+const bridge = createRmtStateSchedulerDiagnosticsBridge({
+  xstate: window.xstate,
+  scheduler: performanceRuntime,
+  diagnosticsHub
+});
+
+const stateBridge = bridge.createStateBridge();
+stateBridge.set('rmt.demo.ready', true);
+
+bridge.recordAdapterResult(routeResult, {
+  scheduleRef: 'route.visible.render'
+});
+
+bridge.recordTelemetrySnapshot(fabricSnapshot, {
+  scheduleRef: 'diagnostics.snapshot',
+  runInline: true
+});
+
+bridge.scheduleEndpoint(
+  'xtendrmt.component.hydrate',
+  'app.component.hydrate',
+  () => ({ ok: true }),
+  { runInline: true }
+);
+```
+
+Among other values, the bridge writes:
+
+- `rmt.bridge.ready`
+- `rmt.telemetry.lastSnapshot`
+- `rmt.backpressure.lastSignal`
+- `rmt.backpressure.profile`
+- `rmt.scheduler.lastEndpoint`
+- `rmt.adapter.lastResult`
+- `rmt.diagnostics.last`
+- `rmt.route.<id>.lastResult`
+- `rmt.component.<id>.lastResult`
+
+If no external `xstate` exists, the bridge falls back to an in-memory state handle and reports a degraded but usable state.
+
+## Multi-Host Rule
+
+Non-XTend hosts use the same RMT flow with their own adapter ID. The browser-smoke fixture uses `vanilla.component` and `xtendrmt.vanilla.mount` to ensure that XTend is a first-class host but not a kernel requirement.
+
+## Artifact Parity
+
+After changes to runtime, schema, manifest or types, the parity gate must run:
+
+```bash
+node scripts/verify_xtendrmt_artifact_parity.js --json
+node scripts/run_xtend_tests.js rmt-compatibility --json
+```
+
+The gate prevents drift between schema, manifest, type definitions, ESM bundles and browser bundle.

package/docs/enterprise-adoption.md

@@ -228,7 +228,7 @@ Die CI-Matrix trennt schnelle PR-Pruefung von Release-nahem Full Gate:
 |------|---------|-------|
 | PR Fast | `npm run test:pr:report` | schnelles Feedback fuer Pull Requests |
 | Full Release | `npm run test:release:full:report` | komplette lokale Runner-Suite mit JSON Report |
-| Nightly | `npm run test:release:full:report` | wiederkehrender Release-naher Lauf |
+| Nightly Build | `.github/workflows/xtend-nightly-build.yml` | wiederkehrender Node-26-Artefaktlauf mit Release-, RMT-Primitive- und Pack-Evidence |
 
 Release-Kandidaten brauchen zusaetzlich:
 
@@ -243,6 +243,8 @@ npm run pack:dry-run
 
 Conditional Network Gates:
 
+Nightly Build Evidence wird als `xtend-nightly-build-node-26` hochgeladen und enthaelt `.xtend-test-results/xtend-nightly-build-manifest.json`. Browser-heavy Source-to-Sea Evidence und Audit/SBOM Network Evidence bleiben in diesem Workflow bewusst manuelle Jobs via `run_source_to_sea=true` und `run_conditional_network=true`.
+
 ```bash
 npm audit --audit-level=moderate
 npm sbom --sbom-format=cyclonedx --json
@@ -390,7 +392,7 @@ Weiterfuehrend: [RC1 Readiness](./rc1-readiness.md), [Release Owner Acceptance](
 XTend ist nach `ER-WP-40`, `WP-E10-16` und `WP-E11-18` enterprise-adoptionsfaehig vorbereitet, aber noch kein finaler `1.0.0`-Release:
 
 - `private: false` ist fuer RC1-Publish-Prep aktiv.
-- Component Catalog Coverage steht nach `RC1TB-WP-03` bei 42/42 Source und Docs, 42/42 Component-Suites, Fixtures und Types, 41/42 A11y sowie 40 expliziten Runtime-/UI-Performance-Profilen. `x-input`, `x-select`, `x-checkbox`, `x-radio`, `x-rmt-lifecycle-demo-build`, `x-textarea`, `x-form`, `x-calendar`, `x-writer`, `x-status`, `x-progress`, `x-tooltip`, `x-popover`, `x-drawer`, `x-surface-manager`, `x-surface-window`, `x-side-panel`, `x-modal`, `x-dialog`, `x-alert`, `x-toast`, `x-spinner`, `x-router`, `x-link`, `x-tabs`, `x-theme`, `x-button`, `x-icon`, `x-menu`, `x-footer`, `x-lightbox`, `x-masonry`, `x-code`, `x-header`, `x-hero`, `x-type`, `x-summary`, `x-section`, `x-cards` und `x-player` sind `enterprise-ready`; `xstate` ist seit `WP-E13-05` als Runtime-Boundary geschlossen; `x-utils` ist seit `WP-E13-05` als Utility-Boundary geschlossen. `x-icon` stellt den lokalen, CDN-freien Iconography Adapter mit internem Core Pack, lokalem Lucide Superset und RMT-kompatibler Pack-Schnittstelle bereit; `x-surface-manager`, `x-surface-window` und `x-side-panel` bilden die erste native Multi-Window- und SidePanel-Surface-Schicht.
+- Component Catalog Coverage steht nach `RC1TB-WP-03` bei 44/44 Source und Docs, 44/44 Component-Suites, Fixtures und Types, 43/44 A11y sowie 42 expliziten Runtime-/UI-Performance-Profilen. `x-input`, `x-select`, `x-checkbox`, `x-radio`, `x-rmt-lifecycle-demo-build`, `x-textarea`, `x-form`, `x-calendar`, `x-writer`, `x-status`, `x-progress`, `x-tooltip`, `x-popover`, `x-drawer`, `x-surface-manager`, `x-surface-portal`, `x-surface-region`, `x-surface-window`, `x-side-panel`, `x-modal`, `x-dialog`, `x-alert`, `x-toast`, `x-spinner`, `x-router`, `x-link`, `x-tabs`, `x-theme`, `x-button`, `x-icon`, `x-menu`, `x-footer`, `x-lightbox`, `x-masonry`, `x-code`, `x-header`, `x-hero`, `x-type`, `x-summary`, `x-section`, `x-cards` und `x-player` sind `enterprise-ready`; `xstate` ist seit `WP-E13-05` als Runtime-Boundary geschlossen; `x-utils` ist seit `WP-E13-05` als Utility-Boundary geschlossen. `x-icon` stellt den lokalen, CDN-freien Iconography Adapter mit internem Core Pack, lokalem Lucide Superset und RMT-kompatibler Pack-Schnittstelle bereit; `x-surface-manager`, `x-surface-portal`, `x-surface-region`, `x-surface-window` und `x-side-panel` bilden die native Multi-Window-, Portal-, Region- und SidePanel-Surface-Schicht.
 - Performance-Profile sind fuer alle sichtbaren Runtime-/UI-Komponenten priorisiert und vorhanden; Infrastruktur-/Utility-Pfade werden ueber Boundary-Contracts bewertet.
 - Netzwerkbasierte Supply-Chain-Gates sind Conditional Gates.
 - `WP-E12-15` aktualisiert die oeffentliche Adoption-Flaeche: Long-Tail Closure, DOM-first Snapshot Gate, Design Token Productization, RMT DSL Authoring Polish, Known Residual Policy und RC0 Gate Matrix sind in `docs/rc0-adoption-guide.md` zusammengefuehrt.