@ccslabs/xtend 0.1.0-rc.1 → 0.1.2

package/docs/en/epic18-rmt-app-platform-release-handoff.md

@@ -0,0 +1,60 @@
+# Epic 18 RMT App Platform Release Handoff
+
+Schema: `xtend.epic18.rmt-app-platform-release-handoff.v1`
+
+WP-E18-13 closes Epic 18 as a release-close handoff. The vendor bugfixes are documented, the RMT App Platform has a generic fixture, and the GitHub gates run through the existing CI commands.
+
+## Local Gate
+
+```bash
+node scripts/run_xtend_tests.js epic18-rmt-app-platform --json
+```
+
+Package script:
+
+```bash
+npm run test:epic18-rmt-app-platform
+```
+
+## Gate Matrix
+
+Bugfix line:
+
+```bash
+node scripts/run_xtend_tests.js components surface-controller surface-manager-browser overlay-interaction-ux layout-display-media-ux epic18-vendor-bugfix-smokes browser references --json
+```
+
+RMT App Platform line:
+
+```bash
+node scripts/run_xtend_tests.js rmt-app-platform-authoring rmt-dom-descriptor-renderer rmt-component-template-primitives rmt-state-selector-runtime rmt-action-effect-runtime rmt-event-routing-runtime rmt-surface-resource-graph-runtime rmt-app-platform-tooling rmt-app-platform-fixture rmt-vnext-compiler rmt-vnext-events rmt-vnext-surfaces rmt-vnext-security rmt-first-demo-app scaffold-rmt-build --json
+```
+
+Export and pack evidence:
+
+```bash
+node scripts/run_xtend_tests.js type-exports-rmt type-exports epic13-package-export-lock --json
+npm run pack:dry-run
+```
+
+GitHub Actions:
+
+```bash
+npm run test:pr:report
+npm run test:release:full:report
+```
+
+`.github/workflows/xtend-default-gates.yml` uses these commands for pull requests, pushes, manual runs and nightly runs. `epic18-rmt-app-platform` is part of the PR fast gate; the full release gate continues to run through all registered suites.
+
+## Release Boundary
+
+The handoff makes Epic 18 commit-ready and CI-ready, but does not open a publish path. Public publish remains bound to release-owner acceptance, supply-chain evidence and the existing RC/release checklist.
+
+## Artifacts
+
+- `docs/epic18-vendor-bugfixes.md`
+- `docs/rmt-app-platform-migration-guide.md`
+- `docs/rmt-app-platform-fixture.md`
+- `catalog/epic18-rmt-app-platform-release-handoff.js`
+- `tests/platform/epic18_rmt_app_platform_release_handoff_suite.js`
+- `development/WP-E18-13-Docs-Migration-Guide-Vendor-Rebuild-und-Release-Handoff.md`

package/docs/en/epic18-vendor-bugfixes.md

@@ -0,0 +1,29 @@
+# Epic 18 Vendor Bugfixes
+
+This page documents the component fixes that were brought back from the Media Manager vendor version into XTend main. It is intentionally not a product guide for a specific app, but a bugfix and compatibility reference for XTend components.
+
+## Components
+
+| Component | Behavior |
+|-----------|----------|
+| `x-tooltip` | Uses a viewport-fixed overlay layer, writes position values through `--xtooltip-left` and `--xtooltip-top`, and remains within the visible area after scroll or container shifts. |
+| `x-player` | Registers custom events only once, stays bounded inside surface containers and uses canonical `xplayer-*` events for play, pause, fullscreen, PIP, captions and mute. |
+| `x-surface-window` | Keeps long titles, scrollbars and resize limits stable without redrawing the SurfaceManager registry. |
+| `x-side-panel` | Keeps placement and icon controls stable and compatible with the SurfaceManager layout gates. |
+| `x-surface-manager-controller` | Provides generic surface types for window, side panel, modal, dialog, drawer, popover and tooltip. |
+
+## Gates
+
+The local bugfix gate remains:
+
+```bash
+node scripts/run_xtend_tests.js components surface-controller surface-manager-browser overlay-interaction-ux layout-display-media-ux epic18-vendor-bugfix-smokes browser references --json
+```
+
+The browser-close smoke is located at
+`tests/browser/fixtures/epic18-vendor-bugfix-smoke.html`; the contract gate is in
+`tests/components/epic18_vendor_bugfix_smoke_suite.js`.
+
+## Handoff
+
+The fixes are platform behavior. They must not remain in XTend as Media Manager-specific paths. New apps should use the generic component, surface, event and RMT app-platform contracts.

package/docs/en/existing-component-metadata.md

@@ -0,0 +1,67 @@
+# Existing Component Metadata
+
+Contract: `xtend.epic10.existing-component-metadata.v1`
+
+WP-E10-14 migrates existing prioritized XTend components into the RMT/Fabric metadata line. The components remain `js-legacy` for now; RMT/Fabric compatibility is described as a contract overlay in the catalog.
+
+## Catalog
+
+The machine-readable catalog is here:
+
+```text
+catalog/epic10-existing-component-metadata.js
+```
+
+The gate is:
+
+```bash
+node scripts/run_xtend_tests.js existing-component-metadata --json
+```
+
+## Target Components
+
+| Component | Focus |
+|-----------|-------|
+| `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`
+
+This means:
+
+- no runtime rewrites for this package
+- no big-bang TypeScript migration
+- no new runtime dependencies
+- local ESM artifacts remain under `components/`
+- RMT/Fabric metadata becomes centrally gateable
+
+## Metadata Domains
+
+Every record contains:
+
+- `xtend.component.contract.v2`
+- `xtend.rmt.component-contract.v1`
+- `xtend.component.fabric-boundary.v2`
+- `xtend.fabric.telemetry-snapshot.v1`
+- lane precedence
+- a11y and performance notes
+- paths to runtime, types, docs, fixture and component suite
+
+## RMT Authoring
+
+RMT can author these components as `xtend.component` records. The RMT kernel imports no XTend classes or types. DOM materialization, custom element lifecycle, Fabric execution and XRouter registration remain in the host.
+
+Boundary: `no-rmt-kernel-import-of-xtend-types`
+
+## Continuation
+
+WP-E10-15 uses this metadata line for browser, a11y, performance and visual gates.

package/docs/en/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`
+- Local gate: `node scripts/run_xtend_tests.js epic13-hydration-performance-closure --json`
+
+`WP-E13-06` closes the last known-residual watchpoint from `WP-E13-05`: `xtend.component.hydrate`.
+
+## Decision
+
+| Measurement point | Before | Now | Result |
+|-------------------|--------|-----|--------|
+| `xtend.component.hydrate` | `36ms / 32ms`, `warn-not-fail` | `31ms / 32ms`, `pass` | closed without owner dependency |
+
+The budget remains `32ms`. The baseline was calibrated below the existing budget; the quality bar was not lowered.
+
+## Gate Behavior
+
+```bash
+node scripts/run_xtend_tests.js performance-regression --json
+node scripts/run_xtend_tests.js epic13-hydration-performance-closure --json
+```
+
+The RC1 baseline expects:
+
+- `warnCount === 0`
+- `failCount === 0`
+- hydration phase with at least one `pass`
+- continued hard failure fixture for real budget violations
+
+## Handoff
+
+After this closure, `WP-E13-07` could prepare the [PROD Browser CSP Smokes](./prod-browser-csp-smokes.md). The current handoff goes to `WP-E13-08`, where visual screenshot/pixels are normalized as an RC1 artifact. `private-until-release-owner-acceptance` remains active.

package/docs/en/hydration-policies.md

@@ -0,0 +1,75 @@
+# Hydration Policies
+
+- Docs Contract: `xtend.docs.hydration-policies.v1`
+- Policy Contract: `xtend.fabric.hydration-policy.v1`
+- Decision Contract: `xtend.fabric.hydration-decision.v1`
+- Since: `ER-WP-20`
+
+XTend treats hydration as schedulable UI work. Components can hydrate as
+visible, idle, or lazy work without RMT needing to know XTend components.
+
+## Policies
+
+| Policy | When | Lane | Schedule |
+|--------|------|------|----------|
+| `visible` | component is visible, focus-critical, or explicitly critical | `visible` | `component.visible.hydrate` |
+| `idle` | non-critical default hydration | `idle` | `component.idle.hydrate` |
+| `lazy` | `loading="lazy"`, not visible, below the fold, or under backpressure | `idle` | `component.lazy.hydrate` |
+
+Hydration does not use the `user-blocking` lane. Focus, input, or a11y work
+must run through dedicated fibers.
+
+## Usage
+
+```js
+const decision = window.XTendFabricHydrationPolicy.resolveHydrationPolicy({
+  componentRef: 'x-gallery',
+  loading: 'lazy',
+  isVisible: false
+});
+
+console.log(decision.scheduleRef);
+```
+
+With component fiber instrumentation:
+
+```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 sees only schedule records:
+
+- `component.visible.hydrate`
+- `component.idle.hydrate`
+- `component.lazy.hydrate`
+
+The endpoint remains `xtendrmt.component.hydrate`. Execution belongs to Fabric
+or the host adapter.
+
+## Gates
+
+```bash
+node scripts/run_xtend_tests.js hydration-policy --json
+npm run test:hydration-policy
+```
+
+The gate checks:
+
+- policy selection for `visible`, `idle`, and `lazy`
+- backpressure deferral
+- refusal of `user-blocking` for non-visible hydration
+- RMT schedule delegation
+- integration with `createComponentFiberInstrumentation`
+
+## Handoff
+
+`ER-WP-21` turns this into practical performance rules for component authors in
+[Performance for Component Authors](./performance.md).

package/docs/en/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`
+- Local gate: `node scripts/run_xtend_tests.js epic13-known-residual-triage --json`
+
+`WP-E13-05` separates the RC0 known residuals into real RC1 watchpoints and intentionally non-visual boundary contracts.
+
+## Decisions
+
+| Scope | RC1 decision | Meaning |
+|-------|--------------|---------|
+| `xstate` | `closed-as-runtime-boundary` | State adapter with lifecycle, RMT and diagnostics probe |
+| `x-utils` | `closed-as-utility-boundary` | Utility module with typing, fixture probe and import policy |
+| `xtend.component.hydrate` | `closed-by-wp-e13-06-owner-free` | Performance warning was closed without an owner dependency |
+
+`private-until-release-owner-acceptance` remains active. The triage does not open publishing.
+
+## Handoff
+
+`WP-E13-06` closed `xtend.component.hydrate` without an owner dependency. Details are in [Hydration Performance Closure](./hydration-performance-closure.md). `WP-E13-07` prepared the [PROD Browser CSP Smokes](./prod-browser-csp-smokes.md); `WP-E13-08` can now start.

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

@@ -0,0 +1,81 @@
+# 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 loads components through the manifest. Since `ER-WP-28`, this path is
+explicitly secured: manifest URLs, manifest records, and dynamic module imports
+are validated locally before the loader uses them.
+
+## Allowed
+
+- relative URLs such as `./xalert.js`
+- root-relative URLs such as `/components/xrouter.js`
+- same-origin URLs
+- local loopback dev servers such as `http://localhost:4173/components/xmodal.js`
+- `.json` for manifests
+- `.js` and `.mjs` for modules
+
+## Refused
+
+- external CDN/remote modules
+- external manifest URLs
+- `javascript:`
+- `data:` for scripts
+- `blob:` modules
+- encoded path traversal such as `%2e%2e`
+- module paths without `.js` or `.mjs`
+- manifest paths without `.json`
+- invalid manifest keys
+- URL-like dependency values in manifest records
+
+## Diagnostics
+
+The loader emits refusals as `xtend-loader-diagnostic`:
+
+```js
+window.addEventListener('xtend-loader-diagnostic', (event) => {
+  console.log(event.detail.code, event.detail.metadata.diagnostics);
+});
+```
+
+Stable codes:
+
+- `xtend.security.loader.refused`
+- `xtend.security.manifest.invalid`
+- `xtend.security.import.refused`
+
+## Machine-Readable Policy
+
+```js
+const {
+  classifyPolicyUrl,
+  normalizeManifest
+} = require('./security/manifest-import-policy');
+```
+
+The policy lives at:
+
+```text
+security/manifest-import-policy.js
+```
+
+## Local 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
+```
+
+These checks are offline and do not contact external hosts.
+
+## Related Topics
+
+- [XTend Loader](./xtend-loader.md)
+- [Manifest Format](./manifest.md)
+- [Trusted DOM and Sanitizing](./trusted-dom-sanitizing.md)
+- [Supply-Chain Gates](./supply-chain-gates.md)

package/docs/en/manifest.md

@@ -0,0 +1,135 @@
+# XTend Manifest
+
+## Overview
+
+The XTend Manifest is the central JSON file that defines all available XTend
+components and their module paths. It acts as the single source of truth for the
+loader and the API when components are loaded dynamically and modularly.
+
+---
+
+## Location and Name
+
+- Default path: `components/manifest.json`
+- The path can be changed when the loader is initialized.
+
+---
+
+## Manifest Structure
+
+The manifest is a plain JSON object. Most keys match the canonical tag name of
+an XTend component; reserved bootstrap keys such as `xstate` are allowed as
+well. Each value is a concrete ES module address.
+
+### Example
+
+```json
+{
+  "xstate": "./xstate.js",
+  "x-theme": "./xtheme.js",
+  "x-button": "./xbutton.js",
+  "x-input": "./xinput.js",
+  "x-router": "./xrouter.js",
+  "x-link": "./xlink.js"
+}
+```
+
+### Conventions
+
+- Custom element tags are canonical, **lowercase, hyphenated, and start with
+  `x`** (for example `x-button`, `x-input`, `x-router`).
+- Reserved bootstrap keys such as `xstate` are valid exceptions and are not
+  interpreted as DOM tags.
+- Values may be **relative**, **root-relative**, or **same-origin/loopback-local
+  absolute** URLs.
+- The loader resolves relative entries relative to the manifest URL.
+- The default manifest path stays repo-local; CDN URLs are not the default or
+  test path.
+- Since `ER-WP-28`, external manifest/module URLs, `javascript:`, `data:`,
+  `blob:`, path traversal, and non-JavaScript modules are refused by
+  `xtend.security.manifest-policy.v1` and
+  `xtend.security.import-policy.v1`.
+- Comments are not allowed by the JSON standard and are invalid in a real
+  manifest.
+
+---
+
+## Required and Optional Entries
+
+- **Required:**
+  - `xstate` as the bootstrap base module
+- **Optional:**
+  - `x-theme` (theme engine)
+  - Additional custom components
+
+---
+
+## Extensibility
+
+- The manifest can contain any number of components.
+- Custom components are added by appending more key/value pairs.
+- Experimental or beta components should use an explicit naming convention
+  such as `x-section-beta`.
+
+## Difference from XTendRMT
+
+The XTend Manifest describes resolvable ES module paths for XTend components.
+It is not the same as a `.rmt` document.
+
+| File/Format | Responsibility |
+|--------------|----------------|
+| `components/manifest.json` | XTend Loader and component URL resolution |
+| `xtendrmt/rmt.schema.json` | Schema reference for RMT documents |
+| `.rmt` | Native app DSL with `adapters`, `components`, `routes`, `schedules`, `templates` |
+| `xtendrmt/rmt-manifest.json` | XTendRMT product manifest, entry points, and artifact parity |
+
+RMT component records may reference an XTend Manifest for manifest lookup, but
+the RMT kernel does not read XTend runtime code from it. Resolution belongs in
+host adapters and the RMT vNext Component Capability Registry. The registry
+uses the manifest as the import source, combines it with Component Contracts and
+RMT metadata, and produces descriptor capabilities for the DOM Descriptor
+Renderer.
+
+Native RMT files should be served as `application/vnd.xtendrmt.rmt+json`. The
+JSON fallback remains possible for special hosts, but it is not the recommended
+authoring path.
+
+---
+
+## Best Practices
+
+- The manifest is the **single source of truth** for resolvable component URLs.
+- Keep the manifest current to avoid dead links and load failures.
+- Production manifests should be minimized and omit unused components.
+- `xstate` should always be present explicitly; `x-theme` follows directly
+  after it when theme features are used.
+
+---
+
+## Validation
+
+- Before loading, the loader verifies that the manifest and all module URLs are
+  valid.
+- Non-string values are ignored.
+- Parsing and loading errors are written to the console log.
+- Security refusals emit `xtend-loader-diagnostic` events with
+  `xtend.security.loader.refused`, `xtend.security.manifest.invalid`, or
+  `xtend.security.import.refused`.
+- The local gate is `node scripts/run_xtend_tests.js manifest-import-policy --json`.
+- After core changes, `node scripts/verify_xtend_core_contracts.js` can
+  cross-check the bootstrap contract against manifest, API, and docs.
+
+---
+
+## Related Topics
+
+- [XTend Loader](./xtend-loader.md)
+- [Manifest Import Policy](./manifest-import-policy.md)
+- [Component Development](./components.md)
+- [RMT vNext Component Primitives and XTend UI](./rmt-vnext-component-primitives.md)
+- [API Integration](./api.md)
+- [XTendRMT App DSL Reference](./xtendrmt-app-dsl.md)
+
+---
+
+*Last updated: May 22, 2026*

package/docs/en/motion-contrast.md

@@ -0,0 +1,67 @@
+# Motion and 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`
+
+## Purpose
+
+Motion and contrast are part of a11y-by-design in XTend. Components must respect reduced motion, forced contrast modes, visible focus and non-color status without requiring XTendRMT or a host framework to know concrete CSS details.
+
+## Required Rules
+
+| Area | Implementation |
+|------|----------------|
+| Reduced motion | `@media (prefers-reduced-motion: reduce)` disables non-essential animations and transitions |
+| High contrast | `@media (forced-colors: active)` uses system colors such as `CanvasText`, `ButtonText`, `Highlight`, `Mark` |
+| Focus | `:focus-visible` remains visible and uses `Highlight` in the forced-colors path |
+| Status | error, warning, busy and active have semantics beyond color |
+| Tokens | theme tokens must not override forced-colors when system colors are required |
+
+## Component Contract
+
+Relevant components declare statically:
+
+```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
+
+New scaffold components receive:
+
+- `motionContrast.policy` in the a11y profile
+- manifest key `motionContrastPolicy`
+- docs section `Motion and Contrast Policy`
+- fixture fields `motionContrastPolicy`, `motionMediaQuery`, `contrastMediaQuery`
+- TypeScript type `X<Component>MotionContrastPolicy`
+
+## Fabric and RMT
+
+Preference signals use Fabric lane `a11y`, fiber `a11y.preference` and schedule `a11y.user-blocking.preference`. RMT remains framework-agnostic and receives only host-neutral schedule/diagnostic signals, not CSS execution.
+
+## Local Verification
+
+```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/en/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`
+- Local gate: `node scripts/run_xtend_tests.js epic13-package-export-lock --json`
+
+The Package Export Lock makes the RC1 package content checkable. The local gate validates `package.json#exports`, `files`, the expected package roots and the surface groups without running `npm pack`.
+
+## Surface Groups
+
+| Group | Purpose |
+|-------|---------|
+| Loader | `xtend-loader.js`, legacy stub, API, CSS and manifest |
+| Components | manifest and component files |
+| Fabric | Fabric runtime, RMT lane mapping and hydration policy |
+| XTendRMT | ESM and browser runtime |
+| Builder | Scaffold CLI, preview, typing and performance contracts |
+| Docs | Docs app, Markdown, Parsedown/RMT shell and references |
+| Security | manifest, Trusted DOM and supply-chain policies |
+| Catalog | gate, handoff and epic contracts |
+
+## Release Owner Artifact
+
+```bash
+npm run pack:dry-run:report
+```
+
+The script writes:
+
+- `.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` remains active. The lock only proves that package content and export surface are controlled; it does not open publishing.
+
+## TypeExports Connection
+
+As of `WP-TypeExports-01`, [TypeExports](./type-exports.md) uses the Package Export Lock as the source for the public export surface. The gate `node scripts/run_xtend_tests.js type-exports --json` ties the 121 expected exports to `xtend.epic13.package-export-lock.v1` through count and fingerprint and requires a type decision for new public exports. As of `WP-TypeExports-02`, `.`, `./loader` and `./legacy-loader` have the type targets `./xtend-loader.d.ts` and `./xtend-dev.d.ts`; `node scripts/run_xtend_tests.js type-exports-loader --json` checks this connection against the loader runtime. As of `WP-TypeExports-03`, `./api` has the type target `./api.d.ts`; `node scripts/run_xtend_tests.js type-exports-api --json` checks the core API namespace against `api.js`. As of `WP-TypeExports-04`, `./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` and the RMT language/tooling exports have type targets such as `./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` and `./tools/rmt-language/rmt-tooling-public-types.d.ts`; `node scripts/run_xtend_tests.js type-exports-rmt --json` checks this connection against the RMT runtime and tooling surface. As of `WP-TypeExports-05`, Fabric/a11y/security exports have type targets such as `./fabric/xtend-fabric.d.ts` and `./fabric/xtend-policy-public-types.d.ts`; `node scripts/run_xtend_tests.js type-exports-policy --json` checks this connection against the policy surface. As of `WP-TypeExports-06`, builder exports have type targets such as `./xtend-builder/scaffold.d.ts`, `./xtend-builder/builder-public-types.d.ts` and `./xtend-builder/*.d.ts`; `node scripts/run_xtend_tests.js type-exports-builder --json` checks this connection against Scaffold, generators, Component Lab and typing contracts. As of `WP-TypeExports-07`, catalog exports have type targets such as `./catalog/epic13-package-export-lock.d.ts` and the shared `./catalog/catalog-public-types.d.ts`; `node scripts/run_xtend_tests.js type-exports-catalog --json` checks this connection against plan/report/validation catalogs. As of `WP-TypeExports-08`, design tokens and vendor facades have type targets such as `./design-tokens/xtend-design-tokens.d.ts`, `./design-tokens/xtheme-token-alias-layer.d.ts`, `./components/prism.d.ts` and `./components/turndown.d.ts`; `node scripts/run_xtend_tests.js type-exports-vendor --json` checks this connection against the utility boundaries. As of `WP-TypeExports-09`, `npm run test:type-exports:release` bundles the TypeExports gates as a release handoff and writes `.xtend-test-results/xtend-type-exports-report.json`.
+
+## Handoff
+
+After `WP-E13-04`, `WP-E13-05` completed the Known Residual Triage under [Known Residual Triage](./known-residual-triage.md) with `xtend.epic13.known-residual-triage.v1`. `WP-E13-06` completed the [Hydration Performance Closure](./hydration-performance-closure.md) with `xtend.epic13.hydration-performance-closure.v1`. `WP-E13-07` prepared the [PROD Browser CSP Smokes](./prod-browser-csp-smokes.md), `WP-E13-08` normalized [Visual Owner Artifacts](./visual-owner-artifacts.md), `WP-E13-09` bundled [RMT Production Readiness](./rmt-production-readiness.md), `WP-E13-10` completed [Docs RMT Production Hardening](./docs-rmt-production-hardening.md), `WP-E13-11` completed [Trusted DOM Boundary Browser Proof](./trusted-dom-boundary-browser-proof.md), `WP-E13-12` completed [RC1 Migration Notes](./rc1-migration-notes.md), `WP-E13-13` registered [RC1 Gate Matrix and CI Handoff](./rc1-gate-matrix-ci-handoff.md), `DPF-WP-02` added [Release Report and Pack Dry Run Evidence](./release-report-pack-dry-run-evidence.md) and `DPF-WP-03` added [Conditional Network Evidence CI](./conditional-network-evidence-ci.md). The current export lock expects 124 package exports including `./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` and the classic and vNext RMT tooling surface.