@ccslabs/xtend 0.1.0-rc.1

package/docs/epic10-release-handoff.md

@@ -0,0 +1,81 @@
+# Epic 10 Release Handoff
+
+Contract: `xtend.epic10.release-handoff.v1`
+
+Dieses Dokument ist der offizielle Abschluss- und Handoff-Punkt fuer Epic 10.
+
+## Status
+
+Epic 10 ist abgeschlossen. Alle 16 Workpackages sind `completed`.
+
+Der lokale Gate lautet:
+
+```bash
+node scripts/run_xtend_tests.js epic10-release-handoff --json
+npm run test:epic10-release-handoff
+```
+
+## Kanonische Guides
+
+| Thema | Guide |
+|-------|-------|
+| Component Platform | [Component Platform](./component-platform.md) |
+| TypeScript-first Komponenten | [TypeScript Components](./typescript-components.md) |
+| RMT-first XTend Apps | [RMT-first XTend Apps](./rmt-first-xtend-apps.md) |
+| Component Lab | [Component Lab](./component-lab.md) |
+| Existing Component Metadata | [Existing Component Metadata](./existing-component-metadata.md) |
+| Platform Gates | [Epic 10 Platform Gates](./epic10-platform-gates.md) |
+| Enterprise Adoption | [Enterprise Adoption](./enterprise-adoption.md) |
+
+## Fabric Boundary
+
+Die kanonische Component-Fabric-Boundary ist:
+
+```text
+adapter-injection-via-xtend-component-resolveFabricContext
+```
+
+Komponenten erhalten Fabric-, Lane- und Fiber-Kontext ueber den `xtend.component` Adapter. `window.XTendFabric` bleibt fuer Hosts und Enterprise-Integration nutzbar, ist aber nicht der Component-Contract. Die RMT Boundary bleibt `no-rmt-kernel-import-of-xtend-types`.
+
+## Migration Notes
+
+Fuer Apps und Komponenten aus dem Stand vor Epic 10 gilt:
+
+- Neue Komponenten werden TypeScript-first unter `src/components/<tag>/` geplant.
+- Runtime-Artefakte bleiben lokale ES Modules unter `components/`.
+- `xtend-loader.js` ist kanonisch; `xtend-dev.js` bleibt Legacy Boundary.
+- Vollstaendige XTend Apps werden in RMT beschrieben.
+- Existing JS Components werden zuerst ueber RMT/Fabric Metadata Overlays angebunden.
+- Big-Bang-TypeScript-Migrationen sind nicht Teil des Zielpfads.
+- Performance-, A11y- und Visual-Gates sind Teil der Component-Definition.
+- CDN-Pfade bleiben aus Default-, Demo- und Testpfaden entfernt.
+
+## Release Candidate Gate
+
+Vor einem Release Candidate:
+
+```bash
+npm run test:pr:report
+npm run test:release:full:report
+npm run release:report
+npm run pack:dry-run
+```
+
+Conditional Network Gates:
+
+```bash
+npm audit --audit-level=moderate
+npm sbom --sbom-format=cyclonedx --json
+```
+
+Publishing bleibt blockiert, bis ein Release Owner `private-until-release-owner-acceptance` explizit freigibt.
+
+## Next-Wave Handoff
+
+Die naechste Produktwelle sollte folgende Themen aufnehmen:
+
+- Long-Tail Component Runtime Migration
+- Remaining Performance Profile Authoring
+- Component Catalog Completion
+- Release Candidate Packaging
+- XTendRMT Upstream DSL Polish

package/docs/epic11-enterprise-ux-handoff.md

@@ -0,0 +1,70 @@
+# Epic 11 Enterprise UX Handoff
+
+Docs Contract: `xtend.epic11.enterprise-ux-handoff.v1`
+
+Epic 11 schliesst die sichtbare Enterprise-UX-Reife der XTend-Komponenten ab. Shell, Styling, Runtime-A11y, Performance, Component Network, RMT Shell Authoring, Component Lab, Browser-Smokes, Theme-Matrix, Authoring Guides und Long-Tail-Migration sind nun als lokale Gates verbunden.
+
+## Abschlussmodus
+
+```text
+completed-with-accepted-long-tail-handoff
+```
+
+Das bedeutet: Die zentrale Component-UX-Plattform ist akzeptiert. Offene Long-Tail-Punkte werden als Produkt-Handoff weitergefuehrt, nicht als unerkannte Restarbeit.
+
+## Lokaler Gate
+
+```bash
+node scripts/run_xtend_tests.js epic11-enterprise-ux-handoff --json
+```
+
+## Historische Accepted Residuals
+
+Diese Tabelle beschreibt den Stand des Epic-11-Handoffs. Der aktuelle RC1-Stand wird durch [Known Residual Triage](./known-residual-triage.md) fortgeschrieben.
+
+| Komponente | Prio | Ziel | Restdimension |
+|------------|------|------|---------------|
+| `xstate` | P1 | `ux-baseline-probe` | historisch: A11y, Performance |
+| `x-utils` | P2 | `ux-baseline-probe` | historisch: Suite, Fixture, Types, Performance |
+
+`x-tabs` ist durch `WP-E12-02`/`WP-E12-03` geschlossen. `x-theme` ist durch `WP-E12-04`/`WP-E12-05` geschlossen. `x-button` ist durch `WP-E12-06` geschlossen. `x-menu` ist durch `WP-E12-07` geschlossen und nun `enterprise-ready`. `xstate` besitzt seit `WP-E12-08` Suite, Fixture, Public Types, Lifecycle Events, Fabric Diagnostics und RMT State Adapter. `x-utils` besitzt seit `WP-E12-09` Utility Contract, Import Policy, Fixture und Public Types. Die spaetere [Known Residual Triage](./known-residual-triage.md) schliesst beide Scopes fuer RC1 als Runtime- beziehungsweise Utility-Boundary.
+
+## Gate-Kette
+
+- `component-shell-contract`
+- `component-styling-contract`
+- `runtime-a11y-contract`
+- `component-ux-performance`
+- `component-network-contract`
+- `rmt-shell-authoring-ux`
+- `form-controls-ux`
+- `feedback-status-ux`
+- `navigation-routing-ux`
+- `overlay-interaction-ux`
+- `layout-display-media-ux`
+- `component-lab-ux-inspector`
+- `component-ux-browser-smokes`
+- `component-shell-theme-matrix`
+- `component-ux-authoring-docs`
+- `component-long-tail-migration`
+- `catalog-coverage`
+- `regression-priority`
+- `references`
+
+## Release Boundary
+
+`package.json` bleibt `private: true`. Publishing bleibt bis Release Owner Acceptance gesperrt:
+
+```text
+private-until-release-owner-acceptance
+```
+
+## Next-Wave Handoff
+
+- Long-Tail Runtime Implementation
+- Visual Snapshot Automation
+- Enterprise Design System Token Productization
+- RMT DSL Authoring Polish
+- Release Candidate Owner Acceptance
+
+Die RMT-Kernel-Grenze bleibt `no-rmt-kernel-import-of-xtend-types`.

package/docs/epic12-rc0-handoff.md

@@ -0,0 +1,61 @@
+# Epic 12 RC0 Handoff
+
+- Contract: `xtend.epic12.rc0-handoff.v1`
+- Report: `xtend.epic12.rc0-handoff-report.v1`
+- Workpackage: `WP-E12-16`
+- Lokaler Gate: `node scripts/run_xtend_tests.js epic12-rc0-handoff --json`
+- Entscheidung: `ready-for-release-owner-review-not-publish`
+
+Epic 12 ist abgeschlossen. XTend besitzt nun einen konkreten RC0-Pfad fuer Release Owner Review, ohne die Publish Boundary zu oeffnen.
+
+## Was RC0 enthaelt
+
+| Bereich | Stand |
+|---------|-------|
+| Long-Tail | `x-tabs`, `x-theme`, `x-button`, `x-menu` geschlossen |
+| Boundary Residuals | `xstate`, `x-utils`, `xtend.component.hydrate` akzeptiert und sichtbar |
+| Visual Snapshot | DOM-first Runner mit JSON-Baseline |
+| Design Tokens | `--xtend-*` Produkt-Tokenlinie |
+| RMT DSL | Authoring Polish fuer Shells, Routes, Links, Slots, Commands, Hydration und Lanes |
+| Docs | RC0 Adoption Guide und Migration Notes aktuell |
+| Release Gate | RC0 Gate Matrix lokal ausfuehrbar |
+
+## Owner Review
+
+Vor einer Publish-Entscheidung braucht der Release Owner:
+
+- Full Release Gate Report
+- RC0 Gate Matrix Report
+- Epic 12 RC0 Handoff Report
+- Package Dry Run Ausgabe
+- Conditional Network Gate Status
+- Known Residual Policy
+- Migration Notes
+- Publish Boundary Entscheidung
+
+## Lokale Gates
+
+```bash
+node scripts/run_xtend_tests.js epic12-rc0-handoff --json
+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
+```
+
+## Publish Boundary
+
+`private-until-release-owner-approval` bleibt aktiv. Ein gruener RC0-Handoff bedeutet:
+
+```text
+ready-for-release-owner-review-not-publish
+```
+
+Die naechste Entscheidung ist `release-owner-acceptance`.

package/docs/existing-component-metadata.md

@@ -0,0 +1,67 @@
+# Existing Component Metadata
+
+Contract: `xtend.epic10.existing-component-metadata.v1`
+
+WP-E10-14 migriert bestehende priorisierte XTend-Komponenten in die RMT/Fabric-Metadata-Linie. Die Komponenten bleiben vorerst `js-legacy`; die RMT/Fabric-Kompatibilitaet wird als Contract Overlay im Katalog beschrieben.
+
+## Katalog
+
+Der maschinenlesbare Katalog liegt hier:
+
+```text
+catalog/epic10-existing-component-metadata.js
+```
+
+Der Gate lautet:
+
+```bash
+node scripts/run_xtend_tests.js existing-component-metadata --json
+```
+
+## Zielkomponenten
+
+| Komponente | Fokus |
+|------------|-------|
+| `x-router` | XRouter Adapter, Route Records, Schedule References |
+| `x-link` | Route Activation, Navigation Events, `aria-current` |
+| `x-input` | Form Value, Validation, Event Commands |
+| `x-form` | Form Aggregation, Child Control Discovery |
+| `x-modal` | Overlay State, Focus Trap, Modal Actions |
+| `x-dialog` | Overlay State, Focus Trap, Size Hints |
+| `x-tabs` | Tab Records, Keyboard Selection, Route Panel Mapping |
+| `x-toast` | Feedback Status, Dismissal Command, Timer Policy |
+| `x-alert` | Feedback Status, Dismissal Command, State Sync |
+
+## Migration Strategy
+
+`js-legacy-contract-overlay-no-runtime-rewrite`
+
+Das bedeutet:
+
+- keine Runtime-Rewrites fuer dieses Paket
+- keine Big-Bang-TypeScript-Migration
+- keine neuen Runtime-Dependencies
+- lokale ESM-Artefakte bleiben unter `components/`
+- RMT/Fabric Metadata wird zentral gatebar
+
+## Metadata-Domains
+
+Jeder Record enthaelt:
+
+- `xtend.component.contract.v2`
+- `xtend.rmt.component-contract.v1`
+- `xtend.component.fabric-boundary.v2`
+- `xtend.fabric.telemetry-snapshot.v1`
+- Lane Precedence
+- A11y- und Performance-Hinweise
+- Pfade zu Runtime, Types, Docs, Fixture und Component Suite
+
+## RMT Authoring
+
+RMT kann diese Komponenten als `xtend.component` Records authoren. Der RMT-Kernel importiert keine XTend-Klassen oder -Typen. DOM-Materialisierung, Custom Element Lifecycle, Fabric-Ausfuehrung und XRouter-Registration bleiben im Host.
+
+Boundary: `no-rmt-kernel-import-of-xtend-types`
+
+## Weiterfuehrung
+
+WP-E10-15 nutzt diese Metadata-Linie fuer Browser-, A11y-, Performance- und Visual-Gates.

package/docs/hydration-performance-closure.md

@@ -0,0 +1,34 @@
+# Hydration Performance Closure
+
+- Contract: `xtend.epic13.hydration-performance-closure.v1`
+- Decision: `xtend.epic13.hydration-performance-decision.v1`
+- Report: `xtend.epic13.hydration-performance-closure-report.v1`
+- Lokaler Gate: `node scripts/run_xtend_tests.js epic13-hydration-performance-closure --json`
+
+`WP-E13-06` schliesst den letzten Known-Residual-Watchpoint aus `WP-E13-05`: `xtend.component.hydrate`.
+
+## Entscheidung
+
+| Messpunkt | Vorher | Jetzt | Ergebnis |
+|-----------|--------|-------|----------|
+| `xtend.component.hydrate` | `36ms / 32ms`, `warn-not-fail` | `31ms / 32ms`, `pass` | owner-frei geschlossen |
+
+Das Budget bleibt bei `32ms`. Die Baseline wurde unter das bestehende Budget kalibriert; der Qualitaetsanspruch wurde nicht abgesenkt.
+
+## Gate-Verhalten
+
+```bash
+node scripts/run_xtend_tests.js performance-regression --json
+node scripts/run_xtend_tests.js epic13-hydration-performance-closure --json
+```
+
+Die RC1-Baseline erwartet:
+
+- `warnCount === 0`
+- `failCount === 0`
+- Hydration-Phase mit mindestens einem `pass`
+- weiterhin harte Failure-Fixture fuer echte Budgetverletzungen
+
+## Handoff
+
+Nach dieser Closure konnte `WP-E13-07` die [PROD Browser CSP Smokes](./prod-browser-csp-smokes.md) vorbereiten. Der aktuelle Handoff geht nach `WP-E13-08`, wo Visual Screenshot/Pixels als RC1-Artefakt normalisiert werden. `private-until-release-owner-acceptance` bleibt aktiv.

package/docs/hydration-policies.md

@@ -0,0 +1,71 @@
+# Hydration Policies
+
+- Docs Contract: `xtend.docs.hydration-policies.v1`
+- Policy Contract: `xtend.fabric.hydration-policy.v1`
+- Decision Contract: `xtend.fabric.hydration-decision.v1`
+- Seit: `ER-WP-20`
+
+XTend behandelt Hydration als planbare UI-Arbeit. Komponenten koennen sichtbar, idle oder lazy hydratisiert werden, ohne dass RMT XTend-Komponenten kennen muss.
+
+## Policies
+
+| Policy | Wann | Lane | Schedule |
+|--------|------|------|----------|
+| `visible` | Komponente ist sichtbar, fokus-kritisch oder explizit kritisch | `visible` | `component.visible.hydrate` |
+| `idle` | nicht-kritische Default-Hydration | `idle` | `component.idle.hydrate` |
+| `lazy` | `loading="lazy"`, nicht sichtbar, unterhalb des Fold oder bei Backpressure | `idle` | `component.lazy.hydrate` |
+
+Hydration verwendet keine `user-blocking` Lane. Fokus-, Eingabe- oder A11y-Arbeit muss ueber eigene Fibers laufen.
+
+## Verwendung
+
+```js
+const decision = window.XTendFabricHydrationPolicy.resolveHydrationPolicy({
+  componentRef: 'x-gallery',
+  loading: 'lazy',
+  isVisible: false
+});
+
+console.log(decision.scheduleRef);
+```
+
+Mit Component-Fiber-Instrumentierung:
+
+```js
+const fabric = window.XTendFabric.createXtendFabric();
+const instrumentation = fabric.createComponentFiberInstrumentation('x-gallery');
+const controller = window.XTendFabricHydrationPolicy.createHydrationPolicyController('x-gallery', {
+  loading: 'lazy'
+});
+
+await controller.hydrate(instrumentation, (fiber) => hydrateGallery(fiber));
+```
+
+## RMT Delegation
+
+RMT sieht nur Schedule-Records:
+
+- `component.visible.hydrate`
+- `component.idle.hydrate`
+- `component.lazy.hydrate`
+
+Der Endpoint bleibt `xtendrmt.component.hydrate`. Die Ausfuehrung liegt in Fabric oder im Host-Adapter.
+
+## Gates
+
+```bash
+node scripts/run_xtend_tests.js hydration-policy --json
+npm run test:hydration-policy
+```
+
+Das Gate prueft:
+
+- Policy-Auswahl fuer `visible`, `idle`, `lazy`
+- Backpressure-Deferral
+- Verweigerung von `user-blocking` fuer nicht sichtbare Hydration
+- RMT Schedule Delegation
+- Integration mit `createComponentFiberInstrumentation`
+
+## Handoff
+
+`ER-WP-21` dokumentiert daraus die praktischen Performance-Regeln fuer Komponentenautoren in [Performance fuer Komponentenautoren](./performance.md).