@ccslabs/xtend 0.1.0-rc.1 → 0.1.2

package/docs/de/rmt-vnext-primitive-grammar-design.md

@@ -0,0 +1,289 @@
+# RMT vNext Primitive Grammar Design
+
+- Contract: `xtend.rmt.vnext-primitive-grammar-design.v1`
+- Workpackage: `RMT-VNEXT-PRIM-01`
+- Status: `completed`
+- Parent backlog: [RMT vNext Primitive Compiler Backlog](./rmt-vnext-primitives-compiler-backlog.md)
+- Design fixture: `tests/rmt-language/fixtures/vnext-primitives-grammar-design.rmt`
+
+## Ziel
+
+Dieser Slice definiert die vNext-Syntax, mit der App-Platform-Primitives direkt
+in RMT authoriert werden sollen. Er ist bewusst ein Grammar-Design-Contract.
+Parser-/AST-Implementierung ist in `RMT-VNEXT-PRIM-02` abgeschlossen; die erste
+Semantic-Graph-Schicht ist in `RMT-VNEXT-PRIM-03` gestartet. Compiler-Lowering
+folgt in `RMT-VNEXT-PRIM-04`.
+
+Die Syntax muss App-Autoren aus Legacy-/JSON-Authoring herausfuehren. Ein
+normaler App-Shell-Entwickler soll State, Selectors, Actions, Events,
+DataSources, Surfaces, Overlays, Portals und Resources in einer lesbaren RMT
+vNext-Datei deklarieren koennen.
+
+## Design-Prinzipien
+
+- **vNext first:** Die menschenfreundliche DSL ist die primaere Authoring-
+  Oberflaeche. JSON bleibt Compiler-Output oder Migrationsinput.
+- **Kernel-neutral:** Syntax kann XTend-Komponenten referenzieren, aber der
+  RMT-Kernel importiert keine XTend-, Fabric- oder Browser-Module.
+- **App-Graph vor Runtime:** Referenzen, Ownership, Payload Contracts und
+  Trust Boundaries muessen aus dem Source Graph pruefbar sein.
+- **Source-map-faehig:** Jede Primitive-Deklaration braucht einen stabilen
+  Source Range und eine Primitive ID.
+- **Composable:** App Shell, UI-Templates, State, Events und Resources duerfen
+  getrennt deklarierbar sein, muessen aber zu einem App Graph verbunden werden.
+- **Legacy im Hintergrund:** Klassische Core-/Scaffold-Artefakte duerfen
+  weiterhin Targets sein, aber Entwickler sollen sie nicht bearbeiten muessen.
+
+## Top-Level-Grammatik
+
+Eine vNext-Datei kann weiterhin `import`, `template`, `surface` und `remote`
+nutzen. Neu kommen primitive Deklarationen hinzu. Sie sind innerhalb eines
+`template`-Blocks bevorzugt, duerfen fuer wiederverwendbare Bibliotheken aber
+auch top-level authoriert werden.
+
+```rmt
+template media.manager {
+  state media.records type MediaRecord[] initial []
+
+  selector media.filtered from state media.records {
+    where record.kind == state.media.filters.kind || state.media.filters.kind == "all"
+    sort by record.name asc
+  }
+
+  datasource media.index from endpoint "/api/media?pageSize=200" {
+    method GET
+    contract MediaIndex
+    result records
+  }
+
+  action media.select {
+    input mediaId string
+    reduce state.media.selection.activeId = input.mediaId
+    emit media.selected with mediaId input.mediaId
+  }
+
+  portal surface.root root "#media-manager-root" layer surface
+  overlay feedback.toast kind toast portal surface.root
+  resource player.stream kind stream owner surface.player source state.media.selection.activeId
+
+  surface media.explorer kind window component x-surface-window {
+    source selector media.filtered
+    key record.id
+    portal surface.root
+
+    lane visible weight 80 {
+      hydrate explorer-list from selector media.filtered
+    }
+
+    on click "[data-media-id]" -> action media.select {
+      payload mediaId from target.dataset.mediaId
+    }
+  }
+}
+```
+
+## Primitive-Formen
+
+### State
+
+```rmt
+state media.filters type object preserve {
+  initial {
+    query ""
+    kind "all"
+    collection "all"
+  }
+}
+```
+
+Lowering-Ziel:
+
+- `core.state[]`
+- Source-map entry mit `primitiveType: "state"`
+- optionaler XState-Bridge-Hint fuer Host-Adapter
+
+### Selector
+
+```rmt
+selector media.filtered from state media.records {
+  where record.kind == state.media.filters.kind || state.media.filters.kind == "all"
+  where contains(record.name, state.media.filters.query)
+  sort by record.name asc
+  output MediaRecord[]
+}
+```
+
+Einschraenkung fuer PRIM-01: Funktionen wie `contains()` sind als deklarative
+Selector-Operatoren erlaubt, aber nicht als beliebige JS-Calls. PRIM-02 muss
+sie als eigene AST-Nodes modellieren.
+
+Lowering-Ziel:
+
+- `core.selectors[]`
+- Referenzen auf `core.state[]`
+- Diagnose fuer unbekannte State- oder Record-Pfade
+
+### DataSource
+
+```rmt
+datasource media.index from endpoint "/api/media?pageSize=200" {
+  method GET
+  contract MediaIndex
+  result records
+  fallback fixture media.fixture
+}
+```
+
+Lowering-Ziel:
+
+- `core.dataSources[]`
+- App-Platform-Report-Domain `dataSources`
+- optionaler SSR-/Fixture-Fallback
+
+### Action und Effect
+
+```rmt
+action media.reindex {
+  status state.actionStatus.reindex
+  effect fetch datasource media.reindex
+  on success -> reduce state.media.records = result.records
+  on success -> emit media.index.loaded with count result.records.length
+  on error -> overlay feedback.toast message error.message tone "danger"
+}
+```
+
+Lowering-Ziel:
+
+- `core.actions[]`
+- `core.effects[]` oder action-scoped `effects`
+- Event-/Feedback-Result-Routing
+- Resource ownership fuer async handles
+
+### Event Binding
+
+```rmt
+on click "[data-command='scan']" -> action media.reindex {
+  preventDefault true
+  payload source from target.dataset.command
+}
+
+on xplayer-play target player.surface -> action media.playback.started {
+  payload mediaId from detail.mediaId
+  payload surfaceId from surface.id
+}
+```
+
+Lowering-Ziel:
+
+- `core.events[]`
+- Payload Contract
+- DOM/custom event routing metadata
+- Source pointer fuer jedes Payload Mapping
+
+### Surface
+
+```rmt
+surface media.player kind window component x-surface-window {
+  repeat from selector player.instances
+  key instance.surfaceId
+  portal surface.root
+  bounds x 920 y 96 width 760 height 500
+  preserve on minimize
+  destroy releases resource player.stream
+
+  lane visible weight 90 {
+    hydrate player-view from selector media.activeRecord
+  }
+}
+```
+
+Lowering-Ziel:
+
+- `core.surfaces[]`
+- `core.lanes[]`
+- `core.operations[]`
+- Surface Graph Runtime records
+- keyed repeater diagnostics
+
+### Portal und Overlay
+
+```rmt
+portal overlay.root root "body" layer overlay z 1000 {
+  focus policy restore
+  pointer policy passthrough
+  scroll policy lock-when-modal
+}
+
+overlay media.lightbox kind lightbox portal overlay.root {
+  escape close topmost
+  focus trap
+  resource lightbox.import
+}
+```
+
+Lowering-Ziel:
+
+- `core.portals[]`
+- `core.overlays[]`
+- portal reference diagnostics
+- overlay stack policy
+
+### Resource
+
+```rmt
+resource lightbox.import kind lazy-import owner overlay.media.lightbox {
+  import "@ccslabs/xtend/components/xlightbox"
+}
+
+resource preview.objectUrl kind object-url owner surface.media.player {
+  source selector media.activeRecord
+  dispose on surface.destroy
+}
+```
+
+Lowering-Ziel:
+
+- `core.resources[]`
+- owner-scoped lifecycle records
+- teardown diagnostics fuer ownerless resources
+
+## AST-Node-Namen
+
+PRIM-02 soll mindestens diese Node-Typen erzeugen:
+
+| Syntax | AST Node |
+|--------|----------|
+| `state` | `RmtStateDeclaration` |
+| `selector` | `RmtSelectorDeclaration` |
+| `datasource` | `RmtDataSourceDeclaration` |
+| `action` | `RmtActionDeclaration` |
+| `effect` | `RmtEffectStatement` |
+| `on ... -> action ...` | `RmtEventBinding` mit Payload-Block |
+| `surface ... kind ... component ...` | `RmtSurfaceDeclaration` mit Primitive-Metadata |
+| `portal` | `RmtPortalDeclaration` |
+| `overlay` | `RmtOverlayDeclaration` |
+| `resource` | `RmtResourceDeclaration` |
+| `template` primitive block | `RmtTemplateDeclaration.body[]` |
+
+## Diagnostik-Mindestumfang
+
+Der Grammar-Slice definiert folgende Fehlerklassen fuer PRIM-02/03:
+
+| Code | Bedeutung |
+|------|-----------|
+| `rmt.vnext.primitive.unknown-reference` | Primitive referenziert unbekannten State, Selector, Action, Portal, Resource oder Surface. |
+| `rmt.vnext.primitive.owner-missing` | Resource oder Overlay besitzt keinen stabilen Owner. |
+| `rmt.vnext.primitive.unkeyed-repeat` | Surface oder Template wiederholt Records ohne `key`. |
+| `rmt.vnext.primitive.payload-contract-missing` | Event bindet eine Action ohne Payload Contract oder Mapping. |
+| `rmt.vnext.primitive.unsafe-html` | Template nutzt HTML ohne Trusted-DOM-Boundary. |
+| `rmt.vnext.primitive.kernel-boundary` | Primitive verlangt Kernel-Import aus XTend, Fabric oder Browser Runtime. |
+
+## Akzeptanz fuer PRIM-01
+
+- Dieses Dokument definiert eine zusammenhaengende vNext-Syntax fuer alle P0-
+  Primitive-Familien.
+- Die Fixture `tests/rmt-language/fixtures/vnext-primitives-grammar-design.rmt`
+  zeigt denselben Syntaxumfang in einer kompakten App-Shell.
+- Das Backlog markiert `RMT-VNEXT-PRIM-01` als `in_progress`.
+- PRIM-02 kann direkt mit Parser-/AST-Arbeit starten, ohne die Syntaxfrage neu
+  zu klaeren.

package/docs/de/rmt-vnext-primitive-lowering.md

@@ -0,0 +1,108 @@
+# RMT vNext Primitive Lowering
+
+- Contract: `xtend.rmt.vnext.primitive-lowering.v1`
+- Workpackage: `RMT-VNEXT-PRIM-04`
+- Status: `completed`
+- Quelle: Media-Manager-Downstream-Transfer, `2026-05-19`
+
+## Ziel
+
+`RMT-VNEXT-PRIM-04` senkt validierte vNext-Primitives aus dem PRIM-03 Semantic
+Graph in deterministische Core-, App-Platform- und Kernel-Records ab. App-
+Autoren bleiben dabei in RMT vNext; JSON bleibt Compiler-Output und nicht der
+Authoring-Pfad.
+
+Die Lowering-Stufe ist Teil des bestehenden vNext-Compilers:
+
+```js
+const {
+  compileRmtVNextSource
+} = require('./tools/rmt-language/vnext-compiler');
+
+const result = compileRmtVNextSource({ text, filePath });
+```
+
+Bei Primitive-Quellen baut der Compiler zuerst
+`buildRmtVNextPrimitiveSemanticGraph(...)`. Error-Diagnostics aus dem Graph
+stoppen das Lowering mit `status: "semantic_error"` und ohne Core-Document.
+
+## Core-Domains
+
+Der vNext-Core erhaelt zusaetzliche Primitive-Domains:
+
+- `states`
+- `selectors`
+- `actions`
+- `effects`
+- `portals`
+- `overlays`
+- `resources`
+
+Vorhandene Domains wie `surfaces`, `lanes`, `operations`, `events` und
+`dataSources` werden fuer Primitive angereichert, statt einen zweiten Runtime-
+Pfad zu erzeugen.
+
+## App-Platform Artifact
+
+Wenn Primitive vorhanden sind, enthaelt das Core-Document `appPlatform`:
+
+```json
+{
+  "schema": "xtend.rmt.vnext.app-platform-records.v1",
+  "sourceSyntax": "rmt-vnext",
+  "surfaces": [],
+  "events": [],
+  "resources": []
+}
+```
+
+Dieses Artefakt ist fuer Host-/Scaffold-Adapter gedacht. Host-spezifische
+Imports, etwa Lazy Component Imports, bleiben dort sichtbar und tragen
+`kernelVisible: false`.
+
+## Kernel Records
+
+Das Core-Document enthaelt bei Primitive-Quellen ausserdem `kernelRecords`:
+
+```json
+{
+  "schema": "xtend.rmt.vnext.kernel-records.v1",
+  "boundary": "no-rmt-kernel-import-of-host-runtime-types",
+  "schedules": [],
+  "fibers": [],
+  "lifecycleRecords": []
+}
+```
+
+Der Kernel-Record-Slice enthaelt Lanes, Fibers, Lifecycle-, State-, Selector-,
+Action-, DataSource- und Resource-Fakten ohne Host-Runtime-Imports. Dadurch ist
+PRIM-05 vorbereitet: Fabric kann Lane/Fiber-Evidence aus Compiler-Output
+ableiten, ohne dass der Kernel Fabric oder XTend importieren muss.
+
+## Evidence
+
+Die Compiler-Suite prueft:
+
+- positive Primitive-Fixture kompiliert zu State-, Selector-, DataSource-,
+  Action-, Effect-, Portal-, Overlay-, Resource-, Surface- und Event-Records;
+- App-Platform-Artefakt und Kernel-Records werden erzeugt;
+- keyed Surface-Repeater und Event-Payload-Contracts bleiben erhalten;
+- Host-Imports bleiben ausserhalb der Kernel-Sichtbarkeit;
+- negative PRIM-03-Fixture stoppt vor dem Lowering mit Semantic-Diagnostics;
+- Core JSON bleibt byte-stabil.
+
+Gezielte lokale Gates:
+
+```bash
+node --check tools/rmt-language/vnext-compiler.js
+node --check tests/rmt-language/rmt_vnext_compiler_suite.js
+node -e "const suite=require('./tests/rmt-language/rmt_vnext_compiler_suite'); const result=suite.runRmtVNextCompilerSuite({rootDir:process.cwd()}); process.exit(result.ok ? 0 : 1);"
+```
+
+## PRIM-06 Anschluss
+
+`RMT-VNEXT-PRIM-06` setzt auf `kernelRecords.schedules` und
+`kernelRecords.fibers` auf. Die erste Source-to-Sea-Scheibe erzeugt daraus
+Evidence, die vNext-Source-Maps, Kernel-Schedules, ableitbare Fabric-Fibers,
+UI-Marker und eine Browser-Smoke-Fixture unter derselben Primitive-ID
+korreliert.

package/docs/de/rmt-vnext-primitive-migration.md

@@ -0,0 +1,119 @@
+# RMT vNext Primitive Migration
+
+- Contract: `xtend.rmt.vnext.primitive-migration-preview.v1`
+- Workpackage: `RMT-VNEXT-PRIM-08`
+- Status: `in_progress`
+- Source fixture: `tests/fixtures/rmt-app-platform-tooling.rmt`
+- Local gate: `node scripts/run_xtend_tests.js rmt-vnext-compatibility --json`
+
+## Ziel
+
+`RMT-VNEXT-PRIM-08` schiebt Legacy- und App-Platform-JSON-Authoring in den
+Hintergrund. Bestehende App-Platform-Primitive-Records bleiben als
+Compiler-Target und Compatibility-Evidence erhalten, aber die primaere
+Authoring-Flaeche ist RMT vNext.
+
+Der Migrationspfad erzeugt deshalb keinen neuen Legacy-Arbeitsmodus. Er erzeugt
+einen vNext-Preview-Draft aus vorhandenen App-Platform-Records und kompiliert
+diesen Draft direkt wieder durch den vNext-Compiler. Erst wenn dieser Draft
+State, DataSources, Actions, Events, Portals, Overlays, Resources, Surfaces,
+Lanes und Kernel-Records absenken kann, gilt die Migration als kompatibel.
+
+## Preview- und Apply-Plan-Vertrag
+
+Die API `createAppPlatformPrimitiveMigrationPreview(...)` erkennt
+App-Platform-JSON-Dokumente mit Primitive-Domains wie `state`, `dataSources`,
+`actions`, `events`, `portals`, `overlays`, `resources` und `surfaces`.
+
+Der Preview-Report enthaelt:
+
+- `schema: "xtend.rmt.vnext.primitive-migration-preview.v1"`
+- `workpackage: "RMT-VNEXT-PRIM-08"`
+- `languageMode: "legacy-app-platform-json"`
+- `vNextAuthoring.role: "default"`
+- `legacyAuthoring.role: "compiler-target"`
+- `legacyAuthoring.backgrounded: true`
+- `authoringDraft` mit vNext-Primitive-Syntax
+- `authoringDraftCompileStatus: "compiled"`
+- `projection.appPlatform` und `projection.kernelRecords`
+- `domainMapping` fuer die erkannten Primitive-Familien
+
+Report-only-Mode schreibt keine Quelle um. Er meldet stattdessen
+`rmt.vnext.migration.opt_in_required` und
+`rmt.vnext.primitive_migration.preview_available`. Preview-Mode ist bewusst
+opt-in, damit vorhandene downstream Fixtures nicht still migriert werden.
+
+Die API `createAppPlatformPrimitiveMigrationApplyPlan(...)` baut darauf auf
+und erzeugt einen deterministischen Apply-Plan:
+
+- `schema: "xtend.rmt.vnext.primitive-migration-apply-plan.v1"`
+- `status: "apply-plan-ready"`, wenn der vNext-Draft kompiliert und eine
+  Projektion erzeugt werden kann
+- `status: "blocked"`, wenn JSON-Parsing oder vNext-Kompilation fehlschlagen
+- `targetPath` als Zielpfad-Hinweis, standardmaessig
+  `<quelle>.vnext.rmt`
+- `automaticWrite: false`
+- `writePolicy: "manual-apply-only"`
+
+Der Apply-Plan fuehrt keinen Datei-Write aus. Er ist ein pruefbarer Handoff
+fuer Agenten, CLIs oder Editoren, die den vNext-Draft nach Review in einen
+neuen Authoring-Pfad uebernehmen wollen. Legacy/App-Platform-JSON bleibt dabei
+Mirror und Compiler-Target, nicht die Benutzeroberflaeche.
+
+## Authoring-Draft
+
+Das App-Platform-Fixture wird in eine vNext-Shell dieser Form ueberfuehrt:
+
+```rmt
+template epic18.app-platform-tooling.fixture {
+  state items type collection initial []
+
+  datasource items from fixture records.generic-items {
+    contract "domain.record.generic-item.v1[]"
+  }
+
+  action load-items {
+    effect fetch datasource items
+    reduce state.items = result.records
+  }
+
+  portal app root "#app-root" layer surface
+
+  surface workspace kind window component workspace {
+    repeat from datasource items
+    portal app
+
+    lane visible weight 70 {
+      hydrate workspace from datasource items
+    }
+
+    on open-detail target ref.row -> action open-detail {
+      payload id from detail.id
+    }
+  }
+}
+```
+
+Die Preview normalisiert bekannte App-Platform-Prefixes fuer vNext-Authoring:
+`state.items` wird zu `state items`, `datasource.items` zu
+`datasource items`, `surface.workspace` zu `surface workspace` und
+`action.open-detail` zu `action open-detail`. Runtime- und Kernel-Records
+bleiben ueber die Compiler-Projektion korrelierbar.
+
+## Gate-Erwartung
+
+Das Compatibility-Gate prueft fuer PRIM-08:
+
+- App-Platform-Primitive-JSON wird als `legacy-app-platform-json` erkannt.
+- Report-only-Mode verlangt explizites Preview-Opt-in.
+- Preview-Mode erzeugt einen vNext-Draft und kompiliert ihn.
+- Apply-Plan-Mode erzeugt denselben Draft, einen Zielpfad-Hinweis und eine
+  blockierende Compile-/Parse-Pruefung, ohne Dateien zu schreiben.
+- Die Projektion enthaelt App-Platform- und Kernel-Records.
+- Legacy wird als `compiler-target` markiert, nicht als Authoring-Pfad.
+- Die Compatibility-Matrix akzeptiert App-Platform-Preview und native vNext-
+  Quelle gemeinsam.
+
+Damit wird die Upgrade-Regel testbar: Legacy ist weiterhin beweisbar
+kompatibel, aber die Developer Experience fuer neue App-Shell-Arbeit liegt in
+vNext.

package/docs/de/rmt-vnext-primitive-parser-ast.md

@@ -0,0 +1,76 @@
+# RMT vNext Primitive Parser AST
+
+- Contract: `xtend.rmt.vnext-primitive-parser-ast.v1`
+- Workpackage: `RMT-VNEXT-PRIM-02`
+- Status: `completed`
+- Parent backlog: [RMT vNext Primitive Compiler Backlog](./rmt-vnext-primitives-compiler-backlog.md)
+- Grammar contract: [RMT vNext Primitive Grammar Design](./rmt-vnext-primitive-grammar-design.md)
+- Parser module: `tools/rmt-language/vnext-parser.js`
+- Parser suite: `tests/rmt-language/rmt_vnext_parser_suite.js`
+- Fixture: `tests/rmt-language/fixtures/vnext-primitives-grammar-design.rmt`
+
+## Ziel
+
+PRIM-02 erweitert den bestehenden vNext-Parser so, dass die in PRIM-01
+definierte Primitive-Syntax als echte AST-Nodes sichtbar wird. Der Slice bleibt
+abwaertskompatibel mit der bisherigen `template/surface/lane`-Syntax.
+
+Compiler-Lowering und Kernel-Ingestion bleiben Folgearbeit in
+`RMT-VNEXT-PRIM-04`. Die erste App-Graph-Semantik ist in
+`RMT-VNEXT-PRIM-03` gestartet.
+
+## Implementierter Parser-Umfang
+
+Der Parser akzeptiert jetzt die Design-Fixture
+`vnext-primitives-grammar-design.rmt` ohne Syntaxdiagnosen und erzeugt
+initiale AST-Nodes fuer:
+
+| Primitive | AST Nodes |
+|-----------|-----------|
+| State | `RmtStateDeclaration`, `RmtInitialBlock`, `RmtInitialValueEntry`, `RmtPrimitiveValue`, `RmtTypeReference` |
+| Selector | `RmtSelectorDeclaration`, `RmtSelectorWhereClause`, `RmtSelectorFindClause`, `RmtSelectorSortClause`, `RmtSelectorOutputClause` |
+| DataSource | `RmtDataSourceDeclaration`, `RmtPrimitiveSourceReference`, `RmtDataSourceMethodClause`, `RmtDataSourceContractClause`, `RmtDataSourceResultClause`, `RmtDataSourceFallbackClause` |
+| Action | `RmtActionDeclaration`, `RmtActionInputClause`, `RmtActionStatusClause`, `RmtEffectStatement`, `RmtReducerStatement`, `RmtEmitStatement`, `RmtActionResultHandler` |
+| Portal | `RmtPortalDeclaration`, `RmtPrimitiveAttribute`, `RmtPortalPolicyClause` |
+| Overlay | `RmtOverlayDeclaration`, `RmtOverlayPolicyClause` |
+| Resource | `RmtResourceDeclaration`, `RmtResourceImportClause`, `RmtResourceSourceClause`, `RmtResourceDisposeClause` |
+| Surface | erweiterte `RmtSurfaceDeclaration`, `RmtSurfaceHeaderClause`, `RmtSurfaceSourceClause`, `RmtSurfaceRepeatClause`, `RmtSurfaceKeyClause`, `RmtSurfacePortalClause`, `RmtSurfaceBoundsClause`, `RmtSurfacePreserveClause`, `RmtSurfaceDestroyClause` |
+| Event | erweiterte `RmtEventBinding`, `RmtEventSelector`, `RmtEventPayloadBlock`, `RmtEventPayloadMapping`, `RmtEventOptionClause` |
+
+## Parser-Grenzen
+
+- Selector-Ausdruecke wie `contains(record.name, state.media.filters.query)`
+  werden in PRIM-02 als deklarative Raw-Clause mit Source Range erhalten.
+  Die semantische Operator-AST folgt in PRIM-03.
+- Action-Result-Handler wie `on success -> reduce ...` erhalten den Effekttext
+  und die Source Range. Typisierte Effect-Nodes folgen in PRIM-03/04.
+- Der Compiler ignoriert unbekannte Template-Body-Nodes weiterhin, damit
+  bestehende vNext-Core-Builds stabil bleiben. Primitive-Lowering ist PRIM-04.
+- Der RMT-Kernel wird in PRIM-02 nicht ingestiert. Das Source-to-Sea-Gate ist
+  PRIM-06.
+
+## Verifikation
+
+Direkte lokale Checks:
+
+```bash
+node --check tools/rmt-language/vnext-parser.js
+node --check tests/rmt-language/rmt_vnext_parser_suite.js
+node -e "const { runRmtVNextParserSuite } = require('./tests/rmt-language/rmt_vnext_parser_suite'); const result = runRmtVNextParserSuite(); process.exit(result.ok ? 0 : 1)"
+node -e "const { runRmtVNextCompilerSuite } = require('./tests/rmt-language/rmt_vnext_compiler_suite'); const result = runRmtVNextCompilerSuite(); process.exit(result.ok ? 0 : 1)"
+```
+
+Der globale Runner `node scripts/run_xtend_tests.js rmt-vnext-parser --json`
+ist aktuell durch bestehende Merge-Conflict-Marker in
+`tests/references/reference_path_suite.js` blockiert, weil der Runner diese
+Suite beim Start importiert.
+
+## Handoff
+
+- `RMT-VNEXT-PRIM-03`: [RMT vNext Primitive Semantic Graph](./rmt-vnext-primitive-semantic-graph.md)
+  baut Indexe, Referenzen und Pre-Runtime-Diagnostics fuer die Primitive-AST-
+  Nodes auf.
+- `RMT-VNEXT-PRIM-04`: Primitive-AST und Semantic Graph in Core-/App-Platform-
+  Records absenken.
+- Language Server nachziehen: completions, hover, symbols und code actions fuer
+  die neuen Node-Typen.