@ccslabs/xtend 0.1.0-rc.1 → 0.1.2

package/docs/de/manifest-import-policy.md

@@ -0,0 +1,79 @@
+# Manifest Import Policy
+
+- Docs Contract: `xtend.docs.manifest-import-policy.v1`
+- Loader Policy: `xtend.security.loader-policy.v1`
+- Manifest Policy: `xtend.security.manifest-policy.v1`
+- Import Policy: `xtend.security.import-policy.v1`
+- Gate: `xtend.security.manifest-import-gate.v1`
+
+XTend laedt Komponenten ueber das Manifest. Seit `ER-WP-28` wird dieser Pfad explizit abgesichert: Manifest-URLs, Manifest Records und dynamische Modul-Imports werden lokal validiert, bevor der Loader sie nutzt.
+
+## Erlaubt
+
+- relative URLs wie `./xalert.js`
+- root-relative URLs wie `/components/xrouter.js`
+- same-origin URLs
+- lokale Loopback-Dev-Server wie `http://localhost:4173/components/xmodal.js`
+- `.json` fuer Manifeste
+- `.js` und `.mjs` fuer Module
+
+## Verweigert
+
+- externe CDN-/Remote-Module
+- externe Manifest-URLs
+- `javascript:`
+- `data:` fuer Skripte
+- `blob:` Module
+- encoded Path Traversal wie `%2e%2e`
+- Modulpfade ohne `.js` oder `.mjs`
+- Manifestpfade ohne `.json`
+- ungueltige Manifest-Keys
+- URL-artige Dependency-Werte in Manifest-Records
+
+## Diagnostics
+
+Der Loader emittiert Refusals als `xtend-loader-diagnostic`:
+
+```js
+window.addEventListener('xtend-loader-diagnostic', (event) => {
+  console.log(event.detail.code, event.detail.metadata.diagnostics);
+});
+```
+
+Stabile Codes:
+
+- `xtend.security.loader.refused`
+- `xtend.security.manifest.invalid`
+- `xtend.security.import.refused`
+
+## Maschinenlesbare Policy
+
+```js
+const {
+  classifyPolicyUrl,
+  normalizeManifest
+} = require('./security/manifest-import-policy');
+```
+
+Die Policy liegt unter:
+
+```text
+security/manifest-import-policy.js
+```
+
+## Lokale Gates
+
+```bash
+node scripts/verify_manifest_import_policy.js --json
+node scripts/run_xtend_tests.js manifest-import-policy --json
+npm run test:manifest-policy
+```
+
+Diese Checks sind offline und fragen keine externen Hosts ab.
+
+## Zusammenhang
+
+- [XTend Loader](./xtend-loader.md)
+- [Manifest-Format](./manifest.md)
+- [Trusted DOM und Sanitizing](./trusted-dom-sanitizing.md)
+- [Supply-Chain Gates](./supply-chain-gates.md)

package/docs/de/manifest.md

@@ -0,0 +1,112 @@
+# XTend Manifest
+
+## Übersicht
+
+Das XTend Manifest ist eine zentrale JSON-Datei, die alle verfügbaren XTend-Komponenten und deren Pfade definiert. Es dient als "Single Source of Truth" für den Loader und die API, um Komponenten dynamisch und modular zu laden.
+
+---
+
+## Speicherort & Name
+
+- Standardpfad: `components/manifest.json`
+- Der Pfad kann beim Initialisieren des Loaders angepasst werden.
+
+---
+
+## Struktur des Manifests
+
+Das Manifest ist ein einfaches JSON-Objekt. Die meisten Schlüssel entsprechen dem kanonischen Tag-Namen einer XTend-Komponente; zusätzlich gibt es reservierte Bootstrap-Keys wie `xstate`. Der Wert ist jeweils eine konkrete ES-Modul-Adresse.
+
+### Beispiel
+
+```json
+{
+  "xstate": "./xstate.js",
+  "x-theme": "./xtheme.js",
+  "x-button": "./xbutton.js",
+  "x-input": "./xinput.js",
+  "x-router": "./xrouter.js",
+  "x-link": "./xlink.js"
+}
+```
+
+### Konventionen
+- Custom-Element-Tags sind kanonisch **kleingeschrieben, hyphenated und beginnen mit `x`** (z.B. `x-button`, `x-input`, `x-router`).
+- Reservierte Bootstrap-Keys wie `xstate` sind zulässige Ausnahmen und werden nicht als DOM-Tag interpretiert.
+- Werte dürfen **relativ**, **root-relativ** oder **same-origin/loopback-lokal absolut** sein.
+- Der Loader löst relative Einträge relativ zur Manifest-URL auf.
+- Der Default-Manifestpfad bleibt repo-lokal; CDN-URLs sind kein Standard- oder Testpfad.
+- Seit `ER-WP-28` werden externe Manifest-/Modul-URLs, `javascript:`, `data:`, `blob:`, Path-Traversal und nicht-JavaScript-Module durch `xtend.security.manifest-policy.v1` und `xtend.security.import-policy.v1` verweigert.
+- Kommentare sind im JSON-Standard nicht erlaubt und im echten Manifest unzulässig.
+
+---
+
+## Pflicht- und optionale Einträge
+
+- **Pflicht:**
+  - `xstate` als Bootstrap-Basismodul
+- **Optional:**
+  - `x-theme` (Theme-Engine)
+  - Weitere eigene Komponenten
+
+---
+
+## Erweiterbarkeit
+
+- Das Manifest kann beliebig viele Komponenten enthalten.
+- Eigene Komponenten können einfach durch Hinzufügen weiterer Schlüssel/Werte ergänzt werden.
+- Für experimentelle oder Beta-Komponenten empfiehlt sich eine eigene Namenskonvention (z.B. `x-section-beta`).
+
+## Abgrenzung zu XTendRMT
+
+Das XTend Manifest beschreibt aufloesbare ES-Modul-Pfade fuer XTend-Komponenten. Es ist nicht dasselbe wie ein `.rmt` Dokument.
+
+| Datei/Format | Aufgabe |
+|--------------|---------|
+| `components/manifest.json` | XTend Loader und Component URL-Aufloesung |
+| `xtendrmt/rmt.schema.json` | Schema-Referenz fuer RMT-Dokumente |
+| `.rmt` | Native App-DSL mit `adapters`, `components`, `routes`, `schedules`, `templates` |
+| `xtendrmt/rmt-manifest.json` | XTendRMT Produktmanifest, Entry Points und Artefakt-Paritaet |
+
+RMT-Component-Records duerfen ein XTend Manifest fuer Manifest Lookup
+referenzieren, aber der RMT Kernel liest daraus keine XTend Runtime. Die
+Aufloesung gehoert in Host-Adapter und die RMT vNext Component Capability
+Registry. Sie nutzt das Manifest als Import-Quelle, verbindet es mit
+Component Contracts und RMT-Metadaten und erzeugt daraus Descriptor-
+Faehigkeiten fuer den DOM Descriptor Renderer.
+
+Native RMT-Dateien sollten mit `application/vnd.xtendrmt.rmt+json` ausgeliefert werden. Der JSON-Fallback bleibt fuer Sonderhosts moeglich, ist aber kein empfohlener Authoring-Pfad.
+
+---
+
+## Best Practices
+
+- Das Manifest ist die **Single Source of Truth** für auflösbare Komponenten-URLs.
+- Das Manifest sollte stets aktuell gehalten werden, um Dead Links und Ladefehler zu vermeiden.
+- Für die Produktion empfiehlt sich ein minimiertes Manifest ohne ungenutzte Komponenten.
+- `xstate` sollte immer explizit vorhanden sein; `x-theme` folgt direkt danach, wenn Theme-Funktionen genutzt werden.
+
+---
+
+## Validierung
+
+- Vor dem Laden prüft der Loader, ob das Manifest und alle Modul-URLs gültig sind.
+- Nicht-string Werte werden ignoriert.
+- Fehler beim Parsen oder Laden werden im Konsolen-Log ausgegeben.
+- Security Refusals erzeugen `xtend-loader-diagnostic` Events mit `xtend.security.loader.refused`, `xtend.security.manifest.invalid` oder `xtend.security.import.refused`.
+- Der lokale Gate lautet `node scripts/run_xtend_tests.js manifest-import-policy --json`.
+- Nach Core-Aenderungen kann `node scripts/verify_xtend_core_contracts.js` den Bootstrap-Contract gegen Manifest, API und Doku querpruefen.
+
+---
+
+## Weiterführende Themen
+- [XTend Loader](./xtend-loader.md)
+- [Manifest Import Policy](./manifest-import-policy.md)
+- [Komponenten-Entwicklung](./components.md)
+- [RMT vNext Component Primitives und XTend UI](./rmt-vnext-component-primitives.md)
+- [API-Integration](./api.md)
+- [XTendRMT App-DSL Reference](./xtendrmt-app-dsl.md)
+
+---
+
+*Letzte Aktualisierung: 22. Mai 2026*

package/docs/de/motion-contrast.md

@@ -0,0 +1,67 @@
+# Motion und Contrast
+
+- Contract: `xtend.docs.motion-contrast.v1`
+- Runtime-/Gate-Contract: `xtend.a11y.motion-contrast-policy.v1`
+- Motion Contract: `xtend.a11y.motion-policy.v1`
+- Contrast Contract: `xtend.a11y.contrast-policy.v1`
+- Gate: `node scripts/run_xtend_tests.js motion-contrast --json`
+
+## Zweck
+
+Motion und Contrast sind in XTend Bestandteil von A11y-by-design. Komponenten muessen reduzierte Bewegung, erzwungene Kontrastmodi, sichtbaren Fokus und Nicht-Farbstatus respektieren, ohne dass XTendRMT oder ein Host-Framework konkrete CSS-Details kennen muss.
+
+## Pflichtregeln
+
+| Bereich | Umsetzung |
+|---------|-----------|
+| Reduced Motion | `@media (prefers-reduced-motion: reduce)` deaktiviert nicht essentielle Animationen und Transitions |
+| High Contrast | `@media (forced-colors: active)` nutzt Systemfarben wie `CanvasText`, `ButtonText`, `Highlight`, `Mark` |
+| Fokus | `:focus-visible` bleibt sichtbar und verwendet im Forced-Colors-Pfad `Highlight` |
+| Status | Error, Warning, Busy und Active haben eine nicht nur farbliche Semantik |
+| Tokens | Theme Tokens duerfen Forced-Colors nicht ueberschreiben, wenn Systemfarben gebraucht werden |
+
+## Component Contract
+
+Relevante Komponenten deklarieren statisch:
+
+```js
+static get xtendMotionContrastPolicy() {
+  return {
+    schema: 'xtend.a11y.motion-contrast-policy.v1',
+    componentRef: 'x-component',
+    motion: {
+      schema: 'xtend.a11y.motion-policy.v1',
+      mediaQuery: '(prefers-reduced-motion: reduce)',
+      noMotionOnlyState: true
+    },
+    contrast: {
+      schema: 'xtend.a11y.contrast-policy.v1',
+      mediaQuery: '(forced-colors: active)',
+      focusVisible: 'required',
+      nonColorStatus: 'required'
+    }
+  };
+}
+```
+
+## Scaffold
+
+Neue Scaffold-Komponenten erhalten:
+
+- `motionContrast.policy` im A11y-Profil
+- Manifest-Key `motionContrastPolicy`
+- Docs-Abschnitt `Motion-und-Contrast-Policy`
+- Fixture-Felder `motionContrastPolicy`, `motionMediaQuery`, `contrastMediaQuery`
+- TypeScript-Type `X<Component>MotionContrastPolicy`
+
+## Fabric und RMT
+
+Preference-Signale nutzen die Fabric-Lane `a11y`, Fiber `a11y.preference` und Schedule `a11y.user-blocking.preference`. RMT bleibt framework-agnostisch und bekommt nur host-neutrale Schedule-/Diagnostic-Signale, keine CSS-Ausfuehrung.
+
+## Lokale Verifikation
+
+```bash
+npm run test:motion-contrast
+node scripts/run_xtend_tests.js motion-contrast --json
+node scripts/run_xtend_tests.js references --json
+```

package/docs/de/package-export-lock.md

@@ -0,0 +1,44 @@
+# Package Export Lock
+
+- Contract: `xtend.epic13.package-export-lock.v1`
+- Report: `xtend.epic13.package-export-lock-report.v1`
+- Surface: `xtend.epic13.package-export-surface.v1`
+- Dry-Run Artifact: `xtend.epic13.package-dry-run-artifact.v1`
+- Lokaler Gate: `node scripts/run_xtend_tests.js epic13-package-export-lock --json`
+
+Der Package Export Lock macht den RC1-Paketinhalt pruefbar. Der lokale Gate validiert `package.json#exports`, `files`, die erwarteten Package Roots und die Surface Groups ohne `npm pack` auszufuehren.
+
+## Surface Groups
+
+| Gruppe | Zweck |
+|--------|-------|
+| Loader | `xtend-loader.js`, Legacy Stub, API, CSS und Manifest |
+| Components | Manifest und Component-Dateien |
+| Fabric | Fabric Runtime, RMT Lane Mapping und Hydration Policy |
+| XTendRMT | ESM- und Browser-Runtime |
+| Builder | Scaffold CLI, Preview, Typing und Performance Contracts |
+| Docs | Docs-App, Markdown, Parsedown/RMT Shell und Referenzen |
+| Security | Manifest, Trusted DOM und Supply-Chain Policies |
+| Catalog | Gate-, Handoff- und Epic-Contracts |
+
+## Release Owner Artifact
+
+```bash
+npm run pack:dry-run:report
+```
+
+Das Script schreibt:
+
+- `.xtend-test-results/xtend-pack-dry-run.json`
+- `.xtend-test-results/xtend-package-export-surface-lock.json`
+- `.xtend-test-results/xtend-package-export-lock-report.json`
+
+`private-until-release-owner-acceptance` bleibt aktiv. Der Lock beweist nur, dass Paketinhalt und Export Surface kontrolliert sind; er oeffnet kein Publishing.
+
+## TypeExports Anschluss
+
+Ab `WP-TypeExports-01` nutzt [TypeExports](./type-exports.md) den Package Export Lock als Quelle fuer die Public Export Surface. Der Gate `node scripts/run_xtend_tests.js type-exports --json` koppelt die 121 erwarteten Exports ueber Count und Fingerprint an `xtend.epic13.package-export-lock.v1` und erzwingt fuer neue Public Exports eine Type-Entscheidung. Ab `WP-TypeExports-02` besitzen `.`, `./loader` und `./legacy-loader` die Type-Ziele `./xtend-loader.d.ts` und `./xtend-dev.d.ts`; `node scripts/run_xtend_tests.js type-exports-loader --json` prueft diesen Anschluss gegen die Loader-Runtime. Ab `WP-TypeExports-03` besitzt `./api` das Type-Ziel `./api.d.ts`; `node scripts/run_xtend_tests.js type-exports-api --json` prueft den Core-API-Namespace gegen `api.js`. Ab `WP-TypeExports-04` besitzen `./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`, `./rmt/native-shell-runtime`, `./rmt-language/app-platform-tooling` und die RMT-Language-/Tooling-Exports Type-Ziele wie `./xtendrmt/rmt-core.d.ts`, `./xtendrmt/rmt-dom-descriptor-renderer.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`, `./tools/rmt-language/app-platform-tooling.d.ts` und `./tools/rmt-language/rmt-tooling-public-types.d.ts`; `node scripts/run_xtend_tests.js type-exports-rmt --json` prueft diesen Anschluss gegen die RMT Runtime- und Tooling-Surface. Ab `WP-TypeExports-05` besitzen Fabric/A11y/Security Exports Type-Ziele wie `./fabric/xtend-fabric.d.ts` und `./fabric/xtend-policy-public-types.d.ts`; `node scripts/run_xtend_tests.js type-exports-policy --json` prueft diesen Anschluss gegen die Policy-Surface. Ab `WP-TypeExports-06` besitzen Builder-Exports Type-Ziele wie `./xtend-builder/scaffold.d.ts`, `./xtend-builder/builder-public-types.d.ts` und `./xtend-builder/*.d.ts`; `node scripts/run_xtend_tests.js type-exports-builder --json` prueft diesen Anschluss gegen Scaffold, Generatoren, Component Lab und Typing Contracts. Ab `WP-TypeExports-07` besitzen Catalog-Exports Type-Ziele wie `./catalog/epic13-package-export-lock.d.ts` und das gemeinsame `./catalog/catalog-public-types.d.ts`; `node scripts/run_xtend_tests.js type-exports-catalog --json` prueft diesen Anschluss gegen Plan-/Report-/Validation-Catalogs. Ab `WP-TypeExports-08` besitzen Design Tokens und Vendor-Facades Type-Ziele wie `./design-tokens/xtend-design-tokens.d.ts`, `./design-tokens/xtheme-token-alias-layer.d.ts`, `./components/prism.d.ts` und `./components/turndown.d.ts`; `node scripts/run_xtend_tests.js type-exports-vendor --json` prueft diesen Anschluss gegen die Utility-Grenzen. Ab `WP-TypeExports-09` buendelt `npm run test:type-exports:release` die TypeExports-Gates als Release-Handoff und schreibt `.xtend-test-results/xtend-type-exports-report.json`.
+
+## Handoff
+
+Nach `WP-E13-04` hat `WP-E13-05` die Known Residual Triage unter [Known Residual Triage](./known-residual-triage.md) mit `xtend.epic13.known-residual-triage.v1` abgeschlossen. `WP-E13-06` hat die [Hydration Performance Closure](./hydration-performance-closure.md) mit `xtend.epic13.hydration-performance-closure.v1` abgeschlossen. `WP-E13-07` hat die [PROD Browser CSP Smokes](./prod-browser-csp-smokes.md) vorbereitet, `WP-E13-08` hat [Visual Owner Artifacts](./visual-owner-artifacts.md) normalisiert, `WP-E13-09` hat [RMT Production Readiness](./rmt-production-readiness.md) gebuendelt, `WP-E13-10` hat [Docs RMT Production Hardening](./docs-rmt-production-hardening.md) abgeschlossen, `WP-E13-11` hat [Trusted DOM Boundary Browser Proof](./trusted-dom-boundary-browser-proof.md) abgeschlossen, `WP-E13-12` hat [RC1 Migration Notes](./rc1-migration-notes.md) abgeschlossen, `WP-E13-13` hat [RC1 Gate Matrix und CI-Handoff](./rc1-gate-matrix-ci-handoff.md) registriert, `DPF-WP-02` hat [Release Report und Pack Dry Run Evidence](./release-report-pack-dry-run-evidence.md) nachgezogen und `DPF-WP-03` hat [Conditional Network Evidence CI](./conditional-network-evidence-ci.md) nachgezogen. Der aktuelle Export Lock erwartet 124 Package-Exports inklusive `./design-tokens/xtheme-token-alias-layer`, `./catalog/epic13-rc1-migration-notes`, `./catalog/epic13-rc1-gate-matrix-ci-handoff`, `./catalog/epic13-release-report-pack-dry-run-evidence`, `./catalog/epic13-conditional-network-evidence-ci`, `./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`, `./rmt/native-shell-runtime`, `./rmt/node-ssr-adapter`, `./rmt-language/app-platform-tooling`, `./rmt-language/kernel-trust-authority`, `./rmt-language/kernel-security-regression`, `./catalog/epic14-rmt-tooling`, `./catalog/epic14-lsp-handoff` sowie der klassischen und vNext RMT-Tooling-Surface.

package/docs/de/performance-measurements.md

@@ -0,0 +1,106 @@
+# Performance Measurements
+
+XTend misst ab `ER-WP-18` Loader-, Hydration-, Render- und Route-Kernpfade lokal.
+
+Der stabile Measurement Contract lautet:
+
+```text
+xtend.performance.measurement.v1
+```
+
+## Messpunkte
+
+| Measure | Phase | Quelle |
+|---------|-------|--------|
+| `xtend.loader.manifest` | `load` | `xtend-loader.js` |
+| `xtend.loader.module` | `load` | `xtend-loader.js`, Fabric Fibers |
+| `xtend.component.define` | `define` | `xtend-loader.js` |
+| `xtend.component.mount` | `mount` | Fabric Fibers |
+| `xtend.component.hydrate` | `hydrate` | Fabric Fibers |
+| `xtend.component.render` | `render` | Fabric Fibers |
+| `xtend.component.update` | `update` | Fabric Fibers |
+| `xtend.event.handler` | `event` | Fabric Fibers |
+| `xtend.route.navigate` | `route` | Fabric Fibers |
+| `xtend.route.render` | `route` | Fabric Fibers |
+| `xtend.diagnostics.snapshot` | `diagnostics` | Fabric Fibers |
+
+## Loader
+
+Der Loader setzt `performance.mark` und `performance.measure` fuer:
+
+- Manifest laden und aufloesen
+- ESM-Modul laden
+- Custom Element Definition abwarten
+
+Zusätzlich emittiert er ein lokales Browser-Event:
+
+```js
+window.addEventListener('xtend-loader-performance', (event) => {
+  console.log(event.detail.name, event.detail.durationMs);
+});
+```
+
+Die automatische Boot-Promise enthaelt die Loader-Messwerte:
+
+```js
+const boot = await window.__XTendLoaderBootPromise;
+console.log(boot.performanceMeasurements);
+```
+
+## Fabric
+
+Fabric misst bekannte Fibers automatisch:
+
+```js
+const fabric = window.XTendFabric.createXtendFabric({
+  performance: window.performance
+});
+
+const component = fabric.createComponentFiberInstrumentation('x-alert');
+await component.hydrate(() => hydrateAlert());
+```
+
+Die Messung kann fuer Spezialtests deaktiviert werden:
+
+```js
+const fabric = window.XTendFabric.createXtendFabric({
+  markPerformance: false
+});
+```
+
+## Telemetry Snapshot
+
+`createTelemetrySnapshot()` liest `mark` und `measure` Eintraege mit Prefix `xtend.` und normalisiert sie:
+
+```js
+const snapshot = fabric.createTelemetrySnapshot({
+  performance: window.performance
+});
+
+console.log(snapshot.performance.measurements);
+console.log(snapshot.performance.phaseSummary.hydrate);
+```
+
+Die Snapshot-Sektion enthaelt:
+
+- `measurementSchema`
+- `measurementCount`
+- `measurements`
+- `phaseSummary`
+- `entries`
+- `totalDurationMs`
+- `maxDurationMs`
+
+## Gates
+
+```bash
+node scripts/run_xtend_tests.js fabric-performance-measurements --json
+npm run test:fabric-performance
+```
+
+Seit `ER-WP-19` nutzt [Performance Regression](./performance-regression.md) dieselben Measurements fuer lokale deterministische Baselines:
+
+```bash
+node scripts/run_xtend_tests.js performance-regression --json
+npm run test:performance
+```

package/docs/de/performance-regression.md

@@ -0,0 +1,89 @@
+# Performance Regression
+
+- Docs Contract: `xtend.docs.performance-regression.v1`
+- Gate Contract: `xtend.performance.regression-gate.v1`
+- Baseline Contract: `xtend.performance.regression-baseline.v1`
+- Report Schema: `xtend.performance.regression-report.v1`
+- Seit: `ER-WP-19`
+
+XTend misst Loader-, Hydration-, Render- und Route-Arbeit bereits als `xtend.performance.measurement.v1`. Das Performance Regression Gate wertet diese Measurements gegen lokale Baselines aus.
+
+## Lokaler Gate
+
+```bash
+node scripts/run_xtend_tests.js performance-regression
+npm run test:performance
+node scripts/run_xtend_tests.js performance-regression --json
+```
+
+Die Suite nutzt:
+
+- `tests/performance/performance_regression_suite.js`
+- `tests/performance/baselines/local-performance-baseline.json`
+- Fabric `createTelemetrySnapshot`
+- Budgetwerte aus `fabric/xtend-fabric.js` und `development/XTend-Performance-Budget-Matrix.md`
+
+## Statusmodell
+
+| Status | Bedingung | Wirkung |
+|--------|-----------|---------|
+| `pass` | `durationMs <= budgetMs` | keine Aktion |
+| `warn` | `durationMs <= budgetMs * 1.5` | sichtbar im Report |
+| `fail` | `durationMs > budgetMs * 1.5` | Suite schlaegt fehl |
+
+Warnungen sind Kalibrierungssignale. Harte `fail`-Eintraege sind Regressionen und erscheinen im Runner-Report unter `failures`. Seit `WP-E13-06` muss die lokale RC1-Baseline `warnCount === 0` melden; die fruehere Hydration-Warnung ist ueber [Hydration Performance Closure](./hydration-performance-closure.md) owner-frei geschlossen.
+
+## Baseline
+
+Die erste Baseline ist bewusst deterministisch und lokal:
+
+```text
+tests/performance/baselines/local-performance-baseline.json
+```
+
+Sie deckt mindestens diese Messpunkte ab:
+
+- `xtend.loader.manifest`
+- `xtend.loader.module`
+- `xtend.component.define`
+- `xtend.component.mount`
+- `xtend.component.hydrate`
+- `xtend.component.render`
+- `xtend.component.update`
+- `xtend.event.handler`
+- `xtend.route.navigate`
+- `xtend.route.render`
+- `xtend.diagnostics.snapshot`
+
+## JSON-Report
+
+Der eingebettete Regression-Report nutzt:
+
+```text
+xtend.performance.regression-report.v1
+```
+
+Wichtige Felder:
+
+- `measurementSchema`
+- `measurementCount`
+- `passCount`
+- `warnCount`
+- `failCount`
+- `warnings`
+- `failures`
+- `phaseSummary`
+
+`phaseSummary` macht sichtbar, welche Phase Budgetdruck erzeugt, ohne dass jede Komponente einen eigenen Browser-Test braucht.
+
+## Beziehung zu Measurements
+
+Das Regression Gate baut auf [Performance Measurements](./performance-measurements.md) auf. Es fuehrt keine zweite Messlogik ein, sondern nimmt Fabric Telemetry Snapshots als Quelle.
+
+## RC1 Closure
+
+`WP-E13-06` hat `xtend.component.hydrate` von `36ms / 32ms` auf `31ms / 32ms` kalibriert, ohne das Budget anzuheben. Die Failure-Fixture bleibt aktiv und belegt weiterhin, dass echte Budgetverletzungen hart fehlschlagen.
+
+## Handoff
+
+`ER-WP-20` nutzt diese Reports fuer Lazy/Idle/Visible Hydration Policies. `ER-WP-21` hat daraus die praktischen Regeln fuer Komponentenautoren in [Performance fuer Komponentenautoren](./performance.md) abgeleitet.

package/docs/de/performance.md

@@ -0,0 +1,94 @@
+# Performance fuer Komponentenautoren
+
+- Docs Contract: `xtend.docs.performance-authoring.v1`
+- Scaffold Policy: `xtend.scaffold.performance-policy.v1`
+- Component Profile Contract: `xtend.performance.component-profile.v1`
+- Budget Matrix: `xtend.performance.budget-matrix.v1`
+- Measurement Contract: `xtend.performance.measurement.v1`
+- Regression Gate: `xtend.performance.regression-gate.v1`
+- Hydration Policy: `xtend.fabric.hydration-policy.v1`
+- Seit: `ER-WP-21`
+
+Dieses Dokument uebersetzt die Performance-Budget-Matrix in konkrete Autorenregeln. Neue Komponenten sollen nicht erst nachtraeglich optimiert werden, sondern ihr Performance-Profil bereits im Scaffold, in der Component-Doku, in Fabric Measurements und im lokalen Regression Gate sichtbar machen.
+
+## Performance-Profil
+
+Jede neue Scaffold-Komponente erhaelt `xtendScaffoldPerformanceProfile` im Source, `performanceProfile` im Manifest-Patch-Plan und die Docs-Abschnitte `Performance-Profil` sowie `Performance-Regeln`. Diese Artefakte referenzieren dieselbe Policy `xtend.scaffold.performance-policy.v1`.
+
+| Profil | Lane | Budgetklasse | Hydration | Kritische Phasen |
+|--------|------|--------------|-----------|------------------|
+| `display` | `visible` | `interactive` | `visible` | load, mount, hydrate, render, update |
+| `interactive` | `user-blocking` | `critical` | `visible` | hydrate, render, update, event |
+| `overlay` | `user-blocking` | `critical` | `visible` | mount, hydrate, render, event |
+| `routing` | `transition` | `interactive` | `visible` | route navigate, route render, hydrate, event |
+| `form` | `user-blocking` | `critical` | `visible` | hydrate, update, event |
+| `media` | `visible` | `interactive` | `visible-or-idle` | mount, hydrate, render, event |
+| `stateful` | `user-blocking` | `critical` | `visible` | update, event, state sync |
+| `feedback` | `a11y` | `critical` | `visible` | render, update, event, announcement |
+| `theme` | `visible` | `interactive` | `visible` | render, update, theme apply |
+
+Komponenten mit mehreren Profilen verwenden die strengste Budgetklasse und die hoechstpriorisierte Lane. `feedback` darf eine eigene `a11y` Fiber nutzen; `media` darf nicht sichtbare Arbeit auf `idle` verschieben.
+
+## DOM-Regeln
+
+- DOM-Suchen muessen auf `this.shadowRoot`, den Host oder einen bekannten Container begrenzt sein.
+- `document.querySelectorAll` und globale DOM-Loops brauchen eine begruendete Ausnahme und ein Budget.
+- Statische Referenzen duerfen gecacht werden; dynamische Node-Listen duerfen nicht unkontrolliert wachsen.
+- Wiederholte Voll-Renderings sind nur fuer kleine, statische Komponenten akzeptabel. Groessere Komponenten muessen gezielt updaten.
+- `MutationObserver`, `ResizeObserver`, Timer und Subscriptions muessen in `disconnectedCallback` bereinigt werden.
+
+## Event-Regeln
+
+- `interactive`, `overlay` und `form` behandeln User Events als `critical`; der synchrone Handler-Zielwert ist 16 ms.
+- Handler duerfen keine synchronen Netzwerk-, Storage- oder grossen DOM-Scan-Arbeiten ausfuehren.
+- High-frequency Events wie `input`, `scroll`, `pointermove` und `resize` muessen gedrosselt, zusammengefasst oder auf `requestAnimationFrame` gelegt werden.
+- Event-Daten sollen in kanonischen State oder lokale Render-Caches ueberfuehrt werden; abgeleitete DOM-Arbeit erfolgt danach gebuendelt.
+
+## Shadow DOM
+
+- Styles sollten statisch bleiben. Wiederholtes Einfuegen identischer `<style>` Bloecke im Update-Pfad ist ein Review-Signal.
+- Wo moeglich werden CSS Custom Properties und Parts genutzt, damit Theme-Arbeit nicht ueber JS-Layout-Loops laeuft.
+- `slotchange` muss budgetiert sein und darf keine unbeschraenkten DOM-Scans ausloesen.
+- Shadow-DOM-Updates sollen kleine Teilbaeume austauschen, statt bei jeder State-Aenderung die gesamte Oberflaeche neu zu schreiben.
+
+## Layout und Animation
+
+- Layout-Reads passieren vor Layout-Writes. Gemischte Read/Write-Schleifen in derselben Sync-Phase sind verboten.
+- Animationen sollen `transform` und `opacity` bevorzugen und `prefers-reduced-motion` respektieren.
+- Messbare sichtbare Arbeit muss mit `componentRef`, `fiberId`, `lane`, `phase` und `durationMs` korrelierbar sein.
+- Nicht sichtbare Arbeit nutzt `idle`, `background` oder `diagnostics`; sie darf keine `user-blocking` Lane beanspruchen.
+
+## Hydration
+
+`visible` ist der Default fuer sichtbare UI. `idle` ist fuer nicht sofort benoetigte, aber bald erwartete Arbeit geeignet. `lazy` ist fuer Arbeit reserviert, die erst bei Bedarf oder Sichtbarkeit aktiviert wird. Nicht sichtbare Hydration darf nicht als `user-blocking` geplant werden.
+
+Die operative Policy steht in [Hydration Policies](./hydration-policies.md). Die Messpunkte und Gate-Auswertung stehen in [Performance Measurements](./performance-measurements.md) und [Performance Regression](./performance-regression.md).
+
+## Scaffold-Pflicht
+
+Neue Scaffold-Ausgaben muessen diese Daten sichtbar machen:
+
+- `performanceProfile`
+- `budgetClass`
+- `lane`
+- `hydrationPolicy`
+- `criticalMeasurements`
+- `idleOrBackgroundAllowed`
+- `requiresA11yFiber`
+
+Die Policy ist in `xtend-builder/scaffold.config.js` unter `performance` hinterlegt. Der Generator spiegelt sie in `xtend-builder/performance/component-performance-profile.js`, den Component-Templates und dem Manifest-Patch-Plan.
+
+## Gates
+
+```bash
+node scripts/run_xtend_tests.js fabric-performance-measurements --json
+node scripts/run_xtend_tests.js performance-regression --json
+node scripts/run_xtend_tests.js hydration-policy --json
+node scripts/run_xtend_tests.js references --json
+```
+
+`performance-regression` darf lokale Warnungen erzeugen, wenn ein deterministischer Fixture-Pfad sein Budget ueberschreitet. Harte Failures bleiben fuer priorisierte Kernpfade und dokumentierte Budgetverletzungen reserviert.
+
+## Handoff
+
+`ER-WP-25` ist abgeschlossen und verbindet Screenreader-Signale mit Performance-Fibers und der `a11y` Lane. `ER-WP-26` ist ebenfalls abgeschlossen: Reduced-Motion- und High-Contrast-Regeln nutzen dieselbe Profil-, Lane- und Gate-Sprache ueber `xtend.a11y.motion-contrast-policy.v1`.

package/docs/de/previews/README.md

@@ -0,0 +1,17 @@
+# XTend Scaffold Previews
+
+- Status: Scaffold-Preview-Konvention
+- Referenz-Gate: `node scripts/run_xtend_tests.js references`
+- Generator: `node xtend-builder/scaffold.js preview --tag x-example --profile display --feature state --json`
+
+## Zweck
+
+Dieses Verzeichnis ist fuer gescaffoldete Component-Preview-Plaene reserviert. Ein Preview-Plan ist eine lokale Markdown-Referenz, die generierte Component-Quellen, Docs, Fixture, Typen und Manifest-Patch-Ausgabe mit der Dokumentations- und Demo-Referenzregistrierung verbindet.
+
+## Mindestvertrag
+
+- Preview-Pfade folgen `docs/previews/<name>.preview.md`.
+- Preview-Plaene muessen in `development/XTend-Dokumentations-und-Demo-Referenzpfade.md` gelistet sein, bevor sie automatisierte Referenzen werden.
+- Preview-Plaene muessen repo-lokale Component-, Fixture- und Manifest-Pfade verwenden.
+- Externe Netzwerkabhaengigkeiten sind fuer automatisierte Scaffold-Previews nicht erlaubt.
+- Produktive Preview-Schreibvorgaenge bleiben review-first, bis ein spaeteres Paket einen Schreibmodus einfuehrt.

package/docs/de/prod-browser-csp-smokes.md

@@ -0,0 +1,40 @@
+# PROD Browser CSP Smokes
+
+- Contract: `xtend.epic13.prod-browser-csp-smoke.v1`
+- Fixture Contract: `xtend.epic13.prod-browser-csp-smoke-fixture.v1`
+- Report: `xtend.epic13.prod-browser-csp-smoke-report.v1`
+- Workpackage: `WP-E13-07`
+- Lokaler Gate: `node scripts/run_xtend_tests.js epic13-prod-browser-csp-smoke --json`
+- Dev Server: `npm run dev:local:csp`
+- Fixture: `tests/browser/fixtures/epic13-prod-csp-smoke.html`
+- Publish Boundary: `private-until-release-owner-acceptance`
+
+## Zweck
+
+Der PROD Browser CSP Smoke prueft den XTend-Loader unter einer PROD-aehnlichen Content Security Policy, ohne externe Netzwerke oder CDN-Fallbacks zu nutzen.
+
+Die Fixture nutzt:
+
+- eine `nonce` fuer alle Inline- und Loader-Skripte
+- ein same-origin Manifest unter `/tests/browser/fixtures/components/manifest.json`
+- den root-lokalen Loader `/xtend-loader.js`
+- keine `importmap`
+- keine `https://cdn.ccs-networks.de/xtend` Referenz
+- XState und XRouter als minimale Hydration-Linie
+
+## Lokale Nutzung
+
+```bash
+npm run test:epic13-prod-browser-csp-smoke
+npm run dev:local:csp
+```
+
+Der lokale Server setzt zusaetzlich zum CSP Meta der Fixture einen `content-security-policy` Header. Damit kann die HTML-Datei sowohl statisch als auch servernah geprueft werden.
+
+## Grenzen
+
+Dieser Smoke ist eine PROD-nahe Boot- und Policy-Vorbereitung. Die Trusted-DOM-Pruefung fuer Parsedown, RMT HTML-Fragmente und untrusted Content liegt seit `WP-E13-11` unter [Trusted DOM Boundary Browser Proof](./trusted-dom-boundary-browser-proof.md) und `xtend.epic13.trusted-dom-boundary.v1`.
+
+## Handoff
+
+`WP-E13-07` ist abgeschlossen. `WP-E13-08` hat [Visual Owner Artifacts](./visual-owner-artifacts.md) normalisiert. `WP-E13-09` ist ready und buendelt als naechstes die RMT-first App Production Readiness.