dreative 0.3.2 → 0.4.0

package/dist/cli/index.js

@@ -107,7 +107,7 @@ async function main() {
                 fs.writeFileSync(agentsMd, stripped + pointer);
             }
             console.log(`installed skill to ${destDir}${forCodex ? " (Codex mode: AGENTS.md pointer added)" : ""}`);
-            console.log(`  core: SKILL.md, DESIGN.md`);
+            console.log(`  core: SKILL.md, DESIGN.md, PLAN.md`);
             console.log(`  specialist skills: ${picked.length ? picked.join(", ") : "(none)"}`);
             console.log(`next: ask your coding agent to "open dreative" or "redesign my app's UI visually"`);
             return;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dreative",
-  "version": "0.3.2",
+  "version": "0.4.0",
   "description": "Layout-first visual editor skill for coding CLIs: extract your app's UI into editable wireframes, tweak with drag-drop + ref images, then the agent applies the diff back to your code.",
   "type": "module",
   "bin": {

package/skill/dreative/DESIGN.md

@@ -6,7 +6,8 @@ because LLM-designed UIs converge on one templated look. Every rule corrects a k
 model default; none is a suggestion. Requests may carry a `plan` (Dreative's
 pre-computed decision: dials, per-section layout families, budgets, lints) — execute
 the plan, apply this doctrine to everything the plan doesn't specify. When
-`plan.skills` names specialist skills (`motion`, `3d`, `interaction`), the matching
+`plan.skills` names specialist skills (`motion`, `3d`, `interaction`, `immersive`,
+`cinematic`, `refined`, `media`, `ux`, `mobile`), the matching
 `skills/<name>.md` files extend this doctrine for that request — read them first;
 where they go deeper than a section here, they win.
 
@@ -313,6 +314,11 @@ capability found as a first-class design material, not a nice-to-have:
   the client's actual photography when those exist.
 - If no generation capability exists, say so and fall back down the §7 priority
   list — never fake a video with a div animation.
+- `skills/media.md` is this section's deep dive: the production pipeline
+  (prompting for the page's light, compression targets, frame sequences), the
+  full DOM-tier and WebGL media-plane treatment vocabulary, and the
+  entrance/idle/response reasoning frame. Read it whenever generated media or
+  motion-integrated imagery ships.
 
 ## 8. Content and copy
 
@@ -342,7 +348,10 @@ tactile press (`scale-[0.98]`). Same button shape, form vocabulary, and icon sty
 on every screen — if "save" looks different in two places, one is wrong. Modals are
 usually laziness; exhaust inline/progressive first. Dropdowns escape
 overflow-hidden ancestors via popover API/position-fixed/portal. Touch targets
-≥ 44px. Never disable zoom.
+≥ 44px. Never disable zoom. This section is the floor; `skills/ux.md` is the
+full working-page contract (nav that resolves, forms that submit, all states
+reachable, keyboard walk, the pointer-events audit) — load it for any
+product-register page and any redesign touching navigation, forms, or state.
 
 ## 10. Banned AI tells (match-and-refuse)
 
@@ -510,11 +519,27 @@ the output is not done.
     conditional state verified present (or logged as intentional) in the new
     code; preservation ledger reported. If motion skills were chosen, the
     implemented animations are named and present in the code.
+17. Spatial integrity (§15): every positioned/fixed element has an anchor and
+    reserved space; no interactive element overlaps another at 320/768/1280;
+    one occupant per overlay corner; overflow-capable rows wrap or scroll
+    inside their container (nothing clips at a viewport edge); animation
+    end-states and parallax extremes collide with nothing; decoration layers
+    are pointer-events-none below content.
+18. Runtime gate (Mode A, whenever motion/3d/media/interactive treatments
+    shipped): console clean while loading + scrolling + interacting; every
+    shipped effect provably runs (canvas draws, transforms change, videos
+    play); ux.md §7's functional audit passes (nav, menu, forms, tab walk,
+    hit-tests); failed effects replaced by their planned fallback (PLAN.md),
+    never shipped broken. If no browser is available, the ungated items are
+    reported to the user by name.
 
 ## 13. Mobile & touch adaptation (how ambitious effects degrade)
 
 Ambitious designs die on phones first. Every effect gets an explicit mobile
-strategy DECIDED AT DESIGN TIME, not patched after. The rule of thumb: touch
+strategy DECIDED AT DESIGN TIME, not patched after. (This section governs how
+desktop effects degrade; when mobile is a primary surface — mobile-first
+briefs, app-register products — load `skills/mobile.md`, which designs the
+phone experience as first-class.) The rule of thumb: touch
 devices get a *different good design*, never a broken half-version of the
 desktop one.
 
@@ -599,3 +624,60 @@ not replace the brand-voice reasoning. Self-host via Fontshare/google-webfonts
 downloads (`font-display: swap`, preload the display weight only). Never ship
 more than 2 families / ~5 weight files. If the brief names a commercial font
 the project already licenses, use the real thing.
+
+## 15. Spatial integrity (nothing overlaps by accident)
+
+The most common way an otherwise-good AI design dies: elements sitting ON TOP of
+each other — a menu button overlapping the nav, a chip row clipped off the
+viewport edge, a floating widget covering the CTA. Beautiful animation cannot
+rescue a page where things collide. These rules are a hard floor, same tier as §5.
+
+**Every out-of-flow element must justify itself.** Before writing
+`absolute`/`fixed`/`sticky`/negative margin/transform-offset, answer: what is
+this anchored to, and what reserves the space it covers? If there's no answer,
+put it in flow. Decoration layers (glows, grain, orbs, canvas backgrounds) are
+`absolute inset-0 -z-10 pointer-events-none` — below content, never intercepting
+clicks, never between the user and a control.
+
+**Interactive elements never overlap other interactive elements.** Not at any
+breakpoint, not mid-animation, not after a toast appears. Two clickable things
+occupying the same pixels is an automatic fail — one of them is unreachable.
+Mentally hit-test every control: is anything rendered above it (higher z-index,
+later stacking context) covering any part of its hit area?
+
+**Fixed/floating overlays get a slot system.** The viewport has at most 4 overlay
+slots (the corners), plus optional top/bottom bars. ONE occupant per slot —
+before adding a floating element (toast, install prompt, chat bubble, back-to-top,
+cookie notice, desktop-pet promo), check what already lives in that corner,
+including the site's own nav controls. Overlays keep ≥16px from viewport edges
+(safe-area insets on mobile), never cover the hero CTA or nav actions, and
+anything persistent is dismissible. If two things want the same corner, stack them
+in one container or queue them — never let them fight.
+
+**Nav is one coherent bar.** Menu toggles, theme switches, and account buttons
+live INSIDE the nav's flex row — never as separately-positioned fixed elements
+that visually land on top of the bar. If a control is fixed so it survives scroll,
+the nav itself is fixed and the control stays part of it.
+
+**Rows that can overflow must have a plan.** Chip rows, tab bars, button groups,
+breadcrumbs: at every width they either wrap (`flex-wrap`), scroll within their
+own container (`overflow-x-auto` with visible affordance, content inset from the
+container edge, `scroll-padding`), or truncate deliberately. Content silently
+sliding under the viewport edge or under a sibling is a bug. Centered rows wider
+than their container clip on BOTH ends — left-align scrollable rows.
+
+**Animation end-states count.** An element's resting position after its entrance
+(and every scroll-linked position in between) obeys these same rules. Parallax
+and floating loops need enough clearance that their extremes never touch
+neighboring text or controls. Pinned sections must not leave the pinned layer
+hovering over the next section's content when unpinned.
+
+**Reserve space for the dynamic.** Text that will be swapped/typed, badges with
+counts, localized labels: size the container for the longest realistic value.
+Fixed bars get matching `padding` on the scroll container (or `scroll-margin`)
+so content can't hide beneath them — anchored headings included.
+
+**Verification is spatial, not stylistic.** At 320 / 768 / 1280, walk the page
+top to bottom and ask of every element: what is under it, what is above it, and
+was that intentional? Any unintentional occlusion, clipped edge, or double-booked
+corner gets fixed before the respond — this is checklist §12 item 17.

package/skill/dreative/PLAN.md

@@ -0,0 +1,143 @@
+# Dreative Plan Mode — decide everything before the first line of code
+
+Run this protocol at the start of ANY non-trivial Mode A request (new page/site,
+redesign at rung 2+, any request implying motion/3d/immersive/cinematic/media, or
+"make it amazing/like <reference>"). Skip it only for trivial single-element
+restyles and rung-1 token refreshes — and even then run §1's capability probe
+once per session. The failure this file prevents: jumping into code with half a
+brief, discovering mid-build that media/tools/structure are missing, and shipping
+a page that is 60% of what the user actually wanted.
+
+Plan Mode is ONE planning pass → ONE structured question round → a written plan
+→ execution in the plan's order. Never turn it into a long interview; the user
+answers once and you build.
+
+## 1. Capability probe (before proposing anything)
+
+Enumerate what your environment can actually produce, and write the result down
+(one line per capability in the plan file, §4). Check for:
+
+- **Image generation** — an image-gen tool/MCP, or a CLI that produces images.
+- **Video generation** — a video-gen tool/MCP (seamless loops, image-to-video).
+- **Browser tools** — screenshot + console + interaction (needed for the
+  verification protocol; note it if absent).
+- **Asset tooling** — anything for compression/conversion (ffmpeg on PATH,
+  sharp/squoosh in the project) for posters, loops, and frame sequences.
+
+Rules:
+- Probe by LOOKING (list your tools, `which ffmpeg`, check MCP config), never by
+  assuming. A capability you didn't verify doesn't exist.
+- If a capability is missing but the design clearly wants it (e.g. a cinematic
+  brief with no video-gen), include an **offer to install** in the question round
+  (§3): name the concrete option (an MCP server the user can add, or
+  falling back to generated stills / pre-rendered loops from image sequences)
+  and let the user decide. Never install tools silently; never silently degrade
+  either — the user must know the fancy version was available.
+- The probe result changes the blueprint: no video-gen → hero loops become
+  generated stills + ken-burns or a shader surface; no browser tools → the
+  verification protocol's manual fallback (SKILL.md) must be declared up front.
+
+## 2. The blueprint (section-by-section, media-first)
+
+Draft the page as a compact table BEFORE asking anything — the question round
+presents choices about a concrete plan, not abstractions. Per section:
+
+| section | layout family | media plan | motion treatment | interaction | fallback |
+
+- **media plan** — one of: `generate-image` (subject + exact aspect + palette/
+  light-temperature prompt notes), `generate-video` (loop subject, 5-10s,
+  seamless), `generate-sequence` (N frames for scroll scrub), `real-asset`
+  (exists in repo / user must supply — name it), `none`. Media enters through
+  the motion system per `skills/media.md` — name the treatment (curtain reveal,
+  mask-shaped, hover-woken, media-plane distortion…), never "add an image".
+- **motion treatment** — from motion.md/immersive.md/cinematic.md vocabulary,
+  with the dial-appropriate ambition (motion.md §9 inventory is the target).
+- **fallback** — for every ambitious cell (WebGL, sim, scrubbed sequence,
+  generated video), the concrete boring version that ships if the fancy one
+  fails runtime verification. A plan cell without a fallback is not ambitious,
+  it's fragile.
+
+Plus four page-level lines: register + design read (DESIGN.md §2), signature
+element, animation stack (ONE system: GSAP+Lenis or motion/react — motion.md §0),
+and the mobile strategy per ambitious effect (DESIGN.md §13).
+
+## 3. The question round (one AskUserQuestion call, ≤4 questions)
+
+Bundle EVERYTHING the user must decide into one structured round (multi-select
+where choices stack). The pool below holds more than 4 questions — pick the
+ones the request leaves genuinely open, most-decision-changing first; skip any
+the request already answers. Structured tools always offer an "Other" free-text
+option, so every question doubles as a remarks channel — and the round's last
+question should explicitly invite extra direction.
+
+1. **Depth** (redesigns of existing code only) — the §11 transformation-depth
+   ladder: restyle / re-layout / restructure / reimagine.
+2. **Treatments** (multi-select) — the specialist skills with one-line plain
+   descriptions, obvious ones marked "(Recommended)":
+   motion · interaction · 3d · immersive · cinematic · refined · media
+   (generated images/video woven into the motion system) · ux (make every
+   control, form, and state actually work — recommended by default) · mobile
+   (first-class phone experience, calmer but equally crafted) · none.
+3. **Generated media** — the concrete offer from your probe: e.g. "Generate a
+   hero video loop + 4 section images (Recommended)" / "Images only" /
+   "Placeholders, I'll supply assets". If a needed tool is missing, this is
+   where the install offer goes ("I can add <X> MCP for video generation — ok?").
+4. **Ambition tier** — safe (clean + light motion) / expressive (full motion.md
+   dial 7-8 inventory) / award-site (dial 9-10, immersive/cinematic
+   architecture). State the cost honestly: higher tiers mean heavier builds and
+   a mandatory runtime verification pass.
+5. **References** — "Do you have a reference — a website you love, a
+   screenshot, a brand whose feel to chase?" Options like: paste a URL /
+   attach screenshots / "surprise me — invent it from the brand" / match the
+   existing brand. When a URL or image arrives, actually study it before
+   designing (SKILL.md's references rule: fetch the site / read the image,
+   distill what specifically to borrow — palette, type feel, layout family,
+   motion cues — never guess a named site from memory).
+6. **Vibe & audience** (when the brief is thin) — 3-4 contrasting directions
+   as options, each a one-line register + palette + energy sketch ("quiet
+   luxury: bone, near-black serif, almost no motion" vs "electric launch:
+   drenched color, kinetic type"), plus who the page must convince (buyers /
+   investors / recruiters / fans). This seeds DESIGN.md §2's design read.
+7. **Scope & priorities** (multi-page or vague requests) — which pages/flows
+   matter most, what's in this pass vs later, and any hard constraints
+   (existing brand tokens to keep, CMS/content that must survive, deadline
+   implying the safe tier).
+8. **Final remarks** — close the round with an open catch-all: "Anything else
+   I should know or you'd love to see — specific effects, colors you hate,
+   sections to add or kill?" Options: "no, go build" / "yes (write it in
+   Other)". Everything written here lands verbatim in the plan file and is
+   honored like the brief.
+
+Cap at 4 per round: depth/treatments/media/references usually win; fold
+ambition into treatments' recommendations when crowded, and vibe/scope into
+the blueprint you present for approval. Never re-ask in later rounds;
+ambiguity discovered mid-build resolves by the plan's spirit + doctrine
+defaults.
+
+## 4. Write the plan, then execute it
+
+Persist the approved plan to `.dreative/plan.md` (or the scratchpad if
+`.dreative/` doesn't exist): capability manifest, every answer verbatim
+(including references studied — with the distilled borrow-list — and all
+free-text remarks), blueprint table, stack, mobile strategy, fallbacks. Long sessions lose context; the plan file is
+the re-entry point — re-read it instead of re-deciding.
+
+**Execution order (always):**
+
+1. **Assets first.** Generate every planned image/video/sequence NOW, at the
+   blueprint's aspect ratios, graded to the palette (media.md §1). Sections get
+   designed around real assets, not around placeholders that "will be swapped".
+2. **Foundation.** Install and WIRE the animation stack (motion.md §8), fonts,
+   tokens, providers — before any section code.
+3. **Sections** in blueprint order, each honoring its row (skills tagged per
+   section apply to that section).
+4. **Effects + choreography** across sections (page-level timelines, transitions,
+   the signature element).
+5. **Verification** — the full runtime protocol (SKILL.md self-critique +
+   runtime gates). Any effect that fails gets its planned fallback, and the
+   final report says so: "shipped the §2 fallback for X because Y".
+
+Report against the plan when done: each blueprint row → shipped / fallback /
+cut (with reason), plus the motion inventory (motion.md §9) and the preservation
+ledger when §11 applies. A build that silently diverges from its approved plan
+is a bug even when it looks good.

package/skill/dreative/SKILL.md

@@ -7,13 +7,16 @@ description: Frontend design skill + optional visual round-trip editor. Use for
 
 You (the coding agent) are the intelligence. Dreative has **two modes**:
 
-- **Mode A — Direct design (default).** The user asks you to design, redesign, restyle, animate, or build UI. Read `DESIGN.md` (and any specialist `skills/<name>.md` the work calls for — motion, 3d, interaction), then design/edit the real code directly. No server, no extraction, no wireframes. When you finish, add one closing note: *"Tip: run `dreative start` / say 'open dreative' if you want to tweak this visually — I'll extract the pages into an editable canvas."* That's the only place the editor should come up; never force the round-trip on a plain design request. **Depth first:** when the request implies more than a fresh coat of paint ("redesign", "change it entirely", "make it like <reference site>"), present DESIGN.md §11's transformation-depth ladder (restyle → re-layout → restructure → reimagine) as explicit options and let the user pick BEFORE designing; a confirmed restructure/reimagine means rebuilding markup, component trees, and routing for real — never just editing stylesheets on the old skeleton. **Preservation contract (non-negotiable when redesigning existing code):** BEFORE editing any existing page, build the preservation manifest per DESIGN.md §11 (every link, id/data-attribute, handler, form field, visible string, data view, and conditional state — tabs, modals, auth branches); AFTER redesigning, mechanically verify each entry survives in the new code and report the preservation ledger. Restructure moves things; it never loses them. **Real motion engineering:** when motion/3d/immersive/cinematic treatments are chosen, deliver them with the proper libraries per the skill files (GSAP + ScrollTrigger, Lenis, `motion/react`, three.js/R3F) — actually add the dependencies to the project (`npm i gsap lenis` etc.), wire providers/render loops, and build the choreography. A static page with a few CSS transitions does not fulfill a motion request; the target is unseen.co-grade coordinated animation, the shipped result must clear the motion-dial inventory in `skills/motion.md` §9, and the self-critique pass must name the specific animations shipped. **Generated media:** probe your environment for image/video generation tools before designing and use them per DESIGN.md §7 — generated hero imagery, textures, and especially seamless video loops (hero backgrounds, pre-rendered living surfaces, hover previews) integrated into the motion system are among the highest-impact upgrades available. **Skill picker:** in the same pre-design question (use the agent's structured question tool, e.g. AskUserQuestion, multi-select), offer the specialist skills with a one-line plain-language description each so the user chooses the treatments they want — recommend the ones the request obviously implies and mark them "(Recommended)":
+- **Mode A — Direct design (default).** The user asks you to design, redesign, restyle, animate, or build UI. For any non-trivial request, FIRST run Plan Mode per `PLAN.md` (same folder): probe your environment's capabilities (image-gen, video-gen, browser tools), draft a section-by-section blueprint with a media plan and fallbacks, bundle every user decision into one structured question round, persist the approved plan, then execute assets-first. Read `DESIGN.md` (and any specialist `skills/<name>.md` the plan calls for), then design/edit the real code directly. No server, no extraction, no wireframes. When you finish, add one closing note: *"Tip: run `dreative start` / say 'open dreative' if you want to tweak this visually — I'll extract the pages into an editable canvas."* That's the only place the editor should come up; never force the round-trip on a plain design request. **Depth first:** when the request implies more than a fresh coat of paint ("redesign", "change it entirely", "make it like <reference site>"), present DESIGN.md §11's transformation-depth ladder (restyle → re-layout → restructure → reimagine) as explicit options and let the user pick BEFORE designing; a confirmed restructure/reimagine means rebuilding markup, component trees, and routing for real — never just editing stylesheets on the old skeleton. **Preservation contract (non-negotiable when redesigning existing code):** BEFORE editing any existing page, build the preservation manifest per DESIGN.md §11 (every link, id/data-attribute, handler, form field, visible string, data view, and conditional state — tabs, modals, auth branches); AFTER redesigning, mechanically verify each entry survives in the new code and report the preservation ledger. Restructure moves things; it never loses them. **Real motion engineering:** when motion/3d/immersive/cinematic treatments are chosen, deliver them with the proper libraries per the skill files (GSAP + ScrollTrigger, Lenis, `motion/react`, three.js/R3F) — actually add the dependencies to the project (`npm i gsap lenis` etc.), wire providers/render loops, and build the choreography. A static page with a few CSS transitions does not fulfill a motion request; the target is unseen.co-grade coordinated animation, the shipped result must clear the motion-dial inventory in `skills/motion.md` §9, and the self-critique pass must name the specific animations shipped. **Generated media:** probe your environment for image/video generation tools before designing and use them per DESIGN.md §7 — generated hero imagery, textures, and especially seamless video loops (hero backgrounds, pre-rendered living surfaces, hover previews) integrated into the motion system are among the highest-impact upgrades available. **Skill picker:** in Plan Mode's single question round (PLAN.md §3 — use the agent's structured question tool, e.g. AskUserQuestion, multi-select), offer the specialist skills with a one-line plain-language description each so the user chooses the treatments they want — recommend the ones the request obviously implies and mark them "(Recommended)":
   - **motion** — scroll animations, staggered entrances, parallax, kinetic type
   - **interaction** — micro-interactions: hover states, magnetic buttons, cursor effects, tactile feedback
   - **3d** — WebGL / three.js scenes, shader backgrounds, 3D product showcases
   - **immersive** — award-site feel: the page becomes a spatial world, scroll-as-journey, page transitions
   - **cinematic** — dark, shader-graded experiential look: fluid/particle surfaces, drag-to-explore, sound
   - **refined** — premium clean business look: whitespace, photography, calm minimal motion (the professional pole)
+  - **media** — generated images/video woven into the motion system: hero video loops, distortion galleries, living thumbnails
+  - **ux** — make everything actually work: nav, mobile menu, forms, states, keyboard, nothing blocks clicks (recommend by default)
+  - **mobile** — first-class phone experience: clean, tidy, thumb-ergonomic, with animations scaled to mobile (calmer than desktop, still premium)
   Plus a "none — plain design doctrine only" option. Skip the question only when the user already named the treatments or the request is trivially a restyle; read each chosen `skills/<name>.md` before designing.
 - **Mode B — Visual round-trip (only when asked).** The user explicitly wants the visual editor ("open dreative", "let me edit visually"). Flow: **extract → baseline → serve requests → finish → apply**. Be token-frugal at every step: read only the files you need, never re-read the whole app, and keep JSON compact.
 
@@ -21,11 +24,15 @@ Everything below §0 describes Mode B; the design doctrine paragraphs apply to b
 
 **Design quality is a hard requirement.** `DESIGN.md` (same folder as this file) is the design doctrine. Read it ONCE before servicing the first `propose-skeletons`, `propose-variants`, `design-page`, or `edit-element` request, keep it in mind for all later ones, and run its pre-flight checklist (§12) before every respond. Requests may carry a `brief` object (aesthetic preset + vibe + dials set by the user in the UI); when present it is the user's explicit direction and overrides doctrine defaults. Before writing any `design-page` code, state (to yourself, one line) the register, the design read, and the signature element — if you cannot name all three, you are about to produce the generic default; stop and commit first.
 
-**Specialist skills.** The `skills/` folder next to this file holds expert playbooks for advanced work: `motion.md` (animation & scroll choreography), `3d.md` (WebGL/three.js/shaders), `interaction.md` (micro-interactions & effect craft), `immersive.md` (award-site worlds, spatial page transitions, scroll-as-journey), `cinematic.md` (dark shader-graded experiential interfaces: fluid/particle surfaces, drag-to-explore, click & hold, sound design — opt-in aesthetic), `refined.md` (premium clean business/DTC/e-commerce: restraint, photography, whitespace — the calm pole). All are universal: they apply directly to any codebase in Mode A; the editor is never required. When a request's `plan.skills` lists names, read each listed `skills/<name>.md` ONCE before writing code (then keep it in mind, like DESIGN.md); when `plan.sections[].skills` tags a section, that section gets that treatment (e.g. "this hero has 3d"). If the brief/prompt clearly calls for one of these but the plan missed it, read it anyway. If a listed file isn't installed, proceed on DESIGN.md alone and note it to the user (`dreative install-skill` installs all).
+**Specialist skills.** The `skills/` folder next to this file holds expert playbooks for advanced work: `motion.md` (animation & scroll choreography), `3d.md` (WebGL/three.js/shaders), `interaction.md` (micro-interactions & effect craft), `immersive.md` (award-site worlds, spatial page transitions, scroll-as-journey), `cinematic.md` (dark shader-graded experiential interfaces: fluid/particle surfaces, drag-to-explore, click & hold, sound design — opt-in aesthetic), `refined.md` (premium clean business/DTC/e-commerce: restraint, photography, whitespace — the calm pole), `media.md` (generated images/video as motion material: production pipeline, DOM and WebGL media treatments, media planes), `ux.md` (the working-page contract: nav, forms, states, keyboard, pointer-events audit — load for any product-register page), `mobile.md` (mobile as a first-class surface: calm-premium motion translation, ergonomics, mobile verification). All are universal: they apply directly to any codebase in Mode A; the editor is never required. When a request's `plan.skills` lists names, read each listed `skills/<name>.md` ONCE before writing code (then keep it in mind, like DESIGN.md); when `plan.sections[].skills` tags a section, that section gets that treatment (e.g. "this hero has 3d"). If the brief/prompt clearly calls for one of these but the plan missed it, read it anyway. If a listed file isn't installed, proceed on DESIGN.md alone and note it to the user (`dreative install-skill` installs all).
 
 **References the user gives you.** If the user attaches screenshots/images, read them with your image tools and treat them as the visual target (extract palette, type feel, layout family, motion cues from any described behavior). If the user names reference URLs, fetch them (browser tools if available, else web fetch of the HTML — look at real script/font/class evidence, not just the text) and distill what specifically to borrow before designing; never guess at a named reference from memory alone when you can look.
 
-**Self-critique pass (Mode A, required before declaring done).** Doctrine at write-time is weaker than judgment at review-time. After implementing a design: run the app and screenshot the result (browser tools / the project's dev server) at desktop AND ~390px mobile width, then grade the screenshots against this rubric — (1) would a stranger name the brand's register and audience from one glance? (2) does it pass DESIGN.md §2's slop tests *as rendered* (not as intended)? (3) is the signature element actually visible and working? (4) any overflow, contrast failure, unloaded font/image, or motion jank? (5) does mobile hold up per DESIGN.md §13? (6) preservation ledger clean — every link, action, form field, text string, and tab/modal/state from the manifest present or logged as intentional? (7) if motion treatments were chosen: are the animation libraries actually installed and imported, and can you name ≥3 specific shipped animations (element + trigger + duration) visible in the running page? Fix what fails and re-check once. If you cannot screenshot (no browser available), say so explicitly and walk the rendered DOM/CSS mentally against the same rubric — never silently skip the pass.
+**Verification pass (Mode A, required before declaring done).** Doctrine at write-time is weaker than judgment at review-time, and screenshots alone cannot catch broken function — a dead WebGL canvas, a menu that won't close, an invisible layer eating clicks all screenshot fine. Verification is TWO stages, both mandatory.
+
+*Stage 1 — runtime gates (functional).* Run the app with browser tools and prove the page WORKS: (a) **console clean** — zero uncaught errors/unhandled rejections while loading, scrolling the full page, and interacting; (b) **effects provably running** — if WebGL shipped, the canvas has a live context and draws (not black/blank); if animations shipped, sample a moving element's transform twice ~500ms apart and confirm it changes, and confirm scroll triggers fire at their positions; if video shipped, confirm `!video.paused` and the poster shows pre-play; (c) **interaction smoke test** — run `skills/ux.md` §7's functional audit (click nav links, open/close the mobile menu, submit a form invalid+valid, tab through, hit-test controls inside effect-heavy regions); (d) at ~390px too (`skills/mobile.md` §5 when mobile shipped). **Failure doctrine:** any effect that fails a runtime gate is fixed or replaced with its planned fallback (PLAN.md §2) before done — never shipped broken, never silently removed; the final report names what fell back and why.
+
+*Stage 2 — visual self-critique.* Screenshot the result at desktop AND ~390px mobile width, then grade the screenshots against this rubric — (1) would a stranger name the brand's register and audience from one glance? (2) does it pass DESIGN.md §2's slop tests *as rendered* (not as intended)? (3) is the signature element actually visible and working? (4) spatial integrity per DESIGN.md §15 — scan the screenshot for anything overlapping anything else: controls covered by other elements, rows/text clipped at a viewport or container edge, two floating widgets fighting for the same corner, fixed bars hiding content; overlap failures outrank aesthetic ones — fix them first? (4b) any contrast failure, unloaded font/image, or motion jank? (5) does mobile hold up per DESIGN.md §13? (6) preservation ledger clean — every link, action, form field, text string, and tab/modal/state from the manifest present or logged as intentional? (7) if motion treatments were chosen: are the animation libraries actually installed and imported, and can you name ≥3 specific shipped animations (element + trigger + duration) visible in the running page? (8) if generated media shipped: posters present, loops playing, treatments wired per `skills/media.md` §5's floors? Fix what fails and re-check once. If you cannot run the app or screenshot (no browser available), say so explicitly and degrade honestly: walk the rendered DOM/CSS mentally against both stages' rubrics, grep for the runtime-gate evidence (imports wired, providers mounted, pointer-events on overlay layers, fallback branches present), and tell the user which gates could not be verified — never silently skip the pass.
 
 ## 0. Setup
 

package/skill/dreative/skills/3d.md

@@ -21,7 +21,9 @@ Cheaper substitutes to consider first: CSS 3D transforms (`perspective` +
 `rotateX/Y` on real DOM — free, accessible, great for cards/mockups/tilt), a
 pre-rendered video/image sequence scrubbed on scroll, or a Lottie/Rive vector
 animation. If the object never needs live lighting or user-driven rotation,
-pre-render it.
+pre-render it — and if a video-generation tool exists in the environment
+(PLAN.md §1's probe), a generated loop or frame sequence (media.md §1) is
+usually the strongest pre-render source.
 
 ## 1. Stack
 
@@ -83,6 +85,27 @@ animated gradient meshes, flowfields, displacement on hover, image transitions.
 - Image effects: sample two textures + a noise mask for transitions; barrel/flow
   distortion on scroll velocity for editorial galleries.
 
+## 4.5 Media in the scene (images & video as textures)
+
+The other half of shader craft: real page media rendered THROUGH WebGL so
+effects can touch it (the unseen.co gallery mechanic — full pattern in
+`skills/media.md` §3):
+
+- **DOM-synced media planes**: the page's `<img>`/`<video>` elements stay in
+  the DOM (a11y/layout/fallback, `opacity: 0` never `display:none`) while
+  textured planes copy their `getBoundingClientRect()` per rAF (lerped).
+  One scene owns ALL planes — never a canvas per image.
+- **Video textures**: `new THREE.VideoTexture(videoEl)` with the element
+  `muted playsinline` and playing; `texture.colorSpace = SRGBColorSpace`;
+  generated seamless loops (media.md §1) make the best texture sources —
+  a pre-rendered loop as a texture often beats a live sim for cost.
+- Effects on media planes: hover ripple/lens (damped `uMouse` + radial UV
+  displacement), velocity stretch + RGB split (clamped, damped decay),
+  noise-mask dissolves between textures (§4), subtle vertex curvature for
+  the floating-paper look.
+- Failure path is wired, not theoretical: WebGL missing/lost or
+  reduced-motion → un-hide the DOM media (`opacity: 1`). Verify it fires.
+
 ## 5. Particles and points
 
 Points/instancing, never meshes-per-particle: `<Points>` + `BufferAttribute`

package/skill/dreative/skills/cinematic.md

@@ -58,7 +58,11 @@ Rules: ONE simulation per site, palette fed from the page tokens, `uTime` slow
 damped — the surface reacts like water, not like a cursor-following gimmick.
 Images/media on the page render INTO the canvas layer (texture planes synced to
 DOM rects — measure, don't guess) so the distortion can touch them; keep real
-DOM (invisible or fallback-visible) underneath for a11y/SEO/selection.
+DOM (invisible or fallback-visible) underneath for a11y/SEO/selection — the
+full media-plane pattern, video textures, and the wired fallback rule live in
+`media.md` §3. When a video-generation tool exists, the pre-rendered-loop
+budget path (§6) becomes first-class: generate the sim-like loop instead of
+building the GPGPU sim (media.md §1).
 
 ## 2. Interaction vocabulary
 
@@ -212,8 +216,11 @@ root layout, outside the router swap point (immersive.md §1).
 7. **The floor.** Reduced-motion still frame, degrade ladder, contrast scrim,
    mobile strategy (poster or halved sim), pause on hidden (§5).
 
-Ship checkpoint after every layer: run it, screenshot it, keep it working.
-A failed step 4 must not take down steps 1–3.
+Ship checkpoint after every layer: run it, screenshot it, READ THE CONSOLE,
+click through it (ux.md §7's audit on the touched surface), keep it working.
+A failed step 4 must not take down steps 1–3 — each layer's fallback is the
+previous layer, and the runtime gate (DESIGN.md §12.18) runs on the final
+stack, not just the last layer added.
 
 ## 7. Changing an existing site into this
 

package/skill/dreative/skills/immersive.md

@@ -30,7 +30,9 @@ intentional. Decide up front:
   No metaphor = you'll produce disconnected effects. The metaphor decides what
   transitions, camera moves, and layout make sense — everything below serves it.
 - Immersive sites still need an **escape hatch**: visible menu with plain links,
-  working back button, deep-linkable routes. Lost visitors close tabs. On touch
+  working back button, deep-linkable routes — all held to ux.md's working-page
+  contract (the menu closes, links resolve, back plays reverse, nothing
+  invisible eats clicks: run ux.md §7 on the world too). Lost visitors close tabs. On touch
   devices the escape hatch becomes the PRIMARY route (DESIGN.md §13): drag/
   spatial navigation conflicts with native scroll, so mobile gets the index-list
   world view or a swipe carousel, with the full world behind an explicit tap-in.
@@ -193,7 +195,8 @@ Everything in motion.md §6 and 3d.md §7 applies, plus genre-specific:
   CTA top-right, awards rail on the edge) stays fixed through every inversion.
   DOM-only, no WebGL — the spatial feel comes purely from theme travel + scale.
 - **World portfolio**: persistent canvas; works as textured planes arranged in
-  depth; scroll flies the camera past them; hover tilts a plane + cursor says
+  depth (DOM-synced media planes per media.md §3 — real images underneath);
+  scroll flies the camera past them; hover tilts a plane + cursor says
   "View"; click = camera dives to the plane which morphs into the project hero
   (shared-element). Back = reverse flight.
 - **Scene-hopping studio site (epic-style)**: stylized environment as stage;

package/skill/dreative/skills/interaction.md

@@ -125,6 +125,9 @@ the static design, not a broken half-effect. All of these are decoration — cap
   `prefers-reduced-motion` disables tracking (element stays styled, static).
 - Nothing in this file may cause layout shift, block scrolling, steal focus, or
   attach a raw `scroll`/`mousemove` listener without rAF batching + cleanup.
+- Effect layers (spotlight overlays, cursor followers, glow/beam wrappers) are
+  `pointer-events: none` — run ux.md §4's pointer-events audit after adding
+  any; an overlay that eats one click fails the whole page's runtime gate.
 - Every effect must survive keyboard use: whatever hover reveals, focus reveals.
 - Effects use palette tokens (accent/neutral), never introduce new hues.
 - If an effect can't be justified in one sentence of communication value

package/skill/dreative/skills/media.md

@@ -0,0 +1,216 @@
+# Dreative Specialist Skill — Media as Motion Material
+
+Load this file when `plan.skills` includes `media`, when the plan's blueprint
+contains any `generate-*` media cell, or when the brief involves imagery/video
+on a page with motion dial ≥ 6. It EXTENDS DESIGN.md §7 (sourcing priority and
+bans still apply) and STACKS with motion.md (timing), 3d.md (shader craft), and
+cinematic.md (the living surface). This file exists because agents know how to
+*embed* media but not how to *use* it: award-grade sites (unseen.co family)
+treat images and video as the raw material the motion system acts on — media is
+choreographed, distorted, revealed, and lit, never just placed.
+
+## 0. The doctrine
+
+- **No bare media at dial ≥ 7.** Every meaningful image/video gets three
+  decisions: an **entrance** (how it arrives — reveal, wipe, materialize), an
+  **idle** (what it does at rest — loop, drift, ken-burns, nothing-on-purpose),
+  and a **response** (what interaction does to it — hover wake, distortion,
+  parallax). "None" is a valid answer per axis, but it must be chosen, not
+  defaulted.
+- **Media and type arrive as one beat.** Time the media entrance with the
+  section's line-mask type reveal (motion.md §4) — image and headline landing
+  together reads as choreography; landing separately reads as two plugins.
+- **One treatment vocabulary per page.** Pick 1-2 media treatments and stamp
+  them consistently (all work cards hover-wake; all section images curtain-
+  reveal). Five different reveal styles = assembled, not designed.
+- **Invent, don't pick.** §2/§3 are springboards, not a menu — the signature
+  media treatment should be COMPOSED for this brand and this prompt using the
+  grammar in §2.5 (a torn-paper archive scrolls differently than a liquid
+  fashion film). Stock-vocabulary media reads as template exactly like stock
+  layouts do; if the user's prompt describes an effect ("images tear apart on
+  scroll"), build THAT effect for real, at the tier it needs.
+- **Real assets outrank generated ones** (DESIGN.md §7). Generated media fills
+  gaps and creates atmosphere; it never replaces the client's product shots.
+
+## 1. Production pipeline (generate → grade → compress)
+
+When the plan calls for generated media, produce it BEFORE section code
+(PLAN.md §4) and produce it correctly:
+
+- **Prompt for the world, grade for the page.** Prompt the brand's physical
+  subject (DESIGN.md §7) PLUS the page's light: temperature ("warm tungsten
+  side-light", "cool overcast daylight"), palette anchors ("deep green shadows,
+  bone highlights"), and grain/mood. Every asset on a page shares ONE lighting
+  logic — mismatched light is the #1 generated-media tell.
+- **Exact aspect ratios** from the blueprint (16:9 hero, 4:5 cards, 1:1
+  thumbnails, 21:9 banners). Never generate square and crop-hope.
+- **Video loops**: 5-10s, prompt explicitly for seamlessness ("seamless loop,
+  continuous motion, no scene change") and slow motion content (drift, steam,
+  fabric, water — fast action never loops cleanly). Generate or extract a
+  **poster frame** for every video (first frame, same grade).
+- **Image sequences** for scroll scrubs: 40-80 frames of one continuous
+  transformation (assemble/rotate/morph). Image-to-video tools can produce
+  these from a single generated still; export frames with ffmpeg
+  (`ffmpeg -i loop.mp4 -vf fps=12,scale=1280:-1 frames/f_%03d.webp`).
+- **Compress before committing**: images → WebP/AVIF at the largest displayed
+  size ×2 max; video → H.264 + AV1 sources, CRF ~28-32, no audio track, ≤ 2-4MB
+  per loop (`ffmpeg -i in.mp4 -an -c:v libx264 -crf 30 -movflags +faststart`).
+  A 40MB hero loop fails the plan even if it's beautiful.
+- Textures too: grain tiles, masks, mattes, displacement maps — generate them
+  instead of hand-rolling SVG (which is banned, DESIGN.md §7).
+
+## 2. DOM-tier treatments (no WebGL — the budget vocabulary)
+
+80% of the effect at 5% of the cost; the right tier below dial 8 or without a
+canvas already on the page. All honor the floors in §5.
+
+- **Curtain / inset reveal**: media enters behind a wipe —
+  `clip-path: inset(100% 0 0 0) → inset(0)` (or 2-4 panel slides), 900ms
+  expo-out, triggered in-view once, synced to the headline's line-mask.
+- **Hover-woken loop**: still poster crossfades to its video loop on
+  hover/focus (240ms), `video.play()` on enter, pause + reset to poster on
+  leave. The "living thumbnail" for work/product cards. Preload `metadata`
+  only; play() only after the crossfade starts.
+- **Mask-shaped video**: the loop plays inside display type
+  (`background-clip: text` on 10vw+ headlines), an arch/circle `clip-path`, or
+  the brand mark (SVG mask). Video becomes identity, not a rectangle. One per
+  page.
+- **Floating media**: 3-5 images hovering in depth — slow damped drift
+  (±6-10px, 4-8s loops, each phase-offset), parallax differential by depth
+  layer, soft tinted contact shadow. The "paper sheets in space" look, pure CSS
+  + one IntersectionObserver.
+- **Ken-burns**: slow scale 1.0→1.06 over 12-20s inside a fixed frame,
+  alternate direction per instance. The refined register's entire motion budget
+  for imagery (refined.md).
+- **Pixel/dither swap**: stepped `image-rendering: pixelated` downscale swap
+  (24px mosaic → full res in 4-6 steps) on scroll progress or hover. Digital-
+  craft registers.
+- **Inner-zoom parallax**: image at 115% height inside `overflow-hidden` frame,
+  `object-position` or translateY driven by scroll (-8%→8%). Media moves, frame
+  doesn't — never parallax the frame itself past text.
+- **Scroll-scrubbed `<canvas>` sequence**: preload frames (§1), draw the frame
+  for the current damped scroll progress; sticky wrapper ≤ 2.5 viewports
+  (motion.md §7's scrub showcase). No WebGL needed.
+
+## 2.5 The invention grammar (compose the signature treatment)
+
+Every media effect — including any the user describes in their own words — is
+three choices multiplied together. Compose deliberately:
+
+- **PROPERTY** (what changes): position/scale · opacity · clip/mask SHAPE
+  (inset, circle, arch, brand mark, jagged polygon) · slices/fragments (the
+  media cut into strips, tiles, or shards that move independently) · UV
+  distortion (WebGL: ripple, stretch, melt, swirl) · resolution (mosaic →
+  sharp) · color channels (RGB split, duotone → full color) · blend/exposure
+  (media develops like a photo print).
+- **DRIVER** (what pushes it): scroll progress (scrubbed) · scroll VELOCITY
+  (agitation that decays) · in-view trigger (one-shot) · hover/focus ·
+  cursor position within the element (directional!) · drag · hold · time.
+- **SHAPE OF PROGRESSION** (how it travels across the media): uniform ·
+  directional sweep (left→right, top→bottom) · radial from a point (often the
+  cursor's entry point) · per-slice stagger · noise-mask (organic, torn) ·
+  along the brand mark's silhouette.
+
+The user's prompt usually fixes one or two axes; you compose the rest from the
+brand's world. "Tearing" = slices + jagged noise-mask edges, driven by scroll.
+"Video fades from left to right on hover" = opacity/mask, hover-driven,
+directional sweep — a gradient `mask-image` whose position animates, 400ms,
+from the edge the cursor entered. Name the composed treatment in the plan
+blueprint like a signature element, and stamp it consistently (§0).
+
+**Worked exotics (copy the construction, not the skin):**
+
+- **Paper tear on scroll**: image duplicated into 2-3 layers, each clipped by
+  a jagged `clip-path` polygon sharing torn edges; scroll progress translates/
+  rotates the pieces apart (±2-6°) with a hairline of background showing
+  through; WebGL version displaces UV along a noise seam. Archive/editorial/
+  punk registers.
+- **Strip-slice reveal**: media as 5-9 vertical strips (repeated
+  `background-image` with offset `background-position`, or plane-per-strip);
+  strips slide in staggered from alternating directions, or shear on scroll
+  velocity. The classic award-site gallery entrance.
+- **Directional hover wipe**: detect the pointer's entry edge (compare
+  enter coordinates to bounds); the reveal (opacity mask, color→duotone,
+  still→video crossfade) sweeps FROM that edge. Feels alive because it
+  answers the gesture's direction.
+- **Cursor-torch reveal**: media sits dimmed/blurred/halftoned; a radial mask
+  tracking the (damped) cursor reveals it sharp and graded — the flashlight
+  over an archive. Pair with a "drag to explore" label.
+- **Melt/liquid exit**: on section leave or route change, UV y-displacement
+  grows by a noise column pattern — the image drips out of frame (WebGL), or
+  budget version: per-strip translateY with eased random offsets.
+- **Shatter/scatter**: media as an instanced tile grid (WebGL) that explodes
+  along scroll velocity and reassembles at rest — the §3 plane system with a
+  per-instance offset uniform; cap tiles ≤ 400.
+- **Print develop**: media enters as paper-white → exposure/contrast/duotone
+  ramps to full grade (CSS `filter` keyframes or a LUT shader), timed with
+  the headline reveal. Photography/portfolio registers.
+
+Discipline stays the law: the composed treatment must still clear §5's floors,
+DESIGN.md §6's "one sentence of communication value", and one-signature-
+per-page — an inventive effect stamped on every image is as loud as a marquee
+on every section.
+
+## 3. WebGL tier — the media plane (the unseen.co mechanic)
+
+When dial ≥ 8 or cinematic/immersive is active, media renders THROUGH the
+canvas so shaders can touch it. The core pattern, in order:
+
+1. **Sync planes to DOM rects.** Real `<img>`/`<video>` elements stay in the
+   document (a11y, SEO, layout, fallback) but render invisible
+   (`opacity: 0`, NOT `display:none` — layout must persist). For each, a
+   textured plane in an orthographic/fitted scene copies its
+   `getBoundingClientRect()` every scroll/resize (rAF-batched; lerp the
+   position for the floaty feel). Texture from `TextureLoader` or
+   `new THREE.VideoTexture(videoEl)` (video must be `muted playsinline` and
+   playing; `texture.colorSpace = SRGBColorSpace`).
+2. **Distortion in the fragment/vertex shader**, uniforms driven by input:
+   - *Hover ripple/lens*: damped `uMouse` + `uHoverStrength` 0→1 spring; UV
+     displacement by radial falloff or noise.
+   - *Velocity stretch / RGB split*: scroll or drag velocity (from Lenis /
+     `useScroll`) → vertex bend + per-channel UV offset, hard-clamped, damped
+     decay to zero (cinematic.md §2). Peak effect at a fast flick stays legible.
+   - *Transition dissolve*: two textures + noise mask `mix()` for gallery/
+     route image swaps (3d.md §4).
+3. **Curved/warped planes**: subtle vertex bend (unseen's floating paper
+   sheets) — displace z by a small curve of UV.x + scroll velocity.
+
+Rules: ONE media-plane system per page owning all planes (one scene, one rAF —
+never a canvas per image); planes pause syncing when off-screen; the DOM
+element remains the interaction target (click/focus/hover listeners on the DOM,
+effects on the plane); reduced-motion and WebGL-failure both fall back to
+simply un-hiding the DOM media (set `opacity: 1`) — this fallback must be
+wired, not theoretical, and it's the first thing runtime verification checks.
+
+## 4. Choosing the treatment (the reasoning frame)
+
+Per media element, walk this in one line each — it's the media ledger the plan
+blueprint (PLAN.md §2) captures:
+
+1. **Role**: hero atmosphere / product evidence / work-card / texture / story
+   beat? Evidence media (screenshots, product photos) gets QUIET treatments —
+   curtain reveal, ken-burns; atmosphere media can take the loud/invented ones.
+2. **Tier**: does the page already pay for WebGL? If yes, media planes (§3);
+   if no, a DOM treatment (§2) or the DOM construction of a §2.5 invention —
+   never add a canvas only to distort one image.
+3. **Entrance / idle / response** per §0, matched to register and dial.
+4. **Failure path**: poster/static version named (reduced-motion, load
+   failure, mobile tier).
+
+## 5. Floors (every treatment, non-negotiable)
+
+- `prefers-reduced-motion`: poster frame / static image, no autoplaying loops,
+  no scrub (static end-state). Test by toggling it.
+- Videos: `muted autoplay loop playsinline preload="metadata"` + `poster`;
+  pause when off-screen (IntersectionObserver) and on `document.hidden`; no
+  audio tracks ever on ambient loops.
+- Loading: explicit `width/height` or `aspect-ratio` on every media box (zero
+  CLS); LCP image/poster preloaded, everything below the fold lazy; a media box
+  is never blank — poster, dominant-color fill, or blur-up while loading.
+- Hover treatments have focus equivalents; touch gets the tap/visible-default
+  story (DESIGN.md §13); media planes and canvases are `pointer-events-none`
+  unless they ARE the control.
+- Budgets: one video loop playing per view, ≤ 2-4MB per loop, sequences ≤
+  ~6MB total, `dpr` capped on media-plane canvases (3d.md §7).
+- Alt text carries voice on images; videos that convey content (not
+  atmosphere) get a text alternative nearby.

package/skill/dreative/skills/mobile.md

@@ -0,0 +1,117 @@
+# Dreative Specialist Skill — Mobile Excellence
+
+Load this file when `plan.skills` includes `mobile`, when the brief says
+mobile-first / most users are on phones / "make the mobile version great", or
+when an app-register product is primarily used on mobile. It EXTENDS DESIGN.md
+§13 (which governs how desktop effects DEGRADE); this file is about designing
+mobile as a first-class surface in its own right — clean, tidy, and still
+genuinely animated and premium, just calibrated to a 390px viewport, a thumb,
+and a battery. It STACKS with whatever treatments were chosen: motion/3d/
+immersive briefs get their mobile-native expression here, never a cropped
+desktop.
+
+## 0. The register: calm confidence, not shrunken desktop
+
+Mobile premium reads differently from desktop premium: less simultaneous
+motion, more focus per viewport, perfect ergonomics. The dial translation:
+desktop ambition N ≈ mobile ambition N−2. A desktop dial-8 site ships a
+dial-6 phone experience that feels JUST as crafted — one hero moment, silky
+scroll reveals, tactile presses — rather than a stuttering copy of the desktop
+choreography.
+
+- **One idea per viewport.** The phone viewport is a frame; compose each
+  screenful like one (hero = one headline + one visual + one CTA, nothing
+  else). If a desktop section held three things, the mobile version stacks
+  them as three clean beats or cuts to the strongest one.
+- **Tidy is the aesthetic.** Consistent gutters (20-24px), one column
+  discipline, generous vertical rhythm (56-80px between sections), no element
+  closer than 8px to another. Clutter reads twice as loud at 390px.
+- **Type recalibrated, not just clamped**: hero 2-3rem (2 lines max with the
+  REAL copy), body stays ≥16px, line-length falls out of the gutters — check
+  headlines don't orphan single words (`text-wrap: balance`).
+
+## 1. Layout patterns that are mobile-native
+
+- Asymmetric desktop grids collapse to intentional single-column ORDER
+  (decide what comes first — usually visual → headline → support → CTA), not
+  DOM-order accidents. Check the collapsed order reads as a story.
+- Horizontal scroll is mobile's extra axis: card shelves, galleries, and
+  chip rows as swipeable strips (`overflow-x-auto` + `scroll-snap-type: x
+  mandatory` on short strips, edge inset, visible peek of the next card —
+  the peek IS the affordance; no scrollbars, no arrows).
+- Sticky bottom bar for the primary action on conversion/product pages
+  (add-to-cart, main CTA): thumb-reach beats footer CTA; respect
+  `env(safe-area-inset-bottom)`.
+- Accordions/tabs for secondary density (specs, FAQs) instead of long walls;
+  tables become stacked cards or a scrollable container with sticky first
+  column — never squeezed 6-column tables.
+- Nav: the fullscreen menu is mobile's one theatrical moment — staggered
+  link entrance (line-mask, 60ms stagger), big touch-sized links (≥ 48px
+  rows), contact/socials in the footer of the overlay. Wired per ux.md §1
+  (focus trap, scroll lock, Esc/back closes).
+
+## 2. Motion on mobile (still premium, never crazy)
+
+The motion inventory scaled to touch (extends motion.md §9):
+
+- **Keep**: one composed hero entrance (≤ 600ms total), line-mask headline
+  reveals, in-view section reveals (2-3, `once: true`), press states on
+  EVERYTHING tappable (`active:scale-[0.98]` — on mobile this is the main
+  interaction feedback, since hover doesn't exist), marquees (pause
+  off-screen), counters, accordion springs.
+- **Translate**: parallax halves or dies (§13); pinned sequences → short
+  sticky sections (≤ 1.5 viewports) or plain stacked beats; hover-woken media
+  → in-view-woken (loop plays while ≥ 60% visible, pauses off-screen) or
+  tap-to-play; magnetic/cursor effects → gone entirely, replaced by press
+  feedback; drag-to-explore → swipe carousel or index list as PRIMARY
+  (DESIGN.md §13).
+- **Ban on mobile**: smooth-scroll libraries at full strength (Lenis: disable
+  or `syncTouch` carefully — fighting native momentum feels broken), more than
+  one scrubbed sequence, simultaneous animation of > 4 elements, any effect
+  that drops the scroll below 60fps on a mid-range phone.
+- Scroll reveals trigger earlier (`margin: "-10% 0px"` not -20%) — mobile
+  viewports are short and users scroll fast; late reveals = users see blank.
+
+## 3. 3D and heavy media on mobile
+
+- Default: replace live 3D with the poster or a pre-rendered loop (3d.md §7,
+  media.md). A generated video loop IS the mobile 3D strategy in most cases —
+  visually near-identical, thermally free.
+- If live 3D ships: dpr capped at 2, sim/particle counts halved, post-FX off,
+  `frameloop="demand"` where possible, pause on scroll-out and
+  `document.hidden`. Test the thermal story: 30s of idling must not heat the
+  phone (no full-rate rAF on static scenes).
+- Video: one playing loop per viewport, ≤ 2MB mobile variants
+  (`<source media>` or renditions), `playsinline` mandatory, poster always.
+- Images: serve mobile-sized renditions (`srcset/sizes`) — a 2400px hero on a
+  390px screen is a failed budget even when it looks fine.
+
+## 4. Ergonomics (the thumb is the cursor)
+
+- Tap targets ≥ 44px (48px preferred) with ≥ 8px gaps; small text links get
+  padded hit areas. Primary actions in the bottom half on app-register
+  screens; destructive actions OUT of easy thumb reach.
+- Respect the gesture map: horizontal edge swipes (back), bottom edge (home)
+  — don't hang custom gestures on them; carousels stop 16px short of edges.
+- Inputs: correct `type/inputmode/autocomplete` (ux.md §2), font-size ≥ 16px
+  (iOS zoom), the focused field scrolls above the keyboard, forms in one
+  column, no fixed elements covering inputs while the keyboard is up.
+- Safe areas: `viewport-fit=cover` + `env(safe-area-inset-*)` padding on
+  fixed bars/corners; nothing under the notch or home indicator.
+- No hover-dependent anything: whatever desktop hover revealed is visible by
+  default, in-view-triggered, or behind an explicit tap (DESIGN.md §13).
+
+## 5. Mobile verification (part of the runtime pass)
+
+At 390×844 (plus one small check at 320px):
+
+1. Walk every section: no horizontal body scroll, no clipped text/controls,
+   no element under fixed bars (DESIGN.md §15 at mobile widths).
+2. Run ux.md §7's audit at this width (menu, forms, taps, console).
+3. Scroll the full page fast: reveals keep up, nothing janks, sticky elements
+   behave through the URL-bar resize.
+4. Confirm the motion translation shipped (§2): press states everywhere, hero
+   ≤ 600ms, heavy effects swapped for their mobile strategy — name what runs
+   on mobile vs desktop in the final report.
+5. If media/3D shipped: posters load, loops play inline (not fullscreen),
+   pause off-screen.

package/skill/dreative/skills/motion.md

@@ -10,7 +10,12 @@ halved parallax, 600ms mobile entrance budget) — decide it at design time.
 If the requested motion needs structure the current markup can't express (pinned
 sections, split text, persistent stages), use DESIGN.md §11's transformation-depth
 ladder: offer restructure as an option and, once confirmed, rebuild the markup —
-don't fake choreography onto the old skeleton.
+don't fake choreography onto the old skeleton. When the page's imagery or video
+participates in the choreography (reveals, scrubbed sequences, distortion,
+hover-woken loops), read `media.md` — media is motion material there, with the
+DOM-tier and WebGL treatment vocabularies and the generation pipeline.
+On phones the whole inventory recalibrates: `mobile.md` §2 is the translation
+table (what keeps, what halves, what dies) — decide it at design time.
 
 ## 0. Pick the tool by the job, not by habit
 
@@ -219,4 +224,6 @@ A motion request is fulfilled only if the final code contains, verifiably
 Before reporting done, list which inventory items shipped and where (element +
 trigger). "The page has hover states" does not clear dial 7+. If a listed item
 was deliberately cut, say so and why. This inventory is what the SKILL.md
-self-critique pass checks against.
+verification pass checks against — and its runtime stage must PROVE the items
+run (transforms changing, triggers firing, console clean), not just find them
+in the source.

package/skill/dreative/skills/refined.md

@@ -10,8 +10,11 @@ craft discipline, not the absence of one.
 
 It EXTENDS DESIGN.md (everything applies; this file tightens the dials). It does
 NOT stack with `immersive`/`cinematic` — those are different registers. It pairs
-well with a light dose of `interaction` (press states, underline draws) and the
-first tier of `motion` (one hero sequence, 2-3 in-view reveals).
+well with a light dose of `interaction` (press states, underline draws), the
+first tier of `motion` (one hero sequence, 2-3 in-view reveals), `ux` (this
+register's audience punishes broken function hardest), and media.md's quiet
+treatments only (ken-burns, curtain reveals, one hover-woken loop — imagery
+here is generated/sourced to ONE photographic grade, media.md §1).
 
 ## 0. The register: expensive silence
 

package/skill/dreative/skills/ux.md

@@ -0,0 +1,144 @@
+# Dreative Specialist Skill — Functional UX (everything works)
+
+Load this file when `plan.skills` includes `ux`, for ANY product-register page,
+and whenever a redesign touches navigation, forms, or stateful views. It EXTENDS
+DESIGN.md §9 (the product floor) into a full working-page contract. Its premise:
+a beautiful page where the menu doesn't open, a link 404s, or an effect eats
+clicks is a FAILED page — visual craft cannot compensate for broken function.
+This skill is the reason "immersive but broken" never ships: it defines what
+"works" means, mechanically, and the runtime verification pass (SKILL.md) tests
+against it.
+
+## 0. The working-page contract
+
+Every page you ship satisfies, verifiably:
+
+1. Every visible control does something real (or is explicitly disabled with a
+   reason). No dead buttons, no `href="#"`, no `onClick={() => {}}`.
+2. Every navigation target resolves — internal routes exist, anchors match real
+   ids, external links open safely (`rel="noopener"`, `target="_blank"` only
+   for true externals).
+3. Every stateful view renders all its states (loading/empty/error/success),
+   not just the happy path.
+4. Keyboard alone can operate everything a pointer can.
+5. Nothing decorative intercepts input, blocks scroll, or steals focus.
+
+## 1. Navigation
+
+- **Links resolve.** Before shipping, list every `href`/`to`/`navigate` target
+  and check each exists (route table, file, or real URL). A designed 404 is
+  still a 404.
+- **Active state**: the nav marks the current page/section (aria-current +
+  visual). Section-scroll pages update it via IntersectionObserver.
+- **Mobile menu is a component, not a hope**: opens AND closes (button, Esc,
+  backdrop click, and on route change); scroll-locks the body while open
+  (`overflow:hidden` on html, restore on close — with scrollbar-gutter
+  compensation so the page doesn't shift); traps focus while open and returns
+  focus to the trigger on close; the toggle reflects state
+  (`aria-expanded`, icon morph). Test the open→navigate→back sequence — stale
+  open menus after route changes are the #1 shipped-menu bug.
+- **Anchors under fixed headers**: every in-page anchor target gets
+  `scroll-margin-top` ≥ header height; smooth-scroll respects reduced-motion.
+- **Logo → home. Back button works** — spatial/SPA transitions must not break
+  history (immersive.md §1); modals and drawers close on back where users
+  expect it (mobile especially).
+- **Custom scroll (Lenis)** must not break anchors, keyboard scrolling
+  (space/PgDn/arrows), or focus-into-view; wire `lenis.scrollTo` for anchor
+  clicks and leave native behavior for the rest.
+
+## 2. Forms
+
+- Every form submits somewhere real, or is explicitly wired to a stub with a
+  visible success simulation — never a button that swallows the click.
+- Labels above inputs (placeholder-as-label banned, DESIGN.md §9);
+  autocomplete attributes on identity fields; correct `type`/`inputmode`
+  (email, tel, numeric) so mobile keyboards match.
+- Validate on submit first (not on first keystroke); after first submit,
+  re-validate per field on blur/change. Errors inline, next to the field,
+  specific ("Enter a valid email"), with `aria-describedby` wiring and focus
+  moved to the first invalid field.
+- Submit feedback: button enters loading state (spinner inside, fixed width,
+  interaction.md §5), double-submit prevented, success confirmed visibly
+  (inline message or state change — not just a toast that may be missed),
+  failure recoverable (inputs keep their values; never wipe a form on error).
+- Enter submits single-field forms (newsletter). Required fields marked; the
+  disabled-until-valid pattern only when errors show on hover/focus of the
+  disabled button, otherwise keep the button enabled and validate on click.
+
+## 3. State coverage (every data view)
+
+For each list/table/feed/detail view, all four states are designed and
+reachable: **loading** (skeleton shaped like the content, DESIGN.md §9),
+**empty** (teaches the interface: what this will show + the action that fills
+it — never a blank area or a lonely "No data"), **error** (what happened + a
+retry affordance), **populated** (including the long-content case: 100 items,
+40-character names, overflow handled per DESIGN.md §15). Async actions get
+optimistic UI only when low-stakes (DESIGN.md §6); destructive actions get
+confirmation and, ideally, undo instead of a scary modal.
+
+## 4. Keyboard, focus, and the hit-area audit
+
+- Full tab walk: every interactive element reachable in visual order, operable
+  (Enter/Space), with a visible `:focus-visible` ring (interaction.md §0), and
+  escapable (no traps outside intentional modal traps).
+- Whatever hover reveals, focus reveals (cards' secondary actions, hover-woken
+  media, dropdown menus). Custom gestures (drag, click-and-hold) always have a
+  plain keyboard/click equivalent (cinematic.md §2).
+- **The pointer-events audit** (the #1 cause of "cool but broken"): walk every
+  overlay in the stacking order — canvases, gradient/grain layers, custom
+  cursor layers, transition curtains, closed menus, preloaders — and verify
+  each is `pointer-events: none` (or removed from the DOM) whenever it is not
+  actively being interacted with. A finished preloader or a closed fullscreen
+  menu sitting at `opacity:0` with pointer-events on is an invisible wall over
+  the whole page. Then hit-test the controls: click every button/link at its
+  visual position — if something above it swallows the click, that's a §15
+  spatial-integrity fail, fix the layer not the button.
+- Modals/drawers: focus trapped inside, Esc closes, focus returns to trigger,
+  `aria-modal` + labelled; scrim click closes (unless data-loss risk).
+- Semantic HTML first: real `<button>`/`<a>`/`<nav>`/`<main>`/headings in
+  order — divs-with-onClick fail half this section automatically.
+
+## 5. Scroll and layout stability
+
+- Zero layout shift from async content: media boxes sized up front (media.md
+  §5), fonts `swap` with metric-compatible fallbacks, skeletons the same size
+  as what replaces them, no banners that push content after load.
+- Scroll restoration: back/forward returns to the previous position (default
+  browser behavior — don't break it with manual scroll-to-top on every route;
+  scroll to top only on forward navigation to a NEW page).
+- Fixed bars: content padded so nothing hides beneath them (DESIGN.md §15);
+  100dvh not 100vh; no horizontal body scroll at 320px.
+- Long pages get orientation aids: sticky nav or progress indication, and a
+  footer that actually ends the page (no infinite-feeling voids).
+
+## 6. Feedback and perceived performance
+
+- Every async action acknowledges input within 100ms (pressed state, spinner,
+  optimistic change) — silence after a click reads as broken even when it
+  works.
+- Toasts only for transient global events; they stack in ONE corner slot
+  (DESIGN.md §15), auto-dismiss ≥ 4s, pause on hover, and are `aria-live`.
+- Destructive/irreversible actions: confirm with specifics ("Delete 3 items?"),
+  never bare "Are you sure?"; prefer undo-toast over confirm-modal when safe.
+- Copy per DESIGN.md §8's UX-writing rules: buttons say what they do, errors
+  say what to do next.
+
+## 7. The functional audit (run at verification time)
+
+This is the checklist the runtime verification pass (SKILL.md) executes with
+browser tools — or walks mentally, file by file, when no browser exists:
+
+1. Click every nav link + the logo; confirm each lands where labeled.
+2. Open and close the mobile menu (both directions, plus Esc, plus navigate-
+   while-open) at 390px width.
+3. Submit each form empty → see inline errors; submit valid → see success
+   state; confirm no double-submit.
+4. Tab through the page start to finish; note any unreachable/invisible-focus/
+   trapped stop.
+5. Hit-test 5+ controls in effect-heavy regions (hero, canvas overlays,
+   floating elements) — every click must land.
+6. Trigger each data view's empty/error state if reachable (or verify the
+   branch exists in code).
+7. Console: zero uncaught errors during all of the above.
+
+Report the result as a pass/fail list, fix fails, re-run the failed items once.