@ccslabs/xtend 0.1.0-rc.1 → 0.1.2

package/docs/de/rmt-language-server.md

@@ -0,0 +1,234 @@
+# RMT Language Server und Editor Setup
+
+- Status: produktiv vorbereitet ab `WP-E14-14`
+- Contract: `xtend.rmt.editor-packaging.v1`
+- Language Server: `xtend.rmt.language-server.v1`
+- Snippet Catalog: `xtend.rmt.snippet-catalog.v1`
+- Epic 14 Handoff: `xtend.epic14.lsp-handoff.v1`
+- Primaerer Dateityp: `.rmt`
+- Lokale Gates:
+  - `node scripts/run_xtend_tests.js rmt-editor-packaging --json`
+  - `node scripts/run_xtend_tests.js rmt-tooling-docs --json`
+  - `node scripts/run_xtend_tests.js epic14-lsp-handoff --json`
+
+## Ziel
+
+Das RMT Tooling ist editor-agnostisch. Die fachliche Source of Truth liegt in:
+
+- `tools/rmt-language`
+- `tools/rmt-linter`
+- `tools/rmt-language-server`
+
+Editor-Packages duerfen Snippets, Syntax-Highlighting und Startbefehle fuer den LSP bereitstellen. Sie duerfen keine zweite RMT-Semantik implementieren.
+
+## Language Server starten
+
+Der Server spricht stdio JSON-RPC:
+
+```bash
+node tools/rmt-language-server/server.js
+```
+
+Der Server bietet aktuell:
+
+- Diagnostics
+- Completion
+- Hover
+- Document Symbols
+- Definition
+- Code Actions
+
+Der LSP nutzt denselben Diagnosekern wie `xt rmt lint`. Editor-Integrationen sollen deshalb keine eigenen RMT-Regeln pflegen.
+
+## LSP Capability Matrix
+
+| Capability | Protokoll / Oberflaeche | Status | Source of Truth | Gate |
+|------------|--------------------------|--------|-----------------|------|
+| Diagnostics | `textDocument/publishDiagnostics` | implemented | `xtend.rmt.linter.rule-engine.v1` | `rmt-linter-rules` |
+| Completion | `textDocument/completion` | implemented | `xtend.rmt.completion-provider.v1` | `rmt-completions` |
+| Hover | `textDocument/hover` | implemented | `xtend.rmt.hover-provider.v1` | `rmt-navigation` |
+| Document Symbols | `textDocument/documentSymbol` | implemented | `xtend.rmt.document-symbols-provider.v1` | `rmt-navigation` |
+| Definition | `textDocument/definition` | implemented | `xtend.rmt.definition-provider.v1` | `rmt-navigation` |
+| Code Actions | `textDocument/codeAction` | implemented | `xtend.rmt.code-action-provider.v1` | `rmt-code-actions` |
+| Agent Repair Report | `xt rmt lint --agent` | implemented | `xtend.rmt.ai-agent-repair-report.v1` | `rmt-agent-report` |
+| Snippets | Editor Packaging | implemented | `xtend.rmt.snippet-catalog.v1` | `rmt-editor-packaging` |
+| Workspace Symbols | `workspace/symbol` | planned | Project Index Follow-up | future |
+| Rename | `textDocument/rename` | planned | Safe Refactor Follow-up | future |
+| References | `textDocument/references` | planned | Project Index Follow-up | future |
+| Semantic Tokens | `textDocument/semanticTokens` | planned | Syntax Highlighting Follow-up | future |
+| Formatting | `textDocument/formatting` | planned | Formatter Follow-up | future |
+
+## Known Limitations
+
+- RMT ist im aktuellen Authoring-MVP weiter JSON-basiert. Eine freundlichere DSL-Syntax ist Folgearbeit.
+- `textDocument/formatting` ist geplant, aber nicht produktiv freigegeben.
+- `workspace/symbol`, `textDocument/rename` und `textDocument/references` brauchen einen projektweiten Index und bleiben bewusst ausserhalb des MVP.
+- Marketplace-Packaging fuer einzelne Editoren ist nicht Teil von Epic 14. Die generischen LSP-Setups bleiben der aktuelle Integrationspfad.
+- Der Language Server fuehrt keine XTend-Komponenten aus, startet keinen XRouter und materialisiert kein DOM.
+- `.rmt.json` bleibt lesbar, wird aber als Fallback behandelt und soll in neuen Projekten nicht der Normalpfad sein.
+
+## Snippets
+
+Der editor-agnostische Snippet-Katalog liegt in:
+
+```text
+tools/rmt-language/snippets/index.js
+```
+
+Das VS-Code-kompatible Exportformat liegt in:
+
+```text
+tools/rmt-language/snippets/rmt.code-snippets
+```
+
+Alle Snippets erzeugen native `.rmt` Authoring-Strukturen. `.rmt.json` bleibt nur ein Parser-/Linter-Fallback und soll in neuen Snippets nicht genutzt werden.
+
+Wichtige Prefixes:
+
+| Prefix | Zweck |
+|--------|-------|
+| `rmt-app` | minimale native App-Shell |
+| `rmt-component` | XTend Component Record |
+| `rmt-route` | XRouter Route Record |
+| `rmt-schedule` | Schedule Policy |
+| `rmt-template-dom` | sicheres `dom_descriptor` Template |
+| `rmt-template-html` | `html_fragment` mit Trusted-DOM-Boundary |
+
+## VS Code
+
+Die VS-Code-Integration liegt in:
+
+```text
+tools/rmt-editor/vscode
+```
+
+Es registriert:
+
+- Language ID `rmt`
+- Dateiendung `.rmt`
+- 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`
+- 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
+{
+  "command": "node",
+  "args": ["tools/rmt-language-server/server.js"]
+}
+```
+
+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.
+
+Empfohlene Werte:
+
+- Language ID: `rmt`
+- Extension: `.rmt`
+- Command: `node`
+- Args: `tools/rmt-language-server/server.js`
+
+## Neovim
+
+Minimaler `nvim-lspconfig`-kompatibler Startpunkt:
+
+```lua
+local lspconfig = require('lspconfig')
+local configs = require('lspconfig.configs')
+
+configs.xtendrmt = {
+  default_config = {
+    cmd = { 'node', 'tools/rmt-language-server/server.js' },
+    filetypes = { 'rmt' },
+    root_dir = lspconfig.util.root_pattern('package.json', '.git')
+  }
+}
+
+lspconfig.xtendrmt.setup({})
+```
+
+## Helix
+
+Beispiel fuer `languages.toml`:
+
+```toml
+[[language]]
+name = "rmt"
+scope = "source.rmt"
+file-types = ["rmt"]
+language-servers = ["xtendrmt"]
+
+[language-server.xtendrmt]
+command = "node"
+args = ["tools/rmt-language-server/server.js"]
+```
+
+## Boundary
+
+Das Editor-Packaging darf keine XTend-Komponenten ausfuehren, keinen XRouter starten und keine DOM-Seiteneffekte erzeugen. Es startet nur den LSP und stellt statische Snippets bereit.
+
+## Verwandte Guides
+
+- [RMT Linter und AI-Agent Repair Report](./rmt-linter.md)
+- [XTendRMT Native Authoring Guide](./xtendrmt-native-authoring.md)
+- [Quick Start Guide](./quick-start-guide.md)
+- [Epic 14 Abschluss und LSP Handoff](../development/XTendRMT-Epic14-Abschluss-und-LSP-Handoff.md)

package/docs/de/rmt-lifecycle-demo.md

@@ -0,0 +1,24 @@
+# RMT Lifecycle Demo
+
+Contract: `xtend.rmt.lifecycle-demo.v1`
+
+Die Lifecycle-Demo zeigt den kompletten Pfad von RMT Authoring bis zur
+oeffnbaren XTend App:
+
+1. `xtendrmt/rmt-lifecycle-demo.rmt` ist das RMT vNext Template.
+2. `node xtend-builder/scaffold.js rmt-lifecycle-demo --write --json` kompiliert
+   das Template in `xtendrmt/rmt-lifecycle-demo.core.json`.
+3. Derselbe Scaffold-Build schreibt die generierten Artefakte:
+   `components/x-rmt-lifecycle-demo.js`,
+   `xtendrmt/rmt-lifecycle-demo.app.js`,
+   `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 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
+Gate `node scripts/run_xtend_tests.js rmt-lifecycle-demo --json` zusammen.
+
+Die generierten Dateien sind absichtlich mit `@generated by XTend Scaffold RMT
+lifecycle build` markiert. Aenderungen sollen am vNext Template oder am
+Scaffold-Generator erfolgen, nicht direkt an den generierten Artefakten.

package/docs/de/rmt-linter.md

@@ -0,0 +1,140 @@
+# RMT Linter und AI-Agent Repair Report
+
+- Status: produktiv vorbereitet ab `WP-E14-14`
+- Contract: `xtend.rmt.tooling-docs.v1`
+- Linter Report: `xtend.rmt.linter.report.v1`
+- Agent Report: `xtend.rmt.ai-agent-repair-report.v1`
+- Primaerer Dateityp: `.rmt`
+- Lokaler Gate: `node scripts/run_xtend_tests.js rmt-tooling-docs --json`
+
+## Zweck
+
+Der RMT Linter macht native `.rmt` Dokumente lokal, in CI und fuer AI-Agenten pruefbar. Er nutzt dieselbe Sprachebene wie der RMT Language Server:
+
+- Source Model
+- Parser und Format Adapter
+- Semantic Graph
+- Linter Rules
+- Code Actions
+- Agent Repair Report
+
+Der Linter fuehrt keine XTend-Komponenten aus, startet keinen XRouter und materialisiert kein DOM. Er analysiert RMT als Sprache.
+
+## Standardbefehl
+
+```bash
+xt rmt lint app.rmt
+```
+
+Der Langpfad bleibt ebenfalls gueltig:
+
+```bash
+xtend rmt lint app.rmt
+```
+
+Directory- und einfache Glob-Targets sind moeglich:
+
+```bash
+xt rmt lint tests/rmt-language/fixtures
+xt rmt lint "tests/rmt-language/fixtures/*.rmt" --json
+```
+
+## JSON Report
+
+```bash
+xt rmt lint app.rmt --json
+```
+
+Der Report ist fuer CI und andere Tools gedacht:
+
+```json
+{
+  "schema": "xtend.rmt.linter.report.v1",
+  "status": "failed",
+  "files": 1,
+  "diagnostics": []
+}
+```
+
+## Fail Policy
+
+Standard ist `--fail-on error`. Warnungen brechen den lokalen Lauf dann nicht ab.
+
+```bash
+xt rmt lint app.rmt --fail-on warning
+xt rmt lint app.rmt --fail-on info
+```
+
+Damit kann CI strenger laufen als lokale Authoring-Loops.
+
+## Agent Report
+
+AI-Agenten nutzen den Repair Report:
+
+```bash
+xt rmt lint app.rmt --agent
+```
+
+`--agent` impliziert JSON und liefert:
+
+- `diagnostics`
+- `repairPlan`
+- `fixOrder`
+- `noOps`
+- `confidence`
+- `impact`
+- `relatedDiagnostics`
+
+Nicht sicher automatisierbare Diagnosen werden bewusst als No-Op erklaert. Beispiele sind Syntax-Recovery, Inline-Script-Entfernung oder Component-Stubs, die Authoring-Kontext brauchen.
+
+## Diagnosecodes
+
+Wichtige Codes:
+
+| Code | Bedeutung |
+|------|-----------|
+| `rmt.syntax.invalid-json` | Das Dokument ist syntaktisch nicht parsebar |
+| `rmt.document.extension.fallback-used` | `.rmt.json` oder `.json` wird nur als Fallback genutzt |
+| `rmt.document.kind.missing` | `kind: "rmt_document"` fehlt |
+| `rmt.adapter.unknown` | Adapter-Referenz ist nicht definiert |
+| `rmt.ref.component.unresolved` | Component-Referenz ist nicht aufloesbar |
+| `rmt.ref.template.unresolved` | Template-Referenz ist nicht aufloesbar |
+| `rmt.ref.schedule.unresolved` | Schedule-Referenz ist nicht aufloesbar |
+| `rmt.ref.route.duplicate-path` | Route Path ist mehrfach definiert |
+| `rmt.fabric.lane.unknown` | Fabric/RMT Lane ist nicht bekannt |
+| `rmt.template.inline-script.refused` | Inline Script verletzt den Trusted-DOM-/Kernel-Boundary |
+
+## Quick Fixes
+
+Sichere Reparaturen kommen aus `xtend.rmt.code-action-provider.v1`.
+
+Der MVP unterstuetzt:
+
+- fehlende Schedules anlegen
+- fehlende Templates als `dom_descriptor` Stub anlegen
+- unbekannte Fabric Lanes auf `visible` setzen
+- unbekannte Hydration Policies auf `runtime_render` setzen
+- fehlende Route `documentTitle` ergaenzen
+- fehlende Schedule `endpointName` ergaenzen
+- `.rmt.json` per Command nach `.rmt` umbenennen
+
+## Regression Gate
+
+Die Tooling-Matrix liegt in:
+
+```bash
+node scripts/run_xtend_tests.js rmt-language-regression --json
+```
+
+Dieser Gate prueft valide, defekte, Legacy- und groessere RMT-Dokumente ueber Parser, Linter, CLI, LSP und Agent Report hinweg.
+
+## Editor Workflow
+
+Fuer IDEs siehe [RMT Language Server und Editor Setup](./rmt-language-server.md).
+
+Empfohlener Ablauf:
+
+1. Neues Dokument mit `rmt-app` Snippet erzeugen.
+2. In der IDE Diagnostics und Completion nutzen.
+3. Lokal mit `xt rmt lint app.rmt` pruefen.
+4. Fuer Agenten oder CI `xt rmt lint app.rmt --agent` nutzen.

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

@@ -0,0 +1,100 @@
+# RMT Node SSR Adapter
+
+Der Node SSR Adapter ist die leichtgewichtige serverseitige API fuer XTendRMT.
+Er erzeugt Light-DOM-HTML fuer XTend Custom Elements, Hydration-Payloads im
+RenderMan-kompatiblen Format und optional JSONL-Streaming fuer inkrementelle
+UI-Komponenten.
+
+Schema: `xtend.rmt.node-ssr-adapter.v1`
+
+```js
+import {
+  createRmtNodeSsrAdapter
+} from '@ccslabs/xtend/rmt/node-ssr-adapter';
+```
+
+Im Runtime-Paket steht dieselbe API ueber
+`@ccslabs/xtend-rmt/node-ssr-adapter` bereit.
+
+Fuer PHP/Laravel-Hosts stellt der
+[RMT PHP/Laravel SSR Adapter](./rmt-php-ssr-adapter.md) denselben
+Client-Wire-Contract bereit: HTML, Hydration, RenderMan-Chunks und JSONL-
+Frames bleiben kompatibel.
+
+## Architektur
+
+Der Adapter ist Host-Schicht, nicht neuer Renderer. RMT vNext beschreibt
+Source, State, Selectors, Actions, Events, Surfaces und Streams. Der Compiler
+erzeugt Core-/Kernel-Records. Die Component Capability Registry beschreibt
+alle XTend-Komponenten generisch. Der Node Adapter serialisiert daraus sichere
+serverseitige Startausgabe.
+
+Er instanziiert keine Custom Elements auf dem Server, greift nicht auf private
+Component-Interna zu, startet keinen HTTP-Server und verwendet keinen
+impliziten globalen Netzwerkzugriff.
+
+## API
+
+```js
+const adapter = createRmtNodeSsrAdapter({
+  manifest,
+  sourceTexts,
+  endpointHandlers: {
+    'ssr.hero': () => ({
+      html: '<x-hero>Hero</x-hero>',
+      trustBoundary: 'xtend.security.sanitizing-boundary.v1'
+    })
+  }
+});
+
+const result = await adapter.render({
+  source,
+  filePath: 'app.rmt'
+});
+```
+
+`render` akzeptiert RMT Source, Core Documents, Prepared Templates und DOM
+Descriptoren. Im Vollpaket wird Source automatisch ueber den vNext Compiler
+kompiliert. Runtime-only Hosts injizieren `compileRmtVNextSource`; fehlt diese
+Funktion, entsteht `rmt.node_ssr.compiler_required`.
+
+## Ausgabe
+
+`xtend.rmt.node-ssr-render-result.v1` enthaelt:
+
+- `html`
+- `head.preloads`
+- `renderman_template_chunk`
+- `server_prerender_hydrate` Hydration-Daten
+- `xtend.rmt.vnext-streaming-contract.v1`
+- Component Capability Marker
+- Diagnostics
+
+## JSONL Streaming
+
+`streamJsonl` liefert Frames mit
+`xtend.rmt.node-ssr-jsonl-frame.v1`. Wichtige Frame-Typen sind `start`,
+`component`, `html`, `hydration`, `diagnostic`, `complete` und `error`.
+
+Die Streaming-Capabilities bleiben kompatibel mit RMT vNext:
+
+- `stream.ssr.incremental`
+- `stream.hydration.chunked`
+
+## DataSources und Security
+
+DataSources werden nur ueber explizite Host-Resolver verarbeitet:
+`resolveDataSource`, `endpointHandlers`, `staticDataSources`, `fixtures` oder
+`fetchAdapter`. Fehlende Resolver melden `rmt.node_ssr.datasource_missing`.
+
+HTML-Fragmente brauchen eine Trust Boundary wie
+`xtend.security.sanitizing-boundary.v1` oder
+`xtend.security.streaming-boundary.v1`. Unsichere URLs, Event-Attribute,
+`srcdoc` und blockierte Tags werden diagnostiziert und bereinigt.
+
+## Gate
+
+```bash
+npm run test:rmt-node-ssr-adapter
+node scripts/run_xtend_tests.js rmt-node-ssr-adapter --json
+```

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

@@ -0,0 +1,120 @@
+# 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 kommt in dieser
+ersten Welle ohne Composer-Package und ohne Service Provider aus.
+
+Schema: `xtend.rmt.php-ssr-adapter.v1`
+
+Der Adapter ist auf Client-Wire-Ebene mit dem
+[RMT Node SSR Adapter](./rmt-node-ssr-adapter.md) austauschbar. HTML,
+Hydration, RenderMan-Chunks und JSONL-Frames nutzen dieselben Schemas:
+`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 die App. XTend Components bleiben die UI-Bausteine. Der PHP
+Adapter serialisiert serverseitiges Light DOM, Capability-Marker,
+Lazy-Import-Hints und Hydration-Payloads, ohne Custom Elements auf dem Server
+zu instanziieren.
+
+Keine Parallelstruktur:
+
+- kein Shadow-DOM-Rendering auf dem Server
+- keine privaten Component-Maps
+- kein Docs-App-Sonderpfad
+- kein eingebauter PHP-RMT-Compiler
+- kein impliziter Netzwerkzugriff
+- keine HTML-Ausgabe ohne Trust Boundary
+
+## 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]);
+```
+
+`render(...)` verarbeitet Core Documents, Prepared Templates und DOM
+Descriptoren direkt. `.rmt` Source braucht eine injizierte
+`compileRmtVNextSource`-Bridge. Ohne Bridge entsteht die blockierende Diagnose
+`rmt.php_ssr.compiler_required`.
+
+## Laravel Helpers
+
+```php
+return $adapter->toLaravelResponse($result);
+
+return $adapter->toLaravelStreamedResponse([
+    'coreDocument' => $coreDocument,
+]);
+```
+
+Wenn Laravel/Symfony Response-Klassen vorhanden sind, nutzt der Adapter diese
+direkt. Ohne Framework gibt er Arrays zurueck. Damit bleibt die Datei in
+Laravel, kleinen PHP-Hosts und Tests nutzbar.
+
+## JSONL Streaming
+
+`streamJsonl(...)` liefert newline-delimited JSON mit
+`xtend.rmt.node-ssr-jsonl-frame.v1`. Unterstuetzte Frames sind `start`,
+`component`, `html`, `hydration`, `diagnostic`, `complete` und `error`.
+
+Die Frames tragen dieselben Felder wie der Node Adapter: `requestId`,
+`sequence`, `operationId`, `variant`, `capability`, `lane`, `chunkKey`,
+`payload` und `diagnostics`. Dadurch muss die XTend Browser-Runtime nicht
+wissen, ob Node oder PHP/Laravel das Backend ist.
+
+## DataSources und Trust Boundaries
+
+Serverdaten kommen nur ueber explizite Host-Hooks:
+
+- `resolveDataSource`
+- `endpointHandlers`
+- `staticDataSources`
+- `fixtures`
+- `fetchAdapter`
+- `laravelContainerResolver`
+
+HTML-Fragmente 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 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. Parsedown
+bleibt Host-Boundary und fuellt nur den Content-Slot, waehrend die Shell aus
+RMT-Primitives, Hydration und RenderMan-Chunks kommt.
+
+## 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
+```

package/docs/de/rmt-production-readiness.md

@@ -0,0 +1,63 @@
+# RMT Production Readiness
+
+- Contract: `xtend.epic13.rmt-production-readiness.v1`
+- Report: `xtend.epic13.rmt-production-readiness-report.v1`
+- Workpackage: `WP-E13-09`
+- Lokaler Gate: `node scripts/run_xtend_tests.js epic13-rmt-production-readiness --json`
+- Package Script: `npm run test:epic13-rmt-production-readiness`
+- Publish Boundary: `private-until-release-owner-acceptance`
+
+## Zweck
+
+`WP-E13-09` buendelt den RMT-first App-Pfad fuer RC1. Das Paket fuehrt die bereits vorhandenen RMT-Gates zu einem produktionsnahen Schnitt zusammen: Shell-first App Shell, native RMT-Routen, XTend-Komponenten ueber Adapter, Fabric/Lane-Ingestion, Lifecycle Telemetry, Diagnostics und XTendRMT Artifact Parity.
+
+Das Bundle fuegt keine neuen App-Features hinzu. Es macht sichtbar, dass XTend Apps vollstaendig in RMT templated werden koennen, waehrend der RMT Kernel framework-agnostisch bleibt.
+
+## Source Gates
+
+```bash
+npm run test:rmt-compatibility
+npm run test:rmt-first-class-app
+npm run test:rmt-first-demo-app
+npm run test:rmt-artifact-parity
+npm run test:rmt-component-fabric-ingestion
+npm run test:rmt-component-lifecycle-telemetry
+npm run test:epic13-visual-owner-artifact
+```
+
+Der lokale WP09-Gate prueft diese Source Gates als statisches RC1-Bundle. Er fuehrt keine Netzwerkzugriffe und keinen externen Browser voraus.
+
+## Readiness-Domains
+
+| Domain | Evidence |
+| --- | --- |
+| Shell-first App Shell | `tests/fixtures/rmt-first-class-xtend-app.rmt`, `xtendrmt/rmt-first-demo-app.rmt` |
+| Routing | `xtend.xrouter` Adapter und RMT `routes` Records |
+| Components | `xtend.component` Adapter und RMT `components` Records |
+| Fabric/Lane | `xtend.component.fabric-lane-ingestion.v2` |
+| Lifecycle Telemetry | `xtend.component.lifecycle-telemetry.v1` |
+| Diagnostics | `rmt.state-scheduler-diagnostics` und Fabric Snapshots |
+| Artifact Parity | `xtend.rmt.artifact-parity.v1` |
+| Kernel Boundary | `no-rmt-kernel-import-of-xtend-types` |
+
+## Boundary
+
+RMT besitzt App Records, Routes, Schedules, Templates und Metadata. XTend-Ausfuehrung bleibt in Host-Adaptern:
+
+- XTend-Komponenten werden nicht in den RMT Kernel importiert.
+- XRouter wird ueber `xtend.xrouter` angeschlossen.
+- Fabric/Lane- und Telemetry-Signale werden ingestiert, aber nicht als harte Kernel-Abhaengigkeit modelliert.
+- React-, Vue-, Vanilla- und Custom-Hosts koennen eigene Adapter verwenden.
+
+## Referenzen
+
+- [RMT-first XTend Apps](./rmt-first-xtend-apps.md)
+- [RMT-first Demo-App](./rmt-first-demo-app.md)
+- [XTendRMT App-DSL](./xtendrmt-app-dsl.md)
+- [XTendRMT Native Authoring](./xtendrmt-native-authoring.md)
+- [XTend-Fabric RMT Lane Mapping](./xtend-fabric-rmt-lane-mapping.md)
+- [Visual Owner Artifacts](./visual-owner-artifacts.md)
+
+## Handoff
+
+`WP-E13-09` ist abgeschlossen. `WP-E13-10` hat [Docs RMT Production Hardening](./docs-rmt-production-hardening.md) nachgezogen und die Docs-App RMT Parsedown Shell fuer PROD-nahe Erweiterungen gehaertet. `WP-E13-11` hat [Trusted DOM Boundary Browser Proof](./trusted-dom-boundary-browser-proof.md) und `xtend.epic13.trusted-dom-boundary.v1` abgeschlossen. `WP-E13-12` hat [RC1 Migration Notes](./rc1-migration-notes.md) und `xtend.epic13.rc1-migration-notes-semver.v1` abgeschlossen. `WP-E13-13` hat [RC1 Gate Matrix und CI-Handoff](./rc1-gate-matrix-ci-handoff.md) und `xtend.epic13.rc1-gate-matrix-ci-handoff.v1` abgeschlossen.