@ccslabs/xtend 0.1.0-rc.1

package/docs/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/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 115 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` und die RMT-Language-/Tooling-Exports Type-Ziele wie `./xtendrmt/rmt-core.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 115 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-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/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/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/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/previews/README.md

@@ -0,0 +1,17 @@
+# XTend Scaffold Previews
+
+- Status: scaffold preview convention
+- Reference gate: `node scripts/run_xtend_tests.js references`
+- Generator: `node xtend-builder/scaffold.js preview --tag x-example --profile display --feature state --json`
+
+## Purpose
+
+This directory is reserved for scaffolded component preview plans. A preview plan is a local Markdown reference that connects generated component source, docs, fixture, types and manifest patch output to the documentation and demo reference registry.
+
+## Minimum Contract
+
+- Preview paths follow `docs/previews/<name>.preview.md`.
+- Preview plans must be listed in `development/XTend-Dokumentations-und-Demo-Referenzpfade.md` before they become automated references.
+- Preview plans must use repo-local component, fixture and manifest paths.
+- External network dependencies are not allowed for automated scaffold previews.
+- Productive preview writes remain review-first until a later package introduces a write mode.

package/docs/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.

package/docs/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 42 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 `42/42`. `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-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.