@ccslabs/xtend 0.1.0-rc.1 → 0.1.2

package/docs/de/public-component-types.md

@@ -0,0 +1,79 @@
+# Public Component Types
+
+- Contract: `xtend.docs.public-component-types.v1`
+- Type Contract: `xtend.enterprise.er-wp-34.public-component-types.v1`
+- Workpackage: `ER-WP-34`
+
+XTend liefert fuer priorisierte Public Components lokale TypeScript-Declaration-Artefakte neben der jeweiligen Runtime-Source aus. Die Dateien liegen direkt in `components/*.d.ts` und werden ueber den Package-Export `xtend/components/*` erreichbar.
+
+## Lokaler Contract
+
+```text
+components/xtend-public-types.d.ts
+components/xalert.d.ts
+components/xtoast.d.ts
+components/xmodal.d.ts
+components/xrouter.d.ts
+components/xlink.d.ts
+components/xinput.d.ts
+components/xselect.d.ts
+components/xcheckbox.d.ts
+components/xradio.d.ts
+components/xtextarea.d.ts
+components/xstatus.d.ts
+components/xprogress.d.ts
+components/xtooltip.d.ts
+components/xpopover.d.ts
+components/xdrawer.d.ts
+components/xform.d.ts
+components/xtabs.d.ts
+components/xdialog.d.ts
+components/xlightbox.d.ts
+components/xcalendar.d.ts
+components/xwriter.d.ts
+components/xtheme.d.ts
+components/xbutton.d.ts
+components/xspinner.d.ts
+components/xmenu.d.ts
+components/xsummary.d.ts
+components/xplayer.d.ts
+components/xsection.d.ts
+components/xcards.d.ts
+components/xheader.d.ts
+components/xfooter.d.ts
+components/xhero.d.ts
+components/xtype.d.ts
+components/xcode.d.ts
+components/xmasonry.d.ts
+components/xstate.d.ts
+components/xutils.d.ts
+```
+
+Jede Komponenten-Datei beschreibt:
+
+- Public Attribute-Namen
+- Public Property- und Methodenflaechen
+- Eventnamen
+- `CustomEvent` Detail-Payloads
+- `HTMLElementTagNameMap` fuer Custom Elements
+- typed `addEventListener` Overloads fuer komponentenspezifische Events
+
+`x-theme` ist kein Custom Element, sondern ein Core-Modul. Seine Typen beschreiben deshalb `window.XTend.theme`, `window.XTheme`, A11y-Preference-Snapshots, Motion-/Contrast-Policy, Density, Theme Context, Performance Snapshot, RMT Metadata und die Document-Events `theme-initialized`, `theme-changed`, `theme-variable-changed`, `theme-preference-changed`, `theme-a11y-announcement`, `theme-density-changed`, `theme-context-changed` und `theme-performance-measured`.
+
+## Gate
+
+```bash
+node scripts/run_xtend_tests.js components
+```
+
+Die Component-Suite enthaelt ab `ER-WP-34` den Sub-Gate `component-public-types`. Nach `RC1TB-WP-03` prueft er die Shared-Type-Helfer, alle 44 priorisierten `.d.ts` Dateien, Eventnamen, Detail-Typen, API-Methoden und Element-/Window-Mappings.
+
+Ab `WP-TypeExports-09` ist der Component-Wildcard-Export auch im produktiven TypeExports-Handoff abgedeckt. `./components/*` bleibt eine adjacent-Declaration-Grenze: Consumer bekommen `components/*.d.ts` ueber die nebenliegenden Dateien, waehrend `node scripts/run_xtend_tests.js type-exports --json` verhindert, dass neue Public Component Exports ohne Type-Entscheidung in die Package Surface geraten.
+
+## Coverage-Status
+
+Nach `RC1TB-WP-03` stehen `types` in der Component Catalog Coverage Matrix bei `44/44`. `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` sind die aktuelle `enterprise-ready` Referenzlinie mit Public Types, Component-Suite, Fixture, A11y und Performance-Profil. `xstate` besitzt Public Types fuer Boundary Contract, RMT State Adapter, Lifecycle Events und Diagnostics. `x-utils` besitzt Public Types fuer Utility Contract, Import Policy, Boundary Snapshot, UI Effects, Template API sowie die Events `xutils:import-policy-check` und `xutils:ui-effects-change`.
+
+Es gibt nach `WP-E12-09` keinen verbleibenden Type-Gap. Seit `WP-E13-05` sind auch die frueheren Boundary-Residuals geschlossen: `xstate` ist `closed-as-runtime-boundary`, `x-utils` ist `closed-as-utility-boundary`. Beide bleiben Public-Type-Boundaries, aber keine offenen Type- oder Performance-Aufgaben.
+
+Die frueheren Vendor-Grenzen `components/prism.js` und `components/turndown.js` besitzen ab `WP-TypeExports-08` schmale Facade-Declarations. Sie sind keine Public XTend UI Komponenten, werden aber vom TypeExports-Release-Gate gegen unbeabsichtigten Declaration Drift mitgeprueft.

package/docs/de/quick-start-guide.md

@@ -0,0 +1,220 @@
+# Quick Start Guide
+
+Dieser Guide bringt dich von einer lokalen XTend-Seite zu einer kleinen
+RMT-vNext-App-Shell. Der schnellste Einstieg bleibt HTML mit Web Components;
+der empfohlene Ausbaupfad fuer Apps ist RMT-first.
+
+## Voraussetzungen
+
+- Node.js 18 oder neuer
+- ein lokaler Checkout des XTend-Repositories
+- ein Browser mit Custom-Elements- und ES-Module-Support
+
+Starte den lokalen Dev Server:
+
+```bash
+npm run dev:local
+```
+
+Der Server liefert die App normalerweise unter `http://127.0.0.1:4173/` aus.
+
+## 1. Minimalen Host starten
+
+Lege im Projekt eine HTML-Datei an, zum Beispiel `quick-start.html`:
+
+```html
+<!doctype html>
+<html lang="de">
+<head>
+  <meta charset="utf-8">
+  <meta name="viewport" content="width=device-width,initial-scale=1">
+  <meta name="xtend-preload" content="x-theme,x-section,x-button">
+  <title>XTend Quick Start</title>
+  <script
+    type="module"
+    src="/xtend-loader.js"
+    data-manifest="/components/manifest.json">
+  </script>
+</head>
+<body>
+  <main>
+    <x-section layout="column" label="Quick Start">
+      <h1>Hallo XTend</h1>
+      <p>Diese App laeuft mit lokalen Web Components.</p>
+      <x-button variant="primary">Loslegen</x-button>
+    </x-section>
+  </main>
+</body>
+</html>
+```
+
+Oeffne danach `http://127.0.0.1:4173/quick-start.html`.
+
+Was passiert hier?
+
+- `xtend-loader.js` ist der lokale Loader.
+- `components/manifest.json` ist die Component Registry.
+- `meta name="xtend-preload"` laedt kritische Komponenten frueh.
+- `x-theme` ist ein Infrastrukturmodul; `x-section` und `x-button` sind
+  normale XTend Web Components.
+- `/xtend.css` ist optional und dient Host-Theming.
+
+## 2. App Shell in RMT vNext beschreiben
+
+Wenn aus der Seite eine App wird, soll die Shell in RMT liegen. RMT vNext
+beschreibt UI-Struktur, State, Actions, Events, Surfaces und Scheduling in
+einer lesbaren `.rmt` Quelle.
+
+Lege zum Beispiel `app.rmt` an:
+
+```rmt
+template quickstart.app {
+  state counter type number initial 0
+
+  selector counterLabel from state counter {
+    output text
+  }
+
+  action increment {
+    input amount number
+    reduce state.counter = input.amount
+    emit counter.changed with action increment
+  }
+
+  portal app root "#app-root" layer surface
+
+  surface home kind page component x-section {
+    source state counter
+    portal app
+    key route.path
+
+    lane visible weight 80 {
+      hydrate x-section from state counter
+    }
+
+    on click target button.primary -> action increment {
+      payload amount from 1
+    }
+  }
+}
+```
+
+Dieses Dokument ist kein Runtime-Import und keine Framework-Komponente. Es ist
+die App-Beschreibung: Der Compiler erzeugt daraus Core-/Kernel-Records, die
+Host-Adapter mit XTend Components, XRouter und Fabric verbinden koennen.
+
+## 3. XTend UI aus RMT materialisieren
+
+Fuer Runtime-Hosts verbindet die Component Capability Registry RMT-Descriptoren
+mit den vorhandenen XTend-Komponenten aus dem Manifest. Dadurch bleiben
+Component Contracts, Events, Slots, Parts und State-Bindings die gemeinsame
+Quelle der Wahrheit:
+
+```js
+import {
+  createRmtComponentCapabilityRegistry
+} from '@ccslabs/xtend/rmt/component-capability-registry';
+import {
+  createRmtDomDescriptorRenderer
+} from '@ccslabs/xtend/rmt/dom-descriptor-renderer';
+
+const registry = createRmtComponentCapabilityRegistry({ manifest, sourceTexts });
+const renderer = createRmtDomDescriptorRenderer({ documentTarget: document });
+
+renderer.renderKeyed(root, [
+  registry.buildComponentDescriptor({
+    tag: 'x-button',
+    key: 'primary-action',
+    attributes: { variant: 'primary' },
+    slots: { default: { text: 'Loslegen' } },
+    events: { click: 'quickstart.increment' }
+  })
+], {
+  componentRegistry: registry,
+  dispatchEvent: actions.dispatch,
+  stateBridge
+});
+```
+
+So koennen RMT-Primitives XTend UI nutzen, ohne Shadow-DOM-Patches,
+komponentenspezifische Renderer oder manuelle HTML-Sinks einzubauen.
+
+## 4. Serverseitig vorhydrieren
+
+Node-Hosts koennen dieselbe RMT-Beschreibung fuer SSR und inkrementelles JSONL
+nutzen. Der Adapter bleibt framework-neutral und startet keinen eigenen
+HTTP-Server:
+
+```js
+import {
+  createRmtNodeSsrAdapter
+} from '@ccslabs/xtend/rmt/node-ssr-adapter';
+
+const adapter = createRmtNodeSsrAdapter({ manifest, sourceTexts });
+const result = await adapter.render({ source, filePath: 'app.rmt' });
+```
+
+PHP/Laravel-Hosts nutzen denselben clientseitigen Wire-Shape ueber das
+Single-File-Modul:
+
+```php
+require __DIR__ . '/xtendrmt/rmt-php-ssr-adapter.php';
+
+$adapter = createRmtPhpSsrAdapter(['manifest' => $manifest]);
+$result = $adapter->render(['coreDocument' => $coreDocument]);
+```
+
+Mehr dazu:
+[RMT Node SSR Adapter](./rmt-node-ssr-adapter.md) und
+[RMT PHP/Laravel SSR Adapter](./rmt-php-ssr-adapter.md).
+
+## 5. RMT lokal pruefen
+
+Der Standardcheck fuer ein einzelnes Dokument ist:
+
+```bash
+xt rmt lint app.rmt
+```
+
+Fuer CI oder maschinenlesbare Auswertung:
+
+```bash
+xt rmt lint app.rmt --json
+```
+
+AI-Agenten koennen den Repair Report nutzen:
+
+```bash
+xt rmt lint app.rmt --agent
+```
+
+Der Agent Report enthaelt `repairPlan`, `fixOrder`, `confidence`, `impact`,
+`relatedDiagnostics` und erklaerte No-Ops fuer bewusst nicht automatisierte
+Reparaturen.
+
+## 6. Editor-Unterstuetzung aktivieren
+
+Der RMT Language Server startet lokal ueber:
+
+```bash
+node tools/rmt-language-server/server.js
+```
+
+Er liefert Diagnostics, Completion, Hover, Document Symbols, Definition und
+Code Actions. VS Code, JetBrains, Neovim und Helix koennen den Server ueber
+stdio anbinden. Fuer eine minimale native App-Shell kannst du in einer IDE mit
+RMT Snippets den Prefix `rmt-app` nutzen; fuer vNext-Primitives ist
+`rmt-vnext-primitive-shell` der schnellste Start.
+
+## Naechste Schritte
+
+- [RMT vNext Authoring Guide](./rmt-vnext-authoring.md)
+- [RMT vNext Component Primitives und XTend UI](./rmt-vnext-component-primitives.md)
+- [RMT Node SSR Adapter](./rmt-node-ssr-adapter.md)
+- [RMT PHP/Laravel SSR Adapter](./rmt-php-ssr-adapter.md)
+- [XTendRMT Developer Overview](./xtendrmt-overview.md)
+- [RMT Linter und AI-Agent Repair Report](./rmt-linter.md)
+- [RMT Language Server und Editor Setup](./rmt-language-server.md)
+- [XTend Loader](./xtend-loader.md)
+- [Manifest-Format](./manifest.md)
+- [Komponenten-Entwicklung](./components.md)

package/docs/de/rc0-adoption-guide.md

@@ -0,0 +1,102 @@
+# RC0 Adoption Guide
+
+- Contract: `xtend.epic12.docs-adoption.v1`
+- Report: `xtend.epic12.docs-adoption-report.v1`
+- Workpackage: `WP-E12-15`
+- Lokaler Gate: `node scripts/run_xtend_tests.js epic12-docs-adoption --json`
+
+Dieser Guide ist der produktnahe Einstieg fuer Teams, die XTend nach Epic 12 als Release-Candidate-Kandidaten evaluieren. Er verbindet die Migration Notes aus Long-Tail Runtime, Visual Snapshots, Design Tokens, RMT DSL Authoring Polish und RC0 Gate Matrix.
+
+RC0 bleibt ein lokaler Review-Kandidat. `private-until-release-owner-approval` bleibt aktiv; ein gruener Gate-Lauf ist keine Publish-Freigabe.
+
+## Migration Notes
+
+### Long-Tail Runtime Closure
+
+Geschlossen:
+
+- `x-tabs`: Performance Profile, Keyboard, Browser-Smoke, Theme Matrix
+- `x-theme`: A11y, Reduced Motion, Forced Colors, Performance, Theme Propagation, Density Boundary
+- `x-button`: Performance Budget, Interaction Budget, Fabric Measurement, RMT Metadata
+- `x-menu`: Performance, Keyboard Navigation, Router-Kompatibilitaet, Fabric Measurement, RMT Metadata
+
+Akzeptierte RC0-Residuals:
+
+- `xstate`: nicht-visuelle Boundary-Probe, `contract-gated`
+- `x-utils`: Utility-Boundary, `typed-contract-gated`
+
+Diese Residuals sind keine versteckten Blocker. Sie bleiben sichtbar, weil Infrastrukturmodule nicht kuenstlich als UI-Shells behandelt werden.
+
+### DOM-first Visual Snapshots
+
+Der RC0 Snapshot-Pfad ist DOM-first:
+
+```bash
+node scripts/run_xtend_tests.js visual-snapshots --json
+node scripts/run_xtend_tests.js design-tokens --json
+```
+
+Pixel-Baselines sind optional lokal. Die reviewbare Baseline liegt in `tests/browser/visual-baselines/visual-snapshots.dom-baseline.json`.
+
+### Design Token Productization
+
+Neue Komponenten und RMT-Shells nutzen die `--xtend-*` Tokenlinie. Theme Packs, Density Packs, High Contrast, Forced Colors und CSS Parts sind oeffentliche Styling-Oberflaechen und brauchen Migration Notes, wenn sie veraendert werden.
+
+### RMT DSL Authoring Polish
+
+Neue RMT-App-Dokumente koennen Shells, Routes, Links, Outlets, Components, Slots, Commands, Hydration und Lanes ueber die DSL-Polish-Schicht authoren. XTendRMT bleibt framework-agnostisch: Der Kernel importiert keine XTend-Typen und keine XRouter-Implementierung.
+
+### RC0 Gate Matrix
+
+Vor dem Owner Review:
+
+```bash
+node scripts/run_xtend_tests.js epic12-docs-adoption --json
+node scripts/run_xtend_tests.js rc0-gate-matrix --json
+npm run test:release:full:report
+npm run pack:dry-run
+```
+
+Conditional Network Gates:
+
+```bash
+npm audit --audit-level=moderate
+npm sbom --sbom-format=cyclonedx --json
+```
+
+Wenn Netzwerkzugriff nicht verfuegbar ist, bleibt RC0 lokal reviewbar; Publish bleibt blockiert.
+
+## Component Author Checklist
+
+| Check | Pflicht |
+|-------|---------|
+| `xtend-loader.js` und lokales Manifest verwenden | ja |
+| Types, Events, A11y und Performance dokumentieren | ja |
+| Design Tokens und CSS Parts als Public API behandeln | ja |
+| Fabric-Lanes und RMT-Schedule-Hints korrekt setzen | ja |
+| Snapshot- und Theme-Matrix-Auswirkungen pruefen | ja |
+| Breaking Changes mit Migration Notes markieren | ja |
+
+## App Author Checklist
+
+| Check | Pflicht |
+|-------|---------|
+| App Shell nach Moeglichkeit Shell-first in RMT beschreiben | ja |
+| XRouter-Routen ueber native RMT `routes` Records fuehren | ja |
+| Parsedown, Rich HTML oder Media als scheduled Content-Komponenten behandeln | ja |
+| Trusted-DOM-Boundary fuer `html_fragment` pruefen | ja |
+| `rmt-dsl-authoring-polish` und `docs-rmt-pilot` fuer RMT-Pfade ausfuehren | ja |
+
+## Known Residual Policy
+
+RC0 akzeptiert:
+
+- `xstate`
+- `x-utils`
+- `xtend.component.hydrate`
+
+Die Hydration-Warnung bleibt akzeptiert, solange sie unter der Fail-Schwelle und unter `maxWarningCount = 2` bleibt. Failures sind nicht erlaubt.
+
+## Handoff zu WP-E12-16
+
+`WP-E12-16` hat aus diesem Guide, der [RC0 Gate Matrix](./rc0-gate-matrix.md), dem Package Dry Run, den Conditional Network Gates und der Known Residual Policy den [Epic 12 RC0 Handoff](./epic12-rc0-handoff.md) fuer Release Owner gebaut.

package/docs/de/rc0-gate-matrix.md

@@ -0,0 +1,58 @@
+# RC0 Gate Matrix
+
+`xtend.epic12.rc0-gate-matrix.v1` beschreibt den ersten release-kandidatenfaehigen Gate-Schnitt fuer XTend. RC0 ist ein lokaler Review-Kandidat, kein Publish.
+
+Lokaler Self Check:
+
+```bash
+node scripts/run_xtend_tests.js rc0-gate-matrix --json
+npm run test:rc0-gate-matrix
+```
+
+## Pflichtgates
+
+| Bereich | Command |
+|---------|---------|
+| PR Fast | `npm run test:pr:report` |
+| Full Release | `npm run test:release:full:report` |
+| Snapshot Gate | `node scripts/run_xtend_tests.js component-shell-theme-matrix visual-snapshot-automation visual-snapshots design-tokens --json` |
+| RMT Authoring Gate | `node scripts/run_xtend_tests.js rmt-shell-authoring-ux rmt-first-class-app rmt-first-demo-app docs-rmt-pilot rmt-dsl-authoring-polish --json` |
+| Package Dry Run | `npm run pack:dry-run` |
+| Matrix Self Check | `node scripts/run_xtend_tests.js rc0-gate-matrix --json` |
+
+## Snapshot und Design Tokens
+
+Der Snapshot Gate nutzt `visual-snapshots` und `design-tokens`. Pixel-Baselines bleiben optional; die reviewbare RC0-Basis ist die DOM-Baseline unter `tests/browser/visual-baselines/visual-snapshots.dom-baseline.json`.
+
+## RMT Authoring
+
+Der RMT Authoring Gate verbindet Shell Authoring, RMT-first Apps, Docs Parsedown Scheduling und den neuen `rmt-dsl-authoring-polish` Gate. So ist pruefbar, dass XTend UI, XRouter und XTendRMT zusammenarbeiten, ohne XTend-Typen in den RMT Kernel zu importieren.
+
+## Conditional Network Gates
+
+Vor Publish muessen Netzwerk-Gates laufen oder im Handoff bewusst deferred werden:
+
+```bash
+npm audit --audit-level=moderate
+npm sbom --sbom-format=cyclonedx --json
+```
+
+Diese Gates sind nicht Teil des lokalen Default-Runners.
+
+## Known Residual Policy
+
+RC0 akzeptiert aktuell:
+
+- `xstate` als `contract-gated` nicht-visuelle Boundary-Probe
+- `x-utils` als `typed-contract-gated` Utility-Boundary
+- die bekannte Performance-Warnung `xtend.component.hydrate`, solange sie unter der Fail-Schwelle bleibt
+
+`private-until-release-owner-approval` bleibt aktiv. Auch ein gruener RC0 Gate Run bedeutet keine Publish-Freigabe.
+
+## Migration und Adoption
+
+Die operative Doku fuer Teams liegt seit `WP-E12-15` im [RC0 Adoption Guide](./rc0-adoption-guide.md). Dort sind Long-Tail Runtime Closure, DOM-first Snapshot-Baseline, Design Token Productization, RMT DSL Authoring Polish, Known Residual Policy und Migration Notes fuer Component Authors und App Authors zusammengefuehrt.
+
+Der finale Owner-Handoff liegt seit `WP-E12-16` unter [Epic 12 RC0 Handoff](./epic12-rc0-handoff.md). Er setzt den Epic-12-Status auf `ready-for-release-owner-review-not-publish` und laesst Publishing bis zur Release Owner Acceptance blockiert.
+
+Kanonischer Pfad: `docs/rc0-adoption-guide.md`.

package/docs/de/rc1-gate-matrix-ci-handoff.md

@@ -0,0 +1,56 @@
+# RC1 Gate Matrix und CI-Handoff
+
+Contract: `xtend.epic13.rc1-gate-matrix-ci-handoff.v1`
+
+Status: `accepted-rc1-gate-matrix-ci-handoff`
+
+Workpackage: `WP-E13-13`
+
+DPF-Paket: `DPF-WP-01-rc1-gate-matrix-ci-handoff`
+
+## Ziel
+
+Die RC1 Gate Matrix fasst die Epic-13-Evidence in einen lokalen, netzwerkfreien Handoff fuer CI Maintainer und Release Owner zusammen. Der Gate prueft nicht die produktiven Netzwerklaeufe selbst, sondern ob ihre Evidence-Pfade, Deferral-Regeln, Reports und Owner-Metadaten registriert sind.
+
+## Lokaler Gate
+
+```bash
+node scripts/run_xtend_tests.js epic13-rc1-gate-matrix-ci-handoff --json
+npm run test:epic13-rc1-gate-matrix-ci-handoff
+```
+
+Der Report schreibt bei Aggregatlaeufen nach `.xtend-test-results/xtend-epic13-rc1-gate-matrix-ci-handoff-report.json` und nutzt `xtend.epic13.rc1-gate-matrix-ci-handoff-report.v1`.
+
+## Source Gates
+
+- `npm run test:epic13-rc1-readiness`
+- `npm run test:epic13-release-owner-acceptance`
+- `npm run test:epic13-conditional-network-evidence`
+- `npm run test:epic13-package-export-lock`
+- `npm run test:epic13-known-residual-triage`
+- `npm run test:epic13-hydration-performance-closure`
+- `npm run test:epic13-prod-browser-csp-smoke`
+- `npm run test:epic13-visual-owner-artifact`
+- `npm run test:epic13-rmt-production-readiness`
+- `npm run test:epic13-docs-rmt-production-hardening`
+- `npm run test:epic13-trusted-dom-boundary`
+- `npm run test:epic13-rc1-migration-notes`
+
+## CI Lanes
+
+| Lane | Zweck | Report |
+|------|-------|--------|
+| `pr-fast` | PR Feedback mit TypeExports Drift-Handoff | `.xtend-test-results/xtend-pr-gate-report.json` |
+| `rc1-full-release` | vollstaendige RC1 Release-Gate-Matrix | `.xtend-test-results/xtend-release-gate-report.json` |
+| `conditional-network-evidence` | Audit/SBOM Execution oder Owner Deferral | `.xtend-test-results/xtend-conditional-network-evidence-report.json` |
+| `owner-handoff` | Release-Owner-Schnitt fuer alle Epic-13-Gates | `.xtend-test-results/xtend-epic13-rc1-gate-matrix-ci-handoff-report.json` |
+
+## Release Owner Evidence
+
+[Release Report und Pack Dry Run Evidence](./release-report-pack-dry-run-evidence.md) ergaenzt den Handoff mit `xtend.epic13.release-report-pack-dry-run-evidence.v1` und schreibt `.xtend-test-results/xtend-epic13-release-report-pack-dry-run-evidence-report.json`.
+
+[Conditional Network Evidence CI](./conditional-network-evidence-ci.md) ergaenzt den Handoff mit `xtend.epic13.conditional-network-evidence-ci.v1`, dem CI-Job `conditional-network-evidence` und `.xtend-test-results/xtend-epic13-conditional-network-evidence-ci-report.json`.
+
+## Publish Boundary
+
+`publishAllowed` bleibt `false`; `packagePrivateRequired` bleibt `true`. Netzwerkbasierte Gates duerfen lokal nur als `executed-or-owner-deferral` referenziert werden. `WP-E13-14` uebernimmt daraus den finalen Epic-13-Abschlussreview und RC1-Handoff.

package/docs/de/rc1-migration-notes.md

@@ -0,0 +1,69 @@
+# RC1 Migration Notes
+
+Contract: `xtend.epic13.rc1-migration-notes-semver.v1`
+
+WP-E13-12 bereitet die Konsumentenkommunikation fuer den ersten RC1-Kandidaten vor. Der angewendete Stand ist `0.1.0-rc.1`; die Package Boundary ist fuer RC1-Publish-Prep auf `private: false` geoeffnet. Der eigentliche Publish-Befehl bleibt weiterhin ein separater manueller Owner-Schritt.
+
+## SemVer
+
+| Feld | Wert |
+| --- | --- |
+| Current Version | `0.1.0-rc.1` |
+| Proposed Version | `0.1.0-rc.1` |
+| Classification | `minor-pre-1.0-release-candidate` |
+| Publish | vorbereitet, `private: false`; `npm publish` nicht ausgefuehrt |
+
+## Migration Sections
+
+### loader-local-esm-cdn-free
+
+XTend-Apps sollen lokale ESM-Loader-Pfade nutzen. Deprecated CDN-Bootstraps, insbesondere alte `xstate`-Referenzen, gehoeren nicht mehr in RC1-nahe Apps.
+
+### package-export-surface
+
+Der Package Export Lock ist die verbindliche Public Surface. Neue Tooling-Exports, darunter `./catalog/epic13-rc1-migration-notes`, muessen im Export Lock, README, Changelog und den Release-Gates auftauchen.
+
+### rmt-first-app-authoring
+
+RMT ist der Shell-first App Authoring Pfad. XTend-Komponenten werden ueber Adapter angebunden; der RMT-Kernel importiert keine XTend-Typen.
+
+### docs-rmt-parsedown-shell
+
+Parsedown ist eine schedulbare Docs-Komponente innerhalb der RMT Shell. Rich HTML oder Multimedia Slots koennen spaeter daneben orchestriert werden.
+
+### trusted-dom-boundary
+
+`dom_descriptor` bleibt bevorzugt. `html_fragment` und Parsedown HTML muessen vor DOM-Sinks ueber `xtend.security.trusted-dom-sanitizer.v1` laufen.
+
+### fabric-lanes-telemetry
+
+Fabric, Lanes und RMT Lane Mapping sind die bevorzugte Bruecke fuer Telemetry und Scheduler-Signale in Komponenten.
+
+### component-typescript-and-dts
+
+Komponenten-Typen und `.d.ts`-Dateien sind Teil des Consumer Contracts. App-Code soll diese Typen statt impliziter DOM-Konventionen konsumieren.
+
+### known-residuals-and-watchpoints
+
+`xstate` und `x-utils` bleiben Boundary Contracts. Der alte Hydration-Watchpoint ist geschlossen, sollte aber in RC1-Gates sichtbar bleiben.
+
+### visual-owner-artifacts
+
+Visual Proofs bleiben owner-reviewbar. Lokale Gates duerfen statisch bleiben; CI oder Release Owner koennen Screenshots als Artefakt bereitstellen.
+
+### conditional-network-evidence
+
+Audit und SBOM werden entweder ausgefuehrt oder explizit owner-deferred. Ohne Evidence oder Deferral gibt es keine Publish-Freigabe.
+
+### publish-boundary
+
+`private: false` ist fuer RC1-Publish-Prep gesetzt. Automatisches Publish bleibt blockiert; der finale `npm publish` braucht weiterhin den manuellen Owner-Befehl.
+
+## Lokaler Gate
+
+```bash
+node scripts/run_xtend_tests.js epic13-rc1-migration-notes --json
+npm run test:epic13-rc1-migration-notes
+```
+
+Der direkte Handoff aus diesem Paket war `WP-E13-13` mit `rc1-gate-matrix-ci-handoff`; die zugehoerige Gate Matrix ist inzwischen unter [RC1 Gate Matrix und CI-Handoff](./rc1-gate-matrix-ci-handoff.md) dokumentiert.

package/docs/de/rc1-readiness.md

@@ -0,0 +1,46 @@
+# RC1 Readiness
+
+- Contract: `xtend.epic13.rc1-production-readiness.v1`
+- Report: `xtend.epic13.rc1-readiness-report.v1`
+- Workpackage: `WP-E13-01`
+- Lokaler Gate: `node scripts/run_xtend_tests.js epic13-rc1-readiness --json`
+- Zielzustand: `rc1-production-candidate-ready`
+
+RC1 fuehrt den RC0-Handoff in einen PROD-naeheren Release Candidate. Der Status bedeutet nicht Publish. `private-until-release-owner-acceptance` bleibt aktiv.
+
+## Was RC1 pruefbar machen muss
+
+| Bereich | RC1-Pflicht |
+|---------|-------------|
+| Release Owner Acceptance | formaler Contract mit Accepted, Deferred und Blocked Entscheidungen |
+| Conditional Network Gates | `npm audit --audit-level=moderate` und `npm sbom --sbom-format=cyclonedx --json` ausfuehren oder Owner-Deferral dokumentieren |
+| Package Dry Run | Paketinhalt und Export Surface maschinenlesbar pruefen |
+| Known Residuals | `xstate` und `x-utils` sind geschlossen; `xtend.component.hydrate` ist in `WP-E13-06` owner-frei geschlossen |
+| Browser/CSP | PROD-nahe same-origin, Nonce und Loader-Smokes sind unter [PROD Browser CSP Smokes](./prod-browser-csp-smokes.md) vorbereitet |
+| Visual Evidence | DOM-first Snapshots behalten und optionales Screenshot/Pixels-Artefakt unter [Visual Owner Artifacts](./visual-owner-artifacts.md) normalisieren |
+| RMT Apps | RMT-first App Shell, Routing, Components, Fabric, Lanes und Diagnostics buendeln |
+| Docs-App | Parsedown bleibt orchestrierte Komponente innerhalb einer RMT Shell |
+| Trusted DOM | Parsedown/RMT HTML Boundary browsernah geprueft |
+| Migration Notes | RC1 SemVer- und Changelog-Entscheid vorbereiten |
+
+## Baseline Gates
+
+```bash
+node scripts/run_xtend_tests.js epic13-rc1-readiness --json
+node scripts/run_xtend_tests.js epic12-rc0-handoff --json
+node scripts/run_xtend_tests.js rc0-gate-matrix --json
+node scripts/run_xtend_tests.js references --json
+```
+
+## Feature Drift
+
+Nicht Teil von RC1:
+
+- XTend in den RMT Kernel einbetten
+- CDN-Fallbacks in Default-Pfade zurueckbringen
+- neue Produktfeatures ohne PROD-Readiness-Zweck bauen
+- `private: true` automatisch oeffnen
+
+## Handoff
+
+`WP-E13-02` ist abgeschlossen und dokumentiert den Release Owner Acceptance Contract unter [Release Owner Acceptance](./release-owner-acceptance.md). `WP-E13-03` ist ebenfalls abgeschlossen und dokumentiert die Conditional Network Evidence unter [Conditional Network Evidence](./conditional-network-evidence.md). `WP-E13-04` ist abgeschlossen und dokumentiert den Package Export Lock unter [Package Export Lock](./package-export-lock.md). `WP-E13-05` ist abgeschlossen und dokumentiert die Known Residual Triage unter [Known Residual Triage](./known-residual-triage.md). `WP-E13-06` ist abgeschlossen und dokumentiert die [Hydration Performance Closure](./hydration-performance-closure.md). `WP-E13-07` ist abgeschlossen und dokumentiert die [PROD Browser CSP Smokes](./prod-browser-csp-smokes.md). `WP-E13-08` ist abgeschlossen und dokumentiert `xtend.epic13.visual-owner-artifact.v1` unter [Visual Owner Artifacts](./visual-owner-artifacts.md). `WP-E13-09` ist abgeschlossen und dokumentiert `xtend.epic13.rmt-production-readiness.v1` unter [RMT Production Readiness](./rmt-production-readiness.md). `WP-E13-10` ist abgeschlossen und dokumentiert `xtend.epic13.docs-rmt-production-hardening.v1` unter [Docs RMT Production Hardening](./docs-rmt-production-hardening.md). `WP-E13-11` ist abgeschlossen und dokumentiert `xtend.epic13.trusted-dom-boundary.v1` unter [Trusted DOM Boundary Browser Proof](./trusted-dom-boundary-browser-proof.md). `WP-E13-12` ist abgeschlossen und dokumentiert `xtend.epic13.rc1-migration-notes-semver.v1` unter [RC1 Migration Notes](./rc1-migration-notes.md). `WP-E13-13` ist abgeschlossen und dokumentiert `xtend.epic13.rc1-gate-matrix-ci-handoff.v1` unter [RC1 Gate Matrix und CI-Handoff](./rc1-gate-matrix-ci-handoff.md). `WP-E13-14` ist ready fuer den finalen Epic-13-Abschlussreview.