@ccslabs/xtend 0.1.0-rc.1

package/docs/components/xwriter.md

@@ -0,0 +1,94 @@
+# xwriter – XTend Komponente
+
+> **Siehe auch:** [xcode](./xcode.md), [xinput](./xinput.md)
+
+## Übersicht
+
+`<x-writer>` ist eine Komponente für Rich-Text-Editing und einfache WYSIWYG-Editoren. Sie unterstützt Formatierungen, Theming, State-Integration, Autosave, Export und API-Anbindung.
+
+---
+
+## Features
+- Rich-Text-Editing (fett, kursiv, Listen, Links, Farben, Größen)
+- State-Integration via xstate
+- Theming via CSS Custom Properties
+- Autosave (lokal oder API)
+- Export als Markdown/HTML
+- Drag & Drop für Bilder/Text
+- API-Anbindung (Speichern an Server)
+
+---
+
+## Verwendung
+
+```html
+<x-writer></x-writer>
+```
+
+---
+
+## Attribute
+| Attribut      | Typ     | Beschreibung                                              |
+|-------------- |---------|----------------------------------------------------------|
+| `value`       | String  | Initialer Textinhalt (Property, nicht Attribut)          |
+| `api`         | String  | API-Endpunkt für Speichern (z.B. `/api/save` oder `local` für LocalStorage) |
+| `method`      | String  | HTTP-Methode für API (Standard: `POST`)                  |
+| `autosave`    | Number  | Intervall in ms für Autosave (z.B. `10000` für 10s)      |
+| `storage-key` | String  | Key für LocalStorage (Standard: `xwriter-content`)       |
+
+---
+
+## Events
+| Event             | Beschreibung                                              |
+|-------------------|----------------------------------------------------------|
+| `writer:change`   | Bei Textänderung ausgelöst, Detail: `{html, markdown, plain}` |
+| `writer:save`     | Nach Speichern (lokal/API), Detail: `{status, response}` |
+| `writer:autosave` | Nach Autosave                                            |
+| `writer:export`   | Nach Export, Detail: `{filename, success}`               |
+| `writer:error`    | Bei Fehlern, Detail: `{error}`                           |
+
+---
+
+## API
+- **Text setzen/lesen:** `element.value = 'Text'` (Property, nicht Attribut)
+- **State-Integration:** Automatisch via xstate
+- **Speichern:**
+  - Lokal: `<x-writer api="local"></x-writer>`
+  - API: `<x-writer api="/api/save" method="POST"></x-writer>`
+- **Export:** Über Export-Button (Markdown/HTML)
+
+## Form Controls UX ab WP-E11-08
+
+`<x-writer>` stellt `xtendFormControlUxProfile` mit `xtend.component.form-control-ux-profile.v1` bereit. Das Profil beschreibt Rich-Text als Form-Control-nahe UX-Flaeche mit `writer:change`, `writer:error`, `xwriter-content`, `component.idle.hydrate`, Fabric-Lane `idle` und RMT Shell Authoring. `x-form` kann `writer:change` aufnehmen und den Wert in `xform-data-<id>` aggregieren.
+
+---
+
+## Beispiel: Dynamisch per JS
+
+```js
+const writer = document.createElement('x-writer');
+writer.value = 'Hallo Welt!';
+document.body.appendChild(writer);
+```
+
+---
+
+## Styling & Theming
+
+```css
+x-writer {
+  --writer-bg: #fff;
+  --writer-color: #222;
+  /* Weitere Custom Properties siehe CSS */
+}
+```
+
+---
+
+## Accessibility
+- Semantisches HTML, ARIA
+- Tastaturbedienung
+
+---
+
+*Letzte Aktualisierung: 16. Juli 2025*

package/docs/components.md

@@ -0,0 +1,117 @@
+# Komponenten-Entwicklung mit XTend
+
+> **Hinweis:** Siehe auch: [xrouter](./components/xrouter.md), [xlink](./components/xlink.md)
+
+## Übersicht
+
+XTend-Komponenten sind eigenständige, wiederverwendbare Web Components, die als Custom Elements implementiert werden. Sie ermöglichen eine modulare, deklarative und performante Entwicklung moderner Webanwendungen.
+
+---
+
+## Grundprinzipien
+
+- Jede Komponente ist ein ES6-Modul (JavaScript-Datei) und wird per Manifest dynamisch geladen.
+- Komponenten verwenden das Custom Elements API (`customElements.define`).
+- Der Manifest-Key ist der kanonische Runtime-/Catalog-Name. Fuer Custom Elements ist er zugleich der Tag-Name, z.B. `x-button`, `x-input`, `x-summary`.
+- Source- und Docs-Slugs folgen im Bestand dem Modul-Basename ohne Bindestrich, z.B. `xbutton.js` mit `docs/components/xbutton.md` fuer Manifest-Key `x-button`.
+- Komponenten sind unabhängig, können aber andere XTend-Komponenten nutzen.
+
+### Naming-Konvention ab ER-WP-32
+
+| Ebene | Regel | Beispiel |
+|-------|-------|----------|
+| Manifest-Key | kanonischer Runtime- und Catalog-Name | `x-summary` |
+| Custom Element Tag | identisch zum Manifest-Key, wenn ein Custom Element registriert wird | `<x-summary>` |
+| Source-Datei | Modul-Basename aus dem Manifest-Pfad | `xsummary.js` |
+| Component-Doku | Source-Basename plus `.md` | `docs/components/xsummary.md` |
+| Docs-Menu-Slug | `components-` plus Source-Basename | `components-xsummary` |
+
+Ausnahmen bleiben explizit dokumentiert: `xstate` ist ein Plattform-State-Modul, `x-utils` ist ein Utility-Modul ohne Custom Element und `x-theme` ist ein Core-Theme-Modul mit Runtime-Fassade unter `window.XTend.theme`. Die vollstaendige Entscheidung liegt in `development/XTend-Component-Catalog-Naming-Konvention.md`.
+
+---
+
+## Struktur einer Komponente
+
+Typischerweise besteht eine Komponente aus:
+- **Klasse**: Erbt von `HTMLElement` oder einer anderen Web Component-Basis.
+- **Template**: HTML-Struktur, meist als Template-String oder Shadow DOM.
+- **Styles**: Inline, als CSS-String oder per Shadow DOM gekapselt.
+- **Registrierung**: Über `customElements.define('xname', XName)`.
+
+### Beispiel: Minimal-Komponente
+
+```js
+class XButton extends HTMLElement {
+  constructor() {
+    super();
+    this.attachShadow({ mode: 'open' });
+    this.shadowRoot.innerHTML = `
+      <button><slot></slot></button>
+      <style>button { padding: 8px; }</style>
+    `;
+  }
+}
+customElements.define('x-button', XButton);
+```
+
+---
+
+## Best Practices
+
+- **Kapselung:** Möglichst Shadow DOM nutzen, um Styles und Markup zu isolieren.
+- **Namenskonvention:** Manifest-Key und Custom-Element-Tag sind kanonisch; Source- und Docs-Slugs folgen dem Modul-Basename.
+- **Wiederverwendbarkeit:** Komponenten sollten unabhängig und konfigurierbar sein (Attribute, Properties, Events).
+- **Lazy Loading:** Komponenten werden nur geladen, wenn sie im DOM verwendet werden.
+- **Dokumentation:** Jede Komponente sollte eine eigene MD-Datei mit API, Attributen, Events und Beispielen erhalten.
+
+---
+
+## Erweiterte Features
+
+- **Attribute & Properties:** Überwache Attribute mit `static get observedAttributes()` und reagiere auf Änderungen.
+- **Events:** Verwende `this.dispatchEvent(new CustomEvent(...))` für Kommunikation.
+- **Slots:** Nutze `<slot>` für flexible Inhalte.
+- **Theming:** Nutze CSS Custom Properties für Anpassbarkeit.
+- **Ikonographie:** Nutze [`x-icon`](./components/xicon.md) als lokalen, RMT-kompatiblen Icon-Adapter fuer Core-Icons, lokale Lucide-Sets und Corporate-Design-Packs.
+
+---
+
+## Beispiel: Erweiterte Komponente
+
+```js
+class XInput extends HTMLElement {
+  static get observedAttributes() { return ['value']; }
+  constructor() {
+    super();
+    this.attachShadow({ mode: 'open' });
+    this.shadowRoot.innerHTML = `
+      <input type="text" />
+      <style>input { border: 1px solid #ccc; }</style>
+    `;
+  }
+  attributeChangedCallback(name, oldVal, newVal) {
+    if (name === 'value') {
+      this.shadowRoot.querySelector('input').value = newVal;
+    }
+  }
+}
+customElements.define('xinput', XInput);
+```
+
+---
+
+## Testen & Debugging
+
+- Komponenten können direkt im HTML getestet werden.
+- Nutze den lokalen Loader `xtend-loader.js` und den lokalen Dev-Server fuer Browser-Smokes und manuelle Tests.
+
+---
+
+## Weiterführende Themen
+- [Manifest-Format](./manifest.md)
+- [XTend Loader](./xtend-loader.md)
+- [API-Integration](./api.md)
+
+---
+
+*Letzte Aktualisierung: 16. Juli 2025*

package/docs/conditional-network-evidence-ci.md

@@ -0,0 +1,38 @@
+# Conditional Network Evidence CI
+
+Contract: `xtend.epic13.conditional-network-evidence-ci.v1`
+
+Status: `accepted-conditional-network-evidence-ci`
+
+Workpackage: `DPF-WP-03-conditional-network-evidence-ci`
+
+## Ziel
+
+Dieses Paket produktisiert Audit- und SBOM-Evidence fuer CI und Release Owner. Der lokale Gate bleibt netzwerkfrei; der CI-Job kann `npm audit --audit-level=moderate` und `npm sbom --sbom-format=cyclonedx --json` ausfuehren oder bei nicht verfuegbarem Netzwerk ein Owner-Deferral im Format `xtend.epic13.conditional-network-deferral.v1` schreiben.
+
+## Lokaler Gate
+
+```bash
+node scripts/run_xtend_tests.js epic13-conditional-network-evidence-ci --json
+npm run test:epic13-conditional-network-evidence-ci
+```
+
+## Capture
+
+```bash
+npm run conditional-network:evidence
+```
+
+Ohne `XTEND_CONDITIONAL_NETWORK_EXECUTE=1` schreibt der Capture lokale Deferral-Artefakte. In CI setzt `.github/workflows/xtend-default-gates.yml` `XTEND_CONDITIONAL_NETWORK_EXECUTE=1`, installiert Workspace-Links per `npm ci --ignore-scripts --no-audit --fund=false`, nutzt `XTEND_CONDITIONAL_NETWORK_USE_NPX_NPM10=1` fuer stabile SBOM-Ausgabe und laedt die Artefakte hoch:
+
+- `.xtend-test-results/xtend-npm-audit-report.json`
+- `.xtend-test-results/xtend-npm-sbom.json`
+- `.xtend-test-results/xtend-conditional-network-evidence-report.json`
+
+## Grenzen
+
+Nicht enthalten sind Dependency-Upgrades, Vulnerability-Fixes und Public Publish. Publish bleibt durch `private-until-release-owner-acceptance` blockiert, bis Audit/SBOM ausgefuehrt oder durch den Owner akzeptiert deferred sind.
+
+Der separate GitHub-Actions-Job `npm-publish-next` laeuft per `workflow_dispatch` mit `publish_to_npm=true` oder nach `release: published` und erlaubt keine Deferrals: Er setzt `XTEND_CONDITIONAL_NETWORK_ALLOW_DEFERRAL=0`, wiederholt `release:report`, Pack- und Audit/SBOM-Evidence und fuehrt danach `npm publish --tag next --provenance --access public` aus.
+
+Der naechste Schritt ist `DPF-WP-04-visual-pixel-evidence-storage`.

package/docs/conditional-network-evidence.md

@@ -0,0 +1,50 @@
+# Conditional Network Evidence
+
+`xtend.epic13.conditional-network-evidence.v1` beschreibt, wie RC1 mit Netzwerk-Gates umgeht, ohne lokale Entwicklung zu blockieren.
+
+Lokaler Gate:
+
+```bash
+node scripts/run_xtend_tests.js epic13-conditional-network-evidence --json
+```
+
+oder:
+
+```bash
+npm run test:epic13-conditional-network-evidence
+```
+
+## Commands
+
+| Command | Artefakt |
+|---------|----------|
+| `npm audit --audit-level=moderate` | `.xtend-test-results/xtend-npm-audit-report.json` |
+| `npm sbom --sbom-format=cyclonedx --json` | `.xtend-test-results/xtend-npm-sbom.json` |
+
+Der aggregierte Report liegt unter `.xtend-test-results/xtend-conditional-network-evidence-report.json`.
+
+## Lokales Verhalten
+
+Der lokale Gate fuehrt die Netzwerkbefehle nicht automatisch aus. Stattdessen prueft er, dass XTend fuer Offline-, Sandbox- und CI-Umgebungen ein stabiles Evidence-/Deferral-Format besitzt.
+
+Ab `DPF-WP-03` produktisiert [Conditional Network Evidence CI](./conditional-network-evidence-ci.md) den CI-Job und den Capture-Befehl `npm run conditional-network:evidence` unter `xtend.epic13.conditional-network-evidence-ci.v1`. Der Job kann die Audit-/SBOM-Kommandos ausfuehren oder Owner-Deferrals in denselben Artefaktpfaden ablegen.
+
+Default-Reason fuer lokale Deferrals:
+
+```text
+network-restricted-local-default
+```
+
+Weitere erlaubte Gruende:
+
+- `sandbox-network-unavailable`
+- `registry-auth-unavailable`
+- `owner-approved-offline-run`
+
+## Publish Boundary
+
+`private-until-release-owner-acceptance` bleibt aktiv. Deferred Network Evidence ist ein Review-Signal, aber keine Publish-Freigabe.
+
+`WP-E13-04` ist abgeschlossen. Der Package Export Lock beschreibt unter [Package Export Lock](./package-export-lock.md), wie `npm run pack:dry-run` und die Export Surface fuer RC1 gesperrt werden. `WP-E13-05` ist abgeschlossen; `WP-E13-06` hat die [Hydration Performance Closure](./hydration-performance-closure.md) 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` ist nun startbar.
+
+Weiterfuehrend: [Release Owner Acceptance](./release-owner-acceptance.md).

package/docs/core-migration-guide.md

@@ -0,0 +1,110 @@
+# XTend Core Migration Guide
+
+## Uebersicht
+
+Dieser Guide fasst die produktiven Core-Standards aus Epic 01 zusammen. Er dient als Migrationshilfe fuer Legacy-Call-Sites und als Referenz fuer neue XTend-Core-Aenderungen.
+
+## Verifikation
+
+Der aktuelle Core-Contract ist automatisiert pruefbar:
+
+```bash
+node scripts/verify_xtend_core_contracts.js
+```
+
+## Runtime-Standards
+
+- `window.XTend.compliance` stellt Checklist, Contract-Uebersicht und Theme-Tokens bereit.
+- zentrale Design-Tokens werden ueber `xtheme` pro Theme registriert und auf `document.documentElement` gespiegelt.
+- Overlay- und Feedback-Komponenten respektieren `prefers-reduced-motion`, Fokus-Standards und kanonische XTend-State-Keys.
+
+## RMT-Templating-Migration ab Epic 04
+
+RMT-Templating ist additiv und opt-in. Bestehende XTend-Apps, klassische HTML-/JS-Integrationen und bestehende Web-Component-Nutzung bleiben gueltig. Eine App nutzt XTendRMT erst, wenn sie ein `.rmt` Dokument, einen RMT Root-Handshake, einen Template-Record oder einen Host Adapter bewusst registriert.
+
+Die verbindliche Migrationsnotiz liegt in `development/XTendRMT-Migrations-und-Framework-Agnostik-Leitplanken.md`.
+Der aktuelle Produktueberblick liegt in `docs/xtendrmt-overview.md`. Das produktive native Authoring-Modell ab Epic 05 liegt in `docs/xtendrmt-native-authoring.md`; die App-DSL-Referenz liegt in `docs/xtendrmt-app-dsl.md`; Runtime Bridge und Adapter sind in `docs/xtendrmt-runtime-bridge.md` beschrieben. Die Migration von Metadatenpfaden zu Top-Level-Domains liegt in `docs/xtendrmt-migration-guide.md`.
+
+| Ausgangslage | Migrationspfad |
+|--------------|----------------|
+| XTend-only App | unveraendert weiter betreiben; RMT nur fuer neue Roots oder Template-Piloten aktivieren |
+| XTend mit XRouter | Route-Records vorbereiten, produktive Adapterausfuehrung in Epic 05 |
+| XTend neben React/Vue | RMT als Scheduler oder Template-Transport nutzen, Host Adapter getrennt halten |
+| Vanilla oder Custom Host | eigene Scheduler-Endpoints deklarieren, keine XTend-Capabilities voraussetzen |
+| Legacy-Demo | klassifizieren und pruefen, nicht stillschweigend zum RMT-Produktcontract machen |
+
+Review-Regeln fuer RMT-kompatible Aenderungen:
+
+- keine XTend Runtime-Imports im RMT Kernel
+- keine erzwungene Migration bestehender Apps
+- keine neue XTend-Template-Sprache neben RMT
+- `kernelVisible: false` fuer XTend-spezifische Adapterdaten
+- produktive Bridge-Factories statt privater Demo-Brueckenlogik verwenden
+- historische Scaffold-Artefakte mit `bridgeRuntime: reserved-for-Epic-05` bleiben als Epic-04-Handoff lesbar, sind aber nicht mehr der operative Bridge-Status
+- `node scripts/run_xtend_tests.js rmt-compatibility --json` und `node scripts/run_xtend_tests.js references --json` als Mindestgates
+
+## Native RMT Routes und Components ab Epic 05
+
+Neue App-DSL-Dokumente sollen operative Routing-, Component- und Scheduling-Daten in nativen Top-Level-Domains fuehren:
+
+- `manifest.metadata.routes -> routes`
+- `manifest.metadata.components -> components`
+- `manifest.metadata.schedules -> schedules`
+- `xtend.xrouter` bleibt Router Adapter
+- `xtend.component` bleibt Component Adapter
+- `rmt.state-scheduler-diagnostics` bleibt Bridge Adapter
+
+`manifest.metadata` bleibt fuer Beschreibung, Handoff und historische Demo-Notizen gueltig, soll aber keine neue operative Route-/Component-Bridge tragen. Template-only-Dokumente bleiben kompatibel.
+
+Die produktive Ausfuehrung nutzt:
+
+- `createRmtFormat().normalizeDocument(...)`
+- `createRmtFormat().createRuntimeRegistries(...)`
+- `createRmtXRouterAdapter(...)`
+- `createRmtXtendComponentAdapter(...)`
+- `createRmtStateSchedulerDiagnosticsBridge(...)`
+
+Die Docs-App selbst bleibt Parsedown-basiert, rendert ihre App Shell aber inzwischen Shell-first aus RMT. Der Scheduling- und Shell-Pfad ist seit `ER-WP-40` in `docs/xtendrmt-parsedown-scheduling.md` und `docs/xtendrmt-parsedown-docs.rmt` als offizieller Pilot beschrieben.
+
+## Legacy zu kanonisch
+
+| Bereich | Legacy | Kanonisch | Status |
+|--------|--------|-----------|--------|
+| Dialog Open | `dialog-open-<id>` | `xtend.component.x-dialog.<id>.open` | Legacy bleibt kompatibel |
+| Dialog Open | `xdialog-open-<id>` | `xtend.component.x-dialog.<id>.open` | Legacy bleibt kompatibel |
+| Modal Open | `modal-open-<id>` | `xtend.component.x-modal.<id>.open` | Legacy bleibt kompatibel |
+| Theme Current | `theme` | `xtend.theme.current` | beide werden gespiegelt |
+| Theme List | `themes` | `xtend.theme.available` | beide werden gespiegelt |
+| Router Last Navigation | `router-navigated` | `xtend.router.lastNavigated` | beide werden gespiegelt |
+| Alert State | `xalert-state-<id>` | `xtend.component.x-alert.<id>` | Legacy bleibt kompatibel |
+
+## Was neue Core-Aenderungen beachten muessen
+
+- neue UI-Flows brauchen einen expliziten `xstate`-Zwilling
+- Doku, API, Typdefinitionen und Runtime muessen denselben Contract verwenden
+- neue Komponenten oder groessere Core-Aenderungen muessen gegen die Compliance-Checklist und den Verify-Script laufen
+
+## Design-Tokens
+
+Die zentralen Tokens kommen aus `xtheme` und koennen pro Theme angepasst werden:
+
+- `--xtend-color-primary`
+- `--xtend-color-primary-dark`
+- `--xtend-color-accent`
+- `--xtend-glass-bg`
+- `--xtend-glass-blur`
+- `--xtend-shadow`
+- `--xtend-border`
+- `--xtend-radius`
+- `--xtend-font-family`
+- `--xtend-focus-outline`
+- `--xtend-surface`
+- `--xtend-surface-muted`
+- `--xtend-text`
+- `--xtend-overlay-bg`
+
+## Hinweise fuer bestehende Integrationen
+
+- Bestehende Legacy-Open-Flags fuer Dialog und Modal muessen nicht sofort entfernt werden, sollten aber nicht mehr neu eingefuehrt werden.
+- Neue API-nahe Integrationen sollen `window.XTend.*` statt unnamespaced Helpern bevorzugen.
+- Fuer Core-Reviews ist die Checkliste in `development/XTend-Core-Compliance-Checklist.md` die operative Quelle.

package/docs/design-tokens.md

@@ -0,0 +1,116 @@
+# Design Tokens
+
+XTend nutzt ab `WP-E12-12` den Contract `xtend.design-tokens.product-contract.v1`. Damit sind zentrale Theme-, Density-, Motion-, Focus- und Statuswerte eine stabile Produkt-API, nicht nur interne CSS-Hilfswerte.
+
+Lokaler Gate:
+
+```bash
+node scripts/run_xtend_tests.js design-tokens --json
+npm run test:design-tokens
+```
+
+## Runtime Provider
+
+`x-theme` ist der Runtime Provider. Apps koennen Tokens ueber Theme Packs registrieren:
+
+```js
+window.XTend.theme.registerTheme('enterprise-light', {
+  '--xtend-color-primary': '#2563eb',
+  '--xtend-surface': '#ffffff',
+  '--xtend-text': '#111827',
+  '--xtend-density-spacing': '0.75rem'
+});
+```
+
+Die vollstaendige Beispielbasis liegt in `design-tokens/themes/enterprise-light.json`.
+
+## Produkt-Tokens
+
+Wichtige Custom Properties:
+
+| Token | Zweck |
+|-------|-------|
+| `--xtend-color-primary` | interaktive Primaerfarbe |
+| `--xtend-color-primary-dark` | Hover-/Active-Variante |
+| `--xtend-color-accent` | Akzent oder inverse Vordergrundfarbe |
+| `--xtend-surface` | Standardflaeche |
+| `--xtend-surface-muted` | sekundare Flaeche |
+| `--xtend-text` | Standardtext |
+| `--xtend-overlay-bg` | Overlay-Hintergrund |
+| `--xtend-border-color` | semantische Borderfarbe |
+| `--xtend-focus-outline` | Keyboard-Fokus |
+| `--xtend-focus-outline-offset` | Fokus-Abstand |
+| `--xtend-info-bg` / `--xtend-info-fg` | Info-Status |
+| `--xtend-success-bg` / `--xtend-success-fg` | Success-Status |
+| `--xtend-warning-bg` / `--xtend-warning-fg` | Warning-Status |
+| `--xtend-error-bg` / `--xtend-error-fg` | Error-Status |
+| `--xtend-shadow` | Elevation |
+| `--xtend-radius` | Standardradius |
+| `--xtend-font-family` | Schriftfamilie |
+| `--xtend-motion-duration-fast` | schnelle Transition |
+| `--xtend-motion-duration-base` | Basis-Transition |
+| `--xtend-motion-scale` | Motion-Skalierung |
+| `--xtend-density-spacing` | Density-Abstand |
+| `--xtend-control-height` | Density-Control-Hoehe |
+| `--xtend-font-scale` | Density-Schrift-Skalierung |
+
+## Theme Packs
+
+Pflicht-Packs:
+
+- `light`
+- `dark`
+- `high-contrast`
+- `forced-colors`
+
+`high-contrast` und `forced-colors` sind Teil des Produktvertrags. `forced-colors` nutzt Systemfarben wie `Canvas`, `CanvasText`, `Highlight` und `HighlightText`.
+
+## Density Packs
+
+Pflicht-Packs:
+
+- `comfortable`
+- `compact`
+- `dense`
+
+`x-theme.setDensity('dense')` setzt `--xtend-density-spacing`, `--xtend-density-scale`, `--xtend-control-height` und `--xtend-font-scale`. `spacious` ist nicht mehr Teil der Enterprise-Token-Linie.
+
+## CSS Parts
+
+Die Token-Schicht ergaenzt den Component Styling Contract. Komponenten dokumentieren weiterhin ihre eigenen `::part(...)` Oberflaechen. Gemeinsame Public Parts sind:
+
+- `root`
+- `control`
+- `label`
+- `content`
+- `helper`
+- `error`
+- `icon`
+- `panel`
+- `overlay`
+- `backdrop`
+- `listbox`
+- `option`
+- `track`
+- `thumb`
+- `media`
+
+## RMT Authoring
+
+RMT kann Theme Packs, Density Packs und Style-Daten schedulen oder deklarieren. Der Kernel importiert keine XTend-Typen; die Boundary bleibt `no-rmt-kernel-import-of-xtend-types`.
+
+Die Component Shell Theme Matrix und Visual Snapshot Fixture nutzen dieselben `--xtend-*` Tokens wie `x-theme`. Dadurch koennen XTend Apps spaeter komplett RMT-first templated werden, ohne ein zweites Token-Vokabular mitzuschleppen.
+
+## RC0 Adoption Update
+
+Seit `WP-E12-15` verweist der [RC0 Adoption Guide](./rc0-adoption-guide.md) auf Design Tokens als verpflichtende Styling-Baseline fuer neue Komponenten und RMT-Shells. Token- oder CSS-Part-Aenderungen gelten als Public-API-Aenderungen und brauchen Migration Notes im RC0-Handoff.
+
+## ECH-WP-11 Drittanbieter Design Authoring Update
+
+Der Guide [Drittanbieter Design Authoring](./third-party-design-authoring.md) uebersetzt die Token-Schicht in einen Corporate-Design-Pfad fuer Host-Apps. Er beschreibt XTend.css Override Patterns, XTheme Token Bridge, CSS Parts, Icon Pack Registrierung, Layout Modes, A11y-Dos and Donts, P0 Token-/Part-Referenzen und Migration von Legacy Token-Namen.
+
+Lokaler Gate:
+
+```bash
+node scripts/run_xtend_tests.js enterprise-third-party-authoring-guide --json
+```

package/docs/docs-rmt-production-hardening.md

@@ -0,0 +1,31 @@
+# Docs RMT Production Hardening
+
+`WP-E13-10` hebt den bisherigen Docs-App Parsedown/RMT-Pilot auf einen PROD-naeheren RC1-Schnitt.
+
+- Contract: `xtend.epic13.docs-rmt-production-hardening.v1`
+- RMT-Dokument: `docs/xtendrmt-parsedown-docs.rmt`
+- Host: `docs/index.php`
+- Page Loader: `docs/utils/pageloader.js`
+- Gate: `node scripts/run_xtend_tests.js epic13-docs-rmt-production-hardening --json`
+- Trusted DOM Proof: `xtend.epic13.trusted-dom-boundary.v1`
+
+## Zweck
+
+Die Docs-App bleibt eine XTend-App mit PHP/Parsedown als Parser-Host. RMT rendert Shell-first die App Shell, markiert stabile Slots und scheduled Erweiterungen. Parsedown, PHP-Ausfuehrung und Sanitizing bleiben ausserhalb des RMT-Kernels.
+
+## Extension Slots
+
+| Slot | Content Kind | Schedule | Boundary |
+|------|--------------|----------|----------|
+| `docs.slot.content` | `parsedownHtml` | `docs.markdown.parse` | `xtend.security.sanitizing-boundary.v1` |
+| `docs.slot.rich-content` | `richHtml` | `docs.rich-content.prepare` | `xtend.security.sanitizing-boundary.v1` |
+| `docs.slot.media` | `xplayerTutorial` | `docs.media.lazy` | component-managed |
+| `docs.slot.diagnostics` | `diagnostics` | `docs.diagnostics.snapshot` | structured-diagnostics |
+
+## Runtime Metadata
+
+`docs/index.php` stellt `window.xtendDocsRmtProductionHardening` bereit. `docs/utils/pageloader.js` spiegelt pro Route `window.xtendDocsRmtProductionLastRender` mit Shell-first-Status, Extension-Slots, Schedules, Diagnostics-Slot und Kernel-Boundary.
+
+## Handoff
+
+`WP-E13-10` ist abgeschlossen. `WP-E13-11` hat Trusted DOM, Parsedown und RMT HTML Boundary browsernah unter [Trusted DOM Boundary Browser Proof](./trusted-dom-boundary-browser-proof.md) geprueft. `WP-E13-12` hat [RC1 Migration Notes](./rc1-migration-notes.md) und `xtend.epic13.rc1-migration-notes-semver.v1` abgeschlossen. `WP-E13-13` hat [RC1 Gate Matrix und CI-Handoff](./rc1-gate-matrix-ci-handoff.md) und `xtend.epic13.rc1-gate-matrix-ci-handoff.v1` abgeschlossen.