@ccslabs/xtend 0.1.0-rc.1

package/docs/rmt-dsl-authoring-polish.md

@@ -0,0 +1,122 @@
+# RMT DSL Authoring Polish
+
+Der Contract `xtend.rmt.dsl-authoring-polish.v1` bereitet eine freundlichere RMT-DSL fuer XTend Component Shells vor. Er macht RMT Authoring kuerzer, ohne XTend in den RMT Kernel einzubetten.
+
+Lokaler Gate:
+
+```bash
+node scripts/run_xtend_tests.js rmt-dsl-authoring-polish --json
+```
+
+## Warum dieses Paket existiert
+
+Nach `WP-E12-12` besitzt XTend ein produktives Design-Token-Vokabular. `WP-E12-13` nutzt diese Tokens, damit Shells, Slots, Styles, A11y, Events, Commands, Hydration, Fabric-Lanes und XRouter-Routen in RMT einfacher beschrieben werden koennen.
+
+RMT bleibt dabei host-neutral:
+
+- `xtend.component` rendert und hydriert Components im Host.
+- `xtend.xrouter` verbindet Route Records mit XRouter.
+- `xtend.fabric` und Telemetry bleiben Adapter-/Hostdaten.
+- `no-rmt-kernel-import-of-xtend-types` bleibt Pflicht.
+
+## Authoring-Aliase
+
+| Alias | Ziel |
+|-------|------|
+| `component` | XTend Component Record |
+| `shell` | Shell-Zustand, Slots, Parts und Fokus |
+| `slot` | Template-, Component- oder Text-Slots |
+| `style` | Variant, Theme, Density, Tokens und Parts |
+| `token` | produktive `--xtend-*` Tokens |
+| `theme` | Theme Pack |
+| `density` | Density Pack |
+| `a11y` | Role, Label, Live Region, Keyboard und Announcements |
+| `on` | Event zu Command |
+| `command` | Command zu Schedule |
+| `hydrate` | Hydration Policy |
+| `lane` | Fabric Lane und Fiber |
+| `route` | XRouter Route |
+| `link` | XLink-kompatibler Link |
+| `outlet` | Route Outlet im Template |
+
+## Beispiel
+
+```json
+{
+  "component": "settings.shell",
+  "tag": "x-section",
+  "shell": {
+    "slot": {
+      "header": "settings.header.template",
+      "feedback": "feedback.toast"
+    }
+  },
+  "style": {
+    "theme": "dark",
+    "density": "comfortable",
+    "token": {
+      "--xtend-surface": "var(--xtend-surface)",
+      "--xtend-color-primary": "var(--xtend-color-primary)"
+    }
+  },
+  "a11y": {
+    "role": "region",
+    "label": "Settings"
+  },
+  "hydrate": {
+    "policy": "visible",
+    "schedule": "component.visible.mount"
+  },
+  "lane": {
+    "lane": "visible",
+    "fiber": "component.render"
+  }
+}
+```
+
+Der normalisierte Output wird zu `components[]`, `templates[]` und `schedules[]`. RMT beschreibt die Struktur; XTend fuehrt die Component-Hydration aus.
+
+## Routing-Sugar
+
+Routen koennen spaeter authoringfreundlich als `route`, `link` und `outlet` beschrieben werden:
+
+```json
+{
+  "route": "/settings",
+  "component": "settings.shell",
+  "link": {
+    "label": "Settings",
+    "href": "/settings"
+  },
+  "outlet": "primary"
+}
+```
+
+Das wird zu `routes[]`, `components[]` und `templates[]` mit Adapter `xtend.xrouter`. XRouter bleibt Host Adapter, nicht RMT-Kernel-Abhaengigkeit.
+
+## Diagnostik
+
+Der Polish-Plan definiert diese Diagnosecodes:
+
+- `rmt.dsl.alias.unknown`
+- `rmt.dsl.alias.required-field-missing`
+- `rmt.dsl.token.unknown`
+- `rmt.dsl.route.target-unresolved`
+- `rmt.dsl.link.route-unresolved`
+- `rmt.dsl.slot.target-unresolved`
+- `rmt.dsl.schedule.unresolved`
+- `rmt.dsl.inline-runtime-code-refused`
+- `rmt.dsl.kernel-boundary.refused`
+
+Damit kann XTendRMT upstream freundlichere Parserfehler und Editor-Hints bauen, ohne die XTend Runtime zu importieren.
+
+## Artefakte
+
+- Contract: `development/XTend-RMT-DSL-Authoring-Polish-fuer-Component-Shells.md`
+- Modul: `xtend-builder/typing/rmt-dsl-authoring-polish.js`
+- Fixture: `tests/fixtures/rmt-dsl-authoring-polish.rmt`
+- Suite: `tests/rmt/rmt_dsl_authoring_polish_suite.js`
+
+## RC0 Adoption Update
+
+Seit `WP-E12-15` beschreibt der [RC0 Adoption Guide](./rc0-adoption-guide.md), wie App Authors diese DSL-Polish-Schicht fuer Shell-first XTend Apps nutzen. Die wichtigste Migrationsregel bleibt: RMT darf XTend-Komponenten, XRouter-Routen und Content Slots konstruieren und schedulen, ohne XTend-Typen in den RMT Kernel einzubetten.

package/docs/rmt-first-demo-app.md

@@ -0,0 +1,77 @@
+# RMT-first Demo-App
+
+Contract: `xtend.epic10.rmt-first-demo-app.v1`
+
+Die RMT-first Demo-App zeigt den Zielpfad fuer Epic 10: Eine XTend App wird nicht mehr als manuelle HTML-Shell gebaut, sondern aus einem `.rmt` App-Dokument gerendert. XTend liefert lokale Web Components. RMT liefert Shell, Routes, Templates, Schedules, Fabric/Lane Metadata und Diagnostics.
+
+## Startpunkt
+
+- Demo: `xtendrmt-rmt-first-demo.html`
+- RMT Document: `xtendrmt/rmt-first-demo-app.rmt`
+- Runtime: `xtendrmt/rmt-first-demo-app.js`
+- Browser Smoke: `tests/browser/fixtures/rmt-first-demo-app-smoke.html`
+
+Die Hostseite enthaelt nur den RMT Root:
+
+```html
+<div
+  id="rmt-first-demo-root"
+  data-rmt-host="rmt-first-demo"
+  data-rmt-document-src="xtendrmt/rmt-first-demo-app.rmt"></div>
+```
+
+Die Shell selbst kommt aus `app.shell.template`.
+
+## Was RMT besitzt
+
+- App Shell
+- Routes
+- `dom_descriptor` Templates
+- Component Records
+- Props, Attribute, Slots und Event Commands
+- Schedules und Lanes
+- Fabric/Fiber Metadata
+- Diagnostics
+
+## Was XTend besitzt
+
+- Custom Elements
+- Manifest Lookup
+- Component Lifecycle
+- DOM-Ausfuehrung
+- XRouter-Registrierung
+- Fabric-Ausfuehrung und Telemetry Hooks
+
+Der RMT-Kernel importiert keine XTend-Komponenten. Diese Boundary bleibt `no-rmt-kernel-import-of-xtend-types`.
+
+## Demo-Routen
+
+| Route | Pfad | Inhalt |
+|-------|------|--------|
+| `dashboard` | `/` | Shell-first Status und Performance Coverage |
+| `settings` | `/settings` | Form Controls mit `x-select`, `x-checkbox`, `x-radio`, `x-textarea` |
+| `overlays` | `/overlays` | `x-tooltip`, `x-popover`, `x-drawer` |
+
+## No-Manual-Shell-Regel
+
+Die Demo gilt nur als korrekt, wenn:
+
+- der Host keine statischen `x-section` oder `x-router` Shell-Tags enthaelt
+- die Runtime kein `innerHTML` nutzt
+- `manifest.metadata.manualShellAllowed` auf `false` steht
+- `manifest.metadata.hostShellMarkup` auf `false` steht
+- der Browser-Smoke die Shell aus RMT rendert
+
+## Lokaler Gate
+
+```bash
+node scripts/run_xtend_tests.js rmt-first-demo-app --json
+```
+
+Der Gate prueft RMT-Referenzen, Runtime-Registry-Normalisierung, Host-Boundary, Browser-Smoke, Package-Metadata und die Dokumentationspfade.
+
+## Weiterfuehrung
+
+`WP-E10-14` migriert bestehende priorisierte Komponenten in dieselbe RMT/Fabric-Metadata-Linie. Die Demo-App bleibt dafuer der erste produktive Abnahme-Host.
+
+Seit `WP-E13-09` ist die Demo-App Teil von [RMT Production Readiness](./rmt-production-readiness.md). Der Contract `xtend.epic13.rmt-production-readiness.v1` nutzt sie als shell-first Evidence fuer Routing, Components, Fabric/Lane, Lifecycle Telemetry und Diagnostics.

package/docs/rmt-first-xtend-apps.md

@@ -0,0 +1,105 @@
+# RMT-first XTend Apps
+
+Docs Contract: `xtend.docs.rmt-first-xtend-apps.v1`
+
+Dieser Guide beschreibt den Zielpfad aus Epic 10: Eine vollstaendige XTend App wird als RMT-Dokument beschrieben. XTend liefert lokale Web Components, RMT liefert Shell, Routes, Templates, Components, Schedules, Hydration Policies, Fabric-Lanes und Diagnostics.
+
+Der zugrunde liegende Authoring Contract ist:
+
+```text
+xtend.rmt.first-class-app-authoring.v1
+```
+
+## Grundregeln
+
+- RMT ist App-Authoring-Modell.
+- XTend-Komponenten sind `xtend.component` Records.
+- XRouter wird ueber `xtend.xrouter` angebunden.
+- Templates nutzen bevorzugt `dom_descriptor`.
+- Event Bindings laufen als `dom-event-to-rmt-command`.
+- Fabric-, Lane- und Fiber-Hints bleiben Metadata.
+- Der RMT Kernel importiert keine XTend-Klassen oder XTend-Typen.
+
+Die Boundary bleibt:
+
+```text
+no-rmt-kernel-import-of-xtend-types
+```
+
+## Minimalstruktur
+
+```json
+{
+  "manifest": {
+    "metadata": {
+      "contractVersion": "xtend.rmt.first-class-app-authoring.v1",
+      "renderMode": "shell-first"
+    }
+  },
+  "adapters": [
+    { "id": "xtend.component", "kind": "component" },
+    { "id": "xtend.xrouter", "kind": "router" }
+  ],
+  "components": [
+    {
+      "id": "settings.status",
+      "kind": "custom_element",
+      "adapter": "xtend.component",
+      "tag": "x-status",
+      "props": { "tone": "success" },
+      "schedule": "component.visible.mount",
+      "fabric": { "lane": "visible", "fiber": "component.mount" }
+    }
+  ],
+  "routes": [
+    { "id": "settings", "path": "/settings", "template": "settings.page" }
+  ],
+  "templates": [
+    {
+      "id": "settings.page",
+      "mode": "dom_descriptor",
+      "children": [
+        { "component": "settings.status" }
+      ]
+    }
+  ]
+}
+```
+
+## Referenzpfade
+
+- Contract: `development/XTend-RMT-First-Class-App-Authoring.md`
+- Fixture: `tests/fixtures/rmt-first-class-xtend-app.rmt`
+- Demo-App: `xtendrmt/rmt-first-demo-app.rmt`
+- Browser-Smoke: `tests/browser/fixtures/rmt-first-demo-app-smoke.html`
+- Gate: `node scripts/run_xtend_tests.js rmt-first-class-app --json`
+- Demo-Gate: `node scripts/run_xtend_tests.js rmt-first-demo-app --json`
+
+## Fabric und Telemetry
+
+Komponenten erhalten Fabric-Kontext ueber Adapter Injection. Die kanonische Boundary ist:
+
+```text
+adapter-injection-via-xtend-component-resolveFabricContext
+```
+
+`window.XTendFabric` kann durch Hosts genutzt werden, ist aber nicht die Contract-Oberflaeche einer Komponente.
+
+## Release-Handoff
+
+Der Abschluss von Epic 10 wird in [Epic 10 Release Handoff](./epic10-release-handoff.md) dokumentiert. Die dortige Gate-Kette entscheidet, ob ein RMT-first XTend App-Pfad releasefaehig genug fuer einen Kandidaten ist.
+
+Seit `WP-E13-09` buendelt [RMT Production Readiness](./rmt-production-readiness.md) diesen Pfad unter `xtend.epic13.rmt-production-readiness.v1`: Shell-first App Shell, Routing, Components, Fabric/Lanes, Lifecycle Telemetry, Diagnostics und Artifact Parity sind als RC1-Gate verbunden. `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) 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.
+
+## Component UX Authoring
+
+Seit `WP-E11-16` ergaenzt [Component UX App Authoring](./component-ux-app-authoring.md) diesen Guide um sichtbare UX-Regeln fuer RMT-first Apps. Dazu gehoeren Theme, Motion, Density, Viewports, Browser-Smokes und die Component Shell Theme Matrix `xtend.epic11.component-shell-theme-matrix.v1`.
+
+Seit `WP-E11-17` beschreibt [Component Long-Tail Migration](./component-long-tail-migration.md), welche Legacy- und Infrastrukturkomponenten zuerst fuer RMT-first App-Kompatibilitaet nachgehaertet werden.
+
+Der lokale Docs-Gate lautet:
+
+```bash
+node scripts/run_xtend_tests.js component-ux-authoring-docs --json
+node scripts/run_xtend_tests.js component-long-tail-migration --json
+```

package/docs/rmt-kernel-panic-recovery-incident-handoff.md

@@ -0,0 +1,61 @@
+# RMT Kernel Panic Recovery Incident Handoff
+
+- Contract: `xtend.rmt.kernel-migration-authoring-incident-handoff.v1`
+- Workpackage: `RKSH-WP-11`
+- Local gate: `node scripts/run_xtend_tests.js rmt-kernel-handoff-docs --json`
+
+Dieses Handoff beschreibt, wie Host-Teams Panic- und Recovery-Diagnostics auswerten, wenn die Kernel-Trust-Schicht fehlerhafte Outputs blockiert oder Recovery startet.
+
+## Diagnostics-Kanaele
+
+| Kanal | Zweck |
+|-------|-------|
+| `rmt.kernel.panic` | Panic-State, Trigger, Severity, Scope und blockierte Commits. |
+| `rmt.kernel.recovery` | Recovery-Outcome, Snapshot-Nutzung, Fallback und Quarantaene. |
+| `rmt.kernel.escalation` | Escalation Envelope aus Diagnostics Hub oder Command Bus. |
+| `rmt.kernel.scheduler_failure` | `failed`, `aborted`, `panic_blocked` und Backpressure-Failure fuer Jobs. |
+
+## Mindestfelder fuer Incident Review
+
+- `panicId`
+- `correlationId`
+- `state`
+- `severity`
+- `scope`
+- `trigger`
+- `blockedCommitCount`
+- `recoveryAction`
+- `quarantined`
+- `hostNotified`
+- `affectedJobs`
+- `firstSeenAt`
+- `lastSeenAt`
+
+## Incident Severity
+
+| Severity | Bedeutung | Erwartete Reaktion |
+|----------|-----------|--------------------|
+| `warning` | Output wurde korrigiert oder sanitisiert. | Verdicts beobachten, keine Eskalation noetig. |
+| `degraded` | Output wurde blockiert, UI bleibt mit sicherem Fallback nutzbar. | Host-Team prueft Authoring oder Remote Source. |
+| `critical` | Surface, Template oder Binding wurde quarantined. | Incident oeffnen, `correlationId` und `panicId` verfolgen. |
+| `fatal` | Recovery ist fehlgeschlagen oder mehrere Kernel-Scope-Fehler korrelieren. | Release/Traffic stoppen und letzten sicheren Stand wiederherstellen. |
+
+## Recovery-Aktionen
+
+| `recoveryAction` | Bedeutung | Host-Handoff |
+|------------------|-----------|--------------|
+| `rollback-last-safe-snapshot` | Der Kernel stellt den letzten sicheren Snapshot wieder her. | Snapshot-ID und Surface-Scope sichern. |
+| `render-safe-fallback` | Ein gepruefter Fallback ersetzt unsicheren Output. | Fallback-Markup und Reason Code pruefen. |
+| `quarantine-surface` | Betroffene Surface nimmt keine neuen Commits an. | Remote Source oder Adapter deaktivieren. |
+| `abort-scope-jobs` | Scheduler Jobs im betroffenen Scope werden abgebrochen. | `rmt.kernel.scheduler_failure` mit `panic_blocked` pruefen. |
+| `notify-host` | Host Adapter wird aktiv ueber Recovery informiert. | `hostNotified` und Host-Log-Korrelation bestaetigen. |
+
+## Triage-Ablauf
+
+1. `rmt.kernel.panic` nach `panicId`, `correlationId`, `scope`, `trigger` und `blockedCommitCount` filtern.
+2. `rmt.kernel.recovery` mit demselben `correlationId` verbinden und `recoveryAction`, `quarantined` sowie `hostNotified` bewerten.
+3. `rmt.kernel.escalation` pruefen, wenn Diagnostics-Subscriber oder Command-Handler beteiligt waren.
+4. `rmt.kernel.scheduler_failure` pruefen, wenn Jobs `failed`, `aborted` oder `panic_blocked` sind.
+5. Authoring anhand von [RMT Kernel Trusted Output Authoring](./rmt-kernel-trusted-output-authoring.md) korrigieren.
+6. Migration und Regression mit [RMT Kernel Security Hardening Migration](./rmt-kernel-security-hardening-migration.md) und `node scripts/run_xtend_tests.js rmt-kernel-security-regression --json` absichern.
+

package/docs/rmt-kernel-security-hardening-migration.md

@@ -0,0 +1,50 @@
+# RMT Kernel Security Hardening Migration
+
+- Contract: `xtend.rmt.kernel-migration-authoring-incident-handoff.v1`
+- Workpackage: `RKSH-WP-11`
+- Status: `completed`
+- Local gate: `node scripts/run_xtend_tests.js rmt-kernel-handoff-docs --json`
+
+Dieses Dokument beschreibt die Migration fuer Hosts und RMT-Authoring, die bisher implizit erlaubte Runtime-Outputs genutzt haben. Seit der Kernel-Haertung gilt: HTML, Attribute, Properties und Remote Outputs werden erst committed, wenn die Trust-Schicht ein `RmtKernelRuntimeTrustVerdict` erzeugt hat.
+
+## Wann eine Trust Boundary erforderlich ist
+
+| Output | Trust Boundary | Migration |
+|--------|----------------|-----------|
+| `slot.html`, `prerender.html`, `fallback.html` | HTML muss vor jedem DOM-Commit bewertet werden. | `commitTrustedHtml` mit `sanitize html`, `html_fragment` und `safeFallbackHtml` nutzen. |
+| Direkte DOM-HTML-Sinks wie `innerHTML`, `insertAdjacentHTML` und `template.innerHTML` | Diese Sinks bleiben privilegierte Trusted-DOM-Sinks. | Direkte Writes entfernen und den Runtime Trust-Sink-Adapter verwenden. |
+| Attribute wie `href`, `src`, `srcset`, `action`, `formaction` und `srcdoc` | URL- und Sandbox-Policy entscheidet vor dem Commit. | `commitTrustedAttribute` verwenden und gefaehrliche Protokolle wie `javascript:` blockieren. |
+| Event-nahe Attribute wie `onclick`, `onload` oder `onerror` | Event-Attribute sind keine erlaubten Markup-Outputs. | Commands oder registrierte Event-Handler statt HTML-Attributen verwenden. |
+| Style- und DOM-Property-Writes wie `style`, `innerHTML`, `outerHTML`, `srcdoc` | Property-Policy bewertet Nebenwirkungen und DOM-Clobbering-Risiko. | `commitTrustedProperty` nur fuer explizit erlaubte Properties nutzen. |
+| Remote Outputs und Adapter Outputs | Remote Surface Boundaries brauchen Scope, Origin, Capability und Integrity-Kontext. | Remote Outputs als `remote-surface` oder `adapter-output` scope in die Trust Authority geben. |
+
+## Legacy-Pfade ersetzen
+
+1. Direkte HTML-Commits aus Komponenten, Adaptern und Host-Bridges entfernen. Der Kernel darf `innerHTML`, `insertAdjacentHTML` oder Template-HTML nur ueber `commitTrustedHtml` erreichen.
+2. HTML, das weiterhin erlaubt sein soll, als `html_fragment` markieren und durch `sanitize html` fuehren. Der Sanitizer muss `script`, `iframe`, `srcdoc`, `on*`, `javascript:` und vergleichbare gefaehrliche Patterns entfernen oder blockieren.
+3. Reine Texte als Text schreiben: `textContent` ist fuer Labels, Status, Fehlermeldungen und User Content der bevorzugte Pfad.
+4. Attribute trennen: `data-*` und `aria-*` bleiben normale strukturierte Attribute, URL-Attribute laufen durch `commitTrustedAttribute`.
+5. Properties trennen: nur explizit erlaubte Properties laufen durch `commitTrustedProperty`; HTML-nahe Properties bleiben blockiert.
+6. Fallbacks wie `fallback.html` nicht privilegieren. Recovery-Fallbacks muessen dieselbe Policy wie normale Outputs erfuellen und ein `safeFallbackHtml` besitzen.
+7. Diagnose und Regression pruefen: `listTrustVerdicts()`, `rmt.kernel.panic`, `rmt.kernel.recovery` und `node scripts/run_xtend_tests.js rmt-kernel-security-regression --json` muessen nach der Migration gruen bleiben.
+
+## SemVer-Auswirkung
+
+Blockierte Legacy-Outputs koennen ein Breaking Change sein, wenn veroeffentlichte Hosts bisher bewusst unsicheres Markup gerendert haben und dieses Verhalten Teil der dokumentierten Integrationsoberflaeche war.
+
+| Aenderung | SemVer |
+|-----------|--------|
+| Unsichere HTML-, URL- oder Event-Attribute werden neu blockiert und bestehende Apps koennen dadurch sichtbaren Content verlieren. | `major` |
+| Unsichere Pfade erhalten Warnungen, Diagnostics oder Opt-in-Fallbacks, aber der bisher sichere Output bleibt sichtbar. | `minor` |
+| Nur Docs, Tests, Report-Felder oder strengere Diagnostics ohne Output-Aenderung werden ergaenzt. | `patch` |
+
+Release Notes muessen fuer behavior-changing Blocks mindestens die betroffenen Sinks, den Reason Code, den Recovery-Pfad und die empfohlene Migration nennen.
+
+## Verifikation
+
+```bash
+node scripts/run_xtend_tests.js rmt-kernel-handoff-docs --json
+node scripts/run_xtend_tests.js rmt-kernel-security-regression --json
+node scripts/verify_xtendrmt_artifact_parity.js --json
+```
+

package/docs/rmt-kernel-trusted-output-authoring.md

@@ -0,0 +1,69 @@
+# RMT Kernel Trusted Output Authoring
+
+- Contract: `xtend.rmt.kernel-migration-authoring-incident-handoff.v1`
+- Workpackage: `RKSH-WP-11`
+- Package script: `npm run test:rmt-kernel-handoff-docs`
+
+RMT-Authoring darf nicht davon ausgehen, dass ein String sicher ist, nur weil er aus einem Template, einer Remote Surface oder einem Adapter stammt. Jeder output-nahe Authoring-Pfad braucht eine klare Trust Boundary und einen sicheren Fallback.
+
+## Authoring-Regeln
+
+- Text bleibt Text: Labels, Status, User Content und Fehlermeldungen als `textContent` oder strukturierte Textfelder authoren.
+- HTML nur bewusst authoren: `html_fragment` mit `sanitize html` und explizitem Scope verwenden.
+- Attribute klein halten: `data-*` und `aria-*` sind bevorzugt, URL-Attribute laufen ueber `commitTrustedAttribute`.
+- Properties nur fuer erlaubte Runtime-Ziele nutzen: DOM-HTML-Properties nicht als Abkuerzung verwenden.
+- Fallbacks sind nicht privilegiert: `safeFallbackHtml` muss selbst sanitizbar und nicht interaktiv gefaehrlich sein.
+- Remote Surface Outputs brauchen Scope, Capability, Origin und Integrity-Kontext, bevor sie in den Kernel gelangen.
+
+## Sichere Muster
+
+```js
+runtime.commitTrustedHtml(slotTarget, {
+  scope: 'slot',
+  source: 'slot.html',
+  html: model.safeSummaryHtml,
+  policy: {
+    transform: 'sanitize html',
+    output: 'html_fragment'
+  },
+  safeFallbackHtml: '<p data-rmt-fallback="safe">Content unavailable.</p>'
+});
+```
+
+```js
+runtime.commitTrustedAttribute(linkTarget, {
+  scope: 'binding',
+  name: 'href',
+  value: model.href,
+  allowedProtocols: ['https:', 'mailto:']
+});
+```
+
+```js
+runtime.commitTrustedProperty(inputTarget, {
+  scope: 'binding',
+  name: 'value',
+  value: model.value,
+  policy: 'form-control-value'
+});
+```
+
+## Authoring-Checkliste
+
+| Frage | Sichere Antwort |
+|-------|-----------------|
+| Enthält der Output Markup? | `html_fragment` plus `sanitize html` und `commitTrustedHtml`. |
+| Ist es nur Text? | `textContent` oder ein strukturierter Text-Record. |
+| Ist es ein URL-Attribut? | `commitTrustedAttribute` mit Protokoll-Allowlist. |
+| Ist es `data-*` oder `aria-*`? | Strukturierter Attribute-Commit, keine HTML-Interpolation. |
+| Ist es ein Fallback? | `safeFallbackHtml` mit derselben Policy wie normale HTML-Outputs. |
+| Kommt es aus Remote oder Adapter Code? | Trust Scope `remote-surface` oder `adapter-output`, Capability und Diagnostics-Korrelation. |
+
+## No-go-Muster
+
+- Markup aus Remote Sources direkt in `slot.html`, `prerender.html` oder `fallback.html` schleusen.
+- Event-Attribute wie `onclick` als Daten transportieren.
+- `style` oder HTML-nahe Properties als Escape Hatch verwenden.
+- `safeFallbackHtml` aus derselben unsicheren Quelle wie den blockierten Output bilden.
+- Diagnostics ignorieren, wenn ein Verdict `blocked` oder `panic` meldet.
+

package/docs/rmt-language-server.md

@@ -0,0 +1,177 @@
+# 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
+
+Ein duennes Bridge-Package liegt in:
+
+```text
+tools/rmt-editor/vscode
+```
+
+Es registriert:
+
+- Language ID `rmt`
+- Dateiendung `.rmt`
+- JSON-basierte TextMate-Grammatik
+- RMT Snippets
+- 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:
+
+```json
+{
+  "command": "node",
+  "args": ["tools/rmt-language-server/server.js"]
+}
+```
+
+## 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)