@ccslabs/xtend 0.1.0-rc.1 → 0.1.2

package/docs/en/rmt-app-platform-migration-guide.md

@@ -0,0 +1,75 @@
+# RMT App Platform Migration Guide
+
+This guide describes the path from external host helpers such as `root.innerHTML`, product-bound surface lists or local registry repaints to native RMT App Platform primitives.
+
+## Target State
+
+- New UI is described in RMT vNext; DOM Descriptor, App Platform JSON and component records are generated output or compatibility mirrors.
+- State, selectors and derived values live in the RMT State Selector Runtime.
+- Interactions run through declarative events and actions.
+- Datasources remain interchangeable: `fixture`, `rest`, `ssr` and `host`.
+- Surfaces, overlays, portals and resources are materialized and cleaned up through the Surface Resource Graph.
+
+```rmt
+template migration.catalog {
+  state records type collection initial []
+
+  selector visibleRecords from state records {
+    output CatalogRecord[]
+  }
+
+  datasource catalog from fixture records.generic-items {
+    contract CatalogRecord[]
+  }
+
+  action load-records {
+    effect fetch datasource catalog
+    on success -> reduce state.records = result.records
+  }
+
+  portal surface.root root "#app-root" layer surface
+
+  surface catalog.board kind workspace component x-cards {
+    repeat from selector visibleRecords
+    key record.id
+    portal surface.root
+
+    lane visible weight 80 {
+      hydrate catalog-cards from selector visibleRecords
+    }
+
+    on card-click target item -> action load-records {
+      payload source from target.dataset.source
+    }
+  }
+}
+```
+
+## Migration
+
+1. Identify external HTML host renderers.
+   Search for `innerHTML`, `outerHTML`, `insertAdjacentHTML` and `document.write`.
+2. Move shell structure to RMT vNext.
+   Normal app UI uses `template`, `surface`, `portal`, `lane`, `hydrate` and events; `mode: "dom_descriptor"` appears only in output.
+3. Decouple product lists.
+   Instead of a fixed record class, use configurable record contracts with stable IDs and keys.
+4. Declare interactions.
+   DOM or custom events receive `payloadContract` and route to actions.
+5. Keep datasources interchangeable.
+   Local fixture data, SSR bootstrap, REST search and host mutation share the same action path.
+6. Check surface lifecycle.
+   Every surface with `resource` entries needs an owner, overlays run through portals, and destroy/close must release resources.
+7. Create scaffold evidence.
+   The RMT App Platform Builder writes diagnostics, source map and build report.
+
+## Reference
+
+The reference fixture is located at `tests/fixtures/rmt-app-platform-fixture.rmt` and proves `generic-catalog`, `admin-queue` and `content-board` with the same primitives.
+
+```bash
+node scripts/run_xtend_tests.js rmt-app-platform-fixture --json
+```
+
+## Boundary
+
+Trusted HTML remains an explicit special case with Trusted DOM boundary. Normal app UI must not use HTML strings as the render path.

package/docs/en/rmt-app-platform-tooling.md

@@ -0,0 +1,58 @@
+# RMT App Platform Tooling
+
+- Contract: `xtend.epic18.rmt-app-platform-tooling.v1`
+- Gate: `node scripts/run_xtend_tests.js rmt-app-platform-tooling --json`
+- Workpackage: `WP-E18-11`
+- Handoff: `WP-E18-12`
+
+## Goal
+
+RMT app sources are now checkable and buildable before runtime. The tooling creates diagnostics, source maps and scaffold reports for generic App Platform primitives such as surfaces, overlays, portals, resources, actions, events, datasources and state.
+
+The slice is intentionally not a Media Manager shell. It provides tools that let developers create their own app structures natively in XTend/RMT without product-side `innerHTML` renderers or custom mini-frameworks.
+
+## Diagnostics
+
+The App Platform linter blocks typical late runtime errors already during authoring:
+
+- `rmt.app.no-manual-shell.html-sink` for `innerHTML`, `outerHTML`, `insertAdjacentHTML` or `document.write` in normal app UI.
+- `rmt.app.unsafe-html.boundary-missing` for HTML fragments without explicit Trusted DOM boundary.
+- `rmt.app.repeat.key.missing` for repeated surfaces without stable key.
+- `rmt.app.event.payload-contract.missing` for events with action target but without payload contract.
+- `rmt.app.resource.ownership.missing` for resources without clear owner.
+- `rmt.app.resource.unresolved`, `rmt.app.portal.unresolved` and `rmt.app.surface.source.unresolved` for faulty app graph references.
+
+The rules run as a dedicated App Platform policy rule in the existing RMT linter and as a direct analyzer in `./rmt-language/app-platform-tooling`.
+
+## LSP
+
+Completion and hover understand the new primitives:
+
+- portal IDs and portal policies such as `stacked`, `toast-region` and `clipping-escape`
+- overlay kinds such as `tooltip`, `toast`, `popover`, `lightbox`, `menu` and `dialog`
+- resource kinds such as `object-url`, `stream`, `observer`, `timer` and `lazy-import`
+- event kinds and surface initial states
+
+App authors can therefore edit RMT documents without a product surface taxonomy and without external helper lists.
+
+## Scaffold Build
+
+The builder registers the command `rmt-app-platform`. It reads a `.rmt` app source and creates under `.xtend-build`:
+
+- `*.app-platform-diagnostics.json`
+- `*.app-platform-source-map.json`
+- `*.app-platform-build.json`
+
+The artifacts run through the Epic 17 WritePlan and carry scaffold ownership. `--check` can therefore verify whether local build artifacts are current.
+
+```bash
+node scripts/run_xtend_tests.js rmt-app-platform-tooling --json
+node xtend-builder/lib/cli.js rmt-app-platform --source tests/fixtures/rmt-app-platform-tooling.rmt
+```
+
+## Boundaries
+
+- No product surface list and no Media Manager-specific registry repaint.
+- No normal UI HTML sinks outside a Trusted DOM boundary.
+- No imports from XTend components into the RMT kernel.
+- The tooling builds reports, diagnostics and source maps; the production-close generic app fixture follows in `WP-E18-12`.

package/docs/en/rmt-component-template-primitives.md

@@ -0,0 +1,49 @@
+# RMT Component Template Primitives
+
+- Contract: `xtend.epic18.rmt-component-template-primitives.v1`
+- Fixture: `tests/fixtures/rmt-component-template-primitives.rmt`
+- Runtime base: `xtendrmt/rmt-dom-descriptor-renderer.js`
+- Local gate: `node scripts/run_xtend_tests.js rmt-component-template-primitives --json`
+- Workpackage: `WP-E18-06`
+- Handoff: `WP-E18-07`
+
+RMT can now compose XTend components natively without host apps assembling HTML strings. This slice extends the DOM Descriptor Renderer with component-close primitives for app shells, lists, forms, tooltips, icons, empty states and error states.
+
+## Primitives
+
+| Primitive | Purpose |
+|-----------|---------|
+| `component` | Resolves a component ID to a custom element such as `x-section`, `x-card`, `x-tooltip` or arbitrary developer tags. |
+| `props` | Sets safe DOM properties and mirrors primitive values as attributes. |
+| `attributes` | Sets safe attributes without inline-event or URL sinks. |
+| `parts` | Writes CSS parts for themeable components. |
+| `slots` | Fills slots with text, templates, components or fragments. |
+| `text` | Creates text nodes through `createTextNode`. |
+| `when` | Renders conditional subtrees. |
+| `repeat` | Renders lists and uses `key` for stable nodes. |
+| `empty` | Renders an explicit empty state. |
+| `fallback` | Renders declarative fallback content. |
+| `key` | Marks reusable list elements with `data-rmt-key`. |
+| `ref` | Writes `data-rmt-ref` and stores the element reference in `refs`. |
+| `class` | Maps classes from strings, arrays or conditional objects. |
+| `style-token` | Mirrors design tokens as `data-style-token-*` and `--xtend-*`. |
+
+## Component Families
+
+The fixture proves generic families instead of product surfaces: icons, tooltips, form controls (`x-input`, `x-select`, `x-checkbox`), navigation, lists, selection, empty state, error state and free custom elements. Components remain developer-defined; RMT only knows descriptors and adapter capabilities.
+
+## Component Capability Registry
+
+The vNext layer connects these primitives to the full XTend component stack
+through `xtendrmt/rmt-component-capability-registry.js`. The registry
+normalizes all 44 public manifest entries, classifies 40 renderable UI
+components, and connects Component Contracts, `xtendRmtMetadata`,
+`observedAttributes`, events, slots, parts, form state, and lazy import with the
+generic DOM descriptors.
+
+That keeps `component`, `props`, `attributes`, `parts`, `slots`, `repeat`, and
+`key` as the same primitives, but gives them a stack-wide compatibility matrix.
+Product code does not need Shadow-DOM patches, private component maps, or
+component-specific renderers.
+
+See [RMT vNext Component Primitives and XTend UI](./rmt-vnext-component-primitives.md).

package/docs/en/rmt-dom-descriptor-renderer.md

@@ -0,0 +1,54 @@
+# RMT DOM Descriptor Renderer
+
+- Contract: `xtend.epic18.rmt-dom-descriptor-renderer.v1`
+- Fixture: `tests/fixtures/rmt-dom-descriptor-renderer.rmt`
+- Runtime: `xtendrmt/rmt-dom-descriptor-renderer.js`
+- Local gate: `node scripts/run_xtend_tests.js rmt-dom-descriptor-renderer --json`
+- Workpackage: `WP-E18-05`
+
+The renderer implements the `WP-E18-04` authoring model as a generic app platform. Normal app UI is built from structured descriptors: `createElement`, `createTextNode`, `createDocumentFragment`, `replaceChildren`, safe attributes/properties and keyed child reuse.
+
+## Descriptor Rules
+
+| Area | Rule |
+|------|------|
+| Shell | Root render units use `replaceChildren` and mark the root with `data-rmt-rendered-shell`. |
+| Elements | Tags must be simple custom-element or HTML tag names. |
+| Attributes | Inline handlers, `srcdoc` and unsafe URL values are rejected. |
+| Properties | HTML-sink properties are blocked for normal UI. |
+| Lists | `renderKeyed` preserves nodes via `data-rmt-key` and patches attributes/children. |
+| Events | Events run through `addEventListener`, not through string attributes. |
+| Diagnostics | Runtime errors include RMT source information such as `documentId`, `templateId` and `pointer`. |
+
+## Component Registry Option
+
+`render(...)` and `renderKeyed(...)` accept `componentRegistry`. When a
+descriptor uses `type: "component"`, the renderer normalizes tag, attributes,
+properties, slots, parts, and event bindings through the RMT vNext Component
+Capability Registry:
+
+```js
+renderer.renderKeyed(root, descriptors, {
+  componentRegistry: registry,
+  dispatchEvent,
+  stateBridge
+});
+```
+
+The registry binds XTend components through public DOM APIs. It reads Component
+Contracts and RMT metadata, performs lazy import through manifest paths, and
+writes safe capability markers such as `data-rmt-component-capability`. The
+renderer stays generic: no Shadow-DOM patches, no private component maps, and no
+HTML sinks for normal RMT app UI.
+
+## Trusted Boundary
+
+HTML fragments are not a normal template path. They may only be rendered as `trusted_html` with `xtend.rmt.trusted-dom-boundary.explicit` and an external `trustedDomRenderer`. The default renderer creates no HTML fragments from strings.
+
+## No Manual HTML
+
+The gate `createNoManualHtmlGate()` blocks normal app shells that use manual HTML sinks such as `root.innerHTML`, `element.innerHTML`, `template.innerHTML`, `outerHTML`, `insertAdjacentHTML`, `document.write` and `createContextualFragment`.
+
+`WP-E18-06` and the vNext Component Capability Registry build component-native
+template primitives on top of this slice without requiring external HTML helper
+renderers.

package/docs/en/rmt-dsl-authoring-polish.md

@@ -0,0 +1,143 @@
+# RMT DSL Authoring Polish
+
+The contract `xtend.rmt.dsl-authoring-polish.v1` prepares a friendlier RMT DSL
+for XTend component shells. It makes RMT authoring shorter without embedding
+XTend in the RMT kernel.
+
+Local gate:
+
+```bash
+node scripts/run_xtend_tests.js rmt-dsl-authoring-polish --json
+```
+
+## Why This Package Exists
+
+After `WP-E12-12`, XTend has a productive design-token vocabulary.
+`WP-E12-13` uses these tokens so shells, slots, styles, a11y, events, commands,
+hydration, Fabric lanes, and XRouter routes can be described more easily in
+RMT.
+
+RMT remains host-neutral:
+
+- `xtend.component` renders and hydrates components in the host.
+- `xtend.xrouter` connects route records to XRouter.
+- `xtend.fabric` and telemetry remain adapter/host data.
+- `no-rmt-kernel-import-of-xtend-types` remains mandatory.
+
+## Authoring Aliases
+
+| Alias | Target |
+|-------|--------|
+| `component` | XTend component record |
+| `shell` | shell state, slots, parts, and focus |
+| `slot` | template, component, or text slots |
+| `style` | variant, theme, density, tokens, and parts |
+| `token` | productive `--xtend-*` tokens |
+| `theme` | theme pack |
+| `density` | density pack |
+| `a11y` | role, label, live region, keyboard, and announcements |
+| `on` | event to command |
+| `command` | command to schedule |
+| `hydrate` | hydration policy |
+| `lane` | Fabric lane and fiber |
+| `route` | XRouter route |
+| `link` | XLink-compatible link |
+| `outlet` | route outlet in the template |
+
+## Example
+
+```rmt
+template settings.shell {
+  state settings.theme type string initial "dark"
+  state settings.density type string initial "comfortable"
+
+  portal surface.root root "#settings-root" layer surface
+
+  surface settings.shell kind page component x-section {
+    portal surface.root
+
+    lane visible weight 80 {
+      hydrate settings-header {
+        slot header hydrate settings.header.template
+      }
+
+      hydrate feedback-toast from endpoint xtendrmt.component.hydrate {
+        slot feedback hydrate feedback.toast
+      }
+    }
+
+    lane idle weight 20 {
+      hydrate settings-shell-style from endpoint xtendrmt.component.hydrate {
+        trust boundary "xtend.security.sanitizing-boundary.v1"
+      }
+    }
+  }
+}
+```
+
+Token aliases remain part of the contract: productive styles continue to
+reference stable custom properties such as `--xtend-surface` and
+`--xtend-color-primary`, while vNext describes structure, slots, and hydration.
+
+The normalized output becomes `components[]`, `templates[]`, and `schedules[]`.
+RMT describes the structure; XTend executes component hydration.
+
+## Routing Sugar
+
+Routes can be described in an author-friendly surface, link, and outlet
+structure:
+
+```rmt
+template settings.routing {
+  portal surface.root root "#app-root" layer surface
+
+  surface settings.route kind page component x-section {
+    portal surface.root
+
+    lane visible weight 80 {
+      hydrate settings-shell from endpoint xtendrmt.route.render
+      hydrate settings-link from endpoint xtendrmt.component.hydrate
+      slot outlet hydrate primary
+    }
+
+    on click target settings-link -> action route.navigate {
+      payload href from "/settings"
+    }
+  }
+}
+```
+
+This becomes `routes[]`, `components[]`, and `templates[]` with adapter
+`xtend.xrouter`. XRouter remains a host adapter, not an RMT kernel dependency.
+
+## Diagnostics
+
+The polish plan defines these diagnostic codes:
+
+- `rmt.dsl.alias.unknown`
+- `rmt.dsl.alias.required-field-missing`
+- `rmt.dsl.token.unknown`
+- `rmt.dsl.route.target-unresolved`
+- `rmt.dsl.link.route-unresolved`
+- `rmt.dsl.slot.target-unresolved`
+- `rmt.dsl.schedule.unresolved`
+- `rmt.dsl.inline-runtime-code-refused`
+- `rmt.dsl.kernel-boundary.refused`
+
+This lets XTendRMT upstream build friendlier parser errors and editor hints
+without importing the XTend runtime.
+
+## Artifacts
+
+- Contract: `development/XTend-RMT-DSL-Authoring-Polish-fuer-Component-Shells.md`
+- Module: `xtend-builder/typing/rmt-dsl-authoring-polish.js`
+- Fixture: `tests/fixtures/rmt-dsl-authoring-polish.rmt`
+- Suite: `tests/rmt/rmt_dsl_authoring_polish_suite.js`
+
+## RC0 Adoption Update
+
+Since `WP-E12-15`, the [RC0 Adoption Guide](./rc0-adoption-guide.md) describes
+how app authors use this DSL polish layer for shell-first XTend apps. The most
+important migration rule remains: RMT may construct and schedule XTend
+components, XRouter routes, and content slots without embedding XTend types in
+the RMT kernel.

package/docs/en/rmt-event-routing-runtime.md

@@ -0,0 +1,98 @@
+# RMT Event Routing Runtime
+
+- Contract: `xtend.epic18.rmt-event-routing-runtime.v1`
+- Workpackage: `WP-E18-09`
+- Runtime: `xtendrmt/rmt-event-routing-runtime.js`
+- Types: `xtendrmt/rmt-event-routing-runtime.d.ts`
+- Fixture: `tests/fixtures/rmt-event-routing-runtime.rmt`
+- Local gate: `node scripts/run_xtend_tests.js rmt-event-routing-runtime --json`
+- Next: `WP-E18-10`
+
+## Purpose
+
+The Event Routing Runtime makes DOM and custom events first-class RMT app
+platform primitives. Apps can bind events to actions declaratively, validate
+payloads before action execution, apply governance policies and clean up
+listeners by owner scope.
+
+The runtime delegates execution to the Action Effect Runtime from `WP-E18-08`.
+It does not create a second action framework and does not import XTend UI
+components.
+
+## Event Bindings
+
+An event binding can declare:
+
+- `event`
+- `target`
+- `component`
+- `owner`
+- `action`
+- `actionMode`
+- `payload`
+- `payloadContract`
+- `governance`
+- `condition`
+
+Targets are resolved through explicit refs, a passed `targets` map, a custom
+target resolver or a DOM query from a provided root. Product-local
+`event.target.closest(...)` delegation chains are not required for normal app
+flows.
+
+## Payload Contracts
+
+Payloads are built from event data with expressions such as:
+
+- `$event.target.value`
+- `$detail.id`
+- `$target.dataset.id`
+- `$source.dataset.path`
+
+Contracts use a small structural shape:
+
+```json
+{
+  "type": "object",
+  "required": ["id"],
+  "properties": {
+    "id": "string"
+  }
+}
+```
+
+Invalid payloads are blocked before the action runtime is called and emit
+`rmt.event.payload_contract.invalid` diagnostics.
+
+## Event Governance
+
+Supported policies:
+
+- `preventDefault`
+- `stopPropagation`
+- `stopImmediatePropagation`
+- `capture`
+- `passive`
+- `once`
+- `retarget`
+
+Retargeting can use `target`, `current-target` or `composed-path`. This keeps
+component interaction explicit without product-specific DOM walking.
+
+## Ownership
+
+`attach()` registers listeners and records their owner. `detachOwner(ownerId)`
+removes only the listeners for that scope, while `detachAll()` removes the
+remaining listeners. This is the bridge to the surface and resource lifecycle
+work in `WP-E18-10`.
+
+## Diagnostics
+
+Diagnostics use `xtend.epic18.rmt-event-routing-diagnostic.v1` on
+`rmt.app_platform.event_routing`. Route diagnostics include event id, component,
+payload and action target so build and runtime reports can show why a user
+interaction did or did not execute.
+
+## Handoff
+
+`WP-E18-10` can now harden surface, overlay, portal and resource graphs using
+owner-scoped events plus the resource ownership model from `WP-E18-08`.

package/docs/en/rmt-first-demo-app.md

@@ -0,0 +1,87 @@
+# RMT-First Demo App
+
+Contract: `xtend.epic10.rmt-first-demo-app.v1`
+
+The RMT-first demo app shows the Epic 10 target path: an XTend app is no longer
+built as a manual HTML shell, but rendered from a `.rmt` app document. XTend
+provides local Web Components. RMT provides shell, routes, templates,
+schedules, Fabric/lane metadata, and diagnostics.
+
+## Starting Point
+
+- Demo / Browser smoke: `tests/browser/fixtures/rmt-first-demo-app-smoke.html`
+- RMT document: `xtendrmt/rmt-first-demo-app.rmt`
+- Runtime: `xtendrmt/rmt-first-demo-app.js`
+- Browser smoke: `tests/browser/fixtures/rmt-first-demo-app-smoke.html`
+
+The host page contains only the RMT root:
+
+```html
+<div
+  id="rmt-first-demo-root"
+  data-rmt-host="rmt-first-demo"
+  data-rmt-document-src="xtendrmt/rmt-first-demo-app.rmt"></div>
+```
+
+The shell itself comes from `app.shell.template`.
+
+## What RMT Owns
+
+- App shell
+- Routes
+- `dom_descriptor` templates
+- Component records
+- Props, attributes, slots, and event commands
+- Schedules and lanes
+- Fabric/fiber metadata
+- Diagnostics
+
+## What XTend Owns
+
+- Custom Elements
+- Manifest lookup
+- Component lifecycle
+- DOM execution
+- XRouter registration
+- Fabric execution and telemetry hooks
+
+The RMT kernel imports no XTend components. This boundary remains
+`no-rmt-kernel-import-of-xtend-types`.
+
+## Demo Routes
+
+| Route | Path | Content |
+|-------|------|---------|
+| `dashboard` | `/` | shell-first status and performance coverage |
+| `settings` | `/settings` | form controls with `x-select`, `x-checkbox`, `x-radio`, `x-textarea` |
+| `overlays` | `/overlays` | `x-tooltip`, `x-popover`, `x-drawer` |
+
+## No-Manual-Shell Rule
+
+The demo is correct only when:
+
+- the host contains no static `x-section` or `x-router` shell tags
+- the runtime does not use `innerHTML`
+- `manifest.metadata.manualShellAllowed` is `false`
+- `manifest.metadata.hostShellMarkup` is `false`
+- the browser smoke renders the shell from RMT
+
+## Local Gate
+
+```bash
+node scripts/run_xtend_tests.js rmt-first-demo-app --json
+```
+
+The gate checks RMT references, runtime registry normalization, host boundary,
+browser smoke, package metadata, and documentation paths.
+
+## Continuation
+
+`WP-E10-14` migrates existing prioritized components into the same RMT/Fabric
+metadata line. The demo app remains the first productive acceptance host for
+that work.
+
+Since `WP-E13-09`, the demo app is part of
+[RMT Production Readiness](./rmt-production-readiness.md). The contract
+`xtend.epic13.rmt-production-readiness.v1` uses it as shell-first evidence for
+routing, components, Fabric/lane, lifecycle telemetry, and diagnostics.

package/docs/en/rmt-first-xtend-apps.md

@@ -0,0 +1,127 @@
+# RMT-First XTend Apps
+
+Docs Contract: `xtend.docs.rmt-first-xtend-apps.v1`
+
+This guide describes the Epic 10 target path: a complete XTend app is described
+as an RMT vNext document. XTend provides local Web Components; RMT provides the
+shell, routes, templates, components, schedules, hydration policies, Fabric
+lanes, and diagnostics.
+
+The underlying authoring contract is:
+
+```text
+xtend.rmt.first-class-app-authoring.v1
+```
+
+## Core Rules
+
+- RMT vNext is the app authoring model.
+- XTend components are described through surfaces with `component x-*` and
+  compiled into `xtend.component` records.
+- XRouter is connected through `xtend.xrouter`.
+- Templates preferably use `dom_descriptor` as generated output.
+- Event bindings use `on ... -> action ...`.
+- Fabric, lane, and fiber hints come from `lane` and lifecycle clauses.
+- The RMT kernel imports no XTend classes or XTend types.
+
+The boundary remains:
+
+```text
+no-rmt-kernel-import-of-xtend-types
+```
+
+## Minimal Structure
+
+```rmt
+template settings.app {
+  state settings.status type string initial "ready"
+
+  selector settings.feedback from state settings.status {
+    output StatusView
+  }
+
+  action settings.refresh {
+    reduce state.settings.status = "refreshing"
+    emit settings.refresh.requested with action settings.refresh
+  }
+
+  portal surface.root root "#app-root" layer surface
+
+  surface settings.status kind card component x-status {
+    source selector settings.feedback
+    portal surface.root
+
+    lane visible weight 80 {
+      mount x-status
+      hydrate settings-status from selector settings.feedback
+    }
+
+    on click target refresh-button -> action settings.refresh {
+      payload source from target.dataset.action
+    }
+  }
+}
+```
+
+The compiler turns this into `xtend.component`, `xtend.xrouter`,
+`rmt.state-scheduler-diagnostics`, `dom_descriptor` templates, and
+schedule/lane records. These JSON records are runtime mirrors, not the primary
+authoring path.
+
+## Reference Paths
+
+- Contract: `development/XTend-RMT-First-Class-App-Authoring.md`
+- Fixture: `tests/fixtures/rmt-first-class-xtend-app.rmt`
+- Demo app: `xtendrmt/rmt-first-demo-app.rmt`
+- Browser smoke: `tests/browser/fixtures/rmt-first-demo-app-smoke.html`
+- Gate: `node scripts/run_xtend_tests.js rmt-first-class-app --json`
+- Demo gate: `node scripts/run_xtend_tests.js rmt-first-demo-app --json`
+
+## Fabric and Telemetry
+
+Components receive Fabric context through adapter injection. The canonical
+boundary is:
+
+```text
+adapter-injection-via-xtend-component-resolveFabricContext
+```
+
+`window.XTendFabric` can be used by hosts, but it is not the contract surface
+of a component.
+
+## Release Handoff
+
+The completion of Epic 10 is documented in
+[Epic 10 Release Handoff](./epic10-release-handoff.md). That gate chain decides
+whether an RMT-first XTend app path is release-ready enough for a candidate.
+
+Since `WP-E13-09`, [RMT Production Readiness](./rmt-production-readiness.md)
+bundles this path under `xtend.epic13.rmt-production-readiness.v1`:
+shell-first app shell, routing, components, Fabric/lanes, lifecycle telemetry,
+diagnostics, and artifact parity are connected as an RC1 gate. `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)
+and `xtend.epic13.trusted-dom-boundary.v1`. `WP-E13-12` completed
+[RC1 Migration Notes](./rc1-migration-notes.md) and
+`xtend.epic13.rc1-migration-notes-semver.v1`. `WP-E13-13` completed
+[RC1 Gate Matrix and CI Handoff](./rc1-gate-matrix-ci-handoff.md) and
+`xtend.epic13.rc1-gate-matrix-ci-handoff.v1`.
+
+## Component UX Authoring
+
+Since `WP-E11-16`, [Component UX App Authoring](./component-ux-app-authoring.md)
+extends this guide with visible UX rules for RMT-first apps. This includes
+theme, motion, density, viewports, browser smokes, and the Component Shell
+Theme Matrix `xtend.epic11.component-shell-theme-matrix.v1`.
+
+Since `WP-E11-17`, [Component Long-Tail Migration](./component-long-tail-migration.md)
+describes which legacy and infrastructure components are hardened first for
+RMT-first app compatibility.
+
+The local docs gate is:
+
+```bash
+node scripts/run_xtend_tests.js component-ux-authoring-docs --json
+node scripts/run_xtend_tests.js component-long-tail-migration --json
+```