@ccslabs/xtend 0.1.0-rc.1 → 0.1.2

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

@@ -0,0 +1,145 @@
+# 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
+
+```rmt
+template settings.shell {
+  state settings.theme type string initial "dark"
+  state settings.density type string initial "comfortable"
+
+  portal surface.root root "#settings-root" layer surface
+
+  surface settings.shell kind page component x-section {
+    portal surface.root
+
+    lane visible weight 80 {
+      hydrate settings-header {
+        slot header hydrate settings.header.template
+      }
+
+      hydrate feedback-toast from endpoint xtendrmt.component.hydrate {
+        slot feedback hydrate feedback.toast
+      }
+    }
+
+    lane idle weight 20 {
+      hydrate settings-shell-style from endpoint xtendrmt.component.hydrate {
+        trust boundary "xtend.security.sanitizing-boundary.v1"
+      }
+    }
+  }
+}
+```
+
+Token-Aliase bleiben Teil des Contracts: produktive Styles referenzieren
+weiterhin stabile Custom Properties wie `--xtend-surface` und
+`--xtend-color-primary`, waehrend vNext die Struktur, Slots und Hydration
+beschreibt.
+
+Der normalisierte Output wird zu `components[]`, `templates[]` und
+`schedules[]`. RMT beschreibt die Struktur; XTend fuehrt die
+Component-Hydration aus.
+
+## Routing-Sugar
+
+Routen koennen authoringfreundlich als Surface-, Link- und Outlet-Struktur
+beschrieben werden:
+
+```rmt
+template settings.routing {
+  portal surface.root root "#app-root" layer surface
+
+  surface settings.route kind page component x-section {
+    portal surface.root
+
+    lane visible weight 80 {
+      hydrate settings-shell from endpoint xtendrmt.route.render
+      hydrate settings-link from endpoint xtendrmt.component.hydrate
+      slot outlet hydrate primary
+    }
+
+    on click target settings-link -> action route.navigate {
+      payload href from "/settings"
+    }
+  }
+}
+```
+
+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/de/rmt-event-routing-runtime.md

@@ -0,0 +1,81 @@
+# RMT Event Routing Runtime
+
+- Contract: `xtend.epic18.rmt-event-routing-runtime.v1`
+- Workpackage: `WP-E18-09`
+- Runtime: `xtendrmt/rmt-event-routing-runtime.js`
+- Types: `xtendrmt/rmt-event-routing-runtime.d.ts`
+- Fixture: `tests/fixtures/rmt-event-routing-runtime.rmt`
+- Lokaler Gate: `node scripts/run_xtend_tests.js rmt-event-routing-runtime --json`
+- Naechstes Paket: `WP-E18-10`
+
+## Zweck
+
+Die Event Routing Runtime macht DOM- und Custom Events zu nativen RMT-App-Platform-Primitives. Apps koennen Events deklarativ an Actions binden, Payloads vor der Action-Ausfuehrung validieren, Governance-Policies anwenden und Listener nach Owner-Scope bereinigen.
+
+Die Runtime delegiert die Ausfuehrung an die Action Effect Runtime aus `WP-E18-08`. Sie erzeugt kein zweites Action-Framework und importiert keine XTend-UI-Komponenten.
+
+## Event Bindings
+
+Ein Event Binding kann deklarieren:
+
+- `event`
+- `target`
+- `component`
+- `owner`
+- `action`
+- `actionMode`
+- `payload`
+- `payloadContract`
+- `governance`
+- `condition`
+
+Targets werden ueber explizite Refs, eine uebergebene `targets` Map, einen eigenen Target Resolver oder eine DOM-Query aus einem bereitgestellten Root aufgeloest. Produktlokale `event.target.closest(...)`-Delegationketten sind fuer normale App-Flows nicht erforderlich.
+
+## Payload Contracts
+
+Payloads werden aus Event-Daten mit Ausdruecken wie diesen gebaut:
+
+- `$event.target.value`
+- `$detail.id`
+- `$target.dataset.id`
+- `$source.dataset.path`
+
+Contracts nutzen eine kleine strukturelle Form:
+
+```json
+{
+  "type": "object",
+  "required": ["id"],
+  "properties": {
+    "id": "string"
+  }
+}
+```
+
+Ungueltige Payloads werden geblockt, bevor die Action Runtime aufgerufen wird, und emittieren `rmt.event.payload_contract.invalid` Diagnostics.
+
+## Event Governance
+
+Unterstuetzte Policies:
+
+- `preventDefault`
+- `stopPropagation`
+- `stopImmediatePropagation`
+- `capture`
+- `passive`
+- `once`
+- `retarget`
+
+Retargeting kann `target`, `current-target` oder `composed-path` verwenden. Dadurch bleibt Component-Interaktion explizit, ohne produktspezifisches DOM-Walking.
+
+## Ownership
+
+`attach()` registriert Listener und merkt sich ihren Owner. `detachOwner(ownerId)` entfernt nur die Listener fuer diesen Scope, waehrend `detachAll()` die verbleibenden Listener entfernt. Das ist die Bruecke zur Surface- und Resource-Lifecycle-Arbeit in `WP-E18-10`.
+
+## Diagnostics
+
+Diagnostics nutzen `xtend.epic18.rmt-event-routing-diagnostic.v1` auf `rmt.app_platform.event_routing`. Route Diagnostics enthalten Event-ID, Component, Payload und Action-Ziel, damit Build- und Runtime-Reports zeigen koennen, warum eine User-Interaktion ausgefuehrt wurde oder nicht.
+
+## Handoff
+
+`WP-E18-10` kann nun Surface-, Overlay-, Portal- und Resource-Graphs mit owner-scoped Events und dem Resource-Ownership-Modell aus `WP-E18-08` haerten.

package/docs/de/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 / Browser Smoke: `tests/browser/fixtures/rmt-first-demo-app-smoke.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/de/rmt-first-xtend-apps.md

@@ -0,0 +1,129 @@
+# 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-vNext-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 vNext ist App-Authoring-Modell.
+- XTend-Komponenten werden ueber Surfaces mit `component x-*` beschrieben und
+  in `xtend.component` Records kompiliert.
+- XRouter wird ueber `xtend.xrouter` angebunden.
+- Templates nutzen bevorzugt `dom_descriptor` als generierten Output.
+- Event Bindings laufen als `on ... -> action ...`.
+- Fabric-, Lane- und Fiber-Hints kommen aus `lane`- und Lifecycle-Klauseln.
+- Der RMT Kernel importiert keine XTend-Klassen oder XTend-Typen.
+
+Die Boundary bleibt:
+
+```text
+no-rmt-kernel-import-of-xtend-types
+```
+
+## Minimalstruktur
+
+```rmt
+template settings.app {
+  state settings.status type string initial "ready"
+
+  selector settings.feedback from state settings.status {
+    output StatusView
+  }
+
+  action settings.refresh {
+    reduce state.settings.status = "refreshing"
+    emit settings.refresh.requested with action settings.refresh
+  }
+
+  portal surface.root root "#app-root" layer surface
+
+  surface settings.status kind card component x-status {
+    source selector settings.feedback
+    portal surface.root
+
+    lane visible weight 80 {
+      mount x-status
+      hydrate settings-status from selector settings.feedback
+    }
+
+    on click target refresh-button -> action settings.refresh {
+      payload source from target.dataset.action
+    }
+  }
+}
+```
+
+Der Compiler erzeugt daraus `xtend.component`, `xtend.xrouter`,
+`rmt.state-scheduler-diagnostics`, `dom_descriptor` Templates und
+Schedule-/Lane-Records. Diese JSON-Records sind Runtime-Mirror, nicht der
+primaere Authoring-Pfad.
+
+## 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/de/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/de/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/de/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.
+