dreative 0.5.0 → 0.5.2

package/skill/dreative/SKILL.md

@@ -1,126 +1,230 @@
----
-name: dreative
-description: Frontend design skill + optional visual round-trip editor. Use for DRASTIC frontend change — redesign/restructure/build a section, a page, or the whole site; landing pages; animations, motion, 3D, micro-interactions; "make my UI look good" — and for visual editing when the user says "open dreative" or "let me edit the layout visually". NOT for micro-tweaks (a button color, one label) unless the user explicitly invokes it. Default is direct design: apply the design doctrine straight to the codebase, after offering Plan Mode. The browser editor (extract → wireframes → edit → apply diff) is an optional mode the user can ask for.
----
-
-# Dreative — frontend design skill (+ optional visual editor)
-
-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. Your FIRST action for every request is the plan gate per `PLAN.md` (same folder): ask the user "plan first (Recommended) or build directly?" — every time, one question, plan recommended. When plan is accepted, run the PLAN.md protocol: probe your environment's capabilities (image-gen, video-gen, 3D tooling, browser tools), draft a section-by-section blueprint with a media plan and fallbacks, bundle every user decision into one structured question round (including the media-type multi-select with its token-cost warning, and the mockups-first offer), persist the approved plan, build 1:1 mockups of the highest-impact pages if the user opted in, 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.
-
-Everything below §0 describes Mode B; the design doctrine paragraphs apply to both modes.
-
-**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), `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.
-
-**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
-
-Requires `dreative` on PATH (`npm i -g dreative` or `npx dreative`). All commands run from the user's project root. State lives in `.dreative/` (paths in payloads are relative to `.dreative/`).
-
-## 1. Extract (code → layout + replica)
-
-Goal: replicate the app's current UI **view-by-view** so the user recognizes every screen. Do this **one page at a time** — find the routes/pages first (router config, pages/ dir, app/ dir), then open only each page's component files. **Single pass per page:** while the source is in front of you, produce all three outputs at once (layout JSON, replica file, summaries) — never revisit a file for a second output.
-
-**One Dreative page per VIEW, not per route file.** If a route renders mutually-exclusive views — tab panels, admin vs viewer modes, auth states, wizard steps, a modal that fills the screen — each view becomes its own Dreative page. A page's layout must show exactly what the user sees at one moment; never stack multiple tab panels' content into one layout. Name split views `"<Screen> — <View>"` (e.g. "Admin Studio — Library", "Admin Studio — Ranking Board"), give them the same `source`, the same `group` (e.g. `"group": "Admin Studio"`), and cluster them on the canvas. Shared chrome (header, tab bar) repeats in each view's layout, with the active tab noted in its `text`.
-
-**Expose hidden UI.** UI that exists but isn't visible by default must still surface, or the user gets a wrong picture of their app:
-- *Full-screen or view-sized* hidden UI (modals, dialogs, drawers, overlay panels with real content) → its own Dreative page, grouped with its parent screen (e.g. "Library — Edit Show modal").
-- *Small* hidden UI (dropdown menus, tooltips-with-actions, hover-revealed buttons, expandable rows) → model it as a block **inside its trigger's parent**, labeled for what it is (e.g. label "Sort dropdown (opens on click)"), with a `summary` saying when it appears. Don't invent open-state visuals in the replica — the replica shows the default state; the layout is where hidden things are enumerated.
-
-**Fidelity is the whole point.** The wireframe and replica must be recognizable as *that* page at a glance. Model every visible major section in order — hero/banner, search+filter bars, stat/KPI rows, each shelf/carousel with its cards, footers. A real page with 8 visible sections must yield ~8 top-level children, not 3 generic boxes. Card grids get realistic counts (a shelf showing 7 posters → a card-grid the user reads as a row of posters, with real show titles in `text`). Before moving on, self-check: *would the user, seeing only this wireframe, name which page of their app it is?* If not, you under-extracted — fix it before the next page.
-
-Per page, produce:
-
-1. **Layout** — the block tree in `project.json` (schema below).
-2. **Replica** — `.dreative/replica/<pageId>.tsx`: a stripped, non-functional **1:1 visual copy** of the real page. Single file, default export, no imports beyond react, Tailwind classes (translate other styling to Tailwind or inline styles). Strip everything behavioral: no handlers, no hooks, no data fetching; replace dynamic state/props with representative literal values (the ones a real user would see). It only needs to LOOK identical, not work. Every block id from the layout appears as `data-dreative-id="<id>"` on the matching element. Set `replicaFile` on the page.
-3. **Summaries** — on each meaningful block, `summary`: one plain line of what it shows or does ("Submits the signup form and redirects to /dashboard", "Lists the 6 most recent orders from the API"). These render as hover tooltips in the replica so the user understands behavior without you re-reading code later, and they are your own re-entry notes at apply time. Keep each under ~120 chars.
-
-Write `.dreative/project.json`:
-
-```json
-{ "version": 1, "brief": { "aesthetic": "minimal", "vibe": "", "audience": "", "variance": 7, "motion": 5, "density": 4, "notes": "" }, "pages": [ {
-  "id": "pg_home", "name": "Home", "canvasPos": {"x": 40, "y": 40},
-  "theme": { "bg": "#0d0d0f", "fg": "#e8e8ea", "accent": "#f59e0b" },
-  "status": "skeleton", "source": "src/pages/Home.tsx",
-  "layout": { "id": "blk_root", "type": "section", "label": "Home", "direction": "column", "children": [ … ] }
-} ] }
-```
-
-(page objects also take `"replicaFile": "replica/pg_home.tsx"` and `"group": "Admin Studio"` for split views of one screen)
-
-Block: `{ id, type, label, text?, summary?, direction?, sizeHint?, source?, children? }`
-- `type`: section | row | column | nav | hero | card-grid | list | form | footer | text | image | button
-- `label`: short recognizable name (shown on hover/inspector).
-- `text`: the **actual visible copy** (heading text, button caption, first ~80 chars of a paragraph) — set it on every text/button/hero leaf; it renders verbatim in the wireframe so the user recognizes the page.
-- Page `theme` `{bg, fg, accent}`: pull the real CSS colors (page background, main text color, brand accent) so the wireframe card matches the app's look. Set it on every page.
-- `source`: the real file that owns this block (component path). Set it on every block whose owner differs from its parent's — this is what lets you apply the diff later without re-searching.
-- Keep depth sensible (3–5 levels); every meaningful visible element should exist, but don't model every span.
-- Ids must be unique and stable; prefix `pg_`/`blk_` plus a slug.
-- Space pages on the canvas: x += 480 per page.
-- Top-level `brief` is optional at extraction time (the user edits it in the UI); if the app has an obvious existing aesthetic, seed it so redesigns preserve the brand.
-
-Then snapshot the baseline: `dreative baseline` (start the server first, step 2, if not running).
-
-## 2. Launch
-
-```
-dreative start   # serves http://localhost:4820, opens browser (background this)
-```
-
-Tell the user the UI is open: they can view the **Replica** tab (1:1 copy of their real page, hover shows your summaries), drag elements in **Layout**, add/remove blocks, set the **Design brief** (preset + dials), attach reference images and prompts, hit **🎨 Design all**, and click **Finish** when done.
-
-## 3. Service requests (the wait loop)
-
-Repeat until finish:
-
-```
-dreative wait    # blocks up to ~8 min; prints ONE event as JSON
-```
-
-- `{"kind":"none"}` → just run `dreative wait` again.
-- `{"kind":"request","id","type","payload"}` → handle per table below, then
-  `dreative respond <id> <resultFile>` (write the result JSON to a temp file) or `dreative respond <id> --error "why"`.
-- `{"kind":"finish","diff":…}` → go to step 4.
-
-| type | payload | result to respond with |
-|---|---|---|
-| `propose-skeletons` | `{prompt, brief?}` | Array of 1–3 `{name, layout}` page proposals (block schema above), structured per DESIGN.md layout rules |
-| `propose-variants` | `{pageName, layout, brief?}` | Array of 1–3 `{name, layout}` variants |
-| `edit-block` | `{block, instruction}` | The updated block JSON (same id) |
-| `design-page` | `{pageName, layout, brief?, plan?, refImage?, blockRefs, designPrompt?, previousFile?, siblingPages, outFile}` | Write a single-file React+Tailwind component (default export, no imports beyond react) to `.dreative/<outFile>`; every block id in layout must appear as `data-dreative-id="<id>"`. **`plan` is Dreative's pre-computed design decision — execute it, don't re-decide:** it carries resolved dials, a layout family per section (`plan.sections`, sections may carry `skills` tags like `["3d"]`), spacing/motion budgets (`plan.directives`), doctrine violations to fix (`plan.lints`), and required specialist skills (`plan.skills` → read `skills/<name>.md` first). DESIGN.md still governs everything the plan doesn't specify. Read `refImage`/`blockRefs[].refImage` (paths under `.dreative/`) with your image tools; if `previousFile` set, read it and preserve prior element edits. Respond `{"ok":true}` |
-| `edit-element` | `{file, elementId, instruction, refImage?}` | Edit `.dreative/<file>` in place, only the element with `data-dreative-id=elementId`, keeping DESIGN.md rules intact. Respond `{"ok":true}` |
-
-A "Design all pages" click in the UI arrives as one `design-page` request per page, back to back: keep visual consistency across them (same accent, type scale, radius system — the first page you design sets the system for the rest).
-
-Token rules: only read ref images when a request names them; never dump whole files into responses; for edits, edit files directly instead of returning code.
-
-## 4. Apply (finish)
-
-The finish event's `diff` (also saved at `.dreative/finish.json`) contains only what changed vs the baseline:
-
-- `pagesAdded` — full layouts; create real pages/components for them.
-- `pagesRemoved` — confirm with the user before deleting real code.
-- `pagesChanged` — per page: `blocksMoved` (reorder in the source), `blocksAdded`, `blocksRemoved`, `blocksChanged` (only differing props listed; `refImage` = style reference to match, `intents` = behavior notes), plus page-level `refImage`/`designPrompt`.
-
-Use each block's/page's `source` pointer to open **only the owning files**, and each block's `summary` to recall what an element does **without re-reading unrelated code**. Read annotated ref images now (paths relative to `.dreative/`). Make the real code match the final layout and annotations, run the project's checks, and summarize what you changed.
+---
+name: dreative
+description: Frontend design skill for substantial UI work, with an optional visual round-trip editor. Use for pages, sections, redesigns, motion, media, interaction, 3D, and visual editing. Direct design is the default.
+---
+
+# Dreative
+
+Dreative makes the coding agent responsible for design judgment, implementation,
+preservation, and proof. It has no AI runtime of its own.
+
+## 1. Choose the mode
+
+- **Direct design (default):** plan, edit the real application, and verify it.
+  No server, extraction, replica, or wireframe is involved.
+- **Visual round-trip:** use only when the user explicitly asks to open Dreative
+  or edit visually. Follow §8.
+
+For a tiny isolated change, make the change directly and run the smallest useful
+check. For substantial design work, follow every Direct Design step below.
+
+## 2. Read progressively
+
+Read this file first, then only the references selected by the plan:
+
+1. `PLAN.md` — planning and the section blueprint.
+2. `DESIGN.md` — visual doctrine and redesign/preservation rules.
+3. `references/TIERS.md` — ambition-tier deliverables.
+4. `references/ARTIFACTS.md` — machine-readable plan, preservation, ledger,
+   and verification files.
+5. `references/RULES.json` and `references/REFLEX_FONTS.json` — rule categories,
+   failure history, bounded substitutions, and reflex font choices.
+6. `frameworks/<name>.md` — the adapter matching the repository.
+7. Each selected `skills/<name>.md`, once.
+8. Only after three original concepts are recorded, load the relevant
+   `recipes/<name>-recipes.md` for feasibility, implementation, performance,
+   fallback selection, or repair of a weak concept.
+
+Detailed doctrine belongs in those references, not in this orchestration file.
+
+## 3. Direct Design protocol
+
+### 3.1 Discover
+
+- Inspect the minimum repository context needed to understand the relevant page,
+  framework, styling system, routes, and available media/tooling.
+- For an existing interface, create `.dreative/preservation.json` before edits.
+  Include links, handlers, forms, visible copy, states, routes, analytics hooks,
+  and accessibility contracts. Every item needs a stable `file` + `needle` that
+  `dreative audit` can check mechanically.
+- Read `.dreative/ledger.json` when it exists. Treat it as preference and failure
+  history, never as proof that a new request is complete.
+
+### 3.2 Plan
+
+- Run `PLAN.md` and resolve the transformation depth: restyle, relayout,
+  restructure, or reimagine.
+- Resolve one ambition tier: solid, premium, expressive, or award.
+- Explore three genuinely different concepts, commit to one, and record why the
+  others were rejected.
+- Classify important rules through `references/RULES.json`: hard gates are
+  absolute; evidence-backed defaults remain the proven remedy; creative
+  provocations influence exploration rather than becoming shipment quotas.
+- Follow the proven default, or outperform it with a named alternative,
+  measurable success criteria, and runtime evidence. Any substitution is
+  declared before `implementationStartedAt` in `ruleExceptions`; hard gates
+  cannot be substituted.
+- Run one short decision phase containing several sequential single-question
+  calls. Use the environment's structured question tool when available;
+  otherwise ask in chat. Do not ask about implementation details the agent can
+  infer safely.
+- Write `.dreative/plan.json` using `references/ARTIFACTS.md`. For multi-page
+  work, show a page × skill matrix: the user can assign treatments to specific
+  pages, and approve routing for selected skills left unassigned. Every section
+  names its layout family, skills, assets, interactions, mobile translation,
+  fallback, and verification criteria.
+- Render a concise `.dreative/plan.md` for the user and for session re-entry.
+
+The approved plan is a delivery contract. A section ends as `shipped`,
+`fallback`, or `cut` with a reason—never silently omitted.
+
+At `expressive` and `award`, choose one coherent quality path: `diversity`
+(several mechanisms across several drivers) or `development` (one signature
+mechanism evolving through at least three materially different roles, supported
+by two quieter mechanisms). Experimental work explores one non-obvious candidate
+per major section, then selects only the strongest two or three to ship.
+
+### 3.3 Select skills
+
+Universal foundation: ux and baseline mobile apply to every web page.
+Add treatments from this complete picker:
+
+| Skill | Use it for |
+| --- | --- |
+| `refined` | Premium clean business, commerce, photography, and restrained motion |
+| `motion` | Scroll choreography, entrances, parallax, kinetic type, and transitions |
+| `interaction` | Hover craft, magnetic controls, cursor effects, and tactile feedback |
+| `media` | Generated/sourced image and video production, grading, and media treatments |
+| `3d` | WebGL, three.js/R3F, shaders, models, particles, and fallbacks |
+| `immersive` | Persistent scenes, spatial transitions, preloaders, and scroll-as-journey |
+| `cinematic` | Living surfaces, shader grading, gesture exploration, and sound |
+| `experimental` | High-variance composition, material shifts, and unusual provocations |
+| `ux` | Working navigation, forms, states, accessibility, and interaction audits |
+| `mobile` | Mobile-native composition, touch ergonomics, and phone verification |
+
+Skill dependencies are additive:
+
+- All skills depend on `ux` and `mobile`.
+- `immersive` depends on `motion`, `interaction`, and `media`.
+- `cinematic` depends on `motion`, `interaction`, and `media`.
+- `experimental` depends on `motion`, `interaction`, and `media`.
+
+The user's selected skills are authoritative. Routing recommends placement; it
+never silently activates an unselected optional skill. Explicit page assignments
+always win. The planner resolves dependencies and places selected-but-unassigned
+skills across suitable pages for approval. If the user selects all, every skill
+must appear somewhere in the overall plan, but not on every page.
+
+### 3.4 Build
+
+- Prepare planned media before section implementation. Record each asset and its
+  delivery status in the plan.
+- Follow the chosen framework adapter and the repository's established patterns.
+- Preserve the manifest unless the user explicitly approved a change; record
+  approved divergence with a reason.
+- Implement blueprint sections in order. Keep the machine plan status current.
+- Do not open recipe catalogs before `conceptExploration` records three
+  brand-native concepts. Record every recipe file and load time in `recipeAccess`.
+- A restructure or reimagine rebuilds markup/component boundaries when necessary;
+  it is not a stylesheet-only restyle.
+- Every heavy effect ships with its planned reduced-motion, mobile, loading, and
+  runtime fallback.
+
+### 3.5 Craft
+
+Run one dedicated finish pass with no new features:
+
+- typography, wrapping, optical alignment, selection, and scrollbar;
+- coherent surfaces, light direction, shadows, and material cues;
+- hover, focus-visible, active, disabled, loading, empty, and error states;
+- media crop, grading, dimensions, posters, and alt text;
+- motion easing, choreography, intent, and reduced-motion behavior;
+- responsive spacing, touch targets, overflow, and spatial integrity.
+
+### 3.6 Verify
+
+Verification is evidence, not prose asserting that something was checked.
+
+1. Run the repository's targeted tests, typecheck, and build.
+2. Run the page and perform the `ux` functional audit.
+3. Verify desktop and approximately 390px mobile.
+4. Check the console, links, forms, keyboard path, states, reduced motion,
+   responsive overflow, and pointer hit areas.
+5. For motion/WebGL/video, record runtime evidence and performance numbers.
+6. Reconcile every plan section and asset against what visibly shipped.
+7. Write `.dreative/verify.json` and run `dreative audit`.
+8. Fix every error. Warnings require either a fix or a recorded justification.
+
+Every evidence-backed substitution references passing evidence IDs whose proof
+meets its declared success criteria. Vague reasons such as "it did not fit",
+"restraint", "felt better", or "3D was unnecessary" fail audit.
+
+The task is complete only when the plan has no `planned` sections, preservation
+passes, verification contains no failing evidence, and `dreative audit` passes.
+
+### 3.7 Learn
+
+Append one entry to `.dreative/ledger.json` after delivery:
+
+- chosen and rejected concepts;
+- user preferences;
+- treatments already used;
+- runtime failures and the fallback they earned.
+
+Use this history to avoid repetitive signatures and known-bad approaches on the
+next run. Never store secrets or unrelated user information.
+
+## 4. Ambition tiers
+
+- **Solid (`solid`):** complete, accessible, responsive product-quality UI.
+- **Premium (`premium`):** strong design read, deliberate media, signature detail, craft pass.
+- **Expressive (`expressive`):** coordinated motion/interaction system with measured fallbacks.
+- **Award (`award`):** distinctive spatial/media system with performance, occlusion, and
+  fallback evidence.
+
+Higher tiers inherit lower-tier requirements. Do not impose `award`-tier cost on a
+solid or premium request. See `references/TIERS.md` for exact deliverables.
+
+## 5. Preservation rules
+
+- Preserve behavior, not necessarily placement or markup shape.
+- Stable IDs, routes, handlers, form fields, visible strings, conditional states,
+  analytics hooks, and accessibility labels are contractual unless approved.
+- `dreative audit` checks each manifest needle after implementation.
+- Intentional changes require `intentionallyChanged: true` and `changeReason`.
+- A visually successful redesign that loses behavior fails.
+
+## 6. Framework adapters
+
+Load exactly one primary adapter from `frameworks/` plus `styling.md` when useful.
+Adapters provide technical implementation guidance only; they do not override the
+plan, design doctrine, preservation contract, or verification gates.
+
+## 7. Completion report
+
+Report:
+
+- chosen concept, tier, depth, and skills;
+- each section as shipped/fallback/cut;
+- preservation result;
+- tests and runtime evidence;
+- known limitations and next step.
+
+Never claim a check ran unless it actually ran.
+
+## 8. Optional visual round-trip
+
+Use only when explicitly requested:
+
+1. Extract the relevant pages into `.dreative/project.json` and replica files.
+2. Run `dreative baseline`.
+3. Start the editor and service `dreative wait` events.
+4. Supported requests are `propose-skeletons`, `propose-variants`, `edit-block`,
+   `design-page`, and `edit-element`. Read `DESIGN.md` and request-selected skills
+   before responding.
+5. On the `finish` event, apply the compact diff to the real source using its
+   source pointers, then run the same preservation and verification gates as
+   Direct Design.
+
+The editor is an optional input surface. It never weakens the Direct Design
+quality, preservation, or verification contract.

package/skill/dreative/frameworks/nextjs.md

@@ -0,0 +1,13 @@
+# Next.js adapter
+
+- Preserve App Router/Pages Router conventions already used by the repository.
+- Prefer Server Components; add `"use client"` only at the smallest interactive
+  boundary.
+- Keep metadata, loading, error, not-found, route groups, and parallel routes
+  intact during redesigns.
+- Use `next/image` with dimensions/sizes and `next/font` when compatible with the
+  existing stack.
+- Dynamically import browser-only animation/WebGL with SSR disabled and a real
+  poster/skeleton fallback.
+- Do not move data fetching client-side merely to simplify visual implementation.
+- Verify navigation, hydration, production build, and both server/client states.

package/skill/dreative/frameworks/react-vite.md

@@ -0,0 +1,12 @@
+# React and Vite adapter
+
+- Follow the repository's component boundaries and state-management conventions.
+- Keep page structure semantic; use components for repeated behavior, not every
+  visual wrapper.
+- Lazy-load heavy routes and 3D/media systems with `React.lazy` and `Suspense`.
+- Put browser-only effects in guarded effects and clean up listeners, observers,
+  timelines, media, and WebGL resources on unmount.
+- Preserve existing providers, route composition, handlers, and test selectors.
+- Use Vite asset imports or `public/` consistently with the host project.
+- Run the repository's typecheck/build and verify the production bundle, not only
+  the development server.

package/skill/dreative/frameworks/styling.md

@@ -0,0 +1,14 @@
+# Styling-system adapter
+
+- Keep the repository's existing styling system unless migration was explicitly
+  approved.
+- For Tailwind, reuse theme tokens and component recipes; avoid unreadable piles
+  of one-off arbitrary values.
+- For CSS Modules, colocate component styles and keep global tokens/utilities in
+  the established global layer.
+- For CSS-in-JS, preserve SSR extraction and theme providers; avoid per-render
+  style object creation in animated paths.
+- For design systems, compose existing primitives before creating replacements.
+- Put durable color, type, spacing, radius, shadow, and motion decisions in tokens.
+- Verify focus-visible, forced colors where relevant, reduced motion, responsive
+  overflow, and browser support for advanced CSS.

package/skill/dreative/frameworks/sveltekit.md

@@ -0,0 +1,10 @@
+# SvelteKit adapter
+
+- Preserve load functions, actions, route layouts, error pages, and progressive
+  enhancement.
+- Keep browser-only motion/WebGL inside `onMount` and return cleanup functions.
+- Use actions for reusable DOM behaviors and stores/runes according to the
+  repository's established version.
+- Preserve form actions, enhancement behavior, bindings, events, and selectors.
+- Avoid turning server data flows into client-only fetches for visual convenience.
+- Verify SSR/hydration, navigation, actions, production build, and mobile states.

package/skill/dreative/frameworks/vue-nuxt.md

@@ -0,0 +1,12 @@
+# Vue and Nuxt adapter
+
+- Preserve the repository's Composition/Options API convention and component
+  contracts.
+- Keep Nuxt layouts, middleware, route metadata, async data, error, and loading
+  behavior intact.
+- Put browser-only effects behind `onMounted`/`ClientOnly`; dispose them in
+  `onBeforeUnmount`.
+- Prefer scoped components/composables for behavior and semantic templates for
+  structure.
+- Preserve emitted events, model bindings, slots, and test selectors.
+- Verify SSR/hydration, production build, navigation, and state transitions.

package/skill/dreative/recipes/3d-recipes.md

@@ -0,0 +1,44 @@
+# 3D implementation recipes
+
+Load only after three original spatial concepts are recorded. Record access in
+`recipeAccess`.
+
+## Recognizable product/subject
+
+- R3F Canvas loaded dynamically with SSR off.
+- `useGLTF` + preload, Environment/IBL, one key light, contact shadows, bounded
+  camera framing, restrained damped parallax/orbit.
+- Poster occupies the final layout while loading and on mobile/low power.
+- Compress GLB with Draco/Meshopt; measure bytes and triangles.
+
+## Photoreal cutout billboard
+
+- Real transparent image on a plane (`alphaTest` where appropriate).
+- Depth comes from parallax against other layers, restrained perspective
+  rotation, contact shadow, rim/fresnel treatment, and optional angle swaps.
+- Verify alpha, matching light temperature, and no sticker-like overlap.
+
+## Shader surface
+
+- Plane/fullscreen material with `uTime`, damped input, resolution, and palette
+  uniforms from the page system.
+- Slow domain-warp/noise, material response, or media-texture transformation;
+  never use rainbow cycling or promote a generic blob as the signature.
+
+## Points/data structure
+
+- BufferGeometry points or instancing; shader-driven position/size/color.
+- Use when data/spatial subject earns it, not as ambient filler.
+- Desktop count measured; mobile halves or posters; pause off-screen.
+
+## DOM-synced media
+
+- One shared scene, real DOM images/videos retained, planes follow measured
+  bounding rects, exact source assets become textures.
+- Context loss/reduced motion reveals DOM media immediately.
+
+## Runtime checklist
+
+Live context and nonblank draw; asset loaded; texture/material identity; input
+response; reduced-motion still; mobile fallback; context-loss poster; no
+occlusion; capped DPR; frame-time and transferred-weight evidence.

package/skill/dreative/recipes/cinematic-recipes.md

@@ -0,0 +1,19 @@
+# Cinematic implementation recipes
+
+Load after three original cinematic concepts are recorded; log the file and
+timestamp in `recipeAccess`.
+
+- **Living shader surface:** slow palette-bound domain warp/refraction with
+  damped input and graded grain; static poster fallback.
+- **Velocity-reactive media:** exact image/video texture responds to clamped
+  scroll/drag velocity and settles crisp at rest.
+- **Drag-to-explore:** bounded/inertial scene or media movement with keyboard
+  chapter controls and visible instruction.
+- **Click/hold focus:** hold changes material/camera/audio state; click/tap toggle
+  alternative and Escape restores.
+- **Material transition:** same surface masks/dissolves between chapters while
+  content remains semantic DOM.
+- **Audio layer:** opt-in ambient bed plus sparse state cues; mute/pause on hidden
+  and route cleanup.
+- **Budget path:** pre-rendered seamless video/sequence carries atmosphere while
+  DOM interaction and type provide responsiveness.

package/skill/dreative/recipes/immersive-recipes.md

@@ -0,0 +1,18 @@
+# Immersive implementation recipes
+
+Load after three world concepts are recorded; log access in `recipeAccess`.
+
+- **Persistent stage:** root canvas/DOM stage plus route-published scene states;
+  tween between states without remounting the world.
+- **Scroll journey:** tall semantic DOM chapters drive damped camera/material/
+  media state; expose chapter navigation and keep copy selectable.
+- **Shared-object transition:** one subject persists while route content exits,
+  camera/material moves, then new content enters.
+- **Portal transition:** mask/plane opens into the next state; direct URLs render
+  the destination without requiring the transition.
+- **Preloader:** real progress from fonts/models/textures, useful content/fallback
+  immediately available, one choreographed handoff.
+- **Mobile translation:** shorter chapters, no long pins, lower scene complexity,
+  poster/static spatial composition where necessary.
+- **Fallback:** conventional routes and content remain complete when the stage is
+  absent, reduced, or lost.

package/skill/dreative/recipes/media-recipes.md

@@ -0,0 +1,60 @@
+# Media implementation recipes
+
+Load only after `conceptExploration` records three original concepts. Record the
+load in `recipeAccess`. These constructions solve technical problems; they do
+not choose the concept.
+
+## DOM-tier constructions
+
+- **Curtain/window:** overflow-hidden frame; animate an inner clip/mask while
+  coordinating nearby type. Keep the image semantic and dimensions explicit.
+- **Strip/slice:** duplicate the same asset into clipped strips with staggered
+  offsets; cap strip count on mobile and provide an unsliced fallback.
+- **Print/pixel develop:** reveal a preprocessed dither/mosaic state into the
+  final image; avoid per-pixel DOM nodes.
+- **Directional hover:** map entry direction or pointer position to a mask;
+  expose the same content by tap/focus.
+- **Drag/inertia gallery:** pointer capture + velocity decay + bounds; keyboard
+  controls and conventional links remain available.
+- **Frame scrub:** preload a bounded image sequence, draw into one canvas, map
+  scroll/time to frame index, and use a poster on reduced motion.
+
+## WebGL media plane
+
+1. Keep `<img>`/`<video>` in normal DOM flow with semantics and dimensions.
+2. Use its exact asset as the texture and copy its bounding rect to one shared
+   scene plane.
+3. Apply brand-native displacement/refraction/decomposition uniforms driven by
+   scroll, pointer, drag, or time.
+4. Compare effect and source rects during verification.
+5. On context loss, low power, or reduced motion, reveal the DOM media.
+
+Useful families: noise-mask dissolve, UV flow/refraction, velocity smear/RGB
+split, depth-map parallax, point/particle decomposition, slice/shatter,
+feedback/trails, and material-light response. Use the family that develops the
+concept; do not collect one of each.
+
+## Participatory constructions
+
+- **Depth dive:** separate foreground/background or depth map; camera/UV scale
+  crosses the image plane into layered space; reverse cleanly on scroll-back.
+- **Decompose/reassemble:** image samples become particles/tiles and later
+  reorganize into a new semantic state.
+- **Temporal scrub:** visitor controls a meaningful change in time, not a
+  decorative autoplay loop.
+- **Physical media:** drag, throw, stack, sort, or peel assets with inertia and
+  accessible equivalents.
+- **Refractive exploration:** pointer/scroll changes how the visitor sees the
+  same asset rather than layering unrelated noise above it.
+- **Scene-responsive media:** media palette, material, crop, or topology reacts
+  to a persistent scene instrument.
+
+## Performance and fallbacks
+
+- Compress responsive images (AVIF/WebP plus safe fallback), define `sizes`, and
+  preload only true LCP media.
+- Keep initial heavy media inside the selected tier budget; lazy-load later
+  chapters and pause hidden/off-screen work.
+- Cap canvas DPR, reuse buffers/materials, avoid allocations in render loops.
+- Mobile halves complexity or uses a purpose-designed poster/DOM treatment.
+- Fallback preserves the concept's hierarchy even when the mechanism simplifies.