@ccslabs/xtend 0.1.0-rc.1 → 0.1.2

package/docs/de/xtendrmt-app-dsl.md

@@ -0,0 +1,334 @@
+# XTendRMT App-DSL Reference
+
+- 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. 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.
+
+## Minimales vNext-Dokument
+
+```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
+    }
+  }
+}
+```
+
+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 als Compiler-Output
+
+| Domain | Aufgabe |
+|--------|---------|
+| `adapters` | Host-Faehigkeiten, Runtime Surface, Capability Negotiation |
+| `components` | fachliche Component Records, Host Adapter und Hydration-Hinweise |
+| `routes` | Navigation, Route-Ziele, Query/Params und Schedule References |
+| `schedules` | wiederverwendbare Scheduler Policies |
+| `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 in vNext-
+Source und werden daraus in die Registry projiziert.
+
+## Adapter Records
+
+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.
+
+## Component Records
+
+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.
+
+## Route Records
+
+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 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
+
+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 bleiben:
+
+- `xtendrmt.route.render`
+- `xtendrmt.component.mount`
+- `xtendrmt.component.hydrate`
+- `xtendrmt.vanilla.mount`
+- `xtendrmt.diagnostics.snapshot`
+- `xtendrmt.template.inspect`
+
+## Template Records und Trusted DOM
+
+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
+
+    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:
+
+```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).
+
+## 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.
+
+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.
+
+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 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 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`.
+
+## 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.
+
+```js
+const records = [];
+adapter.mountComponent(root, 'pages.settings', model, {
+  mapping,
+  telemetryCollector: records
+});
+
+const snapshot = fabric.createTelemetrySnapshot({
+  componentTelemetry: records
+});
+```
+
+`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:
+
+```js
+bridge.recordTelemetrySnapshot(snapshot, {
+  scheduleRef: "diagnostics.snapshot"
+});
+```
+
+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);
+const registry = format.createRuntimeRegistries(normalizedDocument, {
+  requiredRoutes: ["settings", "/settings"],
+  requiredComponents: ["settings.card", "x-card"]
+});
+```
+
+## Diagnostics
+
+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
+- `rmt.xrouter.*` fuer Route-Mapping und Navigation
+- `rmt.xtend.component.*` fuer Component-Mapping, Mounting und Hydration
+- `rmt.bridge.*` fuer State-, Scheduler- und Diagnostics-Bridge
+
+## Review-Checkliste
+
+- 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.
+- XTend-spezifische Daten bleiben ausserhalb des Kernels.
+- Nicht-XTend Hosts erhalten eigene Adapter statt XTend-Fallbacks.
+- `node scripts/run_xtend_tests.js rmt-compatibility --json` laeuft.

package/docs/de/xtendrmt-migration-guide.md

@@ -0,0 +1,266 @@
+# XTendRMT Native Migration Guide
+
+- Status: produktiv nach Epic 05 Abschluss
+- Contract: `xtend.rmt.native-migration-guide.v1`
+- Mindestgates:
+  - `node scripts/run_xtend_tests.js rmt-compatibility --json`
+  - `node scripts/run_xtend_tests.js references --json`
+  - `npm test`
+
+## Zweck
+
+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).
+
+## Zielzustand
+
+Neue Dokumente sollen diese Quellen nutzen:
+
+| Bereich | Zielquelle |
+|---------|------------|
+| 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.
+
+## 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
+
+| Ausgangslage | Migration |
+|--------------|-----------|
+| Template-only `.rmt` Dokument | bleibt gueltig; nur bei App-DSL-Bedarf native Domains ergaenzen |
+| `manifest.metadata.routes` | nach `routes` verschieben |
+| `manifest.metadata.components` | nach `components` verschieben |
+| `manifest.metadata.schedules` | nach `schedules` verschieben |
+| XRouter-spezifische Demo-Initialisierung | durch `createRmtXRouterAdapter` ersetzen |
+| XTend-spezifische Demo-Mount-Logik | durch `createRmtXtendComponentAdapter` ersetzen |
+| manuelle Scheduler-/State-Bruecke | durch `createRmtStateSchedulerDiagnosticsBridge` ersetzen |
+| nicht-XTend Host | eigenen Adapter wie `vanilla.component` deklarieren |
+
+## 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.
+
+```json
+{
+  "id": "xtend.component",
+  "kind": "component_adapter",
+  "runtimeSurface": ["esm", "browser_classic"],
+  "providedCapabilities": ["components", "customElements", "hydration", "scheduleRefs"],
+  "kernelVisible": false
+}
+```
+
+`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 Legacy-Metadaten heben
+
+Vorher: Legacy `manifest.metadata`
+
+```json
+{
+  "manifest": {
+    "metadata": {
+      "components": [
+        {
+          "id": "settings.card",
+          "tag": "x-card"
+        }
+      ]
+    }
+  }
+}
+```
+
+Nachher: Compatibility-/Registry-Output
+
+```json
+{
+  "components": [
+    {
+      "id": "settings.card",
+      "kind": "custom_element",
+      "adapter": "xtend.component",
+      "tag": "x-card",
+      "schedule": "component.idle.hydrate"
+    }
+  ]
+}
+```
+
+Damit kann `createRmtFormat().createRuntimeRegistries(...)` die Component ueber `componentRegistry.byAdapter["xtend.component"]` bereitstellen.
+
+## Schritt 3: Routes aus Legacy-Metadaten heben
+
+Vorher: Legacy `manifest.metadata`
+
+```json
+{
+  "manifest": {
+    "metadata": {
+      "routes": [
+        {
+          "path": "/settings",
+          "component": "settings.card"
+        }
+      ]
+    }
+  }
+}
+```
+
+Nachher: Compatibility-/Registry-Output
+
+```json
+{
+  "routes": [
+    {
+      "id": "settings",
+      "path": "/settings",
+      "router": "xtend.xrouter",
+      "component": "settings.card",
+      "template": "settings.shell",
+      "schedule": "route.visible.render"
+    }
+  ]
+}
+```
+
+Damit kann `createRmtXRouterAdapter` die Route ueber `routeRegistry.byRouter["xtend.xrouter"]` mappen und mit `registerRoutes` an XRouter uebergeben.
+
+## Schritt 4: Schedules zentralisieren
+
+Vorher lagen Endpoint-Hints oft in Route-, Component- oder Template-Metadaten. Nach der Migration steht die Policy zentral in `schedules`.
+
+```json
+{
+  "schedules": [
+    {
+      "id": "route.visible.render",
+      "endpointName": "xtendrmt.route.render",
+      "lane": "visible",
+      "priority": 80,
+      "preferIdle": false
+    },
+    {
+      "id": "component.idle.hydrate",
+      "endpointName": "xtendrmt.component.hydrate",
+      "lane": "idle",
+      "priority": 40,
+      "preferIdle": true
+    }
+  ]
+}
+```
+
+Routes und Components referenzieren nur noch `schedule`. Die Ausfuehrung laeuft ueber `createRmtStateSchedulerDiagnosticsBridge`.
+
+## Schritt 5: Demo-Brueckenlogik entfernen
+
+Dauerhafte Demo-Brueckenlogik soll nicht mehr neue Produktlogik tragen. Ein migrierter Host-Start nutzt die produktiven Factories:
+
+```js
+const format = createRmtFormat();
+const normalizedDocument = format.normalizeDocument(document);
+const registry = format.createRuntimeRegistries(normalizedDocument);
+
+const routes = createRmtXRouterAdapter({ routerElement }).registerRoutes(registry);
+const components = createRmtXtendComponentAdapter({ document, manifest }).mapComponents(registry);
+const bridge = createRmtStateSchedulerDiagnosticsBridge({ schedules: normalizedDocument.schedules });
+
+bridge.recordAdapterResult(routes, { scheduleRef: 'route.visible.render' });
+```
+
+Wenn Speziallogik weiterhin notwendig ist, gehoert sie in einen Adapter oder in upstream RMT Source, nicht in eine Demo-Datei.
+
+## Bestcase-Referenz
+
+`xtendrmt/xtendrmt-bestcase-demo.rmt` ist die produktive Authoring-Referenz fuer RMT vNext:
+
+- 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`, `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.
+
+Fuer die offizielle Docs-App gilt: Parsedown bleibt der aktive Markdown-Parser, aber die sichtbare App Shell wird Shell-first aus `docs.app.shell` im RMT-Dokument gerendert. Der RMT-Scheduling- und Shell-Pfad fuer Parsedown, Search und future-ready Media-Slots ist ueber [XTendRMT Parsedown Scheduling Pilot](./xtendrmt-parsedown-scheduling.md) dokumentiert und bleibt host-neutral.
+
+## SurfaceManager Migration
+
+Ab `WP-SM-09` besitzt der SurfaceManager einen eigenen Migrationsguide: [SurfaceManager Migration Guide](./surface-manager-migration-guide.md) (`docs/surface-manager-migration-guide.md`).
+
+Der Surface-Pfad ist additiv:
+
+- bestehende `components[*].metadata.surface` Records bleiben gueltig
+- native `surfaces[*]` Records werden fuer komplexe App Shells bevorzugt
+- Dual Records halten `id`, `type`, `manager`, `component`, `route`, `schedule` und `stateKey` synchron
+- `xtend.surface` bleibt `surface_adapter` Handoff, bis eine produktive Adapter Runtime implementiert wird
+
+## Was nicht migriert werden muss
+
+Nicht jede Datei braucht sofort native Domains.
+
+Nicht migrieren:
+
+- reine Template-only-Dokumente ohne Routing- oder Component-Bedarf
+- historische Demos mit `manual-legacy` Status
+- Metadaten, die nur Produktbeschreibung oder Handoff-Notizen enthalten
+- React-, Vue-, Vanilla- oder Custom-Hosts, die RMT noch nicht als Scheduler nutzen
+
+Migrieren:
+
+- neue `.rmt` App-DSL-Dokumente
+- Demo-Code mit operativer Route-/Component-Bridge
+- produktive Route- oder Component-Flows
+- Host-Pfade, die Scheduler Endpoint Policies brauchen
+
+## Review-Checkliste
+
+Vor Abschluss einer Migration pruefen:
+
+- `manifest.metadata.routes -> routes` wurde umgesetzt
+- `manifest.metadata.components -> components` wurde umgesetzt
+- `manifest.metadata.schedules -> schedules` wurde umgesetzt
+- `xtend.xrouter` und `xtend.component` sind Adapter-Records, nicht Kernelwissen
+- `route.visible.render` und `component.idle.hydrate` sind zentrale Policies
+- `createRmtXRouterAdapter`, `createRmtXtendComponentAdapter` und `createRmtStateSchedulerDiagnosticsBridge` ersetzen Demo-Brueckenlogik
+- Template-only-Kompatibilitaet bleibt erhalten
+- React, Vue, Vanilla JS und Custom Hosts werden nicht zur XTend-Migration gezwungen
+- `node scripts/run_xtend_tests.js rmt-compatibility --json` und `node scripts/run_xtend_tests.js references --json` laufen