Prototype

stardust:prototype

For each directed page, render a proposed redesign as a self-contained static HTML file at stardust/prototypes/<slug>-proposed.html. Open the file in the browser; iterate via chat-driven impeccable commands ("make the hero bolder", "tighten the cup-note grid"). Mark approved once the user signs off in the conversation.

prototype is not a renderer of its own design — it composes the target spec written by direct (PRODUCT.md, DESIGN.md, DESIGN.json, stardust/direction.md) onto the page content captured by extract (stardust/current/pages/<slug>.json). Visual creativity is delegated to $impeccable craft and the iteration commands (bolder, quieter, distill, polish, colorize, typeset, layout, adapt, animate, delight, overdrive, impeccable).

Inputs

• <slug> — optional positional. Prototype just this page. Without it, prototype every directed page that is not stale.
• --all — prototype every directed page including stale ones.
• --prep — optional. Run in migrate-prep mode: fill page-type gaps (prototype one representative archetype per type) and, on approval, write canon back to stardust/canon/ and DESIGN.json.extensions.canon. See § Prep mode below and reference/canon-extraction.md. Typically invoked via the prepare-migration orchestrator.
• --canon-from <slug> — optional. Override the default canon- author (which is the first approved prototype, typically home). Used when a different page should establish the design canon.
• --publish-sample <slug> — submit the named slug to the stardust showcase. Triggers the publish-sample sub-flow documented in reference/publish-sample.md: eligibility checks, file staging, PR creation against the upstream stardust repo. Requires gh installed and authenticated. The showcase is a visual demonstration, not a deployable site — placeholder content is allowed and recorded in the PR body's § Unsourced content section. Design-quality gates stay strict: refuses on unjustified anti-toolbox hits, :root token contract failure, data-attributes contract failure, or impeccable hard-rule violations. P0/P1 critique findings warn but don't refuse. The showcase publishes via GitHub Pages on merge.
• --cinematic — optional. Layer a cinematic motion register on top of the static prototype. The register is read from DESIGN.json.extensions.motion.register (written by direct); if absent, the prototype phase picks one using the same heuristic per reference/motion-registers.md § Selection heuristic. Output filename is <slug>-cinematic.html (alongside the static <slug>-proposed.html, never replacing it). Triggers the cinematic gates in motion validation (reference/motion-validation.md § Pass 6).
• --cinematic=<register> — optional. Same as --cinematic but forces a specific register (arrival, kinetic-display, live-systems, editorial, kinetic-grid). The override is recorded in _provenance.motion.registerSource = "user-override" so reviewers can spot when direction's heuristic was bypassed.

No opt-outs

prototype does not carry --no-* or --skip-* flags. The quality gates (critique, audit, mobile-adapt audit, anti-toolbox audit, content-sourcing scan) are the product — they're not optional. If a gate refuses a file, the remediation is to fix the file or override the gate by editing the file directly, not to pass a flag that silently lowers the bar. Manual chat overrides ("ship as-is", "accept the P1 findings") are still available; the agent records the override verbatim in _provenance so downstream consumers see the explicit acknowledgement.

Setup

0. Playwright re-probe (mandatory first step). --no-save playwright installs from earlier phases are pruned by any later real npm i (extract SKILL.md § Setup → --no-save installs are ephemeral). Before any rendering step, probe node -e "import('playwright').then(()=>process.exit(0))" from the project root and re-install (npm i -D playwright --no-save --legacy-peer-deps) on failure.
1. Run the master skill's setup (skills/stardust/SKILL.md § Setup).
2. Verify stardust/state.json exists and contains at least one directed page. If not, recommend $stardust direct and stop.
3. Verify the project-root DESIGN.md and DESIGN.json exist. If not, the direction was not fully authored — recommend $stardust direct and stop.
4. Verify stardust/direction.md has an active (not pending) direction. Pending directions block prototype.
5. Validate provenance on every page in scope. Call validateProvenance(page) per skills/stardust/reference/state-machine.md § Provenance validation for every page that this run will render (the single <slug> argument when present, otherwise every non-stale directed/prototyped/approved page). Abort with the helper's error when any page lacks live-render evidence — re-running prototype against a synthesized page record silently propagates the synthesis into the rendered prototype. Surface Provenance OK on N pages once the check passes.
6. Read stardust/current/DESIGN.md (the descriptive snapshot of the existing site, used as a fallback reference during render when the proposed file needs to mirror an aspect of the captured surface).

Delegation mechanic

prototype does not author <slug>-proposed.html directly. The heavy creative lift is delegated to $impeccable craft, and (when needed) the structural plan to $impeccable shape. Spelling out the mechanic matters because the carve-out documented in skills/stardust/reference/artifact-map.md (where stardust authors PRODUCT.md, DESIGN.md, DESIGN.json, current/PRODUCT.md, current/DESIGN.md directly, treating impeccable's references as format specs, not runtime commands) is load-bearing for those five files only. It does NOT extend to:

• stardust/prototypes/<slug>-proposed.html — must be authored by $impeccable craft, not by stardust direct authoring.
• Iteration on the proposed file — must be driven through a chat-driven invocation of an explicit impeccable command (per the iteration paths section).
• Structural planning when a page is complex enough to need it — $impeccable shape.

The proximate cause of past content fabrication was the agent over-generalizing the direct-authoring carve-out to the proposed HTML. Don't.

Invoking impeccable

Impeccable is a skill, not a CLI. Invoke it through the harness's skill-invocation tool, passing the sub-command and its args as the skill's argument string, mirroring the slash-command form. In Claude Code the plugin namespaces it as impeccable:impeccable:

Skill {
  skill: "impeccable:impeccable",
  args: "craft <feature-description>"
}

In GitHub Copilot and other harnesses that flatten plugin skills the skill is named impeccable and takes the same argument string (craft <feature-description>). Every Claude Code Skill { ... } example in this skill translates the same way.

Sub-commands referenced from this skill are all routed through the same skill: craft, shape, plus the iteration commands (bolder, quieter, distill, polish, colorize, typeset, layout, adapt, animate, delight, overdrive, impeccable).

When impeccable is not available (CLI-only environments, plugin uninstalled, sandbox without skill access), stop and tell the user impeccable is required for prototype rendering. Recommend installing the impeccable plugin. Do not fall back to direct authoring of <slug>-proposed.html — the validation contract craft enforces (anti-toolbox audit, divergence rules, type ratios, content sourcing hierarchy) is not reproducible by direct authoring, and falling back silently ships unverified output.

Stardust's job inside Phase 2 is therefore:

• Compose the inputs craft needs (page content from current/pages/<slug>.json, target spec from DESIGN.md / DESIGN.json, hard constraints from direction.md, content sourcing rules from reference/proposed-file-shell.md § Content sourcing hierarchy).
• Invoke craft through the skill-invocation tool.
• Validate the result against the contract (:root block, data attributes, divergence audit, impeccable hard rules, content sourcing). If validation fails, refuse to write — never paper over craft output the agent thinks is "close enough."

The proposed file is whatever craft writes plus the validation report; it is not stardust's authored artifact.

Procedure

Phase 1 — Plan the prototype (page-shape brief)

For each page in scope:

1. Read stardust/current/pages/<slug>.json for the page's structure and content.

2. Read stardust/current/_brand-extraction.json for system components and cross-promo data (the page's site-wide repeated surfaces).

3. Read stardust/direction.md Active section for the resolved direction, divergence inputs, and command sequence.

4. Read project-root DESIGN.md + DESIGN.json for the target site system — tokens, abstract component vocabulary, named system-component roles. The site system tells the agent what the design language is; this Phase decides how it deploys to this specific page.

5. Author stardust/prototypes/<slug>-shape.md — the per-page compositional brief. Format spec: reference/page-shape-brief.md. The brief carries the section list, layout strategy, key states, interaction model, structural data attributes, and the unsourced-content list (bridge to the placeholder contract). Author directly — no interview, no impeccable invocation; this is stardust's reasoning about how the system deploys to this page given this content.

6. Show the brief to the user and wait for confirmation before moving to Phase 2. The user can edit the brief in place (rearrange sections, kill open questions, change composition decisions); re-rendering Phase 2 will rebuild the proposed file from the edited brief.

   Hands-off compliance. When state.json.handsOff is true, the shape brief is still authored and validated but the user-confirmation wait is skipped — the brief is its own record. Approval (Phase 5) under hands-off follows the mode's contract defined in skills/stardust/SKILL.md § Hands-off mode.

$impeccable shape is not invoked in v0.2 (see reference/page-shape-brief.md § Authoring procedure for the rationale; revisit if per-page hand-authoring proves insufficient across sites).

The brief decouples site-level concerns (in DESIGN.md) from page-level deployment (per-page brief). A direction change invalidates the system; existing briefs are content-aware-stale only when the system change makes their composition impossible. This recalibration of stale-flagging is documented in skills/stardust/reference/state-machine.md § Stale flagging.

Brief-time disciplines (validator-enforced)

Five disciplines fire when the brief is authored. The brief validator rejects briefs missing any of them; failure surfaces the specific rule violated and stops Phase 1 before Phase 2 renders anything. The disciplines exist to prevent the AI-slop failure mode where a brief with only (DESIGN tokens) + (captured content) as input produces template-shaped output regardless of brand.

Discipline 1 — Captured-source lineage per section. Every section in ## Sections declares its captured-source origin. Forms:

• "subscription-card-on-bay (consolidates captured banner 2 + dual-card right of pages/home.json#landmarks[hero])" — derived from one or more captured surfaces
• "site-wide system-component (carried from _brand-extraction.json #systemComponents[kind=footer])" — chrome inherited from the brand-surface
• "direction-authorized new" — composed against direction.md, not derived from a captured source (require a one-line note naming which direction movement justifies the new section)

Sections without lineage are rejected. The lineage list lives in _provenance.capturedSourceLineage in the brief and propagates to the rendered file.

Discipline 2 — Anti-template pass. For each captured component pattern the page deploys (cards / banners / search rows / CTA bands / hero composition), the brief considers 2–3 layout alternatives and picks the most differentiated. Curated default-patterns-to-escape flags reflex picks:

• hero-then-bands silhouette (the universal AI silhouette)
• 5-up image-card grid as category nav
• nav-icon glyphs (search / cart / account) in a typographic register
• centered-stack hero with two-button CTA pair
• captured-shape mirror-translated into new tokens

The brief justifies any reach for a default-pattern with a captured-source citation that makes the pattern brand-appropriate (e.g., "5-up grid preserved because the captured site's grid IS the brand's signature catalogue shape; the alternative consideration was a vertical ledger which the brand register rejects").

The alternatives SHOULD be reference-grounded when reference research is available (per skills/stardust/reference/reference-research.md): an alternative cites a real reference screen in the entry's reference? field using that file's evidence shape. Taste-only alternatives remain valid when research is unavailable.

The audit lives in _provenance.antiTemplatePass[] with one entry per captured pattern: { pattern, defaultReflex, alternatives[], picked, rationale, reference? }.

Discipline 3 — Surprise budget. The brief declares a surprise field with one of: low | medium | high. Moves come from the bank of non-template moves — see skills/stardust/reference/divergence-toolkit.md § Non-template move bank, with worked examples in reference/anti-template-bank.md — or an evidence-shaped extension per the bank's § Extension rule. Tier semantics:

• low — brand-faithful + improvements only. Variant A's role under reimagined; all of A1/A2/A3 under verbatim.
• medium (default for B variants under reimagined) — one captured cliché replaced by one move from the bank.
• high (default for C variants under reimagined) — two clichés replaced + one document-shape substitution.

Under ia-fidelity: verbatim (per skills/stardust/reference/intent-dimensions.md § 9), the per-page surprise budget is capped at low site-wide. The validator refuses any verbatim-direction brief with surprise: medium or high.

low ≠ generic. The budget bounds added divergence, not craft or fidelity. low means brand-faithful + improvements + full signature preservation, NOT "the most obvious faithful interpretation." The recurring failure mode (a fintech migration) is the agent reading low / verbatim as license to strip the page to a plain type-hero on a flat ground — the result is faithful but forgettable and under-sells the redesign. Hold the craft bar at low: keep the brand's distinctive elements, apply the improvements list, and reproduce the signature.

Signature preservation is mandatory and budget-exempt. When the captured page has a signature hero medium (background video / canvas / WebGL / Lottie), signature motion (scroll / parallax / kinetic), or a signature visual motif (per intent-dimensions.md § 8b), the brief must reproduce it — with a static fallback, prefers-reduced- motion alternative, and (for overlaid text) a legibility scrim. This does not consume the low allowance: carrying the brand's own signature forward is fidelity, not divergence (§ 8b § Surprise-budget exemption). Record the kept signatures in _provenance.signatureElements[] as { kind, capturedSource, mechanism, fallback }. Render-refusal: a brief that flattens a captured video/canvas/animation hero to a still, gradient, or type-only hero — or drops a site-wide motif — is rejected at the shape-brief audit; reproduce the signature instead.

Type-scale yield clause. When a tier-medium-or-higher variant's captured-trait amplification structurally conflicts with a brand-level type-scale rule from DESIGN.md (e.g. a "Names-At-Headline-Scale" rule, or any other named type-scale floor / ceiling), the brand-level rule may yield per-page. The yield must be cited in _provenance.surpriseTier_typeScaleYields[] with: { rule, variantDominantDimension, capturedTraitAmplified, yieldedTo, rationale }. The brand-level yield clause itself (the named exception in DESIGN.md) is project-side, not spec-side; the spec only requires the per-page citation when the yield fires. See § Friction carve-out #4 below.

Discipline 4 — Substrate transitions are deliberate, named, and rare. Default: single substrate across the page. Each substrate exception requires a named purpose in the brief ("highlights the featured-coffee promotional moment"). More than two substrate transitions per page fails the brief. The transitions live in _provenance.substrateTransitions as { default, exceptions[] }.

Exception — substrate-keyed document-shapes (friction carve-out #2). When the variant's surprise: high move is a substrate-keyed document-shape (zine, catalog-card, poster-sequence), the per-section substrate IS the document-shape's structural rhythm. The ≤ 2-transition cap does not apply; each section's substrate must instead carry a per-section captured-source citation (typically a per-SKU label color, a per-page brand color, or a per-content-type ground convention from the captured site). The exception is recorded in _provenance.substrateTransitions.note with the document-shape named and the citation source. The validator accepts > 2 transitions when:

1. surprise: high is declared, AND
2. the picked move from the bank is document-shape with a substrate-keyed sub-kind (zine / catalog-card / poster-sequence), AND
3. every transition in exceptions[] carries a per-section captured-source citation.

If any of the three conditions fails, the cap re-engages.

Discipline 5 — Heading hierarchy + voice classification tracked per section. The brief requires:

• H1 declared once per page; subsequent sections H2; H3 children.
• Every literal value in copy classified as one of: captured-verbatim, direction-authorized rewrite, or placeholder. No section ships with copy without a classification.

The classification list lives in _provenance.voiceClassification[] as { section, classification, copy?, source? } and propagates to the rendered file.

Placeholder-ribbon labels (friction carve-out #3). System- component honesty-signal labels (placeholder ribbons, "TBD" badges, "from the brand team at migrate" markers) are direction-authorized chrome, not placeholder content. They label placeholder prose / data; the prose / data is what gets enumerated in _provenance.unsourcedContent[]. The ribbon text itself does not. Classify the ribbon labels as direction-authorized chrome (per friction #3) so the placeholder enumerator stays clean (no double-counting across every component instance).

Phase 2 — Render the proposed page

Render stardust/prototypes/<slug>-proposed.html per reference/proposed-file-shell.md § Required structure. Hard requirements there:

• :root token block as the first content of the first <style> (per skills/stardust/reference/token-contract.md).
• Structural data attributes on every section (per skills/stardust/reference/data-attributes.md).
• Provenance block as the first child of <head>.
• Self-contained: no external CSS, no external JS.
• The site's favicon inlined in the head as a data: URI when stardust/current/assets/favicon.<ext> exists (per reference/proposed-file-shell.md § Hard requirements #8).
• Content preserved from the current page (hero copy, CTAs, nav, body) unless direction.md authorises content changes.
• Content sourcing hierarchy (reference/proposed-file-shell.md § Content sourcing hierarchy): every literal value rendered must come from current/pages/<slug>.json, then voice samples, then direction-authorised changes — or be rendered with the mandatory PLACEHOLDER visual signature. Stats, addresses, quotes, tax IDs, hours, prices, named-person words must never be invented. The proposed file's _provenance.unsourcedContent[] lists every placeholder so migrate can refuse to ship unverified content.

Delegate the heavy creative lift to $impeccable craft:

• Pass the page content and the resolved direction as the feature description.
• Reference DESIGN.md / DESIGN.json as the design system.
• Pass direction.md § Anti-references and § Divergence inputs as hard constraints (so craft does not silently veer off the resolved direction).
• Skip craft's "north star mock" generation step (direction.md is the brief). Skip craft's "shape" call (already done if Phase 1 needed it).

Modern-web-guidance consult. When the render implements scroll-driven animation, view transitions, anchor positioning, container queries, or perf-sensitive hero media, and the modern-web-guidance plugin is installed, search it (npx -y modern-web-guidance@latest search "<query>") and follow the retrieved guide; cite the guide id in _provenance.guidesConsulted[]. Skip silently when the plugin is absent.

After craft returns, validate the output:

• :root block present and complete (token-contract.md).
• Data attributes on every section (data-attributes.md).
• Anti-toolbox audit clean (each hit justified per divergence-toolkit.md § 1; record audit results in DESIGN.json.extensions.divergence.anti_toolbox_hits with the audit's amendments noted).
• Impeccable hard rules respected (OKLCH, type ratio ≥ 1.25, no reflex slop).
• Content sourcing scan — every literal value in the rendered output traces to one of the allowed sources (reference/proposed-file-shell.md § Content sourcing hierarchy). Any value that doesn't is either wrapped in a [data-placeholder] element with the mandatory visual signature, or the validation fails. Build the _provenance.unsourcedContent[] list during this scan.

If validation fails, do not write the file. Surface the failure to the user with the specific rule violated and a suggested fix.

Craft-time disciplines (pre-write validators)

Four disciplines fire on the rendered file before it lands on disk. These run after craft returns its output and before the file is written; failure refuses the write with a substitute proposal (Discipline 6) or a rule citation (7, 8), and Discipline 9 registers detector ignores rather than refusing.

Discipline 6 — Reflex-reject font pre-flight. Grep the declared font-family declarations against the reject list in skills/stardust/reference/divergence-toolkit.md § Reflex-reject fonts. If ≥ 3 reject-list families hit, refuse to write and propose dimensionally-equivalent off-list substitutes from the substitute table.

The check fires only on rendered files whose font-family declarations the agent had freedom to pick. Mode A renders with captured display + body families pinned (per direct/SKILL.md § Mode A — Brand-faithful mode) bypass the check — the inherited families are not a reflex choice. Record the bypass reason in _provenance.reflexRejectAudit.bypassed with the captured families named.

Discipline 7 — Variable-font axis engagement. When the resolved direction's expressive or distinctiveness axes have moved past their default (per skills/stardust/reference/intent-dimensions.md §§ 2 + 5), engage ≥ 1 variable-font axis non-trivially per page using deck recipes from the divergence toolkit. The toolkit's font decks expose named axis recipes:

• serif-luxury deck → Fraunces axis recipe: opsz 144, SOFT 100, WONK 1
• bauhaus-functional deck → Bricolage axis recipe: opsz 96, wght 600
• tactile-humanist deck → Recursive axis recipe: MONO 1, CRSV 0, CASL 0.5

Static-weight static-style across all type on a page that claims expressive or distinctive movement fails the check.

Static-only-family precedence (friction carve-out #1). Family substitution rules when the captured/pinned display font does not ship a variable axis:

1. If the captured/pinned display font is variable, engage its axes per deck recipes (standard path).
2. If the captured display font is static-only by family (Bellfort, GT Sectra static, hand-lettered custom cuts whose woff2 files don't expose a parseable fvar table without runtime inspection), exempt the display family from the check and engage the body family's axes instead (typically wght and ital on a workhorse like Public Sans or Hanken Grotesk).
3. Document the family's static-only status in DESIGN.json.extensions.divergence.font_deck.notes so downstream pages don't re-run the check.

A pre-flight that blindly grep'd for font-variation-settings would fire on every brand-faithful render of a static-only-display brand. The exemption keeps the spirit of the discipline (engage variable behavior where it exists) while honoring the letter when the captured family literally has no axes to engage.

Off-deck accent fonts must ship with named expressive positions (marginal-tag, pointer-scribble, headline-callout, badge-fill — see toolkit § Font deck — expressive positions). A face introduced without a position is a reflex pick, not an expressive position.

Discipline 8 — Fidelity tier (--fidelity=quick|refined|production).

• quick (default) — sketch fidelity. Brief decisions land; micro-decisions stay provisional.
• refined — adds a craft micro-pass per reference/fidelity-refined-pass.md: formal type scale as CSS custom properties, font-variant-numeric: tabular-nums on inline digits, text-wrap: balance on headings + text-wrap: pretty on body + hanging-punctuation: first on html, sliding left-rule on nav hover, hairline hover on list items, kicker + title + baseline-aligned more-link section-head triplet, italic display couplet replacing structurally-vague <b>, bottom-of-sidebar reworked as typographic plate.
• production — refined + WCAG AA audit on every render + harden pass (loading states, error states, content-overflow edges).

The tier is declared in the run invocation; persisted in _provenance.fidelity. Default is quick.

Discipline 9 — Copy-cadence detector bypass under verbatim fidelity. This extends the Mode-A reasoning of Discipline 6 from fonts to prose. impeccable's design detector ships prose-voice rules (em-dash-overuse, marketing-buzzword, and similar copy-cadence checks) that assume the copy is the agent's to rewrite. Under ia-fidelity: verbatim — or any faithful/Mode-A render where the body copy is captured-verbatim — that assumption is false by construction: the prose is the source brand's, reproduced exactly per the content-sourcing hierarchy, and rewriting it to satisfy a cadence rule is the fabrication the fidelity setting exists to prevent. So when the rendered file's copy classification is captured-verbatim (per Discipline 5's voiceClassification), register those copy-cadence rules as intentional ignores for the <slug>-proposed.html files before the design hook fires — the same way Discipline 6 bypasses the font reflex-reject check for pinned families. Scope the ignore to the proposed files only, never to the project's own source (blocks, styles, components), where the rules still apply because that copy is the agent's. Record the bypass in _provenance.copyCadenceBypass with the rules ignored and the classification basis. A 2026-06-26 SaaS-site run hit this: the hook flagged em-dashes and "enterprise-grade" on the site's own headings ("Built on Enterprise-Grade Components") under a verbatim direction, and the only correct response was to leave the captured copy untouched and record the bypass.

Bound the bypass: it covers prose-cadence rules only. Structural and craft detector rules (design-system-radius, contrast failures, reflex layout slop) are not exempted by verbatim fidelity — those govern the agent's own CSS and structure, which faithful mode does not freeze. Listing a rule under this bypass requires it be a copy-voice rule whose subject is the captured prose.

Phase 2.4 — Motion application (when --cinematic)

Fires only when --cinematic (with or without an explicit register) was passed, OR when DESIGN.json.extensions.motion.register was authored by direct and the user did not opt out. Produces stardust/prototypes/<slug>-cinematic.html alongside the static <slug>-proposed.html — the static prototype is never replaced.

Procedure:

1. Resolve the register. For single-variant runs, read DESIGN.json.extensions.motion.register. For multi-variant runs (when DESIGN-<id>.json files exist at the project root), read DESIGN-<id>.json.extensions.motion.register for the variant currently being rendered — each variant may carry its own register, or omit it entirely (variant renders static). If --cinematic=<register> was passed at the CLI, the CLI value wins only for the variants in scope (every variant when no <slug> filter is set, otherwise the variant(s) matching the filter).

   Record the source in _provenance.motion.registerSource ("direct" for per-variant DESIGN-authored, "user-override" for CLI). If neither path resolved a register for this variant, fall through to the selection heuristic in reference/motion-registers.md § Selection heuristic. If the heuristic itself returns no register (e.g. the variant's PRODUCT.md Brand Personality maps to none of the five registers, and no evidence-shaped extension register applies per the bank's § Extension rule in reference/motion-registers.md), skip Phase 2.4 entirely for that variant — render it static.

   The per-variant resolution is what lets uplift produce a three-variant set where only variant C engages motion: direct writes the register into DESIGN-C.json only, and Phase 2.4 fires for C alone (A and B render static).

2. Stage Lenis assets. Copy skills/prototype/assets/motion/lenis.min.js and lenis.min.css into stardust/prototypes/ (idempotent — skip if shas match). Cinematic prototypes load these via relative paths.

3. Read the canonical runtime. Embed the inline script from reference/motion-runtime.md § The canonical script verbatim, with the animConfig constants rewritten per the active register's token defaults (reference/motion-registers.md § The five registers § Token defaults).

4. Layer the register's CSS. Append the register-specific keyframes and class rules (entrance keyframes, parallax CSS custom properties, marquee animations, pulse animations) to the file's <style> block. The set of keyframes is closed per register; see reference/motion-runtime.md § Per-register tuning.

5. Annotate target HTML. Walk the rendered DOM and emit the motion data-* attributes per the register's vocabulary:

   • arrival: [data-anim] on section heads, body copy, CTAs, and tile cards; [data-countup] on numeric values; [data-parallax] on the hero photograph.
   • kinetic-display: [data-anim] on most sections; [data-split] on display-cap headlines (<h1 data-split>DINE</h1>); [data-flip] on terminal codes / gate numbers; .word spans on display headlines for clip-path word wipes.
   • live-systems: [data-tile-anim] on every ops-tile and card; [data-countup] on every numeric data value; [data-fill] on every bar inner element; .live-sweep on the live-data container; .marquee__track on the top ticker.
   • editorial: [data-anim] only; [data-parallax] with reduced magnitude on hero imagery; never [data-flip] / [data-fill] / [data-split].
   • kinetic-grid: [data-tile-anim] on cards; [data-anim] on section heads.

   Full per-register attribute matrix: reference/motion-registers.md § Data-attributes consumed.

6. Inject the <noscript> fallback. Add the no-JS override from reference/motion-runtime.md § No-JS fallback to <head> so the file degrades to its static-end state without JavaScript.

7. Update _provenance. Add the motion block:

   "motion": {
     "register": "<register-name>",
     "registerSource": "direct | user-override | heuristic | extension",
     "runtimeVersion": "v1",
     "lenisAssets": { "js": "lenis.min.js", "css": "lenis.min.css" },
     "attributesEmitted": ["data-anim", "data-countup", ...]
   }
   

8. Hand off to Phase 2.8 (motion validation). The cinematic gates in reference/motion-validation.md § Pass 6 fire automatically because the rendered file declares the _provenance.motion.register field.

The static <slug>-proposed.html is unaffected by this phase. Both files are reviewable; the brand owner sees the cinematic version when motion is part of the redesign brief, the static version when migration / accessibility audit is the focus.

Output paths

When to use the static-only path

The static prototype remains the load-bearing artifact for:

• Brand-faithful inheritance reviews (motion is additive — the static prototype is the canonical "yes, that's us, refreshed" surface).
• Accessibility audits (motion-driven pages are harder to evaluate in their reduced-motion state).
• Migration consumption (migrate reads the static prototype as its primary source. It does not merge the cinematic layer — per skills/migrate/SKILL.md § Phase 2 → Cinematic sibling, it carries the motion assets (lenis.min.*) through to migrated/assets/motion/ and records cinematic-variant-not-consumed in the sidecar).

The static prototype must pass every gate independently — the cinematic layer cannot rescue a static prototype that fails Phases 2.5–2.7.

Phases 2.5 – 2.8 — Quality gates: Critique → Audit → Adapt → Motion (Discipline 9)

Four mandatory gate phases run by default before any prototype can advance to prototyped. They implement Discipline 9: critique covers design, audit covers technical correctness, adapt covers viewport behaviour, motion covers scroll-driven and time-driven choreography correctness. P0/P1 findings from any of the four block prototyped until acknowledged. None have an opt-out flag (per § No opt-outs).

Phase 2.8 fires only when the rendered file declares ≥ 1 named choreography (per the page-shape brief's motion stack) OR uses animation-timeline:, @scroll-timeline, IntersectionObserver-driven entry triggers, or rAF loops reading getBoundingClientRect(), OR when Phase 2.4 (motion application under --cinematic) emitted a <slug>-cinematic.html file with motion attributes per reference/motion-attributes.md. Cinematic prototypes additionally trigger the cinematic-mode gates in reference/motion-validation.md § Pass 6 (Lenis bootstrap, reduced-motion fallback completeness, scroll-jack check, three-position screenshots, register-match audit, motion C-cliff detector). Static prototypes skip the discipline entirely.

The wasatch dry-run on 2026-05-13 caught two real bugs the brief and craft phases missed (a WCAG miscalculation off by 0.27–1.86 points on multiple pairs of /beers variant C, and an LCP image lazy-loaded on the first catalog entry). Both were caught by the audit half — not by critique. The detector's contrast computation and responsive performance check are the load-bearing audits; without them the file would have shipped with quantifiable WCAG failures.

Phase 2.5 — Critique

Before opening the proposed file in the browser, run two parallel validators against the rendered proposed file: critique and audit. They are explicitly designed as a complementary pair — critique covers design (AI-slop reflexes, hierarchy, brand fit, cognitive load); audit covers technical correctness (accessibility / performance / theming / responsive / anti-patterns). Running only critique misses every quantifiable WCAG / perf / responsive failure; running only audit misses brand-misalignment and design slop. The pass is a contract, not a courtesy.

A 2026-05-04 hardware-vendor home prototype critique returned 1 P0 + 2 P1 + 3 P2; the audit on the same artifact returned six additional findings (no skip-link, theme carousels without keyboard arrow nav, hero ~3.5MB without responsive <picture>, layout-property animation, JS-gated reveal with no <noscript> fallback, scroll-behavior: smooth not respecting prefers-reduced-motion). None were design issues, none would have been caught by critique alone. Without an audit gate the page would have been marked prototyped with quantifiable WCAG failures.

Procedure:

1. Run both validators in parallel. Invoke impeccable twice in one batch of skill invocations (Claude Code form shown; see § Invoking impeccable):

   Skill { skill: "impeccable:impeccable",
           args: "critique stardust/prototypes/<slug>-proposed.html --json" }
   
   Skill { skill: "impeccable:impeccable",
           args: "audit stardust/prototypes/<slug>-proposed.html --json" }
   

   Each returns a JSON findings list — each finding has priority (P0 / P1 / P2 / P3), category (hierarchy / contrast / motion / a11y / perf / responsive / etc.), and a one-line description. Capture critique findings into _provenance.critique[] and audit findings into _provenance.audit[] on the proposed file (append; never overwrite previous runs' entries).

2. Brand-faithful inversion auto-dismiss. Both validators ship known false positives on Mode A renders — Arial fallback reads as "overused-font," eyebrow uppercase reads as "all-caps body," pure white / pure black flagged when the brand's captured palette includes them. Before surfacing findings to the user, diff each finding against DESIGN.json#extensions.divergence.brand_faithful_inversions[] and DESIGN.md#narrative.rules (e.g. permitted uppercase contexts). Drop findings whose category and target match an approved inversion; keep the original list in _provenance.<critique|audit>[] with a dismissedAsBrandFaithful: true flag for audit-trail purposes. The user-facing report shows only the real hits.

3. Vision gate. Render a screenshot of the proposed file and study i