@ccslabs/xtend 0.1.0-rc.1 → 0.1.2

package/docs/de/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:
+
+- 44 Manifest-Komponenten
+- 44 lokale Source-Dateien
+- 44 Komponenten-Dokumente
+- 44 Component-Level-Suites und Fixtures
+- 44 Public-Type-Artefakte fuer priorisierte Komponenten
+- 43 Komponenten mit erkennbarer A11y-Oberflaeche
+- 42 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-portal`, `x-surface-region`, `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 44 Manifest-Eintraege fuer `desktop-1280`, `mobile-390`, `light`, `dark`, `forced-colors`, `reduced-motion`, Browser-Smokes und Performance-Profil-Ableitung. Die 42 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/de/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/de/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.

package/docs/de/component-platform.md

@@ -0,0 +1,177 @@
+# XTend Component Platform
+
+Contract: `xtend.docs.component-platform.v1`
+
+Diese Seite beschreibt den aktuellen Epic-10-Stand fuer neue XTend-Komponenten. Neue Komponenten werden TypeScript-first geplant, lokal als ESM-Artefakte ausgeliefert und als RMT-first Authoring-Ziele vorbereitet. RMT bleibt dabei Framework-agnostisch: XTend-Komponenten sind `xtend.component` Records, aber der RMT-Kernel importiert keine XTend-Klassen oder Typen.
+
+Seit `WP-E10-16` ist Epic 10 abgeschlossen. Der Release-Handoff liegt in [Epic 10 Release Handoff](./epic10-release-handoff.md), und vollstaendige App-Authoring-Regeln liegen in [RMT-first XTend Apps](./rmt-first-xtend-apps.md). Seit `WP-E11-17` sind die sichtbaren UX-Regeln in [Component UX Authoring](./component-ux-authoring.md), [Component UX App Authoring](./component-ux-app-authoring.md), [Component UX Gates](./component-ux-gates.md) und [Component Long-Tail Migration](./component-long-tail-migration.md) zusammengefuehrt.
+
+## Plattform-Schichten
+
+- TypeScript Source liegt unter `src/components/<tag>/`
+- Runtime-Artefakte bleiben lokale ESM-Dateien unter `components/`
+- Public Types bleiben `.d.ts` Artefakte unter `components/`
+- RMT Metadata liegt als eigenes `ts-rmt` Artefakt vor
+- Fabric, Telemetry, Lanes, A11y und Performance sind Pflichtdomains im `xtend.component.contract.v2`
+- der Builder erzeugt Contract-, Source-, RMT-, A11y-, Performance- und Fixture-Artefakte als Dry-Run
+
+## RMT vNext Component Capability Registry
+
+Die aktuelle RMT-vNext-Linie ergaenzt diese Plattform um
+`xtend.rmt.component-capability-registry.v1`. Die Registry ist die generische
+RMT-Schnittstelle fuer XTend UI: Sie liest `components/manifest.json`,
+`xtend.component.contract.v2`, `xtendRmtMetadata`, `observedAttributes`,
+Events, Slots, Parts, Form-Assoziation, A11y-Profile und Performance-Profile.
+
+Das Ergebnis ist eine Matrix fuer alle 44 public Manifest-Eintraege und 40
+renderbare UI-Komponenten. RMT kann daraus DOM Descriptoren bauen, Events und
+State-Bridges binden und Komponenten lazy ueber Manifest-Pfade importieren.
+Der RMT-Kernel bleibt dabei framework-neutral und importiert keine XTend-
+Klassen oder Typen.
+
+Details stehen in
+[RMT vNext Component Primitives und XTend UI](./rmt-vnext-component-primitives.md).
+
+## P0-Komponentenwelle
+
+WP-E10-08 legt die erste P0-Komponentenwelle als `xtend.epic10.p0-component-wave.v1` fest.
+
+| Komponente | Paket | Schwerpunkt |
+|------------|-------|-------------|
+| `x-select` | `WP-E10-09` | Select Control, Option Slots, Value Events |
+| `x-checkbox` | `WP-E10-09` | Binary Input, checked/indeterminate State |
+| `x-radio` | `WP-E10-09` | Radio Group Coordination und Keyboard Navigation |
+| `x-textarea` | `WP-E10-10` | Long-Form Input, Validation, Counter |
+| `x-status` | `WP-E10-10` | Live Region, Validation Feedback, Scheduler Status |
+| `x-progress` | `WP-E10-10` | Async Progress, Hydration/Task Feedback |
+| `x-tooltip` | `WP-E10-11` | leichte Overlay-Hilfe und describedby Mapping |
+| `x-popover` | `WP-E10-11` | interaktives, verankertes Overlay |
+| `x-drawer` | `WP-E10-11` | App-Shell Navigation und Side Panels |
+
+`x-select`, `x-checkbox`, `x-radio`, `x-textarea`, `x-status`, `x-progress`, `x-tooltip`, `x-popover` und `x-drawer` sind seit `WP-E10-11` als TypeScript-first Referenzlinie umgesetzt und bilden die erste P0-Welle mit `enterprise-ready` Catalog-Status.
+
+## Component Lab und RMT Inspector
+
+`WP-E10-12` legt das Component Lab als Shell-first RMT-Pilot an. Das Lab nutzt `tests/fixtures/rmt-component-lab-pilot.rmt` und das Plan-Modul `xtend-builder/preview/component-lab.js`, um alle neun `enterprise-ready` Komponenten lokal inspizierbar zu machen.
+
+Die Pilot-Oberflaeche besteht aus:
+
+- Component Preview fuer Fixture, Docs, Types und Contract-Pfade
+- RMT Inspector fuer `manifest`, `adapters`, `components`, `routes`, `schedules`, `templates` und `diagnostics`
+- Telemetry Panel fuer `snapshot.componentTelemetry`
+- A11y- und Performance-Hinweisen aus Component Contract v2
+- Source Links auf Runtime, TS Source, RMT Metadata, Fixture, Docs und Suite
+
+Der lokale Gate lautet:
+
+```bash
+node scripts/run_xtend_tests.js component-lab-rmt-inspector --json
+```
+
+## RMT-first Demo-App
+
+`WP-E10-13` liefert mit `tests/browser/fixtures/rmt-first-demo-app-smoke.html` und `xtendrmt/rmt-first-demo-app.rmt` die erste produktive RMT-first Demo-App ohne manuelle Shell. Die Host-/Smoke-Fixture stellt nur einen `data-rmt-host="rmt-first-demo"` Root, den lokalen XTend Loader, das lokale Manifest und die RMT Runtime bereit.
+
+Die App Shell, Navigation, Routen, Seiten-Templates, Component Records, Schedules, Fabric Lanes und Diagnostics werden aus dem RMT-Dokument gerendert. Die Demo nutzt die komplette Epic-10 P0-Welle: `x-select`, `x-checkbox`, `x-radio`, `x-textarea`, `x-status`, `x-progress`, `x-tooltip`, `x-popover` und `x-drawer`.
+
+Der lokale Gate lautet:
+
+```bash
+node scripts/run_xtend_tests.js rmt-first-demo-app --json
+```
+
+## Existing Component Metadata
+
+`WP-E10-14` zieht bestehende priorisierte Komponenten als `js-legacy` Contract Overlay in die RMT/Fabric-Linie. Der maschinenlesbare Katalog liegt in `catalog/epic10-existing-component-metadata.js` und nutzt die Migration Strategy `js-legacy-contract-overlay-no-runtime-rewrite`.
+
+Die Zielkomponenten sind `x-router`, `x-link`, `x-input`, `x-form`, `x-modal`, `x-dialog`, `x-tabs`, `x-toast` und `x-alert`. Jede Komponente erhaelt Contract-v2-, RMT-, Fabric-, Telemetry-, Lane-, A11y- und Performance-Metadata, ohne dass die Runtime in diesem Paket umgebaut werden muss.
+
+Der lokale Gate lautet:
+
+```bash
+node scripts/run_xtend_tests.js existing-component-metadata --json
+```
+
+## Epic 10 Platform Gates
+
+`WP-E10-15` buendelt die Plattformregeln als `xtend.epic10.platform-gates.v1`. Der maschinenlesbare Plan liegt in `catalog/epic10-platform-gates.js` und verbindet Component Contract v2, Existing Component Metadata, RMT-first Demo-App, Browser-Smokes, A11y, Performance und Visual Regression.
+
+Der Fast-PR-Pfad enthaelt `component-contract-v2`, `epic10-p0-component-wave`, `component-lab-rmt-inspector`, `rmt-first-demo-app`, `existing-component-metadata`, `browser`, `a11y-hydration`, `screenreader-signals`, `motion-contrast`, `regression-priority` und `references`. Release-only Performance bleibt ueber `fabric-performance-measurements`, `performance-regression` und `hydration-policy` getrennt.
+
+Der lokale Gate lautet:
+
+```bash
+node scripts/run_xtend_tests.js epic10-platform-gates --json
+```
+
+## Epic 10 Release Handoff
+
+`WP-E10-16` finalisiert die kanonische Guide-Struktur und den Abschlusscontract `xtend.epic10.release-handoff.v1`. Der maschinenlesbare Plan liegt in `catalog/epic10-release-handoff.js`.
+
+Die kanonische Component-Fabric-Boundary ist `adapter-injection-via-xtend-component-resolveFabricContext`. `window.XTendFabric` bleibt Host-Komfort- und Enterprise-Integrationsflaeche, aber Komponenten beziehen Fabric-, Lane- und Fiber-Kontext ueber den `xtend.component` Adapter.
+
+Der lokale Gate lautet:
+
+```bash
+node scripts/run_xtend_tests.js epic10-release-handoff --json
+```
+
+## Epic 11 Enterprise UX Handoff
+
+`WP-E11-18` finalisiert die sichtbare Component-UX-Reife als `xtend.epic11.enterprise-ux-handoff.v1`. Der maschinenlesbare Plan liegt in `catalog/epic11-enterprise-ux-handoff.js`.
+
+Der Abschlussmodus lautet `completed-with-accepted-long-tail-handoff`: Shell, Styling, Runtime-A11y, Performance, Component Network, RMT Shell Authoring, Component Lab, Browser-Smokes, Theme-Matrix und Authoring Guides sind als Produktlinie akzeptiert. Nach `WP-E12-09` sind `x-tabs`, `x-theme`, `x-button` und `x-menu` runtime-seitig geschlossen; `xstate` besitzt Suite, Fixture, Types und Adapter-Boundary-Probe; `x-utils` besitzt Utility Contract, Import Policy, Fixture und Types. Seit `WP-E13-05` sind `xstate` als Runtime-Boundary und `x-utils` als Utility-Boundary fuer RC1 geschlossen.
+
+Der lokale Gate lautet:
+
+```bash
+node scripts/run_xtend_tests.js epic11-enterprise-ux-handoff --json
+```
+
+## RMT First-Class Support
+
+Jede neue Komponente muss als RMT Component Record authorbar sein:
+
+- Adapter: `xtend.component`
+- Template-Modus: `dom_descriptor`
+- Event Binding: `dom-event-to-rmt-command`
+- Pflicht-Schedules: `component.visible.mount`, Hydration Schedule und `diagnostics.snapshot`
+- Kernel Boundary: `no-rmt-kernel-import-of-xtend-types`
+
+RMT beschreibt also Komponente, Props, Attribute, Slots, Events, Hydration und Schedule. XTend fuehrt die Custom Elements lokal aus.
+
+## Fabric, Telemetry und Lanes
+
+Neue Komponenten muessen Fabric-Kontext aufnehmen koennen. Dazu gehoeren:
+
+- `@xtend-fabric` Boundary
+- Lifecycle-Operationen `mount`, `hydrate`, `render`, `update`, `event`, `error`, `unmount`
+- Telemetry Snapshot `xtend.fabric.telemetry-snapshot.v1`
+- Backpressure-faehige Messpunkte
+- deterministische Lane-Precedence aus RMT, Component Metadata, Fabric Override und Blueprint Default
+
+## A11y und Performance
+
+A11y ist kein nachgelagerter Test. Form Controls brauchen Labels, Error Regions, Keyboard-Verhalten und Screenreader-Signale. Feedback-Komponenten brauchen Live Regions und non-color Statussignale. Overlays brauchen Escape, Fokus-Rueckgabe und Reduced Motion.
+
+Performance ist ebenfalls Contract-Bestandteil. Jede Komponente muss Budgetklasse, Lane, Hydration Policy und kritische Messpunkte deklarieren.
+
+## Lokale Gates
+
+```bash
+node scripts/run_xtend_tests.js component-ux-authoring-docs --json
+node scripts/run_xtend_tests.js rmt-vnext-component-primitives --json
+node scripts/run_xtend_tests.js component-long-tail-migration --json
+node scripts/run_xtend_tests.js epic11-enterprise-ux-handoff --json
+node scripts/run_xtend_tests.js component-shell-theme-matrix --json
+node scripts/run_xtend_tests.js component-ux-browser-smokes --json
+node scripts/run_xtend_tests.js epic10-p0-component-wave --json
+node scripts/run_xtend_tests.js component-lab-rmt-inspector --json
+node scripts/run_xtend_tests.js rmt-first-demo-app --json
+node scripts/run_xtend_tests.js existing-component-metadata --json
+node scripts/run_xtend_tests.js epic10-platform-gates --json
+node scripts/run_xtend_tests.js epic10-release-handoff --json
+node scripts/run_xtend_tests.js builder-typescript-blueprint --json
+node scripts/run_xtend_tests.js component-contract-v2 --json
+node scripts/run_xtend_tests.js references --json
+```

package/docs/de/component-ux-app-authoring.md

@@ -0,0 +1,123 @@
+# Component UX App Authoring
+
+Docs Contract: `xtend.docs.component-ux-app-authoring.v1`
+
+Dieser Guide richtet sich an App-Autorinnen und App-Autoren, die
+XTend-Komponenten in RMT-first Apps einsetzen. Die App kann vollstaendig in RMT
+vNext geschrieben werden; XTend liefert lokale Web Components und XTendRMT
+orchestriert Shell, Routes, Templates, Schedules und Diagnostics.
+
+## Grundregeln
+
+- Die App Shell rendert `shell-first`.
+- XTend-Komponenten werden in vNext als `surface ... component x-*`
+  beschrieben und in `xtend.component` Records kompiliert.
+- XRouter wird ueber den Router-Adapter angebunden.
+- Templates verwenden bevorzugt `dom_descriptor` als generierten Output.
+- Events werden mit `on ... -> action ...` gebunden.
+- Hydration, Fabric-Lane, Fiber und Diagnostics bleiben schedulebare Metadata.
+- Der RMT-Kernel importiert keine XTend-Klassen oder XTend-Typen.
+
+Boundary:
+
+```text
+no-rmt-kernel-import-of-xtend-types
+```
+
+## Minimaler Component-Surface
+
+```rmt
+template settings.feedback {
+  state settings.feedback.status type string initial "ready"
+
+  selector settings.feedback.view from state settings.feedback.status {
+    output StatusView
+  }
+
+  portal surface.root root "#settings-root" layer surface
+
+  surface settings.feedback.status kind card component x-status {
+    source selector settings.feedback.view
+    portal surface.root
+
+    lane visible weight 80 {
+      mount x-status
+      hydrate feedback-status from selector settings.feedback.view
+    }
+  }
+}
+```
+
+Der Output enthaelt weiterhin `xtend.component`, A11y-, Style-, Schedule- und
+Fabric-Metadaten. Geschrieben wird aber die vNext-Quelle.
+
+## App-Shell-Muster
+
+```rmt
+template dashboard.app {
+  state dashboard.theme type string initial "dark"
+  state dashboard.density type string initial "compact"
+  state dashboard.motion type string initial "reduced-motion"
+
+  action dashboard.refresh {
+    emit dashboard.refresh.requested with action dashboard.refresh
+  }
+
+  portal surface.root root "#app-root" layer surface
+
+  surface dashboard.page kind page component x-section {
+    source state dashboard.theme
+    portal surface.root
+
+    lane visible weight 80 {
+      hydrate dashboard-shell from endpoint xtendrmt.route.render
+      hydrate settings-feedback-status from endpoint xtendrmt.component.mount
+    }
+
+    on click target refresh-button -> action dashboard.refresh {
+      payload theme from state.dashboard.theme
+      payload density from state.dashboard.density
+      payload motion from state.dashboard.motion
+    }
+  }
+}
+```
+
+## UX-Regeln fuer Apps
+
+| Dimension | App-Regel |
+| --- | --- |
+| Shell | Hostseite stellt nur den Root, Loader, Manifest und RMT Runtime bereit |
+| Routing | Routen kommen aus RMT und werden ueber XRouter aktiviert |
+| Theme | `light`, `dark`, `high-contrast` und `forced-colors` bleiben App-States |
+| Motion | `reduced-motion` muss bis in Overlays, Feedback und Media sichtbar sein |
+| Density | `comfortable`, `compact` und `dense` duerfen Layout nicht brechen |
+| A11y | Route Announcements, Live Regions, Error Regions und Focus Restore sind Teil der App |
+| Performance | Hydration Policies und Fabric-Lanes sind Schedule-Daten, keine Host-Sonderlogik |
+
+## Gates fuer App-Autoren
+
+```bash
+node scripts/run_xtend_tests.js rmt-first-class-app --json
+node scripts/run_xtend_tests.js rmt-shell-authoring-ux --json
+node scripts/run_xtend_tests.js component-ux-browser-smokes --json
+node scripts/run_xtend_tests.js component-shell-theme-matrix --json
+node scripts/run_xtend_tests.js browser --json
+```
+
+Fuer PRs ist der gemeinsame schnelle Pfad:
+
+```bash
+npm run test:pr
+```
+
+## Wann ein App-Pfad reif ist
+
+Ein RMT-first XTend App-Pfad gilt als reif, wenn:
+
+- die Shell nicht manuell aus statischem XTend-Markup zusammengesetzt wird,
+- Komponenten ueber `xtend.component` Records kommen,
+- Route, Theme, Motion, Density und Hydration in RMT sichtbar sind,
+- Browser-Smokes die Kernjourneys abdecken,
+- die Component Shell Theme Matrix nicht bricht,
+- keine externen CDN- oder Importmap-Abhaengigkeiten eingefuehrt werden.

package/docs/de/component-ux-authoring.md

@@ -0,0 +1,96 @@
+# Component UX Authoring
+
+Docs Contract: `xtend.docs.component-ux-authoring.v1`
+
+Dieser Guide ist die kanonische Arbeitsanleitung fuer XTend-Komponentenautorinnen und -autoren nach `WP-E11-16`. Er uebersetzt die Epic-11-Vertraege in konkrete Regeln fuer neue und modernisierte Web Components.
+
+## Grundsatz
+
+Eine XTend-Komponente ist erst dann UX-reif, wenn ihre sichtbare Shell, ihr Styling, ihre A11y, ihre Performance, ihr Component Network, ihre RMT-Autorierbarkeit und ihre browsernahen Smokes zusammenpassen. Einzelne Komponenten duerfen klein bleiben, aber ihre Contracts muessen vollstaendig sein.
+
+Die technische Boundary bleibt:
+
+```text
+no-rmt-kernel-import-of-xtend-types
+```
+
+RMT darf XTend-Komponenten schedulen, rendern und konfigurieren. Der RMT-Kernel importiert aber keine XTend-Klassen oder XTend-Typen.
+
+## Pflichtcontracts
+
+| Contract | Zweck | Gate |
+| --- | --- | --- |
+| `xtend.component.shell.v1` | Root, DOM-Modus, States, Slots, Parts, Focus und Lifecycle | `component-shell-contract` |
+| `xtend.component.styling.v1` | Tokens, CSS Parts, Variants, Size, Density und Theme Bridges | `component-styling-contract` |
+| `xtend.component.runtime-a11y.v1` | Keyboard, Focus, ARIA, Screenreader und High Contrast | `runtime-a11y-contract` |
+| `xtend.component.ux-performance.v1` | Shell-, Hydration-, Render-, Event- und Interaction-Budgets | `component-ux-performance` |
+| `xtend.component.network.v1` | Events, Commands, Form Association, Router Context und Feedback | `component-network-contract` |
+| `xtend.rmt.shell-authoring.v1` | Shell, Style, A11y, Variants, Commands und Events in RMT | `rmt-shell-authoring-ux` |
+| `xtend.epic11.component-lab-ux-inspector.v1` | Preview, RMT Inspector, State, A11y, Performance und Source Links | `component-lab-ux-inspector` |
+| `xtend.epic11.component-ux-browser-smokes.v1` | reale UX-Journeys fuer priorisierte Familien | `component-ux-browser-smokes` |
+| `xtend.epic11.component-shell-theme-matrix.v1` | Theme, Motion, Density, Viewport und Visual States | `component-shell-theme-matrix` |
+
+## Authoring-Reihenfolge
+
+1. Familie waehlen: `form-controls`, `feedback-status`, `navigation-routing`, `overlay-interaction` oder `layout-display-media`.
+2. Shell Contract definieren: Root, Slots, States, Parts, Focus und Lifecycle festlegen.
+3. Styling als API behandeln: Tokens, Parts, Variants, Size und Density dokumentieren.
+4. A11y zuerst modellieren: Keyboard, Labels, ARIA, Live Regions, Focus Restore und Screenreader-Signale festlegen.
+5. Performance-Profil setzen: Lane, Hydration Policy, kritische Messpunkte und Budgetklasse festlegen.
+6. Component Network beschreiben: Events, Commands, Form Association, Router Context oder Feedback-Kanaele definieren.
+7. RMT-Authoring ergaenzen: `xtend.component` Record, `dom_descriptor`, Schedules, Commands und Events pflegen.
+8. Fabric-Kontext akzeptieren: Lane, Fiber und Telemetry ueber Adapterdaten aufnehmen.
+9. Component Lab sichtbar machen: Preview, Docs, Types, Fixture, State, A11y und Performance verlinken.
+10. Browser- und Theme-Matrix pruefen: lokale Smokes und Shell-Matrix laufen lassen.
+
+## Familienregeln
+
+| Familie | Minimum |
+| --- | --- |
+| Form Controls | Label, Help Text, Error Region, Required/Invalid, Form Association, Value Event, Keyboard Entry |
+| Feedback/Status | Live Region, Role, Tone, Dismiss/Timeout, non-color Status, Reduced Motion |
+| Navigation/Routing | Active State, `aria-current`, Keyboard Activation, Route Announcement, Focus Restore, Tablist ARIA und roving `tabindex` |
+| Overlay/Interaction | Initial Focus, Focus Trap, Escape, Focus Restore, Scroll Lock, Reduced Motion |
+| Layout/Display/Media | Responsive Slots, Stable Layout, Lazy/Visible Hydration, Media Shell, Code/Display Semantics |
+
+## Theme Matrix
+
+Jede priorisierte Shell muss in der Component Shell Theme Matrix darstellbar bleiben:
+
+- Themes: `light`, `dark`, `high-contrast`, `forced-colors`
+- Motion: `default-motion`, `reduced-motion`
+- Density: `comfortable`, `compact`, `dense`
+- Viewports: `desktop-1280`, `tablet-768`, `mobile-390`
+
+Der Gate prueft aktuell `360` Shell-Kombinationen:
+
+Seit `WP-E12-03` ist `x-tabs` Teil der Navigation/Routing-Matrix und muss Arrow-Key, `Home`, `End`, `aria-controls`, `role=tabpanel`, `aria-selected` und sichtbaren Fokus in Browser-Smokes und Theme-Matrix halten.
+
+```bash
+node scripts/run_xtend_tests.js component-shell-theme-matrix --json
+```
+
+## Lokale Gates
+
+```bash
+node scripts/run_xtend_tests.js component-shell-contract --json
+node scripts/run_xtend_tests.js component-styling-contract --json
+node scripts/run_xtend_tests.js runtime-a11y-contract --json
+node scripts/run_xtend_tests.js component-ux-performance --json
+node scripts/run_xtend_tests.js component-network-contract --json
+node scripts/run_xtend_tests.js rmt-shell-authoring-ux --json
+node scripts/run_xtend_tests.js component-lab-ux-inspector --json
+node scripts/run_xtend_tests.js component-ux-browser-smokes --json
+node scripts/run_xtend_tests.js component-shell-theme-matrix --json
+node scripts/run_xtend_tests.js references --json
+```
+
+## Definition of Done
+
+- Docs, `.d.ts`, Fixture, Component Suite und RMT Metadata existieren.
+- Shell, Styling, A11y, Performance und Network Contracts sind sichtbar.
+- Events sind `bubbles: true` und `composed: true`, wenn Hosts oder RMT sie konsumieren sollen.
+- Commands sind deklarierbar und nicht nur private Methoden.
+- Theme, Density und Motion sind nicht hart im Shadow DOM versteckt.
+- Browser-Smoke oder Theme-Matrix deckt den relevanten sichtbaren Pfad ab.
+- Kein neuer Pfad fuehrt eine harte XTend-Abhaengigkeit in den RMT-Kernel ein.

package/docs/de/component-ux-gates.md

@@ -0,0 +1,45 @@
+# Component UX Gates
+
+Docs Contract: `xtend.docs.component-ux-gates.v1`
+
+Diese Seite beschreibt die lokale Gate-Kette fuer Epic 11. Sie verbindet Authoring Guides, Browser-Smokes, Theme-Matrix, RMT Shell Authoring, Component Lab und Reference-Gates.
+
+## Gate-Gruppen
+
+| Gruppe | Gate | Zweck |
+| --- | --- | --- |
+| Foundation | `component-shell-contract` | Component Shell Contract `xtend.component.shell.v1` |
+| Foundation | `component-styling-contract` | Styling Contract `xtend.component.styling.v1` |
+| Foundation | `runtime-a11y-contract` | Runtime A11y `xtend.component.runtime-a11y.v1` |
+| Foundation | `component-ux-performance` | Performance Profile `xtend.component.ux-performance.v1` |
+| Foundation | `component-network-contract` | Component Network `xtend.component.network.v1` |
+| RMT | `rmt-shell-authoring-ux` | RMT Shell Authoring `xtend.rmt.shell-authoring.v1` |
+| Lab | `component-lab-ux-inspector` | Component Lab UX Inspector `xtend.epic11.component-lab-ux-inspector.v1` |
+| Browser | `component-ux-browser-smokes` | Browser UX Smokes `xtend.epic11.component-ux-browser-smokes.v1` |
+| Visual | `component-shell-theme-matrix` | Component Shell Theme Matrix `xtend.epic11.component-shell-theme-matrix.v1` |
+| Docs | `component-ux-authoring-docs` | Component UX Authoring Docs `xtend.epic11.component-ux-authoring-docs.v1` |
+| Migration | `component-long-tail-migration` | Legacy Long-Tail Migration `xtend.epic11.legacy-long-tail-migration.v1` |
+| Handoff | `epic11-enterprise-ux-handoff` | Epic 11 Enterprise UX Handoff `xtend.epic11.enterprise-ux-handoff.v1` |
+| References | `references` | Dokumentations- und Demo-Referenzpfade |
+
+## Schneller Epic-11-Check
+
+```bash
+node scripts/run_xtend_tests.js component-network-contract rmt-shell-authoring-ux form-controls-ux feedback-status-ux navigation-routing-ux overlay-interaction-ux layout-display-media-ux component-lab-ux-inspector component-ux-browser-smokes component-shell-theme-matrix component-ux-authoring-docs component-long-tail-migration epic11-enterprise-ux-handoff references --json
+```
+
+## PR-Gate
+
+Der PR-Gate enthaelt die Component-UX-Doku, damit neue Guides nicht neben der produktiven Gate-Kette veralten:
+
+```bash
+npm run test:pr
+```
+
+## Release-Hinweis
+
+`component-shell-theme-matrix` ist noch kein Screenshot-Diff-Runner. Es ist der deterministische, lokale Contract fuer spaetere visuelle Snapshot-Automation. Bis echte Snapshots angeschlossen sind, bleibt diese Matrix die verbindliche Quelle fuer Theme-, Motion-, Density- und Viewport-Pflichten.
+
+## Handoff
+
+Nach `WP-E11-18` ist Epic 11 im Modus `completed-with-accepted-long-tail-handoff` abgeschlossen. Die Legacy Long-Tail Migration ist als Plan gatebar; offene Umsetzungen bleiben bewusst in Wellen priorisiert.