@ccslabs/xtend 0.1.0-rc.1

package/docs/known-residual-triage.md

@@ -0,0 +1,22 @@
+# Known Residual Triage
+
+- Contract: `xtend.epic13.known-residual-triage.v1`
+- Decision: `xtend.epic13.known-residual-decision.v1`
+- Report: `xtend.epic13.known-residual-triage-report.v1`
+- Lokaler Gate: `node scripts/run_xtend_tests.js epic13-known-residual-triage --json`
+
+`WP-E13-05` trennt die RC0 Known Residuals in echte RC1-Watchpoints und absichtlich nicht-visuelle Boundary-Contracts.
+
+## Entscheidungen
+
+| Scope | RC1-Entscheid | Bedeutung |
+|-------|---------------|-----------|
+| `xstate` | `closed-as-runtime-boundary` | State-Adapter mit Lifecycle-, RMT- und Diagnostics-Probe |
+| `x-utils` | `closed-as-utility-boundary` | Utility-Modul mit Typing, Fixture Probe und Import Policy |
+| `xtend.component.hydrate` | `closed-by-wp-e13-06-owner-free` | Performance-Warnung wurde owner-frei geschlossen |
+
+`private-until-release-owner-acceptance` bleibt aktiv. Die Triage oeffnet kein Publishing.
+
+## Handoff
+
+`WP-E13-06` hat `xtend.component.hydrate` owner-frei geschlossen. Details stehen in [Hydration Performance Closure](./hydration-performance-closure.md). `WP-E13-07` hat die [PROD Browser CSP Smokes](./prod-browser-csp-smokes.md) vorbereitet; `WP-E13-08` ist nun startbar.

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

@@ -0,0 +1,106 @@
+# 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 zum `createRmtXtendComponentAdapter`.
+
+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)
+- [API-Integration](./api.md)
+- [XTendRMT App-DSL Reference](./xtendrmt-app-dsl.md)
+
+---
+
+*Letzte Aktualisierung: 5. Mai 2026*