@ccslabs/xtend 0.1.0-rc.1 → 0.1.2

package/docs/en/performance-measurements.md

@@ -0,0 +1,106 @@
+# Performance Measurements
+
+Starting with `ER-WP-18`, XTend measures loader, hydration, render and route core paths locally.
+
+The stable measurement contract is:
+
+```text
+xtend.performance.measurement.v1
+```
+
+## Measurement Points
+
+| Measure | Phase | Source |
+|---------|-------|--------|
+| `xtend.loader.manifest` | `load` | `xtend-loader.js` |
+| `xtend.loader.module` | `load` | `xtend-loader.js`, Fabric Fibers |
+| `xtend.component.define` | `define` | `xtend-loader.js` |
+| `xtend.component.mount` | `mount` | Fabric Fibers |
+| `xtend.component.hydrate` | `hydrate` | Fabric Fibers |
+| `xtend.component.render` | `render` | Fabric Fibers |
+| `xtend.component.update` | `update` | Fabric Fibers |
+| `xtend.event.handler` | `event` | Fabric Fibers |
+| `xtend.route.navigate` | `route` | Fabric Fibers |
+| `xtend.route.render` | `route` | Fabric Fibers |
+| `xtend.diagnostics.snapshot` | `diagnostics` | Fabric Fibers |
+
+## Loader
+
+The loader sets `performance.mark` and `performance.measure` for:
+
+- loading and resolving the manifest
+- loading the ESM module
+- waiting for the Custom Element definition
+
+It also emits a local browser event:
+
+```js
+window.addEventListener('xtend-loader-performance', (event) => {
+  console.log(event.detail.name, event.detail.durationMs);
+});
+```
+
+The automatic boot promise contains the loader measurements:
+
+```js
+const boot = await window.__XTendLoaderBootPromise;
+console.log(boot.performanceMeasurements);
+```
+
+## Fabric
+
+Fabric automatically measures known fibers:
+
+```js
+const fabric = window.XTendFabric.createXtendFabric({
+  performance: window.performance
+});
+
+const component = fabric.createComponentFiberInstrumentation('x-alert');
+await component.hydrate(() => hydrateAlert());
+```
+
+Measurement can be disabled for special tests:
+
+```js
+const fabric = window.XTendFabric.createXtendFabric({
+  markPerformance: false
+});
+```
+
+## Telemetry Snapshot
+
+`createTelemetrySnapshot()` reads `mark` and `measure` entries with the `xtend.` prefix and normalizes them:
+
+```js
+const snapshot = fabric.createTelemetrySnapshot({
+  performance: window.performance
+});
+
+console.log(snapshot.performance.measurements);
+console.log(snapshot.performance.phaseSummary.hydrate);
+```
+
+The snapshot section contains:
+
+- `measurementSchema`
+- `measurementCount`
+- `measurements`
+- `phaseSummary`
+- `entries`
+- `totalDurationMs`
+- `maxDurationMs`
+
+## Gates
+
+```bash
+node scripts/run_xtend_tests.js fabric-performance-measurements --json
+npm run test:fabric-performance
+```
+
+Since `ER-WP-19`, [Performance Regression](./performance-regression.md) uses the same measurements for local deterministic baselines:
+
+```bash
+node scripts/run_xtend_tests.js performance-regression --json
+npm run test:performance
+```

package/docs/en/performance-regression.md

@@ -0,0 +1,89 @@
+# Performance Regression
+
+- Docs contract: `xtend.docs.performance-regression.v1`
+- Gate contract: `xtend.performance.regression-gate.v1`
+- Baseline contract: `xtend.performance.regression-baseline.v1`
+- Report schema: `xtend.performance.regression-report.v1`
+- Since: `ER-WP-19`
+
+XTend already measures loader, hydration, render and route work as `xtend.performance.measurement.v1`. The Performance Regression Gate evaluates these measurements against local baselines.
+
+## Local Gate
+
+```bash
+node scripts/run_xtend_tests.js performance-regression
+npm run test:performance
+node scripts/run_xtend_tests.js performance-regression --json
+```
+
+The suite uses:
+
+- `tests/performance/performance_regression_suite.js`
+- `tests/performance/baselines/local-performance-baseline.json`
+- Fabric `createTelemetrySnapshot`
+- budget values from `fabric/xtend-fabric.js` and `development/XTend-Performance-Budget-Matrix.md`
+
+## Status Model
+
+| Status | Condition | Effect |
+|--------|-----------|--------|
+| `pass` | `durationMs <= budgetMs` | no action |
+| `warn` | `durationMs <= budgetMs * 1.5` | visible in report |
+| `fail` | `durationMs > budgetMs * 1.5` | suite fails |
+
+Warnings are calibration signals. Hard `fail` entries are regressions and appear in the runner report under `failures`. Since `WP-E13-06`, the local RC1 baseline must report `warnCount === 0`; the earlier hydration warning is closed without owner dependency through [Hydration Performance Closure](./hydration-performance-closure.md).
+
+## Baseline
+
+The first baseline is intentionally deterministic and local:
+
+```text
+tests/performance/baselines/local-performance-baseline.json
+```
+
+It covers at least these measurement points:
+
+- `xtend.loader.manifest`
+- `xtend.loader.module`
+- `xtend.component.define`
+- `xtend.component.mount`
+- `xtend.component.hydrate`
+- `xtend.component.render`
+- `xtend.component.update`
+- `xtend.event.handler`
+- `xtend.route.navigate`
+- `xtend.route.render`
+- `xtend.diagnostics.snapshot`
+
+## JSON Report
+
+The embedded regression report uses:
+
+```text
+xtend.performance.regression-report.v1
+```
+
+Important fields:
+
+- `measurementSchema`
+- `measurementCount`
+- `passCount`
+- `warnCount`
+- `failCount`
+- `warnings`
+- `failures`
+- `phaseSummary`
+
+`phaseSummary` makes visible which phase creates budget pressure without requiring every component to have its own browser test.
+
+## Relationship to Measurements
+
+The regression gate builds on [Performance Measurements](./performance-measurements.md). It does not introduce a second measurement logic, but uses Fabric telemetry snapshots as the source.
+
+## RC1 Closure
+
+`WP-E13-06` calibrated `xtend.component.hydrate` from `36ms / 32ms` to `31ms / 32ms` without raising the budget. The failure fixture remains active and continues to prove that real budget violations fail hard.
+
+## Handoff
+
+`ER-WP-20` uses these reports for lazy/idle/visible hydration policies. `ER-WP-21` derived the practical rules for component authors in [Performance for component authors](./performance.md).

package/docs/en/performance.md

@@ -0,0 +1,132 @@
+# Performance for Component Authors
+
+- Docs Contract: `xtend.docs.performance-authoring.v1`
+- Scaffold Policy: `xtend.scaffold.performance-policy.v1`
+- Component Profile Contract: `xtend.performance.component-profile.v1`
+- Budget Matrix: `xtend.performance.budget-matrix.v1`
+- Measurement Contract: `xtend.performance.measurement.v1`
+- Regression Gate: `xtend.performance.regression-gate.v1`
+- Hydration Policy: `xtend.fabric.hydration-policy.v1`
+- Since: `ER-WP-21`
+
+This document turns the performance budget matrix into concrete authoring
+rules. New components should not be optimized only after the fact; their
+performance profile should already be visible in the scaffold, component docs,
+Fabric measurements, and the local regression gate.
+
+## Performance Profile
+
+Every new scaffolded component receives `xtendScaffoldPerformanceProfile` in
+source, `performanceProfile` in the manifest patch plan, and the docs sections
+`Performance Profile` and `Performance Rules`. These artifacts all reference
+the same policy: `xtend.scaffold.performance-policy.v1`.
+
+| Profile | Lane | Budget Class | Hydration | Critical Phases |
+|--------|------|--------------|-----------|------------------|
+| `display` | `visible` | `interactive` | `visible` | load, mount, hydrate, render, update |
+| `interactive` | `user-blocking` | `critical` | `visible` | hydrate, render, update, event |
+| `overlay` | `user-blocking` | `critical` | `visible` | mount, hydrate, render, event |
+| `routing` | `transition` | `interactive` | `visible` | route navigate, route render, hydrate, event |
+| `form` | `user-blocking` | `critical` | `visible` | hydrate, update, event |
+| `media` | `visible` | `interactive` | `visible-or-idle` | mount, hydrate, render, event |
+| `stateful` | `user-blocking` | `critical` | `visible` | update, event, state sync |
+| `feedback` | `a11y` | `critical` | `visible` | render, update, event, announcement |
+| `theme` | `visible` | `interactive` | `visible` | render, update, theme apply |
+
+Components with multiple profiles use the strictest budget class and the
+highest-priority lane. `feedback` may use a dedicated `a11y` fiber; `media` may
+move non-visible work to `idle`.
+
+## DOM Rules
+
+- DOM queries must be limited to `this.shadowRoot`, the host, or a known
+  container.
+- `document.querySelectorAll` and global DOM loops need a justified exception
+  and a budget.
+- Static references may be cached; dynamic node lists must not grow without
+  control.
+- Repeated full renders are acceptable only for small, static components.
+  Larger components must update targeted subtrees.
+- `MutationObserver`, `ResizeObserver`, timers, and subscriptions must be
+  cleaned up in `disconnectedCallback`.
+
+## Event Rules
+
+- `interactive`, `overlay`, and `form` treat user events as `critical`; the
+  synchronous handler target is 16 ms.
+- Handlers must not perform synchronous network, storage, or large DOM-scan
+  work.
+- High-frequency events such as `input`, `scroll`, `pointermove`, and `resize`
+  must be throttled, batched, or moved onto `requestAnimationFrame`.
+- Event data should be moved into canonical state or local render caches;
+  derived DOM work is then batched afterwards.
+
+## Shadow DOM
+
+- Styles should stay static. Re-inserting identical `<style>` blocks on the
+  update path is a review signal.
+- Use CSS custom properties and parts where possible so theme work does not
+  require JavaScript layout loops.
+- `slotchange` must be budgeted and must not trigger unbounded DOM scans.
+- Shadow DOM updates should replace small subtrees instead of rewriting the
+  entire UI for every state change.
+
+## Layout and Animation
+
+- Layout reads happen before layout writes. Mixed read/write loops in the same
+  synchronous phase are forbidden.
+- Animations should prefer `transform` and `opacity` and respect
+  `prefers-reduced-motion`.
+- Measurable visible work must be correlatable through `componentRef`,
+  `fiberId`, `lane`, `phase`, and `durationMs`.
+- Non-visible work uses `idle`, `background`, or `diagnostics`; it must not
+  claim a `user-blocking` lane.
+
+## Hydration
+
+`visible` is the default for visible UI. `idle` is suitable for work that is
+not needed immediately but is expected soon. `lazy` is reserved for work that
+activates only on demand or when it becomes visible. Non-visible hydration must
+not be scheduled as `user-blocking`.
+
+The operational policy is described in
+[Hydration Policies](./hydration-policies.md). Measurement points and gate
+evaluation are described in [Performance Measurements](./performance-measurements.md)
+and [Performance Regression](./performance-regression.md).
+
+## Scaffold Requirements
+
+New scaffold outputs must expose this data:
+
+- `performanceProfile`
+- `budgetClass`
+- `lane`
+- `hydrationPolicy`
+- `criticalMeasurements`
+- `idleOrBackgroundAllowed`
+- `requiresA11yFiber`
+
+The policy is stored in `xtend-builder/scaffold.config.js` under
+`performance`. The generator mirrors it into
+`xtend-builder/performance/component-performance-profile.js`, the component
+templates, and the manifest patch plan.
+
+## Gates
+
+```bash
+node scripts/run_xtend_tests.js fabric-performance-measurements --json
+node scripts/run_xtend_tests.js performance-regression --json
+node scripts/run_xtend_tests.js hydration-policy --json
+node scripts/run_xtend_tests.js references --json
+```
+
+`performance-regression` may produce local warnings when a deterministic
+fixture path exceeds its budget. Hard failures remain reserved for prioritized
+core paths and documented budget violations.
+
+## Handoff
+
+`ER-WP-25` is complete and connects screen reader signals with performance
+fibers and the `a11y` lane. `ER-WP-26` is complete as well: reduced-motion and
+high-contrast rules use the same profile, lane, and gate language through
+`xtend.a11y.motion-contrast-policy.v1`.

package/docs/en/previews/README.md

@@ -0,0 +1,17 @@
+# XTend Scaffold Previews
+
+- Status: scaffold preview convention
+- Reference gate: `node scripts/run_xtend_tests.js references`
+- Generator: `node xtend-builder/scaffold.js preview --tag x-example --profile display --feature state --json`
+
+## Purpose
+
+This directory is reserved for scaffolded component preview plans. A preview plan is a local Markdown reference that connects generated component source, docs, fixture, types and manifest patch output to the documentation and demo reference registry.
+
+## Minimum Contract
+
+- Preview paths follow `docs/previews/<name>.preview.md`.
+- Preview plans must be listed in `development/XTend-Dokumentations-und-Demo-Referenzpfade.md` before they become automated references.
+- Preview plans must use repo-local component, fixture and manifest paths.
+- External network dependencies are not allowed for automated scaffold previews.
+- Productive preview writes remain review-first until a later package introduces a write mode.

package/docs/en/prod-browser-csp-smokes.md

@@ -0,0 +1,40 @@
+# PROD Browser CSP Smokes
+
+- Contract: `xtend.epic13.prod-browser-csp-smoke.v1`
+- Fixture contract: `xtend.epic13.prod-browser-csp-smoke-fixture.v1`
+- Report: `xtend.epic13.prod-browser-csp-smoke-report.v1`
+- Workpackage: `WP-E13-07`
+- Local gate: `node scripts/run_xtend_tests.js epic13-prod-browser-csp-smoke --json`
+- Dev server: `npm run dev:local:csp`
+- Fixture: `tests/browser/fixtures/epic13-prod-csp-smoke.html`
+- Publish boundary: `private-until-release-owner-acceptance`
+
+## Purpose
+
+The PROD browser CSP smoke checks the XTend loader under a production-like Content Security Policy without using external networks or CDN fallbacks.
+
+The fixture uses:
+
+- a `nonce` for all inline and loader scripts
+- a same-origin manifest at `/tests/browser/fixtures/components/manifest.json`
+- the root-local loader `/xtend-loader.js`
+- no `importmap`
+- no `https://cdn.ccs-networks.de/xtend` reference
+- XState and XRouter as the minimal hydration line
+
+## Local Usage
+
+```bash
+npm run test:epic13-prod-browser-csp-smoke
+npm run dev:local:csp
+```
+
+The local server adds a `content-security-policy` header in addition to the fixture CSP meta tag. This allows the HTML file to be checked both statically and close to a server environment.
+
+## Boundaries
+
+This smoke is a production-close boot and policy preparation. The Trusted DOM check for Parsedown, RMT HTML fragments and untrusted content has lived under [Trusted DOM Boundary Browser Proof](./trusted-dom-boundary-browser-proof.md) and `xtend.epic13.trusted-dom-boundary.v1` since `WP-E13-11`.
+
+## Handoff
+
+`WP-E13-07` is complete. `WP-E13-08` normalized [Visual Owner Artifacts](./visual-owner-artifacts.md). `WP-E13-09` is ready and next bundles the RMT-first app production readiness.

package/docs/en/public-component-types.md

@@ -0,0 +1,79 @@
+# Public Component Types
+
+- Contract: `xtend.docs.public-component-types.v1`
+- Type contract: `xtend.enterprise.er-wp-34.public-component-types.v1`
+- Workpackage: `ER-WP-34`
+
+XTend ships local TypeScript declaration artifacts next to the respective runtime source for prioritized public components. The files live directly in `components/*.d.ts` and become reachable through the package export `xtend/components/*`.
+
+## Local Contract
+
+```text
+components/xtend-public-types.d.ts
+components/xalert.d.ts
+components/xtoast.d.ts
+components/xmodal.d.ts
+components/xrouter.d.ts
+components/xlink.d.ts
+components/xinput.d.ts
+components/xselect.d.ts
+components/xcheckbox.d.ts
+components/xradio.d.ts
+components/xtextarea.d.ts
+components/xstatus.d.ts
+components/xprogress.d.ts
+components/xtooltip.d.ts
+components/xpopover.d.ts
+components/xdrawer.d.ts
+components/xform.d.ts
+components/xtabs.d.ts
+components/xdialog.d.ts
+components/xlightbox.d.ts
+components/xcalendar.d.ts
+components/xwriter.d.ts
+components/xtheme.d.ts
+components/xbutton.d.ts
+components/xspinner.d.ts
+components/xmenu.d.ts
+components/xsummary.d.ts
+components/xplayer.d.ts
+components/xsection.d.ts
+components/xcards.d.ts
+components/xheader.d.ts
+components/xfooter.d.ts
+components/xhero.d.ts
+components/xtype.d.ts
+components/xcode.d.ts
+components/xmasonry.d.ts
+components/xstate.d.ts
+components/xutils.d.ts
+```
+
+Each component file describes:
+
+- public attribute names
+- public property and method surfaces
+- event names
+- `CustomEvent` detail payloads
+- `HTMLElementTagNameMap` for custom elements
+- typed `addEventListener` overloads for component-specific events
+
+`x-theme` is not a custom element, but a core module. Its types therefore describe `window.XTend.theme`, `window.XTheme`, a11y preference snapshots, motion/contrast policy, density, theme context, performance snapshot, RMT metadata and the document events `theme-initialized`, `theme-changed`, `theme-variable-changed`, `theme-preference-changed`, `theme-a11y-announcement`, `theme-density-changed`, `theme-context-changed` and `theme-performance-measured`.
+
+## Gate
+
+```bash
+node scripts/run_xtend_tests.js components
+```
+
+As of `ER-WP-34`, the component suite contains the subgate `component-public-types`. After `RC1TB-WP-03`, it checks the shared type helpers, all 44 prioritized `.d.ts` files, event names, detail types, API methods and element/window mappings.
+
+As of `WP-TypeExports-09`, the component wildcard export is also covered in the productive TypeExports handoff. `./components/*` remains an adjacent-declaration boundary: consumers receive `components/*.d.ts` through neighboring files, while `node scripts/run_xtend_tests.js type-exports --json` prevents new public component exports from entering the package surface without a type decision.
+
+## Coverage Status
+
+After `RC1TB-WP-03`, `types` in the Component Catalog Coverage Matrix are at `44/44`. `x-input`, `x-select`, `x-checkbox`, `x-radio`, `x-rmt-lifecycle-demo-build`, `x-textarea`, `x-form`, `x-calendar`, `x-writer`, `x-status`, `x-progress`, `x-tooltip`, `x-popover`, `x-drawer`, `x-surface-manager`, `x-surface-portal`, `x-surface-region`, `x-surface-window`, `x-side-panel`, `x-modal`, `x-dialog`, `x-alert`, `x-toast`, `x-spinner`, `x-router`, `x-link`, `x-tabs`, `x-theme`, `x-button`, `x-icon`, `x-menu`, `x-footer`, `x-lightbox`, `x-masonry`, `x-code`, `x-header`, `x-hero`, `x-type`, `x-summary`, `x-section`, `x-cards` and `x-player` are the current `enterprise-ready` reference line with public types, component suite, fixture, a11y and performance profile. `xstate` has public types for boundary contract, RMT state adapter, lifecycle events and diagnostics. `x-utils` has public types for utility contract, import policy, boundary snapshot, UI effects, template API and the events `xutils:import-policy-check` and `xutils:ui-effects-change`.
+
+After `WP-E12-09`, no type gap remains. Since `WP-E13-05`, the earlier boundary residuals are also closed: `xstate` is `closed-as-runtime-boundary`, `x-utils` is `closed-as-utility-boundary`. Both remain public type boundaries, but no open type or performance tasks.
+
+The previous vendor boundaries `components/prism.js` and `components/turndown.js` have narrow facade declarations as of `WP-TypeExports-08`. They are not public XTend UI components, but are checked by the TypeExports release gate against unintended declaration drift.

package/docs/en/quick-start-guide.md

@@ -0,0 +1,189 @@
+# Quick Start Guide
+
+This guide takes you from a local XTend page to a small RMT vNext app shell. The fastest first step is still HTML with Web Components; the recommended growth path for apps is RMT-first.
+
+## Requirements
+
+- Node.js 18 or newer
+- a local checkout of the XTend repository
+- a browser with Custom Elements and ES Module support
+
+Start the local dev server:
+
+```bash
+npm run dev:local
+```
+
+The server usually serves the app at `http://127.0.0.1:4173/`.
+
+## 1. Start a Minimal Host
+
+Create an HTML file in the project, for example `quick-start.html`:
+
+```html
+<!doctype html>
+<html lang="en">
+<head>
+  <meta charset="utf-8">
+  <meta name="viewport" content="width=device-width,initial-scale=1">
+  <meta name="xtend-preload" content="x-theme,x-section,x-button">
+  <title>XTend Quick Start</title>
+  <script
+    type="module"
+    src="/xtend-loader.js"
+    data-manifest="/components/manifest.json">
+  </script>
+</head>
+<body>
+  <main>
+    <x-section layout="column" label="Quick Start">
+      <h1>Hello XTend</h1>
+      <p>This app runs with local Web Components.</p>
+      <x-button variant="primary">Get started</x-button>
+    </x-section>
+  </main>
+</body>
+</html>
+```
+
+Then open `http://127.0.0.1:4173/quick-start.html`.
+
+What happens here?
+
+- `xtend-loader.js` is the local loader.
+- `components/manifest.json` is the component registry.
+- `meta name="xtend-preload"` loads critical modules early.
+- `x-theme` is an infrastructure module; `x-section` and `x-button` are
+  normal XTend Web Components.
+- `/xtend.css` is optional host theming.
+
+## 2. Describe the App Shell in RMT vNext
+
+When the page becomes an app, the shell should live in RMT. RMT vNext describes UI structure, state, actions, events, surfaces, and scheduling in a readable `.rmt` source.
+
+```rmt
+template quickstart.app {
+  state counter type number initial 0
+
+  selector counterLabel from state counter {
+    output text
+  }
+
+  action increment {
+    input amount number
+    reduce state.counter = input.amount
+    emit counter.changed with action increment
+  }
+
+  portal app root "#app-root" layer surface
+
+  surface home kind page component x-section {
+    source state counter
+    portal app
+    key route.path
+
+    lane visible weight 80 {
+      hydrate x-section from state counter
+    }
+
+    on click target button.primary -> action increment {
+      payload amount from 1
+    }
+  }
+}
+```
+
+This document is the app description. The compiler turns it into Core and kernel records that host adapters can connect to XTend Components, XRouter, and Fabric.
+
+## 3. Materialize XTend UI from RMT
+
+Runtime hosts connect RMT descriptors with the existing XTend components from
+the manifest through the Component Capability Registry. Component Contracts,
+events, slots, parts, and state bindings stay the shared source of truth:
+
+```js
+import {
+  createRmtComponentCapabilityRegistry
+} from '@ccslabs/xtend/rmt/component-capability-registry';
+import {
+  createRmtDomDescriptorRenderer
+} from '@ccslabs/xtend/rmt/dom-descriptor-renderer';
+
+const registry = createRmtComponentCapabilityRegistry({ manifest, sourceTexts });
+const renderer = createRmtDomDescriptorRenderer({ documentTarget: document });
+
+renderer.renderKeyed(root, [
+  registry.buildComponentDescriptor({
+    tag: 'x-button',
+    key: 'primary-action',
+    attributes: { variant: 'primary' },
+    slots: { default: { text: 'Get started' } },
+    events: { click: 'quickstart.increment' }
+  })
+], {
+  componentRegistry: registry,
+  dispatchEvent: actions.dispatch,
+  stateBridge
+});
+```
+
+That lets RMT primitives use XTend UI without Shadow-DOM patches,
+component-specific renderers, or manual HTML sinks.
+
+## 4. Server-Prerender with Node
+
+Node hosts can use the same RMT description for SSR and incremental JSONL. The
+adapter stays framework-neutral and does not start its own HTTP server:
+
+```js
+import {
+  createRmtNodeSsrAdapter
+} from '@ccslabs/xtend/rmt/node-ssr-adapter';
+
+const adapter = createRmtNodeSsrAdapter({ manifest, sourceTexts });
+const result = await adapter.render({ source, filePath: 'app.rmt' });
+```
+
+PHP/Laravel hosts use the same client-facing wire shape through the single-file
+module:
+
+```php
+require __DIR__ . '/xtendrmt/rmt-php-ssr-adapter.php';
+
+$adapter = createRmtPhpSsrAdapter(['manifest' => $manifest]);
+$result = $adapter->render(['coreDocument' => $coreDocument]);
+```
+
+See [RMT Node SSR Adapter](./rmt-node-ssr-adapter.md) and
+[RMT PHP/Laravel SSR Adapter](./rmt-php-ssr-adapter.md).
+
+## 5. Check RMT Locally
+
+```bash
+xt rmt lint app.rmt
+xt rmt lint app.rmt --json
+xt rmt lint app.rmt --agent
+```
+
+The agent report contains `repairPlan`, `fixOrder`, `confidence`, `impact`, `relatedDiagnostics`, and explained no-ops for repairs that intentionally stay manual.
+
+## 6. Enable Editor Support
+
+```bash
+node tools/rmt-language-server/server.js
+```
+
+The server provides diagnostics, completion, hover, document symbols, definition, and code actions. For a minimal native app shell, use the `rmt-app` snippet prefix; for vNext primitives, `rmt-vnext-primitive-shell` is the fastest start.
+
+## Next Steps
+
+- [RMT vNext Authoring Guide](./rmt-vnext-authoring.md)
+- [RMT vNext Component Primitives and XTend UI](./rmt-vnext-component-primitives.md)
+- [RMT Node SSR Adapter](./rmt-node-ssr-adapter.md)
+- [RMT PHP/Laravel SSR Adapter](./rmt-php-ssr-adapter.md)
+- [XTendRMT Developer Overview](./xtendrmt-overview.md)
+- [RMT Linter and AI-Agent Repair Report](./rmt-linter.md)
+- [RMT Language Server and Editor Setup](./rmt-language-server.md)
+- [XTend Loader](./xtend-loader.md)
+- [Manifest Format](./manifest.md)
+- [Component Development](./components.md)