@ccslabs/xtend 0.1.0-rc.1 → 0.1.2

package/docs/de/XTend-ADR.md

@@ -0,0 +1,221 @@
+# XTend Architecture Decision Record
+
+- Status: Accepted
+- Datum: 8. Mai 2026
+- Contract: `xtend.docs.architecture-decision-record.v2`
+- Typ: Produktarchitektur-Baseline fuer XTend UI, XTend-Fabric und XTendRMT
+
+## Zweck
+
+Dieses ADR ersetzt die fruehere Architekturaufnahme aus den ersten Epics. Die alte Fassung beschrieb noch eine Plattform im Umbau: Core-Konsolidierung, Loader-Rename, RMT-Fusion, Test-Harness und Component-Coverage waren damals teilweise erst Zielbild.
+
+Die heutige Entscheidung beschreibt den aktuellen Architekturvertrag fuer XTend als Enterprise-Webframework:
+
+- XTend UI ist das Web-Component- und UI-Builder-Produkt.
+- XTendRMT ist Scheduler, Runtime-Kernel, Templating Engine und native `.rmt` Authoring-Sprache.
+- XTend-Fabric ist die host-nahe Schutz-, Telemetry-, Lane- und Reporter-Schicht.
+- Die Docs-App ist eine XTend-App mit RMT-generierter Shell und Parsedown als scheduled Content-Komponente.
+- RMT Tooling, Linter und Language Server sind Teil der Authoring-Plattform.
+
+## Entscheidung
+
+XTend wird als **manifest- und state-zentriertes Web-Components-Framework** mit RMT-first App Authoring, Fabric Boundary und TypeScript-first Component Platform weitergefuehrt.
+
+Dokumentation, Manifest und Laufzeit-APIs muessen kuenftig als zusammengehoerender Vertrag gepflegt werden.
+
+Die Architektur trennt bewusst fuenf Verantwortungen:
+
+| Ebene | Verantwortung | Darf wissen von | Darf nicht tun |
+|-------|---------------|-----------------|----------------|
+| XTend UI | Custom Elements, Shells, Styling, A11y, UX und Host-Komponenten | Manifest, Loader, Component Contracts, Fabric Context | RMT-Kernel-Semantik implementieren |
+| XTend Loader | lokale ESM-Imports, Manifest Policy, Bootstrap, Component Loading | Manifest, Import Policy, Runtime API | CDN-Fallbacks erzwingen oder externe Quellen still laden |
+| XTend-Fabric | Fehlergrenzen, Telemetry, Reporter Adapter, Fibers, Lanes, Backpressure | XTend Runtime, optionale RMT Adapter Results | RMT-Dokumente parsen oder XTendRMT ersetzen |
+| XTendRMT | `.rmt` Source, DSL-Domains, Scheduling, Templates, Routes, Diagnostics | neutrale Adapter Records und Host Capabilities | XTend, XRouter, DOM, React, Vue oder `xstate` direkt importieren |
+| Tooling | Linter, LSP, Snippets, Reports, Editor Bridges | RMT Source Model, Parser, Rule Engine, Schema | eigene Semantik neben dem RMT-Sprachkern pflegen |
+
+## Architekturprinzipien
+
+### 1. Native Web Standards bleiben der Kern
+
+XTend basiert auf Custom Elements, Shadow DOM, Slots, CSS Custom Properties und ES-Modulen. Build- und TypeScript-Artefakte duerfen diese Laufzeit nicht hinter einem proprietaeren Abstraktionsmodell verstecken.
+
+Komponenten sind weiterhin echte Web Components. Framework-Integrationen fuer React, Vue oder Custom Hosts entstehen als Adapter oder Host-Konventionen, nicht als Ersatz fuer die native Oberflaeche.
+
+### 2. State-zentrierte UI
+
+`xstate` bleibt die host-nahe State-Boundary fuer XTend UI. Der State ist die beobachtbare Wahrheit fuer UI-Zustaende, Route-Spiegel, Theme-Kontext, Feedback, Komponentenzustaende und Diagnostics.
+
+Das **Digital Twin Principle** bleibt verbindlich: relevante UI-Aktionen muessen in einen nachvollziehbaren State-, Event- oder Diagnostic-Record zurueckschreiben. Lokale Flags duerfen nur abgeleitete Render-Caches sein.
+
+### 3. RMT-first, aber framework-agnostisch
+
+Neue App-Shells, Routes, Templates und Scheduling-Policies sollen primaer in nativen `.rmt` Dokumenten beschrieben werden. `.rmt.json` bleibt nur ein Edge-Case-Fallback fuer Hosts ohne passenden MIME-Typ oder fuer Legacy-Pfade.
+
+RMT ist trotzdem kein XTend-Untermodul. XTend ist First-Class Host, aber nicht Pflicht-Host. Der RMT-Kernel sieht Adapter-Records wie `xtend.component` oder `xtend.xrouter`, importiert aber keine XTend-Komponenten und fuehrt keine DOM-Arbeit selbst aus.
+
+### 4. Shell-first Rendering
+
+App-Shells sollen zuerst stabil rendern. Content, Markdown, Rich HTML, Medien und schwere Komponenten werden anschliessend scheduled oder lazy nachgeladen.
+
+Die Docs-App ist der Referenzpfad: RMT erzeugt die Shell, Parsedown ist eine scheduled Content-Komponente. Spaetere Inhalte wie XPlayer-Tutorials oder Rich-Content-Bloecke koennen in dieselbe Scheduling-Struktur aufgenommen werden.
+
+### 5. Fabric als Sicherheits- und Telemetry-Schicht
+
+XTend-Fabric ist der globale Host-Sicherheitslayer fuer Fehlergrenzen, Reporter Adapter, Telemetry, Lane/Fiber-Kontext, Backpressure und Qualitaetssignale.
+
+Fabric darf RMT Adapter Results und Scheduler-Signale aufnehmen, aber nicht den RMT-Kernel ersetzen. Dadurch bleibt die Grenze klar:
+
+```text
+RMT Kernel -> Adapter / Bridge Result -> XTend-Fabric -> XTend UI / Reporter
+```
+
+### 6. Performance-by-design
+
+Performance ist kein spaeter Optimierungsschritt. Komponenten muessen ihre Hydration-, Visibility-, Idle-, Busy- und Measurement-Profile deklarieren. Loader, Fabric und RMT duerfen diese Profile fuer Scheduling und Diagnostics verwenden.
+
+Die akzeptierten Baselines sind:
+
+- lokales ESM statt CDN-Abhaengigkeit
+- manifestbasierte Import Policy
+- Lazy, Idle und Visible Hydration Policies
+- Performance Regression Gates
+- Component-level Performance Profiles
+- Shell-first Rendering fuer App-Erstaufbau
+
+### 7. A11y-by-design
+
+A11y ist Teil des Component Contracts. Neue Komponenten muessen Keyboard-Verhalten, Focus, ARIA, Screenreader-Signale, Reduced Motion, Contrast und sichtbare States als Produktoberflaeche behandeln.
+
+RMT darf A11y-relevante Shell- und Component-Metadaten beschreiben. Die konkrete Ausfuehrung bleibt bei XTend UI und den Host-Adaptern.
+
+### 8. Tooling ist Teil des Produkts
+
+RMT ist nicht nur Runtime-Format, sondern Authoring-Sprache. Deshalb gehoeren Linter, AI-Agent Repair Report, Snippets, LSP, Editor Bridges und Release Gates zur Plattform.
+
+Der Language Server nutzt dieselbe Semantik wie `xt rmt lint`; Editor-Integrationen duerfen keine zweite RMT-Regelwelt pflegen.
+
+## Systembild
+
+```text
+App / Host
+  |
+  | local ESM + manifest policy
+  v
+XTend Loader
+  |
+  +-- XTend UI Components
+  |     +-- x-router / x-link
+  |     +-- x-header / x-menu / x-icon / x-hero / ...
+  |     +-- form, feedback, overlay, media and layout components
+  |
+  +-- xstate / xtheme / api.js
+  |
+  +-- XTend-Fabric
+        |
+        +-- telemetry, fibers, lanes, reporter adapters
+        |
+        +-- optional RMT adapter results
+
+XTendRMT
+  |
+  +-- .rmt source model
+  +-- templates, routes, components, schedules, adapters
+  +-- linter, language server, snippets, diagnostics
+  |
+  +-- host adapters: xtend.component, xtend.xrouter, docs.parsedown, custom hosts
+```
+
+## Laufzeitentscheidungen
+
+### Loader und Manifest
+
+Der kanonische Loader ist `xtend-loader.js`. Er arbeitet lokal, ESM-basiert und manifestgesteuert. Externe CDNs sind kein Normalpfad. Manifest-URLs und Component-Imports unterliegen der Import Policy.
+
+### Komponenten
+
+Komponenten folgen dem Component Contract v2 und der Epic-11-UX-Shell-Linie:
+
+- TypeScript-first Source, wenn neue Komponenten entstehen
+- Public Types
+- RMT Metadata
+- Fabric Boundary
+- A11y- und Performance-Profil
+- Component Fixture
+- Component Suite
+- Docs-Seite
+
+`x-icon` ist der Referenzfall fuer eine framework-agnostische Erweiterung: internes Core Icon Pack, lokale Lucide-Erweiterung, Pack Registry und RMT-kompatibler Adapter ohne CDN-Pflicht.
+
+### Routing
+
+`x-router` bleibt die XTend-UI-Routing-Komponente. RMT kann Routes deklarieren und ueber den `xtend.xrouter` Adapter an XRouter uebergeben. Seitentitel, Route-Metadaten und shell-nahe Navigation duerfen in RMT beschrieben werden.
+
+### Docs-App
+
+Die Docs-App ist nicht nur Dokumentation, sondern ein Produktbeispiel. Sie soll zeigen:
+
+- Shell-first Rendering mit RMT
+- Parsedown als scheduled Content-Komponente
+- stabile Navigation mit `x-router`
+- Quick Start, RMT Authoring, Linter und LSP als offizielle Developer Journey
+- keine App-spezifische Parallel-Logik, wenn eine fehlende Faehigkeit in XTend-Komponenten gehoert
+
+## Non-Goals
+
+Diese Entscheidung bedeutet ausdruecklich nicht:
+
+- XTend wird zu einem React-/Vue-Ersatz mit eigenem virtuellen DOM.
+- RMT wird an XTend gebunden.
+- Fabric wird zum Parser, Router oder Scheduler-Kernel.
+- `.rmt.json` wird als bevorzugtes Authoring-Format beworben.
+- Editor-Plugins duerfen eigene RMT-Semantik einfuehren.
+- Komponenten duerfen A11y oder Performance als optionale spaetere Politur behandeln.
+
+## Konsequenzen
+
+1. Neue Architekturarbeit muss zuerst einer Ebene zugeordnet werden: Loader, XTend UI, Fabric, RMT, Tooling oder Docs.
+2. Wenn XTend-spezifisches Verhalten in RMT gebraucht wird, entsteht ein Adapter-Contract, kein Kernel-Sonderfall.
+3. Wenn eine App Sonderlogik braucht, wird zuerst geprueft, ob eine generische Component-, Fabric- oder RMT-Faehigkeit fehlt.
+4. Neue Dokumentation muss native `.rmt` Dateien empfehlen. `.rmt.json` darf nur als Fallback beschrieben werden.
+5. Jede neue First-Class-Komponente braucht RMT-, Fabric-, A11y-, Performance-, Type- und Testabdeckung.
+6. Release- und Reference-Gates bleiben Teil des Architekturvertrags.
+
+## Verbindliche Gates
+
+Die Architektur-Baseline wird durch lokale Gates abgesichert:
+
+```bash
+node scripts/run_xtend_tests.js architecture
+node scripts/run_xtend_tests.js references --json
+node scripts/run_xtend_tests.js rmt-compatibility --json
+node scripts/run_xtend_tests.js epic14-lsp-handoff --json
+npm run test:release:full:report
+```
+
+Fuer gezielte Arbeit bleiben die spezialisierten Gates massgeblich:
+
+| Bereich | Gate |
+|---------|------|
+| Core Architektur | `node scripts/run_xtend_tests.js architecture` |
+| Component Catalog | `npm run test:catalog-coverage` |
+| RMT Tooling | `npm run test:rmt-tooling` |
+| LSP Handoff | `npm run test:epic14-lsp-handoff` |
+| Docs Referenzen | `node scripts/run_xtend_tests.js references --json` |
+
+## Akzeptierte Folgeentscheidungen
+
+Dieses ADR integriert die Ergebnisse der bisherigen Einzelentscheidungen:
+
+- Loader und lokale Entwicklung: `xtend.loader.local-development.adr.v1`
+- XTend-Fabric: `xtend.fabric.adr.v1`
+- Security Trust Boundaries: `xtend.security.trust-boundaries.adr.v1`
+- XTendRMT First-Class Fusion: `development/ADR-XTendRMT-First-Class-Fusion.md`
+- RMT Tooling und LSP Handoff: `xtend.epic14.lsp-handoff.v1`
+
+Die Einzel-ADRs bleiben als Detailquellen gueltig. Dieses Dokument ist die aktuelle Docs-App-Baseline fuer das Gesamtbild.
+
+## Fazit
+
+XTend ist heute kein loses Komponentenpaket mehr, sondern eine gekoppelte Plattform aus Web Components, Loader, State, Fabric, RMT und Authoring Tooling.
+
+Der wichtigste Produktpfad ist jetzt nicht mehr die reine Flaechenerweiterung, sondern die konsequente Reife dieser Plattform: native `.rmt` Authoring-Erfahrung, bessere Editor-Unterstuetzung, stabile Component Shells, A11y, Performance, Security und nachvollziehbare Release Gates.

package/docs/de/a11y-keyboard-smokes.md

@@ -0,0 +1,62 @@
+# A11y Keyboard Smokes
+
+Contract:
+
+```text
+xtend.docs.a11y-keyboard-smokes.v1
+xtend.a11y.browser-keyboard-smoke.v1
+```
+
+XTend prueft ab `ER-WP-24` zentrale A11y-Interaktionen browsernah. Der Gate ist kein Ersatz fuer manuelle Screenreader-Reviews, aber er verhindert, dass Fokus- und Keyboard-Pfade unbemerkt aus Core-Komponenten herausfallen.
+
+## Fixture
+
+Die selbstpruefende Browser-Fixture liegt hier:
+
+```text
+tests/browser/fixtures/a11y-focus-keyboard-smoke.html
+```
+
+Sie nutzt:
+
+- `xtend-loader.js`
+- `data-manifest="/tests/browser/fixtures/components/manifest.json"`
+- lokale Component-Module
+- `window.__xtendA11yKeyboardSmokeResult`
+
+## Abgedeckte Pfade
+
+| Bereich | Komponente | Erwartung |
+|---------|------------|-----------|
+| Routing | `x-link` + `x-router` | `Enter` und `Space` navigieren, `aria-current` folgt der Route |
+| Form | `x-input` + `x-form` | Fokus wird delegiert, Eingabe synchronisiert `xstate` und Formdaten |
+| Tabs | `x-tabs` | `ArrowRight`, `ArrowLeft` und `Enter` bleiben aktivierbar |
+| Overlay | `x-modal` | Initialfokus, Fokusfalle, `Escape` und Fokusrestore funktionieren |
+
+`x-dialog` nutzt denselben Overlay-Contract und wird im Gate source-seitig auf Fokusfalle, `Escape` und Fokusrestore geprueft.
+
+## Lokale Gates
+
+```bash
+node scripts/run_xtend_tests.js browser --json
+node scripts/run_xtend_tests.js a11y-hydration --json
+```
+
+Optional kann der Browser-Smoke mit Safari WebDriver ausgefuehrt werden:
+
+```bash
+XTEND_BROWSER_SMOKE_DRIVER=safari node scripts/run_xtend_tests.js browser
+```
+
+Der Standardlauf bleibt deterministisch und benoetigt keinen externen Browser.
+
+## Komponentenautoren
+
+Neue oder modernisierte Komponenten sollen ihren A11y-Pfad aus dem Profil ableiten:
+
+- Routing und Commands: `Enter`, optional `Space`, aktiver ARIA-State.
+- Overlays: Initialfokus, Fokusfalle, `Escape`, Fokusrestore.
+- Form Controls: delegierter Fokus, Eingabeereignisse, State-/Form-Synchronisierung.
+- Composite Widgets: Pfeiltasten und aktueller ARIA-State.
+
+Scaffolded Komponenten erhalten ab `ER-WP-23` ein `xtend.a11y.profile.v1`. ER-WP-24 liefert den browsernahen Gate, an den solche Profile spaeter komponentenspezifisch andocken koennen.

package/docs/de/about.md

@@ -0,0 +1,18 @@
+# Über diese Dokumentations-Web App
+
+Diese Webanwendung dient als interaktive Dokumentation für das XTend Web-Framework und basiert vollständig auf modernen Web Components. Sie bietet eine modulare, schnelle und benutzerfreundliche Oberfläche für Entwickler und Anwender.
+
+## Verwendete Open-Source-Projekte
+
+### Parsedown
+Diese Anwendung nutzt für die Markdown-Verarbeitung das Projekt **Parsedown** von Emanuil Rusev.
+
+> (c) Emanuil Rusev  
+> http://erusev.com
+
+### XRouter PHP
+Das Routing und die serverseitige Logik basieren auf einer PHP-Implementierung von XRouter, entwickelt von **CCS Networks**. Das Projekt ist nun unter dem Namen **xrouter.php** verfügbar.
+
+---
+
+Weitere Informationen und Credits finden Sie in den jeweiligen Komponenten-Dokumentationen.

package/docs/de/api.md

@@ -0,0 +1,157 @@
+# XTend API
+
+## Uebersicht
+
+`api.js` ist die Orchestrierungsschicht zwischen Loader, Core-Komponenten und globalen Helper-APIs. Sie initialisiert die XTend-APIs idempotent, haertet den gemeinsamen UI-State und laedt API-relevante Komponenten aus dem Manifest nach.
+
+## Initialisierung
+
+Der Loader importiert `api.js` nach dem Manifest-Laden und ruft anschliessend `initXTendAPI(manifest)` auf.
+
+```js
+const api = await import('./api.js');
+await api.initXTendAPI(manifest);
+```
+
+## Contract von `initXTendAPI(manifest)`
+
+- initialisiert `ui` in `xstate` defensiv und zerstoert keinen bestehenden UI-State bei Mehrfachaufruf
+- stellt Theme-State (`theme`, `themes`) nur dann bereit, wenn er noch nicht existiert
+- laedt die API-relevanten Core-Module ueber Manifest-URLs als ES-Module
+- bindet die globalen Helper erneut an den `window.XTend`-Namespace, falls die API erneut initialisiert wird
+
+## Globale APIs
+
+Nach erfolgreicher Initialisierung stehen folgende APIs zur Verfuegung:
+
+- `window.XTheme`
+- `window.XToast`
+- `window.XAlert`
+- `window.XDialog`
+- `window.XModal`
+
+Zusatzlich werden die APIs unter `window.XTend` gespiegelt:
+
+- `window.XTend.theme`
+- `window.XTend.toast`
+- `window.XTend.alert`
+- `window.XTend.dialog`
+- `window.XTend.modal`
+- `window.XTend.compliance`
+
+Die Legacy-Helper bleiben verfuegbar:
+
+- `window.showToast`
+- `window.showAlert`
+- `window.showDialog`
+- `window.showModal`
+
+## Compliance-API
+
+`window.XTend.compliance` beschreibt den produktiven Core-Review-Contract. Verfuegbare Methoden:
+
+- `getChecklist()`
+- `getCoreContracts()`
+- `getThemeTokens(themeName?)`
+
+Die Runtime spiegelt diese Metadaten zusaetzlich in `xstate`:
+
+- `xtend.compliance.version`
+- `xtend.compliance.checklist`
+- `xtend.compliance.contracts`
+
+## UI-State
+
+Die API verwaltet den gemeinsamen UI-State unter `xstate.get('ui')`.
+
+```js
+{
+  toasts: [],
+  alerts: [],
+  dialogs: [],
+  modals: []
+}
+```
+
+Die API aktualisiert diesen State nur differenziell. Re-Init fuehrt nicht mehr zu einem Reset laufender UI-Eintraege.
+
+## Theme-API
+
+`window.XTheme` ist die oeffentliche Theme-Fassade. Wichtige Methoden:
+
+- `getCurrentTheme()`
+- `getAvailableThemes()`
+- `setTheme(themeName)`
+- `set(name, value)`
+- `get(name)`
+- `subscribe(fn)`
+- `registerTheme(name, properties)`
+- `loadExternalTheme(themeName, cssUrl)`
+- `toggleDarkMode()`
+
+`set(name, value)` ist die Kompatibilitaets-Fassade:
+
+- `set('dark')` schaltet auf ein Theme
+- `set('--primary-color', '#0e4e81')` setzt eine CSS-Variable fuer das aktuelle Theme
+
+## Dialog- und Modal-Flags
+
+Die API schreibt Open-State kompatibel fuer bestehende Call-Sites:
+
+- Dialog: `dialog-open-<id>`, `xdialog-open-<id>`
+- Modal: `modal-open-<id>`
+
+Der kanonische Zielpfad aus der Contract-Matrix bleibt fuer neue Arbeit relevant:
+
+- `xtend.component.x-dialog.<id>.open`
+- `xtend.component.x-modal.<id>.open`
+
+## XTendRMT Runtime-API
+
+XTendRMT ist nicht Teil von `api.js`, aber die oeffentliche XTend-Entwicklerdokumentation fuehrt den produktiven Integrationspfad mit. Die Runtime-Factories liegen in den Artefakten unter `xtendrmt/`:
+
+- `createRmtFormat`
+- `createRmtXRouterAdapter`
+- `createRmtXtendComponentAdapter`
+- `createRmtStateSchedulerDiagnosticsBridge`
+
+ESM:
+
+```js
+import {
+  createRmtFormat,
+  createRmtXRouterAdapter,
+  createRmtXtendComponentAdapter,
+  createRmtStateSchedulerDiagnosticsBridge
+} from './xtendrmt/rmt-runtime.esm.js';
+```
+
+Browser Classic:
+
+```html
+<script src="/xtendrmt/rmt-runtime.browser.js"></script>
+<script type="module">
+  const format = window.AppModules.createRmtFormat();
+  const rmt = window.xtend.rmt;
+</script>
+```
+
+RMT-nahe XTend-Integrationen sollen diese Factories verwenden, statt private Demo-Bruecken oder direkte Kernel-Kopplung aufzubauen. Details stehen in [XTendRMT Runtime Bridge](./xtendrmt-runtime-bridge.md).
+
+## Hinweise
+
+- `api.js` ist eine Runtime-Orchestrierung, keine statische Komponentenliste.
+- Die API erwartet ein konsistentes Manifest und bereits verfügbare `xstate`-Bootstrap-Infrastruktur.
+- Komponenten sollen weiterhin bevorzugt deklarativ verwendet werden; die API ist fuer dynamische Flows gedacht.
+- Nach Core-Aenderungen sollte `node scripts/verify_xtend_core_contracts.js` ausgefuehrt werden.
+
+## Weiterfuehrende Themen
+
+- [Manifest-Format](./manifest.md)
+- [XTend Loader](./xtend-loader.md)
+- [xrouter](./components/xrouter.md)
+- [xlink](./components/xlink.md)
+- [xtheme](./components/xtheme.md)
+- [Core Migration Guide](./core-migration-guide.md)
+- [XTendRMT Developer Overview](./xtendrmt-overview.md)
+- [XTendRMT Runtime Bridge](./xtendrmt-runtime-bridge.md)

package/docs/de/best-practices.md

@@ -0,0 +1,76 @@
+# Best Practices für XTend
+
+Diese Empfehlungen helfen dir, XTend-Projekte robust, performant und wartbar zu gestalten – sowohl für menschliche Entwickler als auch für AI-Coding-Agenten.
+
+---
+
+## Komponenten-Nutzung
+- **Deklarativ bevorzugen:** Nutze XTend-Komponenten möglichst direkt im HTML, nicht nur dynamisch per JS.
+- **Lazy Loading:** Baue Seiten so, dass Komponenten erst geladen werden, wenn sie gebraucht werden (Viewport, User-Interaktion).
+- **Shadow DOM:** Verwende Shadow DOM für Style-Kapselung und Konfliktvermeidung.
+- **Slots & Attribute:** Nutze Slots und Attribute für flexible, wiederverwendbare Komponenten.
+
+---
+
+## State-Management
+- **xstate nutzen:** Teile globalen und lokalen Zustand über das zentrale State-Management-Modul.
+- **Abonnements:** Reagiere auf State-Änderungen mit `xstate.subscribe` statt aufwändiger DOM-Queries.
+
+---
+
+## Theming & Styling
+- **CSS Custom Properties:** Verwende Variablen für Farben, Abstände, etc. – so bleibt das Design flexibel.
+- **xtheme nutzen:** Setze globale Styles und Theme-Änderungen zentral über das Theme-Modul.
+- **Dark/Light-Mode:** Unterstütze beide Modi und respektiere Systempräferenzen.
+
+---
+
+## Barrierefreiheit (Accessibility)
+- **ARIA-Rollen:** Setze sinnvolle ARIA-Attribute und Rollen.
+- **Keyboard-Navigation:** Stelle sicher, dass alle interaktiven Komponenten per Tastatur bedienbar sind.
+- **Fokus-Management:** Dialoge, Modals und Menüs sollten den Fokus korrekt setzen und zurückgeben.
+
+---
+
+## Performance
+- **Minimiertes Manifest:** Entferne ungenutzte Komponenten aus dem Manifest für Produktions-Builds.
+- **Kleine Bundles:** Halte Komponenten modular und klein, um Ladezeiten zu optimieren.
+- **IntersectionObserver:** Nutze Lazy Loading für große oder selten genutzte Komponenten.
+
+---
+
+## Entwicklung & Wartung
+- **Dokumentation:** Jede Komponente sollte eine eigene, aktuelle MD-Dokumentation besitzen.
+- **Namenskonventionen:** Halte dich an das `x`-Prefix und sprechende Namen.
+- **Testing:** Teste Komponenten isoliert und im Zusammenspiel.
+- **Querverweise:** Pflege Querverweise in der Doku für bessere Orientierung.
+
+---
+
+## Testpflicht fuer neue Komponenten
+- **Profil festlegen:** Ordne jede neue oder modernisierte Komponente einem Profil aus `development/XTend-Component-Level-Teststandard.md` zu.
+- **Artefakte vollständig halten:** Komponente, Doku, Component-Suite, Fixture, Typdefinition und Manifest-Eintrag sind Pflicht, sofern nicht explizit begründet ausgenommen.
+- **Scaffold als Standardpfad:** `XTend-Scaffold` muss die Testpflicht aus `development/XTend-Testpflicht-und-Scaffold-Anschluss.md` als Blueprint verwenden.
+- **Lokale Gates ausführen:** Nutze mindestens `node scripts/run_xtend_tests.js components`, `a11y-hydration`, `references` und bei RMT-kompatiblen Scaffold-Artefakten `rmt-compatibility`; bei Core-Bezug zusätzlich `core`, `architecture` und `browser`.
+- **Keine Platzhaltertests:** Testdateien ohne echte Assertions erfüllen die Testpflicht nicht.
+
+## XTendRMT-kompatible Entwicklung
+
+- **Native Domains bevorzugen:** Neue RMT-nahe Arbeit nutzt `adapters`, `components`, `routes`, `schedules` und `templates` statt operativer `manifest.metadata`-Bloecke.
+- **Kernel-Grenze halten:** XTend, XRouter, DOM, `window.XTend` und `xstate` gehoeren in Adapter oder Host-Code, nicht in den RMT Kernel.
+- **Produktive Factories nutzen:** Verwende `createRmtXRouterAdapter`, `createRmtXtendComponentAdapter` und `createRmtStateSchedulerDiagnosticsBridge` statt privater Demo-Brueckenlogik.
+- **Multi-Host pruefen:** XTend ist First-Class Host, aber nicht Pflicht-Host. Ein nicht-XTend Pfad wie `vanilla.component` sollte bei Framework-nahen Aenderungen mitgedacht werden.
+- **Trusted DOM respektieren:** RMT `dom_descriptor` ist bevorzugt. RMT `html_fragment` und Parsedown HTML brauchen `xtend.security.sanitizing-boundary.v1`; rohe `innerHTML`-Sinks gehoeren nicht in Komponenten oder Adapter.
+- **Docs-App respektieren:** Die offizielle Dokumentation nutzt Parsedown als Parser-Host, rendert ihre Shell aber Shell-first ueber RMT. Neue Docs-Komfortfunktionen sollen `docs/xtendrmt-parsedown-scheduling.md`, `docs.app.shell` und die vorhandenen RMT-Schedules nutzen, statt neben dem Host-Adapter eine zweite SPA-Schicht aufzubauen.
+- **Gates ausfuehren:** Fuer RMT-nahe Aenderungen mindestens `node scripts/run_xtend_tests.js rmt-compatibility --json`, `node scripts/run_xtend_tests.js references --json` und bei Browserpfad `node scripts/run_xtend_tests.js browser --json`.
+
+---
+
+## AI-Optimierung
+- **Konsistente API:** Halte Methoden und Attribute konsistent und sprechend.
+- **Beispielcode:** Ergänze jede Doku um konkrete Codebeispiele.
+- **Semantische Struktur:** Nutze klare Überschriften, Tabellen und Listen für AI-Parsing.
+
+---
+
+*Letzte Aktualisierung: 5. Mai 2026*

package/docs/de/changelog.md

@@ -0,0 +1,107 @@
+# XTend Changelog
+
+Dieser Artikel sammelt die historischen Epic-, Workpackage-, Handoff- und
+Gate-Notizen, die frueher in vielen einzelnen Developer-Artikeln standen. Die
+normalen Guides bleiben dadurch auf Produktnutzung und Developer Experience
+fokussiert; dieser Changelog ist der kanonische Ort fuer Fortschritt,
+Release-Signale und technische Historie.
+
+## RMT vNext und App-Shell-Authoring
+
+- `RMT-VNEXT-PRIM-01` bis `RMT-VNEXT-PRIM-04` haben Grammar, Parser, Semantic
+  Graph und Lowering fuer RMT-vNext-Primitives aufgebaut.
+- `RMT-VNEXT-PRIM-05` hat Fabric Lane/Fiber Evidence fuer vNext-authorierte
+  Lanes, Route-Fibers und Component-Fibers nachgezogen.
+- `RMT-VNEXT-PRIM-06` hat das Source-to-Sea-Gate aufgebaut: vNext Source,
+  Kernel Records, Fabric Telemetry, UI-Marker und Browser-Evidence werden
+  ueber Primitive IDs korreliert.
+- `RMT-VNEXT-PRIM-07` hat die Authoring-DX abgeschlossen: Completions, Hover,
+  Symbols, Code Actions, Safe Fix-All und VS-Code-Bridge arbeiten aus echten
+  RMT-vNext-Quellen.
+- `RMT-VNEXT-PRIM-08` hat Migration und Legacy-Backgrounding abgeschlossen:
+  App-Platform-Primitive-JSON bleibt Mirror/Compiler-Target, waehrend vNext
+  der Authoring-Pfad ist.
+- `WP-E15-18` hat den vNext Release Handoff gebuendelt. Die Reference Demo
+  liegt in `xtendrmt/rmt-vnext-reference-demo.rmt`, der stabile Core-Output in
+  `xtendrmt/rmt-vnext-reference-demo.core.json`.
+
+## RMT Tooling, LSP und Editor-Integration
+
+- `WP-E14-02` bis `WP-E14-04` haben Source Model, Parser/Format Adapter und
+  Semantic Graph fuer native `.rmt` Dokumente stabilisiert.
+- `WP-E14-05` bis `WP-E14-10` haben Linter, CLI, Completion, Hover, Document
+  Symbols, Definition und sichere Code Actions aufgebaut.
+- `WP-E14-11` hat AI-Agent Repair Reports mit `repairPlan`, `fixOrder`,
+  `confidence`, `impact` und No-Op-Erklaerungen eingefuehrt.
+- `WP-E14-12` hat Snippets, Editor Packaging und die VS-Code-Bridge
+  vorbereitet.
+- `WP-E14-14` hat Quick Start, Linter- und Language-Server-Dokumentation
+  konsolidiert. Der Contract bleibt `xtend.rmt.tooling-docs.v1`; der lokale
+  Gate bleibt `node scripts/run_xtend_tests.js rmt-tooling-docs --json`.
+- `WP-E14-15` und `WP-E14-16` haben RMT Tooling Release Gates und den LSP
+  Handoff abgeschlossen.
+
+## XTendRMT Runtime, Kernel und Fabric
+
+- Epic 05 hat XTendRMT als produktiven Scheduler-, Runtime- und
+  Templating-Pfad etabliert: native `.rmt` Domains, Runtime Registry, XRouter
+  Adapter, XTend Component Adapter und State-/Scheduler-/Diagnostics Bridge.
+- `ER-WP-08` bis `ER-WP-21` haben Fabric als Host-Kern, Component
+  Lifecycle Error Boundary, Reporter Adapter, Diagnostics Bridge, Component
+  und Route Fibers, Telemetry Snapshots, Performance Measurements, Regression
+  und Hydration Policies aufgebaut.
+- `ER-WP-13` hat Fabric-Lanes auf host-neutrale RMT Schedule Records
+  abgebildet. Die RMT-Kernel-Grenze bleibt framework-neutral.
+- `RKSH-WP-11` hat Kernel-Migration, Trusted Output Authoring sowie Panic- und
+  Recovery-Incident-Handoff dokumentiert.
+
+## Component Platform und App-Surfaces
+
+- Epic 10 hat TypeScript-first Components, Component Contract v2,
+  RMT-first Apps und Platform Gates aufgebaut.
+- Epic 11 hat Component UX, Shell Styling, A11y, Visual Regression,
+  Enterprise UX Handoff und Long-Tail-Migration vorbereitet.
+- SurfaceManager-Pakete `WP-SM-01` bis `WP-SM-19` haben RMT Authoring,
+  Controller, Window Runtime, SidePanel, Workbench Fixture, Overlay Bridge,
+  Native RMT Surfaces, Route Lifecycles, Persistence, Layout Engines,
+  Component Lab und Runtime Release Handoff aufgebaut.
+- Epic 18 hat App-Platform-Primitives, Media-Manager-Lessons-Learned,
+  Vendor-Bugfix-Backports und generische RMT App-Platform-Fixtures in den
+  Upstream-Stand ueberfuehrt.
+
+## Quality, Security und Release
+
+- Epic 12 hat RC0-Hardening, Visual Snapshot Automation, Design Token
+  Productization, RMT DSL Authoring Polish und Adoption Guides gebuendelt.
+- Epic 13 hat RC1 Readiness, Release Owner Acceptance, Conditional Network
+  Evidence, Package Export Lock, Trusted DOM, RMT Production Readiness,
+  Visual Owner Artifacts und CI-Handoff konsolidiert.
+- `DPF-WP-02` und `DPF-WP-03` haben Release Report, Pack Dry Run Evidence und
+  Conditional Network Evidence CI produktisiert.
+- `WP-TypeExports-01` bis `WP-TypeExports-09` haben Package `types`
+  Conditions, RMT-/Loader-/API-/Policy-/Builder-/Catalog-/Vendor-Facades und
+  Drift Reports abgesichert.
+
+## Was gehoert nicht mehr in Einzelartikel?
+
+Developer Guides sollen nicht mehr als Release-Protokoll gelesen werden. Neue
+oder ueberarbeitete Artikel sollen:
+
+- produktive Nutzung, Syntax und Architektur erklaeren;
+- lokale Befehle nur dort nennen, wo sie fuer den Arbeitsfluss gebraucht
+  werden;
+- Epic-, WP-, Status- und Handoff-Historie hier im Changelog ablegen;
+- auf `development/` nur verweisen, wenn ein internes Detail wirklich
+  nachvollzogen werden muss.
+
+## Relevante Release-nahe Artikel
+
+- [RMT vNext Release Handoff](./rmt-vnext-release-handoff.md)
+- [RMT vNext Source-to-Sea Gate](./rmt-vnext-source-to-sea-gate.md)
+- [RMT vNext Fabric Bridge Evidence](./rmt-vnext-fabric-bridge-evidence.md)
+- [RMT vNext Primitive Authoring Tooling](./rmt-vnext-primitive-authoring-tooling.md)
+- [RMT vNext Primitive Migration](./rmt-vnext-primitive-migration.md)
+- [RC1 Readiness](./rc1-readiness.md)
+- [RC1 Gate Matrix und CI-Handoff](./rc1-gate-matrix-ci-handoff.md)
+- [Release Report und Pack Dry Run Evidence](./release-report-pack-dry-run-evidence.md)
+- [TypeExports](./type-exports.md)