@ccslabs/xtend 0.1.0-rc.1 → 0.1.2

package/docs/package-export-lock.md

@@ -37,8 +37,8 @@ Das Script schreibt:
 
 ## TypeExports Anschluss
 
-Ab `WP-TypeExports-01` nutzt [TypeExports](./type-exports.md) den Package Export Lock als Quelle fuer die Public Export Surface. Der Gate `node scripts/run_xtend_tests.js type-exports --json` koppelt die 115 erwarteten Exports ueber Count und Fingerprint an `xtend.epic13.package-export-lock.v1` und erzwingt fuer neue Public Exports eine Type-Entscheidung. Ab `WP-TypeExports-02` besitzen `.`, `./loader` und `./legacy-loader` die Type-Ziele `./xtend-loader.d.ts` und `./xtend-dev.d.ts`; `node scripts/run_xtend_tests.js type-exports-loader --json` prueft diesen Anschluss gegen die Loader-Runtime. Ab `WP-TypeExports-03` besitzt `./api` das Type-Ziel `./api.d.ts`; `node scripts/run_xtend_tests.js type-exports-api --json` prueft den Core-API-Namespace gegen `api.js`. Ab `WP-TypeExports-04` besitzen `./rmt`, `./rmt/browser` und die RMT-Language-/Tooling-Exports Type-Ziele wie `./xtendrmt/rmt-core.d.ts` und `./tools/rmt-language/rmt-tooling-public-types.d.ts`; `node scripts/run_xtend_tests.js type-exports-rmt --json` prueft diesen Anschluss gegen die RMT Runtime- und Tooling-Surface. Ab `WP-TypeExports-05` besitzen Fabric/A11y/Security Exports Type-Ziele wie `./fabric/xtend-fabric.d.ts` und `./fabric/xtend-policy-public-types.d.ts`; `node scripts/run_xtend_tests.js type-exports-policy --json` prueft diesen Anschluss gegen die Policy-Surface. Ab `WP-TypeExports-06` besitzen Builder-Exports Type-Ziele wie `./xtend-builder/scaffold.d.ts`, `./xtend-builder/builder-public-types.d.ts` und `./xtend-builder/*.d.ts`; `node scripts/run_xtend_tests.js type-exports-builder --json` prueft diesen Anschluss gegen Scaffold, Generatoren, Component Lab und Typing Contracts. Ab `WP-TypeExports-07` besitzen Catalog-Exports Type-Ziele wie `./catalog/epic13-package-export-lock.d.ts` und das gemeinsame `./catalog/catalog-public-types.d.ts`; `node scripts/run_xtend_tests.js type-exports-catalog --json` prueft diesen Anschluss gegen Plan-/Report-/Validation-Catalogs. Ab `WP-TypeExports-08` besitzen Design Tokens und Vendor-Facades Type-Ziele wie `./design-tokens/xtend-design-tokens.d.ts`, `./design-tokens/xtheme-token-alias-layer.d.ts`, `./components/prism.d.ts` und `./components/turndown.d.ts`; `node scripts/run_xtend_tests.js type-exports-vendor --json` prueft diesen Anschluss gegen die Utility-Grenzen. Ab `WP-TypeExports-09` buendelt `npm run test:type-exports:release` die TypeExports-Gates als Release-Handoff und schreibt `.xtend-test-results/xtend-type-exports-report.json`.
+Ab `WP-TypeExports-01` nutzt [TypeExports](./type-exports.md) den Package Export Lock als Quelle fuer die Public Export Surface. Der Gate `node scripts/run_xtend_tests.js type-exports --json` koppelt die 124 erwarteten Exports ueber Count und Fingerprint an `xtend.epic13.package-export-lock.v1` und erzwingt fuer neue Public Exports eine Type-Entscheidung. Ab `WP-TypeExports-02` besitzen `.`, `./loader` und `./legacy-loader` die Type-Ziele `./xtend-loader.d.ts` und `./xtend-dev.d.ts`; `node scripts/run_xtend_tests.js type-exports-loader --json` prueft diesen Anschluss gegen die Loader-Runtime. Ab `WP-TypeExports-03` besitzt `./api` das Type-Ziel `./api.d.ts`; `node scripts/run_xtend_tests.js type-exports-api --json` prueft den Core-API-Namespace gegen `api.js`. Ab `WP-TypeExports-04` besitzen `./rmt`, `./rmt/browser`, `./rmt/dom-descriptor-renderer`, `./rmt/component-capability-registry`, `./rmt/state-selector-runtime`, `./rmt/action-effect-runtime`, `./rmt/event-routing-runtime`, `./rmt/surface-resource-graph-runtime`, `./rmt/native-shell-runtime`, `./rmt/node-ssr-adapter`, `./rmt-language/app-platform-tooling` und die RMT-Language-/Tooling-Exports Type-Ziele wie `./xtendrmt/rmt-core.d.ts`, `./xtendrmt/rmt-dom-descriptor-renderer.d.ts`, `./xtendrmt/rmt-component-capability-registry.d.ts`, `./xtendrmt/rmt-state-selector-runtime.d.ts`, `./xtendrmt/rmt-action-effect-runtime.d.ts`, `./xtendrmt/rmt-event-routing-runtime.d.ts`, `./xtendrmt/rmt-surface-resource-graph-runtime.d.ts`, `./xtendrmt/rmt-native-shell-runtime.d.ts`, `./xtendrmt/rmt-node-ssr-adapter.d.ts`, `./tools/rmt-language/app-platform-tooling.d.ts` und `./tools/rmt-language/rmt-tooling-public-types.d.ts`; `node scripts/run_xtend_tests.js type-exports-rmt --json` prueft diesen Anschluss gegen die RMT Runtime- und Tooling-Surface. Ab `WP-TypeExports-05` besitzen Fabric/A11y/Security Exports Type-Ziele wie `./fabric/xtend-fabric.d.ts` und `./fabric/xtend-policy-public-types.d.ts`; `node scripts/run_xtend_tests.js type-exports-policy --json` prueft diesen Anschluss gegen die Policy-Surface. Ab `WP-TypeExports-06` besitzen Builder-Exports Type-Ziele wie `./xtend-builder/scaffold.d.ts`, `./xtend-builder/builder-public-types.d.ts` und `./xtend-builder/*.d.ts`; `node scripts/run_xtend_tests.js type-exports-builder --json` prueft diesen Anschluss gegen Scaffold, Generatoren, Component Lab und Typing Contracts. Ab `WP-TypeExports-07` besitzen Catalog-Exports Type-Ziele wie `./catalog/epic13-package-export-lock.d.ts` und das gemeinsame `./catalog/catalog-public-types.d.ts`; `node scripts/run_xtend_tests.js type-exports-catalog --json` prueft diesen Anschluss gegen Plan-/Report-/Validation-Catalogs. Ab `WP-TypeExports-08` besitzen Design Tokens und Vendor-Facades Type-Ziele wie `./design-tokens/xtend-design-tokens.d.ts`, `./design-tokens/xtheme-token-alias-layer.d.ts`, `./components/prism.d.ts` und `./components/turndown.d.ts`; `node scripts/run_xtend_tests.js type-exports-vendor --json` prueft diesen Anschluss gegen die Utility-Grenzen. Ab `WP-TypeExports-09` buendelt `npm run test:type-exports:release` die TypeExports-Gates als Release-Handoff und schreibt `.xtend-test-results/xtend-type-exports-report.json`.
 
 ## Handoff
 
-Nach `WP-E13-04` hat `WP-E13-05` die Known Residual Triage unter [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) vorbereitet, `WP-E13-08` hat [Visual Owner Artifacts](./visual-owner-artifacts.md) normalisiert, `WP-E13-09` hat [RMT Production Readiness](./rmt-production-readiness.md) gebuendelt, `WP-E13-10` hat [Docs RMT Production Hardening](./docs-rmt-production-hardening.md) abgeschlossen, `WP-E13-11` hat [Trusted DOM Boundary Browser Proof](./trusted-dom-boundary-browser-proof.md) abgeschlossen, `WP-E13-12` hat [RC1 Migration Notes](./rc1-migration-notes.md) abgeschlossen, `WP-E13-13` hat [RC1 Gate Matrix und CI-Handoff](./rc1-gate-matrix-ci-handoff.md) registriert, `DPF-WP-02` hat [Release Report und Pack Dry Run Evidence](./release-report-pack-dry-run-evidence.md) nachgezogen und `DPF-WP-03` hat [Conditional Network Evidence CI](./conditional-network-evidence-ci.md) nachgezogen. Der aktuelle Export Lock erwartet 115 Package-Exports inklusive `./design-tokens/xtheme-token-alias-layer`, `./catalog/epic13-rc1-migration-notes`, `./catalog/epic13-rc1-gate-matrix-ci-handoff`, `./catalog/epic13-release-report-pack-dry-run-evidence`, `./catalog/epic13-conditional-network-evidence-ci`, `./rmt-language/kernel-trust-authority`, `./rmt-language/kernel-security-regression`, `./catalog/epic14-rmt-tooling`, `./catalog/epic14-lsp-handoff` sowie der klassischen und vNext RMT-Tooling-Surface.
+Nach `WP-E13-04` hat `WP-E13-05` die Known Residual Triage unter [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) vorbereitet, `WP-E13-08` hat [Visual Owner Artifacts](./visual-owner-artifacts.md) normalisiert, `WP-E13-09` hat [RMT Production Readiness](./rmt-production-readiness.md) gebuendelt, `WP-E13-10` hat [Docs RMT Production Hardening](./docs-rmt-production-hardening.md) abgeschlossen, `WP-E13-11` hat [Trusted DOM Boundary Browser Proof](./trusted-dom-boundary-browser-proof.md) abgeschlossen, `WP-E13-12` hat [RC1 Migration Notes](./rc1-migration-notes.md) abgeschlossen, `WP-E13-13` hat [RC1 Gate Matrix und CI-Handoff](./rc1-gate-matrix-ci-handoff.md) registriert, `DPF-WP-02` hat [Release Report und Pack Dry Run Evidence](./release-report-pack-dry-run-evidence.md) nachgezogen und `DPF-WP-03` hat [Conditional Network Evidence CI](./conditional-network-evidence-ci.md) nachgezogen. Der aktuelle Export Lock erwartet 124 Package-Exports inklusive `./design-tokens/xtheme-token-alias-layer`, `./catalog/epic13-rc1-migration-notes`, `./catalog/epic13-rc1-gate-matrix-ci-handoff`, `./catalog/epic13-release-report-pack-dry-run-evidence`, `./catalog/epic13-conditional-network-evidence-ci`, `./rmt/dom-descriptor-renderer`, `./rmt/component-capability-registry`, `./rmt/state-selector-runtime`, `./rmt/action-effect-runtime`, `./rmt/event-routing-runtime`, `./rmt/surface-resource-graph-runtime`, `./rmt/native-shell-runtime`, `./rmt/node-ssr-adapter`, `./rmt-language/app-platform-tooling`, `./rmt-language/kernel-trust-authority`, `./rmt-language/kernel-security-regression`, `./catalog/epic14-rmt-tooling`, `./catalog/epic14-lsp-handoff` sowie der klassischen und vNext RMT-Tooling-Surface.

package/docs/public-component-types.md

@@ -66,13 +66,13 @@ Jede Komponenten-Datei beschreibt:
 node scripts/run_xtend_tests.js components
 ```
 
-Die Component-Suite enthaelt ab `ER-WP-34` den Sub-Gate `component-public-types`. Nach `RC1TB-WP-03` prueft er die Shared-Type-Helfer, alle 42 priorisierten `.d.ts` Dateien, Eventnamen, Detail-Typen, API-Methoden und Element-/Window-Mappings.
+Die Component-Suite enthaelt ab `ER-WP-34` den Sub-Gate `component-public-types`. Nach `RC1TB-WP-03` prueft er die Shared-Type-Helfer, alle 44 priorisierten `.d.ts` Dateien, Eventnamen, Detail-Typen, API-Methoden und Element-/Window-Mappings.
 
 Ab `WP-TypeExports-09` ist der Component-Wildcard-Export auch im produktiven TypeExports-Handoff abgedeckt. `./components/*` bleibt eine adjacent-Declaration-Grenze: Consumer bekommen `components/*.d.ts` ueber die nebenliegenden Dateien, waehrend `node scripts/run_xtend_tests.js type-exports --json` verhindert, dass neue Public Component Exports ohne Type-Entscheidung in die Package Surface geraten.
 
 ## Coverage-Status
 
-Nach `RC1TB-WP-03` stehen `types` in der Component Catalog Coverage Matrix bei `42/42`. `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` sind die aktuelle `enterprise-ready` Referenzlinie mit Public Types, Component-Suite, Fixture, A11y und Performance-Profil. `xstate` besitzt Public Types fuer Boundary Contract, RMT State Adapter, Lifecycle Events und Diagnostics. `x-utils` besitzt Public Types fuer Utility Contract, Import Policy, Boundary Snapshot, UI Effects, Template API sowie die Events `xutils:import-policy-check` und `xutils:ui-effects-change`.
+Nach `RC1TB-WP-03` stehen `types` in der Component Catalog Coverage Matrix bei `44/44`. `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` sind die aktuelle `enterprise-ready` Referenzlinie mit Public Types, Component-Suite, Fixture, A11y und Performance-Profil. `xstate` besitzt Public Types fuer Boundary Contract, RMT State Adapter, Lifecycle Events und Diagnostics. `x-utils` besitzt Public Types fuer Utility Contract, Import Policy, Boundary Snapshot, UI Effects, Template API sowie die Events `xutils:import-policy-check` und `xutils:ui-effects-change`.
 
 Es gibt nach `WP-E12-09` keinen verbleibenden Type-Gap. Seit `WP-E13-05` sind auch die frueheren Boundary-Residuals geschlossen: `xstate` ist `closed-as-runtime-boundary`, `x-utils` ist `closed-as-utility-boundary`. Beide bleiben Public-Type-Boundaries, aber keine offenen Type- oder Performance-Aufgaben.
 

package/docs/quick-start-guide.md

@@ -1,6 +1,8 @@
 # Quick Start Guide
 
-Dieser Guide bringt eine minimale XTend-App lokal zum Laufen. Ziel ist ein kleiner, nachvollziehbarer Startpunkt ohne CDN, ohne Build-Schritt und ohne Framework-Zwang.
+Dieser Guide bringt dich von einer lokalen XTend-Seite zu einer kleinen
+RMT-vNext-App-Shell. Der schnellste Einstieg bleibt HTML mit Web Components;
+der empfohlene Ausbaupfad fuer Apps ist RMT-first.
 
 ## Voraussetzungen
 
@@ -8,7 +10,7 @@ Dieser Guide bringt eine minimale XTend-App lokal zum Laufen. Ziel ist ein klein
 - ein lokaler Checkout des XTend-Repositories
 - ein Browser mit Custom-Elements- und ES-Module-Support
 
-XTend laeuft im Kern als lokales ES-Module- und Web-Component-Framework. Fuer Entwicklung und Tests wird der lokale Dev Server genutzt.
+Starte den lokalen Dev Server:
 
 ```bash
 npm run dev:local
@@ -16,7 +18,7 @@ npm run dev:local
 
 Der Server liefert die App normalerweise unter `http://127.0.0.1:4173/` aus.
 
-## Minimaler Host
+## 1. Minimalen Host starten
 
 Lege im Projekt eine HTML-Datei an, zum Beispiel `quick-start.html`:
 
@@ -35,8 +37,6 @@ Lege im Projekt eine HTML-Datei an, zum Beispiel `quick-start.html`:
   </script>
 </head>
 <body>
-  <x-theme></x-theme>
-
   <main>
     <x-section layout="column" label="Quick Start">
       <h1>Hallo XTend</h1>
@@ -48,68 +48,129 @@ Lege im Projekt eine HTML-Datei an, zum Beispiel `quick-start.html`:
 </html>
 ```
 
-Danach oeffnest du `http://127.0.0.1:4173/quick-start.html`.
+Oeffne danach `http://127.0.0.1:4173/quick-start.html`.
 
-## Was passiert hier?
+Was passiert hier?
 
-- `xtend-loader.js` ist der kanonische lokale Loader.
-- `components/manifest.json` ist die lokale Component Registry.
-- Die Loader-StyleRegistry bringt Runtime-Critical CSS fuer Tokens, Skeletons und FOUC-Schutz selbst mit.
-- `meta name="xtend-preload"` laedt die kritischen Komponenten frueh.
-- `x-theme` initialisiert Theme-Unterstuetzung.
-- `x-section` und `x-button` sind normale XTend Web Components.
+- `xtend-loader.js` ist der lokale Loader.
+- `components/manifest.json` ist die Component Registry.
+- `meta name="xtend-preload"` laedt kritische Komponenten frueh.
+- `x-theme` ist ein Infrastrukturmodul; `x-section` und `x-button` sind
+  normale XTend Web Components.
+- `/xtend.css` ist optional und dient Host-Theming.
 
-Die App bleibt Vanilla HTML. XTend uebernimmt nur Loader, Komponenten, Styling- und Runtime-Kontrakte.
+## 2. App Shell in RMT vNext beschreiben
 
-`/xtend.css` ist optional. Der Dateiname bleibt der kanonische XTend-Standard fuer Host-Theming und gezielte 3rd-Party-Anpassungen, ist aber nicht noetig, damit der Loader ohne ungestyltes Pop-In bootet.
+Wenn aus der Seite eine App wird, soll die Shell in RMT liegen. RMT vNext
+beschreibt UI-Struktur, State, Actions, Events, Surfaces und Scheduling in
+einer lesbaren `.rmt` Quelle.
 
-## Optional: Routing
+Lege zum Beispiel `app.rmt` an:
 
-Wenn du eine SPA brauchst, fuegst du `x-router` und `x-link` hinzu:
+```rmt
+template quickstart.app {
+  state counter type number initial 0
 
-```html
-<meta name="xtend-preload" content="x-theme,x-link,x-router,x-section">
-
-<nav>
-  <x-link href="/home">Home</x-link>
-  <x-link href="/about">About</x-link>
-</nav>
-
-<x-router mode="hash" document-title-template="{{title}} | Quick Start">
-  <x-route path="/" component="x-section" title="Home"></x-route>
-  <x-route path="/home" component="x-section" title="Home"></x-route>
-  <x-route path="/about" component="x-section" title="About"></x-route>
-</x-router>
+  selector counterLabel from state counter {
+    output text
+  }
+
+  action increment {
+    input amount number
+    reduce state.counter = input.amount
+    emit counter.changed with action increment
+  }
+
+  portal app root "#app-root" layer surface
+
+  surface home kind page component x-section {
+    source state counter
+    portal app
+    key route.path
+
+    lane visible weight 80 {
+      hydrate x-section from state counter
+    }
+
+    on click target button.primary -> action increment {
+      payload amount from 1
+    }
+  }
+}
 ```
 
-Der Router schreibt pro Route den Seitentitel. Fuer SEO-nahe Apps koennen Titel und Meta-Daten auch aus RMT Route Records kommen.
+Dieses Dokument ist kein Runtime-Import und keine Framework-Komponente. Es ist
+die App-Beschreibung: Der Compiler erzeugt daraus Core-/Kernel-Records, die
+Host-Adapter mit XTend Components, XRouter und Fabric verbinden koennen.
+
+## 3. XTend UI aus RMT materialisieren
+
+Fuer Runtime-Hosts verbindet die Component Capability Registry RMT-Descriptoren
+mit den vorhandenen XTend-Komponenten aus dem Manifest. Dadurch bleiben
+Component Contracts, Events, Slots, Parts und State-Bindings die gemeinsame
+Quelle der Wahrheit:
+
+```js
+import {
+  createRmtComponentCapabilityRegistry
+} from '@ccslabs/xtend/rmt/component-capability-registry';
+import {
+  createRmtDomDescriptorRenderer
+} from '@ccslabs/xtend/rmt/dom-descriptor-renderer';
+
+const registry = createRmtComponentCapabilityRegistry({ manifest, sourceTexts });
+const renderer = createRmtDomDescriptorRenderer({ documentTarget: document });
+
+renderer.renderKeyed(root, [
+  registry.buildComponentDescriptor({
+    tag: 'x-button',
+    key: 'primary-action',
+    attributes: { variant: 'primary' },
+    slots: { default: { text: 'Loslegen' } },
+    events: { click: 'quickstart.increment' }
+  })
+], {
+  componentRegistry: registry,
+  dispatchEvent: actions.dispatch,
+  stateBridge
+});
+```
 
-## Optional: RMT-first denken
+So koennen RMT-Primitives XTend UI nutzen, ohne Shadow-DOM-Patches,
+komponentenspezifische Renderer oder manuelle HTML-Sinks einzubauen.
 
-Fuer groessere Apps empfiehlt sich der RMT-first Pfad: Die Shell, Routes, Schedules und spaeter Komponentenbindungen werden deklarativ in einem `.rmt` Dokument beschrieben. XTend bleibt dann der UI-Adapter, XRouter der Routing-Adapter und XTendRMT der Scheduler.
+## 4. Serverseitig vorhydrieren
 
-Der lokale XTend-Dev-Server liefert `.rmt` mit dem nativen MIME-Type `application/vnd.xtendrmt.rmt+json` aus. Neue Apps sollten deshalb direkt `.rmt` verwenden; JSON-Endungen sind nur noch ein Kompatibilitaetsfallback fuer Hosts ohne eigene MIME-Konfiguration.
+Node-Hosts koennen dieselbe RMT-Beschreibung fuer SSR und inkrementelles JSONL
+nutzen. Der Adapter bleibt framework-neutral und startet keinen eigenen
+HTTP-Server:
 
-Minimaler Route Record:
+```js
+import {
+  createRmtNodeSsrAdapter
+} from '@ccslabs/xtend/rmt/node-ssr-adapter';
 
-```json
-{
-  "id": "home",
-  "path": "/home",
-  "router": "xtend.xrouter",
-  "component": "page.home",
-  "title": "Home",
-  "documentTitle": "Home | Quick Start",
-  "template": "home.shell",
-  "schedule": "route.visible.render"
-}
+const adapter = createRmtNodeSsrAdapter({ manifest, sourceTexts });
+const result = await adapter.render({ source, filePath: 'app.rmt' });
 ```
 
-Fuer eine minimale native App-Shell kannst du in einer IDE mit RMT Snippets den Prefix `rmt-app` nutzen. Der Snippet-Katalog liegt in `tools/rmt-language/snippets/` und erzeugt direkt `.rmt` Authoring-Strukturen.
+PHP/Laravel-Hosts nutzen denselben clientseitigen Wire-Shape ueber das
+Single-File-Modul:
 
-## RMT lokal pruefen
+```php
+require __DIR__ . '/xtendrmt/rmt-php-ssr-adapter.php';
 
-Der Standard-Gate fuer ein einzelnes Dokument ist:
+$adapter = createRmtPhpSsrAdapter(['manifest' => $manifest]);
+$result = $adapter->render(['coreDocument' => $coreDocument]);
+```
+
+Mehr dazu:
+[RMT Node SSR Adapter](./rmt-node-ssr-adapter.md) und
+[RMT PHP/Laravel SSR Adapter](./rmt-php-ssr-adapter.md).
+
+## 5. RMT lokal pruefen
+
+Der Standardcheck fuer ein einzelnes Dokument ist:
 
 ```bash
 xt rmt lint app.rmt
@@ -127,9 +188,11 @@ AI-Agenten koennen den Repair Report nutzen:
 xt rmt lint app.rmt --agent
 ```
 
-Der Agent Report enthaelt `repairPlan`, `fixOrder`, `confidence`, `impact`, `relatedDiagnostics` und erklaerte No-Ops fuer bewusst nicht automatisierte Reparaturen.
+Der Agent Report enthaelt `repairPlan`, `fixOrder`, `confidence`, `impact`,
+`relatedDiagnostics` und erklaerte No-Ops fuer bewusst nicht automatisierte
+Reparaturen.
 
-## Editor-Unterstuetzung
+## 6. Editor-Unterstuetzung aktivieren
 
 Der RMT Language Server startet lokal ueber:
 
@@ -137,16 +200,21 @@ Der RMT Language Server startet lokal ueber:
 node tools/rmt-language-server/server.js
 ```
 
-Er liefert Diagnostics, Completion, Hover, Document Symbols, Definition und Code Actions. VS Code, JetBrains, Neovim und Helix koennen den Server ueber stdio anbinden. Die Setup-Hinweise stehen in [RMT Language Server und Editor Setup](./rmt-language-server.md).
-
-Fuer den ersten Einstieg reicht die HTML-Variante. Sobald Routing, Scheduling, Hydration oder mehrere Frameworks zusammenspielen, ist `.rmt` mit Linter und LSP der stabilere Ausbaupfad.
+Er liefert Diagnostics, Completion, Hover, Document Symbols, Definition und
+Code Actions. VS Code, JetBrains, Neovim und Helix koennen den Server ueber
+stdio anbinden. Fuer eine minimale native App-Shell kannst du in einer IDE mit
+RMT Snippets den Prefix `rmt-app` nutzen; fuer vNext-Primitives ist
+`rmt-vnext-primitive-shell` der schnellste Start.
 
 ## Naechste Schritte
 
+- [RMT vNext Authoring Guide](./rmt-vnext-authoring.md)
+- [RMT vNext Component Primitives und XTend UI](./rmt-vnext-component-primitives.md)
+- [RMT Node SSR Adapter](./rmt-node-ssr-adapter.md)
+- [RMT PHP/Laravel SSR Adapter](./rmt-php-ssr-adapter.md)
+- [XTendRMT Developer Overview](./xtendrmt-overview.md)
+- [RMT Linter und AI-Agent Repair Report](./rmt-linter.md)
+- [RMT Language Server und Editor Setup](./rmt-language-server.md)
 - [XTend Loader](./xtend-loader.md)
 - [Manifest-Format](./manifest.md)
 - [Komponenten-Entwicklung](./components.md)
-- [XTendRMT App-DSL Reference](./xtendrmt-app-dsl.md)
-- [RMT-first XTend Apps](./rmt-first-xtend-apps.md)
-- [RMT Linter und AI-Agent Repair Report](./rmt-linter.md)
-- [RMT Language Server und Editor Setup](./rmt-language-server.md)

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

@@ -0,0 +1,101 @@
+# 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`
+- Local gate: `node scripts/run_xtend_tests.js rmt-action-effect-runtime --json`
+- Next: `WP-E18-09`
+
+## Purpose
+
+The Action Effect Runtime turns common app flows into native RMT platform
+primitives. Apps can load fixture, REST, SSR or host-adapter data; update typed
+state; publish feedback; navigate; focus controls; lazy-load modules; and own
+resources without product-local action frameworks.
+
+The runtime is deliberately domain-neutral. It does not define product surfaces
+or record taxonomies. Developers provide their own actions, contracts, adapters,
+effects and resources.
+
+## DataSources
+
+Supported datasource kinds:
+
+- `fixture`: returns static fixture records for local app fixtures and tests.
+- `rest`: calls an injected adapter with an endpoint and payload.
+- `ssr`: reads a prehydrated payload and can project it with `resultPath`.
+- `host`: calls an explicit host adapter for mutations or platform commands.
+
+Runtime code never reaches for global network APIs directly. REST and host work
+through injected adapters so browser, server, test and shell environments can
+choose their own transport policy.
+
+## Actions
+
+An action can declare:
+
+- `datasource`
+- `resultState`
+- `loadingState`
+- `statusState`
+- `effects`
+- `resources`
+- `resourceOwner`
+- `cancelable`
+
+`runAction(id, payload)` moves the action through loading, success, error or
+cancelled states. If a typed state runtime is passed in, loading and status are
+written through `setState` and `patchState`, while datasource results can be
+stored in `resultState`.
+
+## Effects
+
+Supported effect kinds:
+
+- `toast` and `feedback`
+- `navigation`
+- `focus`
+- `lazy-import`
+- `side-effect`
+
+Feedback, navigation, focus and custom side effects use injected adapters.
+Lazy imports are modeled as resources, which means they can share the same
+ownership and cleanup model as other runtime resources.
+
+## Resource Ownership
+
+Supported resource kinds:
+
+- `object-url`
+- `stream`
+- `observer`
+- `timer`
+- `lazy-import`
+
+Resources are acquired under an owner, normally the action id. The resource
+manager exposes `releaseOwner(ownerId)` so surface destroy, render-unit destroy
+or action cancel can clean up only the resources they own.
+
+## Diagnostics
+
+The runtime emits diagnostics with
+`xtend.epic18.rmt-action-effect-diagnostic.v1` on the
+`rmt.app_platform.action_effect` channel. Loading, success, error and cancel
+are all visible in the local runtime history and in an optional diagnostics hub.
+
+## Boundaries
+
+- The RMT kernel imports no XTend UI components.
+- Data access goes through injected adapters.
+- Product-local action frameworks are not part of the platform contract.
+- Product flow names remain app code, not framework defaults.
+- Normal app UI still uses RMT templates and DOM descriptors instead of HTML
+  string renderers.
+
+## Handoff
+
+`WP-E18-09` builds on this runtime by connecting declarative DOM and custom
+events to actions. The event layer should reuse the Action Effect Runtime
+instead of creating another action execution path.

package/docs/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/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/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.