@ccslabs/xtend 0.1.0-rc.1 → 0.1.2

package/docs/xtendrmt-migration-guide.md

@@ -9,7 +9,12 @@
 
 ## Zweck
 
-Dieser Guide beschreibt die Migration von fruehen XTendRMT-Metadatenpfaden zu nativen RMT Top-Level-Domains. Die Migration ist additiv und opt-in: bestehende XTend-, React-, Vue-, Vanilla-JS- und Custom-Apps duerfen weiterlaufen, waehrend neue RMT App-DSL-Dokumente direkt `adapters`, `components`, `routes` und `schedules` verwenden.
+Dieser Guide beschreibt die Migration von fruehen XTendRMT-Metadatenpfaden zu
+nativen RMT Top-Level-Domains und weiter zu RMT vNext. Die Migration ist
+additiv und opt-in: bestehende XTend-, React-, Vue-, Vanilla-JS- und
+Custom-Apps duerfen weiterlaufen, waehrend neue App-Shells in RMT vNext
+geschrieben werden. `adapters`, `components`, `routes`, `schedules` und
+`templates` bleiben Runtime Registry, Compiler-Output und Compatibility Mirror.
 
 Der aktuelle Produktueberblick liegt in [XTendRMT Developer Overview](./xtendrmt-overview.md). Die App-DSL-Details stehen in [XTendRMT App-DSL Reference](./xtendrmt-app-dsl.md), die produktive Adapter-/Bridge-Verkabelung in [XTendRMT Runtime Bridge](./xtendrmt-runtime-bridge.md).
 
@@ -19,14 +24,40 @@ Neue Dokumente sollen diese Quellen nutzen:
 
 | Bereich | Zielquelle |
 |---------|------------|
-| Host Adapter | `adapters` |
-| XTend Components | `components` mit `adapter: "xtend.component"` |
-| XRouter Routes | `routes` mit `router: "xtend.xrouter"` |
-| Scheduler Policies | `schedules` |
-| Markup oder Fragmente | `templates` |
+| Host Adapter | vNext Surface-/Endpoint-Nutzung, Output: `adapters` |
+| XTend Components | `surface ... component x-*`, Output: `components` mit `adapter: "xtend.component"` |
+| XRouter Routes | vNext Shell-/Route-Surface, Output: `routes` mit `router: "xtend.xrouter"` |
+| Scheduler Policies | `lane` und Lifecycle-Operationen, Output: `schedules` |
+| Markup oder Fragmente | `surface`, `slot`, `trust boundary`, Output: `templates` |
 | Beschreibung, Handoff, Historie | `manifest.metadata` |
 
-`manifest.metadata` bleibt fuer Produktbeschreibung, Handoff-Notizen, Demo-Historie und bewusst historische Pilotdaten gueltig. Operative Routes, Components und Schedules sollen dort nicht neu entstehen. Template-only-Dokumente bleiben kompatibel.
+`manifest.metadata` bleibt fuer Produktbeschreibung, Handoff-Notizen,
+Demo-Historie und bewusst historische Pilotdaten gueltig. Operative Routes,
+Components und Schedules sollen dort nicht neu entstehen.
+Template-only-Dokumente bleiben kompatibel.
+
+## vNext-Zielbild
+
+```rmt
+template settings.migration {
+  state settings.tab type string initial "profile"
+
+  portal surface.root root "#settings-root" layer surface
+
+  surface settings.card kind card component x-card {
+    source state settings.tab
+    portal surface.root
+
+    lane visible weight 80 {
+      hydrate settings-card from state settings.tab
+    }
+  }
+}
+```
+
+Die JSON-Beispiele in den folgenden Schritten sind bewusst als Legacy Input
+oder Runtime-Registry-Output markiert. Sie zeigen Migrationsevidence, nicht die
+neue Schreibform.
 
 ## Migrationsmatrix
 
@@ -41,7 +72,7 @@ Neue Dokumente sollen diese Quellen nutzen:
 | manuelle Scheduler-/State-Bruecke | durch `createRmtStateSchedulerDiagnosticsBridge` ersetzen |
 | nicht-XTend Host | eigenen Adapter wie `vanilla.component` deklarieren |
 
-## Schritt 1: Adapter explizit machen
+## Schritt 1: Adapter im Registry-Output explizit machen
 
 Alte Demo-Metadaten enthalten oft implizites Wissen wie "diese Route nutzt XRouter" oder "diese Component ist XTend". Der erste Migrationsschritt ist ein expliziter Adapter-Record.
 
@@ -57,9 +88,9 @@ Alte Demo-Metadaten enthalten oft implizites Wissen wie "diese Route nutzt XRout
 
 `kernelVisible: false` ist fuer host-spezifische Adapterdaten Pflicht. Es bedeutet: Der Kernel darf den Record validieren und indizieren, aber keine XTend-Laufzeit importieren.
 
-## Schritt 2: Components aus Metadaten heben
+## Schritt 2: Components aus Legacy-Metadaten heben
 
-Vorher:
+Vorher: Legacy `manifest.metadata`
 
 ```json
 {
@@ -76,7 +107,7 @@ Vorher:
 }
 ```
 
-Nachher:
+Nachher: Compatibility-/Registry-Output
 
 ```json
 {
@@ -94,9 +125,9 @@ Nachher:
 
 Damit kann `createRmtFormat().createRuntimeRegistries(...)` die Component ueber `componentRegistry.byAdapter["xtend.component"]` bereitstellen.
 
-## Schritt 3: Routes aus Metadaten heben
+## Schritt 3: Routes aus Legacy-Metadaten heben
 
-Vorher:
+Vorher: Legacy `manifest.metadata`
 
 ```json
 {
@@ -113,7 +144,7 @@ Vorher:
 }
 ```
 
-Nachher:
+Nachher: Compatibility-/Registry-Output
 
 ```json
 {
@@ -181,10 +212,10 @@ Wenn Speziallogik weiterhin notwendig ist, gehoert sie in einen Adapter oder in
 
 `xtendrmt/xtendrmt-bestcase-demo.rmt` ist die produktive Authoring-Referenz fuer RMT vNext:
 
-- die `.rmt` Datei nutzt `template`, `surface`, `lane`, Lifecycle-Operationen, Slots und Event-Actions statt JSON
+- die `.rmt` Datei nutzt `template`, `surface`, `lane`, Lifecycle-Operationen, Slots, Event-Actions, State, Selectors, Actions, DataSources, Portals, Overlays, Resources und Remote Surfaces statt JSON
 - `xtendrmt/xtendrmt-bestcase-demo.core.json` ist der byte-stabile vNext-Core-Output
-- die Browser-Demo projiziert vNext-Core zur Laufzeit auf `adapters`, `components`, `routes` und `schedules`
-- `createRmtXRouterAdapter`, `createRmtXtendComponentAdapter` und `createRmtStateSchedulerDiagnosticsBridge` bleiben die produktiven Adapterpfade
+- die Browser-Demo projiziert vNext-Core zur Laufzeit auf `adapters`, `components`, `routes`, `schedules`, Component Capability Registry, Player Contract und Resource Ownership
+- `createRmtXRouterAdapter`, `createRmtXtendComponentAdapter`, `createRmtStateSchedulerDiagnosticsBridge` und `createRmtComponentCapabilityRegistry` bleiben die produktiven Adapterpfade
 - `nativeDemoMigration` wird in der Runtime-Projektion als Handoff-Metadatum erhalten
 
 `tests/browser/fixtures/rmt-xrouter-xtend-smoke.html` ist die browsernahe Regression fuer den migrierten Pfad. Sie prueft zusaetzlich `vanilla.component`, damit der Zielzustand framework-agnostisch bleibt.

package/docs/xtendrmt-native-authoring.md

@@ -1,6 +1,6 @@
 # XTendRMT Native Authoring Guide
 
-- Status: produktiv nach Epic 05 Abschluss
+- Status: produktiv nach Epic 05 Abschluss, vNext-first aktualisiert
 - Contract: `xtend.rmt.native-authoring-guide.v1`
 - Mindestgates:
   - `node scripts/run_xtend_tests.js rmt-compatibility --json`
@@ -9,221 +9,193 @@
 
 ## Zweck
 
-Dieser Guide beschreibt das produktive Authoring-Modell fuer native `.rmt` Dokumente mit XTend UI und XRouter. Ziel ist, dass Menschen und AI-Agenten native RMT Routes, XTend Components, Adapter und Schedules schreiben koennen, ohne XTend oder XRouter in den RMT Kernel einzubetten.
+Dieser Guide beschreibt das produktive Authoring-Modell fuer native `.rmt`
+Dokumente mit XTend UI und XRouter. Der empfohlene Weg fuer neue Apps ist RMT
+vNext: App Shell, Surfaces, Routes, State, Events, Hydration und Fabric-Lanes
+stehen in einer lesbaren RMT-Quelle. Legacy- und App-DSL-JSON bleiben
+Compatibility Layer, Runtime Registry und Compiler-Target, aber nicht der
+normale Autorenpfad.
 
-`.rmt` ist der kanonische Dateityp. Server sollten ihn als `application/vnd.xtendrmt.rmt+json` oder kompatibel als Text ausliefern; der Runtime-Loader liest RMT-Dokumente als Text und parst sie ueber `createRmtFormat().parseDocument(...)`. JSON-Endungen bleiben nur fuer Edge-Case-Hosts ohne native MIME-Unterstuetzung vorgesehen.
+`.rmt` ist der kanonische Dateityp. Server sollten ihn als
+`application/vnd.xtendrmt.rmt+json` oder kompatibel als Text ausliefern; der
+Runtime-Loader liest RMT-Dokumente als Text und parst sie ueber
+`createRmtFormat().parseDocument(...)`. JSON-Endungen bleiben nur fuer
+Edge-Case-Hosts ohne native MIME-Unterstuetzung vorgesehen.
 
-Fuer einen kompakten Produktueberblick siehe [XTendRMT Developer Overview](./xtendrmt-overview.md). Die referenzartige DSL-Beschreibung liegt in [XTendRMT App-DSL Reference](./xtendrmt-app-dsl.md); Runtime-Factories und Bridge-Verkabelung liegen in [XTendRMT Runtime Bridge](./xtendrmt-runtime-bridge.md).
+Fuer einen kompakten Produktueberblick siehe [XTendRMT Developer
+Overview](./xtendrmt-overview.md). Die referenzartige DSL-Beschreibung liegt in
+[XTendRMT App-DSL Reference](./xtendrmt-app-dsl.md); Runtime-Factories und
+Bridge-Verkabelung liegen in [XTendRMT Runtime Bridge](./xtendrmt-runtime-bridge.md).
 
 Die Produktgrenze bleibt:
 
-- XTend UI ist das UI-Builder- und Web-Component-Produkt
-- XTendRMT ist Scheduler, Runtime Kernel und Templating Engine
-- XRouter ist der erste produktive Router Adapter
-- XTend Components sind First-Class RMT Components ueber `xtend.component`
-- nicht-XTend Hosts bleiben ueber eigene Adapter gleichberechtigt
+- XTend UI ist das UI-Builder- und Web-Component-Produkt.
+- XTendRMT ist Scheduler, Runtime Kernel und Templating Engine.
+- XRouter ist der erste produktive Router Adapter.
+- XTend Components sind First-Class RMT Components ueber `xtend.component`.
+- Nicht-XTend Hosts bleiben ueber eigene Adapter gleichberechtigt.
+- Der RMT Kernel importiert keine XTend-, XRouter-, DOM- oder Browser-Typen.
 
-Ab `WP-E13-09` ist [RMT Production Readiness](./rmt-production-readiness.md) der RC1-Schnitt fuer diesen Pfad. Der Contract `xtend.epic13.rmt-production-readiness.v1` wird lokal ueber `node scripts/run_xtend_tests.js epic13-rmt-production-readiness --json` geprueft und buendelt die bestehenden RMT-, Component-, Fabric- und Telemetry-Gates.
+Ab `WP-E13-09` ist [RMT Production Readiness](./rmt-production-readiness.md)
+der RC1-Schnitt fuer diesen Pfad. Der Contract
+`xtend.epic13.rmt-production-readiness.v1` wird lokal ueber
+`node scripts/run_xtend_tests.js epic13-rmt-production-readiness --json`
+geprueft und buendelt die bestehenden RMT-, Component-, Fabric- und
+Telemetry-Gates.
 
 Ab Epic 14 ist der native Authoring-Pfad auch toolgestuetzt:
 
-- [RMT Linter und AI-Agent Repair Report](./rmt-linter.md) beschreibt `xt rmt lint`, JSON-Reports, `--fail-on` und `--agent`.
-- [RMT Language Server und Editor Setup](./rmt-language-server.md) beschreibt LSP, Snippets und Editor-Anbindung fuer VS Code, JetBrains, Neovim und Helix.
-- `node scripts/run_xtend_tests.js rmt-language-regression --json` prueft valide, defekte, Legacy- und groessere RMT-Dokumente ueber Parser, Linter, CLI, LSP und Agent-Report hinweg.
-
-## Minimaler Dokumentaufbau
-
-Neue App-DSL-Dokumente nutzen native Top-Level-Domains:
-
-```json
-{
-  "kind": "rmt_document",
-  "version": "1.0",
-  "documentId": "app.shell",
-  "namespace": "app",
-  "adapters": [],
-  "components": [],
-  "routes": [],
-  "schedules": [],
-  "surfaces": [],
-  "templates": []
-}
-```
+- [RMT Linter und AI-Agent Repair Report](./rmt-linter.md) beschreibt
+  `xt rmt lint`, JSON-Reports, `--fail-on` und `--agent`.
+- [RMT Language Server und Editor Setup](./rmt-language-server.md) beschreibt
+  LSP, Snippets und Editor-Anbindung fuer VS Code, JetBrains, Neovim und Helix.
+- `node scripts/run_xtend_tests.js rmt-language-regression --json` prueft
+  valide, defekte, Legacy- und groessere RMT-Dokumente ueber Parser, Linter,
+  CLI, LSP und Agent-Report hinweg.
 
-Bestehende Template-only-Dokumente bleiben gueltig. Neue Routing- und Component-Arbeit soll jedoch nicht mehr in `manifest.metadata` versteckt werden.
+## Minimaler vNext-Aufbau
 
-## Adapter
+Neue App-Shells starten mit einer vNext-Quelle:
 
-Adapter beschreiben Host-Faehigkeiten. Sie sind Daten im RMT Dokument, keine Kernel-Imports.
+```rmt
+template settings.app {
+  state settings.tab type string initial "profile"
 
-```json
-{
-  "id": "xtend.xrouter",
-  "kind": "router_adapter",
-  "runtimeSurface": ["esm", "browser_classic"],
-  "providedCapabilities": ["routes", "navigation", "params", "query", "scheduleRefs"],
-  "kernelVisible": false
-}
-```
+  selector settings.view from state settings.tab {
+    output SettingsView
+  }
 
-Stabile Adapter-IDs fuer den aktuellen Produktpfad:
-
-- `xtend.xrouter` fuer native XRouter Routes
-- `xtend.component` fuer XTend Custom Elements
-- `xtend.surface` fuer native Surface Records als WindowManager-, SidePanel- und Overlay-Handoff
-- `rmt.state-scheduler-diagnostics` fuer Adapter Results, Scheduler Endpoints und Diagnostics
-- `vanilla.component` als Beispiel fuer einen nicht-XTend Component Host
-
-## Components
-
-Eine Component beschreibt das fachliche Host-Element. XTend-spezifische Arbeit bleibt Adapteraufgabe.
-
-```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"
+  action settings.save {
+    input tab string
+    reduce state.settings.tab = input.tab
+    emit settings.saved with action settings.save
   }
-}
-```
 
-Authoring-Regeln:
-
-- `id` ist stabil und route-freundlich.
-- `adapter` referenziert einen Record aus `adapters`.
-- `tag` ist bei Custom Elements erforderlich.
-- `props`, `attributes` und `slots` bleiben explizit.
-- `schedule` referenziert eine Policy aus `schedules`.
-- Manifest Lookup, Custom-Element-Registration, DOM-Erzeugung und Hydration gehoeren zu `createRmtXtendComponentAdapter`.
-
-## Routes
-
-Eine Route beschreibt Navigation, nicht DOM-Aufbau.
-
-```json
-{
-  "id": "settings",
-  "path": "/settings",
-  "router": "xtend.xrouter",
-  "component": "settings.card",
-  "template": "settings.shell",
-  "schedule": "route.visible.render",
-  "query": {
-    "tab": "profile"
+  portal surface.root root "#app-root" layer surface
+
+  surface settings.card kind page component x-card {
+    source selector settings.view
+    portal surface.root
+
+    lane visible weight 80 {
+      mount x-card
+      hydrate settings-card from selector settings.view
+    }
+
+    on submit target settings-form -> action settings.save {
+      payload tab from target.dataset.tab
+    }
   }
 }
 ```
 
-Authoring-Regeln:
-
-- `router` referenziert den Router Adapter.
-- `component` referenziert einen nativen Component Record.
-- `template` bleibt optional, aber empfohlen fuer renderbare Shells.
-- `schedule` steuert Route-Aktivierung ueber eine zentrale Policy.
-- Parameter, Query und Metadata bleiben generisch.
-- XRouter-Mapping, `registerRoutes` und Navigation gehoeren zu `createRmtXRouterAdapter`.
-
-## Schedules
-
-Schedules sind zentrale Policies. Routes und Components referenzieren sie nur.
-
-```json
-{
-  "id": "component.idle.hydrate",
-  "endpointName": "xtendrmt.component.hydrate",
-  "scope": "app.component.hydrate",
-  "lane": "idle",
-  "priority": 40,
-  "deadlineMs": 420,
-  "preferIdle": true,
-  "budgetClass": "background"
-}
-```
+Der Compiler erzeugt daraus Core- und Kernel-Records fuer `adapters`,
+`components`, `routes`, `schedules`, `surfaces` und `templates`. Diese Records
+sind Runtime-Registry und Mirror; App-Autoren arbeiten in vNext.
+
+## Adapter und Host-Grenze
+
+Adapter beschreiben Host-Faehigkeiten. Sie sind Daten im RMT Dokument, keine
+Kernel-Imports. Der aktuelle Produktpfad kennt diese stabilen Adapter-IDs:
+
+- `xtend.xrouter` fuer native XRouter Routes.
+- `xtend.component` fuer XTend Custom Elements.
+- `xtend.surface` fuer SurfaceManager-, SidePanel- und Overlay-Handoffs.
+- `rmt.state-scheduler-diagnostics` fuer Adapter Results, Scheduler Endpoints
+  und Diagnostics.
+- `vanilla.component` als Beispiel fuer einen nicht-XTend Component Host.
 
-Erprobte Policies aus Demo und Browser-Smoke:
+`kernelVisible: false` bleibt fuer host-spezifische Adapterdaten der Normalfall.
+Der Kernel darf Records normalisieren, indizieren und schedulen, aber keine
+Host-Runtime laden.
 
-- `route.visible.render` -> `xtendrmt.route.render`
-- `component.visible.mount` -> `xtendrmt.component.mount`
-- `component.idle.hydrate` -> `xtendrmt.component.hydrate`
-- `vanilla.visible.mount` -> `xtendrmt.vanilla.mount`
+## Components, Routes und Schedules in vNext
 
-Die Ausfuehrung und Spiegelung von Scheduler-Ergebnissen gehoert zu `createRmtStateSchedulerDiagnosticsBridge`.
+Components werden ueber `surface ... component ...` sichtbar. Route- und
+Schedule-Informationen bleiben in der RMT-Quelle deklarativ und werden vom Host
+ueber Adapter ausgefuehrt:
 
-## Surfaces
+```rmt
+template settings.routes {
+  portal surface.root root "#app-root" layer surface
 
-Ab `WP-SM-08` koennen komplexe App-Shell-Oberflaechen native `surfaces` Records fuehren:
+  surface settings.page kind page component x-section {
+    portal surface.root
 
-```json
-{
-  "id": "surface.inspector",
-  "schema": "xtend.surface.record.v1",
-  "type": "window",
-  "adapter": "xtend.surface",
-  "manager": "workbench.manager",
-  "component": "workbench.inspector",
-  "route": "workbench",
-  "schedule": "surface.user-blocking.open",
-  "stateKey": "xtend.surface.inspector.state"
+    lane visible weight 80 {
+      hydrate settings-shell from endpoint xtendrmt.route.render
+      hydrate settings-form from endpoint xtendrmt.component.hydrate
+    }
+
+    lane idle weight 20 {
+      hydrate settings-help from endpoint xtendrmt.component.hydrate
+    }
+  }
 }
 ```
 
-Authoring-Regeln:
-
-- `manager` und `component` referenzieren native Component Records.
-- `route` und `schedule` binden Surface-Sichtbarkeit an App- und Scheduler-Kontext.
-- `components[*].metadata.surface` bleibt als Migrationsquelle gueltig.
-- `xtend.surface` ist in `WP-SM-08` ein Adapter-Handoff, keine produktive Kernel-Runtime.
-- Details liegen in [SurfaceManager Native RMT Surfaces](./surface-manager-native-rmt-surfaces.md).
-- Der abgeschlossene Surface-Authoring-Pfad liegt in [SurfaceManager Authoring Guide](./surface-manager-authoring-guide.md) (`docs/surface-manager-authoring-guide.md`) und beschreibt `component-metadata-mvp`, `dual-record-handoff` und `native-surfaces-preferred`.
-
-## Templates
-
-Templates bleiben Teil von RMT. Fuer XTend UI sollen sie Host-Daten referenzieren statt versteckte Component-Logik zu enthalten.
-
-```json
-{
-  "id": "settings.shell",
-  "mode": "html_fragment",
-  "markup": "<x-card></x-card>",
-  "security": {
-    "markupClass": "htmlFragment",
-    "trustBoundary": "xtend.security.sanitizing-boundary.v1",
-    "sink": "trustedDomBoundary"
-  },
-  "hydration": {
-    "mode": "runtime_render",
-    "metadata": {
-      "endpointHint": "xtendrmt.component.hydrate"
+Der Normalizer macht daraus Runtime-Registry-Eintraege, die Adapter ueber
+`componentRegistry.byAdapter["xtend.component"]`, `componentRegistry.byTag[...]`
+und Route-/Schedule-Indizes konsumieren. XRouter-Mapping, `registerRoutes`,
+Custom-Element-Registration, DOM-Erzeugung und Hydration bleiben Host-Aufgabe.
+
+## Surfaces und Templates
+
+Komplexe App-Shells werden in vNext als Surfaces und Portals beschrieben:
+
+```rmt
+template workbench.app {
+  state workbench.selection type object initial null
+
+  portal surface.root root "#workbench-root" layer surface
+
+  surface workbench.manager kind workspace component x-surface-manager {
+    portal surface.root
+
+    lane visible weight 90 {
+      hydrate surface-manager from endpoint xtendrmt.component.mount
+    }
+  }
+
+  surface workbench.inspector kind window component x-surface-window {
+    source state workbench.selection
+    portal surface.root
+
+    lane user-blocking weight 95 {
+      hydrate inspector-window from state workbench.selection
     }
   }
 }
 ```
 
-Wenn eine Component eine Route vollstaendig abdeckt, bleibt `template` optional. Wenn Slots oder Shell-Markup benoetigt werden, sollte der Template Record stabil referenziert werden.
+Das Lowering kann daraus weiterhin `dom_descriptor` Template Records und
+native `surfaces` Records erzeugen. `html_fragment` bleibt kompatibel, ist aber
+DOM-untrusted und braucht `xtend.security.sanitizing-boundary.v1`. Der Kernel
+sanitized kein HTML; Host Adapter besitzen den Trusted-DOM-Sink. Siehe
+[Trusted DOM und Sanitizing](./trusted-dom-sanitizing.md).
 
-Security-Regel ab `ER-WP-29`: `dom_descriptor` ist der bevorzugte Modus fuer neue Templates. `html_fragment` bleibt moeglich, ist aber DOM-untrusted und braucht `xtend.security.sanitizing-boundary.v1`. Der RMT Kernel sanitized kein HTML; Host Adapter besitzen den Trusted-DOM-Sink. Siehe [Trusted DOM und Sanitizing](./trusted-dom-sanitizing.md).
+Der abgeschlossene Surface-Authoring-Pfad liegt in [SurfaceManager Authoring
+Guide](./surface-manager-authoring-guide.md) (`docs/surface-manager-authoring-guide.md`).
 
 ## Runtime-Verkabelung
 
-Der produktive Browser-/ESM-Pfad besteht aus vier Schritten:
+Der produktive Browser-/ESM-Pfad bleibt stabil:
 
 1. `createRmtFormat().normalizeDocument(document)`
 2. `createRmtFormat().createRuntimeRegistries(normalizedDocument)`
 3. `createRmtXRouterAdapter(...).registerRoutes(registry)`
-4. `createRmtXtendComponentAdapter(...).mountComponent(...)` und `hydrateComponent(...)`
+4. `createRmtXtendComponentAdapter(...).mountComponent(...)` und
+   `hydrateComponent(...)`
 
-Adapter Results koennen anschliessend ueber `createRmtStateSchedulerDiagnosticsBridge(...).recordAdapterResult(...)` an `xstate`, Scheduler und Diagnostics Hub gespiegelt werden.
+Adapter Results koennen anschliessend ueber
+`createRmtStateSchedulerDiagnosticsBridge(...).recordAdapterResult(...)` an
+`xstate`, Scheduler und Diagnostics Hub gespiegelt werden.
+
+Die stabilen Factory-Namen fuer Adapterdokumentation und Tooling bleiben
+`createRmtXRouterAdapter`, `createRmtXtendComponentAdapter` und
+`createRmtStateSchedulerDiagnosticsBridge`. Die Standard-Policies bleiben
+`route.visible.render` fuer sichtbares Routing und `component.idle.hydrate`
+fuer nachgelagerte Component-Hydration.
 
 ## Authoring Tooling
 
@@ -241,26 +213,19 @@ Die IDE-Anbindung startet denselben Sprachkern ueber:
 node tools/rmt-language-server/server.js
 ```
 
-Wichtig: Linter, LSP, Code Actions und Agent Report teilen sich den gleichen Diagnosekern. Editor-Packages und AI-Agenten sollen keine eigenen RMT-Regeln implementieren.
-
-Neue App-Shells koennen ueber den Snippet-Prefix `rmt-app` gestartet werden. Weitere Prefixes sind `rmt-component`, `rmt-route`, `rmt-schedule`, `rmt-template-dom` und `rmt-template-html`.
+Wichtig: Linter, LSP, Code Actions und Agent Report teilen sich den gleichen
+Diagnosekern. Editor-Packages und AI-Agenten sollen keine eigenen RMT-Regeln
+implementieren.
 
-## Epic-10-App-Authoring
-
-Fuer vollstaendige XTend-Apps gilt ab Epic 10 der Contract `xtend.rmt.first-class-app-authoring.v1`. Er erweitert den nativen Authoring-Pfad von einzelnen Routes und Components auf komplette Shell-first Apps:
-
-- App Shell als `dom_descriptor`
-- `xtend.component`, `xtend.xrouter` und `rmt.state-scheduler-diagnostics` als Pflichtadapter
-- Component Records mit Props, Attributes, Slots, Events, Fabric- und A11y-Metadaten
-- Route Records mit Component-, Template- und Schedule-Referenzen
-- zentrale Schedule Policies fuer Shell, Route Render, Component Mount, Hydration, User Input, Lazy Media und Diagnostics
-- Kernel Boundary `no-rmt-kernel-import-of-xtend-types`
-
-Das Referenz-Fixture liegt in `tests/fixtures/rmt-first-class-xtend-app.rmt`; der lokale Gate ist `node scripts/run_xtend_tests.js rmt-first-class-app --json`.
+Neue App-Shells koennen ueber den Snippet-Prefix `rmt-app` gestartet werden.
+Weitere Prefixes sind `rmt-component`, `rmt-route`, `rmt-schedule`,
+`rmt-template-dom`, `rmt-template-html` und `rmt-vnext-primitive-shell`.
 
 ## Fabric/Lane-Ingestion im Component Adapter
 
-Der XTend Component Adapter wertet ab `xtend.component.fabric-lane-ingestion.v2` Fabric- und Lane-Hints direkt beim Mounting und bei Hydration aus. Die Precedence ist:
+Der XTend Component Adapter wertet ab `xtend.component.fabric-lane-ingestion.v2`
+Fabric- und Lane-Hints direkt beim Mounting und bei Hydration aus. Die
+Precedence bleibt:
 
 1. `rmt.schedule-record`
 2. `rmt.component-metadata`
@@ -268,7 +233,12 @@ Der XTend Component Adapter wertet ab `xtend.component.fabric-lane-ingestion.v2`
 4. `component.static-contract`
 5. `scaffold.blueprint-default`
 
-Der Adapter stellt dafuer `resolveFabricContext(componentRef, operation, model, options)` bereit. `mountComponent(...)` und `hydrateComponent(...)` spiegeln den Context in `result.metadata.fabric` und setzen DOM-Attribute fuer Lane, RMT-Lane, Fiber, Source und Endpoint. Konflikte erzeugen `rmt.xtend.component.fabric_lane.conflict`.
+In vNext kommt die bevorzugte Quelle aus `lane`- und Lifecycle-Klauseln. Der
+Adapter stellt dafuer `resolveFabricContext(componentRef, operation, model,
+options)` bereit. `mountComponent(...)` und `hydrateComponent(...)` spiegeln
+den Context in `result.metadata.fabric` und setzen DOM-Attribute fuer Lane,
+RMT-Lane, Fiber, Source und Endpoint. Konflikte erzeugen
+`rmt.xtend.component.fabric_lane.conflict`.
 
 Der lokale Gate ist:
 
@@ -278,38 +248,64 @@ node scripts/run_xtend_tests.js rmt-component-fabric-ingestion --json
 
 ## Component Lifecycle Telemetry
 
-Ab `xtend.component.lifecycle-telemetry.v1` erzeugt derselbe Adapter standardisierte Component Lifecycle Telemetry. `mountComponent(...)` und `hydrateComponent(...)` schreiben `result.metadata.telemetry`; die Event Bridge erzeugt `event` Records; fuer Render, Update, Unmount und Error steht `recordComponentTelemetry(record, options)` bereit.
+Ab `xtend.component.lifecycle-telemetry.v1` erzeugt derselbe Adapter
+standardisierte Component Lifecycle Telemetry. 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 = [];
+adapter.mountComponent(root, 'pages.settings', model, {
+  mapping,
+  telemetryCollector: records
+});
+
+const snapshot = fabric.createTelemetrySnapshot({
+  componentTelemetry: records
+});
+```
 
-Fabric kann diese Records ueber `createTelemetrySnapshot({ componentTelemetry })` unter `snapshot.componentTelemetry` aggregieren. Component-Fehler, Deadline-Ueberschreitungen und explizite `backpressureSignal` Metadata fliessen in die Backpressure-Sektion ein.
+`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`.
 
-```bash
-node scripts/run_xtend_tests.js rmt-component-lifecycle-telemetry --json
-```
+Hosts koennen Fabric Snapshots direkt an die produktive RMT Bridge uebergeben:
 
-Aktuelle Artefakte:
+```js
+bridge.recordTelemetrySnapshot(snapshot, {
+  scheduleRef: "diagnostics.snapshot"
+});
+```
 
-- `xtendrmt/rmt-core.esm.js`
-- `xtendrmt/rmt-runtime.esm.js`
-- `xtendrmt/rmt-runtime.browser.js`
-- `xtendrmt/rmt-core.d.ts`
-- `xtendrmt/rmt.schema.json`
-- `xtendrmt/rmt-manifest.json`
+Die Bridge spiegelt daraus `rmt.telemetry.lastSnapshot` und
+`rmt.backpressure.*` und plant bei Bedarf den Diagnostics-Snapshot-Endpunkt.
 
 ## Multi-Host-Regel
 
-Native RMT Components duerfen nicht implizit XTend bedeuten. Ein nicht-XTend Host nutzt denselben Component-Record-Aufbau mit eigener Adapter-ID:
+Native RMT Components duerfen nicht implizit XTend bedeuten. Ein nicht-XTend
+Host nutzt denselben vNext-Aufbau mit eigener Adapter-ID und eigener
+Host-Ausfuehrung:
+
+```rmt
+template vanilla.app {
+  portal surface.root root "#vanilla-root" layer surface
+
+  surface vanilla.panel kind card component vanilla-panel {
+    portal surface.root
 
-```json
-{
-  "id": "vanilla-panel",
-  "kind": "custom_element",
-  "adapter": "vanilla.component",
-  "tag": "vanilla-panel",
-  "schedule": "vanilla.visible.mount"
+    lane visible weight 60 {
+      hydrate vanilla-panel from endpoint xtendrmt.vanilla.mount
+    }
+  }
 }
 ```
 
-Der Browser-Smoke `tests/browser/fixtures/rmt-xrouter-xtend-smoke.html` prueft genau diesen Pfad. Damit ist Framework-Agnostik nicht nur Architekturziel, sondern Regression.
+Der Browser-Smoke `tests/browser/fixtures/rmt-xrouter-xtend-smoke.html` prueft
+genau diesen Pfad. Damit ist Framework-Agnostik nicht nur Architekturziel,
+sondern Regression.
 
 ## Kernel Boundary
 
@@ -322,16 +318,16 @@ Der RMT Kernel darf nicht importieren oder voraussetzen:
 - `xstate`
 - Browser DOM APIs
 
-Der Kernel darf normalisieren, indizieren, validieren und Schedule Policies beschreiben. Host-Ausfuehrung bleibt Adapterarbeit.
+Der Kernel darf normalisieren, indizieren, validieren und Schedule Policies
+beschreiben. Host-Ausfuehrung bleibt Adapterarbeit.
 
 ## Review-Checkliste
 
 Vor einem neuen nativen `.rmt` Dokument pruefen:
 
-- sind `adapters`, `components`, `routes` und `schedules` Top-Level-Domains?
-- referenzieren Routes nur Component IDs und keine DOM-Details?
-- referenzieren Components nur Adapter IDs und keine Kernel-Sonderfaelle?
-- sind Schedule Policies zentral und wiederverwendbar?
-- bleiben XTend-spezifische Daten `kernelVisible: false`?
+- beschreibt die Quelle App Shell, Surfaces, Lanes und Events in RMT vNext?
+- sind Legacy-/App-DSL-JSON nur noch Compiler-Output, Mirror oder Migration?
+- bleiben XTend-spezifische Daten ausserhalb des Kernels?
+- referenzieren Lifecycle-Operationen stabile Endpoints und Adaptergrenzen?
 - existiert fuer nicht-XTend Hosts ein eigener Adapter statt XTend-Fallback?
 - laufen `rmt-compatibility`, `browser` und `references` Gates?