@reqvire-org/ads 0.3.18 → 0.3.20

package/dist/skills/ads-import/references/review.md

@@ -0,0 +1,96 @@
+# Development-only review UI
+
+Read this when creating or migrating demo frames, preview sizing helpers, token
+renderers or demonstration controls. MCP serves it as `ads://guides/review`.
+
+## Responsibilities and boundaries
+
+Components provide cohesive production capabilities. Patterns provide reusable
+application structures/workflows. Both receive variable application data and
+callbacks through their APIs. Their scenarios import the same implementation
+used by the application and supply fixtures; do not create a second implementation
+that only looks correct in the showcase.
+
+`design-system/review/` owns development-only presentation: example frames,
+arrangement, demonstration controls, token sample renderers and their styles.
+It remains project-owned. The MCP host shell stays generic; review code executes
+inside the preview App with the project's framework, foundation, fonts and styles.
+Nothing depends on particular helper names or an imported component library.
+
+The development entry defaults to `review/index.ts` relative to `dsDir`; configure
+`reviewEntry` for another script inside `review/`. Its import alias is the
+configured `publicAlias` plus `/review`, normally `@ds/review`. Discover the actual
+entry/alias through `ads_status.project.review`. Export helpers there, never from
+the production public barrel. Review implementations, types and styles must not
+enter application, component, pattern or controller dependencies. Tests, fixtures,
+scenarios and preview mounts can consume review code.
+
+Review helpers can own Linaria presentation, local state and demo controls. Normal
+style-token, variable ownership, measured-style-write and application separation
+gates still apply. They consume deliberate public component/pattern/controller
+contracts and may reuse local foundation helpers. They cannot target private
+component styles or replace real product behavior. Keep one-off fixture data in
+the scenario; a helper need not become a product API to frame an example.
+
+## Scenario and token contracts
+
+```tsx
+import { Panel } from "@ds";
+import { ReviewFrame } from "@ds/review";
+import { fixture } from "./Panel.fixture";
+
+export const scenario = { title: "Panel", covers: ["Panel"] };
+export default function Scenario() {
+  return <ReviewFrame><Panel {...fixture} /></ReviewFrame>;
+}
+```
+
+The names above are illustrative. `covers` names the production subjects actually
+demonstrated, not every review wrapper. A review export has no product catalogue
+entry and needs no standalone catalogue scenario. Keep review unit tests/specs
+beside their owner; optional behavior contracts can verify review guarantees
+through an existing real scenario. They establish no production coverage.
+
+A token scenario may name its real review renderer in `covers`, import it from
+the development entry, declare `samples: fixture.samples`, and pass those samples
+into the renderer. Existing real product patterns may also serve as token UI.
+Empty covers, unused samples, fabricated tokens and plain value lists remain
+invalid. The rendered App must still pass token-binding checks. See
+[scenarios.md](scenarios.md) for the full token/render contract.
+
+Review class helpers can supply source-proven Linaria classes to a scenario.
+Arbitrary scenario classes/styles remain forbidden. A review wrapper's own native
+controls do not authorize arbitrary native controls in its consuming scenario;
+slot/selector exceptions still need actual production-owner evidence. Keep
+production and review export names distinct where `covers` would be ambiguous.
+
+## Build and guarded edits
+
+The normal preview plugin registers the exact review alias before broader product
+aliases. Configure the same alias in project TypeScript and any independent
+preview/dev harness. In an ordered bundler alias map, put `@ds/review` before
+`@ds`; the broad `@ds` mapping must not resolve it as `index.ts/review`.
+Production entrypoints never import the development entry. Inspect the product
+bundle for review modules/CSS; passing static checks does not prove bundle parity.
+
+Use `ads_units` for `review/<Owner>` units. Scenarios, local specs and helper files
+follow ordinary flat/directory ownership. A review patch may update only its own
+re-exports in the development entry and its own documented style boundaries.
+Product owners retain the separate production entry companion. Use prepared
+patches/dry runs and coupled transactions as described in
+[guarded-editing.md](guarded-editing.md); do not bypass a rejected mutation.
+
+For an existing project, identify helpers by responsibility and actual consumers,
+not names or the number of imported components. Preserve real application patterns.
+Move only demo helpers, their styles and relevant guides to `review/`; update
+scenario/preview imports, style-boundary paths, TypeScript/bundler aliases and
+links. Remove their production exports and obsolete standalone product scenarios.
+Do not copy old example fixtures or export demonstration controls as product UI.
+
+Upgrade ADS before migrating a consuming project: older versions do not know the
+separate review entry. For staged guarded edits, first add distinctly named review
+exports, migrate consumers in passing owner patches, then remove the old pattern
+exports/owners once unused. Required coupled changes use a transaction. Check
+source gates, typecheck, preview and production builds, real browser rendering,
+registered behaviors and token bindings. A source move alone establishes none
+of those rendered guarantees.

package/dist/skills/ads-import/references/scenarios.md

@@ -34,10 +34,31 @@ do not add scenario `preventDefault` handlers merely to hide it. Explicit App
 bases retain their declared behavior and CSP requirements; external hosts own
 their document-loading policy. Verify link activation as well as rendering.
 
+## Forms inside Apps
+
+Use real form semantics and the runtime owner's intended submit handler. ADS's
+showcase and diagnostic explorer permit `allow-forms` at every iframe layer,
+including legacy widgets. Browser constraint validation, Submit clicks, Enter and
+`requestSubmit()` can reach the normal submit path. Client-side forms call
+`preventDefault()` in their submit handlers; the host does not synthesize clicks
+or submit events. Native action requests are blocked by CSP `form-action 'none'`.
+Submit effects that use tools or resources still follow the MCP bridge.
+
+If a click fires but the `submit` handler never runs, inspect the browser's sandbox
+diagnostic and every ancestor iframe's permissions. Distinguish that host problem
+from native constraint validation legitimately preventing submission. Do not add
+scenario click interception to disguise a missing sandbox permission. External
+MCP hosts control their own sandbox/CSP policy.
+
+Verify an invalid submit, a valid submit, implicit Enter submission and the promised
+state effects. A working Next button is not evidence that form submission works.
+Keep native action navigation separate from client-side submission behavior;
+`allow-forms` does not grant host DOM access or top-level navigation.
+
 ## Owner-local token previews load their own definitions
 
 Keep the registered token sheet imported by its runtime owner for product use.
-A colocated `kind: "tokens"` scenario may render only the public review pattern
+A colocated `kind: "tokens"` scenario may render only the development-only review renderer
 with its fixture samples. Discovery adds the registered owner sheet to the
 generated record's `stylesheets`; `previewEntriesPlugin` imports those paths
 into the token preview independently of the runtime component. Custom builders
@@ -91,7 +112,7 @@ These examples describe verification mistakes, not component-specific rules:
 
 | Situation | Do not | Do instead |
 |-----------|--------|------------|
-| A reference example sets `width: 15rem`, while the native popup uses its default width. | Remove the reference width and claim the original example now matches. | Keep the baseline intact. Reproduce demo sizing through the project's public review/layout pattern or supported style helper. If a different native size is intentional, document it. Label any additional normalized comparison separately. |
+| A reference example sets `width: 15rem`, while the native popup uses its default width. | Remove the reference width and claim the original example now matches. | Keep the baseline intact. Reproduce demo sizing through the project's development-only review helper or supported style helper. If a different native size is intentional, document it. Label any additional normalized comparison separately. |
 | Static tracing cannot prove that a public clear control renders when a value is selected. | Remove its export, drop its required coverage, or change runtime behavior merely to pass the gate. | Preserve the intended public API. Try a meaningful selected-state fixture or another real scenario. If valid rendering remains untraceable, report the tooling limitation with a small reproduction. |
 | A screenshot shows the clear control in a selected state. | Treat its presence as evidence that clearing works. | Add a browser check: start selected, activate Clear, assert the value and selection are empty, verify the control's resulting visibility and documented focus behavior, then select again. |
 
@@ -207,6 +228,6 @@ An `exercises` entry records behavioral use; it never grants styling permission.
 Keep helper signatures compatible with the product API. Fix ownership/provenance
 in the runtime owner when genuinely wrong; retain intentional public APIs when
 reporting an unsupported trace. Demo-only sizing, framing and arrangement still
-belong in public review/layout patterns. A style helper is not permission to
+belong in development-only review helpers. A style helper is not permission to
 author a second design in the scenario. For cascade risks and extraction issues,
 read [atomic-styles.md](atomic-styles.md).

package/dist/skills/ads-migrate/SKILL.md

@@ -56,6 +56,19 @@ one `ads_investigate({unit,check,runId})` summary before changing APIs or policy
 load request/error/artifact details only when relevant.
 
 
+Review/demo layout belongs in development-only `review/`, exported through the
+separate `${publicAlias}/review` entry (normally `@ds/review`), never the production
+barrel. Product patterns are application UI. For ownership, migration, token
+renderers, build aliases or `review-import` / `review-contract` diagnostics, read
+[development review UI](references/review.md), also served as `ads://guides/review`.
+
+A component provides one cohesive UI capability; a pattern arranges capabilities
+into reusable structures or workflows. Components may compose components/controllers;
+layout patterns may arrange slots. Do not classify by component count. For owner
+selection or `component-dependency`, `component-contract` or `component-style`, read
+[layer responsibilities and contracts](references/layers.md), also served as
+`ads://guides/layers`. Preserve public APIs and documented non-state styling hooks.
+
 For parent/child `covers`, conditional-control review, reference comparisons,
 public style-helper use, native slot/selector composition, fragment navigation,
 or `scenario-render` / `showcase-control` / `showcase-class` findings, read [scenario contracts](references/scenarios.md). Its verification
@@ -269,7 +282,7 @@ fixture under the configured token directory. Declare metadata
 The renderer name is project-owned; use its real public API. Each literal fixture
 sample declares `{ token, property, probe }`: a real token, the CSS property its
 sample demonstrates, and a valid test value different from that token's current
-value. Pass `samples` into the rendered public review pattern. Names, sample text,
+value. Pass `samples` into the rendered development-only review renderer. Names, sample text,
 bindings and probes are fixture data; displayed values come from foundation CSS.
 There is no property catalogue, token-name mapping or probe palette in ADS.
 Every token needs sample coverage; fabricated tokens, missing bindings/probes,
@@ -290,10 +303,12 @@ source definitions and values; inspecting definitions does not prove UI parity.
 The tool keeps the shared naming contract; sample templates and their token
 lists belong to the project.
 
-A public review pattern may be covered by real token or composition scenarios;
-it needs no redundant standalone entry. Remove an optional scenario only while
-retaining reachable render coverage. Keep directory ownership anchored by its
-runtime entry (`index` or a file matching the directory name) or colocated fixture.
+Development review helpers need no product catalogue scenario. A token scenario
+may name its review renderer in `covers`; ordinary component/pattern scenarios
+cover their production subjects. Keep review exports in the separate review entry.
+Remove redundant helper catalogue scenarios during migration. Product UI retains
+its real render-coverage requirement. Keep directory ownership anchored by its
+implementation entry (`index` or a file matching the directory name) or colocated fixture.
 Import colocated image/font fixtures so MCP serves them through asset resources.
 For a broken-image case, use a local failing fixture, rather than an external
 network failure or a domain-specific CSP exception. Production asset APIs remain
@@ -317,7 +332,7 @@ branch, property and value must fit its role. Token-backed control skins, layout
 interactive state rules and owner hooks are rejected even through `:where()`.
 Do not copy an unchecked upstream preflight or turn a component repair into a reset.
 Keep behavior and skin in their runtime owner. Put demo-only sizing and framing
-in a public review/layout pattern; add component props for a deliberate runtime
+in a development-only review helper; add component props for a deliberate runtime
 API need. Preserve required capabilities while following ownership rules.
 Use tokens for absolute/font-relative lengths, including `ch`, `ex`, `cap`, `ic`
 and `lh`; calculations and fallback values follow the same rule. Structural

package/dist/skills/ads-migrate/references/guarded-editing.md

@@ -103,7 +103,7 @@ and a definition-only `tokens.css`, imported by its runtime source. Flat owners
 shared or --ds-/--ux-/--showcase- variables. Only that owner consumes/defines its
 local tokens; aliases can use shared or own tokens. UI styles stay in Linaria.
 Add a colocated token scenario with `kind:"tokens"`, real fixture `samples` and a
-public review pattern. These inputs belong to the same owner and need real sample
+development-only review renderer. These inputs belong to the same owner and need real sample
 coverage. Manifests and fixtures stay out of the product bundle.
 
 `ads_prepare_token_samples({id, bindings?})` preserves existing project samples,

package/dist/skills/ads-migrate/references/layers.md

@@ -0,0 +1,123 @@
+# Components, patterns and application adapters
+
+Read this when choosing an owner, moving UI between layers, or resolving
+`component-dependency`, `component-contract`, `component-style`, `no-app-import`
+or `showcase-import`. MCP also serves this guide as `ads://guides/layers`.
+
+## Choose by responsibility
+
+A **component** provides one cohesive UI capability: semantics, input handling,
+focus, accessibility, states and appearance. It may compose other components and
+controllers. A notification using an icon, action button and spinner can still
+be one component.
+
+A **pattern** arranges capabilities and content slots into a reusable structure
+or workflow, such as navigation with search/account controls or a report screen.
+Layout parts may arrange `children` without importing several components.
+Patterns may compose other patterns. A native wrapper or a large implementation
+does not decide the layer.
+
+An **application adapter** supplies domain data, store access, route state and
+navigation/service callbacks. Domain-shaped inputs are valid in project-owned
+patterns; importing a particular application store/router is not.
+
+A **scenario** supplies demonstration inputs, local state and simulated services.
+A component scenario may compose several public components and development review helpers
+to demonstrate its subject. That does not turn its fixture or variant selectors
+into production API. Keep `covers` aligned with the scenario's subject layer.
+
+Do not classify by import count, JSX element count, names or file length. Review
+the capability and its consumer contract. Preserve valid APIs when tracing is
+inconclusive; do not make an export private or add a product prop just to pass.
+
+## Demonstrate the production implementation
+
+Product patterns are reusable application UI, not showcase replicas. A scenario
+imports the same production owner and supplies fixtures through its public API;
+the application supplies live data and callbacks to that API. Keep mock records,
+demo selections and simulated services in development files. Legitimate defaults,
+control labels and the pattern's own interaction logic remain with their owner.
+
+Demo framing must not replace a product pattern's styling or behavior. Browser
+checks should exercise both the demonstrated contract and relevant application
+integration; a successful showcase does not establish production parity. A new
+pattern need not already have an application consumer, and import counts cannot
+detect a duplicated implementation. Existing import guards prevent fixture/test
+dependencies; review and browser checks must assess hardcoded mock data and
+unrepresentative rendering that source ownership alone cannot prove.
+
+Review framing belongs in development-only `review/`, not production patterns.
+Use the separate review entry and [review.md](review.md) for the migration and
+build contract.
+
+## Dependency contracts (blocking)
+
+- Component runtime may depend on components, shared controllers and lower-level
+  helpers. It cannot depend on patterns or composition, including indirectly
+  through aliases, forwarding exports, helpers or literal dynamic imports.
+  Type-only pattern references do not introduce runtime dependencies.
+- Patterns consume component symbols published by the configured public entry,
+  including intentional public types. A relative import of a public symbol is
+  allowed inside the ADS; requiring a self-import through the barrel can create
+  cycles. Private state, class blocks and implementation helpers stay internal.
+  A public component may use its own private implementation dependencies.
+- Runtime code cannot import review implementations/types/styles, scenarios, fixtures or checks, including through
+  forwarding exports. Scenarios also cannot import application source.
+- ADS implementations receive application data/effects through inputs and
+  callbacks. Re-exporting application stores, routers or services from a helper
+  does not make them part of the ADS.
+
+For example, `components/Control → shared/helper → patterns/Navigation` fails
+`component-dependency`. Extract a lower-level capability/controller, or move the
+arrangement to a pattern. `patterns/Navigation → components/Control` is valid
+when `Control` is public. Replacing that import with its private state helper
+fails `component-contract` even through a forwarding module.
+
+## Styling contracts (blocking when ownership is established)
+
+Components own their control states and appearance. Patterns own arrangement,
+spacing and their own presentation. Use typed component props/variants, an
+intentional public class helper/hook, or registered non-state customization
+variables. Registration does not authorize overriding interaction policy.
+
+```tsx
+// Component-owned implementation; the marker is not a consumer styling API.
+function Control() {
+  return <button><span className="control-private-label">Label</span></button>;
+}
+
+// Pattern: rejected because it styles the component's private rendered part.
+const wrong = css`
+  & .control-private-label { color: var(--text-muted); }
+`;
+
+// Pattern: its own arrangement remains valid.
+const layout = css`
+  display: flex;
+  gap: var(--space-4);
+`;
+```
+
+The source guard matches component-emitted class names and unambiguous literal
+data markers to the selector's styled subject, including `:is()`/`:where()`.
+It also rejects reads of known private component variables. It does not treat
+an ancestor predicate or `:has()` query as styling that ancestor/descendant:
+`[data-layout="expanded"] > & { gap: var(--space-4); }` changes the pattern's
+own arrangement. Public hooks and registered non-state variables remain valid.
+Token definitions, namespaces and writes retain their existing guards.
+
+Opaque/computed imports, generated selectors, ambiguous shared markers, forwarded
+consumer classes and arbitrary service abstractions are not a complete static
+proof. Passing source checks does not prove that every visual override is safe.
+Review the real rendered states, computed styles, keyboard interactions and
+responsive layouts; use registered browser checks for promised behavior.
+
+## Refactoring an owner
+
+Move runtime source, its scenarios/fixtures and guides together; update public
+exports, dependent imports and documented scenario IDs. Keep callers on the
+same intentional public API. Navigation stays in an application callback or a
+normal link supplied by the consumer, rather than a hidden router mutation in
+the pattern. Validate the complete migration with project checks, product and
+preview builds, and behavior tests. An existing guard rejection is not permission
+to write around the guarded editing workflow.

package/dist/skills/ads-migrate/references/review.md

@@ -0,0 +1,96 @@
+# Development-only review UI
+
+Read this when creating or migrating demo frames, preview sizing helpers, token
+renderers or demonstration controls. MCP serves it as `ads://guides/review`.
+
+## Responsibilities and boundaries
+
+Components provide cohesive production capabilities. Patterns provide reusable
+application structures/workflows. Both receive variable application data and
+callbacks through their APIs. Their scenarios import the same implementation
+used by the application and supply fixtures; do not create a second implementation
+that only looks correct in the showcase.
+
+`design-system/review/` owns development-only presentation: example frames,
+arrangement, demonstration controls, token sample renderers and their styles.
+It remains project-owned. The MCP host shell stays generic; review code executes
+inside the preview App with the project's framework, foundation, fonts and styles.
+Nothing depends on particular helper names or an imported component library.
+
+The development entry defaults to `review/index.ts` relative to `dsDir`; configure
+`reviewEntry` for another script inside `review/`. Its import alias is the
+configured `publicAlias` plus `/review`, normally `@ds/review`. Discover the actual
+entry/alias through `ads_status.project.review`. Export helpers there, never from
+the production public barrel. Review implementations, types and styles must not
+enter application, component, pattern or controller dependencies. Tests, fixtures,
+scenarios and preview mounts can consume review code.
+
+Review helpers can own Linaria presentation, local state and demo controls. Normal
+style-token, variable ownership, measured-style-write and application separation
+gates still apply. They consume deliberate public component/pattern/controller
+contracts and may reuse local foundation helpers. They cannot target private
+component styles or replace real product behavior. Keep one-off fixture data in
+the scenario; a helper need not become a product API to frame an example.
+
+## Scenario and token contracts
+
+```tsx
+import { Panel } from "@ds";
+import { ReviewFrame } from "@ds/review";
+import { fixture } from "./Panel.fixture";
+
+export const scenario = { title: "Panel", covers: ["Panel"] };
+export default function Scenario() {
+  return <ReviewFrame><Panel {...fixture} /></ReviewFrame>;
+}
+```
+
+The names above are illustrative. `covers` names the production subjects actually
+demonstrated, not every review wrapper. A review export has no product catalogue
+entry and needs no standalone catalogue scenario. Keep review unit tests/specs
+beside their owner; optional behavior contracts can verify review guarantees
+through an existing real scenario. They establish no production coverage.
+
+A token scenario may name its real review renderer in `covers`, import it from
+the development entry, declare `samples: fixture.samples`, and pass those samples
+into the renderer. Existing real product patterns may also serve as token UI.
+Empty covers, unused samples, fabricated tokens and plain value lists remain
+invalid. The rendered App must still pass token-binding checks. See
+[scenarios.md](scenarios.md) for the full token/render contract.
+
+Review class helpers can supply source-proven Linaria classes to a scenario.
+Arbitrary scenario classes/styles remain forbidden. A review wrapper's own native
+controls do not authorize arbitrary native controls in its consuming scenario;
+slot/selector exceptions still need actual production-owner evidence. Keep
+production and review export names distinct where `covers` would be ambiguous.
+
+## Build and guarded edits
+
+The normal preview plugin registers the exact review alias before broader product
+aliases. Configure the same alias in project TypeScript and any independent
+preview/dev harness. In an ordered bundler alias map, put `@ds/review` before
+`@ds`; the broad `@ds` mapping must not resolve it as `index.ts/review`.
+Production entrypoints never import the development entry. Inspect the product
+bundle for review modules/CSS; passing static checks does not prove bundle parity.
+
+Use `ads_units` for `review/<Owner>` units. Scenarios, local specs and helper files
+follow ordinary flat/directory ownership. A review patch may update only its own
+re-exports in the development entry and its own documented style boundaries.
+Product owners retain the separate production entry companion. Use prepared
+patches/dry runs and coupled transactions as described in
+[guarded-editing.md](guarded-editing.md); do not bypass a rejected mutation.
+
+For an existing project, identify helpers by responsibility and actual consumers,
+not names or the number of imported components. Preserve real application patterns.
+Move only demo helpers, their styles and relevant guides to `review/`; update
+scenario/preview imports, style-boundary paths, TypeScript/bundler aliases and
+links. Remove their production exports and obsolete standalone product scenarios.
+Do not copy old example fixtures or export demonstration controls as product UI.
+
+Upgrade ADS before migrating a consuming project: older versions do not know the
+separate review entry. For staged guarded edits, first add distinctly named review
+exports, migrate consumers in passing owner patches, then remove the old pattern
+exports/owners once unused. Required coupled changes use a transaction. Check
+source gates, typecheck, preview and production builds, real browser rendering,
+registered behaviors and token bindings. A source move alone establishes none
+of those rendered guarantees.

package/dist/skills/ads-migrate/references/scenarios.md

@@ -34,10 +34,31 @@ do not add scenario `preventDefault` handlers merely to hide it. Explicit App
 bases retain their declared behavior and CSP requirements; external hosts own
 their document-loading policy. Verify link activation as well as rendering.
 
+## Forms inside Apps
+
+Use real form semantics and the runtime owner's intended submit handler. ADS's
+showcase and diagnostic explorer permit `allow-forms` at every iframe layer,
+including legacy widgets. Browser constraint validation, Submit clicks, Enter and
+`requestSubmit()` can reach the normal submit path. Client-side forms call
+`preventDefault()` in their submit handlers; the host does not synthesize clicks
+or submit events. Native action requests are blocked by CSP `form-action 'none'`.
+Submit effects that use tools or resources still follow the MCP bridge.
+
+If a click fires but the `submit` handler never runs, inspect the browser's sandbox
+diagnostic and every ancestor iframe's permissions. Distinguish that host problem
+from native constraint validation legitimately preventing submission. Do not add
+scenario click interception to disguise a missing sandbox permission. External
+MCP hosts control their own sandbox/CSP policy.
+
+Verify an invalid submit, a valid submit, implicit Enter submission and the promised
+state effects. A working Next button is not evidence that form submission works.
+Keep native action navigation separate from client-side submission behavior;
+`allow-forms` does not grant host DOM access or top-level navigation.
+
 ## Owner-local token previews load their own definitions
 
 Keep the registered token sheet imported by its runtime owner for product use.
-A colocated `kind: "tokens"` scenario may render only the public review pattern
+A colocated `kind: "tokens"` scenario may render only the development-only review renderer
 with its fixture samples. Discovery adds the registered owner sheet to the
 generated record's `stylesheets`; `previewEntriesPlugin` imports those paths
 into the token preview independently of the runtime component. Custom builders
@@ -91,7 +112,7 @@ These examples describe verification mistakes, not component-specific rules:
 
 | Situation | Do not | Do instead |
 |-----------|--------|------------|
-| A reference example sets `width: 15rem`, while the native popup uses its default width. | Remove the reference width and claim the original example now matches. | Keep the baseline intact. Reproduce demo sizing through the project's public review/layout pattern or supported style helper. If a different native size is intentional, document it. Label any additional normalized comparison separately. |
+| A reference example sets `width: 15rem`, while the native popup uses its default width. | Remove the reference width and claim the original example now matches. | Keep the baseline intact. Reproduce demo sizing through the project's development-only review helper or supported style helper. If a different native size is intentional, document it. Label any additional normalized comparison separately. |
 | Static tracing cannot prove that a public clear control renders when a value is selected. | Remove its export, drop its required coverage, or change runtime behavior merely to pass the gate. | Preserve the intended public API. Try a meaningful selected-state fixture or another real scenario. If valid rendering remains untraceable, report the tooling limitation with a small reproduction. |
 | A screenshot shows the clear control in a selected state. | Treat its presence as evidence that clearing works. | Add a browser check: start selected, activate Clear, assert the value and selection are empty, verify the control's resulting visibility and documented focus behavior, then select again. |
 
@@ -207,6 +228,6 @@ An `exercises` entry records behavioral use; it never grants styling permission.
 Keep helper signatures compatible with the product API. Fix ownership/provenance
 in the runtime owner when genuinely wrong; retain intentional public APIs when
 reporting an unsupported trace. Demo-only sizing, framing and arrangement still
-belong in public review/layout patterns. A style helper is not permission to
+belong in development-only review helpers. A style helper is not permission to
 author a second design in the scenario. For cascade risks and extraction issues,
 read [atomic-styles.md](atomic-styles.md).

package/dist/skills/ads-motion/SKILL.md

@@ -76,6 +76,19 @@ one `ads_investigate({unit,check,runId})` summary before changing APIs or policy
 load request/error/artifact details only when relevant.
 
 
+Review/demo layout belongs in development-only `review/`, exported through the
+separate `${publicAlias}/review` entry (normally `@ds/review`), never the production
+barrel. Product patterns are application UI. For ownership, migration, token
+renderers, build aliases or `review-import` / `review-contract` diagnostics, read
+[development review UI](references/review.md), also served as `ads://guides/review`.
+
+A component provides one cohesive UI capability; a pattern arranges capabilities
+into reusable structures or workflows. Components may compose components/controllers;
+layout patterns may arrange slots. Do not classify by component count. For owner
+selection or `component-dependency`, `component-contract` or `component-style`, read
+[layer responsibilities and contracts](references/layers.md), also served as
+`ads://guides/layers`. Preserve public APIs and documented non-state styling hooks.
+
 For parent/child `covers`, conditional-control review, reference comparisons,
 public style-helper use, native slot/selector composition, fragment navigation,
 or `scenario-render` / `showcase-control` / `showcase-class` findings, read [scenario contracts](references/scenarios.md). Its verification
@@ -116,7 +129,7 @@ reach the agent.
 | Request | Reference | Outcome |
 |---------|-----------|---------|
 | Build or change an animation | [build.md](references/build.md) | Implement purposeful motion in its owning component/pattern |
-| Review existing motion | [review.md](references/review.md) | Findings grounded in source and observed behavior |
+| Review existing motion | [motion-review.md](references/motion-review.md) | Findings grounded in source and observed behavior |
 | Audit a component or screen, or find opportunities | [audit.md](references/audit.md) | Prioritized findings or a concrete implementation plan when requested |
 | Investigate jank or rendering cost | [performance.md](references/performance.md) | Evidence, a focused fix when requested, and a comparison |
 
@@ -216,7 +229,7 @@ fixture under the configured token directory. Declare metadata
 The renderer name is project-owned; use its real public API. Each literal fixture
 sample declares `{ token, property, probe }`: a real token, the CSS property its
 sample demonstrates, and a valid test value different from that token's current
-value. Pass `samples` into the rendered public review pattern. Names, sample text,
+value. Pass `samples` into the rendered development-only review renderer. Names, sample text,
 bindings and probes are fixture data; displayed values come from foundation CSS.
 There is no property catalogue, token-name mapping or probe palette in ADS.
 Every token needs sample coverage; fabricated tokens, missing bindings/probes,
@@ -237,10 +250,12 @@ source definitions and values; inspecting definitions does not prove UI parity.
 The tool keeps the shared naming contract; sample templates and their token
 lists belong to the project.
 
-A public review pattern may be covered by real token or composition scenarios;
-it needs no redundant standalone entry. Remove an optional scenario only while
-retaining reachable render coverage. Keep directory ownership anchored by its
-runtime entry (`index` or a file matching the directory name) or colocated fixture.
+Development review helpers need no product catalogue scenario. A token scenario
+may name its review renderer in `covers`; ordinary component/pattern scenarios
+cover their production subjects. Keep review exports in the separate review entry.
+Remove redundant helper catalogue scenarios during migration. Product UI retains
+its real render-coverage requirement. Keep directory ownership anchored by its
+implementation entry (`index` or a file matching the directory name) or colocated fixture.
 Import colocated image/font fixtures so MCP serves them through asset resources.
 For a broken-image case, use a local failing fixture, rather than an external
 network failure or a domain-specific CSP exception. Production asset APIs remain
@@ -264,7 +279,7 @@ branch, property and value must fit its role. Token-backed control skins, layout
 interactive state rules and owner hooks are rejected even through `:where()`.
 Do not copy an unchecked upstream preflight or turn a component repair into a reset.
 Keep behavior and skin in their runtime owner. Put demo-only sizing and framing
-in a public review/layout pattern; add component props for a deliberate runtime
+in a development-only review helper; add component props for a deliberate runtime
 API need. Preserve required capabilities while following ownership rules.
 Use tokens for absolute/font-relative lengths, including `ch`, `ex`, `cap`, `ic`
 and `lh`; calculations and fallback values follow the same rule. Structural

package/dist/skills/ads-motion/references/audit.md

@@ -5,7 +5,7 @@ public inputs, state transitions, motion tokens, styles, geometry helpers,
 timers, cleanup, and tests. Read nearby call sites to understand frequency and
 composition. Track documented tradeoffs and accepted upstream comparisons.
 
-Review using the categories in [review.md](review.md). Expand into rendering
+Review using the categories in [motion-review.md](motion-review.md). Expand into rendering
 performance only where observations or source evidence justify it; use
 [performance.md](performance.md) if profiling is requested. An audit does not
 silently apply production changes or rewrite configuration.

package/dist/skills/ads-motion/references/guarded-editing.md

@@ -103,7 +103,7 @@ and a definition-only `tokens.css`, imported by its runtime source. Flat owners
 shared or --ds-/--ux-/--showcase- variables. Only that owner consumes/defines its
 local tokens; aliases can use shared or own tokens. UI styles stay in Linaria.
 Add a colocated token scenario with `kind:"tokens"`, real fixture `samples` and a
-public review pattern. These inputs belong to the same owner and need real sample
+development-only review renderer. These inputs belong to the same owner and need real sample
 coverage. Manifests and fixtures stay out of the product bundle.
 
 `ads_prepare_token_samples({id, bindings?})` preserves existing project samples,