npm - dreative - Versions diffs - 0.5.2 → 0.5.4 - Mend

dreative 0.5.2 → 0.5.4

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (25) hide show

package/dist/cli/audit.js +87 -11
package/dist/cli/audit.test.js +40 -1
package/dist/cli/docsCheck.js +1 -1
package/dist/server/index.js +10 -5
package/dist/shared/artifacts.js +157 -4
package/dist/shared/artifacts.test.js +101 -0
package/dist/shared/design.js +212 -26
package/dist/shared/design.test.js +70 -0
package/dist/shared/ruleSystem.js +101 -11
package/dist/shared/ruleSystem.test.js +94 -19
package/dist/ui/assets/{index-CKwmbx2j.js → index-BQhYTdSa.js} +11 -11
package/dist/ui/index.html +1 -1
package/package.json +5 -5
package/skill/dreative/DESIGN.md +47 -35
package/skill/dreative/PLAN.md +97 -55
package/skill/dreative/SKILL.md +35 -12
package/skill/dreative/recipes/motion-recipes.md +24 -0
package/skill/dreative/references/ARTIFACTS.md +52 -18
package/skill/dreative/references/RULES.json +9 -9
package/skill/dreative/references/TIERS.md +14 -6
package/skill/dreative/schemas/plan.schema.json +161 -11
package/skill/dreative/schemas/verify.schema.json +22 -2
package/skill/dreative/skills/media.md +28 -14
package/skill/dreative/skills/mobile.md +19 -13
package/skill/dreative/skills/motion.md +45 -8

package/dist/ui/index.html CHANGED Viewed

@@ -4,7 +4,7 @@
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1.0" />
     <title>Dreative</title>
-    <script type="module" crossorigin src="/assets/index-CKwmbx2j.js"></script>
+    <script type="module" crossorigin src="/assets/index-BQhYTdSa.js"></script>
     <link rel="stylesheet" crossorigin href="/assets/index-y0gVjC7u.css">
   </head>
   <body>

package/package.json CHANGED Viewed

@@ -1,7 +1,7 @@
 {
   "name": "dreative",
-  "version": "0.5.2",
-  "description": "Frontend design skill for coding CLIs with typed planning, specialist treatments, verification, and an optional visual editor.",
+  "version": "0.5.4",
+  "description": "Frontend design skill for coding CLIs with typed planning, specialist treatments, verification, and an optional visual editor.",
   "type": "module",
   "bin": {
     "dreative": "dist/cli/index.js"
@@ -14,9 +14,9 @@
     "build": "npm run build:server && npm run build:ui",
     "prepublishOnly": "npm run build",
     "build:server": "tsc -p tsconfig.json",
-    "build:ui": "vite build",
-    "test": "npm run build:server && node --test dist/shared/*.test.js dist/cli/*.test.js",
-    "docs-check": "npm run build:server && node dist/cli/index.js docs-check",
+    "build:ui": "vite build",
+    "test": "npm run build:server && node --test dist/shared/*.test.js dist/cli/*.test.js",
+    "docs-check": "npm run build:server && node dist/cli/index.js docs-check",
     "dev": "concurrently \"tsx watch src/cli/index.ts --no-open\" \"vite\"",
     "start": "node dist/cli/index.js"
   },

package/skill/dreative/DESIGN.md CHANGED Viewed

@@ -4,7 +4,7 @@ You MUST read this file before servicing any `propose-skeletons`, `propose-varia
 `design-page`, or `edit-element` request, and run §12 before every respond. It exists
 because LLM-designed UIs converge on one templated look. Every rule corrects a known
 model default, but its category determines how it governs. Requests may carry a `plan` (Dreative's
-pre-computed decision: dials, per-section layout families, budgets, lints) — execute
+pre-computed constraints: dials, depth, source strategy, structural/mobile/expression contracts, budgets, and lints) — execute
 the plan, apply this doctrine to everything the plan doesn't specify. When
 `plan.skills` names specialist skills (`motion`, `3d`, `interaction`, `immersive`,
 `cinematic`, `refined`, `media`, `ux`, `mobile`), the matching
@@ -156,7 +156,7 @@ its own plan didn't describe. Hard rules for any expressive+ no-media build:
    the blueprint's layout-family words couldn't match them, the build
    restyled a card list and called it the spine — that is a depth-honesty
    failure (§11), not a detail.
-2. **≥ 2 bespoke drawn/procedural artifacts.** With no photography, the page
+2. **Bespoke drawn/procedural artifacts carry the missing media role.** With no photography, the page
    earns visual richness from things MADE for it: a live canvas (meter,
    field, trace), custom SVG structure (rules, notches, connectors, dials —
    drawn, not icon-font), procedural texture/grain, a data-driven ornament.
@@ -165,16 +165,14 @@ its own plan didn't describe. Hard rules for any expressive+ no-media build:
 3. **Type does structural work.** Multi-scale composition (oversized
    numerals/designators against small mono metadata), real hierarchy per §6
    — not one font-size row layout repeated N times.
-4. **Motion budget spends on the structure**, not on entrance fades: the
-   spine's own physicality (things racked, tossed, slid, stamped) is the
-   choreography. Motion.md's inventory applies at full dial.
-5. **A live rendered layer is required at award tier.** No imagery does not
-   mean no rendering: the page ships at least one WebGL/canvas system doing
-   real graphic work — a particle field, procedural texture/flowfield,
-   shader-lit surface, a data-driven instrument that never stops — plus
-   dimensional motion somewhere real (CSS 3D card physicality, depth-layered
-   parallax, a lit WebGL surface). A no-media award page with zero rendered
-   pixels is a text document with transitions. Vocabulary to draw from
+4. **Motion budget spends on the structure**, not on entrance fades: the
+   spine's own physicality (things racked, tossed, slid, stamped) is the
+   choreography. Motion.md's treatment and verification rules apply.
+5. **Choose a rendering layer only when it earns its cost.** No imagery can
+   justify Canvas/WebGL when a live procedural or data-driven surface is the
+   concept, but award ambition does not require one. Spatial typography,
+   layered DOM/SVG composition, masks, or other subject-grounded systems may be
+   stronger. Vocabulary to draw from when rendering is warranted
    (subject-grounded, not decorative): oscilloscope/waveform traces driven by
    real events · topographic contour lines drifting · dot-matrix/LED field
    that spells live state · plexus line-network connecting related items ·
@@ -361,10 +359,17 @@ sites win on composition, not decoration; this is where that happens.
 - Product register: responsive behavior is structural (collapse sidebar, responsive
   table), not fluid type.
-## 6. Motion
-Every animation answers "what does this communicate?" — hierarchy, storytelling,
-feedback, or state change. "It looked cool" = delete it.
+## 6. Motion
+Every animation answers "what does this communicate?" — hierarchy, storytelling,
+feedback, or state change. "It looked cool" = delete it.
+Motion has three roles. **Decorative motion** reveals, responds, or adds ambient
+life. **Structural motion** controls hierarchy, pacing, pinning, and composition
+handoffs. **Transformational motion** changes imagery/type/objects into a new
+form or the next scene. Expressive/award pages evaluate key moments for the last
+two roles; opacity, translate, scale, and slight parallax are not automatically
+enough merely because they animate.
 **The 100/300/500 rule:** 100-150ms instant feedback (press, toggle) · 200-300ms
 state changes (menu, tooltip, hover) · 300-500ms layout changes (accordion, modal)
@@ -381,9 +386,12 @@ micro-interactions; the uniform fade-and-rise on every scrolled section is the
 saturated AI tell. Some brands skip entrance motion entirely — restraint as voice.
 Product = 150-250ms, state-conveying only, zero page-load choreography.
-**Mechanics:** animate transform/opacity by default; blur/backdrop-filter/clip-path/
-masks/shadow allowed when they materially improve the effect, bounded to small areas,
-verified smooth. Never casually animate width/height/top/left/margins (use FLIP or
+**Mechanics:** use transform/opacity for ordinary local state when they fit, but
+do not make them the unexamined expressive default. Select CSS, GSAP timelines,
+ScrollTrigger, SVG, masks, `clip-path`, DOM fragments, Canvas, WebGL/shaders,
+sequences, video, Lottie, or 3D by visual result, cost, responsiveness, and
+available assets. Use the simplest mechanism capable of making the intended
+transformation convincing. Never casually animate width/height/top/left/margins (use FLIP or
 grid-template-rows). Sibling stagger `calc(var(--i) * 50ms)` capped at ~500ms total.
 IntersectionObserver (unobserve after firing), CSS scroll-driven animations, or
 Motion/GSAP scroll tools — `window.addEventListener("scroll")` is a hard ban. Reveals
@@ -541,8 +549,11 @@ route slugs, nav labels, form field names, logo, legal copy; extract brand token
 before applying §4 (a purple brand stays purple); apply modernisation levers in
 order — typography → spacing/rhythm → color recalibration → motion layer → hero
 recomposition → full replacement only when unsalvageable. Honor existing
-accessibility wins and analytics hooks. Preserve prior element-level edits when
-`previousFile` is set.
+accessibility wins and analytics hooks. `previousFile` is a composition source
+only for `restyle`. For `relayout`, old code is a content/behavior inventory. For
+`restructure` and `reimagine`, it is a wiring reference only: draft the new
+blueprint independently, then reconcile routes, handlers, data, fields, states,
+accessibility, analytics, required copy, and public APIs.
 ### The preservation contract (mandatory for ANY redesign of existing code)
@@ -637,9 +648,10 @@ coat of CSS on the old skeleton.
 **The drastic-change floor (rungs 3–4).** The chronic failure at these rungs is
 timidity: the agent rebuilds the components but reproduces the old page's shape,
 so a before/after glance reads as a re-theme. That is a failed restructure. At
-rung 3–4 the new page must be **unmistakably a different design at one glance**
-— someone shown both screenshots should assume different products. Concretely,
-change at least TWO structural paradigms, not just their styling:
+rung 3–4 the structural-delta contract must name material changes to page
+architecture, component boundaries, navigation, workflow, or interaction model.
+Tokens, cards, decoration, and entrance motion cannot satisfy it. Relevant
+paradigms can include:
 - **Navigation model** — top bar → side rail / command palette / dock / sticky
   chapter nav / full-screen overlay menu.
@@ -651,12 +663,12 @@ change at least TWO structural paradigms, not just their styling:
 - **Hero concept** — a new signature idea (typographic monument, media plane,
   3D object, kinetic composition), not the old hero with new colors.
-Creativity is bounded by usability: every drastic move must still be MORE
+These are diagnostic possibilities, not quotas. Creativity is bounded by usability: every drastic move must still be MORE
 user-friendly than what it replaces — clearer hierarchy, fewer steps to the key
 action, honest affordances, mobile ergonomics intact (§13, skills/ux.md). A
 restructure that confuses users is as failed as one that changed nothing. The
-self-critique pass at these rungs must answer: "name the two-plus structural
-paradigms that changed, and why each is easier to use than before." If mid-work you discover the chosen rung cannot
+self-critique pass must explain why the implemented delta honestly satisfies the
+chosen depth and how it improves use. If mid-work you discover the chosen rung cannot
 honestly deliver the requested outcome (the reference look demands structure the
 current markup can't express), say so and ask to move up one rung rather than
 shipping an imitation. Rungs 3–4 on an extracted app still honor §11 preservation
@@ -734,11 +746,11 @@ On touch, whatever hover revealed must be visible by default or reachable by
 tap — never lost. Custom cursors simply don't exist on touch; don't ship their
 DOM/listeners there.
-**Pinned/scrubbed sections**: pinning is fragile on mobile (URL-bar resize
+**Pinned/scrubbed sections**: pinning is fragile on mobile (URL-bar resize
 fires viewport changes mid-pin; iOS momentum scroll skips scrub frames).
-Strategies in preference order: (1) keep the pin but shorten it (≤ 1.5
-viewports) and drive it with `position: sticky`, never JS pinning; (2) unpin —
-the same content as stacked sections with simple in-view reveals;
+Strategies in preference order: (1) keep the pin but shorten it and drive it
+with `position: sticky` when reliable; (2) redesign the same idea as a shorter
+mask, layered-parallax, or state handoff sequence rather than merely disabling it;
 (3) `ScrollTrigger.matchMedia()` / a `matchMedia` branch that swaps the whole
 choreography. Never let a desktop pin length ride on a phone.
@@ -765,10 +777,10 @@ clamps DOWN gracefully (hero ≥ 2rem, body stays ≥ 16px — iOS zooms inputs
 under 16px); sticky navs shrink rather than stack; test the three widths 320 /
 768 / 1280 mentally before responding.
-**Motion budget on mobile**: entrance choreography total ≤ 600ms (vs 900ms
-desktop), at most 1 scroll-driven sequence per page, marquees pause when
-off-screen. Battery is a design constraint: continuous rAF loops must idle
-when nothing animates.
+**Motion budget on mobile**: shorten travel and timelines according to content,
+viewport, and measured device cost. Preserve one defining idea when feasible;
+marquees pause off-screen and continuous rAF loops idle when nothing animates.
+Battery is a design constraint, not a reason to erase the concept.
 ## 14. Typography sourcing (escape the first reflex)

package/skill/dreative/PLAN.md CHANGED Viewed

@@ -34,17 +34,16 @@ Enumerate what your environment can actually produce, and write the result down
 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), you MUST ask a real question with a real choice —
-  **stating the gap and moving on is not an offer, it's a disclosure.** The
-  bug this catches: saying "video generation isn't available, so I'll use
-  stills" and continuing is a FAILURE even though it's honest. The fix is a
-  question with at least two live options: "install <concrete MCP/tool name>
-  now and use it" vs "skip it, use <the specific fallback>". Ask it in the
-  decision phase (§3), phrased as a genuine fork, not a heads-up. Never
-  install tools silently; never silently degrade either.
-- The probe result changes the blueprint: no video-gen → hero loops become
-  generated stills + ken-burns or a shader surface; **no image-gen → media
+- Missing video, 3D, or separated source layers is not automatically a blocker.
+  First plan the strongest honest treatment available from generated/sourced
+  stills, local image processing, transparent cutouts, SVG, CSS, Canvas,
+  generated keyframes, or existing project assets. Ask for a tool or source
+  asset only when the requested result cannot be approximated convincingly;
+  present the concrete best-effort fallback in that question. Never install a
+  tool silently and never leave an "advanced animation later" placeholder.
+- The probe result changes the blueprint: no video-gen → stills become layered
+  scenes, masks, related keyframes, frame sequences, tiles/fragments, Canvas
+  samples, or shader textures as the concept warrants; **no image-gen → media
   cells become `source-image` (DESIGN.md §7's priority: verified stock/CDN
   photography), every planned cutout prop becomes a sourced-and-matted photo
   or is cut, and any 3D of an organic real-world subject is re-planned as a
@@ -59,7 +58,7 @@ Rules:
 Draft the page as a compact table BEFORE asking anything — the decision phase
 presents choices about a concrete plan, not abstractions. Per section:
-| section | layout family | media plan | motion treatment | interaction | intensity | fallback |
+| section | layout family | media + preparation | motion class/treatment | interaction | intensity | fallback |
 - **media plan** — one of: `generate-image` (subject + exact aspect + palette/
   light-temperature prompt notes), `generate-video` (loop subject, 5-10s,
@@ -72,8 +71,7 @@ presents choices about a concrete plan, not abstractions. Per section:
   where media itself becomes the visitor-controlled spectacle, not a specific
   catalog effect. A different solution uses a registered planning-time
   substitution with observable success criteria and evidence IDs.
-  When the set-piece uses a depth dive (the default for image-led `award`
-  concepts with depth-capable assets), its
+  When a concept-led set-piece uses a depth dive, its
   `generate-image` cell must plan a DEPTH-CAPABLE composition (a corridor,
   room, landscape, machinery receding — something a camera can enter) and
   the companion assets in the same cell: the depth map and/or the separated
@@ -102,17 +100,18 @@ presents choices about a concrete plan, not abstractions. Per section:
   Every 3D prop cell also names its BERTH (3d.md §3): which lane/stage of
   the section it occupies and what the layout does to make room — a prop
   planned "over the hero image" or with no berth is an invalid cell.
-  At the `award` tier the outcome gate is one unmistakable dimensional or
-  spatial signature. The proven default is a recognizable real GLB or photoreal
-  cutout prop with a berth and asset source. A typography, photographic, data,
-  scene-instrument, or other alternative must use `award.spatialSignature` and
-  prove equivalent depth, recurrence, interaction, and dominance on desktop
-  and mobile. Generic orbs/blobs/toruses remain invalid.
-  At dial ≥ 8 the media column marks each hero/key image quiet-class or
-  PIXEL-class. The proven default is at least half pixel-class (minimum three,
-  set-piece included), each a different mechanism. A coherent alternative may
-  substitute `media.award.pixelCoverage` only when it visibly develops through
-  at least three materially different roles or states and carries runtime proof.
+  At the `award` tier the outcome gate is one unmistakable spatial, media,
+  typographic, or material signature that shapes the journey. If the concept
+  calls for a recognizable physical subject, use a real GLB or photoreal cutout
+  with a berth and source. Typography, layered photography, data, SVG/Canvas,
+  or a scene instrument may be the stronger direct choice; no substitution is
+  needed merely because 3D is absent. Generic orbs/blobs/toruses remain invalid.
+  At expressive/award, the media column records whether each hero/key image
+  stays flat or becomes motion-ready through cutouts, depth layers, masks,
+  fragments, maps, alternate states, a frame sequence, or a Canvas/WebGL
+  texture. Transform only where it strengthens the concept; a still may remain
+  flat as an intentional rest. The default in `media.keyAssetTreatment` is a
+  coherent asset-preparation decision, not a pixel-effect quota.
 - **Travel map (mandatory when any element persists across sections).** If
   the blueprint contains a fixed canvas object, a recurring signature, or any
   scroll-morphing prop that lives through more than one section, add a travel
@@ -121,35 +120,67 @@ presents choices about a concrete plan, not abstractions. Per section:
   it never sits over text or controls (DESIGN.md §15). No berth fits ⇒ the
   object is scripted HIDDEN for that section. A persistent object without a
   travel map is an unplanned collision that verify will find later — plan it
-  now. The set-piece at dial ≥ 8 must also be pixel-transforming per
-  media.md §3 (placement choreography like orbit/collapse doesn't qualify).
+  now. When the set-piece claims transformation, its pixels, layers, form, or
+  role must visibly change; placement choreography alone does not qualify.
 - **Diversity or development (dial ≥ 7 / expressive+).** Choose and record one
-  path in `creativeStrategy`. Diversity uses at least four distinct mechanisms
-  across three distinct drivers. Development uses one coherent signature
-  mechanism that changes through at least three materially different roles or
-  states, supported by two quieter secondary mechanisms and two drivers. The
-  same reveal repeated with different values is neither path. This keeps the
-  proven anti-repetition safeguard without forcing unrelated effects into a
-  coherent concept.
-- **motion treatment** — from motion.md/immersive.md/cinematic.md vocabulary,
-  with the dial-appropriate ambition. **motion.md §5's verification inventory is a hard
-  plan gate, not a target:** at `expressive`/`award` ambition the blueprint
-  must enumerate every §9 item for its dial — which element carries it, what
-  triggers it — or explicitly name the item as cut with a reason. A plan that
-  neither covers nor justifies a §9 item is incomplete; rework it before
-  presenting, don't ship the gap to the build.
+  path in `creativeStrategy`. Diversity uses only the mechanisms and drivers the
+  concept needs, tied together by a shared language. Development evolves one
+  coherent signature through materially different roles with quieter support.
+  The same reveal repeated with different values is neither path. Do not add
+  unrelated mechanisms to satisfy a count.
+- **motion treatment** — from motion.md/immersive.md/cinematic.md vocabulary,
+  with dial-appropriate ambition. At `expressive`/`award`, complete every
+  `motionTreatment` field below and name the element/driver for each planned
+  moment. A generic or incomplete treatment is reworked before presentation.
 - **intensity (the pacing map)** — 1–10 per section: how loud this section is
   (motion + media + visual weight combined). The page must read as a CURVE, not
   a flat line: uniform intensity fails in both directions (all loud = exhausting,
-  all quiet = the set-piece feels bolted on). Place deliberate rests (≤ 3)
-  immediately before and after the set-piece so it lands; the hero and the
-  set-piece section are the peaks, nothing else matches them. A blueprint whose
+  all quiet = the set-piece feels bolted on). Place deliberate rests around
+  hero moments where the content permits so they land; supporting sections
+  should not compete with them. A blueprint whose
   intensity column is all the same number is incomplete — rework the pacing
   before presenting.
-- **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.
+- **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.
+### Motion treatment and complexity budget
+At expressive/award, write a coherent scene sequence before implementation. For
+every major section record in `motionTreatment`:
+- static composition and motion class (`none`, `decorative`, `structural`, or
+  `transformational`);
+- starting and ending visual states;
+- what changes, persists, pins, enters, transforms, combines, fragments, or exits;
+- the handoff into the next composition;
+- narrative/emotional purpose;
+- rendering mechanism;
+- mobile translation and reduced-motion state.
+Decorative motion introduces or responds. Structural motion controls hierarchy,
+pacing, pinning, and composition. Transformational motion changes form or turns
+one composition into the next. Opacity, translate, scale, and light parallax are
+not sufficient evidence of structural or transformational motion.
+Record `motionComplexityBudget`: normally two or three hero moments (one is valid
+for a short page), calm sections around them, shared motion language, target-
+device limits, and progressive enhancement. Spend complexity where the story
+changes state; do not distribute medium-complexity effects evenly.
+Choose the simplest mechanism capable of producing the intended transformation
+convincingly. Simplicity means implementation suitability, not visual blandness.
+Choose deliberately among CSS, Motion, GSAP/ScrollTrigger, SVG masks/filters,
+`clip-path`, DOM fragments, Canvas 2D, WebGL/shaders, image sequences, video,
+Lottie/vector animation, and 3D. Neither basic transforms nor WebGL/3D/pixels are
+an unexamined default.
+Before approving the plan, record `antiDefaultReview` answers: are images mostly
+fading/scaling/sliding; are sections independent reveals; where is the major
+composition handoff; how does motion change visual state; could this system fit
+an unrelated site; what is memorable; and how does movement express the concept?
+If the result is generic at expressive/award, revise the scene plan now.
 Plus four page-level lines: register + design read (DESIGN.md §2), signature
 element, animation stack (ONE system: GSAP+Lenis or motion/react — motion.md §2),
@@ -160,10 +191,11 @@ discovered at build time: if the signature is a visual OBJECT, it must be a
 subject a stranger names correctly (3d.md §1–2's subject test). An abstract
 crude coded organic form is a hard-gate failure. Generic spheres/orbs/rings/
 blobs/toruses with no brand-native function remain invalid signatures. The
-proven `award` default is a real GLB or rung-2 transparent photoreal cutout;
-an alternative spatial typography, layered photography, data structure, or
-interactive instrument uses a registered substitution and must outperform the
-default on depth, recurrence, input response, and visual dominance. **Coded custom 3D is
+award work chooses the medium that makes the signature most legible and
+concept-specific. A real GLB or rung-2 transparent photoreal cutout is preferred
+when the signature is a recognizable physical subject; spatial typography,
+layered photography, data structure, or an interactive instrument can be the
+direct plan when the concept supports it. **Coded custom 3D is
 capability-gated at the probe (§1):** offer/plan it only when the probe
 verified an actual quality path — a real GLB in reach, image-gen for
 albedo/label textures, an HDRI/environment source. No verified texture path
@@ -231,8 +263,17 @@ hard cap 7). Structured tools always offer an "Other" free-text option, so
 every question doubles as a remarks channel — and the last question asked
 should explicitly invite extra direction.
-1. **Depth** (redesigns of existing code only) — the §11 transformation-depth
-   ladder: restyle / re-layout / restructure / reimagine.
+1. **Depth** (redesigns of existing code only) — the §11 transformation-depth
+   ladder: restyle / re-layout / restructure / reimagine.
+   Record it independently from ambition. For every page, write the current and
+   proposed models/paradigms, material changes, surviving/rebuilt boundaries,
+   preserved contracts, retained patterns with rationale, forbidden carryovers,
+   and a depth-honesty assessment. Then write the page-level mobile blueprint
+   (task, first viewport, exact order, thumb action, safe areas, navigation,
+   desktop translations, media/motion/forms, 390px and 320px compositions, and
+   why it is not desktop DOM stacking). Classify the page register before
+   composing; transactional, account, admin, and utility pages do not inherit a
+   marketing shell.
 2. **Treatments** (multi-select — THE canonical skill-picker list). List every
    option **individually**, never pre-bundled into a combo choice (a
    "refined+motion+interaction+ux+mobile" single option is a bug — the user
@@ -472,7 +513,8 @@ Persist the approved plan first to `.dreative/plan.json` using
 `references/ARTIFACTS.md` and `schemas/plan.schema.json`; this is the delivery
 contract consumed by `dreative audit`. Render the same decisions as a readable
 `.dreative/plan.md` for the user and session re-entry. Keep section and asset
-statuses synchronized in JSON as the build progresses. Set `doctrineVersion: 2`,
+statuses synchronized in JSON as the build progresses. Set `version: 3` and
+`doctrineVersion: 3`,
 record `implementationStartedAt` immediately before code changes, and ensure all
 rule exceptions predate it. **The first time this run writes into
 `.dreative/`, also write `.dreative/README.md`** with exactly this content

package/skill/dreative/SKILL.md CHANGED Viewed

@@ -72,17 +72,30 @@ Detailed doctrine belongs in those references, not in this orchestration file.
   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.
+  fallback, and verification criteria. Expressive/award plans also include a
+  motion treatment for every major section: static composition, start/end
+  states, changes, pins, handoff, purpose, mechanism, mobile translation, and
+  reduced-motion state.
+- For every existing page, record its register, source strategy, concrete
+  existing-versus-proposed structural delta, page-level mobile blueprint, and
+  typed verification criteria. `restyle` uses `patch`, `relayout` uses
+  `recompose`, and `restructure`/`reimagine` use `rebuild-from-contracts`.
+  Expressive/award pages also need a content/state-specific expression contract
+  or a documented intentional-calm rationale. Record project coherence without
+  repeating one branded shell across unlike page registers.
 - 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.
+(several concept-related mechanisms/drivers) or `development` (one signature
+mechanism evolving through materially different roles with quiet support).
+Allocate a contextual motion-complexity budget: concentrate effort into a small
+number of hero moments, name calm sections, and run the anti-default review.
+Do not satisfy ambition through mechanism quotas. Experimental work explores one
+non-obvious candidate per major section, then selects only the strongest two or
+three to ship.
 ### 3.3 Select skills
@@ -117,16 +130,19 @@ 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.
+- Prepare planned media before section implementation. Treat generated stills as
+  raw material: decide whether each asset stays flat or needs cutouts, depth
+  layers, masks, fragments, variants, maps, or a frame sequence. Record the
+  decision, derivatives, rationale, and 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.
+- A restructure or reimagine creates the new blueprint independently, uses old
+  code only as a behavior/wiring reference, and then reconciles preservation.
+  It is not a stylesheet-only restyle.
 - Every heavy effect ships with its planned reduced-motion, mobile, loading, and
   runtime fallback.
@@ -147,13 +163,20 @@ 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.
+3. Verify desktop (approximately 1280/1440px), 390×844 mobile, and a 320px
+   narrow-mobile fallback for every important page.
 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.
+   Capture initial, early, mid-transition, final, handoff, mobile, and
+   reduced-motion states; add pinned midpoint/exit states when pinning exists.
 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.
+7. At expressive/award, visually inspect the captured states, make at least one
+   refinement to timing, composition, readability, or continuity, and record it.
+8. Write `.dreative/verify.json` v2. Associate each row to a typed criterion,
+   page/section, evidence kind, viewport class, and artifact/test. Run
+   `dreative audit`.
+9. 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",

package/skill/dreative/recipes/motion-recipes.md CHANGED Viewed

@@ -21,6 +21,30 @@ in `recipeAccess`.
 - Sticky CSS for simple pinning; cap pin length and remove/shorten on mobile.
 - Velocity treatments use damped/clamped derivatives, never raw scroll deltas.
+## Optional transformation patterns
+Choose only patterns that express the concept:
+- **Image fragmentation:** split a source into aligned DOM/SVG/Canvas tiles or
+  sampled pixels; disperse, filter, and reconstruct the actual image.
+- **Composition handoff:** carry an object, mask, grid, or type structure from
+  one section into the next instead of resetting the page.
+- **Layered image dive:** separate depth planes or use a depth map and move the
+  camera through the composition.
+- **Mask migration:** evolve one mask window across images or sections.
+- **Object persistence:** keep a key subject staged while its environment,
+  scale, supporting content, and berth change.
+- **Generated-keyframe morph:** blend related still states through masking,
+  displacement, or a bounded frame sequence.
+- **Pixel-to-object reconstruction:** assemble sampled text/image particles into
+  a recognizable subject.
+- **Typography-to-image:** use readable type as mask, grid, path, or fragment
+  source that becomes imagery.
+- **Environmental system:** drive texture, light, particles, type, and objects
+  from the same scroll/interaction state.
+- **Editorial sequence:** treat a long section as one pinned timeline with
+  deliberate internal states rather than independent blocks.
 ## Type
 - Split lines/words/characters only for selected display moments; keep accessible