@ccslabs/xtend 0.1.0-rc.1 → 0.1.2

package/docs/de/components/xutils.md

@@ -0,0 +1,144 @@
+# xutils - XTend Utility-Modul
+
+## Uebersicht
+
+`x-utils` ist ein Manifest-geführtes Utility-Modul und keine eigene Custom-Element-Oberflaeche. Das Modul exportiert `XUtils` und stellt im Browser zusaetzlich `window.XUtils` bereit. Es sammelt kleine DOM-, Event-, A11y-, Format- und Low-Code-Helfer fuer XTend-Komponenten und Demos.
+
+## Import
+
+```js
+import { XUtils } from './components/xutils.js';
+
+const button = XUtils.create('button', {
+  textContent: 'Speichern'
+});
+```
+
+Im Browser ist nach dem Laden des Moduls verfuegbar:
+
+```js
+window.XUtils.find('[data-action="save"]');
+```
+
+## DOM- und Event-API
+
+| Methode | Beschreibung |
+|---------|--------------|
+| `find(selector, root?)` | gibt das erste passende Element zurueck |
+| `findAll(selector, root?)` | gibt alle passenden Elemente als Array zurueck |
+| `create(tag, props?)` | erzeugt ein Element und weist Properties zu |
+| `on(el, type, handler, opts?)` | registriert einen Listener und gibt eine Cleanup-Funktion zurueck |
+| `delegate(root, selector, type, handler)` | delegiert Events innerhalb eines Containers |
+
+## A11y- und UI-Helfer
+
+| Methode | Beschreibung |
+|---------|--------------|
+| `setAria(el, attrs)` | setzt `aria-*` Attribute aus einem Objekt |
+| `focusTrap(container)` | fokussiert das erste fokussierbare Element im Container |
+| `fadeIn(el, duration?)` | einfache Opacity-Animation |
+| `fadeOut(el, duration?)` | einfache Opacity-Animation |
+| `resolveUiEffects(input?)` | normalisiert opt-in UI-Effekte aus Body-Attribut, Loader-Option oder RMT |
+| `prepareUiEffects(input?)` | bereitet einen opt-in UI-Effekt vor, z.B. Body-Fade |
+| `releaseUiEffects(input?)` | gibt einen vorbereiteten UI-Effekt wieder frei |
+| `isMobile()` | prueft den lokalen Mobile-Breakpoint |
+
+## Format- und Datenhelfer
+
+| Methode | Beschreibung |
+|---------|--------------|
+| `hexToRgb(hex)` | wandelt Hex-Farben in RGB-Werte |
+| `contrastColor(hex)` | liefert Schwarz oder Weiss als Kontrastfarbe |
+| `formatDate(date, locale?)` | formatiert ein Datum |
+| `formatNumber(num, locale?)` | formatiert eine Zahl |
+| `uniqueId(prefix?)` | erzeugt eine einfache Runtime-ID |
+| `deepClone(obj)` | erzeugt eine JSON-basierte Kopie |
+
+## XTemplate Recipes
+
+`XUtils.XTemplate` enthaelt kleine Low-Code-Rezepte fuer einfache DOM-Fragmente:
+
+```js
+const card = XUtils.XTemplate.card({
+  title: 'Status',
+  content: 'Alle Systeme bereit'
+});
+
+const action = XUtils.XTemplate.button({
+  label: 'Aktualisieren',
+  onClick: () => window.location.reload()
+});
+```
+
+Aktuelle Rezepte:
+
+| Recipe | Beschreibung |
+|--------|--------------|
+| `card(opts)` | erzeugt eine einfache Card-Struktur |
+| `button(opts)` | erzeugt einen Button |
+| `modal(opts)` | erzeugt eine einfache Modal-Struktur |
+
+## Contract
+
+- `x-utils` ist als Manifest-Eintrag vorhanden, bleibt aber ein Utility-Modul.
+- Es registriert kein `customElements.define()`.
+- Die Datei `docs/components/xutils.md` ist der kanonische Docs-Slug zum Source-Basename `xutils.js`.
+- Runtime-Tag und Manifest-Key bleiben fuer die Catalog Matrix `x-utils`.
+
+## Utility Boundary Contract
+
+Seit `WP-E12-09` ist `x-utils` als nicht-visuelle Utility-Boundary gatebar:
+
+- Utility Schema: `xtend.utility.module-contract.v1`
+- Import Policy Schema: `xtend.utility.import-policy.v1`
+- Import Policy Result Schema: `xtend.utility.import-policy-result.v1`
+- Boundary Probe Schema: `xtend.utility.boundary-probe.v1`
+- Kernel Boundary: `no-rmt-kernel-import-of-xtend-types`
+
+Die Runtime stellt dafuer drei explizite Contract-APIs bereit:
+
+| Methode | Beschreibung |
+|---------|--------------|
+| `getUtilityContract()` | liefert Kategorien, Exports, Globals und Methoden der Utility-Oberflaeche |
+| `snapshotUtilityContract()` | liefert einen stabilen Boundary-Snapshot fuer Fixtures und Catalog-Gates |
+| `assertLocalImport(specifier)` | prueft, ob ein Import-Specifier lokal und policy-konform ist |
+
+```js
+const local = XUtils.assertLocalImport('/components/xbutton.js');
+const blocked = XUtils.assertLocalImport('https://cdn.ccs-networks.de/xtend/components/xstate.js');
+
+console.log(local.allowed);   // true
+console.log(blocked.allowed); // false
+```
+
+`assertLocalImport()` dispatcht im Browser zusaetzlich `xutils:import-policy-check`. Das Event ist fuer Test-, Fabric- und Security-Harnesses gedacht; der RMT Kernel importiert `x-utils` weiterhin nicht.
+
+## UI Effects Boundary
+
+Seit `xtend.utility.ui-effects.v1` kapselt `x-utils` opt-in Effekte, die die App-Shell beeinflussen koennen. Der globale Loader versteckt den Body nicht mehr standardmaessig. Ein Fade-In muss bewusst aktiviert werden:
+
+```html
+<body xt-ui-effects="fade-in">
+```
+
+RMT-Hosts koennen denselben Effekt als nicht-visuellen Intent beschreiben:
+
+```json
+{
+  "id": "app.ui-effects",
+  "kind": "ui_effects",
+  "tag": "ui-effects",
+  "props": {
+    "effect": "fade-in"
+  }
+}
+```
+
+Die Host-Seite bleibt Ausfuehrungsort. RMT beschreibt nur den Intent; `XUtils.prepareUiEffects()` und `XUtils.releaseUiEffects()` setzen die DOM-Attribute `data-xt-ui-effects`, `data-xt-ui-effects-state` und `data-xt-ui-effects-ready`. Fuer RMT-lose Umgebungen reicht das Body-Attribut. Fuer Shell-first Apps, die keinen Effekt wollen, ist kein Attribut noetig oder explizit `xt-ui-effects="none"` moeglich.
+
+## Hinweise
+
+- Neue Komponenten sollten fuer produktive UI-Vertraege bevorzugt eigene Component-APIs und XTend-Fabric-Gates nutzen.
+- `x-utils` bleibt ein kleiner Hilfsmodul-Pfad fuer Bestand, Demos und einfache DOM-Arbeit.
+- Suite, Fixture und Utility-Typisierung sind seit `WP-E12-09` vorhanden.
+- Seit `WP-E13-05` ist `x-utils` als `closed-as-utility-boundary` bewertet. Ein eigenes visuelles Performance-Profil ist fuer diese Utility-Boundary keine offene RC1-Aufgabe.

package/docs/de/components/xwriter.md

@@ -0,0 +1,94 @@
+# xwriter – XTend Komponente
+
+> **Siehe auch:** [xcode](./xcode.md), [xinput](./xinput.md)
+
+## Übersicht
+
+`<x-writer>` ist eine Komponente für Rich-Text-Editing und einfache WYSIWYG-Editoren. Sie unterstützt Formatierungen, Theming, State-Integration, Autosave, Export und API-Anbindung.
+
+---
+
+## Features
+- Rich-Text-Editing (fett, kursiv, Listen, Links, Farben, Größen)
+- State-Integration via xstate
+- Theming via CSS Custom Properties
+- Autosave (lokal oder API)
+- Export als Markdown/HTML
+- Drag & Drop für Bilder/Text
+- API-Anbindung (Speichern an Server)
+
+---
+
+## Verwendung
+
+```html
+<x-writer></x-writer>
+```
+
+---
+
+## Attribute
+| Attribut      | Typ     | Beschreibung                                              |
+|-------------- |---------|----------------------------------------------------------|
+| `value`       | String  | Initialer Textinhalt (Property, nicht Attribut)          |
+| `api`         | String  | API-Endpunkt für Speichern (z.B. `/api/save` oder `local` für LocalStorage) |
+| `method`      | String  | HTTP-Methode für API (Standard: `POST`)                  |
+| `autosave`    | Number  | Intervall in ms für Autosave (z.B. `10000` für 10s)      |
+| `storage-key` | String  | Key für LocalStorage (Standard: `xwriter-content`)       |
+
+---
+
+## Events
+| Event             | Beschreibung                                              |
+|-------------------|----------------------------------------------------------|
+| `writer:change`   | Bei Textänderung ausgelöst, Detail: `{html, markdown, plain}` |
+| `writer:save`     | Nach Speichern (lokal/API), Detail: `{status, response}` |
+| `writer:autosave` | Nach Autosave                                            |
+| `writer:export`   | Nach Export, Detail: `{filename, success}`               |
+| `writer:error`    | Bei Fehlern, Detail: `{error}`                           |
+
+---
+
+## API
+- **Text setzen/lesen:** `element.value = 'Text'` (Property, nicht Attribut)
+- **State-Integration:** Automatisch via xstate
+- **Speichern:**
+  - Lokal: `<x-writer api="local"></x-writer>`
+  - API: `<x-writer api="/api/save" method="POST"></x-writer>`
+- **Export:** Über Export-Button (Markdown/HTML)
+
+## Form Controls UX ab WP-E11-08
+
+`<x-writer>` stellt `xtendFormControlUxProfile` mit `xtend.component.form-control-ux-profile.v1` bereit. Das Profil beschreibt Rich-Text als Form-Control-nahe UX-Flaeche mit `writer:change`, `writer:error`, `xwriter-content`, `component.idle.hydrate`, Fabric-Lane `idle` und RMT Shell Authoring. `x-form` kann `writer:change` aufnehmen und den Wert in `xform-data-<id>` aggregieren.
+
+---
+
+## Beispiel: Dynamisch per JS
+
+```js
+const writer = document.createElement('x-writer');
+writer.value = 'Hallo Welt!';
+document.body.appendChild(writer);
+```
+
+---
+
+## Styling & Theming
+
+```css
+x-writer {
+  --writer-bg: #fff;
+  --writer-color: #222;
+  /* Weitere Custom Properties siehe CSS */
+}
+```
+
+---
+
+## Accessibility
+- Semantisches HTML, ARIA
+- Tastaturbedienung
+
+---
+
+*Letzte Aktualisierung: 16. Juli 2025*

package/docs/de/components.md

@@ -0,0 +1,153 @@
+# Komponenten-Entwicklung mit XTend
+
+XTend-Komponenten sind wiederverwendbare Web Components. In RMT-first Apps
+werden sie nicht zur App-Architektur selbst: RMT beschreibt Shell, State,
+Actions, Events, Surfaces und Scheduling; XTend Components materialisieren die
+sichtbare UI.
+
+Siehe auch [x-router](./components/xrouter.md), [x-link](./components/xlink.md)
+und [RMT vNext Authoring Guide](./rmt-vnext-authoring.md).
+
+## Grundprinzipien
+
+- Jede visuelle Komponente ist ein ES-Modul und wird per Manifest geladen.
+- Der Manifest-Key ist der kanonische Runtime- und Catalog-Name.
+- Fuer Custom Elements ist der Tag-Name identisch zum Manifest-Key, z. B.
+  `x-button`, `x-input`, `x-summary`.
+- Source-Dateien folgen im Bestand dem Modul-Basename ohne Bindestrich, z. B.
+  `xbutton.js` fuer `x-button`.
+- Komponenten bleiben unabhaengig, konfigurierbar und host-neutral.
+- RMT kann Komponenten referenzieren, mounten, hydrieren und mit Events
+  verbinden, importiert sie aber nicht in den Kernel.
+
+## Rolle in RMT-authorierten Apps
+
+| Ebene | Aufgabe |
+| --- | --- |
+| RMT vNext | beschreibt App Shell, Surfaces, State, Actions, Events und Lanes |
+| XTend Component | rendert UI, kapselt Shadow DOM, Attribute, Properties und Events |
+| Host Adapter | verbindet RMT Records mit realen Custom Elements und Browser-DOM |
+| Fabric | fuehrt Hydration, Render, User-Blocking- und Idle-Arbeit als Fibers aus |
+
+Eine RMT-Surface kann zum Beispiel `component x-cards` deklarieren. Der Host
+Adapter laedt `x-cards` ueber das Manifest, mountet das Custom Element und
+verdrahtet Event-Payloads mit RMT Actions.
+
+Die RMT vNext Component Capability Registry macht diesen Adapterpfad
+generisch. Sie liest Manifest, Component Contracts, `xtendRmtMetadata`,
+`observedAttributes`, Events, Slots, Parts, Form-Assoziation sowie A11y- und
+Performance-Profile und stellt daraus Capabilities fuer alle public
+Manifest-Komponenten bereit. Neue Komponenten bleiben normale Web Components;
+fuer RMT-Kompatibilitaet brauchen sie stabile public Contracts statt Host-
+Monkeypatching.
+
+## Struktur einer Komponente
+
+Typischerweise besteht eine Komponente aus:
+
+- einer Klasse, die von `HTMLElement` oder einer lokalen Basis erbt
+- Shadow DOM oder kontrolliertem Light-DOM
+- Styles ueber CSS Custom Properties, Parts oder lokale Shadow-DOM-Regeln
+- Attributen und Properties fuer Konfiguration
+- Custom Events fuer Kommunikation
+- Registrierung ueber `customElements.define(...)`
+
+### Minimalbeispiel
+
+```js
+class XButton extends HTMLElement {
+  constructor() {
+    super();
+    this.attachShadow({ mode: 'open' });
+    this.shadowRoot.innerHTML = `
+      <button part="button"><slot></slot></button>
+      <style>
+        :host { display: inline-flex; }
+        button { padding: 0.5rem 0.75rem; }
+      </style>
+    `;
+  }
+}
+
+customElements.define('x-button', XButton);
+```
+
+## Naming-Regeln
+
+| Ebene | Regel | Beispiel |
+| --- | --- | --- |
+| Manifest-Key | kanonischer Runtime- und Catalog-Name | `x-summary` |
+| Custom Element Tag | identisch zum Manifest-Key | `<x-summary>` |
+| Source-Datei | Modul-Basename aus dem Manifest-Pfad | `xsummary.js` |
+| Component-Doku | Source-Basename plus `.md` | `docs/components/xsummary.md` |
+| Docs-Menu-Slug | `components-` plus Source-Basename | `components-xsummary` |
+
+Ausnahmen bleiben bewusst klein: `xstate` ist ein Plattform-State-Modul,
+`x-utils` ist ein Utility-Modul ohne Custom Element und `x-theme` stellt die
+Theme-Fassade bereit.
+
+## Best Practices
+
+- Nutze Shadow DOM, Parts und CSS Custom Properties fuer Kapselung und
+  Theming.
+- Halte Attribute, Properties und Events stabil und dokumentiert.
+- Dispatch Events mit klaren `detail`-Payloads, damit RMT Actions sie sicher
+  konsumieren koennen.
+- Vermeide globale DOM-Annahmen in Komponenten; App-Struktur gehoert in RMT.
+- Nutze `x-icon` fuer lokale Icons, Icon Packs und kontrollierte URL-Quellen.
+- Plane Hydration bewusst: sichtbare UI gehoert in sichtbare Lanes, weniger
+  dringende Arbeit in idle oder lazy Pfade.
+
+## Beispiel mit Attribut und Event
+
+```js
+class XCounterButton extends HTMLElement {
+  static get observedAttributes() {
+    return ['value'];
+  }
+
+  constructor() {
+    super();
+    this.attachShadow({ mode: 'open' });
+    this.shadowRoot.innerHTML = `
+      <button part="button" type="button"></button>
+    `;
+    this.shadowRoot.querySelector('button').addEventListener('click', () => {
+      const value = Number(this.getAttribute('value') || 0) + 1;
+      this.setAttribute('value', String(value));
+      this.dispatchEvent(new CustomEvent('counter-change', {
+        bubbles: true,
+        detail: { value }
+      }));
+    });
+  }
+
+  attributeChangedCallback() {
+    const button = this.shadowRoot && this.shadowRoot.querySelector('button');
+    if (button) button.textContent = `Zaehler ${this.getAttribute('value') || 0}`;
+  }
+}
+
+customElements.define('x-counter-button', XCounterButton);
+```
+
+In RMT kann dieses Event als `on counter-change -> action ...` an eine Action
+gebunden werden.
+
+## Testen und Debugging
+
+- Komponenten koennen direkt im HTML getestet werden.
+- Nutze `xtend-loader.js` und den lokalen Dev Server fuer manuelle Tests.
+- Nutze RMT-Surfaces, wenn du Component-Verhalten im App-Lifecycle pruefen
+  willst.
+- Fuer API- und Typing-Fragen siehe [Public Component Types](./public-component-types.md).
+
+## Weiterfuehrende Themen
+
+- [Manifest-Format](./manifest.md)
+- [XTend Loader](./xtend-loader.md)
+- [RMT vNext Authoring Guide](./rmt-vnext-authoring.md)
+- [RMT vNext Component Primitives und XTend UI](./rmt-vnext-component-primitives.md)
+- [Component Platform](./component-platform.md)
+- [Component UX Authoring](./component-ux-authoring.md)
+- [API-Integration](./api.md)

package/docs/de/conditional-network-evidence-ci.md

@@ -0,0 +1,38 @@
+# Conditional Network Evidence CI
+
+Contract: `xtend.epic13.conditional-network-evidence-ci.v1`
+
+Status: `accepted-conditional-network-evidence-ci`
+
+Workpackage: `DPF-WP-03-conditional-network-evidence-ci`
+
+## Ziel
+
+Dieses Paket produktisiert Audit- und SBOM-Evidence fuer CI und Release Owner. Der lokale Gate bleibt netzwerkfrei; der CI-Job kann `npm audit --audit-level=moderate` und `npm sbom --sbom-format=cyclonedx --json` ausfuehren oder bei nicht verfuegbarem Netzwerk ein Owner-Deferral im Format `xtend.epic13.conditional-network-deferral.v1` schreiben.
+
+## Lokaler Gate
+
+```bash
+node scripts/run_xtend_tests.js epic13-conditional-network-evidence-ci --json
+npm run test:epic13-conditional-network-evidence-ci
+```
+
+## Capture
+
+```bash
+npm run conditional-network:evidence
+```
+
+Ohne `XTEND_CONDITIONAL_NETWORK_EXECUTE=1` schreibt der Capture lokale Deferral-Artefakte. In CI setzt `.github/workflows/xtend-default-gates.yml` `XTEND_CONDITIONAL_NETWORK_EXECUTE=1`, installiert Workspace-Links per `npm ci --ignore-scripts --no-audit --fund=false`, nutzt `XTEND_CONDITIONAL_NETWORK_USE_NPX_NPM10=1` fuer stabile SBOM-Ausgabe und laedt die Artefakte hoch:
+
+- `.xtend-test-results/xtend-npm-audit-report.json`
+- `.xtend-test-results/xtend-npm-sbom.json`
+- `.xtend-test-results/xtend-conditional-network-evidence-report.json`
+
+## Grenzen
+
+Nicht enthalten sind Dependency-Upgrades, Vulnerability-Fixes und Public Publish. Publish bleibt durch `private-until-release-owner-acceptance` blockiert, bis Audit/SBOM ausgefuehrt oder durch den Owner akzeptiert deferred sind.
+
+Der separate GitHub-Actions-Job `npm-publish-next` laeuft per `workflow_dispatch` mit `publish_to_npm=true` oder nach `release: published` und erlaubt keine Deferrals: Er setzt `XTEND_CONDITIONAL_NETWORK_ALLOW_DEFERRAL=0`, wiederholt `release:report`, Pack- und Audit/SBOM-Evidence und fuehrt danach `npm publish --tag next --provenance --access public` aus.
+
+Der naechste Schritt ist `DPF-WP-04-visual-pixel-evidence-storage`.

package/docs/de/conditional-network-evidence.md

@@ -0,0 +1,50 @@
+# Conditional Network Evidence
+
+`xtend.epic13.conditional-network-evidence.v1` beschreibt, wie RC1 mit Netzwerk-Gates umgeht, ohne lokale Entwicklung zu blockieren.
+
+Lokaler Gate:
+
+```bash
+node scripts/run_xtend_tests.js epic13-conditional-network-evidence --json
+```
+
+oder:
+
+```bash
+npm run test:epic13-conditional-network-evidence
+```
+
+## Commands
+
+| Command | Artefakt |
+|---------|----------|
+| `npm audit --audit-level=moderate` | `.xtend-test-results/xtend-npm-audit-report.json` |
+| `npm sbom --sbom-format=cyclonedx --json` | `.xtend-test-results/xtend-npm-sbom.json` |
+
+Der aggregierte Report liegt unter `.xtend-test-results/xtend-conditional-network-evidence-report.json`.
+
+## Lokales Verhalten
+
+Der lokale Gate fuehrt die Netzwerkbefehle nicht automatisch aus. Stattdessen prueft er, dass XTend fuer Offline-, Sandbox- und CI-Umgebungen ein stabiles Evidence-/Deferral-Format besitzt.
+
+Ab `DPF-WP-03` produktisiert [Conditional Network Evidence CI](./conditional-network-evidence-ci.md) den CI-Job und den Capture-Befehl `npm run conditional-network:evidence` unter `xtend.epic13.conditional-network-evidence-ci.v1`. Der Job kann die Audit-/SBOM-Kommandos ausfuehren oder Owner-Deferrals in denselben Artefaktpfaden ablegen.
+
+Default-Reason fuer lokale Deferrals:
+
+```text
+network-restricted-local-default
+```
+
+Weitere erlaubte Gruende:
+
+- `sandbox-network-unavailable`
+- `registry-auth-unavailable`
+- `owner-approved-offline-run`
+
+## Publish Boundary
+
+`private-until-release-owner-acceptance` bleibt aktiv. Deferred Network Evidence ist ein Review-Signal, aber keine Publish-Freigabe.
+
+`WP-E13-04` ist abgeschlossen. Der Package Export Lock beschreibt unter [Package Export Lock](./package-export-lock.md), wie `npm run pack:dry-run` und die Export Surface fuer RC1 gesperrt werden. `WP-E13-05` ist abgeschlossen; `WP-E13-06` hat die [Hydration Performance Closure](./hydration-performance-closure.md) abgeschlossen. `WP-E13-07` hat die [PROD Browser CSP Smokes](./prod-browser-csp-smokes.md) vorbereitet. `WP-E13-08` hat [Visual Owner Artifacts](./visual-owner-artifacts.md) normalisiert. `WP-E13-09` ist nun startbar.
+
+Weiterfuehrend: [Release Owner Acceptance](./release-owner-acceptance.md).

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

@@ -0,0 +1,110 @@
+# XTend Core Migration Guide
+
+## Uebersicht
+
+Dieser Guide fasst die produktiven Core-Standards aus Epic 01 zusammen. Er dient als Migrationshilfe fuer Legacy-Call-Sites und als Referenz fuer neue XTend-Core-Aenderungen.
+
+## Verifikation
+
+Der aktuelle Core-Contract ist automatisiert pruefbar:
+
+```bash
+node scripts/verify_xtend_core_contracts.js
+```
+
+## Runtime-Standards
+
+- `window.XTend.compliance` stellt Checklist, Contract-Uebersicht und Theme-Tokens bereit.
+- zentrale Design-Tokens werden ueber `xtheme` pro Theme registriert und auf `document.documentElement` gespiegelt.
+- Overlay- und Feedback-Komponenten respektieren `prefers-reduced-motion`, Fokus-Standards und kanonische XTend-State-Keys.
+
+## RMT-Templating-Migration ab Epic 04
+
+RMT-Templating ist additiv und opt-in. Bestehende XTend-Apps, klassische HTML-/JS-Integrationen und bestehende Web-Component-Nutzung bleiben gueltig. Eine App nutzt XTendRMT erst, wenn sie ein `.rmt` Dokument, einen RMT Root-Handshake, einen Template-Record oder einen Host Adapter bewusst registriert.
+
+Die verbindliche Migrationsnotiz liegt in `development/XTendRMT-Migrations-und-Framework-Agnostik-Leitplanken.md`.
+Der aktuelle Produktueberblick liegt in `docs/xtendrmt-overview.md`. Das produktive native Authoring-Modell ab Epic 05 liegt in `docs/xtendrmt-native-authoring.md`; die App-DSL-Referenz liegt in `docs/xtendrmt-app-dsl.md`; Runtime Bridge und Adapter sind in `docs/xtendrmt-runtime-bridge.md` beschrieben. Die Migration von Metadatenpfaden zu Top-Level-Domains liegt in `docs/xtendrmt-migration-guide.md`.
+
+| Ausgangslage | Migrationspfad |
+|--------------|----------------|
+| XTend-only App | unveraendert weiter betreiben; RMT nur fuer neue Roots oder Template-Piloten aktivieren |
+| XTend mit XRouter | Route-Records vorbereiten, produktive Adapterausfuehrung in Epic 05 |
+| XTend neben React/Vue | RMT als Scheduler oder Template-Transport nutzen, Host Adapter getrennt halten |
+| Vanilla oder Custom Host | eigene Scheduler-Endpoints deklarieren, keine XTend-Capabilities voraussetzen |
+| Legacy-Demo | klassifizieren und pruefen, nicht stillschweigend zum RMT-Produktcontract machen |
+
+Review-Regeln fuer RMT-kompatible Aenderungen:
+
+- keine XTend Runtime-Imports im RMT Kernel
+- keine erzwungene Migration bestehender Apps
+- keine neue XTend-Template-Sprache neben RMT
+- `kernelVisible: false` fuer XTend-spezifische Adapterdaten
+- produktive Bridge-Factories statt privater Demo-Brueckenlogik verwenden
+- historische Scaffold-Artefakte mit `bridgeRuntime: reserved-for-Epic-05` bleiben als Epic-04-Handoff lesbar, sind aber nicht mehr der operative Bridge-Status
+- `node scripts/run_xtend_tests.js rmt-compatibility --json` und `node scripts/run_xtend_tests.js references --json` als Mindestgates
+
+## Native RMT Routes und Components ab Epic 05
+
+Neue App-DSL-Dokumente sollen operative Routing-, Component- und Scheduling-Daten in nativen Top-Level-Domains fuehren:
+
+- `manifest.metadata.routes -> routes`
+- `manifest.metadata.components -> components`
+- `manifest.metadata.schedules -> schedules`
+- `xtend.xrouter` bleibt Router Adapter
+- `xtend.component` bleibt Component Adapter
+- `rmt.state-scheduler-diagnostics` bleibt Bridge Adapter
+
+`manifest.metadata` bleibt fuer Beschreibung, Handoff und historische Demo-Notizen gueltig, soll aber keine neue operative Route-/Component-Bridge tragen. Template-only-Dokumente bleiben kompatibel.
+
+Die produktive Ausfuehrung nutzt:
+
+- `createRmtFormat().normalizeDocument(...)`
+- `createRmtFormat().createRuntimeRegistries(...)`
+- `createRmtXRouterAdapter(...)`
+- `createRmtXtendComponentAdapter(...)`
+- `createRmtStateSchedulerDiagnosticsBridge(...)`
+
+Die Docs-App selbst bleibt Parsedown-basiert, rendert ihre App Shell aber inzwischen Shell-first aus RMT. Der Scheduling- und Shell-Pfad ist seit `ER-WP-40` in `docs/xtendrmt-parsedown-scheduling.md` und `docs/xtendrmt-parsedown-docs.rmt` als offizieller Pilot beschrieben.
+
+## Legacy zu kanonisch
+
+| Bereich | Legacy | Kanonisch | Status |
+|--------|--------|-----------|--------|
+| Dialog Open | `dialog-open-<id>` | `xtend.component.x-dialog.<id>.open` | Legacy bleibt kompatibel |
+| Dialog Open | `xdialog-open-<id>` | `xtend.component.x-dialog.<id>.open` | Legacy bleibt kompatibel |
+| Modal Open | `modal-open-<id>` | `xtend.component.x-modal.<id>.open` | Legacy bleibt kompatibel |
+| Theme Current | `theme` | `xtend.theme.current` | beide werden gespiegelt |
+| Theme List | `themes` | `xtend.theme.available` | beide werden gespiegelt |
+| Router Last Navigation | `router-navigated` | `xtend.router.lastNavigated` | beide werden gespiegelt |
+| Alert State | `xalert-state-<id>` | `xtend.component.x-alert.<id>` | Legacy bleibt kompatibel |
+
+## Was neue Core-Aenderungen beachten muessen
+
+- neue UI-Flows brauchen einen expliziten `xstate`-Zwilling
+- Doku, API, Typdefinitionen und Runtime muessen denselben Contract verwenden
+- neue Komponenten oder groessere Core-Aenderungen muessen gegen die Compliance-Checklist und den Verify-Script laufen
+
+## Design-Tokens
+
+Die zentralen Tokens kommen aus `xtheme` und koennen pro Theme angepasst werden:
+
+- `--xtend-color-primary`
+- `--xtend-color-primary-dark`
+- `--xtend-color-accent`
+- `--xtend-glass-bg`
+- `--xtend-glass-blur`
+- `--xtend-shadow`
+- `--xtend-border`
+- `--xtend-radius`
+- `--xtend-font-family`
+- `--xtend-focus-outline`
+- `--xtend-surface`
+- `--xtend-surface-muted`
+- `--xtend-text`
+- `--xtend-overlay-bg`
+
+## Hinweise fuer bestehende Integrationen
+
+- Bestehende Legacy-Open-Flags fuer Dialog und Modal muessen nicht sofort entfernt werden, sollten aber nicht mehr neu eingefuehrt werden.
+- Neue API-nahe Integrationen sollen `window.XTend.*` statt unnamespaced Helpern bevorzugen.
+- Fuer Core-Reviews ist die Checkliste in `development/XTend-Core-Compliance-Checklist.md` die operative Quelle.