@ccslabs/xtend 0.1.0-rc.1

package/docs/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/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/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/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/component-catalog-coverage.md

@@ -0,0 +1,58 @@
+# Component Catalog Coverage
+
+- Contract: `xtend.docs.component-catalog-coverage.v1`
+- Matrix Contract: `xtend.catalog.component-coverage-matrix.v1`
+- Gate Contract: `xtend.catalog.component-coverage-gate.v1`
+- Workpackage: `ER-WP-31`, fortgeschrieben durch `ER-WP-32`, `ER-WP-33`, `ER-WP-34`, `ER-WP-35`, `WP-E11-12`, `WP-E11-17`, `WP-E12-02`, `WP-E12-03`, `WP-E12-04`, `WP-E12-05`, `WP-E12-06`, `WP-E12-07`, `WP-E12-08`, `WP-E12-09`, `WP-E13-12A`, `WP-SM-03`, `WP-SM-04` und `RC1TB-WP-03`
+
+Die Component Catalog Coverage Matrix zeigt, wie reif jede Komponente aus `components/manifest.json` gerade ist. Sie verbindet Source, Dokumentation, Component-Level-Suite, Fixture, Types, A11y und Performance zu einem Statusmodell.
+
+## Lokal pruefen
+
+```bash
+npm run test:catalog-coverage
+node scripts/run_xtend_tests.js catalog-coverage --json
+```
+
+Der Gate ist aktuell gruen, wenn alle Manifest-Sources lokal aufloesbar sind und der Matrix-Report strukturell valide ist. Fehlende Suites, Fixtures, Types, A11y- und Performance-Profile erscheinen als Warnungen. So kann der Catalog Schritt fuer Schritt gehaertet werden, ohne offene Folgepakete zu verstecken.
+
+## Statusmodell
+
+| Status | Bedeutung |
+|--------|-----------|
+| `enterprise-ready` | vollstaendige Source-, Docs-, Suite-, Fixture-, Types-, A11y- und Performance-Coverage |
+| `typed-contract-gated` | Types und A11y sind vorhanden, Performance fehlt noch |
+| `contract-gated` | Source, Docs, Component-Suite und Fixture sind vorhanden |
+| `documented` | Source und Docs sind vorhanden |
+| `source-only` | Source ist vorhanden, Docs oder Gates fehlen |
+| `missing-source` | Manifest zeigt auf keine lokale Source; dieser Zustand blockiert |
+
+## Aktueller Stand
+
+Der Snapshot nach `RC1TB-WP-03` zeigt:
+
+- 42 Manifest-Komponenten
+- 42 lokale Source-Dateien
+- 42 Komponenten-Dokumente
+- 42 Component-Level-Suites und Fixtures
+- 42 Public-Type-Artefakte fuer priorisierte Komponenten
+- 41 Komponenten mit erkennbarer A11y-Oberflaeche
+- 40 Komponenten mit explizitem Runtime-/UI-Performance-Profil
+
+`x-input`, `x-select`, `x-checkbox`, `x-radio`, `x-rmt-lifecycle-demo-build`, `x-textarea`, `x-form`, `x-calendar`, `x-writer`, `x-status`, `x-progress`, `x-tooltip`, `x-popover`, `x-drawer`, `x-surface-manager`, `x-surface-window`, `x-side-panel`, `x-modal`, `x-dialog`, `x-alert`, `x-toast`, `x-spinner`, `x-router`, `x-link`, `x-tabs`, `x-theme`, `x-button`, `x-icon`, `x-menu`, `x-footer`, `x-lightbox`, `x-masonry`, `x-code`, `x-header`, `x-hero`, `x-type`, `x-summary`, `x-section`, `x-cards` und `x-player` bilden die aktuelle `enterprise-ready` Linie: Source, Docs, Component-Suite, Fixture, Public Types, A11y und Performance-Profil sind vollstaendig vorhanden. `xstate` ist seit [Known Residual Triage](./known-residual-triage.md) als Runtime-Boundary geschlossen; `x-utils` ist als Utility-Boundary geschlossen. Beide bleiben bewusst nicht als visuelle `enterprise-ready` Komponenten klassifiziert.
+
+Seit `ER-WP-35` existiert zusaetzlich der Regression-Priority-Plan `xtend.catalog.component-regression-priority-plan.v1`. Er priorisiert alle 42 Manifest-Eintraege fuer `desktop-1280`, `mobile-390`, `light`, `dark`, `forced-colors`, `reduced-motion`, Browser-Smokes und Performance-Profil-Ableitung. Die 40 sichtbaren Runtime-/UI-Komponenten bringen ihre Performance-Profile mit; `xstate` und `x-utils` werden stattdessen ueber ihre Boundary-Contracts bewertet.
+
+## Handoff
+
+| Paket | Aufgabe |
+|-------|---------|
+| `ER-WP-32` | abgeschlossen: Docs- und Naming-Luecken schliessen |
+| `ER-WP-33` | abgeschlossen: Component-Level-Suites und Fixtures fuer priorisierte Komponenten nachziehen |
+| `ER-WP-34` | abgeschlossen: Public Types und Event Contracts fuer priorisierte Komponenten vervollstaendigen |
+| `ER-WP-35` | abgeschlossen: Long-Tail-Suites, Performance-Profile sowie visuelle und browsernahe Regression priorisieren |
+| `WP-E11-12` | abgeschlossen: Layout-, Display- und Media-Shell-Reife in Katalog, Types, Suites und Performance-Profilen nachziehen |
+
+`WP-E11-17` fuehrt diese Matrix mit dem Regression-Priority-Plan in `xtend.epic11.legacy-long-tail-migration.v1` zusammen. Nach `WP-E12-09` sind `x-tabs`, `x-theme`, `x-button` und `x-menu` aus diesem Long-Tail geschlossen. Seit `WP-E13-05` sind auch `xstate` und `x-utils` als Boundary-Contracts geschlossen: `xstate` als Runtime-Boundary mit Suite, Fixture, Types, Lifecycle Events, Fabric Diagnostics und RMT State Adapter; `x-utils` als Utility-Boundary mit Utility Contract, Import Policy, Fixture und Public Types. Der Gate `node scripts/run_xtend_tests.js component-long-tail-migration --json` prueft diese geschlossene Long-Tail-Linie weiter gegen Plan, Package, Scaffold, Referenzen und Handoff.
+
+Die vollstaendige Matrix liegt in `development/XTend-Component-Catalog-Coverage-Matrix.md`. Die Naming-Konvention liegt in `development/XTend-Component-Catalog-Naming-Konvention.md`. Public Types sind in `docs/public-component-types.md` dokumentiert. Visual-/Browser-Regression ist in `docs/visual-browser-regression.md` dokumentiert. Das maschinenlesbare Coverage-Modul liegt in `catalog/component-catalog-coverage.js`; der Regression-Priority-Plan liegt in `catalog/component-regression-priority.js`; der Long-Tail-Migrationsplan liegt in `catalog/component-long-tail-migration.js`.

package/docs/component-lab.md

@@ -0,0 +1,103 @@
+# XTend Component Lab
+
+Contract: `xtend.docs.component-lab.v1`
+
+Das Component Lab ist ab `WP-E10-12` der lokale Preview- und Inspect-Pfad fuer TypeScript-first XTend-Komponenten. Es verbindet Component Contract v2, RMT Metadata, Fabric/Lane Context, Lifecycle Telemetry, A11y-Profile und Performance-Profile in einem Shell-first RMT-Pilot.
+
+## Pilot-Artefakte
+
+- Plan-Modul: `xtend-builder/preview/component-lab.js`
+- RMT Fixture: `tests/fixtures/rmt-component-lab-pilot.rmt`
+- Contract: `development/XTend-Component-Lab-und-RMT-Inspector-Pilot.md`
+- Gate: `node scripts/run_xtend_tests.js component-lab-rmt-inspector --json`
+
+## Preview Targets
+
+Das Lab startet mit den neun `enterprise-ready` Komponenten aus Epic 10:
+
+- `x-select`
+- `x-checkbox`
+- `x-radio`
+- `x-textarea`
+- `x-status`
+- `x-progress`
+- `x-tooltip`
+- `x-popover`
+- `x-drawer`
+
+Jeder Target-Eintrag verweist auf Runtime, TypeScript Source, RMT Metadata, Contract, A11y, Performance, Fixture Data, Browser-Fixture, Docs, Public Types und Component-Suite.
+
+## RMT Inspector
+
+Der RMT Inspector zeigt im Pilot die Domains:
+
+- `manifest`
+- `adapters`
+- `components`
+- `routes`
+- `schedules`
+- `templates`
+- `diagnostics`
+
+RMT bleibt dabei host-neutral. Der Kernel importiert keine XTend-Klassen und keine XTend-Typen. Execution, DOM-Materialisierung, XRouter-Registrierung und Fabric-Laufzeit bleiben Adapteraufgabe.
+
+## Panels
+
+| Panel | Zweck |
+|-------|-------|
+| `component-preview` | Preview Target, Fixture und Component Contract anzeigen |
+| `rmt-inspector` | RMT-Dokument, Routes, Schedules und Templates inspizieren |
+| `telemetry` | Component Lifecycle Records und Fabric Snapshots sichtbar machen |
+| `a11y` | Rollen, Keyboard, Screenreader-Signale und Pflichtassertions zeigen |
+| `performance` | Budgetklasse, Lane, Hydration Policy und Messpunkte zeigen |
+| `source-links` | Runtime-, TS-, RMT-, Docs-, Types- und Suite-Pfade verlinken |
+
+## Lokaler Gate
+
+```bash
+node scripts/run_xtend_tests.js component-lab-rmt-inspector --json
+```
+
+Der Gate validiert den Plan, das RMT-Fixture, die neun Preview Targets, alle Panels, Inspector-Domains, Package-Metadaten, Runner-Registrierung und Referenzpfade.
+
+## Epic 11 UX Inspector
+
+Ab `WP-E11-13` liegt zusaetzlich der UX Inspector `xtend.epic11.component-lab-ux-inspector.v1` vor.
+
+Artefakte:
+
+- Plan-Modul: `xtend-builder/preview/component-lab-ux-inspector.js`
+- RMT Fixture: `tests/fixtures/rmt-component-lab-ux-inspector.rmt`
+- Contract: `development/XTend-Component-Lab-UX-Inspector.md`
+- Gate: `node scripts/run_xtend_tests.js component-lab-ux-inspector --json`
+
+Der UX Inspector arbeitet ueber 31 `enterprise-ready` Komponenten aus den fuenf Epic-11-Familien:
+
+- Form Controls
+- Feedback und Status
+- Navigation und Routing
+- Overlay und Interaction
+- Layout, Display und Media
+
+Die Panels erweitern den alten Pilot um `ux-family-matrix`, `state`, `styling` und `component-network`. Die Inspector-Domains sind `shell`, `style`, `a11y`, `performance`, `state`, `componentNetwork`, `rmtAuthoring`, `fabricTelemetry`, `diagnostics` und `sourceLinks`.
+
+```bash
+node scripts/run_xtend_tests.js component-lab-ux-inspector --json
+```
+
+Auch diese Schicht bleibt shell-first, lokal und host-neutral. RMT beschreibt Shell, Routes, Templates und Schedules; XTend-Komponenten laufen ueber Adapter ausserhalb des Kernels.
+
+## SurfaceManager Component Lab
+
+Ab `WP-SM-09` gibt es eine Surface-spezifische Lab-Fixture:
+
+- Docs: [SurfaceManager Component Lab](./surface-manager-component-lab.md)
+- Fixture: `tests/fixtures/rmt-surface-manager-component-lab.rmt`
+- Contract: `xtend.surface.component-lab-fixture.v1`
+- Gate: `node scripts/run_xtend_tests.js surface-release-handoff --json`
+
+Die Panels `surface-preview`, `native-rmt-inspector`, `migration-diff`, `quality-gates` und `source-links` zeigen die SurfaceManager-Linie als App-Shell-Lab: native `surfaces[*]`, kompatible `components[*].metadata.surface` Records, `x-surface-manager`, Windows, SidePanels und Overlay-Bridge bleiben zusammen pruefbar, ohne eine produktive `xtend.surface` Runtime zu behaupten.
+
+## Handoff
+
+Das Lab ist noch kein produktiver Browser-Lab-Server. Es ist der gatebare Pilot fuer `WP-E10-13`, in dem die RMT-first Demo-App ohne manuelle Shell-Sonderlogik gebaut wird.

package/docs/component-long-tail-migration.md

@@ -0,0 +1,41 @@
+# Component Long-Tail Migration
+
+- Contract: `xtend.docs.component-long-tail-migration.v1`
+- Plan Contract: `xtend.epic11.legacy-long-tail-migration.v1`
+- Gate Contract: `xtend.epic11.legacy-long-tail-migration-gate.v1`
+- Workpackage: `WP-E11-17`
+
+Diese Seite beschreibt, wie XTend die letzten nicht vollstaendig `enterprise-ready` Komponenten nach Epic 11 behandelt. Der Plan ist bewusst inkrementell: sichtbare Custom Elements werden gegen Shell, Styling, A11y, Performance, Browser-Smokes und Theme-Matrix gehaertet; Infrastruktur- und Utility-Module erhalten Integration-Probes statt kuenstlicher UI-Shells.
+
+Fortschreibung nach `WP-E13-05`: `x-tabs` besitzt ein explizites Performance-Profil und ist nicht mehr Teil des offenen Long-Tail-Plans. `x-theme` besitzt A11y-, Reduced-Motion-, Forced-Colors-, Performance-, Theme-Propagation- und Density-Coverage. `x-button` besitzt Performance-, Interaction-Budget-, Fabric-Measurement- und RMT-Metadaten. `x-menu` besitzt Performance-, Keyboard-, Routing-, Fabric- und RMT-Metadaten. `xstate` besitzt Suite, Fixture, Public Types, Lifecycle Events, Fabric Diagnostics und RMT State Adapter und ist durch [Known Residual Triage](./known-residual-triage.md) als `closed-as-runtime-boundary` bewertet. `x-utils` besitzt Utility Contract, Import Policy, Fixture und Public Types und ist als `closed-as-utility-boundary` bewertet. Es bleiben keine offenen Long-Tail- oder Boundary-Profilentscheidungen aus diesem Plan.
+
+## Lokal pruefen
+
+```bash
+node scripts/run_xtend_tests.js component-long-tail-migration --json
+npm run test:component-long-tail-migration
+```
+
+## Migrationswellen
+
+| Wave | Komponenten | Ziel |
+|------|-------------|------|
+| `wave-1-p0-routing-interaction` | geschlossen: `x-tabs` | Performance-Profil, Browser-Smoke und Theme-Matrix sind abgeschlossen |
+| `wave-2-p1-theme-and-interaction` | geschlossen: `x-theme`, `x-button`, `x-menu` | Performance-, A11y-, Interaction- und Routing-Haertung sind abgeschlossen |
+| `wave-3-infrastructure-and-utility-probes` | geschlossen: `xstate`, `x-utils` | Suite-, Fixture-, Type- und Boundary-Entscheidungen sind abgeschlossen; beide bleiben als nicht-visuelle Runtime-/Utility-Boundaries dokumentiert |
+
+## Regeln fuer Komponentenautoren
+
+- Keine Long-Tail-Komponente wird per Big-Bang auf TypeScript oder neue Shells umgeschrieben.
+- Custom Elements muessen ihre fehlenden Profile zuerst in `components/*`, Docs, Types und Component-Suites nachziehen.
+- Nicht-Custom-Elemente wie `xstate` und `x-utils` werden als Infrastruktur- oder Utility-Grenzen getestet.
+- Browser-Smokes und Theme-Matrix sind nur Pflicht, wenn die Oberflaeche wirklich visuell oder interaktiv ist.
+- RMT beschreibt weiterhin Adapterdaten; der Kernel importiert keine XTend-Typen.
+
+## Quelle
+
+Der Migrationsplan wird aus `catalog/component-catalog-coverage.js` und `catalog/component-regression-priority.js` erzeugt. Die akzeptierte Spezifikation liegt in `development/XTend-Epic11-Legacy-Long-Tail-Migrationsplan.md`.
+
+## RC0 Adoption Update
+
+Seit `WP-E12-15` fasst der [RC0 Adoption Guide](./rc0-adoption-guide.md) diesen Long-Tail-Status als Migration Note fuer Component Authors und App Authors zusammen. Fuer RC0 galten `xstate` und `x-utils` als bekannte, akzeptierte Residuals aus der Known Residual Policy; sie blockierten den lokalen RC0 Review nicht und oeffneten keine Publish Boundary. Seit `WP-E13-05` sind beide Scopes fuer RC1 geschlossen: `xstate` als Runtime-Boundary, `x-utils` als Utility-Boundary.