@ccslabs/xtend 0.1.0-rc.1 → 0.1.2

package/docs/xtendrmt-overview.md

@@ -1,89 +1,109 @@
 # XTendRMT Developer Overview
 
-- Status: aktuell nach Epic 05 Abschluss
 - Contract: `xtend.docs.xtendrmt-overview.v1`
 - Produktversion: `XTendRMT 0.2.0`
-- Kernartefakte:
-  - `xtendrmt/rmt-core.esm.js`
-  - `xtendrmt/rmt-runtime.esm.js`
-  - `xtendrmt/rmt-runtime.browser.js`
-  - `xtendrmt/rmt-core.d.ts`
-  - `xtendrmt/rmt.schema.json`
-  - `xtendrmt/rmt-manifest.json`
 
-## Zielbild
-
-XTendRMT verbindet zwei Produkte, ohne ihre Grenzen zu verwischen:
+XTendRMT ist die deklarative App-Schicht von XTend. Entwickler schreiben eine
+lesbare `.rmt` Quelle; der Compiler erzeugt daraus Core Records, Kernel-
+Artefakte, Source Maps und Adapter-Uebergaben. XTend UI bleibt das
+Web-Component-System, XTendRMT beschreibt App-Struktur und Lifecycle.
+
+## Produktgrenze
+
+| Ebene | Verantwortung |
+| --- | --- |
+| RMT vNext | App Shell, Surfaces, State, Selectors, Actions, Events, Resources, Lanes |
+| RMT Kernel | Normalisierung, Scheduling, Diagnostics, Source Maps, Kernel Records |
+| Host Adapter | XTend Components, XRouter, DOM, Browser APIs, Framework-Bridges |
+| XTend UI | Web Components, Styling, A11y, Interaktion, sichtbare UI |
+| Fabric | Lanes, Fibers, Telemetry, Backpressure und Runtime-Diagnostics |
+
+Der Kernel bleibt framework-agnostisch. Er importiert keine XTend Components,
+kein XRouter-Modul, keine Browser-APIs und keine Host-Runtime. Alles, was DOM,
+Routing, Component-Importe oder Browser-Zustaende braucht, gehoert in Adapter.
+
+## Warum RMT vNext?
+
+RMT vNext ist die bevorzugte Syntax fuer neue Apps:
+
+- Eine App Shell entsteht aus einer Quelle statt aus verstreutem HTML,
+  Legacy-JSON und Host-Code.
+- UI-Objekte bleiben ueber Primitive IDs, Source Maps, Kernel Records, Fabric
+  Fibers und DOM-Marker korrelierbar.
+- State, Selectors, Actions, DataSources, Events, Portals, Overlays,
+  Resources und Surfaces sind erstklassige Authoring-Primitive.
+- Editor-DX kommt direkt aus dem Language Server: Completion, Hover, Document
+  Symbols, Definition und Code Actions.
+- Legacy- und App-Platform-JSON bleiben kompatible Targets, aber nicht der
+  normale Authoring-Pfad.
+
+## Kleines mentales Modell
+
+```text
+app.rmt
+  -> vNext parser
+  -> semantic primitive graph
+  -> core document + kernel records
+  -> DOM descriptor renderer + component capability registry
+  -> host adapter
+  -> XTend Components / XRouter / Fabric
+  -> sichtbare App im Browser
+```
 
-| Produkt | Rolle |
-|---------|-------|
-| XTend UI | UI Builder und Web-Component-System |
-| XTendRMT | Scheduler, Runtime Kernel und Templating Engine |
+Ein Surface beschreibt einen sichtbaren Bereich. Eine Lane beschreibt, wann
+und mit welcher Prioritaet Arbeit ausgefuehrt wird. Actions und Events
+beschreiben Interaktion. Resources beschreiben Besitz und Cleanup. Adapter
+setzen diese Beschreibung in echte Komponenten und Browser-Arbeit um.
 
-XTend ist First-Class Host fuer RMT, aber keine Pflichtabhaengigkeit des RMT Kernels. RMT kann XTend Components, XRouter Routes und Scheduler Policies beschreiben und ausfuehren lassen, ohne XTend, XRouter, DOM oder `xstate` in den Kernel einzubetten.
+## Kernartefakte
 
-## Aktueller Implementierungsstand
+- `xtendrmt/rmt-core.esm.js`
+- `xtendrmt/rmt-runtime.esm.js`
+- `xtendrmt/rmt-runtime.browser.js`
+- `xtendrmt/rmt-core.d.ts`
+- `xtendrmt/rmt.schema.json`
+- `xtendrmt/rmt-manifest.json`
 
-Epic 05 ist abgeschlossen. Der produktive Pfad besteht aus:
+## Wichtige APIs und Adapter
 
-- nativen `.rmt` Top-Level-Domains: `adapters`, `components`, `routes`, `schedules`, `templates`
 - Runtime Registry fuer Route- und Component-Indizes
+- Component Capability Registry `createRmtComponentCapabilityRegistry`
 - XRouter Adapter `createRmtXRouterAdapter`
 - XTend Component Adapter `createRmtXtendComponentAdapter`
 - State-/Scheduler-/Diagnostics Bridge `createRmtStateSchedulerDiagnosticsBridge`
-- ESM- und Browser-Bundles mit Artefakt-Paritaetsgate
-- Browser-Smoke fuer RMT/XRouter/XTend/Vanilla
-
-Die wichtigsten Regressionen liegen in:
-
-- `tests/fixtures/rmt-app-dsl.native-bridge.rmt`
-- `tests/browser/fixtures/rmt-xrouter-xtend-smoke.html`
-- `xtendrmt/xtendrmt-bestcase-demo.rmt`
-- `xtendrmt-bestcase.html`
-
-## Architekturgrenze
-
-RMT darf:
-
-- `.rmt` Dokumente normalisieren
-- DSL-Domains indizieren
-- Adapter Records validieren
-- Scheduler Policies beschreiben
-- Diagnostics und Reference Graphs erzeugen
-
-RMT darf nicht:
-
-- `components/xrouter.js` importieren
-- XTend Components importieren
-- `window.XTend` voraussetzen
-- `xstate` direkt schreiben
-- DOM-Mounting im Kernel ausfuehren
-- React, Vue, Vanilla oder Custom Hosts auf XTend migrieren
-
-Host-Arbeit gehoert in Adapter. Das ist der Kern der First-Class-Citizen-Strategie: XTend bekommt hochwertige Adapter, aber der Kernel bleibt framework-agnostisch.
+- RMT Language Server fuer Editor-Integrationen
+- Compiler-Ausgaben fuer Core, App-Platform und Kernel Records
 
 ## Offizielle Entwicklerdokumente
 
 | Thema | Dokument |
-|-------|----------|
+| --- | --- |
+| Erste App | [Quick Start Guide](./quick-start-guide.md) |
+| vNext App Authoring | [RMT vNext Authoring Guide](./rmt-vnext-authoring.md) |
+| RMT und XTend UI | [RMT vNext Component Primitives und XTend UI](./rmt-vnext-component-primitives.md) |
 | Native Authoring | [XTendRMT Native Authoring Guide](./xtendrmt-native-authoring.md) |
-| Native App-DSL Referenz | [XTendRMT App-DSL Reference](./xtendrmt-app-dsl.md) |
+| App-DSL Referenz | [XTendRMT App-DSL Reference](./xtendrmt-app-dsl.md) |
 | Runtime Bridge und Adapter | [XTendRMT Runtime Bridge](./xtendrmt-runtime-bridge.md) |
 | Migration aus alten Metadatenpfaden | [XTendRMT Native Migration Guide](./xtendrmt-migration-guide.md) |
-| Docs-App / Parsedown Scheduling | [XTendRMT Parsedown Scheduling Pilot](./xtendrmt-parsedown-scheduling.md) |
+| Editor Setup | [RMT Language Server und Editor Setup](./rmt-language-server.md) |
+| Historie | [XTend Changelog](./changelog.md) |
 
-## Empfohlener lokaler Gate
+## Lokaler Check fuer RMT-Arbeit
 
 ```bash
-node scripts/run_xtend_tests.js references --json
-node scripts/run_xtend_tests.js rmt-compatibility --json
-node scripts/run_xtend_tests.js browser --json
-node scripts/verify_xtendrmt_artifact_parity.js --json
-npm test
+xt rmt lint app.rmt
+node tools/rmt-language-server/server.js
+node scripts/run_xtend_tests.js rmt-vnext-parser rmt-vnext-compiler rmt-vnext-tooling --json
+node scripts/run_xtend_tests.js rmt-vnext-component-primitives --json
 ```
 
-`references` prueft die offizielle Entwicklerdokumentation, `rmt-compatibility` prueft DSL, Adapter, Bridge und Artefakt-Paritaet, `browser` prueft den browsernahen Multi-Host-Pfad.
+Fuer Runtime- und Adapter-Paritaet bleiben zwei repo-lokale Gates wichtig:
 
-## Entwicklungsregel
+- `tests/browser/fixtures/rmt-xrouter-xtend-smoke.html` prueft, dass RMT,
+  XRouter, XTend Components und Vanilla-Host zusammen sichtbar rendern.
+- `node scripts/verify_xtendrmt_artifact_parity.js --json` prueft, dass
+  Schema, Manifest, Typen, ESM-Bundles und Browser-Bundle zusammenpassen.
 
-Neue RMT-nahe Arbeit soll zuerst klaeren, ob sie Kernel-, DSL-, Adapter-, Host- oder Dokumentationsverantwortung ist. Wenn XTend-spezifisches Verhalten benoetigt wird, entsteht ein Adapter- oder Host-Contract, kein Kernel-Sonderfall.
+Neue RMT-nahe Arbeit soll zuerst klaeren, ob sie Kernel-, Syntax-, Adapter-,
+Host- oder Dokumentationsverantwortung ist. XTend-spezifisches Verhalten wird
+ueber Adapter modelliert, nicht als Kernel-Sonderfall.

package/docs/xtendrmt-parsedown-scheduling.md

@@ -4,21 +4,34 @@
 - Contract: `xtend.docs.parsedown-rmt-scheduling.v1`
 - Pilot Contract: `xtend.docs.parsedown-rmt-pilot.v1`
 - Production-Hardening Contract: `xtend.epic13.docs-rmt-production-hardening.v1`
+- PHP-SSR-Prehydration Contract: `xtend.docs.php-ssr-prehydration.v1`
 - Pilot-Dokument: `docs/xtendrmt-parsedown-docs.rmt`
+- vNext-Shell-Dokument: `docs/xtendrmt-docs-shell-vnext.rmt`
 - Aktuelle Runtime: `docs/index.php` + `docs/utils/parsedown.php` + `docs/utils/pageloader.js`
 
 ## Zweck
 
 Die offizielle XTend Dokumentation ist selbst eine XTend-App. Markdown-Dateien im `docs` Ordner werden serverseitig ueber Parsedown nach HTML gewandelt und clientseitig ueber XRouter als SPA angezeigt. Der Host spiegelt nur noch die initial benoetigte HTML-Seite in `window.xtendDocsPages`; weitere Parsedown-Payloads werden pro Route ueber `window.xtendDocsPageEndpoint` nachgeladen.
 
-Der aktuelle Stand ist Shell-first: Die sichtbare Page-Shell wird nicht mehr rein imperativ im PageLoader gebaut, sondern aus `docs.app.shell` im RMT-Pilot-Dokument als `dom_descriptor` gerendert. Parsedown bleibt Host-Adapter und fuellt nur noch den Content-Slot. Damit kann die Docs-App spaeter neben Markdown auch Rich-HTML- oder XPlayer-Tutorial-Inhalte als RMT-geplante Slots nachladen; der maschinenlesbare Content-Kind dafuer ist `xplayerTutorial`. Parsedown und XTend werden dabei nicht in den RMT Kernel eingebettet.
+Der aktuelle Stand ist Shell-first mit serverseitiger Prehydration: `docs/index.php`
+laedt `xtendrmt/rmt-php-ssr-adapter.php`, kompiliert
+`docs/xtendrmt-docs-shell-vnext.rmt` ueber
+`scripts/compile_rmt_vnext_bridge.js` und rendert die Root-Shell als RMT DOM
+Descriptor. Die sichtbare Page-Shell wird weiter aus `docs.app.shell` im
+RMT-Pilot-Dokument beschrieben; Parsedown bleibt Host-Adapter und fuellt nur
+noch den Content-Slot. Damit kann die Docs-App spaeter neben Markdown auch
+Rich-HTML- oder XPlayer-Tutorial-Inhalte als RMT-geplante Slots nachladen; der
+maschinenlesbare Content-Kind dafuer ist `xplayerTutorial`. Parsedown und XTend
+werden dabei nicht in den RMT Kernel eingebettet.
 
 ## ER-WP-40 Pilot-Artefakte
 
 | Artefakt | Rolle |
 |----------|-------|
 | `docs/xtendrmt-parsedown-docs.rmt` | RMT-Pilot-Dokument fuer Shell-first-Templates, Docs-Routen, Parsedown-Templates, Schedules, Rich-Content-Slots und Host-Adapter |
+| `docs/xtendrmt-docs-shell-vnext.rmt` | vNext-Source fuer Root Shell, Header, Hero, Router, Footer, Page Shell, Sidebar, Search, Related Links und Diagnostics als RMT-Primitives |
 | `docs/index.php` | aktiver Parser-Host, setzt `Parsedown::setSafeMode(true)` und spiegelt `window.xtendDocsRmtDocument`, `window.xtendDocsRmtPilot` sowie `window.xtendDocsPagesMeta` |
+| `scripts/compile_rmt_vnext_bridge.js` | sichere Node-Bridge fuer `compileRmtVNextSource` im PHP-Host |
 | `docs/utils/pageloader.js` | rendert `docs.app.shell` und `docs.header.search` aus RMT-`dom_descriptor`-Templates, markiert Content-Slots mit `data-rmt-template`, `data-rmt-parse-schedule`, `data-rmt-trust-boundary` und `xtend.docs.parsedown-rmt-render.v1` |
 | `tests/rmt/docs_rmt_pilot_suite.js` | Gate fuer RMT-Normalisierung, Runtime-Registry, Trusted-DOM-Boundary und Docs-App-Anschluss |
 | `package.json` | Metadaten unter `xtend.docsRmtPilot` und Script `npm run test:docs-rmt-pilot` |
@@ -32,13 +45,15 @@ Ab der Skeleton-Haertung nutzt der Pilot den nativen `xtend.loader.skeleton-load
 ## Aktueller Docs-App-Fluss
 
 1. `docs/index.php` findet alle `.md` Dateien rekursiv.
-2. `docs/utils/parsedown.php` wandelt nur die initiale oder per Route angefragte Markdown-Datei in HTML.
-3. `window.xtendDocsPagesMeta` enthaelt die SEO-, Schedule- und RMT-Metadaten nach Slug; `window.xtendDocsPages` enthaelt nur vorhandene HTML-Payloads.
-4. `<x-router mode="hash" skeleton="article">` routet auf `xtend-doc-page`, lazy-laedt dessen Modul und hydriert den Route-Subtree ueber den Loader.
-5. `docs/utils/pageloader.js` liest `window.xtendDocsRmtDocument` und rendert `docs.app.shell` Shell-first.
-6. Der `data-rmt-slot="content"` Slot zeigt einen nativen SkeletonLoader, bis Parsedown-HTML nach dem ersten Paint sanitisiert und eingesetzt wurde.
-7. `docs.header.search` liefert die Header-Suche als RMT-Descriptor fuer den `search` Slot von `x-header`.
-8. `docs/menu.json` definiert die sichtbare Navigationshierarchie; `pageloader.js` gruppiert und priorisiert sie fuer die Drawer-Navigation.
+2. Der PHP-Host injiziert `compileRmtVNextSource` ueber die Node-Bridge und rendert die App Shell mit dem PHP SSR Adapter.
+3. `window.xtendDocsSsrPrehydration` enthaelt `renderman_template_chunk`, Hydration, Diagnostics und den JSONL-SSR-Endpunkt.
+4. `docs/utils/parsedown.php` wandelt nur die initiale oder per Route angefragte Markdown-Datei in HTML.
+5. `window.xtendDocsPagesMeta` enthaelt die SEO-, Schedule- und RMT-Metadaten nach Slug; `window.xtendDocsPages` enthaelt nur vorhandene HTML-Payloads.
+6. `<x-router mode="hash" skeleton="article">` routet auf `xtend-doc-page`, lazy-laedt dessen Modul und hydriert den Route-Subtree ueber den Loader.
+7. `docs/utils/pageloader.js` liest `window.xtendDocsRmtDocument`, reused vorhandene SSR-Shells ueber `data-rmt-shell-prehydrated="true"` und rendert nur bei Degradation den Client-Fallback.
+8. Der `data-rmt-slot="content"` Slot zeigt einen nativen SkeletonLoader, bis Parsedown-HTML nach dem ersten Paint sanitisiert und eingesetzt wurde.
+9. `docs.header.search` liefert die Header-Suche als RMT-Descriptor fuer den `search` Slot von `x-header`.
+10. `docs/menu.json` definiert die sichtbare Navigationshierarchie; `pageloader.js` gruppiert und priorisiert sie fuer die Drawer-Navigation.
 
 Seit dem Document-Title-Rewrite werden pro Markdown-Datei zusaetzlich RMT Route Records erzeugt und in `window.xtendDocsRmtDocument.routes` gespiegelt. `docs/index.php` extrahiert den ersten H1 als `title`, erzeugt `documentTitle`, `titleTemplate`, `metaDescription` und `metaKeywords` und rendert daraus die sichtbaren `<x-route>` Attribute `title`, `document-title`, `title-template`, `meta-description` und `meta-keywords`. XRouter fuehrt anschliessend das eigentliche Schreiben von `document.title` und der SEO-Metatags aus. Damit bleibt der Use Case RMT-deklarativ, waehrend die Browser-Seiteneffekte im XRouter Adapter liegen.
 

package/fabric/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ccslabs/xtend-fabric",
-  "version": "0.1.0-rc.1",
+  "version": "0.1.2",
   "private": false,
   "description": "XTend Fabric runtime for safety, telemetry, diagnostics and lane mapping.",
   "license": "Apache-2.0",