@ccslabs/xtend 0.1.0-rc.1 → 0.1.2

package/docs/visual-browser-regression.md

@@ -51,7 +51,7 @@ Der Plan haelt die frueheren Boundary-Luecken nachvollziehbar, aber nicht mehr a
 - 0 Manifest-Eintraege brauchen noch Suite-, Fixture- oder Type-Nacharbeit.
 - `xstate` ist seit `WP-E13-05` als Runtime-Boundary geschlossen.
 - `x-utils` ist seit `WP-E13-05` als Utility-Boundary geschlossen.
-- Die 40 sichtbaren Runtime-/UI-Komponenten behalten explizite Performance-Profile; `xstate` und `x-utils` werden nicht kuenstlich zu visuellen Profiltraegern umgedeutet.
+- Die 42 sichtbaren Runtime-/UI-Komponenten behalten explizite Performance-Profile; `xstate` und `x-utils` werden nicht kuenstlich zu visuellen Profiltraegern umgedeutet.
 
 Damit ist klar, dass `ER-WP-35` priorisiert, aber die eigentliche Screenshot-/Pixel-Regression an CI und Release Readiness uebergibt.
 

package/docs/xtend-rmt-types.md

@@ -10,16 +10,17 @@
 
 ## Zweck
 
-`WP-TypeExports-04` macht die XTendRMT Runtime, den Browser-Entry und die RMT-Language-/Tooling-Exports fuer TypeScript-Consumer importierbar. Die Runtime bleibt unveraendert: `./rmt` und `./rmt/browser` zeigen per `types`-Condition auf `./xtendrmt/rmt-core.d.ts`, waehrend die JS-Ziele weiterhin `rmt-runtime.esm.js` und `rmt-runtime.browser.js` bleiben.
+`WP-TypeExports-04` macht die XTendRMT Runtime, den Browser-Entry und die RMT-Language-/Tooling-Exports fuer TypeScript-Consumer importierbar. `./rmt` und `./rmt/browser` zeigen per `types`-Condition auf `./xtendrmt/rmt-core.d.ts`, waehrend `./rmt/dom-descriptor-renderer`, `./rmt/component-capability-registry`, `./rmt/state-selector-runtime`, `./rmt/action-effect-runtime`, `./rmt/event-routing-runtime` und `./rmt/surface-resource-graph-runtime` eigene schmale Runtime-Declarations besitzen.
 
 ## Declaration Pack
 
 | Bereich | Package Export | Declaration |
 | --- | --- | --- |
 | RMT Runtime | `./rmt`, `./rmt/browser` | `./xtendrmt/rmt-core.d.ts` |
+| RMT App Platform Runtime | `./rmt/dom-descriptor-renderer`, `./rmt/component-capability-registry`, `./rmt/state-selector-runtime`, `./rmt/action-effect-runtime`, `./rmt/event-routing-runtime`, `./rmt/surface-resource-graph-runtime` | `./xtendrmt/rmt-dom-descriptor-renderer.d.ts`, `./xtendrmt/rmt-component-capability-registry.d.ts`, `./xtendrmt/rmt-state-selector-runtime.d.ts`, `./xtendrmt/rmt-action-effect-runtime.d.ts`, `./xtendrmt/rmt-event-routing-runtime.d.ts`, `./xtendrmt/rmt-surface-resource-graph-runtime.d.ts` |
 | Source Model und Parser | `./rmt-language/source-model`, `./rmt-language/parser` | `tools/rmt-language/*.d.ts` |
 | vNext Compiler und Contracts | `./rmt-language/vnext-*` | `tools/rmt-language/vnext-*.d.ts` |
-| Tooling Services | `./rmt-language/diagnostics`, `./rmt-language/completions`, `./rmt-language/hover`, `./rmt-language/symbols`, `./rmt-language/definitions`, `./rmt-language/code-actions` | Service-Facades mit gemeinsamen RMT-Tooling-Typen |
+| Tooling Services | `./rmt-language/diagnostics`, `./rmt-language/app-platform-tooling`, `./rmt-language/completions`, `./rmt-language/hover`, `./rmt-language/symbols`, `./rmt-language/definitions`, `./rmt-language/code-actions` | Service-Facades mit gemeinsamen RMT-Tooling-Typen |
 | LSP, Linter, Editor | `./rmt-language-server`, `./rmt-linter/*`, `./rmt-editor/vscode` | LSP-/CLI-/Editor-Facades |
 
 Der gemeinsame Typkern liegt in `tools/rmt-language/rmt-tooling-public-types.d.ts` und enthaelt unter anderem `RmtToolingDiagnostic`, `RmtTextEdit`, `RmtWorkspaceEdit`, `RmtLanguageServiceReport` und `RmtJsonRpcMessage`.

package/docs/xtendrmt-app-dsl.md

@@ -1,35 +1,48 @@
 # XTendRMT App-DSL Reference
 
-- Status: aktuell nach Epic 05 Abschluss
+- Status: aktuell nach Epic 05 Abschluss, vNext-first aktualisiert
 - Contract: `xtend.docs.xtendrmt-app-dsl.v1`
 - Schema-Quelle: `xtendrmt/rmt.schema.json`
 - Normalizer: `createRmtFormat().normalizeDocument(...)`
 
 ## Zweck
 
-Die App-DSL beschreibt eine renderbare Anwendung als RMT-Dokument. Sie ist kein XTend-spezifisches Format. XTend UI, XRouter, Vanilla JS oder andere Hosts werden ueber Adapter Records angebunden.
+Die App-DSL beschreibt eine renderbare Anwendung als RMT-Dokument. Neue
+Authoring-Arbeit nutzt RMT vNext; Legacy-/App-DSL-JSON ist weiterhin der
+normalisierte Core-Output, Runtime Registry und Compatibility Surface. XTend UI,
+XRouter, Vanilla JS oder andere Hosts werden ueber Adapter Records angebunden,
+ohne dass der Kernel Host-Runtime importiert.
 
-Seit `WP-E13-09` buendelt [RMT Production Readiness](./rmt-production-readiness.md) diese App-DSL unter `xtend.epic13.rmt-production-readiness.v1` als RC1-Schnitt fuer Shell-first App Shell, native Routes, Components, Fabric/Lanes, Lifecycle Telemetry, Diagnostics und Artifact Parity.
+Seit `WP-E13-09` buendelt [RMT Production
+Readiness](./rmt-production-readiness.md) diese App-DSL unter
+`xtend.epic13.rmt-production-readiness.v1` als RC1-Schnitt fuer Shell-first App
+Shell, native Routes, Components, Fabric/Lanes, Lifecycle Telemetry,
+Diagnostics und Artifact Parity.
 
-## Minimales Dokument
+## Minimales vNext-Dokument
 
-```json
-{
-  "kind": "rmt_document",
-  "version": "1.0",
-  "documentId": "app.shell",
-  "namespace": "app",
-  "adapters": [],
-  "components": [],
-  "routes": [],
-  "schedules": [],
-  "templates": []
+```rmt
+template app.shell {
+  state app.ready type boolean initial true
+
+  portal surface.root root "#app-root" layer surface
+
+  surface app.home kind page component x-section {
+    source state app.ready
+    portal surface.root
+
+    lane visible weight 80 {
+      hydrate app-shell from state app.ready
+    }
+  }
 }
 ```
 
-Template-only-Dokumente bleiben gueltig. Neue App-DSL-Dokumente sollen operative Host-Daten aber in nativen Top-Level-Domains fuehren.
+Der Compiler senkt diese Quelle in Core-Domains wie `adapters`, `components`,
+`routes`, `schedules`, `surfaces` und `templates`. Diese Domains sind fuer
+Runtime-Adapter stabil, aber nicht mehr die bevorzugte Schreiboberflaeche.
 
-## Native Domains
+## Native Domains als Compiler-Output
 
 | Domain | Aufgabe |
 |--------|---------|
@@ -37,95 +50,102 @@ Template-only-Dokumente bleiben gueltig. Neue App-DSL-Dokumente sollen operative
 | `components` | fachliche Component Records, Host Adapter und Hydration-Hinweise |
 | `routes` | Navigation, Route-Ziele, Query/Params und Schedule References |
 | `schedules` | wiederverwendbare Scheduler Policies |
-| `templates` | Markup, Props, Slots, Bindings und Hydration Contracts |
+| `templates` | `dom_descriptor`, Props, Slots, Bindings und Hydration Contracts |
+| `surfaces` | SurfaceManager-, Window-, Panel- und Overlay-Handoffs |
 
-`manifest.metadata` bleibt fuer Beschreibung, Handoff, Historie und Demo-Notizen gueltig. Neue operative Routes, Components und Schedules gehoeren nicht mehr in `manifest.metadata`.
+`manifest.metadata` bleibt fuer Beschreibung, Handoff, Historie und Demo-Notizen
+gueltig. Neue operative Routes, Components und Schedules gehoeren in vNext-
+Source und werden daraus in die Registry projiziert.
 
 ## Adapter Records
 
-```json
-{
-  "id": "xtend.xrouter",
-  "kind": "router_adapter",
-  "runtimeSurface": ["esm", "browser_classic"],
-  "providedCapabilities": ["routes", "navigation", "params", "query", "scheduleRefs"],
-  "kernelVisible": false
-}
-```
-
-Stabile Adapter-IDs:
+Adapter werden in vNext implizit durch Surface-, Route- und Endpoint-Nutzung
+sichtbar. Die Registry enthaelt danach stabile Adapter Records fuer Hosts:
 
 - `xtend.xrouter`
 - `xtend.component`
+- `xtend.surface`
 - `rmt.state-scheduler-diagnostics`
 - `vanilla.component`
 
-`kernelVisible: false` ist fuer host-spezifische Adapterdaten der Normalfall. Der Kernel darf diese Records indizieren, aber keine Host-Runtime laden.
+`kernelVisible: false` ist fuer host-spezifische Adapterdaten der Normalfall.
+Der Kernel darf diese Records indizieren, aber keine Host-Runtime laden.
 
 ## Component Records
 
-```json
-{
-  "id": "settings.card",
-  "kind": "custom_element",
-  "adapter": "xtend.component",
-  "tag": "x-card",
-  "schedule": "component.idle.hydrate",
-  "props": {
-    "label": "Settings"
-  },
-  "attributes": {
-    "data-host": "xtend"
-  },
-  "hydration": {
-    "mode": "runtime_render",
-    "ownershipMode": "managed_subtree"
+Ein vNext-Surface beschreibt das fachliche Host-Element:
+
+```rmt
+template settings.components {
+  portal surface.root root "#settings-root" layer surface
+
+  surface settings.card kind card component x-card {
+    portal surface.root
+
+    lane visible weight 80 {
+      mount x-card
+      hydrate settings-card from endpoint xtendrmt.component.hydrate
+    }
   }
 }
 ```
 
-Der Normalizer macht daraus Runtime-Registry-Eintraege, die ueber `componentRegistry.byAdapter["xtend.component"]` und `componentRegistry.byTag["x-card"]` konsumierbar sind.
+Der Normalizer macht daraus Runtime-Registry-Eintraege, die ueber
+`componentRegistry.byAdapter["xtend.component"]` und
+`componentRegistry.byTag["x-card"]` konsumierbar sind.
 
 ## Route Records
 
-```json
-{
-  "id": "settings",
-  "path": "/settings",
-  "router": "xtend.xrouter",
-  "component": "settings.card",
-  "title": "Settings",
-  "documentTitle": "Settings | XTend App",
-  "metaDescription": "Einstellungen der XTend RMT App",
-  "metaKeywords": ["xtend", "rmt", "routing"],
-  "template": "settings.shell",
-  "schedule": "route.visible.render",
-  "metadata": {
-    "seo": {
-      "titleTemplate": "{{title}} | XTend App"
+Route-Metadaten bleiben deklarativ und koennen an Surfaces gekoppelt werden:
+
+```rmt
+template settings.routes {
+  state settings.tab type string initial "profile"
+
+  portal surface.root root "#app-root" layer surface
+
+  surface settings.page kind page component x-section {
+    source state settings.tab
+    portal surface.root
+
+    lane visible weight 80 {
+      hydrate route-view from endpoint xtendrmt.route.render
+      hydrate settings-shell from state settings.tab
     }
   }
 }
 ```
 
-Der Normalizer macht daraus Runtime-Registry-Eintraege, die ueber `routeRegistry.byRouter["xtend.xrouter"]`, `routeRegistry.byId["settings"]` und `routeRegistry.byPath["/settings"]` konsumierbar sind. `title`, `documentTitle`, `titleTemplate`, `metaDescription` und `metaKeywords` bleiben deklarative Route-Metadaten: XRouter schreibt daraus `document.title` sowie `description`/`keywords`, ohne dass RMT XTend oder XRouter importiert.
+Der Normalizer erzeugt daraus Route- und Schedule-Indizes fuer
+`routeRegistry.byRouter["xtend.xrouter"]`, `routeRegistry.byId[...]` und
+`routeRegistry.byPath[...]`. `title`, `documentTitle`, `titleTemplate`,
+`metaDescription` und `metaKeywords` bleiben deklarative Route-Metadaten:
+XRouter schreibt daraus `document.title` sowie `description`/`keywords`, ohne
+dass RMT XTend oder XRouter importiert.
 
 ## Schedule Records
 
-```json
-{
-  "id": "route.visible.render",
-  "endpointName": "xtendrmt.route.render",
-  "scope": "app.route.render",
-  "lane": "visible",
-  "priority": 80,
-  "deadlineMs": 250,
-  "preferIdle": false,
-  "budgetClass": "interactive"
+Schedules sind in vNext `lane`- und Lifecycle-Klauseln:
+
+```rmt
+template scheduler.page {
+  portal surface.root root "#app-root" layer surface
+
+  surface app.shell kind page component x-section {
+    portal surface.root
+
+    lane visible weight 80 {
+      hydrate route-shell from endpoint xtendrmt.route.render
+    }
+
+    lane idle weight 20 {
+      hydrate help-panel from endpoint xtendrmt.component.hydrate
+    }
+  }
 }
 ```
 
-Erprobte Endpoint-Namen:
+Erprobte Endpoint-Namen bleiben:
 
 - `xtendrmt.route.render`
 - `xtendrmt.component.mount`
@@ -136,80 +156,116 @@ Erprobte Endpoint-Namen:
 
 ## Template Records und Trusted DOM
 
-Neue Template Records sollen strukturierte Daten mit `dom_descriptor` bevorzugen:
+Neue Templates werden aus vNext-Surfaces und Slots in `dom_descriptor` Output
+gesenkt:
+
+```rmt
+template settings.template {
+  portal surface.root root "#settings-root" layer surface
+
+  surface settings.shell kind page component x-card {
+    portal surface.root
 
-```json
-{
-  "id": "settings.shell",
-  "mode": "dom_descriptor",
-  "nodes": [
-    { "tag": "x-card", "attributes": { "label": "Settings" } }
-  ]
+    lane visible weight 80 {
+      hydrate settings-card from endpoint xtendrmt.component.hydrate {
+        slot header hydrate settings-header
+        slot body hydrate settings-body
+      }
+    }
+  }
 }
 ```
 
-`html_fragment` bleibt kompatibel, braucht aber eine explizite Trusted-DOM-Boundary:
-
-```json
-{
-  "id": "settings.shell.legacy",
-  "mode": "html_fragment",
-  "markup": "<x-card label=\"Settings\"></x-card>",
-  "security": {
-    "markupClass": "htmlFragment",
-    "trustBoundary": "xtend.security.sanitizing-boundary.v1",
-    "sink": "trustedDomBoundary"
+`html_fragment` bleibt kompatibel, braucht aber eine explizite
+Trusted-DOM-Boundary:
+
+```rmt
+template settings.legacyHtml {
+  surface settings.legacy kind card component x-card {
+    lane visible weight 60 {
+      hydrate legacy-fragment from endpoint docs.parse {
+        trust boundary "xtend.security.sanitizing-boundary.v1"
+        sanitize html_fragment
+      }
+    }
   }
 }
 ```
 
-Der Kernel darf solche Records normalisieren und schedulen. Sanitizing, Trusted DOM und konkrete DOM-Sinks bleiben Host-Adapter-Aufgabe. Siehe [Trusted DOM und Sanitizing](./trusted-dom-sanitizing.md).
+Der Kernel darf solche Records normalisieren und schedulen. Sanitizing, Trusted
+DOM und konkrete DOM-Sinks bleiben Host-Adapter-Aufgabe. Siehe [Trusted DOM und
+Sanitizing](./trusted-dom-sanitizing.md).
 
 ## Shell-first Host Apps
 
-Die Docs-App nutzt diesen Pfad produktiv als Shell-first-Pilot. `docs/xtendrmt-parsedown-docs.rmt` beschreibt `docs.app.shell` als `dom_descriptor`, `docs.header.search` als Header-Search-Slot-Template und `docs.media.lazy` als future-ready Slot fuer XPlayer-Tutorials. `docs/utils/pageloader.js` rendert zuerst die RMT-Shell und setzt Parsedown-HTML anschliessend nur noch in den `data-rmt-slot="content"` Slot.
+Die Docs-App nutzt diesen Pfad produktiv als Shell-first-Pilot.
+`docs/xtendrmt-parsedown-docs.rmt` beschreibt `docs.app.shell` als
+`dom_descriptor`, `docs.header.search` als Header-Search-Slot-Template und
+`docs.media.lazy` als future-ready Slot fuer XPlayer-Tutorials.
+`docs/utils/pageloader.js` rendert zuerst die RMT-Shell und setzt
+Parsedown-HTML anschliessend nur noch in den `data-rmt-slot="content"` Slot.
 
-Wichtig: Auch in diesem Modus bleibt RMT framework-agnostisch. Parsedown, Rich-HTML-Sinks, XPlayer-Lazy-Loading und konkrete DOM-Events werden vom Host-Adapter ausgefuehrt. RMT stellt Shell-Records, Slots, Schedules und Diagnostics bereit.
+Wichtig: Auch in diesem Modus bleibt RMT framework-agnostisch. Parsedown,
+Rich-HTML-Sinks, XPlayer-Lazy-Loading und konkrete DOM-Events werden vom
+Host-Adapter ausgefuehrt. RMT stellt Shell-Records, Slots, Schedules und
+Diagnostics bereit.
 
 ## RMT-first XTend Apps
 
-Ab Epic 10 ist das App-Authoring fuer vollstaendige XTend-Apps als Contract `xtend.rmt.first-class-app-authoring.v1` beschrieben. Das Ziel ist eine App, deren Shell, Routes, Components, Templates, Events, Commands, Hydration Policies, Fabric-Lanes und Diagnostics komplett in RMT stehen.
+Ab Epic 10 ist das App-Authoring fuer vollstaendige XTend-Apps als Contract
+`xtend.rmt.first-class-app-authoring.v1` beschrieben. Das Ziel ist eine App,
+deren Shell, Routes, Components, Templates, Events, Commands, Hydration
+Policies, Fabric-Lanes und Diagnostics komplett in RMT stehen.
 
-Der Referenzpfad liegt in `tests/fixtures/rmt-first-class-xtend-app.rmt`. Der Gate ist:
+Der Referenzpfad liegt in `tests/fixtures/rmt-first-class-xtend-app.rmt`. Der
+Gate ist:
 
 ```bash
 node scripts/run_xtend_tests.js rmt-first-class-app --json
 ```
 
-Der Contract bleibt bewusst host-neutral. RMT kennt `xtend.component`, `xtend.xrouter` und `rmt.state-scheduler-diagnostics` als Adapter-Records, importiert aber keine XTend-Komponenten und kein XRouter-Modul in den Kernel. Details stehen in `development/XTend-RMT-First-Class-App-Authoring.md`.
+Der Contract bleibt bewusst host-neutral. RMT kennt `xtend.component`,
+`xtend.xrouter` und `rmt.state-scheduler-diagnostics` als Adapter-Records,
+importiert aber keine XTend-Komponenten und kein XRouter-Modul in den Kernel.
+Details stehen in `development/XTend-RMT-First-Class-App-Authoring.md`.
 
-Der kanonische Entwicklerguide fuer komplette XTend Apps liegt in [RMT-first XTend Apps](./rmt-first-xtend-apps.md). Der Epic-10-Abschluss und die Release-Gates sind in [Epic 10 Release Handoff](./epic10-release-handoff.md) dokumentiert.
+Der kanonische Entwicklerguide fuer komplette XTend Apps liegt in [RMT-first
+XTend Apps](./rmt-first-xtend-apps.md). Der Epic-10-Abschluss und die
+Release-Gates sind in [Epic 10 Release Handoff](./epic10-release-handoff.md)
+dokumentiert.
 
 ## Component Fabric Context
 
-XTend Components koennen Fabric-Hints in `metadata.fabric` tragen:
-
-```json
-{
-  "id": "pages.settings",
-  "adapter": "xtend.component",
-  "tag": "x-form",
-  "schedule": "component.idle.hydrate",
-  "metadata": {
-    "fabric": {
-      "lane": "idle",
-      "fiber": "component.hydrate",
-      "telemetry": true
+XTend Components koennen Fabric-Hints aus vNext-Lanes und Legacy-Metadata
+erhalten:
+
+```rmt
+template pages.settings {
+  portal surface.root root "#app-root" layer surface
+
+  surface pages.settings kind page component x-form {
+    portal surface.root
+
+    lane idle weight 40 {
+      hydrate settings-form from endpoint xtendrmt.component.hydrate
     }
   }
 }
 ```
 
-Der produktive Adapter loest diese Daten ueber `xtend.component.fabric-lane-ingestion.v2` auf. RMT Schedule Records haben Vorrang vor Component Metadata, Runtime Overrides, Static Contracts und Scaffold Defaults. Der Gate ist `node scripts/run_xtend_tests.js rmt-component-fabric-ingestion --json`.
+Der produktive Adapter loest diese Daten ueber
+`xtend.component.fabric-lane-ingestion.v2` auf. RMT Schedule Records haben
+Vorrang vor Component Metadata, Runtime Overrides, Static Contracts und
+Scaffold Defaults. Der Gate ist
+`node scripts/run_xtend_tests.js rmt-component-fabric-ingestion --json`.
 
 ## Component Lifecycle Telemetry
 
-Der Adapter erzeugt ab `xtend.component.lifecycle-telemetry.v1` Lifecycle Records fuer Component-Arbeit. RMT-Dokumente muessen dafuer keinen XTend-Code importieren; sie liefern nur Component-, Route-, Schedule- und Fabric-Kontext. Der Host kann `telemetryCollector`, `recordTelemetry` oder eine Fabric-Instanz uebergeben.
+Der Adapter erzeugt ab `xtend.component.lifecycle-telemetry.v1` Lifecycle
+Records fuer Component-Arbeit. RMT-Dokumente muessen dafuer keinen XTend-Code
+importieren; sie liefern nur Component-, Route-, Schedule- und Fabric-Kontext.
+Der Host kann `telemetryCollector`, `recordTelemetry` oder eine Fabric-Instanz
+uebergeben.
 
 ```js
 const records = [];
@@ -223,7 +279,11 @@ const snapshot = fabric.createTelemetrySnapshot({
 });
 ```
 
-`snapshot.componentTelemetry` aggregiert `mount`, `hydrate`, `render`, `update`, `event`, `unmount` und `error` nach Operation, Component und Lane. Component-Fehler, Deadline-Ueberschreitungen und explizite `backpressureSignal` Metadata koennen Backpressure erzeugen. Der Gate ist `node scripts/run_xtend_tests.js rmt-component-lifecycle-telemetry --json`.
+`snapshot.componentTelemetry` aggregiert `mount`, `hydrate`, `render`, `update`,
+`event`, `unmount` und `error` nach Operation, Component und Lane.
+Component-Fehler, Deadline-Ueberschreitungen und explizite
+`backpressureSignal` Metadata koennen Backpressure erzeugen. Der Gate ist
+`node scripts/run_xtend_tests.js rmt-component-lifecycle-telemetry --json`.
 
 Hosts koennen Fabric Snapshots direkt an die produktive RMT Bridge uebergeben:
 
@@ -233,10 +293,14 @@ bridge.recordTelemetrySnapshot(snapshot, {
 });
 ```
 
-Die Bridge spiegelt daraus `rmt.telemetry.lastSnapshot` und `rmt.backpressure.*` und plant bei Bedarf den Diagnostics-Snapshot-Endpunkt.
+Die Bridge spiegelt daraus `rmt.telemetry.lastSnapshot` und
+`rmt.backpressure.*` und plant bei Bedarf den Diagnostics-Snapshot-Endpunkt.
 
 ## Runtime Registry
 
+Die Registry ist die konsumierbare Grenze zwischen DSL und Adapter. Adapter
+lesen Registry-Eintraege, nicht rohe Demo-Metadaten:
+
 ```js
 const format = createRmtFormat();
 const normalizedDocument = format.normalizeDocument(document);
@@ -246,11 +310,10 @@ const registry = format.createRuntimeRegistries(normalizedDocument, {
 });
 ```
 
-Die Registry ist die konsumierbare Grenze zwischen DSL und Adapter. Adapter lesen Registry-Eintraege, nicht rohe Demo-Metadaten.
-
 ## Diagnostics
 
-Der App-DSL-Normalizer erzeugt Diagnostics, statt Host-Ausfuehrung zu erzwingen. Wichtige Gruppen:
+Der App-DSL-Normalizer erzeugt Diagnostics, statt Host-Ausfuehrung zu
+erzwingen. Wichtige Gruppen:
 
 - `rmt.dsl.reference.*` fuer fehlende oder ungueltige Referenzen
 - `rmt.runtime.registry.*` fuer Registry-Konflikte oder fehlende Required-Refs
@@ -260,7 +323,9 @@ Der App-DSL-Normalizer erzeugt Diagnostics, statt Host-Ausfuehrung zu erzwingen.
 
 ## Review-Checkliste
 
-- `adapters`, `components`, `routes` und `schedules` sind native Top-Level-Domains.
+- App-Shell-Beispiele sind `rmt` und vNext-first.
+- Runtime-Registry-JSON ist als generierter Output oder Compatibility Surface
+  eingeordnet.
 - Routes referenzieren Components und Schedules nur per ID.
 - Components referenzieren Host Adapter nur per ID.
 - Schedule Policies sind zentral und wiederverwendbar.

package/docs/xtendrmt-docs-shell-vnext.rmt

@@ -0,0 +1,165 @@
+template xtend.docs.php_ssr_shell {
+  state docs.shell.request type object preserve {
+    initial {
+      id "docs-shell"
+      locale "de"
+      slug "readme"
+      status "server-prehydrated"
+    }
+  }
+
+  state docs.shell.capabilities type object preserve {
+    initial {
+      id "docs-shell-capabilities"
+      components 12
+      jsonlStreaming true
+      hydrationMode "server_prerender_hydrate"
+    }
+  }
+
+  selector docs.shell.model from state docs.shell.request {
+    output DocsShellRequest
+  }
+
+  selector docs.shell.capabilityModel from state docs.shell.capabilities {
+    output DocsShellCapabilities
+  }
+
+  datasource docs.page.payload from endpoint "index.php?xtend-docs-page={slug}&locale={locale}" {
+    method GET
+    contract DocsParsedownPagePayload
+    result html
+    fallback fixture docs.page.initial
+  }
+
+  datasource docs.shell.ssr from endpoint "index.php?xtend-docs-rmt-ssr=shell&format=jsonl" {
+    method GET
+    contract DocsShellSsrFrames
+    result frames
+    fallback fixture docs.ssr.initial
+  }
+
+  action docs.route.navigate {
+    input path string
+    reduce state.docs.shell.request.status = "route-requested"
+    emit docs.route.requested with path input.path
+  }
+
+  action docs.search.submit {
+    input query string
+    reduce state.docs.shell.request.status = "search-requested"
+    emit docs.search.requested with query input.query
+  }
+
+  portal docs.shell.root root "body" layer surface
+
+  portal docs.overlay.root root "body" layer overlay z 1000 {
+    focus policy restore
+    pointer policy passthrough
+    scroll policy lock-when-modal
+  }
+
+  resource docs.shell.prehydration kind subscription owner surface.docs.root {
+    dispose on surface.destroy
+  }
+
+  surface docs.root kind shell component x-theme {
+    source selector docs.shell.model
+    key id
+    portal docs.shell.root
+    destroy releases resource docs.shell.prehydration
+
+    lane critical weight 100 {
+      mount docs-root-shell from endpoint xtendrmt.docs.php-ssr.shell
+    }
+
+    lane idle weight 20 {
+      hydrate docs-root-hydration from datasource docs.shell.ssr
+    }
+  }
+
+  surface docs.header kind header component x-header {
+    source selector docs.shell.model
+    key id
+    portal docs.shell.root
+
+    lane critical weight 96 {
+      mount docs-header from endpoint xtendrmt.docs.php-ssr.shell
+    }
+
+    on click "[data-docs-language-select]" -> action docs.route.navigate {
+      payload path from target.value
+    }
+  }
+
+  surface docs.hero kind hero component x-hero {
+    source selector docs.shell.model
+    key id
+    portal docs.shell.root
+
+    lane visible weight 86 {
+      mount docs-hero from endpoint xtendrmt.docs.php-ssr.shell
+    }
+  }
+
+  surface docs.router kind router component x-router {
+    source selector docs.shell.model
+    key id
+    portal docs.shell.root
+
+    lane visible weight 92 {
+      mount docs-router from endpoint xtendrmt.docs.php-ssr.shell
+    }
+
+    lane idle weight 24 {
+      prewarm docs-page-payload from datasource docs.page.payload
+    }
+  }
+
+  surface docs.page kind page component xtend-doc-page {
+    source selector docs.shell.model
+    key slug
+    portal docs.shell.root
+
+    lane visible weight 90 {
+      hydrate docs-page-shell from endpoint xtendrmt.docs.parsedown.parse
+    }
+
+    lane idle weight 18 {
+      prewarm docs-related-links from worker xtendrmt.docs.related.prepare
+    }
+  }
+
+  surface docs.sidebar kind panel component x-section {
+    source selector docs.shell.capabilityModel
+    key id
+    portal docs.shell.root
+
+    lane visible weight 60 {
+      hydrate docs-sidebar from endpoint xtendrmt.docs.php-ssr.shell
+    }
+  }
+
+  surface docs.footer kind footer component x-footer {
+    source selector docs.shell.model
+    key id
+    portal docs.shell.root
+
+    lane visible weight 54 {
+      mount docs-footer from endpoint xtendrmt.docs.php-ssr.shell
+    }
+  }
+
+  surface docs.diagnostics kind status component x-status {
+    source selector docs.shell.capabilityModel
+    key id
+    portal docs.overlay.root
+
+    lane diagnostics weight 12 {
+      stream docs-ssr-diagnostics from datasource docs.shell.ssr {
+        trust boundary "xtend.security.streaming-boundary.v1"
+        sanitize html
+      }
+    }
+  }
+}