@ccslabs/xtend 0.1.0-rc.1 → 0.1.2

package/docs/de/release-owner-acceptance.md

@@ -0,0 +1,56 @@
+# Release Owner Acceptance
+
+`xtend.epic13.release-owner-acceptance.v1` beschreibt den ersten RC1-Owner-Schnitt nach dem RC1 Readiness Model.
+
+Lokaler Gate:
+
+```bash
+node scripts/run_xtend_tests.js epic13-release-owner-acceptance --json
+```
+
+oder:
+
+```bash
+npm run test:epic13-release-owner-acceptance
+```
+
+## Was der Contract festlegt
+
+- Release Owner Acceptance ist ein Review-Contract, keine Publish-Freigabe.
+- `private-until-release-owner-acceptance` bleibt aktiv.
+- `publishAllowed` bleibt `false`.
+- `automaticPublishApproval` bleibt `false`.
+- Owner-Entscheidungen nutzen `accepted`, `deferred` und `blocked`.
+
+## Checklist-Modell
+
+| Status | Verwendung |
+|--------|------------|
+| `accepted` | Baseline ist als Review-Grundlage angenommen |
+| `deferred` | Offene Evidenz ist sichtbar und besitzt ein Zielpaket |
+| `blocked` | Entscheidung darf nicht automatisch erfolgen |
+
+Der bewusst blockierte Eintrag ist `automatic-publish-approval`. Damit bleibt ein gruener Testlauf ein Review-Signal, aber kein Publish-Signal.
+
+## Aktueller Handoff
+
+`WP-E13-03` hat die Conditional Network Gate Evidence unter [Conditional Network Evidence](./conditional-network-evidence.md) mit `xtend.epic13.conditional-network-evidence.v1` vorbereitet:
+
+- `npm audit --audit-level=moderate`
+- `npm sbom --sbom-format=cyclonedx --json`
+
+Wenn diese Gates lokal wegen Sandbox, Netzwerk oder Policy nicht laufen koennen, entsteht eine strukturierte Owner-Deferral.
+
+`WP-E13-04` hat den [Package Export Lock](./package-export-lock.md) mit `xtend.epic13.package-export-lock.v1` abgeschlossen. `WP-E13-05` hat die [Known Residual Triage](./known-residual-triage.md) mit `xtend.epic13.known-residual-triage.v1` abgeschlossen. `WP-E13-06` hat die [Hydration Performance Closure](./hydration-performance-closure.md) mit `xtend.epic13.hydration-performance-closure.v1` abgeschlossen. `WP-E13-07` hat die [PROD Browser CSP Smokes](./prod-browser-csp-smokes.md) mit `xtend.epic13.prod-browser-csp-smoke.v1` abgeschlossen. `WP-E13-08` hat [Visual Owner Artifacts](./visual-owner-artifacts.md) mit `xtend.epic13.visual-owner-artifact.v1` normalisiert.
+
+Der Checklist-Eintrag `known-residual-renewal` ist damit `accepted`: `xstate` und `x-utils` sind Boundary-Contracts, `xtend.component.hydrate` ist owner-frei geschlossen. Der Checklist-Eintrag `visual-owner-artifact` ist `accepted`; `rmt-production-readiness` ist seit `WP-E13-09` und `xtend.epic13.rmt-production-readiness.v1` ebenfalls `accepted`. `docs-rmt-production-hardening` ist seit `WP-E13-10` und `xtend.epic13.docs-rmt-production-hardening.v1` accepted. `prod-browser-csp-smoke` und `trusted-dom-boundary` sind seit `WP-E13-11` accepted; die Trusted-DOM-Evidence liegt unter [Trusted DOM Boundary Browser Proof](./trusted-dom-boundary-browser-proof.md) und `xtend.epic13.trusted-dom-boundary.v1`. `rc1-migration-notes` ist seit `WP-E13-12` accepted; die Evidence liegt unter [RC1 Migration Notes](./rc1-migration-notes.md) und `xtend.epic13.rc1-migration-notes-semver.v1`. `rc1-gate-matrix-ci-handoff` ist seit `WP-E13-13` accepted; die Evidence liegt unter [RC1 Gate Matrix und CI-Handoff](./rc1-gate-matrix-ci-handoff.md) und `xtend.epic13.rc1-gate-matrix-ci-handoff.v1`. Der naechste Handoff geht nach `WP-E13-14`.
+
+Weiterfuehrend: [RC1 Readiness](./rc1-readiness.md).
+
+## RC1 Test-Build Acceptance
+
+`RC1TB-WP-08` konkretisiert den Owner-Schnitt fuer den ersten lokalen RC1-Test-Build in `development/XTend-RC1-Test-Build-Owner-Acceptance.md` unter `xtend.rc1.test-build-owner-acceptance.v1`.
+
+Die Entscheidung fuer diesen Schnitt lautet `accepted-for-internal-test-build-not-publish`: Der Test-Build darf intern gegen die dokumentierten Gate-Reports, die RMT vNext Reference Demo und die XTendRMT Bestcase Demo verwendet werden. `npm-audit-moderate` und `npm-sbom-json` sind im Owner-Publish-Schritt ausgefuehrt und akzeptiert; Version `0.1.0-rc.1` und `private: false` sind fuer Publish Prep gesetzt, `automaticPublishApproval: false` bleibt aktiv.
+
+Der separate Owner-Publish-Entscheid ist in `development/XTend-RC1-Release-Owner-Publish-Decision.md` unter `xtend.rc1.release-owner-publish-decision.v1` angelegt. Sein aktueller Zustand ist `accepted-for-publish-prep`; der eigentliche Publish-Befehl wurde nicht ausgefuehrt. Die License-Entscheidung fuer den kompletten Stack ist `Apache-2.0`; Audit und SBOM sind akzeptiert.

package/docs/de/release-report-pack-dry-run-evidence.md

@@ -0,0 +1,39 @@
+# Release Report und Pack Dry Run Evidence
+
+Contract: `xtend.epic13.release-report-pack-dry-run-evidence.v1`
+
+Status: `accepted-release-report-pack-dry-run-evidence`
+
+Workpackage: `DPF-WP-02-release-report-pack-dry-run`
+
+## Ziel
+
+Dieses Paket macht `release:report` und `pack:dry-run` zu reproduzierbarer Release-Owner-Evidence. Beide Befehle bleiben lokal und netzwerkfrei; Audit/SBOM, Public Publish und License-Entscheidung bleiben Folgepakete.
+
+## Lokaler Gate
+
+```bash
+node scripts/run_xtend_tests.js epic13-release-report-pack-dry-run-evidence --json
+npm run test:epic13-release-report-pack-dry-run-evidence
+```
+
+## Evidence-Befehle
+
+```bash
+npm run release:report
+npm run pack:dry-run
+```
+
+`npm run release:report` schreibt `.xtend-test-results/xtend-release-report.json`.
+
+`npm run pack:dry-run` schreibt:
+
+- `.xtend-test-results/xtend-pack-dry-run.json`
+- `.xtend-test-results/xtend-package-export-surface-lock.json`
+- `.xtend-test-results/xtend-package-export-lock-report.json`
+
+Der rohe npm-Textlauf bleibt ueber `npm run pack:dry-run:raw` erreichbar.
+
+## RC1-Handoff
+
+Die Evidence wird im RC1-Handoff unter `xtend.epic13.rc1-gate-matrix-ci-handoff.v1` referenziert. Der DPF-WP-02-Report nutzt `.xtend-test-results/xtend-epic13-release-report-pack-dry-run-evidence-report.json` und uebergibt an `DPF-WP-03` [Conditional Network Evidence CI](./conditional-network-evidence-ci.md) mit `xtend.epic13.conditional-network-evidence-ci.v1`.

package/docs/de/rmt-action-effect-runtime.md

@@ -0,0 +1,81 @@
+# RMT Action Effect Runtime
+
+- Contract: `xtend.epic18.rmt-action-effect-runtime.v1`
+- Workpackage: `WP-E18-08`
+- Runtime: `xtendrmt/rmt-action-effect-runtime.js`
+- Types: `xtendrmt/rmt-action-effect-runtime.d.ts`
+- Fixture: `tests/fixtures/rmt-action-effect-runtime.rmt`
+- Lokaler Gate: `node scripts/run_xtend_tests.js rmt-action-effect-runtime --json`
+- Naechstes Paket: `WP-E18-09`
+
+## Zweck
+
+Die Action Effect Runtime macht haeufige App-Flows zu nativen RMT-App-Platform-Primitives. Apps koennen Fixture-, REST-, SSR- oder Host-Adapter-Daten laden, typisierten State aktualisieren, Feedback veroeffentlichen, navigieren, Controls fokussieren, Module lazy laden und Ressourcen besitzen, ohne produktlokale Action-Frameworks aufzubauen.
+
+Die Runtime ist bewusst domain-neutral. Sie definiert keine Produktsurfaces und keine Record-Taxonomien. Entwickler liefern ihre eigenen Actions, Contracts, Adapter, Effects und Resources.
+
+## DataSources
+
+Unterstuetzte Datasource-Arten:
+
+- `fixture`: liefert statische Fixture-Records fuer lokale App-Fixtures und Tests.
+- `rest`: ruft einen injizierten Adapter mit Endpoint und Payload auf.
+- `ssr`: liest ein vorhydriertes Payload und kann es mit `resultPath` projizieren.
+- `host`: ruft einen expliziten Host-Adapter fuer Mutationen oder Plattformkommandos auf.
+
+Runtime-Code greift niemals direkt auf globale Netzwerk-APIs zu. REST und Host laufen ueber injizierte Adapter, damit Browser-, Server-, Test- und Shell-Umgebungen ihre eigene Transport-Policy waehlen koennen.
+
+## Actions
+
+Eine Action kann deklarieren:
+
+- `datasource`
+- `resultState`
+- `loadingState`
+- `statusState`
+- `effects`
+- `resources`
+- `resourceOwner`
+- `cancelable`
+
+`runAction(id, payload)` fuehrt die Action durch Loading-, Success-, Error- oder Cancelled-Zustaende. Wenn eine typed State Runtime uebergeben wird, werden Loading und Status ueber `setState` und `patchState` geschrieben; Datasource-Ergebnisse koennen in `resultState` gespeichert werden.
+
+## Effects
+
+Unterstuetzte Effect-Arten:
+
+- `toast` und `feedback`
+- `navigation`
+- `focus`
+- `lazy-import`
+- `side-effect`
+
+Feedback, Navigation, Focus und eigene Side Effects nutzen injizierte Adapter. Lazy Imports werden als Ressourcen modelliert und koennen dadurch dasselbe Ownership- und Cleanup-Modell wie andere Runtime-Ressourcen teilen.
+
+## Resource Ownership
+
+Unterstuetzte Resource-Arten:
+
+- `object-url`
+- `stream`
+- `observer`
+- `timer`
+- `lazy-import`
+
+Ressourcen werden unter einem Owner erworben, normalerweise der Action-ID. Der Resource Manager stellt `releaseOwner(ownerId)` bereit, damit Surface-Destroy, Render-Unit-Destroy oder Action-Cancel nur die Ressourcen bereinigen, die ihnen gehoeren.
+
+## Diagnostics
+
+Die Runtime emittiert Diagnostics mit `xtend.epic18.rmt-action-effect-diagnostic.v1` auf dem Channel `rmt.app_platform.action_effect`. Loading, Success, Error und Cancel sind in der lokalen Runtime-History und in einem optionalen Diagnostics Hub sichtbar.
+
+## Boundaries
+
+- Der RMT-Kernel importiert keine XTend-UI-Komponenten.
+- Datenzugriff laeuft ueber injizierte Adapter.
+- Produktlokale Action-Frameworks sind nicht Teil des Plattformvertrags.
+- Produkt-Flow-Namen bleiben App-Code, nicht Framework-Defaults.
+- Normale App-UI nutzt weiterhin RMT-Templates und DOM-Descriptors statt HTML-String-Renderern.
+
+## Handoff
+
+`WP-E18-09` baut auf dieser Runtime auf, indem deklarative DOM- und Custom Events an Actions angeschlossen werden. Die Event-Schicht soll die Action Effect Runtime wiederverwenden, statt einen weiteren Action-Ausfuehrungspfad zu erzeugen.

package/docs/de/rmt-app-platform-authoring.md

@@ -0,0 +1,54 @@
+# RMT App Platform Authoring
+
+- Contract: `xtend.epic18.rmt-app-platform-authoring.v1`
+- Fixture: `tests/fixtures/rmt-app-platform-authoring.rmt`
+- Local Gate: `node scripts/run_xtend_tests.js rmt-app-platform-authoring --json`
+- Workpackage: `WP-E18-04`
+
+## Zweck
+
+Dieses Authoring-Modell definiert RMT als generische App Platform. Es ist keine
+Portierung einer konkreten Produktoberflaeche. Entwickler koennen eigene
+App-Domains, Record-Vertraege, Komponentenfamilien, Surfaces, State-Graphen,
+Actions, DataSources, Resources und Events kombinieren.
+
+## Primitives
+
+| Primitive | Zweck |
+|-----------|-------|
+| `app` | App-Metadaten, Shell, Domain, Record-Contract und Einstiegspunkte |
+| `route` | URL- oder Navigationszustand auf Surface und Template mappen |
+| `surface` | keyed App-Bereiche mit Lifecycle, Placement, State und Persistence |
+| `slot` | benannte Kompositionspunkte zwischen Templates und Komponenten |
+| `template` | strukturierte UI als DOM Descriptor, nicht als HTML-String |
+| `component` | beliebige Custom Elements ueber einen Faehigkeitskatalog binden |
+| `state` | typed App-State fuer Collections, Auswahl, Filter und Formwerte |
+| `selector` | abgeleitete Lesesichten auf State |
+| `derive` | computed Values mit klarem Output-Typ |
+| `repeat` | keyed Listen ohne Produkt-Renderer |
+| `when` | deklarative Bedingungen, Empty- und Fallback-Zustaende |
+| `bind` | State, Selectors oder Derived Values auf Attribute/Properties mappen |
+| `action` | deklarative Commands fuer App-Flows |
+| `effect` | async Ausfuehrung mit Lanes und Feedback |
+| `datasource` | Fixture-, REST-, SSR- oder spaetere Host-Datenadapter |
+| `resource` | lazy/preload/cleanup Ressourcen inklusive Trusted-HTML-Sonderfall |
+| `event` | scoped Event-Routing ohne impliziten globalen Event-Bus |
+
+## Boundaries
+
+- `no-media-manager-product-surface-clone`
+- `no-product-record-contract-required`
+- `structured-ui-before-trusted-html`
+- `trusted-html-explicit-boundary-only`
+- `no-rmt-kernel-import-of-xtend-types`
+- `no-external-innerhtml-helper-required`
+
+Normale App-UI muss ueber strukturierte Templates modellierbar sein. HTML bleibt
+eine explizite Trusted-DOM-Boundary fuer Sonderfaelle und ist nicht der
+Standardweg fuer Komponentenentwicklung.
+
+## Handoff
+
+`WP-E18-04` legt nur das Authoring-Modell fest. `WP-E18-05` baut danach den
+sicheren DOM Descriptor Renderer und den No-Manual-HTML-Gate. `WP-E18-06`
+setzt darauf die component-nativen Template Primitives um.

package/docs/de/rmt-app-platform-fixture.md

@@ -0,0 +1,46 @@
+# RMT App Platform Fixture
+
+WP-E18-12 liefert die generische Referenz-Fixture fuer die RMT App Platform.
+Sie beweist, dass die Epic-18-Primitives nicht an eine Produktoberflaeche
+gekoppelt sind: dieselben RMT-Bausteine tragen einen `generic-catalog`, eine
+`admin-queue` und ein `content-board`.
+
+## Vertrag
+
+- Schema: `xtend.epic18.rmt-app-platform-fixture.v1`
+- Fixture Schema: `xtend.epic18.rmt-app-platform-fixture-source.v1`
+- Lokaler Gate: `node scripts/run_xtend_tests.js rmt-app-platform-fixture --json`
+- Package Script: `npm run test:rmt-app-platform-fixture`
+- Handoff: `WP-E18-13`
+
+## Abgedeckte Plattformfaehigkeiten
+
+- konfigurierbare Record-Contracts ohne feste Record-Klasse
+- Listen-, Detail-, Toolbar-, Feedback- und Overlay-Komposition mit DOM
+  Descriptor Templates
+- Actions mit Fixture-, REST-, SSR- und Host-DataSources
+- Feedback-, Navigation-, Focus-, Lazy-Import- und Side-Effect-Flows
+- dynamische Surfaces fuer mehrere Domains aus denselben Primitives
+- Portals und Overlays inklusive Stack-Verhalten
+- Resource Ownership und Cleanup fuer Streams, Observer, Timer, Object URLs und
+  Lazy Imports
+- Scaffold Build Evidence ueber den RMT App Platform Generator
+
+## Grenzen
+
+Normale RMT UI bleibt deklarativ. `innerHTML`, `outerHTML`,
+`insertAdjacentHTML` und `document.write` gehoeren nicht in die App-Fixture;
+der No-Manual-HTML-Gate prueft das explizit. Produktgebundene Surface-Listen
+werden ebenfalls vermieden. Entwickler sollen in XTend App-Strukturen bauen
+koennen, ohne externe Shell-Renderer oder lokale Registry-Umbauten zu brauchen.
+
+## Fixture-Artefakte
+
+- `catalog/epic18-rmt-app-platform-fixture.js`
+- `tests/fixtures/rmt-app-platform-fixture.rmt`
+- `tests/rmt/rmt_app_platform_fixture_suite.js`
+- `development/WP-E18-12-Generische-RMT-App-Platform-Fixture-bauen.md`
+
+Der Gate rendert die Fixture mit dem DOM Descriptor Renderer, routet Events in
+Actions, tauscht DataSources, materialisiert Surfaces, oeffnet Overlays und
+belegt Cleanup durch Resource-Disposals.

package/docs/de/rmt-app-platform-migration-guide.md

@@ -0,0 +1,88 @@
+# RMT App Platform Migration Guide
+
+Dieser Guide beschreibt den Weg von externen Host-Hilfen wie
+`root.innerHTML`, produktgebundenen Surface-Listen oder lokalen Registry-
+Repaints hin zu nativen RMT-App-Platform-Primitives.
+
+## Zielbild
+
+- Neue UI wird in RMT vNext beschrieben; DOM Descriptor, App-Platform-JSON und
+  Component Records sind generierter Output oder Compatibility Mirror.
+- State, Selectors und Derived Values liegen in der RMT State Selector Runtime.
+- Interaktionen laufen ueber deklarative Events und Actions.
+- DataSources bleiben austauschbar: `fixture`, `rest`, `ssr` und `host`.
+- Surfaces, Overlays, Portals und Resources werden ueber den Surface Resource
+  Graph materialisiert und aufgeraeumt.
+
+```rmt
+template migration.catalog {
+  state records type collection initial []
+
+  selector visibleRecords from state records {
+    output CatalogRecord[]
+  }
+
+  datasource catalog from fixture records.generic-items {
+    contract CatalogRecord[]
+  }
+
+  action load-records {
+    effect fetch datasource catalog
+    on success -> reduce state.records = result.records
+  }
+
+  portal surface.root root "#app-root" layer surface
+
+  surface catalog.board kind workspace component x-cards {
+    repeat from selector visibleRecords
+    key record.id
+    portal surface.root
+
+    lane visible weight 80 {
+      hydrate catalog-cards from selector visibleRecords
+    }
+
+    on card-click target item -> action load-records {
+      payload source from target.dataset.source
+    }
+  }
+}
+```
+
+## Migration
+
+1. Externe HTML-Host-Renderer identifizieren.
+   Suchen nach `innerHTML`, `outerHTML`, `insertAdjacentHTML` und
+   `document.write`.
+2. Shell-Struktur in RMT vNext ueberfuehren.
+   Normale App-UI nutzt `template`, `surface`, `portal`, `lane`, `hydrate` und
+   Events; `mode: "dom_descriptor"` entsteht erst im Output.
+3. Produktlisten entkoppeln.
+   Statt einer festen Record-Klasse werden konfigurierbare Record-Contracts
+   mit stabilen IDs und Keys genutzt.
+4. Interaktionen deklarieren.
+   DOM- oder Custom-Events erhalten `payloadContract` und routen zu Actions.
+5. DataSources austauschbar halten.
+   Lokale Fixture-Daten, SSR-Bootstrap, REST-Suche und Host-Mutation teilen
+   denselben Action-Pfad.
+6. Surface Lifecycle pruefen.
+   Jede Surface mit `resource`-Eintraegen braucht einen Owner, Overlays laufen ueber
+   Portals, und Destroy/Close muss Ressourcen freigeben.
+7. Scaffold Evidence erzeugen.
+   Der RMT App Platform Builder schreibt Diagnostics, Source Map und Build
+   Report.
+
+## Referenz
+
+Die Referenz-Fixture liegt in `tests/fixtures/rmt-app-platform-fixture.rmt` und
+belegt `generic-catalog`, `admin-queue` und `content-board` mit denselben
+Primitives.
+
+```bash
+node scripts/run_xtend_tests.js rmt-app-platform-fixture --json
+```
+
+## Grenze
+
+Trusted HTML bleibt ein expliziter Sonderfall mit Trusted-DOM-Boundary. Normale
+App-UI darf keine HTML-Strings als Renderpfad verwenden.

package/docs/de/rmt-app-platform-tooling.md

@@ -0,0 +1,79 @@
+# RMT App Platform Tooling
+
+- Contract: `xtend.epic18.rmt-app-platform-tooling.v1`
+- Gate: `node scripts/run_xtend_tests.js rmt-app-platform-tooling --json`
+- Workpackage: `WP-E18-11`
+- Handoff: `WP-E18-12`
+
+## Ziel
+
+RMT App Sources sind jetzt vor der Runtime pruefbar und buildfaehig. Das
+Tooling erzeugt Diagnostics, Source Maps und Scaffold Reports fuer generische
+App-Platform-Primitives wie Surfaces, Overlays, Portale, Resources, Actions,
+Events, DataSources und State.
+
+Der Slice ist bewusst keine Media-Manager-Shell. Er liefert Werkzeuge, mit
+denen Entwickler eigene App-Strukturen in XTend/RMT nativ anlegen koennen,
+ohne produktseitige `innerHTML`-Renderer oder eigene Mini-Frameworks.
+
+## Diagnostics
+
+Der App-Platform-Linter blockiert typische spaete Runtime-Fehler bereits beim
+Authoring:
+
+- `rmt.app.no-manual-shell.html-sink` fuer `innerHTML`, `outerHTML`,
+  `insertAdjacentHTML` oder `document.write` in normaler App-UI.
+- `rmt.app.unsafe-html.boundary-missing` fuer HTML-Fragmente ohne explizite
+  Trusted-DOM-Boundary.
+- `rmt.app.repeat.key.missing` fuer wiederholte Surfaces ohne stabilen Key.
+- `rmt.app.event.payload-contract.missing` fuer Events mit Action-Ziel ohne
+  Payload Contract.
+- `rmt.app.resource.ownership.missing` fuer nicht klar besessene Ressourcen.
+- `rmt.app.resource.unresolved`, `rmt.app.portal.unresolved` und
+  `rmt.app.surface.source.unresolved` fuer fehlerhafte App-Graph-Referenzen.
+
+Die Regeln laufen als eigener App-Platform-Policy-Rule im bestehenden
+RMT-Linter und als direkter Analyzer in
+`./rmt-language/app-platform-tooling`.
+
+## LSP
+
+Completion und Hover kennen die neuen Primitives:
+
+- Portal-IDs und Portal-Policies wie `stacked`, `toast-region` und
+  `clipping-escape`.
+- Overlay-Kinds wie `tooltip`, `toast`, `popover`, `lightbox`, `menu` und
+  `dialog`.
+- Resource-Kinds wie `object-url`, `stream`, `observer`, `timer` und
+  `lazy-import`.
+- Event-Kinds und Surface-Initialstates.
+
+Damit koennen App-Autoren RMT-Dokumente ohne Produkt-Surface-Taxonomie und ohne
+externe Hilfslisten bearbeiten.
+
+## Scaffold Build
+
+Der Builder registriert den Befehl `rmt-app-platform`. Er liest eine `.rmt`
+App Source und erzeugt unter `.xtend-build`:
+
+- `*.app-platform-diagnostics.json`
+- `*.app-platform-source-map.json`
+- `*.app-platform-build.json`
+
+Die Artefakte laufen ueber den Epic-17 WritePlan und tragen Scaffold-
+Ownership. `--check` kann damit pruefen, ob lokale Build-Artefakte aktuell
+sind.
+
+```bash
+node scripts/run_xtend_tests.js rmt-app-platform-tooling --json
+node xtend-builder/lib/cli.js rmt-app-platform --source tests/fixtures/rmt-app-platform-tooling.rmt
+```
+
+## Grenzen
+
+- Keine Produkt-Surface-Liste und kein Media-Manager-spezifischer Registry-
+  Repaint.
+- Keine normalen UI-HTML-Sinks ausserhalb einer Trusted-DOM-Boundary.
+- Keine Imports aus XTend-Komponenten in den RMT Kernel.
+- Das Tooling baut Reports, Diagnostics und Source Maps; die produktnahe
+  generische App-Fixture folgt in `WP-E18-12`.

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

@@ -0,0 +1,57 @@
+# RMT Component Template Primitives
+
+- Contract: `xtend.epic18.rmt-component-template-primitives.v1`
+- Fixture: `tests/fixtures/rmt-component-template-primitives.rmt`
+- Runtime Basis: `xtendrmt/rmt-dom-descriptor-renderer.js`
+- Local Gate: `node scripts/run_xtend_tests.js rmt-component-template-primitives --json`
+- Workpackage: `WP-E18-06`
+- Handoff: `WP-E18-07`
+
+RMT kann XTend-Komponenten jetzt nativ komponieren, ohne dass Host-Apps
+HTML-Strings zusammenbauen. Der Slice erweitert den DOM Descriptor Renderer um
+component-nahe Primitives fuer App-Shells, Listen, Formulare, Tooltips, Icons,
+leere Zustaende und Fehlerzustaende.
+
+## Primitives
+
+| Primitive | Zweck |
+|-----------|-------|
+| `component` | Loest eine Component-ID auf ein Custom Element wie `x-section`, `x-card`, `x-tooltip` oder beliebige Entwickler-Tags auf. |
+| `props` | Setzt sichere DOM Properties und spiegelt primitive Werte als Attribute. |
+| `attributes` | Setzt sichere Attribute ohne Inline-Event- oder URL-Sinks. |
+| `parts` | Schreibt CSS Parts fuer themingfaehige Komponenten. |
+| `slots` | Fuellt Slots mit Text, Templates, Komponenten oder Fragmenten. |
+| `text` | Erzeugt Textknoten ueber `createTextNode`. |
+| `when` | Rendert bedingte Teilbaeume. |
+| `repeat` | Rendert Listen und nutzt `key` fuer stabile Knoten. |
+| `empty` | Rendert einen expliziten leeren Zustand. |
+| `fallback` | Rendert deklarative Ersatzinhalte. |
+| `key` | Markiert wiederverwendbare Listenelemente mit `data-rmt-key`. |
+| `ref` | Schreibt `data-rmt-ref` und legt die Elementreferenz in `refs` ab. |
+| `class` | Mappt Klassen aus Strings, Arrays oder bedingten Objekten. |
+| `style-token` | Spiegelt Design Tokens als `data-style-token-*` und `--xtend-*`. |
+
+## Component-Familien
+
+Die Fixture beweist generische Familien statt Produkt-Surfaces:
+Icons, Tooltips, Form Controls (`x-input`, `x-select`, `x-checkbox`),
+Navigation, Listen, Selection, Empty State, Error State und freie Custom
+Elements. Die Komponenten bleiben Entwickler-definiert; RMT kennt nur
+Descriptoren und Adapterfaehigkeiten.
+
+## Component Capability Registry
+
+Die vNext-Schicht fuehrt diese Primitives ueber
+`xtendrmt/rmt-component-capability-registry.js` mit dem ganzen XTend-
+Component-Stack zusammen. Die Registry normalisiert alle 44 public
+Manifest-Eintraege, klassifiziert 40 renderbare UI-Komponenten und verbindet
+Component Contracts, `xtendRmtMetadata`, `observedAttributes`, Events, Slots,
+Parts, Form-State und Lazy Import mit den generischen DOM Descriptoren.
+
+Damit bleiben `component`, `props`, `attributes`, `parts`, `slots`, `repeat`
+und `key` dieselben Primitives, aber sie bekommen eine stack-weite
+Kompatibilitaetsmatrix. Produktcode braucht keine Shadow-DOM-Patches, keine
+privaten Component-Maps und keine komponentenspezifischen Renderer.
+
+Details stehen in
+[RMT vNext Component Primitives und XTend UI](./rmt-vnext-component-primitives.md).

package/docs/de/rmt-dom-descriptor-renderer.md

@@ -0,0 +1,64 @@
+# RMT DOM Descriptor Renderer
+
+- Contract: `xtend.epic18.rmt-dom-descriptor-renderer.v1`
+- Fixture: `tests/fixtures/rmt-dom-descriptor-renderer.rmt`
+- Runtime: `xtendrmt/rmt-dom-descriptor-renderer.js`
+- Local Gate: `node scripts/run_xtend_tests.js rmt-dom-descriptor-renderer --json`
+- Workpackage: `WP-E18-05`
+
+Der Renderer fuehrt das `WP-E18-04` Authoring-Modell als generische App
+Platform aus. Normale App-UI wird aus strukturierten Deskriptoren gebaut:
+`createElement`, `createTextNode`, `createDocumentFragment`,
+`replaceChildren`, sichere Attribute/Properties und keyed Child-Reuse.
+
+## Descriptor-Regeln
+
+| Bereich | Regel |
+|---------|-------|
+| Shell | Root-Render-Units verwenden `replaceChildren` und markieren den Root mit `data-rmt-rendered-shell`. |
+| Elemente | Tags muessen einfache Custom-Element- oder HTML-Tagnamen sein. |
+| Attribute | Inline-Handler, `srcdoc` und unsichere URL-Werte werden abgelehnt. |
+| Properties | HTML-Sink-Properties sind fuer normale UI gesperrt. |
+| Listen | `renderKeyed` erhaelt Knoten ueber `data-rmt-key` und patcht Attribute/Children. |
+| Events | Events laufen ueber `addEventListener`, nicht ueber String-Attribute. |
+| Diagnostics | Runtimefehler enthalten RMT-Source-Informationen wie `documentId`, `templateId` und `pointer`. |
+
+## Component Registry Option
+
+`render(...)` und `renderKeyed(...)` akzeptieren `componentRegistry`. Wenn ein
+Descriptor `type: "component"` nutzt, normalisiert der Renderer Tag,
+Attribute, Properties, Slots, Parts und Event-Bindings ueber die RMT vNext
+Component Capability Registry:
+
+```js
+renderer.renderKeyed(root, descriptors, {
+  componentRegistry: registry,
+  dispatchEvent,
+  stateBridge
+});
+```
+
+Die Registry bindet XTend-Komponenten ueber public DOM APIs. Sie liest
+Component Contracts und RMT-Metadaten, fuehrt lazy Import ueber Manifest-Pfade
+aus und schreibt sichere Capability-Marker wie
+`data-rmt-component-capability`. Der Renderer bleibt dadurch generisch: keine
+Shadow-DOM-Patches, keine privaten Component-Maps und keine HTML-Sinks fuer
+normale RMT-App-UI.
+
+## Trusted Boundary
+
+HTML-Fragmente sind kein normaler Template-Pfad. Sie duerfen nur als
+`trusted_html` mit `xtend.rmt.trusted-dom-boundary.explicit` und einem
+externen `trustedDomRenderer` gerendert werden. Der Standard-Renderer erzeugt
+keine HTML-Fragmente aus Strings.
+
+## No-Manual-HTML
+
+Das Gate `createNoManualHtmlGate()` blockiert normale App-Shells mit
+manuellen HTML-Sinks wie `root.innerHTML`, `element.innerHTML`,
+`template.innerHTML`, `outerHTML`, `insertAdjacentHTML`, `document.write` und
+`createContextualFragment`.
+
+`WP-E18-06` und die vNext Component Capability Registry bauen auf diesem Slice
+component-native Template-Primitives auf, ohne externe HTML-Hilfsrenderer
+vorauszusetzen.