@ccslabs/xtend 0.1.0-rc.1 → 0.1.2

package/docs/de/rmt-state-selector-runtime.md

@@ -0,0 +1,47 @@
+# RMT State Selector Runtime
+
+- Contract: `xtend.epic18.rmt-state-selector-runtime.v1`
+- Fixture: `tests/fixtures/rmt-state-selector-runtime.rmt`
+- Runtime: `xtendrmt/rmt-state-selector-runtime.js`
+- Types: `xtendrmt/rmt-state-selector-runtime.d.ts`
+- Local Gate: `node scripts/run_xtend_tests.js rmt-state-selector-runtime --json`
+- Workpackage: `WP-E18-07`
+
+Die State Selector Runtime macht App-Zustand fuer RMT Templates deklarativ
+nutzbar. Sie definiert typisierte State Records, wertet Selectors und derived
+Values aus, dispatcht Reducer-Commands und erzeugt ein Render-Context-Model fuer
+den DOM Descriptor Renderer aus `WP-E18-05`/`WP-E18-06`.
+
+## Primitives
+
+| Primitive | Zweck |
+|-----------|-------|
+| `state` | typisierte App-Zustaende wie Collection, Selection, Filter, UI und Loading |
+| `selector` | abgeleitete, wiederverwendbare Sichten auf State, zum Beispiel gefilterte Listen |
+| `derive` | einzelne derived Values wie Selection Count oder Detail Label |
+| `reducer` | Command-getriebene State-Aenderungen ohne produktlokale Mini-Frameworks |
+| `xstateBridge` | injizierte Host-Bridge zu `xstate`, ohne Runtime-Import |
+| `preservePatchPlan` | unterscheidet strukturelle Rerenders von Attribut-/Component-State-Sync |
+| `stateBindings` | aktualisiert Attribute, Klassen und Properties bestehender DOM-Knoten |
+
+## Preserve-Regeln
+
+States mit `preserve: "attribute-sync"` oder `preserve: "component-state"`
+duerfen DOM-Inseln erhalten. Selection- oder UI-Aenderungen koennen dadurch
+Attribute wie `aria-selected`, Klassen wie `is-selected` oder Component
+Properties synchronisieren, ohne Listen neu zu materialisieren.
+
+Strukturelle Selectors, zum Beispiel `selector.filtered-items`, duerfen dagegen
+einen Rerender anfordern. Filter- oder Collection-Aenderungen bleiben dadurch
+korrekt, waehrend reine Selection-Aenderungen Fokus, Scroll und Component
+Instanzen erhalten koennen.
+
+## XState Boundary
+
+Die Runtime importiert `xstate` nicht. Host-Code kann ein kompatibles Ziel mit
+`set`, `setState`, `get`, `getState` oder `subscribe` injizieren. Die Bridge
+spiegelt State-, Selector- und Derived-Keys in dieses Ziel, bleibt aber auch mit
+einem internen Snapshot lauffaehig.
+
+`WP-E18-08` kann darauf Actions, Effects, DataSources und Resource Runtime
+aufbauen.

package/docs/de/rmt-surface-resource-graph-runtime.md

@@ -0,0 +1,92 @@
+# RMT Surface Resource Graph Runtime
+
+- Contract: `xtend.epic18.rmt-surface-resource-graph-runtime.v1`
+- Gate: `node scripts/run_xtend_tests.js rmt-surface-resource-graph-runtime --json`
+- Workpackage: `WP-E18-10`
+- Handoff: `WP-E18-11`
+
+## Ziel
+
+Die Surface Resource Graph Runtime macht dynamische App-Layouts in RMT als
+generische Plattformfaehigkeit modellierbar. Entwickler koennen eigene
+Surface-Modelle aus beliebigen Records erzeugen, Bounds und Fokus verwalten,
+Overlays ueber Portale stapeln und instanzgebundene Ressourcen aufraeumen,
+ohne eine produktlokale Registry oder Shell-spezifische Repaint-Logik zu
+schreiben.
+
+Der Media Manager bleibt dabei nur Proof-of-Need. Die Runtime kennt keine
+Produkt-Surface-Liste und importiert keine XTend-Komponenten.
+
+## Keyed Surface Repeater
+
+`surface` Definitionen koennen `source`, `repeat` und `key` deklarieren. Die
+Runtime erzeugt daraus stabile Surface-Instanzen wie
+`surface.workspace:alpha`. Beim erneuten Materialisieren mit denselben Keys
+bleiben Runtime-Zustand, Bounds, Fokusreihenfolge, Ressourcenstatus und
+Persistenzdaten erhalten.
+
+Wichtige Operationen:
+
+- `materialize(recordsBySource)`: erzeugt oder reused Surface-Instanzen.
+- `openSurface(id)`: oeffnet eine Instanz und uebernimmt ihre Ressourcen.
+- `minimizeSurface(id)`: minimiert, ohne DOM- oder Ressourcenstatus zu
+  verwerfen.
+- `restoreSurface(id)`: stellt Bounds und offenen Zustand wieder her.
+- `closeSurface(id)`: schliesst nach Policy, ohne zwingend zu zerstoeren.
+- `destroySurface(id)`: gibt instanzgebundene Ressourcen frei und trennt den
+  Event-Owner.
+
+## Portal Layer Stack
+
+Portale beschreiben Layer- und Policy-Grenzen fuer Tooltips, Toasts, Popovers,
+Lightboxes, Menus, Dialoge und weitere Overlay-Arten. `openOverlay` legt
+Overlay-Instanzen in ihrem Portal ab und vergibt eine stabile Stack-Reihenfolge
+ueber `zIndexStart` und `zStep`. `closeTopOverlay` schliesst den obersten
+dismissible Overlay-Eintrag pro Portal oder global.
+
+Die Portal-Policy ist generisch:
+
+- `stacked` fuer normale App-Flächen.
+- `modal` und `nonmodal` fuer blockierende und nicht blockierende Overlays.
+- `toast-region` fuer Feedback-Layer.
+- `clipping-escape` fuer Viewport-feste Layer wie Tooltips.
+
+## Resource Ownership
+
+Ressourcen werden ueber den WP-E18-08 Resource Manager injiziert. Die Surface
+Runtime besitzt keine eigenen Adapter, sondern ruft `acquireMany` und
+`releaseOwner` pro Surface- oder Overlay-Instanz auf.
+
+Dadurch gelten klare Regeln:
+
+- Minimize erhaelt Ressourcen und Component-State.
+- Close kann Ressourcen optional freigeben.
+- Destroy gibt Ressourcen der betroffenen Instanz frei.
+- Overlay-Close gibt Overlay-Ressourcen frei.
+- Destroy einer Surface ruft zusaetzlich `eventRuntime.detachOwner(owner)` auf.
+
+## Persistenz
+
+`persistSnapshot` liefert einen Snapshot mit Surface-Zustand, Bounds, Fokus,
+offenen Overlays und Portal-Metadaten. Ein optionaler Persistence Adapter kann
+diesen Snapshot speichern. `hydrateSnapshot` spielt ihn spaeter in bereits
+materialisierte Instanzen zurueck.
+
+## Grenzen
+
+- Keine Produkt-Surface-Taxonomie als Framework-Default.
+- Keine produktlokale Registry-Repaint-Pflicht.
+- Keine XTend-Component-Imports im RMT Kernel.
+- Normale UI bleibt bei DOM Descriptoren und Component Templates; HTML-String-
+  Renderer bleiben eine separate Trusted-DOM-Grenze.
+
+## Gates
+
+```bash
+node scripts/run_xtend_tests.js rmt-surface-resource-graph-runtime --json
+node scripts/run_xtend_tests.js rmt-app-platform-authoring rmt-dom-descriptor-renderer rmt-component-template-primitives rmt-state-selector-runtime rmt-action-effect-runtime rmt-event-routing-runtime rmt-surface-resource-graph-runtime --json
+```
+
+`WP-E18-11` erweitert darauf aufbauend Scaffold, Linter, LSP und Diagnostics,
+damit Surface-, Overlay-, Portal- und Resource-Graphen schon beim Authoring
+sichtbar und pruefbar werden.

package/docs/de/rmt-tooling-release-gates.md

@@ -0,0 +1,77 @@
+# RMT Tooling Release Gates
+
+- Status: produktiv vorbereitet ab `WP-E14-15`
+- Contract: `xtend.epic14.rmt-tooling.v1`
+- Gate Record Contract: `xtend.epic14.rmt-tooling-gate.record.v1`
+- Report Contract: `xtend.epic14.rmt-tooling-report.v1`
+- Lokaler Gate: `node scripts/run_xtend_tests.js epic14-rmt-tooling --json`
+
+## Zweck
+
+Die RMT Tooling Gates buendeln den nativen `.rmt` Authoring-Pfad fuer Pull Requests, Release-Kandidaten und AI-Agenten. Sie pruefen nicht die RMT Runtime, sondern die Sprachebene: Source Model, Parser, Semantic Graph, Linter, CLI, Completion, Navigation, LSP, Code Actions, Agent Report, Editor Packaging, Regression Fixtures und Dokumentation.
+
+## Befehle
+
+```bash
+npm run test:rmt-linter
+npm run test:rmt-language-server
+npm run test:pr:rmt
+npm run test:pr:rmt:report
+npm run test:rmt-tooling
+npm run test:rmt-tooling:report
+node scripts/run_xtend_tests.js epic14-rmt-tooling --json
+```
+
+`npm run test:pr:rmt` ist ein optionaler Zusatzgate fuer RMT-nahe Pull Requests. Der globale PR-Gate bleibt dadurch schlank, kann aber bei DSL-, Linter-, LSP- oder Agent-Report-Aenderungen gezielt erweitert werden.
+
+`npm run test:rmt-tooling` ist der Release-Bundle-Gate fuer Epic 14. Er laeuft ohne Netzwerk und nutzt ausschliesslich repo-lokale Fixtures, Docs und Tooling-Module.
+
+## Release-Bundle
+
+Das Release-Bundle umfasst:
+
+- `rmt-source-model`
+- `rmt-parser`
+- `rmt-semantic-graph`
+- `rmt-linter-rules`
+- `rmt-linter-cli`
+- `rmt-completions`
+- `rmt-navigation`
+- `rmt-language-server`
+- `rmt-code-actions`
+- `rmt-agent-report`
+- `rmt-editor-packaging`
+- `rmt-language-regression`
+- `rmt-tooling-docs`
+
+## Package Surface
+
+Die Package-Surface fuer RMT Tooling ist ueber `package.json` exportiert. Relevant fuer Tooling-Konsumenten sind insbesondere:
+
+- `xtend/rmt-language/source-model`
+- `xtend/rmt-language/parser`
+- `xtend/rmt-language/diagnostics`
+- `xtend/rmt-language/completions`
+- `xtend/rmt-language/code-actions`
+- `xtend/rmt-language-server`
+- `xtend/rmt-linter/cli`
+- `xtend/rmt-linter/reporter`
+- `xtend/rmt-language/snippets`
+
+Der Gate `epic14-rmt-tooling` prueft, dass diese Surface nicht unbemerkt driftet und dass `xtend.epic14RmtTooling` die aktiven Scripts, Suites und Handoff-Metadaten enthaelt.
+
+## CI-Handoff
+
+Die globale Full-Release-Linie bleibt:
+
+```bash
+npm run test:release:full:report
+```
+
+RMT Tooling ist zusaetzlich als eigener Release-Gate in `xtend.releaseGates` registriert:
+
+```bash
+npm run test:rmt-tooling
+```
+
+Damit koennen Release-Owner, CI-Systeme und AI-Agenten die RMT-Sprachwerkzeuge separat nachweisen, ohne den RMT Kernel mit XTend Runtime-Typen zu koppeln.

package/docs/de/rmt-vnext-authoring.md

@@ -0,0 +1,170 @@
+# RMT vNext Authoring Guide
+
+- Contract: `xtend.rmt.vnext-release-handoff.v1`
+- Syntax Contract: `xtend.rmt.vnext.grammar.v1`
+- Core Output: `xtend.rmt.core-format.vnext.v1`
+
+RMT vNext ist die menschenfreundliche Syntax fuer XTend Apps. Du kannst eine
+vollstaendige UI-Shell in RMT schreiben: State, Selectors, DataSources,
+Actions, Events, Portals, Overlays, Resources, Surfaces und Fabric-Lanes
+liegen in einer `.rmt` Quelle und werden deterministisch in Core- und
+Kernel-Records kompiliert.
+
+## Grundform
+
+```rmt
+template media.manager {
+  state selectedItem type object initial null
+
+  selector visibleItems from datasource library {
+    output card-list
+  }
+
+  datasource library from fixture records.media-items {
+    contract "media.item.v1[]"
+  }
+
+  action select-item {
+    input id string
+    reduce state.selectedItem = input.id
+    emit media.item.selected with action select-item
+  }
+
+  portal app root "#app-root" layer surface
+
+  surface library kind workspace component x-cards {
+    repeat from selector visibleItems
+    key item.id
+    portal app
+
+    lane visible weight 80 {
+      hydrate x-cards from selector visibleItems
+    }
+
+    on card-click target item -> action select-item {
+      payload id from item.id
+    }
+  }
+}
+```
+
+Die wichtigsten Bausteine:
+
+| Syntax | Zweck |
+| --- | --- |
+| `template` | gruppiert eine App- oder Dokument-Shell |
+| `state` | beschreibt persistenten oder transienten App-Zustand |
+| `selector` | leitet UI-nahe Views aus State oder DataSources ab |
+| `datasource` | bindet Fixture-, Endpoint-, SSE- oder Worker-Quellen an |
+| `action` | beschreibt User- und Systemaktionen mit Reducern und Effects |
+| `on ... -> action ...` | routet DOM- oder Custom-Events in Actions |
+| `portal` | benennt Mount-Ziele fuer Surfaces und Overlays |
+| `surface` | beschreibt sichtbare UI-Objekte, Listen, Panels oder Pages |
+| `overlay` | beschreibt Toasts, Dialoge, Menues, Popovers und Lightboxes |
+| `resource` | beschreibt Besitz, Import, Stream, Timer und Cleanup |
+| `lane` | steuert Prioritaet, Scheduling und Backpressure |
+| `mount`, `hydrate`, `prewarm`, `dispose` | Lifecycle-Operationen |
+| `when` | deklarative Conditions ohne Funktionsaufrufe oder Eval |
+| `slot` | Composition innerhalb einer Operation |
+| `trust boundary` und `sanitize` | Security-Policy fuer unsichere Daten |
+| `stream` | inkrementelle Streaming-Operation |
+
+## App Shell nur in RMT
+
+Eine vNext-App soll nicht zwischen RMT, App-Platform-JSON und Host-Code
+zerfallen. RMT ist der Authoring-Ort fuer:
+
+- Route- und Shell-Struktur
+- sichtbare Surfaces und Overlay-Portale
+- State- und Selector-Modell
+- Actions, Effects und Event-Payloads
+- Resource Ownership und Cleanup
+- Fabric-Lanes fuer sichtbare, user-blocking, transition, idle,
+  background- und diagnostics-Arbeit
+
+Der Host stellt Komponenten, Router, Browser-APIs und externe Daten bereit.
+Diese Grenze haelt den Kernel framework-neutral und macht die App trotzdem
+vollstaendig beschreibbar.
+
+## XTend UI-Kompatibilitaet
+
+RMT vNext Component Primitives zielen auf den bestehenden XTend-Component-
+Stack. Eine Surface wie `component x-select` wird zu einem DOM Descriptor
+abgesenkt und dann ueber die Component Capability Registry aufgeloest, nicht
+ueber einen produktspezifischen Renderer. Die Registry liest
+`components/manifest.json`, `xtendComponentContract`, `xtendRmtMetadata`,
+public Events, `observedAttributes`, Slots, Parts, Form-Assoziation,
+Accessibility-Profile und Performance-Profile.
+
+Damit erreicht RMT alle 44 public Manifest-Eintraege, waehrend 40 renderbare
+UI-Komponenten ihren normalen Web-Component-Lifecycle behalten. Infrastruktur-
+module wie `x-theme` und `xstate` bleiben Host-Services, keine normalen
+Surface-Elemente. Produktcode soll ueber public Attribute, Properties, Events,
+Parts, Slots und State-Bridges binden, statt `shadowRoot` oder private
+Component-Maps zu patchen.
+
+Details stehen in
+[RMT vNext Component Primitives und XTend UI](./rmt-vnext-component-primitives.md).
+
+## Editor-DX
+
+Der Language Server erkennt vNext-Primitives direkt:
+
+- Completions fuer Primitive-Keywords und klauselnahe Vorschlaege
+- Hover mit Core Pointer und Primitive-Informationen
+- Document Symbols fuer `states`, `selectors`, `actions`, `surfaces`,
+  `portals`, `overlays` und `resources`
+- Code Actions fuer sichere Reparaturen
+- Safe Fix-All fuer `source.fixAll.rmt.vnext.primitives`
+- manuelle Uebergaben fuer Kernel-/Host-Boundaries
+
+Das Snippet `rmt-vnext-primitive-shell` erzeugt eine kleine App Shell mit
+State, Selector, Action, Portal, Surface, Lane und Event-Payload-Contract.
+
+## Migration aus Legacy-Records
+
+Legacy- und App-Platform-JSON bleiben lesbar, sind aber nicht der normale
+Authoring-Pfad. Fuer vorhandene App-Platform-Primitive-Records gibt es:
+
+- `createAppPlatformPrimitiveMigrationPreview(...)` fuer einen vNext-Draft
+- `createAppPlatformPrimitiveMigrationApplyPlan(...)` fuer einen manuellen
+  Apply-Plan ohne automatisches Schreiben
+- `report-only`, `preview-ready`, `apply-plan-ready` und `blocked` als
+  klare Statuswerte
+
+Details stehen in [RMT vNext Primitive Migration](./rmt-vnext-primitive-migration.md).
+
+## Reference Demo
+
+Die vollstaendige Referenz liegt in `xtendrmt/rmt-vnext-reference-demo.rmt`.
+Sie deckt Templates, Surfaces, gewichtete Lanes, Conditions, Slots, Events,
+Endpoint/SSE/Worker Sources, Security Policies und Streaming ab.
+
+Der stabile Compiler-Output liegt in
+`xtendrmt/rmt-vnext-reference-demo.core.json`. Wenn Syntax oder Compiler
+absichtlich geaendert werden, muessen Quelle und Core-Output gemeinsam
+aktualisiert werden.
+
+## Lokal pruefen
+
+```bash
+node scripts/run_xtend_tests.js rmt-vnext-parser rmt-vnext-compiler rmt-vnext-tooling --json
+node scripts/run_xtend_tests.js rmt-vnext-compatibility --json
+node scripts/run_xtend_tests.js rmt-vnext-component-primitives --json
+node scripts/run_xtend_tests.js rmt-vnext-release --json
+```
+
+Fuer App-Shell-Arbeit reichen normalerweise Parser, Compiler, Tooling und
+Compatibility. Release-Gates pruefen zusaetzlich Referenzdemo, Core-Output,
+Migration und Referenzpfade.
+
+## Grenzen
+
+- RMT vNext fuehrt keine Host-Runtime im Kernel aus.
+- Conditions sind deklarativ und erlauben keine Funktionsaufrufe.
+- Imports sind statisch und bleiben package-root-gebunden.
+- Legacy JSON bleibt kompatibel, aber nicht der bevorzugte Authoring-Pfad.
+- XTend-, XRouter-, DOM- und Browser-Details gehoeren in Adapter.
+- XTend-Component-Integration laeuft ueber public Contracts und die Component
+  Capability Registry, nicht ueber direkte Kernel-Imports oder
+  Shadow-DOM-Monkeypatching.

package/docs/de/rmt-vnext-component-primitives.md

@@ -0,0 +1,188 @@
+# RMT vNext Component Primitives und XTend UI
+
+- Schema: `xtend.rmt.component-capability-registry.v1`
+- Report Schema: `xtend.rmt.component-capability-registry-report.v1`
+- Runtime: `xtendrmt/rmt-component-capability-registry.js`
+- Export: `@ccslabs/xtend/rmt/component-capability-registry`
+- Local Gate: `node scripts/run_xtend_tests.js rmt-vnext-component-primitives --json`
+- Aggregat: `npm run test:rmt-vnext-primitives:report`
+
+RMT vNext und XTend UI sind keine Parallelwelten. Die Component Primitives
+verbinden RMT-Templates, Kernel Records, DOM Descriptor Renderer und die
+public XTend Web Components ueber eine gemeinsame Capability Registry. RMT
+beschreibt Shell, State, Surfaces, Events und Lifecycle; XTend Components
+liefern die konkreten UI-Bausteine, Accessibility-Profile, Parts, Slots,
+Events und Performance-Profile.
+
+## Source-to-Sea-Fluss
+
+```text
+.rmt template
+  -> RMT Compiler und Core Records
+  -> Kernel Records und Fabric Lanes
+  -> DOM Descriptor Renderer
+  -> Component Capability Registry
+  -> XTend Component aus components/manifest.json
+  -> Browser DOM und Component Lifecycle
+```
+
+Der RMT-Kernel importiert keine XTend-Komponenten und keine XTend-Typen. Die
+Registry liest Manifest, Component Contracts, `xtendRmtMetadata`,
+`observedAttributes`, Events, Slots, Parts, Form-Assoziation sowie A11y- und
+Performance-Profile. Daraus entsteht eine normalisierte Matrix fuer alle 42
+public Eintraege aus `components/manifest.json`.
+
+## Matrix
+
+| Bereich | Abdeckung |
+| --- | --- |
+| Manifest-Eintraege | 44 |
+| Renderbare public UI-Komponenten | 40 |
+| Nicht-visuelle Sonderfaelle | 4 |
+| RMT-Metadaten | 42 Eintraege |
+| Component Contracts | 40 Eintraege |
+| Form-associated Components | 6 |
+
+Nicht-visuelle Sonderfaelle sind `x-theme`, `xstate`, `x-utils` und
+`x-rmt-lifecycle-demo-build`. `x-theme` und `xstate` sind Infrastrukturmodule;
+sie werden ueber Host-/Loader-Dienste genutzt, aber nicht als normale RMT-App-
+UI gerendert. `x-utils` bleibt Utility-Modul, der Lifecycle-Demo-Build bleibt
+Demo-Artefakt.
+
+## Component-Familien
+
+| Familie | Tags |
+| --- | --- |
+| Form | `x-calendar`, `x-checkbox`, `x-form`, `x-input`, `x-radio`, `x-select`, `x-textarea` |
+| Navigation | `x-router`, `x-link`, `x-menu`, `x-drawer` |
+| Overlay/Surface | `x-dialog`, `x-lightbox`, `x-modal`, `x-popover`, `x-side-panel`, `x-surface-manager`, `x-surface-window`, `x-toast`, `x-tooltip` |
+| Media/Feedback/Layout | `x-alert`, `x-button`, `x-cards`, `x-code`, `x-icon`, `x-masonry`, `x-player`, `x-progress`, `x-spinner`, `x-status`, `x-summary`, `x-type`, `x-writer` |
+| Theme/Layout | `x-footer`, `x-header`, `x-hero`, `x-section`, `x-tabs` |
+| Infrastruktur | `x-theme`, `xstate`, `x-utils`, `x-rmt-lifecycle-demo-build` |
+
+Die risikoreichen Familien `form`, `navigation`, `overlay-surface`,
+`media-feedback-layout` und `theme-layout` bleiben fuer representative Browser
+Smokes markiert. Der Default-Gate prueft die breite Matrix fake-DOM-nah und
+haelt Browser-Flakiness aus dem schnellen Primitive-Gate heraus.
+
+## Runtime API
+
+```js
+import {
+  createRmtComponentCapabilityRegistry
+} from '@ccslabs/xtend/rmt/component-capability-registry';
+import {
+  createRmtDomDescriptorRenderer
+} from '@ccslabs/xtend/rmt/dom-descriptor-renderer';
+
+const registry = createRmtComponentCapabilityRegistry({
+  manifest,
+  sourceTexts,
+  importer: async (modulePath) => import(`/components/${modulePath.replace(/^\.\//u, '')}`)
+});
+
+const descriptor = registry.buildComponentDescriptor({
+  tag: 'x-select',
+  id: 'plan-select',
+  key: 'settings:plan',
+  attributes: {
+    name: 'plan',
+    value: 'pro'
+  },
+  slots: {
+    label: { text: 'Plan' }
+  },
+  events: {
+    'select-changed': 'settings.plan.changed'
+  }
+});
+
+const renderer = createRmtDomDescriptorRenderer({ documentTarget: document });
+
+renderer.renderKeyed(root, [descriptor], {
+  componentRegistry: registry,
+  dispatchEvent(event) {
+    actions.dispatch(event.action, event.payload);
+  },
+  stateBridge: {
+    read(key) {
+      return state.read(key);
+    },
+    write(key, value) {
+      state.write(key, value);
+    }
+  }
+});
+```
+
+Wichtige Registry-Funktionen:
+
+| Funktion | Zweck |
+| --- | --- |
+| `resolveComponentCapability(tag)` | Liefert normalisierte Capabilities fuer einen Manifest-Tag. |
+| `listCapabilities(filter)` | Listet Capabilities nach Familie oder Visual Kind. |
+| `buildComponentDescriptor(input)` | Baut einen DOM Descriptor fuer XTend-Komponenten inklusive Capability-Markern. |
+| `bindComponentInstance(element, binding, options)` | Verbindet Events, Form-State und State Bridge ueber public DOM APIs. |
+| `ensureComponentLoaded(tag, options)` | Fuehrt lazy Import ueber einen expliziten Importer aus. |
+| `createMatrixReport()` | Erzeugt den Compatibility-Report fuer CI und lokale Diagnose. |
+
+## Event- und State-Bridge
+
+Form Controls liefern `value`, `checked`, `validity`, `dataset` und Datei-
+Metadaten in einem sicheren Payload-Record
+`xtend.rmt.component-event-payload.v1`. Fuer Form-Familien werden `input` und
+`change` ergaenzt, wenn keine explizite Event-Bindung gesetzt ist.
+
+Navigation, Overlays, Feedback- und Layout-Komponenten bleiben ebenfalls ueber
+public Events und Properties angebunden. Produktcode muss nicht in
+`shadowRoot` greifen, keine privaten Component-Maps lesen und keine
+komponentenspezifischen Renderer einbauen.
+
+## Renderer-Integration
+
+Der DOM Descriptor Renderer akzeptiert `componentRegistry` in
+`render(...)` und `renderKeyed(...)`. Bei `type: "component"` werden Tag,
+Attribute, Properties, Slots, Parts und Event-Bindings ueber die Registry
+normalisiert. Keyed Reuse bleibt erhalten, unkeyed Repeat-UI wird weiterhin
+diagnostiziert.
+
+Normale RMT-App-UI nutzt keine HTML-Sinks. `innerHTML`, `outerHTML`,
+`insertAdjacentHTML`, `document.write`, `createContextualFragment` und
+unsichere URL-/Inline-Event-Sinks bleiben durch den No-Manual-HTML-Gate und
+die Trusted-DOM-Boundary gesperrt.
+
+## Architekturregeln
+
+- Component Contracts bleiben die Quelle der Wahrheit.
+- RMT erweitert XTend UI ueber Metadaten und Runtime-Bridges, nicht ueber
+  Monkeypatching.
+- Lazy Import laeuft nur ueber Manifest und explizite Importer.
+- Der RMT-Kernel bleibt framework-neutral und importiert keine XTend-Typen.
+- Overlays, Surfaces und Portals brauchen Resource Ownership und Cleanup.
+- `x-player` nutzt den public Player Contract fuer Play/Pause, State Bridge,
+  Theme Tokens und Parts; Produktcode patcht kein Shadow DOM.
+- Infrastrukturmodule wie `x-theme` und `xstate` werden als Services genutzt,
+  nicht als normale Surface-Elemente.
+
+## Gates
+
+```bash
+node scripts/run_xtend_tests.js rmt-vnext-component-primitives --json
+npm run test:rmt-vnext-primitives:report
+node scripts/run_xtend_tests.js component-ux-browser-smokes --json
+node scripts/run_xtend_tests.js type-exports-rmt --json
+```
+
+Das schnelle Primitive-Gate prueft Registry, Matrix, Renderer-Bindung,
+Package-Exports, Type Declarations, Lazy Import, State Roundtrip und negative
+Grenzen gegen Shadow-DOM-Patches, manuelle HTML-Sinks und direkte Component-
+Imports.
+
+## Verwandte Doku
+
+- [RMT vNext Authoring Guide](./rmt-vnext-authoring.md)
+- [RMT DOM Descriptor Renderer](./rmt-dom-descriptor-renderer.md)
+- [RMT Component Template Primitives](./rmt-component-template-primitives.md)
+- [XTend Components](./components.md)
+- [Component Platform](./component-platform.md)
+- [XTend-Fabric RMT Lane Mapping](./xtend-fabric-rmt-lane-mapping.md)

package/docs/de/rmt-vnext-cross-surface-events.md

@@ -0,0 +1,68 @@
+# RMT vNext Cross Surface Events
+
+Cross Surface Events verbinden Bereiche der App Shell, ohne einen impliziten
+globalen Event Bus einzufuehren. Jede Richtung, jedes Ziel und jedes Payload-
+Schema wird explizit beschrieben und durch Governance-Diagnostics abgesichert.
+Boundary: no implicit global Event Bus.
+
+## Contract
+
+```js
+schema: "xtend.rmt.vnext-cross-surface-event-protocol.v1"
+reportSchema: "xtend.rmt.vnext-cross-surface-event-report.v1"
+governanceSchema: "xtend.rmt.vnext-event-governance-policy.v1"
+```
+
+Ein Event muss definieren:
+
+- `event` als versionierter Name, zum Beispiel `checkout.cart.updated.v1`.
+- `owner` als Team fuer Event- und Versionspflege.
+- `payload.schema` als stabile Payload-ID.
+- `direction` als `outbound` oder `inbound`.
+- `scope` als Lane-, Surface- oder Shell-Target-Bindung.
+- `delivery` mit TTL, Korrelation und Idempotenz, wenn erforderlich.
+
+## Direction
+
+`emits` beschreibt ausgehende Events einer Surface. `consumes` beschreibt
+eingehende Events. Die Shell darf diese Bindings weiterleiten, aber nicht frei
+interpretieren. Dadurch bleibt sichtbar, ob eine User-Aktion mehrere Bereiche
+der Shell tangiert.
+
+## Scope
+
+Events sind auf Lanes und Shell Targets begrenzt:
+
+```rmt
+emits checkout.cart.updated.v1 {
+  owner: "checkout-platform"
+  payload: "xtend.schemas.cartUpdated.v1"
+  direction: outbound
+  scope: lane critical -> shell.slot:sidebar.cart
+}
+```
+
+Ein Event ohne klaren Scope wird im E16-Gate blockiert oder diagnostiziert. Das
+verhindert denselben impliziten Kopplungsdruck, der Micro-Frontend-Systeme ohne
+Disziplin schwer wartbar macht.
+
+## Governance
+
+Das Governance-Modell prueft:
+
+- Event Owner und Payload Owner.
+- Cross-Team-Events.
+- Delivery Mode, TTL, `correlationId` und `idempotencyKey`.
+- Sensitivity und Review-Pflichten.
+- Degradation-Verhalten fuer Events einer blockierten oder degradierten Surface.
+
+## Gates
+
+```bash
+node scripts/run_xtend_tests.js rmt-vnext-cross-surface-events --json
+node scripts/run_xtend_tests.js rmt-vnext-event-governance --json
+node scripts/run_xtend_tests.js rmt-vnext-enterprise-release --json
+```
+
+Die Enterprise Demo deckt `checkout.cart.updated.v1` und
+`user.session.changed.v1` als typisierte, gerichtete Cross-Surface-Events ab.