@ccslabs/xtend 0.1.0-rc.1

package/docs/rmt-lifecycle-demo.md

@@ -0,0 +1,25 @@
+# RMT Lifecycle Demo
+
+Contract: `xtend.rmt.lifecycle-demo.v1`
+
+Die Lifecycle-Demo zeigt den kompletten Pfad von RMT Authoring bis zur
+oeffnbaren XTend App:
+
+1. `xtendrmt/rmt-lifecycle-demo.rmt` ist das RMT vNext Template.
+2. `node xtend-builder/scaffold.js rmt-lifecycle-demo --write --json` kompiliert
+   das Template in `xtendrmt/rmt-lifecycle-demo.core.json`.
+3. Derselbe Scaffold-Build schreibt die generierten Artefakte:
+   `components/x-rmt-lifecycle-demo.js`,
+   `xtendrmt/rmt-lifecycle-demo.app.js`,
+   `xtendrmt-rmt-lifecycle-demo.html` und
+   `tests/browser/fixtures/rmt-lifecycle-demo-smoke.html`.
+4. Die App kann ueber den lokalen HTTP-Server geoeffnet werden:
+   `node scripts/serve_xtend_dev.js --default xtendrmt-rmt-lifecycle-demo.html`.
+
+Der Build-Report liegt in `xtendrmt/rmt-lifecycle-demo.scaffold.json`. Er
+haelt Source, Core Output, generierte XTend App, Browser-Smoke und den lokalen
+Gate `node scripts/run_xtend_tests.js rmt-lifecycle-demo --json` zusammen.
+
+Die generierten Dateien sind absichtlich mit `@generated by XTend Scaffold RMT
+lifecycle build` markiert. Aenderungen sollen am vNext Template oder am
+Scaffold-Generator erfolgen, nicht direkt an den generierten Artefakten.

package/docs/rmt-linter.md

@@ -0,0 +1,140 @@
+# RMT Linter und AI-Agent Repair Report
+
+- Status: produktiv vorbereitet ab `WP-E14-14`
+- Contract: `xtend.rmt.tooling-docs.v1`
+- Linter Report: `xtend.rmt.linter.report.v1`
+- Agent Report: `xtend.rmt.ai-agent-repair-report.v1`
+- Primaerer Dateityp: `.rmt`
+- Lokaler Gate: `node scripts/run_xtend_tests.js rmt-tooling-docs --json`
+
+## Zweck
+
+Der RMT Linter macht native `.rmt` Dokumente lokal, in CI und fuer AI-Agenten pruefbar. Er nutzt dieselbe Sprachebene wie der RMT Language Server:
+
+- Source Model
+- Parser und Format Adapter
+- Semantic Graph
+- Linter Rules
+- Code Actions
+- Agent Repair Report
+
+Der Linter fuehrt keine XTend-Komponenten aus, startet keinen XRouter und materialisiert kein DOM. Er analysiert RMT als Sprache.
+
+## Standardbefehl
+
+```bash
+xt rmt lint app.rmt
+```
+
+Der Langpfad bleibt ebenfalls gueltig:
+
+```bash
+xtend rmt lint app.rmt
+```
+
+Directory- und einfache Glob-Targets sind moeglich:
+
+```bash
+xt rmt lint tests/rmt-language/fixtures
+xt rmt lint "tests/rmt-language/fixtures/*.rmt" --json
+```
+
+## JSON Report
+
+```bash
+xt rmt lint app.rmt --json
+```
+
+Der Report ist fuer CI und andere Tools gedacht:
+
+```json
+{
+  "schema": "xtend.rmt.linter.report.v1",
+  "status": "failed",
+  "files": 1,
+  "diagnostics": []
+}
+```
+
+## Fail Policy
+
+Standard ist `--fail-on error`. Warnungen brechen den lokalen Lauf dann nicht ab.
+
+```bash
+xt rmt lint app.rmt --fail-on warning
+xt rmt lint app.rmt --fail-on info
+```
+
+Damit kann CI strenger laufen als lokale Authoring-Loops.
+
+## Agent Report
+
+AI-Agenten nutzen den Repair Report:
+
+```bash
+xt rmt lint app.rmt --agent
+```
+
+`--agent` impliziert JSON und liefert:
+
+- `diagnostics`
+- `repairPlan`
+- `fixOrder`
+- `noOps`
+- `confidence`
+- `impact`
+- `relatedDiagnostics`
+
+Nicht sicher automatisierbare Diagnosen werden bewusst als No-Op erklaert. Beispiele sind Syntax-Recovery, Inline-Script-Entfernung oder Component-Stubs, die Authoring-Kontext brauchen.
+
+## Diagnosecodes
+
+Wichtige Codes:
+
+| Code | Bedeutung |
+|------|-----------|
+| `rmt.syntax.invalid-json` | Das Dokument ist syntaktisch nicht parsebar |
+| `rmt.document.extension.fallback-used` | `.rmt.json` oder `.json` wird nur als Fallback genutzt |
+| `rmt.document.kind.missing` | `kind: "rmt_document"` fehlt |
+| `rmt.adapter.unknown` | Adapter-Referenz ist nicht definiert |
+| `rmt.ref.component.unresolved` | Component-Referenz ist nicht aufloesbar |
+| `rmt.ref.template.unresolved` | Template-Referenz ist nicht aufloesbar |
+| `rmt.ref.schedule.unresolved` | Schedule-Referenz ist nicht aufloesbar |
+| `rmt.ref.route.duplicate-path` | Route Path ist mehrfach definiert |
+| `rmt.fabric.lane.unknown` | Fabric/RMT Lane ist nicht bekannt |
+| `rmt.template.inline-script.refused` | Inline Script verletzt den Trusted-DOM-/Kernel-Boundary |
+
+## Quick Fixes
+
+Sichere Reparaturen kommen aus `xtend.rmt.code-action-provider.v1`.
+
+Der MVP unterstuetzt:
+
+- fehlende Schedules anlegen
+- fehlende Templates als `dom_descriptor` Stub anlegen
+- unbekannte Fabric Lanes auf `visible` setzen
+- unbekannte Hydration Policies auf `runtime_render` setzen
+- fehlende Route `documentTitle` ergaenzen
+- fehlende Schedule `endpointName` ergaenzen
+- `.rmt.json` per Command nach `.rmt` umbenennen
+
+## Regression Gate
+
+Die Tooling-Matrix liegt in:
+
+```bash
+node scripts/run_xtend_tests.js rmt-language-regression --json
+```
+
+Dieser Gate prueft valide, defekte, Legacy- und groessere RMT-Dokumente ueber Parser, Linter, CLI, LSP und Agent Report hinweg.
+
+## Editor Workflow
+
+Fuer IDEs siehe [RMT Language Server und Editor Setup](./rmt-language-server.md).
+
+Empfohlener Ablauf:
+
+1. Neues Dokument mit `rmt-app` Snippet erzeugen.
+2. In der IDE Diagnostics und Completion nutzen.
+3. Lokal mit `xt rmt lint app.rmt` pruefen.
+4. Fuer Agenten oder CI `xt rmt lint app.rmt --agent` nutzen.

package/docs/rmt-production-readiness.md

@@ -0,0 +1,63 @@
+# RMT Production Readiness
+
+- Contract: `xtend.epic13.rmt-production-readiness.v1`
+- Report: `xtend.epic13.rmt-production-readiness-report.v1`
+- Workpackage: `WP-E13-09`
+- Lokaler Gate: `node scripts/run_xtend_tests.js epic13-rmt-production-readiness --json`
+- Package Script: `npm run test:epic13-rmt-production-readiness`
+- Publish Boundary: `private-until-release-owner-acceptance`
+
+## Zweck
+
+`WP-E13-09` buendelt den RMT-first App-Pfad fuer RC1. Das Paket fuehrt die bereits vorhandenen RMT-Gates zu einem produktionsnahen Schnitt zusammen: Shell-first App Shell, native RMT-Routen, XTend-Komponenten ueber Adapter, Fabric/Lane-Ingestion, Lifecycle Telemetry, Diagnostics und XTendRMT Artifact Parity.
+
+Das Bundle fuegt keine neuen App-Features hinzu. Es macht sichtbar, dass XTend Apps vollstaendig in RMT templated werden koennen, waehrend der RMT Kernel framework-agnostisch bleibt.
+
+## Source Gates
+
+```bash
+npm run test:rmt-compatibility
+npm run test:rmt-first-class-app
+npm run test:rmt-first-demo-app
+npm run test:rmt-artifact-parity
+npm run test:rmt-component-fabric-ingestion
+npm run test:rmt-component-lifecycle-telemetry
+npm run test:epic13-visual-owner-artifact
+```
+
+Der lokale WP09-Gate prueft diese Source Gates als statisches RC1-Bundle. Er fuehrt keine Netzwerkzugriffe und keinen externen Browser voraus.
+
+## Readiness-Domains
+
+| Domain | Evidence |
+| --- | --- |
+| Shell-first App Shell | `tests/fixtures/rmt-first-class-xtend-app.rmt`, `xtendrmt/rmt-first-demo-app.rmt` |
+| Routing | `xtend.xrouter` Adapter und RMT `routes` Records |
+| Components | `xtend.component` Adapter und RMT `components` Records |
+| Fabric/Lane | `xtend.component.fabric-lane-ingestion.v2` |
+| Lifecycle Telemetry | `xtend.component.lifecycle-telemetry.v1` |
+| Diagnostics | `rmt.state-scheduler-diagnostics` und Fabric Snapshots |
+| Artifact Parity | `xtend.rmt.artifact-parity.v1` |
+| Kernel Boundary | `no-rmt-kernel-import-of-xtend-types` |
+
+## Boundary
+
+RMT besitzt App Records, Routes, Schedules, Templates und Metadata. XTend-Ausfuehrung bleibt in Host-Adaptern:
+
+- XTend-Komponenten werden nicht in den RMT Kernel importiert.
+- XRouter wird ueber `xtend.xrouter` angeschlossen.
+- Fabric/Lane- und Telemetry-Signale werden ingestiert, aber nicht als harte Kernel-Abhaengigkeit modelliert.
+- React-, Vue-, Vanilla- und Custom-Hosts koennen eigene Adapter verwenden.
+
+## Referenzen
+
+- [RMT-first XTend Apps](./rmt-first-xtend-apps.md)
+- [RMT-first Demo-App](./rmt-first-demo-app.md)
+- [XTendRMT App-DSL](./xtendrmt-app-dsl.md)
+- [XTendRMT Native Authoring](./xtendrmt-native-authoring.md)
+- [XTend-Fabric RMT Lane Mapping](./xtend-fabric-rmt-lane-mapping.md)
+- [Visual Owner Artifacts](./visual-owner-artifacts.md)
+
+## Handoff
+
+`WP-E13-09` ist abgeschlossen. `WP-E13-10` hat [Docs RMT Production Hardening](./docs-rmt-production-hardening.md) nachgezogen und die Docs-App RMT Parsedown Shell fuer PROD-nahe Erweiterungen gehaertet. `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.

package/docs/rmt-tooling-release-gates.md

@@ -0,0 +1,77 @@
+# RMT Tooling Release Gates
+
+- Status: produktiv vorbereitet ab `WP-E14-15`
+- Contract: `xtend.epic14.rmt-tooling.v1`
+- Gate Record Contract: `xtend.epic14.rmt-tooling-gate.record.v1`
+- Report Contract: `xtend.epic14.rmt-tooling-report.v1`
+- Lokaler Gate: `node scripts/run_xtend_tests.js epic14-rmt-tooling --json`
+
+## Zweck
+
+Die RMT Tooling Gates buendeln den nativen `.rmt` Authoring-Pfad fuer Pull Requests, Release-Kandidaten und AI-Agenten. Sie pruefen nicht die RMT Runtime, sondern die Sprachebene: Source Model, Parser, Semantic Graph, Linter, CLI, Completion, Navigation, LSP, Code Actions, Agent Report, Editor Packaging, Regression Fixtures und Dokumentation.
+
+## Befehle
+
+```bash
+npm run test:rmt-linter
+npm run test:rmt-language-server
+npm run test:pr:rmt
+npm run test:pr:rmt:report
+npm run test:rmt-tooling
+npm run test:rmt-tooling:report
+node scripts/run_xtend_tests.js epic14-rmt-tooling --json
+```
+
+`npm run test:pr:rmt` ist ein optionaler Zusatzgate fuer RMT-nahe Pull Requests. Der globale PR-Gate bleibt dadurch schlank, kann aber bei DSL-, Linter-, LSP- oder Agent-Report-Aenderungen gezielt erweitert werden.
+
+`npm run test:rmt-tooling` ist der Release-Bundle-Gate fuer Epic 14. Er laeuft ohne Netzwerk und nutzt ausschliesslich repo-lokale Fixtures, Docs und Tooling-Module.
+
+## Release-Bundle
+
+Das Release-Bundle umfasst:
+
+- `rmt-source-model`
+- `rmt-parser`
+- `rmt-semantic-graph`
+- `rmt-linter-rules`
+- `rmt-linter-cli`
+- `rmt-completions`
+- `rmt-navigation`
+- `rmt-language-server`
+- `rmt-code-actions`
+- `rmt-agent-report`
+- `rmt-editor-packaging`
+- `rmt-language-regression`
+- `rmt-tooling-docs`
+
+## Package Surface
+
+Die Package-Surface fuer RMT Tooling ist ueber `package.json` exportiert. Relevant fuer Tooling-Konsumenten sind insbesondere:
+
+- `xtend/rmt-language/source-model`
+- `xtend/rmt-language/parser`
+- `xtend/rmt-language/diagnostics`
+- `xtend/rmt-language/completions`
+- `xtend/rmt-language/code-actions`
+- `xtend/rmt-language-server`
+- `xtend/rmt-linter/cli`
+- `xtend/rmt-linter/reporter`
+- `xtend/rmt-language/snippets`
+
+Der Gate `epic14-rmt-tooling` prueft, dass diese Surface nicht unbemerkt driftet und dass `xtend.epic14RmtTooling` die aktiven Scripts, Suites und Handoff-Metadaten enthaelt.
+
+## CI-Handoff
+
+Die globale Full-Release-Linie bleibt:
+
+```bash
+npm run test:release:full:report
+```
+
+RMT Tooling ist zusaetzlich als eigener Release-Gate in `xtend.releaseGates` registriert:
+
+```bash
+npm run test:rmt-tooling
+```
+
+Damit koennen Release-Owner, CI-Systeme und AI-Agenten die RMT-Sprachwerkzeuge separat nachweisen, ohne den RMT Kernel mit XTend Runtime-Typen zu koppeln.

package/docs/rmt-vnext-authoring.md

@@ -0,0 +1,60 @@
+# RMT vNext Authoring Guide
+
+- Contract: `xtend.rmt.vnext-release-handoff.v1`
+- Syntax Contract: `xtend.rmt.vnext.grammar.v1`
+- Core Output: `xtend.rmt.core-format.vnext.v1`
+- Reference Demo: `xtendrmt/rmt-vnext-reference-demo.rmt`
+- Gate: `node scripts/run_xtend_tests.js rmt-vnext-release --json`
+
+RMT vNext ist die neue deklarative Authoring-Syntax fuer XTendRMT. Sie bleibt JSON-nah im Ergebnis, ist aber als menschenfreundliche DSL geschrieben und kompiliert deterministisch in das vNext Core Format.
+
+## Grundform
+
+```rmt
+template xtend.vnext.reference {
+  surface root {
+    lane critical weight 10 {
+      hydrate app-shell
+      hydrate hero-panel when route.visible == true
+    }
+  }
+}
+```
+
+Die wichtigsten Bausteine:
+
+| Syntax | Zweck |
+| --- | --- |
+| `template` | gruppiert eine orchestrierte App- oder Dokument-Shell |
+| `surface` | beschreibt Zielbereiche wie `root`, Dialoge, Overlays oder Panels |
+| `lane` | steuert Prioritaet, Scheduling und Backpressure |
+| `mount`, `hydrate`, `prewarm`, `dispose` | Lifecycle-Operationen |
+| `when` | deklarative Conditions ohne Funktionsaufrufe oder Eval |
+| `slot` | Composition innerhalb einer Operation |
+| `on ... -> action ...` | Event zu Action-Referenz |
+| `from endpoint/sse/worker` | Data-Source-Referenz |
+| `trust boundary` und `sanitize` | Security-Policy fuer unsichere Daten |
+| `stream` | inkrementelle Streaming-Operation |
+
+## Reference Demo
+
+Die vollstaendige Referenz liegt in `xtendrmt/rmt-vnext-reference-demo.rmt`. Sie deckt Templates, Surfaces, gewichtete Lanes, Conditions, Slots, Events, Endpoint/SSE/Worker Sources, Security Policies und Streaming ab.
+
+Der stabile Compiler-Output liegt in `xtendrmt/rmt-vnext-reference-demo.core.json`. Eine absichtliche Aenderung am Compiler oder an der Syntax muss beide Dateien und die Release-Gates bewusst aktualisieren.
+
+## Lokal pruefen
+
+```bash
+node scripts/run_xtend_tests.js rmt-vnext-release --json
+node scripts/run_xtend_tests.js rmt-vnext-parser rmt-vnext-compiler rmt-vnext-regression --json
+```
+
+Der Release-Gate prueft Docs, Reference Demo, Core-Output, Release-Matrix, Handoff und Referenzpfade. Fuer schnelle Authoring-Checks reichen Parser, Compiler und Regression-Gate.
+
+## Grenzen
+
+- RMT vNext fuehrt keine Host-Runtime im Kernel aus.
+- Conditions sind deklarativ und erlauben keine Funktionsaufrufe.
+- Imports sind statisch und bleiben package-root-gebunden.
+- Legacy JSON bleibt lesbar, Migration bleibt opt-in.
+- Produktive Runtime-Adapter fuer vNext Core sind Folgearbeit, nicht Teil dieses Syntax-Epics.

package/docs/rmt-vnext-cross-surface-events.md

@@ -0,0 +1,68 @@
+# RMT vNext Cross Surface Events
+
+Cross Surface Events verbinden Bereiche der App Shell, ohne einen impliziten
+globalen Event Bus einzufuehren. Jede Richtung, jedes Ziel und jedes Payload-
+Schema wird explizit beschrieben und durch Governance-Diagnostics abgesichert.
+Boundary: no implicit global Event Bus.
+
+## Contract
+
+```js
+schema: "xtend.rmt.vnext-cross-surface-event-protocol.v1"
+reportSchema: "xtend.rmt.vnext-cross-surface-event-report.v1"
+governanceSchema: "xtend.rmt.vnext-event-governance-policy.v1"
+```
+
+Ein Event muss definieren:
+
+- `event` als versionierter Name, zum Beispiel `checkout.cart.updated.v1`.
+- `owner` als Team fuer Event- und Versionspflege.
+- `payload.schema` als stabile Payload-ID.
+- `direction` als `outbound` oder `inbound`.
+- `scope` als Lane-, Surface- oder Shell-Target-Bindung.
+- `delivery` mit TTL, Korrelation und Idempotenz, wenn erforderlich.
+
+## Direction
+
+`emits` beschreibt ausgehende Events einer Surface. `consumes` beschreibt
+eingehende Events. Die Shell darf diese Bindings weiterleiten, aber nicht frei
+interpretieren. Dadurch bleibt sichtbar, ob eine User-Aktion mehrere Bereiche
+der Shell tangiert.
+
+## Scope
+
+Events sind auf Lanes und Shell Targets begrenzt:
+
+```rmt
+emits checkout.cart.updated.v1 {
+  owner: "checkout-platform"
+  payload: "xtend.schemas.cartUpdated.v1"
+  direction: outbound
+  scope: lane critical -> shell.slot:sidebar.cart
+}
+```
+
+Ein Event ohne klaren Scope wird im E16-Gate blockiert oder diagnostiziert. Das
+verhindert denselben impliziten Kopplungsdruck, der Micro-Frontend-Systeme ohne
+Disziplin schwer wartbar macht.
+
+## Governance
+
+Das Governance-Modell prueft:
+
+- Event Owner und Payload Owner.
+- Cross-Team-Events.
+- Delivery Mode, TTL, `correlationId` und `idempotencyKey`.
+- Sensitivity und Review-Pflichten.
+- Degradation-Verhalten fuer Events einer blockierten oder degradierten Surface.
+
+## Gates
+
+```bash
+node scripts/run_xtend_tests.js rmt-vnext-cross-surface-events --json
+node scripts/run_xtend_tests.js rmt-vnext-event-governance --json
+node scripts/run_xtend_tests.js rmt-vnext-enterprise-release --json
+```
+
+Die Enterprise Demo deckt `checkout.cart.updated.v1` und
+`user.session.changed.v1` als typisierte, gerichtete Cross-Surface-Events ab.

package/docs/rmt-vnext-enterprise-mfe-handoff.md

@@ -0,0 +1,70 @@
+# RMT vNext Enterprise MFE Handoff
+
+Epic 16 schliesst RMT vNext fuer Enterprise-MFE-Authoring mit Remote Surfaces,
+Surface Discoverability, Cross Surface Events, Security Policies, Versionierung
+und Graceful Degradation ab.
+
+## Contract
+
+```js
+schema: "xtend.rmt.vnext-enterprise-release-handoff.v1"
+reportSchema: "xtend.rmt.vnext-enterprise-release-handoff-report.v1"
+gateMatrixSchema: "xtend.rmt.vnext-enterprise-release-gate-matrix.v1"
+targetReadiness: "rmt-vnext-enterprise-mfe-ready"
+```
+
+## Release Assets
+
+- Authoring Guide: `docs/rmt-vnext-remote-surfaces.md`
+- Registry Reference: `docs/rmt-vnext-surface-registry-enterprise.md`
+- Event Protocol Reference: `docs/rmt-vnext-cross-surface-events.md`
+- Operational Handoff: `docs/rmt-vnext-enterprise-mfe-handoff.md`
+- Demo Source: `xtendrmt/rmt-vnext-enterprise-mfe-demo.rmt`
+- Core Output: `xtendrmt/rmt-vnext-enterprise-mfe-demo.core.json`
+- Browser Smoke: `tests/browser/fixtures/rmt-vnext-enterprise-mfe-smoke.html`
+- Fixture Matrix: `tests/rmt-language/fixtures/vnext-enterprise-mfe-fixture-matrix.json`
+
+## Release Gate Matrix
+
+```bash
+node scripts/run_xtend_tests.js rmt-vnext-remote-manifest --json
+node scripts/run_xtend_tests.js rmt-vnext-enterprise-registry --json
+node scripts/run_xtend_tests.js rmt-vnext-degradation --json
+node scripts/run_xtend_tests.js rmt-vnext-remote-security --json
+node scripts/run_xtend_tests.js rmt-vnext-cross-surface-events --json
+node scripts/run_xtend_tests.js rmt-vnext-event-governance --json
+node scripts/run_xtend_tests.js rmt-vnext-remote-compiler --json
+node scripts/run_xtend_tests.js rmt-vnext-remote-tooling --json
+node scripts/run_xtend_tests.js rmt-vnext-remote-compatibility --json
+node scripts/run_xtend_tests.js rmt-vnext-enterprise-fixtures --json
+node scripts/run_xtend_tests.js rmt-vnext-enterprise-release --json
+node scripts/run_xtend_tests.js references --json
+node scripts/run_xtend_tests.js browser --json
+```
+
+## Operational Notes
+
+- Remote Surfaces bleiben Contract-Artefakte. Ein produktiver Runtime Loader ist
+  Folgearbeit im Host- oder Runtime-Adapter-Pfad.
+- `surface.registry` macht Ownership, aktive Versionen und Shell Bindings
+  sichtbar, ersetzt aber keinen SurfaceManager.
+- Cross Surface Events benoetigen typisierte Payloads, klare Owner und explizite
+  Richtung.
+- Graceful Degradation ist verpflichtend. Systeme ohne Fallback- oder
+  Blockierungsmodell gelten nicht als Enterprise-ready.
+- Migration aus Legacy-Surface-Fakten bleibt `report-only` per Default; Preview
+  ist opt-in und wird ueber `xtend.rmt.vnext-remote-surface-migration.v1`
+  beschrieben.
+
+## Accepted Residuals
+
+- Kein produktiver Remote Runtime Loader im RMT-Kernel.
+- Keine echte Netzwerk-Integration in lokalen Language-Layer-Gates.
+- Keine implizite globale Event-Bus-Semantik.
+- Kein Public-Runtime-Claim fuer Hosts, die den Contract noch nicht umsetzen.
+
+Der lokale Abschluss-Gate ist:
+
+```bash
+node scripts/run_xtend_tests.js rmt-vnext-enterprise-release --json
+```

package/docs/rmt-vnext-migration-notes.md

@@ -0,0 +1,62 @@
+# RMT vNext Migration Notes
+
+- Contract: `xtend.rmt.vnext-release-handoff.v1`
+- Compatibility Contract: `xtend.rmt.vnext-compatibility-matrix.v1`
+- Migration Report: `xtend.rmt.vnext-migration-report.v1`
+- Gate: `node scripts/run_xtend_tests.js rmt-vnext-compatibility --json`
+
+RMT vNext ist additiv. Bestehende JSON-nahe `.rmt` und `.rmt.json` Dokumente bleiben parse- und normalisierbar. Neue Authoring-Dateien sollten die vNext-Syntax verwenden und nach `xtend.rmt.core-format.vnext.v1` kompilieren.
+
+## Migrationsmodus
+
+Der Standardmodus ist `report-only`. Er erzeugt einen Migrationsreport, prueft den Legacy-Roundtrip und zeigt Boundary-Warnungen, schreibt aber keine Datei automatisch um.
+
+`preview` ist opt-in und erzeugt zusaetzlich einen vNext Authoring-Draft.
+
+```js
+const {
+  createMigrationReport
+} = require('./tools/rmt-language/vnext-compatibility');
+
+const report = createMigrationReport({
+  text: source,
+  filePath: 'app.rmt'
+}, {
+  migrationMode: 'preview'
+});
+```
+
+## Kompatible Warnungen
+
+Diese Warnungen blockieren Migration nicht:
+
+- `rmt.document.extension.fallback-used`
+- `rmt.vnext.migration.opt_in_required`
+- `rmt.vnext.migration.lossy_domain`
+
+`lossy_domain` bedeutet: Die Legacy-Domaene ist fachlich kompatibel, aber nicht automatisch source-stabil in vNext Authoring uebersetzbar. Beispiele sind Adapter-Contracts, komplexe Templates oder Router-Metadaten.
+
+## Harte Fehler
+
+Diese Faelle blockieren den betroffenen Eintrag:
+
+- Legacy JSON kann nicht geparst werden.
+- Legacy JSON kann nicht normalisiert werden.
+- vNext Source kompiliert nicht.
+- Der semantische Legacy-Roundtrip ist nicht stabil.
+
+## Empfohlene Migration
+
+1. `rmt-vnext-compatibility` gegen bestehende Fixtures ausfuehren.
+2. Reports mit `migrationMode: "report-only"` lesen und Boundary-Warnungen triagieren.
+3. Fuer einzelne Dateien `preview` erzeugen.
+4. Den Preview-Draft manuell pruefen und auf vNext-Authoring-Konventionen bringen.
+5. Parser, Compiler, Regression und Release-Gate ausfuehren.
+
+```bash
+node scripts/run_xtend_tests.js rmt-vnext-compatibility rmt-vnext-regression rmt-vnext-release --json
+```
+
+## Handoff
+
+Dieses Epic liefert Syntax, Compiler, Tooling, Compatibility, Regression und Release-Handoff. Produktive Runtime-Adapter fuer vNext Core und ein Formatter/Writer gehoeren in Folge-Epics.

package/docs/rmt-vnext-release-handoff.md

@@ -0,0 +1,69 @@
+# RMT vNext Release Handoff
+
+- Contract: `xtend.rmt.vnext-release-handoff.v1`
+- Report Contract: `xtend.rmt.vnext-release-handoff-report.v1`
+- Gate Matrix: `xtend.rmt.vnext-release-gate-matrix.v1`
+- Workpackage: `WP-E15-18`
+- Gate: `node scripts/run_xtend_tests.js rmt-vnext-release --json`
+
+Epic 15 ist mit dem vNext Release Handoff source-ready. Die neue Syntax ist dokumentiert, die Referenzdemo kompiliert byte-stabil in Core JSON, und die lokale Release-Matrix buendelt Parser, Compiler, Semantikmodule, Tooling, Migration, Regression, Browser-Smoke und Referenzpfade.
+
+## Release Gates
+
+```bash
+npm run test:rmt-vnext-parser
+npm run test:rmt-vnext-compiler
+npm run test:rmt-vnext-lifecycle
+npm run test:rmt-vnext-scheduler
+npm run test:rmt-vnext-surfaces
+npm run test:rmt-vnext-conditions
+npm run test:rmt-vnext-composition
+npm run test:rmt-vnext-imports
+npm run test:rmt-vnext-events
+npm run test:rmt-vnext-security
+npm run test:rmt-vnext-streaming
+npm run test:rmt-vnext-tooling
+npm run test:rmt-vnext-compatibility
+npm run test:rmt-vnext-regression
+npm run test:browser
+npm run test:references
+```
+
+Der Self-Gate fuer diesen Abschluss ist:
+
+```bash
+npm run test:rmt-vnext-release
+```
+
+## Reference Demo
+
+- Source: `xtendrmt/rmt-vnext-reference-demo.rmt`
+- Core Output: `xtendrmt/rmt-vnext-reference-demo.core.json`
+- Browser Probe: `tests/browser/fixtures/rmt-vnext-reference-smoke.html`
+
+Die Demo deckt die volle vNext-MVP-Flaeche ab:
+
+- `template`
+- `surface`
+- `lane ... weight`
+- Lifecycle-Operationen
+- `when` Conditions
+- `slot` Composition
+- `on ... -> action ...`
+- `from endpoint`, `from sse`, `from worker`
+- `trust boundary`
+- `sanitize html`
+- `stream`
+
+## Accepted Residuals
+
+| Residual | Status | Folgepfad |
+| --- | --- | --- |
+| produktive Runtime-Adapter fuer vNext Core | planned-follow-up | `rmt-vnext-runtime-adapters` |
+| Formatter und Writer API | planned-follow-up | `rmt-vnext-formatter-writer` |
+| Workspace Project Index, Rename und References | planned-follow-up | `rmt-vnext-project-index` |
+| Editor Marketplace Distribution | planned-follow-up | `rmt-vnext-editor-distribution` |
+
+## Abschlussentscheidung
+
+RMT vNext ist als Syntax-, Compiler-, Tooling-, Compatibility- und Regression-Schicht akzeptiert. Der Handoff ist kein oeffentlicher Runtime-Release; er markiert den Zustand `rmt-vnext-release-ready` und uebergibt Runtime-Adapter, Formatter und Workspace-Index als klar getrennte Folgearbeiten.