@ccslabs/xtend 0.1.0-rc.1 → 0.1.2

package/docs/rmt-language-server.md

@@ -96,7 +96,7 @@ Wichtige Prefixes:
 
 ## VS Code
 
-Ein duennes Bridge-Package liegt in:
+Die VS-Code-Integration liegt in:
 
 ```text
 tools/rmt-editor/vscode
@@ -106,11 +106,31 @@ Es registriert:
 
 - Language ID `rmt`
 - Dateiendung `.rmt`
-- JSON-basierte TextMate-Grammatik
+- RMT-vNext-aware TextMate-Grammatik mit Legacy-JSON-Fallback
 - RMT Snippets
+- `vscode-languageclient` fuer den lokalen RMT Language Server
+- `$xtend-rmt-lint` Problem Matcher
+- XTend CLI Tasks und Debug-Console-Launch-Konfigurationen
 - Command `XTendRMT: Show Language Server Command`
-
-Bis ein voll gepackter VS-Code-LanguageClient freigegeben ist, kann ein generischer LSP-Client mit folgendem Befehl genutzt werden:
+- Command `XTendRMT: Start/Restart Language Server`
+- Command `XTendRMT: Run Active RMT Lint`
+- Command `XTendRMT: Run Workspace RMT Lint`
+- Command `XTendRMT: Run RMT Build Check`
+- Command `XTendRMT: Run Scaffold Verify`
+- Command `XTendRMT: Debug Language Server`
+- Command `XTendRMT: Debug Active RMT Lint`
+- Command `XTendRMT: Debug Active RMT Build`
+- Command `XTendRMT: Open XTend CLI Terminal`
+- Command `XTendRMT: Run XTend CLI Command...`
+- Command `XTendRMT: Run Agent Repair Report`
+- Command `XTendRMT: Run RMT Build Write`
+- Command `XTendRMT: Open VS Code Tasks Template`
+- Command `XTendRMT: Open VS Code Launch Template`
+- Command `XTendRMT: Show vNext Primitive Apply Experience`
+- Command `XTendRMT: Show vNext Primitive Code Action Preview`
+- Command `XTendRMT: Show vNext Primitive Command Handoff`
+
+Der gepackte LanguageClient startet den Server per stdio:
 
 ```json
 {
@@ -119,6 +139,43 @@ Bis ein voll gepackter VS-Code-LanguageClient freigegeben ist, kann ein generisc
 }
 ```
 
+Terminal-Tasks nutzen die XTend CLI als Orchestrator und pflegen keine eigene
+RMT-Semantik. Die Extension sucht die CLI im Workspace zuerst unter
+`xtend-builder/scaffold.js`, danach unter `node_modules/.bin/xt` und danach
+unter `node_modules/@ccslabs/xtend-cli/scaffold.js`. Falls ein Projekt anders
+aufgebaut ist, kann `xtendRmt.xtendCli.path` explizit auf ein Executable oder
+eine `scaffold.js` zeigen. Die versionierte Vorlage liegt unter:
+
+```text
+tools/rmt-editor/vscode/templates/tasks.json
+```
+
+Der Problem Matcher konsumiert die stabile Linter-Ausgabe:
+
+```bash
+xt rmt lint app.rmt --format problem-matcher --fail-on warning
+```
+
+Die Launch-Vorlage fuer die Debug Console liegt unter:
+
+```text
+tools/rmt-editor/vscode/templates/launch.json
+```
+
+Sie enthaelt Debug-Starts fuer Language Server, aktiven RMT Lint, aktiven RMT
+Build und Scaffold Verify. Das ist Tool-Debugging fuer Authoring-Workflows; ein
+eigener Debug Adapter fuer ausgefuehrte RMT-UI-Breakpoints bleibt bewusst
+ausserhalb dieses Slices.
+
+Die vNext-Primitive-Commands lesen CodeAction-Reports oder einzelne Actions
+aus der RMT-vNext-Tooling-Schicht und zeigen die drei Apply-Pfade getrennt im
+Output Channel:
+
+- sichere einzelne Quick-Fixes;
+- `source.fixAll.rmt.vnext.primitives` fuer alle sicheren WorkspaceEdits;
+- manuelle `xtend.rmt.vnext.extractKernelImport` Handoffs fuer Kernel-/Fabric-
+  Boundary-Verletzungen ohne automatischen WorkspaceEdit.
+
 ## JetBrains
 
 JetBrains-IDEs koennen ueber einen generischen LSP-Client oder ein lokales File-Watcher-/External-Tool-Setup angebunden werden.

package/docs/rmt-lifecycle-demo.md

@@ -11,10 +11,9 @@ oeffnbaren XTend App:
 3. Derselbe Scaffold-Build schreibt die generierten Artefakte:
    `components/x-rmt-lifecycle-demo.js`,
    `xtendrmt/rmt-lifecycle-demo.app.js`,
-   `xtendrmt-rmt-lifecycle-demo.html` und
    `tests/browser/fixtures/rmt-lifecycle-demo-smoke.html`.
 4. Die App kann ueber den lokalen HTTP-Server geoeffnet werden:
-   `node scripts/serve_xtend_dev.js --default xtendrmt-rmt-lifecycle-demo.html`.
+   `node scripts/serve_xtend_dev.js --default tests/browser/fixtures/rmt-lifecycle-demo-smoke.html`.
 
 Der Build-Report liegt in `xtendrmt/rmt-lifecycle-demo.scaffold.json`. Er
 haelt Source, Core Output, generierte XTend App, Browser-Smoke und den lokalen

package/docs/rmt-node-ssr-adapter.md

@@ -0,0 +1,144 @@
+# RMT Node SSR Adapter
+
+Der Node SSR Adapter ist die leichte serverseitige Host-Schicht fuer RMT
+vNext. Er erzeugt Light-DOM-HTML fuer XTend Custom Elements, Hydration-
+Payloads im bestehenden RenderMan-Shape und optional JSONL-Frames fuer
+inkrementelle UI-Ausgabe. Das Modul ist bewusst kein HTTP-Server und kein
+Parallelrenderer.
+
+Schema: `xtend.rmt.node-ssr-adapter.v1`
+
+Export:
+
+```js
+import {
+  createRmtNodeSsrAdapter
+} from '@ccslabs/xtend/rmt/node-ssr-adapter';
+```
+
+Das Runtime-Paket exportiert dieselbe API ueber
+`@ccslabs/xtend-rmt/node-ssr-adapter`.
+
+Fuer PHP/Laravel-Hosts gibt es denselben Client-Wire-Contract ueber den
+[RMT PHP/Laravel SSR Adapter](./rmt-php-ssr-adapter.md). Beide Adapter liefern
+kompatible HTML-, Hydration-, RenderMan-Chunk- und JSONL-Frames.
+
+## Rolle im Stack
+
+RMT bleibt die App-Beschreibung. Der Compiler erzeugt Core-/Kernel-Records,
+Fabric fuehrt Scheduling-Absicht aus, die Component Capability Registry
+beschreibt XTend UI generisch, und der Node SSR Adapter materialisiert daraus
+serverseitige Startausgabe.
+
+Der Adapter:
+
+- instanziiert keine Custom Elements auf dem Server
+- rendert kein Component-Shadow-DOM
+- nutzt keine privaten Component-Maps
+- startet keinen HTTP-Server
+- nutzt keinen impliziten globalen Netzwerkzugriff
+- serialisiert nur sichere Host-Ausgabe mit Trust-Boundary-Diagnostics
+
+## Public API
+
+```js
+const adapter = createRmtNodeSsrAdapter({
+  manifest,
+  sourceTexts,
+  endpointHandlers: {
+    'ssr.hero': () => ({
+      html: '<x-hero>Hero</x-hero>',
+      trustBoundary: 'xtend.security.sanitizing-boundary.v1'
+    })
+  },
+  sanitizeHtmlOutput(html) {
+    return html;
+  }
+});
+
+const result = await adapter.render({
+  source,
+  filePath: 'app.rmt'
+});
+
+for await (const line of adapter.streamJsonl({ source })) {
+  process.stdout.write(line);
+}
+```
+
+`render(input, options)` akzeptiert `.rmt` Source, RMT vNext Core Documents,
+Prepared Templates und DOM Descriptoren. Im Vollpaket wird die Source-
+Kompilierung automatisch ueber den bestehenden vNext Compiler verdrahtet. Im
+Runtime-only-Paket muss `compileRmtVNextSource` injiziert werden; sonst meldet
+der Adapter `rmt.node_ssr.compiler_required`.
+
+## Render-Ergebnis
+
+`adapter.render(...)` liefert `xtend.rmt.node-ssr-render-result.v1`:
+
+- `html`: serverseitiges Light DOM fuer XTend Custom Elements
+- `head.preloads`: Lazy-Import-Hints aus Component Capabilities
+- `chunks`: `renderman_template_chunk` im bestehenden
+  `server_prerender_hydrate`-Shape
+- `hydration`: serialisierbares Payload fuer die Browser-Hydration
+- `streamingContract`: vorhandener `xtend.rmt.vnext-streaming-contract.v1`
+  Contract, wenn das Dokument Streaming beschreibt
+- `componentCapabilities`: normalisierte XTend Component Capability Marker
+- `diagnostics`: blockierende und nicht-blockierende Host-Diagnostics
+
+## JSONL Streaming
+
+`streamJsonl(input, options)` erzeugt newline-delimited JSON Frames mit Schema
+`xtend.rmt.node-ssr-jsonl-frame.v1`.
+
+Frame-Typen:
+
+- `start`
+- `component`
+- `html`
+- `hydration`
+- `diagnostic`
+- `complete`
+- `error`
+
+Jeder Frame traegt `requestId`, `sequence`, `operationId`, `variant`,
+`capability`, `lane`, `chunkKey`, `payload` und `diagnostics`. SSR-Frames
+nutzen `stream.ssr.incremental`; Hydration-Frames nutzen
+`stream.hydration.chunked`.
+
+## DataSource Resolver
+
+Serverdaten sind immer Host-Verantwortung. Nutze eine der expliziten
+Integrationen:
+
+- `resolveDataSource(record, context)`
+- `endpointHandlers[target]`
+- `staticDataSources`
+- `fixtures`
+- `fetchAdapter(record, context)`
+
+Wenn ein RMT-Streaming- oder Endpoint-Record keinen Resolver hat, meldet der
+Adapter `rmt.node_ssr.datasource_missing`. Dadurch bleibt der Kernel frei von
+Host-Netzwerkannahmen.
+
+## Trust Boundary
+
+HTML-Fragmente aus Hosts, Endpoints oder Streaming muessen eine Boundary wie
+`xtend.security.sanitizing-boundary.v1` oder
+`xtend.security.streaming-boundary.v1` tragen. Unsichere URLs, Event-
+Attribute, `srcdoc` und blockierte Tags werden diagnostiziert und vom
+Fallback-Sanitizer entfernt. Produktive Hosts sollten `sanitizeHtmlOutput`
+injizieren.
+
+## Gates
+
+```bash
+npm run test:rmt-node-ssr-adapter
+node scripts/run_xtend_tests.js rmt-node-ssr-adapter --json
+```
+
+Der Adapter ist Teil des RMT vNext Primitive Gates:
+
+```bash
+npm run test:rmt-vnext-primitives:report
+```

package/docs/rmt-php-ssr-adapter.md

@@ -0,0 +1,158 @@
+# RMT PHP/Laravel SSR Adapter
+
+Der PHP SSR Adapter ist die Laravel-kompatible Host-Schicht fuer RMT vNext.
+Er liegt als portables Single-File-Modul unter
+`xtendrmt/rmt-php-ssr-adapter.php`, benoetigt PHP 8.1+ und hat in diesem Slice
+keine Composer- oder Service-Provider-Pflicht.
+
+Schema: `xtend.rmt.php-ssr-adapter.v1`
+
+Der Adapter ist auf Client-Wire-Ebene kompatibel mit dem
+[RMT Node SSR Adapter](./rmt-node-ssr-adapter.md). Beide liefern denselben
+Render-Result-, Hydration-, Chunk- und JSONL-Frame-Shape:
+`xtend.rmt.node-ssr-render-result.v1`,
+`xtend.rmt.node-ssr-hydration-payload.v1` und
+`xtend.rmt.node-ssr-jsonl-frame.v1`.
+
+## Rolle im Stack
+
+RMT beschreibt App Shell, State, DataSources, Surfaces, Events und Lanes. Der
+PHP Adapter materialisiert daraus serverseitiges Light DOM fuer XTend Custom
+Elements und uebergibt Hydration-Daten an die bestehende Browser-Runtime.
+
+Der Adapter:
+
+- instanziiert keine Custom Elements auf dem Server
+- rendert kein Shadow DOM
+- nutzt keine privaten Component-Maps
+- ist nicht an die Docs-App gekoppelt
+- fuehrt keinen PHP-RMT-Compiler mit
+- akzeptiert DataSources nur ueber explizite Host-Resolver
+
+## Public API
+
+```php
+require __DIR__ . '/xtendrmt/rmt-php-ssr-adapter.php';
+
+$adapter = createRmtPhpSsrAdapter([
+    'manifest' => $manifest,
+    'endpointHandlers' => [
+        'ssr.hero' => fn () => [
+            'html' => '<x-hero>Hero</x-hero>',
+            'trustBoundary' => 'xtend.security.sanitizing-boundary.v1',
+        ],
+    ],
+]);
+
+$result = $adapter->render([
+    'coreDocument' => $coreDocument,
+]);
+
+foreach ($adapter->streamJsonl(['coreDocument' => $coreDocument]) as $line) {
+    echo $line;
+}
+```
+
+`render($input, $options)` akzeptiert RMT vNext Core Documents, Prepared
+Templates und DOM Descriptoren direkt. `.rmt` Source wird nur verarbeitet, wenn
+ein Host eine `compileRmtVNextSource`-Bridge injiziert. Ohne Bridge meldet der
+Adapter `rmt.php_ssr.compiler_required`.
+
+## Laravel Helpers
+
+Die Helpers bleiben optional und aktivieren sich nur, wenn Laravel oder
+Symfony Response-Klassen bereits geladen sind:
+
+```php
+return $adapter->toLaravelResponse($result);
+
+return $adapter->toLaravelStreamedResponse([
+    'coreDocument' => $coreDocument,
+]);
+```
+
+Ohne Framework degradieren die Methoden sauber zu Arrays. Dadurch kann dieselbe
+Adapterdatei in Laravel, kleinen PHP-Hosts und Tests genutzt werden.
+
+## Render-Ergebnis
+
+`render(...)` liefert ein Array mit:
+
+- `schema`: `xtend.rmt.node-ssr-render-result.v1`
+- `adapterSchema`: `xtend.rmt.php-ssr-adapter.v1`
+- `html`: serverseitiges Light DOM fuer XTend Custom Elements
+- `head.preloads`: Lazy-Import-Hints aus Component Capabilities
+- `chunks`: `renderman_template_chunk` im `server_prerender_hydrate`-Shape
+- `response`: `renderman_template_prerender_response`
+- `hydration`: `xtend.rmt.node-ssr-hydration-payload.v1`
+- `streamingContract`: `xtend.rmt.vnext-streaming-contract.v1`, falls das
+  Dokument Streaming beschreibt
+- `componentCapabilities`: Marker fuer XTend Component Tags
+- `diagnostics`: PHP-spezifische Diagnostics unter `rmt.php_ssr.*`
+
+## JSONL Streaming
+
+`streamJsonl(...)` erzeugt newline-delimited JSON Frames mit
+`xtend.rmt.node-ssr-jsonl-frame.v1`.
+
+Frame-Typen:
+
+- `start`
+- `component`
+- `html`
+- `hydration`
+- `diagnostic`
+- `complete`
+- `error`
+
+Jeder Frame traegt `requestId`, `sequence`, `operationId`, `variant`,
+`capability`, `lane`, `chunkKey`, `payload` und `diagnostics`. SSR-Frames
+nutzen `stream.ssr.incremental`; Hydration-Frames nutzen
+`stream.hydration.chunked`.
+
+## DataSources und Security
+
+Serverdaten sind Host-Verantwortung. Der Adapter nutzt nur explizite Resolver:
+
+- `resolveDataSource`
+- `endpointHandlers`
+- `staticDataSources`
+- `fixtures`
+- `fetchAdapter`
+- `laravelContainerResolver`
+
+HTML-Fragmente brauchen eine Trust Boundary wie
+`xtend.security.sanitizing-boundary.v1` oder
+`xtend.security.streaming-boundary.v1`. Der eingebaute Fallback-Sanitizer
+blockt Event-Attribute, `srcdoc`, unsichere URLs und Script-/Frame-/Object-
+Tags. Produktive Hosts koennen `sanitizeHtmlOutput` injizieren.
+
+## Docs-App Integration
+
+Die Docs-App nutzt den Adapter nun direkt in `docs/index.php` fuer
+Shell-first-Prehydration.
+
+- Contract: `xtend.docs.php-ssr-prehydration.v1`
+- vNext Source: `docs/xtendrmt-docs-shell-vnext.rmt`
+- Compiler-Bridge: `scripts/compile_rmt_vnext_bridge.js`
+- JSONL Endpoint:
+  `index.php?xtend-docs-rmt-ssr=shell&format=jsonl&page={slug}&locale={locale}`
+
+Der Host injiziert `compileRmtVNextSource` ueber die Node-Bridge, rendert die
+Root-Shell als RMT DOM Descriptor und exposes `window.xtendDocsSsrPrehydration`
+mit Hydration, Chunks und Diagnostics. Parsedown bleibt Host-Boundary und
+fuellt weiterhin nur den Content-Slot.
+
+## Gates
+
+```bash
+npm run test:rmt-php-ssr-adapter
+npm run test:docs-php-ssr-prehydration
+node scripts/run_xtend_tests.js rmt-php-ssr-adapter --json
+```
+
+Empfohlene Regression:
+
+```bash
+node scripts/run_xtend_tests.js rmt-php-ssr-adapter rmt-node-ssr-adapter rmt-vnext-streaming rmt-vnext-component-primitives type-exports-rmt --json
+```

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