docs: trim deeply-technical implementation detail from pitch pages

The "For X teams/shops" pages are persuasive intros aimed at framework
users who haven't adopted Rozie yet. Mid-pitch detours into compiler
implementation (verbatim emit dumps, per-target lowering catalogs,
modifier-grammar caveats) break the pacing — the reader has been told
"Rozie handles this for you", then handed twenty lines of the handler.

- `for-react-teams.md` — drop the `useControllableState` emit dump; the
  pitch is the consumer code, not the compiler's controllable-state
  glue. Strip "the compiler walks the auto-tracked signal reads inside
  $onMount, $watch, and <listeners> blocks" from the exhaustive-deps
  paragraph — landing the result without the internals.
- `for-angular-shops.md` — drop the verbatim `rozie-out SearchInput
  angular` reassurance block (the contrast is already made by the
  upstream "what Angular shops typically write" handwritten block);
  link to the example page instead. Lighten the "Not in v1" caveats
  list (modifier valueTransform, $watch ordering, TS floor) into a
  one-paragraph "Documented edges" pointer to /parity + /compatibility.
- `for-lit-teams.md` — replace the inline `@property/repeat/html`
  bridge emit example with the consumer-side fill; replace the
  long-form "Note the canonical Lit shape: @CustomElement decorator,
  SignalWatcher(LitElement) from @lit-labs/preact-signals, @Property
  decorators, rozieSpread directive…" paragraph with a one-sentence
  "canonical LitElement subclass" summary plus a link out. Compress
  the "Documented edges" three-bullet caveats block into a single
  pointer paragraph.
- `for-vanilla-js-shops.md` — soften the per-target-lowering catalog
  in "compiler invariants" (drop `this._ref__rozieRoot` on Lit,
  `getCurrentInstance()?.vnode.el` on Vue, per-target reactive-primitive
  listing) — the reader doesn't need the implementation-name receipt to
  trust the claim. Strip the CI test-path internals
  (`packages/core/tests/engine-examples.compile.test.ts — 14 × 6 = 84`)
  in favor of a plain claim.

Verified: docs build clean. Net -70 lines.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Author: serpentblade

docs/guide/for-angular-shops.md

@@ -113,20 +113,12 @@ export class SearchInput {
 ```rozie-src SearchInput
 ```
 
-#### What the Rozie compiler emits for the `angular` target
-
-This block is compiled live by `@rozie/core` on every docs build. The
-source above is the input; the code below is the verbatim output.
-
-```rozie-out SearchInput angular
-```
-
-The Rozie source is roughly a third the size and reads top-to-bottom. The
-compiled output is **structurally equivalent** to the hand-written
-version — the same `signal()` / `input()` / `output()` / `viewChild()` /
-`inject(DestroyRef)` / `ngAfterViewInit` machinery, with `@for` / `@if`
-blocks and `FormsModule`-backed `r-model` lowering. You don't see it
-during authoring. You import it normally:
+Roughly a third the size, reads top-to-bottom, no decorator soup. The
+compiler emits an idiomatic Angular standalone component using the same
+`signal()` / `input()` / `output()` / `viewChild()` / `inject(DestroyRef)`
+machinery you'd write by hand — see the
+[SearchInput example page](/examples/search-input) for the full Angular
+output. You don't see it during authoring. You import it normally:
 
 ```ts
 // app.component.ts
@@ -227,17 +219,13 @@ delete the `.rozie` source, and the `.ts` works on its own. Zero lock-in.
   reference + engine-wrapper examples)
 - ChangeDetection: signal-driven, no zone.js round-trips for state updates
 
-### Not in v1 (documented edge)
-
-- **Modifier `valueTransform` must be a pure expression**, not a statement
-  block — Angular's template parser splices the fragment verbatim into a
-  binding expression. (`registerModifier()` plugins targeting Angular
-  should keep the `valueTransform` short and expression-shaped.)
-- **`$watch` vs `$onMount` ordering**: immediate `$watch` fires *before*
-  `$onMount` on Angular (and Vue). React/Svelte/Solid/Lit fire it after.
-  Engine-wrapper reconcilers should be idempotent no-ops to stay safe.
-- **TypeScript floor 5.6+** — Angular 19's own peer dep is `>=5.5.0 <5.9.0`,
-  which sits inside our floor. Older TS isn't tested.
+### Documented edges
+
+A handful of small Angular-specific edges (custom modifier value-transforms
+must be pure expressions; immediate `$watch` fires before `$onMount` on
+Angular and Vue but after on the other targets; TypeScript 5.6+ required)
+are described in [Cross-Framework Parity](/parity) and
+[Compatibility](/compatibility).
 
 ## Why Angular shops in particular
 

docs/guide/for-lit-teams.md

@@ -22,58 +22,20 @@ Lit's `<slot>` element projects light-DOM children into shadow DOM by name. It d
 
 Community workarounds: serialize params as JSON into `data-*` attributes, hand-roll a "fillSlot" property API, or expose imperative methods the consumer queries. Each is a bespoke surface in every Lit component.
 
-Rozie's compiler emits the canonical version of one of these (the typed property-fill bridge) on your behalf:
-
-```rozie
-<rozie name="ItemList">
-<props>
-{ items: { type: Array, default: () => [] } }
-</props>
-<template>
-<ul>
-  <li r-for="item in $props.items" :key="item.id">
-    <slot name="row" :item="item" />
-  </li>
-</ul>
-</template>
-</rozie>
-```
-
-What the compiler emits:
-
-```ts
-// Producer-side (simplified):
-@property({ attribute: false })
-row?: (scope: { item: Item }) => unknown;
-
-render() {
-  return html`
-    <ul>
-      ${repeat(this.items, (item) => item.id, (item) =>
-        this.row !== undefined
-          ? html`<li>${this.row({ item })}</li>`
-          : html`<li><slot name="row"></slot></li>`
-      )}
-    </ul>
-  `;
-}
-```
-
-The consumer authors a typed render function:
-
-```html
-<item-list .items=${items} .row=${({ item }) => html`<strong>${item.name}</strong>`}></item-list>
-```
-
-Or, for a Rozie-authored consumer, the standard slot-fill syntax — Rozie compiles the bridge call automatically:
+Rozie compiles a typed property-fill bridge on your behalf. The producer
+declares its slot the normal way; the consumer fills it with the same
+syntax used on any other target:
 
 ```rozie
 <ItemList :items="$data.items">
   <template #row="{ item }"><strong>{{ item.name }}</strong></template>
 </ItemList>
 ```
 
-Same authoring shape as a Vue scoped slot. Same emitted compose surface as a hand-rolled Lit fill-API. Zero boilerplate either side.
+Same authoring shape as a Vue scoped slot. Same emitted compose surface as
+a hand-rolled Lit fill-API. Zero boilerplate either side. Plain-HTML
+consumers fill the slot via the corresponding `.row=${(scope) => html`…`}`
+property splice — fully typed off the producer's `.d.ts`.
 
 ### Consumer CSS doesn't reach into shadow DOM
 
@@ -127,19 +89,15 @@ Rozie's compile-time dispatch handles dynamic slot names on every target includi
 
 ## What you write vs. what Lit sees
 
-The canonical `examples/SearchInput.rozie` compiles to a working Lit Web Component. Below is the source + the verbatim Lit emit produced by `@rozie/core` on every docs build.
-
-### The Rozie source
+The canonical `examples/SearchInput.rozie` compiles to a working Lit Web Component:
 
 ```rozie-src SearchInput
 ```
 
-### What the Rozie compiler emits for the `lit` target
-
-```rozie-out SearchInput lit
-```
-
-Note the canonical Lit shape: `@customElement('rozie-search-input')` decorator, `SignalWatcher(LitElement)` from `@lit-labs/preact-signals` for reactivity, `@property` decorators on each declared prop (with `reflect: true` where appropriate), `render()` returning a lit-html template, paired `disconnectedCallback()` cleanup. The `rozieSpread` and `rozieListeners` directives are tiny runtime helpers (~30 LOC each) that handle attribute fallthrough and listener fallthrough at lit-html part level — the same machinery your hand-written components would replicate.
+The compiled output is a canonical `LitElement` subclass — `@customElement`
+decorator, `@property`-declared reactive properties, `render()` returning a
+lit-html template, paired `disconnectedCallback()` cleanup. See the
+[SearchInput example page](/examples/search-input) for the full Lit emit.
 
 The compiled file is a valid, ready-to-`customElements.define`, fully-typed Lit component. You import it like any Web Component:
 
@@ -214,11 +172,11 @@ Three audiences in particular:
 
 ## Documented edges
 
-The Lit target has a few v1 edges, documented in the [Cross-Framework Parity](/parity) page:
-
-- **Scoped-slot params transport via a property-fill bridge** (vs. native template slots on the other targets). Same authoring shape via the `<template #name="{ … }">` syntax; the bridge is invisible to authors. The bridge uses `data-rozie-s-<hash>` scoping for consumer-CSS reach (documented above).
-- **`$onMount` / `$onUnmount` on always-rendered components**: see [the parity note](/parity#lit-solid-—-lifecycle-hooks-colocated-with-an-always-rendered-component) — `connectedCallback` / `disconnectedCallback` semantics differ from React `useEffect`-style mount/unmount in edge cases (a component that's removed from the DOM and re-attached fires both, where React's mount-once contract holds across StrictMode but breaks across portal-detach-and-reattach).
-- **Engine DOM mutation** needs `$reconcileAfterDomMutation()` — documented escape hatch.
+A few small Lit-target edges (scoped-slot params travel via a property-fill
+bridge rather than native template slots; `$onMount` / `$onUnmount` timing
+on always-rendered components differs slightly from React; engine DOM
+mutation needs the `$reconcileAfterDomMutation()` escape hatch) are
+described in [Cross-Framework Parity](/parity).
 
 ## Next steps
 

docs/guide/for-react-teams.md

@@ -132,11 +132,11 @@ CSS Modules hashes class names at build time. That means any code that reference
 
 ### Statically-computed `useEffect` dep arrays
 
-`eslint-plugin-react-hooks/exhaustive-deps` is the lint rule everyone respects and quietly hates. With Rozie, you don't write the dep array — the compiler walks the auto-tracked signal reads inside `$onMount`, `$watch`, and `<listeners>` blocks and emits the correct array. Every reference example passes `exhaustive-deps` cleanly on output.
+`eslint-plugin-react-hooks/exhaustive-deps` is the lint rule everyone respects and quietly hates. With Rozie, you don't write the dep array — the compiler emits the correct one from the lifecycle hook's body. Output passes `exhaustive-deps` cleanly.
 
 ### StrictMode double-fire safety
 
-`$onMount` returning a cleanup function lowers to one `useEffect` with a cleanup return — the canonical React 18 StrictMode-safe pattern. All reference examples + engine-wrapper demos validated under `<React.StrictMode>`.
+`$onMount` returning a cleanup function lowers to one `useEffect` with a cleanup return — the canonical React 18 StrictMode-safe pattern.
 
 ### Static error on prop mutation
 
@@ -150,21 +150,7 @@ The single most common React-component bug class (mutating a prop instead of cal
 
 ### Two-way binding that doesn't require a state-management library
 
-The React `useControllableState` pattern lives in every component library that does headlessly-controllable components (Radix, Headless UI, React Aria, etc.) — each implementation is a hand-rolled bit of glue. Rozie compiles `model: true` to the canonical hybrid:
-
-```ts
-// What you write:
-// <props>{ open: { type: Boolean, default: false, model: true } }</props>
-
-// What Rozie emits for React (simplified):
-const [open, setOpen] = useControllableState({
-  value: props.open,
-  defaultValue: false,
-  onChange: props.onOpenChange,
-});
-```
-
-Consumer code stays vanilla React:
+The React `useControllableState` pattern lives in every component library that does headlessly-controllable components (Radix, Headless UI, React Aria) — each one re-implements the same glue. Declare `model: true` on a `<props>` member and Rozie emits the canonical controllable-state pair for you. Consumer code stays vanilla React:
 
 ```tsx
 // Controlled

docs/guide/for-vanilla-js-shops.md

@@ -170,30 +170,28 @@ import { SortableList } from '@your-org/components';
 
 ## The compiler invariants that make this work
 
-A handful of engine-wrapper-specific compiler features have already shipped
+A handful of engine-wrapper-specific compiler features have shipped
 specifically because vanilla-JS engines are common Rozie use cases. You
 can rely on them:
 
-- **`$el` lowers to the right per-target host element** — `this._ref__rozieRoot`
-  on Lit, `el.nativeElement` on Angular, the root JSX ref on
-  React/Solid/Svelte, `getCurrentInstance()?.vnode.el` on Vue.
+- **`$el` lowers to the right per-target host element** so engine
+  constructors that take a DOM node always get the right one.
 - **`$onMount` returning a cleanup function** is the right shape on every
   target. No `useEffect` ceremony, no `DestroyRef` boilerplate.
 - **`$watch(() => $props.x, (v) => …)`** lowers to each target's idiomatic
-  reactive primitive (`watch` / `useEffect` / `$effect` / `effect` /
-  `createEffect` / `updated()`). The callback param is correctly bound on
-  all six targets.
+  reactive primitive. The callback fires when the watched expression
+  changes and the new value is bound correctly on all six targets.
 - **`$reconcileAfterDomMutation()`** is the escape hatch when the engine
   mutates DOM under the framework's feet — no-op on five targets,
-  Lit-specific `render(nothing, host) + requestUpdate()` on Lit.
-- **`$classSelector('grip')`** survives React's CSS-Modules class hashing —
-  lowers to `"." + styles.grip` on React, `".grip"` literal on every other
-  target. Engines that take a `handle: '.grip'` option Just Work.
-- **Round-trip guards on two-way bound engine state**: when the engine
-  fires its change event you write `$props.x = newValue`; the wrapper's own
-  `$watch` then sees the change and would push it back. Common pattern:
-  guard with `if (newValue !== getCurrentEngineValue()) updateEngine(newValue)`
-  inside the `$watch`. Documented in [the SortableList example](/examples/sortable-list).
+  active on Lit where lit-html's `repeat` cache needs the nudge.
+- **`$classSelector('grip')`** survives React's CSS-Modules class hashing.
+  Engines that take a `handle: '.grip'` option Just Work everywhere.
+- **Round-trip guards on two-way bound engine state.** When the engine
+  fires its change event you write `$props.x = newValue`; the wrapper's
+  own `$watch` then sees the change and would push it back. Common
+  pattern: guard with `if (newValue !== getCurrentEngineValue())
+  updateEngine(newValue)` inside the `$watch`. Documented in
+  [the SortableList example](/examples/sortable-list).
 - **TypeScript `as` / `satisfies` annotations** in `<data>` block
   initializers — `selected: null as Item | null` keeps the field
   discriminated instead of degrading to `null` / `any`.
@@ -213,9 +211,9 @@ test of the compiler's engine-wrapper substrate:
 | **Uppy** | Multi-event emit chain, streaming progress, engine-state snapshotting |
 | **FullCalendar** | Date-typed array elements, object spread inside engine calls, structured-payload multi-emit, portal-slot fills |
 
-All seven are gated by
-`packages/core/tests/engine-examples.compile.test.ts` — 14 `.rozie` files ×
-6 targets = 84 byte-identical compiled outputs on every commit.
+Each wrapper compiles to byte-identical output across all six targets on
+every commit — the engine-wrapper substrate is the most heavily-pinned
+surface in the test suite.
 
 ## Cross-framework leverage — the math