@ccslabs/xtend 0.1.0-rc.1

package/docs/xtendrmt-migration-guide.md

@@ -0,0 +1,235 @@
+# 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. 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.
+
+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 | `adapters` |
+| XTend Components | `components` mit `adapter: "xtend.component"` |
+| XRouter Routes | `routes` mit `router: "xtend.xrouter"` |
+| Scheduler Policies | `schedules` |
+| Markup oder Fragmente | `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.
+
+## 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 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 Metadaten heben
+
+Vorher:
+
+```json
+{
+  "manifest": {
+    "metadata": {
+      "components": [
+        {
+          "id": "settings.card",
+          "tag": "x-card"
+        }
+      ]
+    }
+  }
+}
+```
+
+Nachher:
+
+```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 Metadaten heben
+
+Vorher:
+
+```json
+{
+  "manifest": {
+    "metadata": {
+      "routes": [
+        {
+          "path": "/settings",
+          "component": "settings.card"
+        }
+      ]
+    }
+  }
+}
+```
+
+Nachher:
+
+```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 und Event-Actions 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
+- `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

package/docs/xtendrmt-native-authoring.md

@@ -0,0 +1,337 @@
+# XTendRMT Native Authoring Guide
+
+- Status: produktiv nach Epic 05 Abschluss
+- Contract: `xtend.rmt.native-authoring-guide.v1`
+- Mindestgates:
+  - `node scripts/run_xtend_tests.js rmt-compatibility --json`
+  - `node scripts/run_xtend_tests.js browser --json`
+  - `node scripts/run_xtend_tests.js references --json`
+
+## 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.
+
+`.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).
+
+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
+
+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": []
+}
+```
+
+Bestehende Template-only-Dokumente bleiben gueltig. Neue Routing- und Component-Arbeit soll jedoch nicht mehr in `manifest.metadata` versteckt werden.
+
+## Adapter
+
+Adapter beschreiben Host-Faehigkeiten. Sie sind Daten im RMT Dokument, keine Kernel-Imports.
+
+```json
+{
+  "id": "xtend.xrouter",
+  "kind": "router_adapter",
+  "runtimeSurface": ["esm", "browser_classic"],
+  "providedCapabilities": ["routes", "navigation", "params", "query", "scheduleRefs"],
+  "kernelVisible": false
+}
+```
+
+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"
+  }
+}
+```
+
+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"
+  }
+}
+```
+
+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"
+}
+```
+
+Erprobte Policies aus Demo und Browser-Smoke:
+
+- `route.visible.render` -> `xtendrmt.route.render`
+- `component.visible.mount` -> `xtendrmt.component.mount`
+- `component.idle.hydrate` -> `xtendrmt.component.hydrate`
+- `vanilla.visible.mount` -> `xtendrmt.vanilla.mount`
+
+Die Ausfuehrung und Spiegelung von Scheduler-Ergebnissen gehoert zu `createRmtStateSchedulerDiagnosticsBridge`.
+
+## Surfaces
+
+Ab `WP-SM-08` koennen komplexe App-Shell-Oberflaechen native `surfaces` Records fuehren:
+
+```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"
+}
+```
+
+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"
+    }
+  }
+}
+```
+
+Wenn eine Component eine Route vollstaendig abdeckt, bleibt `template` optional. Wenn Slots oder Shell-Markup benoetigt werden, sollte der Template Record stabil referenziert werden.
+
+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).
+
+## Runtime-Verkabelung
+
+Der produktive Browser-/ESM-Pfad besteht aus vier Schritten:
+
+1. `createRmtFormat().normalizeDocument(document)`
+2. `createRmtFormat().createRuntimeRegistries(normalizedDocument)`
+3. `createRmtXRouterAdapter(...).registerRoutes(registry)`
+4. `createRmtXtendComponentAdapter(...).mountComponent(...)` und `hydrateComponent(...)`
+
+Adapter Results koennen anschliessend ueber `createRmtStateSchedulerDiagnosticsBridge(...).recordAdapterResult(...)` an `xstate`, Scheduler und Diagnostics Hub gespiegelt werden.
+
+## Authoring Tooling
+
+Empfohlener lokaler Ablauf:
+
+```bash
+xt rmt lint app.rmt
+xt rmt lint app.rmt --json
+xt rmt lint app.rmt --agent
+```
+
+Die IDE-Anbindung startet denselben Sprachkern ueber:
+
+```bash
+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`.
+
+## 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`.
+
+## 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:
+
+1. `rmt.schedule-record`
+2. `rmt.component-metadata`
+3. `fabric.runtime-override`
+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`.
+
+Der lokale Gate ist:
+
+```bash
+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.
+
+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.
+
+```bash
+node scripts/run_xtend_tests.js rmt-component-lifecycle-telemetry --json
+```
+
+Aktuelle Artefakte:
+
+- `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`
+
+## Multi-Host-Regel
+
+Native RMT Components duerfen nicht implizit XTend bedeuten. Ein nicht-XTend Host nutzt denselben Component-Record-Aufbau mit eigener Adapter-ID:
+
+```json
+{
+  "id": "vanilla-panel",
+  "kind": "custom_element",
+  "adapter": "vanilla.component",
+  "tag": "vanilla-panel",
+  "schedule": "vanilla.visible.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.
+
+## Kernel Boundary
+
+Der RMT Kernel darf nicht importieren oder voraussetzen:
+
+- `x-router`
+- konkrete `x-*` Komponenten
+- XTend Manifest-Strukturen
+- `window.XTend`
+- `xstate`
+- Browser DOM APIs
+
+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`?
+- existiert fuer nicht-XTend Hosts ein eigener Adapter statt XTend-Fallback?
+- laufen `rmt-compatibility`, `browser` und `references` Gates?

package/docs/xtendrmt-overview.md

@@ -0,0 +1,89 @@
+# XTendRMT Developer Overview
+
+- Status: aktuell nach Epic 05 Abschluss
+- Contract: `xtend.docs.xtendrmt-overview.v1`
+- Produktversion: `XTendRMT 0.2.0`
+- Kernartefakte:
+  - `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`
+
+## Zielbild
+
+XTendRMT verbindet zwei Produkte, ohne ihre Grenzen zu verwischen:
+
+| Produkt | Rolle |
+|---------|-------|
+| XTend UI | UI Builder und Web-Component-System |
+| XTendRMT | Scheduler, Runtime Kernel und Templating Engine |
+
+XTend ist First-Class Host fuer RMT, aber keine Pflichtabhaengigkeit des RMT Kernels. RMT kann XTend Components, XRouter Routes und Scheduler Policies beschreiben und ausfuehren lassen, ohne XTend, XRouter, DOM oder `xstate` in den Kernel einzubetten.
+
+## Aktueller Implementierungsstand
+
+Epic 05 ist abgeschlossen. Der produktive Pfad besteht aus:
+
+- nativen `.rmt` Top-Level-Domains: `adapters`, `components`, `routes`, `schedules`, `templates`
+- Runtime Registry fuer Route- und Component-Indizes
+- XRouter Adapter `createRmtXRouterAdapter`
+- XTend Component Adapter `createRmtXtendComponentAdapter`
+- State-/Scheduler-/Diagnostics Bridge `createRmtStateSchedulerDiagnosticsBridge`
+- ESM- und Browser-Bundles mit Artefakt-Paritaetsgate
+- Browser-Smoke fuer RMT/XRouter/XTend/Vanilla
+
+Die wichtigsten Regressionen liegen in:
+
+- `tests/fixtures/rmt-app-dsl.native-bridge.rmt`
+- `tests/browser/fixtures/rmt-xrouter-xtend-smoke.html`
+- `xtendrmt/xtendrmt-bestcase-demo.rmt`
+- `xtendrmt-bestcase.html`
+
+## Architekturgrenze
+
+RMT darf:
+
+- `.rmt` Dokumente normalisieren
+- DSL-Domains indizieren
+- Adapter Records validieren
+- Scheduler Policies beschreiben
+- Diagnostics und Reference Graphs erzeugen
+
+RMT darf nicht:
+
+- `components/xrouter.js` importieren
+- XTend Components importieren
+- `window.XTend` voraussetzen
+- `xstate` direkt schreiben
+- DOM-Mounting im Kernel ausfuehren
+- React, Vue, Vanilla oder Custom Hosts auf XTend migrieren
+
+Host-Arbeit gehoert in Adapter. Das ist der Kern der First-Class-Citizen-Strategie: XTend bekommt hochwertige Adapter, aber der Kernel bleibt framework-agnostisch.
+
+## Offizielle Entwicklerdokumente
+
+| Thema | Dokument |
+|-------|----------|
+| Native Authoring | [XTendRMT Native Authoring Guide](./xtendrmt-native-authoring.md) |
+| Native App-DSL Referenz | [XTendRMT App-DSL Reference](./xtendrmt-app-dsl.md) |
+| Runtime Bridge und Adapter | [XTendRMT Runtime Bridge](./xtendrmt-runtime-bridge.md) |
+| Migration aus alten Metadatenpfaden | [XTendRMT Native Migration Guide](./xtendrmt-migration-guide.md) |
+| Docs-App / Parsedown Scheduling | [XTendRMT Parsedown Scheduling Pilot](./xtendrmt-parsedown-scheduling.md) |
+
+## Empfohlener lokaler Gate
+
+```bash
+node scripts/run_xtend_tests.js references --json
+node scripts/run_xtend_tests.js rmt-compatibility --json
+node scripts/run_xtend_tests.js browser --json
+node scripts/verify_xtendrmt_artifact_parity.js --json
+npm test
+```
+
+`references` prueft die offizielle Entwicklerdokumentation, `rmt-compatibility` prueft DSL, Adapter, Bridge und Artefakt-Paritaet, `browser` prueft den browsernahen Multi-Host-Pfad.
+
+## Entwicklungsregel
+
+Neue RMT-nahe Arbeit soll zuerst klaeren, ob sie Kernel-, DSL-, Adapter-, Host- oder Dokumentationsverantwortung ist. Wenn XTend-spezifisches Verhalten benoetigt wird, entsteht ein Adapter- oder Host-Contract, kein Kernel-Sonderfall.