@ccslabs/xtend 0.1.0-rc.1 → 0.1.2

package/docs/rmt-app-platform-tooling.md

@@ -0,0 +1,79 @@
+# RMT App Platform Tooling
+
+- Contract: `xtend.epic18.rmt-app-platform-tooling.v1`
+- Gate: `node scripts/run_xtend_tests.js rmt-app-platform-tooling --json`
+- Workpackage: `WP-E18-11`
+- Handoff: `WP-E18-12`
+
+## Ziel
+
+RMT App Sources sind jetzt vor der Runtime pruefbar und buildfaehig. Das
+Tooling erzeugt Diagnostics, Source Maps und Scaffold Reports fuer generische
+App-Platform-Primitives wie Surfaces, Overlays, Portale, Resources, Actions,
+Events, DataSources und State.
+
+Der Slice ist bewusst keine Media-Manager-Shell. Er liefert Werkzeuge, mit
+denen Entwickler eigene App-Strukturen in XTend/RMT nativ anlegen koennen,
+ohne produktseitige `innerHTML`-Renderer oder eigene Mini-Frameworks.
+
+## Diagnostics
+
+Der App-Platform-Linter blockiert typische spaete Runtime-Fehler bereits beim
+Authoring:
+
+- `rmt.app.no-manual-shell.html-sink` fuer `innerHTML`, `outerHTML`,
+  `insertAdjacentHTML` oder `document.write` in normaler App-UI.
+- `rmt.app.unsafe-html.boundary-missing` fuer HTML-Fragmente ohne explizite
+  Trusted-DOM-Boundary.
+- `rmt.app.repeat.key.missing` fuer wiederholte Surfaces ohne stabilen Key.
+- `rmt.app.event.payload-contract.missing` fuer Events mit Action-Ziel ohne
+  Payload Contract.
+- `rmt.app.resource.ownership.missing` fuer nicht klar besessene Ressourcen.
+- `rmt.app.resource.unresolved`, `rmt.app.portal.unresolved` und
+  `rmt.app.surface.source.unresolved` fuer fehlerhafte App-Graph-Referenzen.
+
+Die Regeln laufen als eigener App-Platform-Policy-Rule im bestehenden
+RMT-Linter und als direkter Analyzer in
+`./rmt-language/app-platform-tooling`.
+
+## LSP
+
+Completion und Hover kennen die neuen Primitives:
+
+- Portal-IDs und Portal-Policies wie `stacked`, `toast-region` und
+  `clipping-escape`.
+- Overlay-Kinds wie `tooltip`, `toast`, `popover`, `lightbox`, `menu` und
+  `dialog`.
+- Resource-Kinds wie `object-url`, `stream`, `observer`, `timer` und
+  `lazy-import`.
+- Event-Kinds und Surface-Initialstates.
+
+Damit koennen App-Autoren RMT-Dokumente ohne Produkt-Surface-Taxonomie und ohne
+externe Hilfslisten bearbeiten.
+
+## Scaffold Build
+
+Der Builder registriert den Befehl `rmt-app-platform`. Er liest eine `.rmt`
+App Source und erzeugt unter `.xtend-build`:
+
+- `*.app-platform-diagnostics.json`
+- `*.app-platform-source-map.json`
+- `*.app-platform-build.json`
+
+Die Artefakte laufen ueber den Epic-17 WritePlan und tragen Scaffold-
+Ownership. `--check` kann damit pruefen, ob lokale Build-Artefakte aktuell
+sind.
+
+```bash
+node scripts/run_xtend_tests.js rmt-app-platform-tooling --json
+node xtend-builder/lib/cli.js rmt-app-platform --source tests/fixtures/rmt-app-platform-tooling.rmt
+```
+
+## Grenzen
+
+- Keine Produkt-Surface-Liste und kein Media-Manager-spezifischer Registry-
+  Repaint.
+- Keine normalen UI-HTML-Sinks ausserhalb einer Trusted-DOM-Boundary.
+- Keine Imports aus XTend-Komponenten in den RMT Kernel.
+- Das Tooling baut Reports, Diagnostics und Source Maps; die produktnahe
+  generische App-Fixture folgt in `WP-E18-12`.

package/docs/rmt-component-template-primitives.md

@@ -0,0 +1,57 @@
+# RMT Component Template Primitives
+
+- Contract: `xtend.epic18.rmt-component-template-primitives.v1`
+- Fixture: `tests/fixtures/rmt-component-template-primitives.rmt`
+- Runtime Basis: `xtendrmt/rmt-dom-descriptor-renderer.js`
+- Local Gate: `node scripts/run_xtend_tests.js rmt-component-template-primitives --json`
+- Workpackage: `WP-E18-06`
+- Handoff: `WP-E18-07`
+
+RMT kann XTend-Komponenten jetzt nativ komponieren, ohne dass Host-Apps
+HTML-Strings zusammenbauen. Der Slice erweitert den DOM Descriptor Renderer um
+component-nahe Primitives fuer App-Shells, Listen, Formulare, Tooltips, Icons,
+leere Zustaende und Fehlerzustaende.
+
+## Primitives
+
+| Primitive | Zweck |
+|-----------|-------|
+| `component` | Loest eine Component-ID auf ein Custom Element wie `x-section`, `x-card`, `x-tooltip` oder beliebige Entwickler-Tags auf. |
+| `props` | Setzt sichere DOM Properties und spiegelt primitive Werte als Attribute. |
+| `attributes` | Setzt sichere Attribute ohne Inline-Event- oder URL-Sinks. |
+| `parts` | Schreibt CSS Parts fuer themingfaehige Komponenten. |
+| `slots` | Fuellt Slots mit Text, Templates, Komponenten oder Fragmenten. |
+| `text` | Erzeugt Textknoten ueber `createTextNode`. |
+| `when` | Rendert bedingte Teilbaeume. |
+| `repeat` | Rendert Listen und nutzt `key` fuer stabile Knoten. |
+| `empty` | Rendert einen expliziten leeren Zustand. |
+| `fallback` | Rendert deklarative Ersatzinhalte. |
+| `key` | Markiert wiederverwendbare Listenelemente mit `data-rmt-key`. |
+| `ref` | Schreibt `data-rmt-ref` und legt die Elementreferenz in `refs` ab. |
+| `class` | Mappt Klassen aus Strings, Arrays oder bedingten Objekten. |
+| `style-token` | Spiegelt Design Tokens als `data-style-token-*` und `--xtend-*`. |
+
+## Component-Familien
+
+Die Fixture beweist generische Familien statt Produkt-Surfaces:
+Icons, Tooltips, Form Controls (`x-input`, `x-select`, `x-checkbox`),
+Navigation, Listen, Selection, Empty State, Error State und freie Custom
+Elements. Die Komponenten bleiben Entwickler-definiert; RMT kennt nur
+Descriptoren und Adapterfaehigkeiten.
+
+## Component Capability Registry
+
+Die vNext-Schicht fuehrt diese Primitives ueber
+`xtendrmt/rmt-component-capability-registry.js` mit dem ganzen XTend-
+Component-Stack zusammen. Die Registry normalisiert alle 44 public
+Manifest-Eintraege, klassifiziert 40 renderbare UI-Komponenten und verbindet
+Component Contracts, `xtendRmtMetadata`, `observedAttributes`, Events, Slots,
+Parts, Form-State und Lazy Import mit den generischen DOM Descriptoren.
+
+Damit bleiben `component`, `props`, `attributes`, `parts`, `slots`, `repeat`
+und `key` dieselben Primitives, aber sie bekommen eine stack-weite
+Kompatibilitaetsmatrix. Produktcode braucht keine Shadow-DOM-Patches, keine
+privaten Component-Maps und keine komponentenspezifischen Renderer.
+
+Details stehen in
+[RMT vNext Component Primitives und XTend UI](./rmt-vnext-component-primitives.md).

package/docs/rmt-dom-descriptor-renderer.md

@@ -0,0 +1,64 @@
+# RMT DOM Descriptor Renderer
+
+- Contract: `xtend.epic18.rmt-dom-descriptor-renderer.v1`
+- Fixture: `tests/fixtures/rmt-dom-descriptor-renderer.rmt`
+- Runtime: `xtendrmt/rmt-dom-descriptor-renderer.js`
+- Local Gate: `node scripts/run_xtend_tests.js rmt-dom-descriptor-renderer --json`
+- Workpackage: `WP-E18-05`
+
+Der Renderer fuehrt das `WP-E18-04` Authoring-Modell als generische App
+Platform aus. Normale App-UI wird aus strukturierten Deskriptoren gebaut:
+`createElement`, `createTextNode`, `createDocumentFragment`,
+`replaceChildren`, sichere Attribute/Properties und keyed Child-Reuse.
+
+## Descriptor-Regeln
+
+| Bereich | Regel |
+|---------|-------|
+| Shell | Root-Render-Units verwenden `replaceChildren` und markieren den Root mit `data-rmt-rendered-shell`. |
+| Elemente | Tags muessen einfache Custom-Element- oder HTML-Tagnamen sein. |
+| Attribute | Inline-Handler, `srcdoc` und unsichere URL-Werte werden abgelehnt. |
+| Properties | HTML-Sink-Properties sind fuer normale UI gesperrt. |
+| Listen | `renderKeyed` erhaelt Knoten ueber `data-rmt-key` und patcht Attribute/Children. |
+| Events | Events laufen ueber `addEventListener`, nicht ueber String-Attribute. |
+| Diagnostics | Runtimefehler enthalten RMT-Source-Informationen wie `documentId`, `templateId` und `pointer`. |
+
+## Component Registry Option
+
+`render(...)` und `renderKeyed(...)` akzeptieren `componentRegistry`. Wenn ein
+Descriptor `type: "component"` nutzt, normalisiert der Renderer Tag,
+Attribute, Properties, Slots, Parts und Event-Bindings ueber die RMT vNext
+Component Capability Registry:
+
+```js
+renderer.renderKeyed(root, descriptors, {
+  componentRegistry: registry,
+  dispatchEvent,
+  stateBridge
+});
+```
+
+Die Registry bindet XTend-Komponenten ueber public DOM APIs. Sie liest
+Component Contracts und RMT-Metadaten, fuehrt lazy Import ueber Manifest-Pfade
+aus und schreibt sichere Capability-Marker wie
+`data-rmt-component-capability`. Der Renderer bleibt dadurch generisch: keine
+Shadow-DOM-Patches, keine privaten Component-Maps und keine HTML-Sinks fuer
+normale RMT-App-UI.
+
+## Trusted Boundary
+
+HTML-Fragmente sind kein normaler Template-Pfad. Sie duerfen nur als
+`trusted_html` mit `xtend.rmt.trusted-dom-boundary.explicit` und einem
+externen `trustedDomRenderer` gerendert werden. Der Standard-Renderer erzeugt
+keine HTML-Fragmente aus Strings.
+
+## No-Manual-HTML
+
+Das Gate `createNoManualHtmlGate()` blockiert normale App-Shells mit
+manuellen HTML-Sinks wie `root.innerHTML`, `element.innerHTML`,
+`template.innerHTML`, `outerHTML`, `insertAdjacentHTML`, `document.write` und
+`createContextualFragment`.
+
+`WP-E18-06` und die vNext Component Capability Registry bauen auf diesem Slice
+component-native Template-Primitives auf, ohne externe HTML-Hilfsrenderer
+vorauszusetzen.

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

@@ -1,6 +1,8 @@
 # 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.
+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:
 
@@ -10,7 +12,10 @@ 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.
+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:
 
@@ -41,58 +46,71 @@ RMT bleibt dabei host-neutral:
 
 ## Beispiel
 
-```json
-{
-  "component": "settings.shell",
-  "tag": "x-section",
-  "shell": {
-    "slot": {
-      "header": "settings.header.template",
-      "feedback": "feedback.toast"
+```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
+      }
     }
-  },
-  "style": {
-    "theme": "dark",
-    "density": "comfortable",
-    "token": {
-      "--xtend-surface": "var(--xtend-surface)",
-      "--xtend-color-primary": "var(--xtend-color-primary)"
+
+    lane idle weight 20 {
+      hydrate settings-shell-style from endpoint xtendrmt.component.hydrate {
+        trust boundary "xtend.security.sanitizing-boundary.v1"
+      }
     }
-  },
-  "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.
+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 spaeter authoringfreundlich als `route`, `link` und `outlet` beschrieben werden:
-
-```json
-{
-  "route": "/settings",
-  "component": "settings.shell",
-  "link": {
-    "label": "Settings",
-    "href": "/settings"
-  },
-  "outlet": "primary"
+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.
+Das wird zu `routes[]`, `components[]` und `templates[]` mit Adapter
+`xtend.xrouter`. XRouter bleibt Host Adapter, nicht RMT-Kernel-Abhaengigkeit.
 
 ## Diagnostik
 
@@ -108,7 +126,8 @@ Der Polish-Plan definiert diese Diagnosecodes:
 - `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.
+Damit kann XTendRMT upstream freundlichere Parserfehler und Editor-Hints bauen,
+ohne die XTend Runtime zu importieren.
 
 ## Artefakte
 
@@ -119,4 +138,8 @@ Damit kann XTendRMT upstream freundlichere Parserfehler und Editor-Hints bauen,
 
 ## 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.
+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-event-routing-runtime.md

@@ -0,0 +1,98 @@
+# 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`
+- Local gate: `node scripts/run_xtend_tests.js rmt-event-routing-runtime --json`
+- Next: `WP-E18-10`
+
+## Purpose
+
+The Event Routing Runtime makes DOM and custom events first-class RMT app
+platform primitives. Apps can bind events to actions declaratively, validate
+payloads before action execution, apply governance policies and clean up
+listeners by owner scope.
+
+The runtime delegates execution to the Action Effect Runtime from `WP-E18-08`.
+It does not create a second action framework and does not import XTend UI
+components.
+
+## Event Bindings
+
+An event binding can declare:
+
+- `event`
+- `target`
+- `component`
+- `owner`
+- `action`
+- `actionMode`
+- `payload`
+- `payloadContract`
+- `governance`
+- `condition`
+
+Targets are resolved through explicit refs, a passed `targets` map, a custom
+target resolver or a DOM query from a provided root. Product-local
+`event.target.closest(...)` delegation chains are not required for normal app
+flows.
+
+## Payload Contracts
+
+Payloads are built from event data with expressions such as:
+
+- `$event.target.value`
+- `$detail.id`
+- `$target.dataset.id`
+- `$source.dataset.path`
+
+Contracts use a small structural shape:
+
+```json
+{
+  "type": "object",
+  "required": ["id"],
+  "properties": {
+    "id": "string"
+  }
+}
+```
+
+Invalid payloads are blocked before the action runtime is called and emit
+`rmt.event.payload_contract.invalid` diagnostics.
+
+## Event Governance
+
+Supported policies:
+
+- `preventDefault`
+- `stopPropagation`
+- `stopImmediatePropagation`
+- `capture`
+- `passive`
+- `once`
+- `retarget`
+
+Retargeting can use `target`, `current-target` or `composed-path`. This keeps
+component interaction explicit without product-specific DOM walking.
+
+## Ownership
+
+`attach()` registers listeners and records their owner. `detachOwner(ownerId)`
+removes only the listeners for that scope, while `detachAll()` removes the
+remaining listeners. This is the bridge to the surface and resource lifecycle
+work in `WP-E18-10`.
+
+## Diagnostics
+
+Diagnostics use `xtend.epic18.rmt-event-routing-diagnostic.v1` on
+`rmt.app_platform.event_routing`. Route diagnostics include event id, component,
+payload and action target so build and runtime reports can show why a user
+interaction did or did not execute.
+
+## Handoff
+
+`WP-E18-10` can now harden surface, overlay, portal and resource graphs using
+owner-scoped events plus the resource ownership model from `WP-E18-08`.

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

@@ -6,7 +6,7 @@ Die RMT-first Demo-App zeigt den Zielpfad fuer Epic 10: Eine XTend App wird nich
 
 ## Startpunkt
 
-- Demo: `xtendrmt-rmt-first-demo.html`
+- 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`
@@ -17,7 +17,7 @@ Die Hostseite enthaelt nur den RMT Root:
 <div
   id="rmt-first-demo-root"
   data-rmt-host="rmt-first-demo"
-  data-rmt-document-src="xtendrmt/rmt-first-demo-app.rmt"></div>
+  data-rmt-document-src="/xtendrmt/rmt-first-demo-app.rmt"></div>
 ```
 
 Die Shell selbst kommt aus `app.shell.template`.

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

@@ -2,7 +2,10 @@
 
 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.
+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:
 
@@ -12,12 +15,13 @@ xtend.rmt.first-class-app-authoring.v1
 
 ## Grundregeln
 
-- RMT ist App-Authoring-Modell.
-- XTend-Komponenten sind `xtend.component` Records.
+- 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`.
-- Event Bindings laufen als `dom-event-to-rmt-command`.
-- Fabric-, Lane- und Fiber-Hints bleiben Metadata.
+- 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:
@@ -28,44 +32,42 @@ 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" }
+```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
     }
-  ],
-  "routes": [
-    { "id": "settings", "path": "/settings", "template": "settings.page" }
-  ],
-  "templates": [
-    {
-      "id": "settings.page",
-      "mode": "dom_descriptor",
-      "children": [
-        { "component": "settings.status" }
-      ]
+
+    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`
@@ -77,25 +79,47 @@ no-rmt-kernel-import-of-xtend-types
 
 ## Fabric und Telemetry
 
-Komponenten erhalten Fabric-Kontext ueber Adapter Injection. Die kanonische Boundary ist:
+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.
+`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.
+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-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.
+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: