@ccslabs/xtend 0.1.0-rc.1 → 0.1.2

package/docs/surface-manager-migration-guide.md

@@ -7,7 +7,11 @@
 
 ## Ziel
 
-Dieser Guide beschreibt die additive Migration von Surface-Metadata in Component Records zu nativen RMT Surface Records. Die Migration ist bewusst ohne Big Bang: bestehende `components[*].metadata.surface` Records bleiben gueltig, waehrend neue App Shells `surfaces[*]` bevorzugen.
+Dieser Guide beschreibt die additive Migration von Surface-Metadata in Component
+Records zu nativen RMT Surface Records. Die Migration ist bewusst ohne Big
+Bang: bestehende `components[*].metadata.surface` Records bleiben gueltig,
+waehrend neue App Shells in RMT vNext authoriert werden. `surfaces[*]` ist der
+Runtime- und Compatibility-Output, nicht die neue Handarbeit.
 
 ## Migrationsschritte
 
@@ -17,10 +21,29 @@ Dieser Guide beschreibt die additive Migration von Surface-Metadata in Component
 | `stabilize-surface-ids-and-state-keys` | IDs, `type`, `manager` und `stateKey` einfrieren |
 | `add-native-surfaces-records` | parallele `surfaces[*]` Records mit gleicher Identitaet anlegen |
 | `keep-dual-records-during-handoff` | Component-Metadata und native Records im Gate vergleichen |
-| `switch-authoring-default-to-surfaces-domain` | neue komplexe Shells direkt in `surfaces[*]` schreiben |
+| `switch-authoring-default-to-vnext-surfaces` | neue komplexe Shells als `surface ... component ...` in RMT vNext schreiben |
 | `close-xtend-surface-runtime-after-adapter-implementation` | historisches Adapter-Handoff aus `WP-SM-09` durch `WP-SM-19` Runtime-Gates schliessen |
 
-## Vorher
+## vNext-Zielbild
+
+```rmt
+template workbench.surfaceMigration {
+  state workbench.properties type object initial null
+
+  portal surface.root root "#workbench-root" layer surface
+
+  surface surface.properties kind side-panel component x-side-panel {
+    source state workbench.properties
+    portal surface.root
+
+    lane visible weight 70 {
+      hydrate properties-panel from state workbench.properties
+    }
+  }
+}
+```
+
+## Vorher: Legacy Component Metadata
 
 ```json
 {
@@ -38,7 +61,7 @@ Dieser Guide beschreibt die additive Migration von Surface-Metadata in Component
 }
 ```
 
-## Nachher als Dual Record
+## Nachher: Dual Record als Runtime-Output
 
 ```json
 {
@@ -58,7 +81,9 @@ Dieser Guide beschreibt die additive Migration von Surface-Metadata in Component
 }
 ```
 
-Die Component-Metadata bleibt waehrend des Handoffs im Component Record und verweist optional mit `nativeRecord` auf den nativen Record.
+Die Component-Metadata bleibt waehrend des Handoffs im Component Record und
+verweist optional mit `nativeRecord` auf den nativen Record. Neue Beispiele
+sollen das vNext-Zielbild zeigen; Dual Records dienen als Migrationsevidence.
 
 ## Review-Checkliste
 
@@ -91,4 +116,7 @@ node scripts/run_xtend_tests.js surface-browser-lab --json
 node scripts/run_xtend_tests.js surface-runtime-release-handoff --json
 ```
 
-Bestehende `components[*].metadata.surface` Records bleiben erlaubt. Der Zielzustand fuer neue Shells ist dennoch `surfaces[*]`, weil Tooling, Materialisierung, Persistenz, Routing, Remote Policy und Browser-Lab-Stabilitaet dort gemeinsam pruefbar sind.
+Bestehende `components[*].metadata.surface` Records bleiben erlaubt. Der
+Zielzustand fuer neue Shells ist dennoch RMT vNext; `surfaces[*]` bleibt der
+pruefbare Output, weil Tooling, Materialisierung, Persistenz, Routing, Remote
+Policy und Browser-Lab-Stabilitaet dort gemeinsam pruefbar sind.

package/docs/surface-manager-overlay-bridge.md

@@ -1,6 +1,6 @@
 # SurfaceManager Overlay Bridge
 
-`WP-SM-06` fuehrt `xtend.surface.overlay-stack-bridge.v1` ein. Die Bridge macht `x-modal`, `x-dialog` und `x-drawer` optional kompatibel mit dem `x-surface-manager` Surface Stack.
+`WP-SM-06` fuehrt `xtend.surface.overlay-stack-bridge.v1` ein. Die Bridge macht `x-modal`, `x-dialog`, `x-drawer`, `x-popover`, `x-tooltip`, `x-toast`, `x-lightbox` und `x-menu` optional kompatibel mit dem `x-surface-manager` Surface Stack.
 
 ## Was sich aendert
 
@@ -9,8 +9,13 @@
 - `x-modal` als Surface Type `modal`
 - `x-dialog` als Surface Type `dialog`
 - `x-drawer` als Surface Type `drawer`
+- `x-popover` als Surface Type `popover`
+- `x-tooltip` als Surface Type `tooltip`
+- `x-toast` als Surface Type `toast`
+- `x-lightbox` als Surface Type `lightbox`
+- `x-menu` als Surface Type `menu`
 
-Die bestehenden Overlay APIs bleiben erhalten. Ein Modal kann weiter ueber `open()` und `close()` gesteuert werden, ein Drawer weiter ueber `openDrawer()` und `closeDrawer()`. Die Legacy Events `modal-opened`, `dialog-opened` und `drawer-opened` bleiben sichtbar.
+Die bestehenden Overlay APIs bleiben erhalten. Ein Modal kann weiter ueber `open()` und `close()` gesteuert werden, ein Drawer weiter ueber `openDrawer()` und `closeDrawer()`. Die Legacy Events `modal-opened`, `dialog-opened`, `drawer-opened`, `popover-opened`, `tooltip-opened`, `toast-shown` und `lightbox-opened` bleiben sichtbar.
 
 ## Command Bridge
 
@@ -27,7 +32,7 @@ manager.dispatchEvent(new CustomEvent('surface-overlay-command', {
 }));
 ```
 
-Unterstuetzt werden die vorhandenen Surface-Operationen wie `open`, `close`, `focus` und `update`. Der Manager nutzt dafuer denselben Controller Stack wie Windows und SidePanels.
+Unterstuetzt werden die vorhandenen Surface-Operationen wie `open`, `close`, `focus` und `update`. `show`, `hide`, `toggle` und `dismiss` werden additiv auf die Manager-Operationen normalisiert. Der Manager nutzt dafuer denselben Controller Stack wie Windows und SidePanels.
 
 ## Stack-Verhalten
 
@@ -36,7 +41,7 @@ Die Bridge spiegelt den Surface Snapshot in Overlay CSS Custom Properties:
 - `--surface-overlay-z`
 - `--surface-overlay-backdrop-z`
 
-Ausserhalb eines SurfaceManagers behalten `x-modal`, `x-dialog` und `x-drawer` ihre bisherigen Default-z-Indizes.
+Ausserhalb eines SurfaceManagers behalten die Overlay-Komponenten ihre bisherigen Default-z-Indizes.
 
 ## RMT und Lifecycle
 

package/docs/surface-manager-rmt-authoring.md

@@ -2,7 +2,10 @@
 
 Docs Contract: `xtend.docs.surface-manager-rmt-authoring.v1`
 
-Der SurfaceManager ist der geplante XTend App-Shell-Baustein fuer Multi Window Oberflaechen, SidePanels und spaetere Surface-Typen in einer SPA. `WP-SM-01` definiert zuerst das RMT Authoring Model; Runtime-Komponenten folgen in den naechsten Paketen.
+Der SurfaceManager ist der XTend App-Shell-Baustein fuer Multi Window
+Oberflaechen, SidePanels und spaetere Surface-Typen in einer SPA. `WP-SM-01`
+definiert zuerst das RMT Authoring Model; Runtime-Komponenten folgen in den
+naechsten Paketen.
 
 ## Entscheidung
 
@@ -12,48 +15,56 @@ SurfaceManager wird als RMT-native Komponentenfamilie aufgebaut:
 - `x-surface-window`
 - `x-side-panel`
 
-Fabric bleibt darunter fuer Lanes, Fibers, Diagnostics und Telemetry. Der SurfaceManager ersetzt Fabric nicht.
+Fabric bleibt darunter fuer Lanes, Fibers, Diagnostics und Telemetry. Der
+SurfaceManager ersetzt Fabric nicht.
 
 ## MVP Authoring
 
-Der MVP nutzt vorhandene RMT `components` Records mit `metadata.surfaceManager` und `metadata.surface`:
-
-```json
-{
-  "id": "workbench.manager",
-  "kind": "custom_element",
-  "adapter": "xtend.component",
-  "tag": "x-surface-manager",
-  "schedule": "surface.visible.render",
-  "metadata": {
-    "surfaceManager": {
-      "schema": "xtend.surface.manager.v1",
-      "stateKey": "xtend.surface.registry",
-      "defaultLayer": "workspace"
+Neue SurfaceManager-Beispiele werden vNext-first geschrieben. Der Compiler kann
+daraus weiterhin vorhandene RMT `components` Records mit
+`metadata.surfaceManager` und `metadata.surface` erzeugen:
+
+```rmt
+template workbench.surfaces {
+  state workbench.selection type object initial null
+
+  portal surface.root root "#workbench-root" layer surface
+
+  surface workbench.manager kind workspace component x-surface-manager {
+    portal surface.root
+
+    lane visible weight 90 {
+      mount x-surface-manager
+      hydrate surface-manager from endpoint surface.visible.render
     }
   }
-}
-```
 
-```json
-{
-  "id": "workbench.inspector",
-  "kind": "custom_element",
-  "adapter": "xtend.component",
-  "tag": "x-surface-window",
-  "schedule": "surface.user-blocking.open",
-  "metadata": {
-    "surface": {
-      "schema": "xtend.surface.record.v1",
-      "type": "window",
-      "manager": "workbench.manager",
-      "stateKey": "xtend.surface.inspector.state"
+  surface workbench.inspector kind window component x-surface-window {
+    source state workbench.selection
+    portal surface.root
+
+    lane user-blocking weight 95 {
+      hydrate inspector-window from endpoint surface.user-blocking.open
+    }
+
+    lane transition weight 55 {
+      hydrate inspector-layout from endpoint surface.transition.layout
+    }
+  }
+
+  surface workbench.details kind panel component x-side-panel {
+    portal surface.root
+
+    lane visible weight 70 {
+      hydrate details-panel from state workbench.selection
     }
   }
 }
 ```
 
-`xtend.surface` und eine native RMT `surfaces` Domain sind reserviert, aber noch nicht aktiv.
+`xtend.surface` und eine native RMT `surfaces` Domain bleiben die Runtime-
+Projektion dieses vNext-Pfads. Legacy `components[*].metadata.surface` ist
+Migrationsquelle und Mirror, aber nicht mehr die bevorzugte Schreibform.
 
 ## Schedules
 
@@ -75,7 +86,10 @@ Das Referenzdokument liegt in:
 tests/fixtures/rmt-surface-manager-workbench.rmt
 ```
 
-Es beschreibt eine Shell-first Workbench mit zwei `x-surface-window` Records und einem `x-side-panel` Record.
+Es beschreibt eine Shell-first Workbench mit zwei `x-surface-window` Records und
+einem `x-side-panel` Record. Die naechste Dokumentationslinie sollte dieselbe
+Workbench als RMT-vNext-Draft zeigen und die Records nur noch als
+Compiler-/Compatibility-Output fuehren.
 
 ## Gate
 
@@ -83,4 +97,6 @@ Es beschreibt eine Shell-first Workbench mit zwei `x-surface-window` Records und
 node scripts/run_xtend_tests.js rmt-surface-authoring --json
 ```
 
-Der Gate prueft `xtend.rmt.surface-authoring.v1`, das Fixture, Package-/Scaffold-Hooks, Runner-Registrierung, Docs und die RMT-Core-Normalisierung ohne Browser- oder Netzwerkpflicht.
+Der Gate prueft `xtend.rmt.surface-authoring.v1`, das Fixture,
+Package-/Scaffold-Hooks, Runner-Registrierung, Docs und die
+RMT-Core-Normalisierung ohne Browser- oder Netzwerkpflicht.

package/docs/surface-manager-workbench-fixture.md

@@ -11,9 +11,8 @@ Runtime Contract: `xtend.surface.workbench-fixture.v1`
 | Pfad | Zweck |
 |------|-------|
 | `xtendrmt/surface-workbench.rmt` | RMT-Dokument mit App Shell, Route, SurfaceManager, zwei Windows, SidePanel und Content |
-| `xtendrmt-surface-workbench.html` | Host-Datei ohne manuelle Surface-Komponenten |
+| `tests/browser/fixtures/rmt-surface-workbench-smoke.html` | Host-/Smoke-Fixture ohne manuelle Surface-Komponenten |
 | `xtendrmt/surface-workbench.js` | Workbench Renderer fuer `dom_descriptor`, Slots, Routes und Snapshot |
-| `tests/browser/fixtures/rmt-surface-workbench-smoke.html` | vorbereiteter Browser-Smoke fuer spaetere Surface-Gates |
 
 ## Modell
 

package/docs/third-party-design-authoring.md

@@ -255,6 +255,7 @@ Dieses Beispiel kombiniert XTend.css, XTheme, CSS Parts, Icon Pack, Header Mode,
 <html data-theme="light" data-xtend-density="compact">
   <head>
     <link rel="stylesheet" href="/xtend.css">
+    <meta name="xtend-preload" content="x-theme,x-header,x-link,x-button,x-icon">
     <style>
       @layer xtend-customer {
         :root {
@@ -334,7 +335,6 @@ Dieses Beispiel kombiniert XTend.css, XTheme, CSS Parts, Icon Pack, Header Mode,
     <script type="module" src="/xtend-loader.js" data-manifest="/components/manifest.json"></script>
   </head>
   <body>
-    <x-theme></x-theme>
     <x-header menu-mode="side-panel" menu-placement="end" menu-modal>
       <span slot="title">Acme Operations</span>
       <x-link slot="nav" href="/overview" aria-current="page">Overview</x-link>

package/docs/type-exports.md

@@ -28,8 +28,8 @@ npm run test:type-exports:release
 | Legacy Loader | `./legacy-loader` | `./xtend-dev.d.ts` | `WP-TypeExports-02` completed |
 | Core API | `./api` | `./api.d.ts` | `WP-TypeExports-03` completed |
 | Components | `./components/*` | `./components/*.d.ts` | `ER-WP-34` |
-| RMT Runtime | `./rmt`, `./rmt/browser` | `./xtendrmt/rmt-core.d.ts` | `WP-TypeExports-04` completed |
-| RMT Language und Tooling | `./rmt-language/*`, `./rmt-linter/*`, `./rmt-language-server/*` | jeweiliges `tools/**/*.d.ts` plus `./tools/rmt-language/rmt-tooling-public-types.d.ts` | `WP-TypeExports-04` completed |
+| RMT Runtime | `./rmt`, `./rmt/browser`, `./rmt/dom-descriptor-renderer`, `./rmt/component-capability-registry`, `./rmt/state-selector-runtime`, `./rmt/action-effect-runtime`, `./rmt/event-routing-runtime`, `./rmt/surface-resource-graph-runtime` | `./xtendrmt/rmt-core.d.ts`, `./xtendrmt/rmt-dom-descriptor-renderer.d.ts`, `./xtendrmt/rmt-component-capability-registry.d.ts`, `./xtendrmt/rmt-state-selector-runtime.d.ts`, `./xtendrmt/rmt-action-effect-runtime.d.ts`, `./xtendrmt/rmt-event-routing-runtime.d.ts`, `./xtendrmt/rmt-surface-resource-graph-runtime.d.ts` | `WP-TypeExports-04` completed |
+| RMT Language und Tooling | `./rmt-language/*`, `./rmt-language/app-platform-tooling`, `./rmt-linter/*`, `./rmt-language-server/*` | jeweiliges `tools/**/*.d.ts` plus `./tools/rmt-language/rmt-tooling-public-types.d.ts` | `WP-TypeExports-04` completed |
 | Fabric, A11y, Security | `./fabric`, `./a11y/*`, `./security/*` | jeweiliges Runtime-Modul als `.d.ts` plus `./fabric/xtend-policy-public-types.d.ts` | `WP-TypeExports-05` completed |
 | Builder | `./builder`, `./builder/*` | `./xtend-builder/**/*.d.ts` plus `./xtend-builder/builder-public-types.d.ts` | `WP-TypeExports-06` completed |
 | Catalog | `./catalog/*` | `./catalog/*.d.ts` plus `./catalog/catalog-public-types.d.ts` | `WP-TypeExports-07` completed |
@@ -58,4 +58,4 @@ Der Report `xtend.type-exports.drift-report.v1` prueft:
 
 ## Handoff
 
-`WP-TypeExports-02` hat `./xtend-loader.d.ts`, `./xtend-dev.d.ts` und [XTend Loader Types](./xtend-loader-types.md) geliefert. `WP-TypeExports-03` hat `./api.d.ts` und [XTend API Types](./xtend-api-types.md) fuer `window.XTend.*` geliefert. `WP-TypeExports-04` hat `./xtendrmt/rmt-core.d.ts`, `./tools/rmt-language/rmt-tooling-public-types.d.ts`, die RMT-Language-Facades und [XTend RMT Types](./xtend-rmt-types.md) geliefert. `WP-TypeExports-05` hat `./fabric/xtend-policy-public-types.d.ts`, Fabric/A11y/Security-Facades und [XTend Policy Types](./xtend-policy-types.md) geliefert. `WP-TypeExports-06` hat `./xtend-builder/builder-public-types.d.ts`, Builder-/Scaffold-/Component-Lab-Facades und [XTend Builder Types](./xtend-builder-types.md) geliefert. `WP-TypeExports-07` hat `./catalog/catalog-public-types.d.ts`, Catalog-Facades und [XTend Catalog Types](./xtend-catalog-types.md) geliefert. `WP-TypeExports-08` hat `./design-tokens/xtend-design-tokens.d.ts`, `./design-tokens/xtheme-token-alias-layer.d.ts`, `./components/prism.d.ts`, `./components/turndown.d.ts` und [XTend Vendor and Utility Types](./xtend-vendor-types.md) geliefert. `WP-TypeExports-09` produktisiert den Drift-Report und das Package-Handoff fuer Release Owner.
+`WP-TypeExports-02` hat `./xtend-loader.d.ts`, `./xtend-dev.d.ts` und [XTend Loader Types](./xtend-loader-types.md) geliefert. `WP-TypeExports-03` hat `./api.d.ts` und [XTend API Types](./xtend-api-types.md) fuer `window.XTend.*` geliefert. `WP-TypeExports-04` hat `./xtendrmt/rmt-core.d.ts`, `./tools/rmt-language/rmt-tooling-public-types.d.ts`, `./tools/rmt-language/app-platform-tooling.d.ts`, die RMT-Language-Facades und [XTend RMT Types](./xtend-rmt-types.md) geliefert. `WP-TypeExports-05` hat `./fabric/xtend-policy-public-types.d.ts`, Fabric/A11y/Security-Facades und [XTend Policy Types](./xtend-policy-types.md) geliefert. `WP-TypeExports-06` hat `./xtend-builder/builder-public-types.d.ts`, Builder-/Scaffold-/Component-Lab-Facades und [XTend Builder Types](./xtend-builder-types.md) geliefert. `WP-TypeExports-07` hat `./catalog/catalog-public-types.d.ts`, Catalog-Facades und [XTend Catalog Types](./xtend-catalog-types.md) geliefert. `WP-TypeExports-08` hat `./design-tokens/xtend-design-tokens.d.ts`, `./design-tokens/xtheme-token-alias-layer.d.ts`, `./components/prism.d.ts`, `./components/turndown.d.ts` und [XTend Vendor and Utility Types](./xtend-vendor-types.md) geliefert. `WP-TypeExports-09` produktisiert den Drift-Report und das Package-Handoff fuer Release Owner.