@ccslabs/xtend 0.1.0-rc.1 → 0.1.2

package/docs/changelog.md

@@ -0,0 +1,107 @@
+# XTend Changelog
+
+Dieser Artikel sammelt die historischen Epic-, Workpackage-, Handoff- und
+Gate-Notizen, die frueher in vielen einzelnen Developer-Artikeln standen. Die
+normalen Guides bleiben dadurch auf Produktnutzung und Developer Experience
+fokussiert; dieser Changelog ist der kanonische Ort fuer Fortschritt,
+Release-Signale und technische Historie.
+
+## RMT vNext und App-Shell-Authoring
+
+- `RMT-VNEXT-PRIM-01` bis `RMT-VNEXT-PRIM-04` haben Grammar, Parser, Semantic
+  Graph und Lowering fuer RMT-vNext-Primitives aufgebaut.
+- `RMT-VNEXT-PRIM-05` hat Fabric Lane/Fiber Evidence fuer vNext-authorierte
+  Lanes, Route-Fibers und Component-Fibers nachgezogen.
+- `RMT-VNEXT-PRIM-06` hat das Source-to-Sea-Gate aufgebaut: vNext Source,
+  Kernel Records, Fabric Telemetry, UI-Marker und Browser-Evidence werden
+  ueber Primitive IDs korreliert.
+- `RMT-VNEXT-PRIM-07` hat die Authoring-DX abgeschlossen: Completions, Hover,
+  Symbols, Code Actions, Safe Fix-All und VS-Code-Bridge arbeiten aus echten
+  RMT-vNext-Quellen.
+- `RMT-VNEXT-PRIM-08` hat Migration und Legacy-Backgrounding abgeschlossen:
+  App-Platform-Primitive-JSON bleibt Mirror/Compiler-Target, waehrend vNext
+  der Authoring-Pfad ist.
+- `WP-E15-18` hat den vNext Release Handoff gebuendelt. Die Reference Demo
+  liegt in `xtendrmt/rmt-vnext-reference-demo.rmt`, der stabile Core-Output in
+  `xtendrmt/rmt-vnext-reference-demo.core.json`.
+
+## RMT Tooling, LSP und Editor-Integration
+
+- `WP-E14-02` bis `WP-E14-04` haben Source Model, Parser/Format Adapter und
+  Semantic Graph fuer native `.rmt` Dokumente stabilisiert.
+- `WP-E14-05` bis `WP-E14-10` haben Linter, CLI, Completion, Hover, Document
+  Symbols, Definition und sichere Code Actions aufgebaut.
+- `WP-E14-11` hat AI-Agent Repair Reports mit `repairPlan`, `fixOrder`,
+  `confidence`, `impact` und No-Op-Erklaerungen eingefuehrt.
+- `WP-E14-12` hat Snippets, Editor Packaging und die VS-Code-Bridge
+  vorbereitet.
+- `WP-E14-14` hat Quick Start, Linter- und Language-Server-Dokumentation
+  konsolidiert. Der Contract bleibt `xtend.rmt.tooling-docs.v1`; der lokale
+  Gate bleibt `node scripts/run_xtend_tests.js rmt-tooling-docs --json`.
+- `WP-E14-15` und `WP-E14-16` haben RMT Tooling Release Gates und den LSP
+  Handoff abgeschlossen.
+
+## XTendRMT Runtime, Kernel und Fabric
+
+- Epic 05 hat XTendRMT als produktiven Scheduler-, Runtime- und
+  Templating-Pfad etabliert: native `.rmt` Domains, Runtime Registry, XRouter
+  Adapter, XTend Component Adapter und State-/Scheduler-/Diagnostics Bridge.
+- `ER-WP-08` bis `ER-WP-21` haben Fabric als Host-Kern, Component
+  Lifecycle Error Boundary, Reporter Adapter, Diagnostics Bridge, Component
+  und Route Fibers, Telemetry Snapshots, Performance Measurements, Regression
+  und Hydration Policies aufgebaut.
+- `ER-WP-13` hat Fabric-Lanes auf host-neutrale RMT Schedule Records
+  abgebildet. Die RMT-Kernel-Grenze bleibt framework-neutral.
+- `RKSH-WP-11` hat Kernel-Migration, Trusted Output Authoring sowie Panic- und
+  Recovery-Incident-Handoff dokumentiert.
+
+## Component Platform und App-Surfaces
+
+- Epic 10 hat TypeScript-first Components, Component Contract v2,
+  RMT-first Apps und Platform Gates aufgebaut.
+- Epic 11 hat Component UX, Shell Styling, A11y, Visual Regression,
+  Enterprise UX Handoff und Long-Tail-Migration vorbereitet.
+- SurfaceManager-Pakete `WP-SM-01` bis `WP-SM-19` haben RMT Authoring,
+  Controller, Window Runtime, SidePanel, Workbench Fixture, Overlay Bridge,
+  Native RMT Surfaces, Route Lifecycles, Persistence, Layout Engines,
+  Component Lab und Runtime Release Handoff aufgebaut.
+- Epic 18 hat App-Platform-Primitives, Media-Manager-Lessons-Learned,
+  Vendor-Bugfix-Backports und generische RMT App-Platform-Fixtures in den
+  Upstream-Stand ueberfuehrt.
+
+## Quality, Security und Release
+
+- Epic 12 hat RC0-Hardening, Visual Snapshot Automation, Design Token
+  Productization, RMT DSL Authoring Polish und Adoption Guides gebuendelt.
+- Epic 13 hat RC1 Readiness, Release Owner Acceptance, Conditional Network
+  Evidence, Package Export Lock, Trusted DOM, RMT Production Readiness,
+  Visual Owner Artifacts und CI-Handoff konsolidiert.
+- `DPF-WP-02` und `DPF-WP-03` haben Release Report, Pack Dry Run Evidence und
+  Conditional Network Evidence CI produktisiert.
+- `WP-TypeExports-01` bis `WP-TypeExports-09` haben Package `types`
+  Conditions, RMT-/Loader-/API-/Policy-/Builder-/Catalog-/Vendor-Facades und
+  Drift Reports abgesichert.
+
+## Was gehoert nicht mehr in Einzelartikel?
+
+Developer Guides sollen nicht mehr als Release-Protokoll gelesen werden. Neue
+oder ueberarbeitete Artikel sollen:
+
+- produktive Nutzung, Syntax und Architektur erklaeren;
+- lokale Befehle nur dort nennen, wo sie fuer den Arbeitsfluss gebraucht
+  werden;
+- Epic-, WP-, Status- und Handoff-Historie hier im Changelog ablegen;
+- auf `development/` nur verweisen, wenn ein internes Detail wirklich
+  nachvollzogen werden muss.
+
+## Relevante Release-nahe Artikel
+
+- [RMT vNext Release Handoff](./rmt-vnext-release-handoff.md)
+- [RMT vNext Source-to-Sea Gate](./rmt-vnext-source-to-sea-gate.md)
+- [RMT vNext Fabric Bridge Evidence](./rmt-vnext-fabric-bridge-evidence.md)
+- [RMT vNext Primitive Authoring Tooling](./rmt-vnext-primitive-authoring-tooling.md)
+- [RMT vNext Primitive Migration](./rmt-vnext-primitive-migration.md)
+- [RC1 Readiness](./rc1-readiness.md)
+- [RC1 Gate Matrix und CI-Handoff](./rc1-gate-matrix-ci-handoff.md)
+- [Release Report und Pack Dry Run Evidence](./release-report-pack-dry-run-evidence.md)
+- [TypeExports](./type-exports.md)

package/docs/component-catalog-coverage.md

@@ -31,17 +31,17 @@ Der Gate ist aktuell gruen, wenn alle Manifest-Sources lokal aufloesbar sind und
 
 Der Snapshot nach `RC1TB-WP-03` zeigt:
 
-- 42 Manifest-Komponenten
-- 42 lokale Source-Dateien
-- 42 Komponenten-Dokumente
-- 42 Component-Level-Suites und Fixtures
-- 42 Public-Type-Artefakte fuer priorisierte Komponenten
-- 41 Komponenten mit erkennbarer A11y-Oberflaeche
-- 40 Komponenten mit explizitem Runtime-/UI-Performance-Profil
+- 44 Manifest-Komponenten
+- 44 lokale Source-Dateien
+- 44 Komponenten-Dokumente
+- 44 Component-Level-Suites und Fixtures
+- 44 Public-Type-Artefakte fuer priorisierte Komponenten
+- 43 Komponenten mit erkennbarer A11y-Oberflaeche
+- 42 Komponenten mit explizitem Runtime-/UI-Performance-Profil
 
-`x-input`, `x-select`, `x-checkbox`, `x-radio`, `x-rmt-lifecycle-demo-build`, `x-textarea`, `x-form`, `x-calendar`, `x-writer`, `x-status`, `x-progress`, `x-tooltip`, `x-popover`, `x-drawer`, `x-surface-manager`, `x-surface-window`, `x-side-panel`, `x-modal`, `x-dialog`, `x-alert`, `x-toast`, `x-spinner`, `x-router`, `x-link`, `x-tabs`, `x-theme`, `x-button`, `x-icon`, `x-menu`, `x-footer`, `x-lightbox`, `x-masonry`, `x-code`, `x-header`, `x-hero`, `x-type`, `x-summary`, `x-section`, `x-cards` und `x-player` bilden die aktuelle `enterprise-ready` Linie: Source, Docs, Component-Suite, Fixture, Public Types, A11y und Performance-Profil sind vollstaendig vorhanden. `xstate` ist seit [Known Residual Triage](./known-residual-triage.md) als Runtime-Boundary geschlossen; `x-utils` ist als Utility-Boundary geschlossen. Beide bleiben bewusst nicht als visuelle `enterprise-ready` Komponenten klassifiziert.
+`x-input`, `x-select`, `x-checkbox`, `x-radio`, `x-rmt-lifecycle-demo-build`, `x-textarea`, `x-form`, `x-calendar`, `x-writer`, `x-status`, `x-progress`, `x-tooltip`, `x-popover`, `x-drawer`, `x-surface-manager`, `x-surface-portal`, `x-surface-region`, `x-surface-window`, `x-side-panel`, `x-modal`, `x-dialog`, `x-alert`, `x-toast`, `x-spinner`, `x-router`, `x-link`, `x-tabs`, `x-theme`, `x-button`, `x-icon`, `x-menu`, `x-footer`, `x-lightbox`, `x-masonry`, `x-code`, `x-header`, `x-hero`, `x-type`, `x-summary`, `x-section`, `x-cards` und `x-player` bilden die aktuelle `enterprise-ready` Linie: Source, Docs, Component-Suite, Fixture, Public Types, A11y und Performance-Profil sind vollstaendig vorhanden. `xstate` ist seit [Known Residual Triage](./known-residual-triage.md) als Runtime-Boundary geschlossen; `x-utils` ist als Utility-Boundary geschlossen. Beide bleiben bewusst nicht als visuelle `enterprise-ready` Komponenten klassifiziert.
 
-Seit `ER-WP-35` existiert zusaetzlich der Regression-Priority-Plan `xtend.catalog.component-regression-priority-plan.v1`. Er priorisiert alle 42 Manifest-Eintraege fuer `desktop-1280`, `mobile-390`, `light`, `dark`, `forced-colors`, `reduced-motion`, Browser-Smokes und Performance-Profil-Ableitung. Die 40 sichtbaren Runtime-/UI-Komponenten bringen ihre Performance-Profile mit; `xstate` und `x-utils` werden stattdessen ueber ihre Boundary-Contracts bewertet.
+Seit `ER-WP-35` existiert zusaetzlich der Regression-Priority-Plan `xtend.catalog.component-regression-priority-plan.v1`. Er priorisiert alle 44 Manifest-Eintraege fuer `desktop-1280`, `mobile-390`, `light`, `dark`, `forced-colors`, `reduced-motion`, Browser-Smokes und Performance-Profil-Ableitung. Die 42 sichtbaren Runtime-/UI-Komponenten bringen ihre Performance-Profile mit; `xstate` und `x-utils` werden stattdessen ueber ihre Boundary-Contracts bewertet.
 
 ## Handoff
 

package/docs/component-platform.md

@@ -15,6 +15,23 @@ Seit `WP-E10-16` ist Epic 10 abgeschlossen. Der Release-Handoff liegt in [Epic 1
 - Fabric, Telemetry, Lanes, A11y und Performance sind Pflichtdomains im `xtend.component.contract.v2`
 - der Builder erzeugt Contract-, Source-, RMT-, A11y-, Performance- und Fixture-Artefakte als Dry-Run
 
+## RMT vNext Component Capability Registry
+
+Die aktuelle RMT-vNext-Linie ergaenzt diese Plattform um
+`xtend.rmt.component-capability-registry.v1`. Die Registry ist die generische
+RMT-Schnittstelle fuer XTend UI: Sie liest `components/manifest.json`,
+`xtend.component.contract.v2`, `xtendRmtMetadata`, `observedAttributes`,
+Events, Slots, Parts, Form-Assoziation, A11y-Profile und Performance-Profile.
+
+Das Ergebnis ist eine Matrix fuer alle 44 public Manifest-Eintraege und 40
+renderbare UI-Komponenten. RMT kann daraus DOM Descriptoren bauen, Events und
+State-Bridges binden und Komponenten lazy ueber Manifest-Pfade importieren.
+Der RMT-Kernel bleibt dabei framework-neutral und importiert keine XTend-
+Klassen oder Typen.
+
+Details stehen in
+[RMT vNext Component Primitives und XTend UI](./rmt-vnext-component-primitives.md).
+
 ## P0-Komponentenwelle
 
 WP-E10-08 legt die erste P0-Komponentenwelle als `xtend.epic10.p0-component-wave.v1` fest.
@@ -53,7 +70,7 @@ node scripts/run_xtend_tests.js component-lab-rmt-inspector --json
 
 ## RMT-first Demo-App
 
-`WP-E10-13` liefert mit `xtendrmt-rmt-first-demo.html` und `xtendrmt/rmt-first-demo-app.rmt` die erste produktive RMT-first Demo-App ohne manuelle Shell. Die Hostseite stellt nur einen `data-rmt-host="rmt-first-demo"` Root, den lokalen XTend Loader, das lokale Manifest und die RMT Runtime bereit.
+`WP-E10-13` liefert mit `tests/browser/fixtures/rmt-first-demo-app-smoke.html` und `xtendrmt/rmt-first-demo-app.rmt` die erste produktive RMT-first Demo-App ohne manuelle Shell. Die Host-/Smoke-Fixture stellt nur einen `data-rmt-host="rmt-first-demo"` Root, den lokalen XTend Loader, das lokale Manifest und die RMT Runtime bereit.
 
 Die App Shell, Navigation, Routen, Seiten-Templates, Component Records, Schedules, Fabric Lanes und Diagnostics werden aus dem RMT-Dokument gerendert. Die Demo nutzt die komplette Epic-10 P0-Welle: `x-select`, `x-checkbox`, `x-radio`, `x-textarea`, `x-status`, `x-progress`, `x-tooltip`, `x-popover` und `x-drawer`.
 
@@ -143,6 +160,7 @@ Performance ist ebenfalls Contract-Bestandteil. Jede Komponente muss Budgetklass
 
 ```bash
 node scripts/run_xtend_tests.js component-ux-authoring-docs --json
+node scripts/run_xtend_tests.js rmt-vnext-component-primitives --json
 node scripts/run_xtend_tests.js component-long-tail-migration --json
 node scripts/run_xtend_tests.js epic11-enterprise-ux-handoff --json
 node scripts/run_xtend_tests.js component-shell-theme-matrix --json

package/docs/component-ux-app-authoring.md

@@ -2,15 +2,19 @@
 
 Docs Contract: `xtend.docs.component-ux-app-authoring.v1`
 
-Dieser Guide richtet sich an App-Autorinnen und App-Autoren, die XTend-Komponenten in RMT-first Apps einsetzen. Die App kann vollstaendig in RMT templated werden; XTend liefert lokale Web Components und XTendRMT orchestriert Shell, Routes, Templates, Schedules und Diagnostics.
+Dieser Guide richtet sich an App-Autorinnen und App-Autoren, die
+XTend-Komponenten in RMT-first Apps einsetzen. Die App kann vollstaendig in RMT
+vNext geschrieben werden; XTend liefert lokale Web Components und XTendRMT
+orchestriert Shell, Routes, Templates, Schedules und Diagnostics.
 
 ## Grundregeln
 
 - Die App Shell rendert `shell-first`.
-- XTend-Komponenten werden als `xtend.component` Records beschrieben.
+- XTend-Komponenten werden in vNext als `surface ... component x-*`
+  beschrieben und in `xtend.component` Records kompiliert.
 - XRouter wird ueber den Router-Adapter angebunden.
-- Templates verwenden bevorzugt `dom_descriptor`.
-- Events werden als `dom-event-to-rmt-command` gebunden.
+- Templates verwenden bevorzugt `dom_descriptor` als generierten Output.
+- Events werden mit `on ... -> action ...` gebunden.
 - Hydration, Fabric-Lane, Fiber und Diagnostics bleiben schedulebare Metadata.
 - Der RMT-Kernel importiert keine XTend-Klassen oder XTend-Typen.
 
@@ -20,73 +24,62 @@ Boundary:
 no-rmt-kernel-import-of-xtend-types
 ```
 
-## Minimaler Component Record
-
-```json
-{
-  "id": "settings.feedback.status",
-  "kind": "custom_element",
-  "adapter": "xtend.component",
-  "tag": "x-status",
-  "props": {
-    "type": "success",
-    "label": "Scheduler",
-    "message": "Ready"
-  },
-  "a11y": {
-    "role": "status",
-    "live": "polite"
-  },
-  "style": {
-    "theme": "dark",
-    "density": "compact"
-  },
-  "schedule": "component.visible.mount",
-  "fabric": {
-    "lane": "visible",
-    "fiber": "component.mount"
+## Minimaler Component-Surface
+
+```rmt
+template settings.feedback {
+  state settings.feedback.status type string initial "ready"
+
+  selector settings.feedback.view from state settings.feedback.status {
+    output StatusView
+  }
+
+  portal surface.root root "#settings-root" layer surface
+
+  surface settings.feedback.status kind card component x-status {
+    source selector settings.feedback.view
+    portal surface.root
+
+    lane visible weight 80 {
+      mount x-status
+      hydrate feedback-status from selector settings.feedback.view
+    }
   }
 }
 ```
 
+Der Output enthaelt weiterhin `xtend.component`, A11y-, Style-, Schedule- und
+Fabric-Metadaten. Geschrieben wird aber die vNext-Quelle.
+
 ## App-Shell-Muster
 
-```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" }
-  ],
-  "routes": [
-    { "id": "dashboard", "path": "/", "template": "dashboard.page" }
-  ],
-  "templates": [
-    {
-      "id": "dashboard.page",
-      "mode": "dom_descriptor",
-      "children": [
-        { "component": "settings.feedback.status" }
-      ]
+```rmt
+template dashboard.app {
+  state dashboard.theme type string initial "dark"
+  state dashboard.density type string initial "compact"
+  state dashboard.motion type string initial "reduced-motion"
+
+  action dashboard.refresh {
+    emit dashboard.refresh.requested with action dashboard.refresh
+  }
+
+  portal surface.root root "#app-root" layer surface
+
+  surface dashboard.page kind page component x-section {
+    source state dashboard.theme
+    portal surface.root
+
+    lane visible weight 80 {
+      hydrate dashboard-shell from endpoint xtendrmt.route.render
+      hydrate settings-feedback-status from endpoint xtendrmt.component.mount
     }
-  ],
-  "schedules": [
-    {
-      "id": "dashboard.visible.mount",
-      "lane": "visible",
-      "endpoint": "xtend.component.mount",
-      "metadata": {
-        "theme": "dark",
-        "density": "compact",
-        "motion": "reduced-motion"
-      }
+
+    on click target refresh-button -> action dashboard.refresh {
+      payload theme from state.dashboard.theme
+      payload density from state.dashboard.density
+      payload motion from state.dashboard.motion
     }
-  ]
+  }
 }
 ```
 

package/docs/components/xcode.md

@@ -1,83 +1,105 @@
-# xcode – XTend Komponente
+# xcode - XTend Komponente
 
-> **Siehe auch:** [xwriter](./xwriter.md), [xstate](./xstate.md)
+> Siehe auch: [xwriter](./xwriter.md), [xstate](./xstate.md)
 
-## Übersicht
+## Uebersicht
 
-`<x-code>` ist eine Komponente zur Anzeige und Bearbeitung von Quellcode mit Syntax-Highlighting, State-Integration und Theming.
+`<x-code>` rendert Codebeispiele als XTend Web Component mit Copy-Control,
+State-Integration, Theming und optionalem Prism.js Syntax Highlighting. Die
+Komponente ist Shadow-DOM-basiert und kann deshalb in jeder App- oder
+Developer-Center-Surface eingesetzt werden, ohne dass globale `pre code`
+Selektoren in den Host hineinreichen muessen.
 
----
-
-## Features
-- Syntax-Highlighting (z.B. via Prism.js)
-- Sprache wählbar (`lang`-Attribut)
-- State-Integration via xstate
-- Theming via CSS Custom Properties
-
----
+Prism bleibt optional und host-neutral. Wenn `window.Prism` oder ein
+registrierter XCode-Highlighter vorhanden ist, rendert XCode Token-Spans. Wenn
+keine Grammatik verfuegbar ist, bleibt der Code sicher escaped als Plaintext
+sichtbar.
 
 ## Verwendung
 
 ```html
 <x-code lang="js">
-  console.log('Hallo XTend!');
+  <template data-x-code-mode="text">console.log('Hallo XTend!');</template>
 </x-code>
 ```
 
----
-
-## Attribute
-| Attribut    | Typ     | Beschreibung                        |
-|-------------|---------|-------------------------------------|
-| `lang`      | String  | Programmiersprache (default: text)   |
-
----
+Das Alias-Attribut `language` ist fuer bestehende Fixtures und fremde Hosts
+unterstuetzt:
 
-## Events
-| Event         | Beschreibung                        |
-|---------------|-------------------------------------|
-| –             | –                                   |
+```html
+<x-code language="rmt">
+  <template data-x-code-mode="text">template docs.demo { surface root { lane visible { hydrate page } } }</template>
+</x-code>
+```
 
----
+## Prism und RMT
 
-## API
-- **Sprache setzen:** `element.setAttribute('lang', 'css')`
-- **State-Integration:** Automatisch via xstate
+Das Developer Center laedt `components/prism.js` und danach
+`components/prism-rmt.js`. Die RMT-Middleware registriert
+`Prism.languages.rmt` sowie die Aliase `rmt-vnext` und `xtendrmt`. Damit kann
+jede XCode-Instanz RMT-vNext-App-Shells, Primitives, Lanes, Events und
+Boundary-Regeln highlighten:
 
----
+- `template`, `state`, `selector`, `datasource`, `action`, `portal`,
+  `overlay`, `resource`, `surface`, `remote surface`
+- `lane`, Lifecycle-Operationen, `when`, `slot`, `trust boundary`, `sanitize`
+- Event-Bindings, Payloads, Reducer, Effects, dotted Primitive IDs und
+  Component-Tags
 
-## Beispiel: Dynamisch per JS
+Hosts koennen einen eigenen Highlighter registrieren:
 
 ```js
-const code = document.createElement('x-code');
-code.setAttribute('lang', 'html');
-code.textContent = '<h1>Hallo</h1>';
-document.body.appendChild(code);
+customElements.get('x-code')?.registerHighlighter({
+  highlight({ code, language }) {
+    return { html: code, highlighted: false, engine: 'plain-text', language };
+  }
+});
 ```
 
----
+## Developer Center
 
-## Styling & Theming
+Markdown-Codefences aus Parsedown werden nach dem Trusted-DOM-Sanitizing in
+`<x-code>` ueberfuehrt. Dadurch laufen alle Codeflaechen im Developer Center
+ueber denselben Pfad:
 
-```css
-x-code {
-  --background: #222;
-  --color: #fff;
-}
-```
+- Copy-Control und A11y-Signale aus XCode
+- `docs.syntax.highlight` als RMT-Schedule
+- Prism-Highlighting im Shadow DOM
+- Fallback auf Plaintext ohne Raw-HTML-Sink
+
+## Attribute
+
+| Attribut | Typ | Beschreibung |
+| --- | --- | --- |
+| `lang` | String | Primaere Sprache, z. B. `js`, `html`, `rmt` |
+| `language` | String | Kompatibilitaetsalias, wenn `lang` nicht gesetzt ist |
 
----
+## Events
+
+| Event | Beschreibung |
+| --- | --- |
+| `code-copied` | Wird nach erfolgreichem Copy-Control ausgeloest |
+
+## API
 
-## Accessibility
-- Semantisches HTML, Copy-Support
+- `hydrate()` rendert Code und Highlighting neu.
+- `snapshot()` liefert Sprache, Code-Laenge und Highlighting-Metadaten.
+- `customElements.get('x-code').registerHighlighter(provider)` registriert
+  einen optionalen Host-Highlighter.
 
----
+Der Snapshot enthaelt nicht-brechend zusaetzlich:
 
-*Letzte Aktualisierung: 16. Juli 2025*
+- `highlighted`
+- `highlightEngine`
+- `highlightLanguage`
+- `languageAlias`
 
 ## Layout Display Media UX Profil
 
-`x-code` stellt ab `WP-E11-12` das Profil `xtend.component.layout-display-media-ux-profile.v1` bereit. Code-Bloecke koennen damit als idle hydrierbare Display-Shell in RMT authoriert werden und nutzen den State-Key `xcode-state-<id>`.
+`x-code` stellt das Profil
+`xtend.component.layout-display-media-ux-profile.v1` bereit. Code-Bloecke
+koennen damit als idle hydrierbare Display-Shell in RMT authoriert werden und
+nutzen den State-Key `xcode-state-<id>`.
 
 - Profil-Getter: `xtendLayoutDisplayMediaUxProfile`
 - Schedule: `component.idle.hydrate`
@@ -85,9 +107,12 @@ x-code {
 - Snapshot: `snapshot()`
 - CSS Parts: `root`, `copy`, `pre`, `code`
 
-## ECH-WP-07 Token-Tabelle und signatureDesign
+## Token-Tabelle
 
-`signatureDesign`: Lesbare Enterprise-Codeflaeche mit klarem Copy-Control, internem Overflow und eigenstaendiger, themebarer Monospace-Persoenlichkeit. Docs-, IDE- und Corporate-Themes sollen ohne DOM-Aenderung funktionieren.
+ECH-WP-07 bleibt als Tokenization-Contract sichtbar. `signatureDesign`:
+Lesbare Enterprise-Codeflaeche mit klarem Copy-Control, internem Overflow,
+Prism-kompatibler Token-Farbgebung und eigenstaendiger, themebarer
+Monospace-Persoenlichkeit.
 
 | Token | Zweck |
 | --- | --- |
@@ -104,8 +129,13 @@ x-code {
 | `--xtend-layout-focus-ring` | Copy-Control-Fokus |
 | `--xtend-layout-grid-min` | Code-Layout-Untergrenze |
 | `--xtend-layout-content-max` | Code-Maximalbreite |
+| `--x-code-token-keyword` | Prism Keyword und RMT Primitive |
+| `--x-code-token-string` | Prism String |
+| `--x-code-token-property` | Prism Property und RMT IDs |
+| `--x-code-token-class` | Component Tags |
+| `--x-code-token-comment` | Kommentare |
 
-## ECH-WP-07 Fremdtheme
+## Fremdtheme
 
 ```css
 [data-xtend-layout-theme="enterprise-foreign"] x-code {

package/docs/components/xsurfaceportal.md

@@ -0,0 +1,32 @@
+# xsurfaceportal - XTend Komponente
+
+`x-surface-portal` beschreibt benannte Portal- und Layer-Policies fuer den
+`x-surface-manager`. Die Komponente rendert selbst keine sichtbare UI, sondern
+meldet `xtend.surface.portal-policy.v1` an die umgebende Surface-Orchestrierung.
+
+## Attribute
+
+- `portal-id`: stabile Portal-ID, standardmaessig die Element-ID
+- `policy`: `stacked`, `modal`, `nonmodal`, `toast-region` oder `clipping-escape`
+- `layer`: logischer Layer-Name fuer Stack- und Z-Index-Ableitung
+- `for`: optionaler Ziel-Surface- oder Manager-Identifier
+- `z-index-start`: Startwert fuer den Portal-Stack
+- `z-step`: Abstand zwischen verwalteten Stack-Ebenen
+
+## API
+
+`toPortalPolicy()` gibt den serialisierbaren Policy Record fuer
+SurfaceManager, RMT Materialisierung und Resource Graph Runtime zurueck.
+
+Events: `surface-portal-policy`.
+
+RMT: `xtend.rmt.component-contract.v1`,
+`xtend.surface.type-capability-matrix.v1`,
+`xtend.surface.portal-policy.v1`,
+`no-rmt-kernel-import-of-xtend-types`.
+
+## Accessibility und Performance
+
+Die Komponente ist `aria-hidden`, weil die sichtbare und fokussierbare UI durch
+die verwaltete Surface bereitgestellt wird. Das Performance-Profil ist
+`xtend.performance.component-profile.v1` mit der Lane `surface.portal.policy`.

package/docs/components/xsurfaceregion.md

@@ -0,0 +1,37 @@
+# xsurfaceregion - XTend Komponente
+
+`x-surface-region` ist die generische SurfaceManager-Komponente fuer RMT
+Surfaces wie `root`, `workspace`, `page`, `card`, `list`, `region` und
+`overlay-host`. Sie registriert sich bei einem umgebenden `x-surface-manager`
+und uebersetzt RMT Surface Records in Attribute, Bounds, Fokus und Lifecycle
+Commands.
+
+## Attribute
+
+- `surface-id`: stabile Surface-ID fuer Controller und Resource Graph
+- `kind`: RMT Authoring-Semantik, zum Beispiel `page`, `card` oder `workspace`
+- `label`: Accessible Name fuer die Region
+- `open`, `hidden`, `active`: Sichtbarkeit und aktiver Manager-Zustand
+- `mode`: `region` oder `floating`
+- `placement`: optionale Portal-, Docking- oder Layout-Platzierung
+- `initial-x`, `initial-y`, `initial-width`, `initial-height`: Start-Bounds
+- `role`: explizite ARIA-Rolle, sonst `main` fuer `page` und `region` fuer alle anderen Kinds
+
+## API
+
+`toSurfaceRecord(managerId)`, `applySurfaceSnapshot(record)`,
+`openRegion()`, `closeRegion(reason)`, `focusRegion()`, `restoreRegion()` und
+`updateRegion(payload)` bilden die SurfaceController-Schnittstelle additiv ab.
+
+Events: `surface-region-command`.
+
+RMT: `xtend.rmt.component-contract.v1`, `xtend.surface.record.v1`,
+`surface.visible.render`, `surface.user-blocking.open`,
+`surface.transition.layout`, `surface.diagnostics.snapshot`.
+
+## Accessibility und Performance
+
+Der interne Surface-Host setzt `role`, `aria-label`, `aria-hidden` und
+`tabindex="-1"`. Das Performance-Profil ist
+`xtend.performance.component-profile.v1` mit der Lane
+`surface.region.visible`.