dreative 0.5.1 → 0.5.3

package/skill/dreative/PLAN.md

@@ -34,32 +34,31 @@ 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
-  question round (§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
-  photo billboard, an abstract form, or cut (3d.md §3 rungs 2/4 — coded
+  photo billboard, a brand-native abstract instrument, or cut (3d.md §1–2 — coded
   organic geometry never becomes the fallback)**; no browser tools → the
   verification protocol's manual fallback (SKILL.md) must be declared up front.
   Missing tools change WHERE assets come from, never whether media/3D rules
-  apply — sourced media carries the same treatment obligations (media.md §0).
+  apply — sourced media carries the same treatment obligations (media.md §1–3).
 
 ## 2. The blueprint (section-by-section, media-first)
 
-Draft the page as a compact table BEFORE asking anything — the question round
+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,
@@ -67,39 +66,52 @@ presents choices about a concrete plan, not abstractions. Per section:
   (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".
-  At dial ≥ 7 the blueprint also names the page's ONE media set-piece
-  (media.md §0 — image tornado, disintegration on scroll, shatter/reassemble,
-  living overlay…) and which section carries it; a dial-7+ plan whose media
-  column is all quiet treatments is incomplete.
-  When the set-piece is a media.md §3.5 dive (the award-tier default), its
+  At dial ≥ 7 the proven default is one meaningful media set-piece and the
+  blueprint names which section carries it. The outcome is a memorable moment
+  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 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
   foreground/background plates, generated in the same prompt world.
-  The set-piece is chosen via
-  media.md's exploration protocol: invent three brand-native candidates not
-  listed in the catalogs, record them + the pick in the plan file — a media
-  plan assembled only from listed effects with no rejected invention on
-  record is minimum-effort compliance. **Custom 3D in a media cell must name
+  The set-piece is chosen via
+  media.md's exploration protocol: invent three brand-native candidates not
+  sourced from recipes, record them + the pick in `conceptExploration`, then
+  load recipe references only for feasibility/implementation/fallback and log
+  them in `recipeAccess`. A media plan assembled from listed effects before
+  original exploration is invalid. **Every media-plane / pixel-class cell
+  names WHICH image asset the effect consumes as its texture/source** — a
+  "shader plane" cell with no named image, or a plane carrying its own
+  separate texture (steel/noise/gradient) layered over the section's
+  photography, is an invalid cell (media.md §2's treatment-identity rule: the
+  treatment must transform the image's own pixels, aligned to its rect —
+  never a decorated rectangle floating over a static `<img>`).
+  **Custom 3D in a media cell must name
   its asset source in the blueprint** — a GLB path, a generated/sourced
   texture (the actual prompt or file), or the billboard cutout it will ride
   on. "Custom 3D bean/bottle/plant geometry" with no named source is an
-  invalid cell: primitives can't produce an organic subject (3d.md §3), so
+  invalid cell: primitives can't produce an organic subject (3d.md §1), so
   re-plan it as rung 2 (photo billboard) or an abstract SUPPORTING form
-  (3d.md §3 rung 3 — never the promoted signature object) at plan time —
+  (3d.md §2 — never a generic promoted signature object) at plan time —
   don't let the build stage discover this. The user picking "custom 3D" in
   the media question grants the *medium*, not an exemption from the ladder.
-  Every 3D prop cell also names its BERTH (3d.md §1.5): which lane/stage of
+  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 award-site ambition the blueprint must contain at least one 3D prop
-  cell (3d.md §0's required prop — GLB or cutout billboard, with its berth
-  and asset source named); zero prop cells = incomplete plan.
-  At dial ≥ 8 the media column additionally marks each hero/key image's
-  treatment as quiet-class or PIXEL-class (media.md §0) and must already
-  satisfy the coverage floor on paper: at least half pixel-class (min 3,
-  set-piece included), each a different mechanism, quiet cells tied to the
-  intensity curve's rests.
+  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
@@ -108,50 +120,107 @@ 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 §0 (placement choreography like orbit/collapse doesn't qualify).
-- **Mechanism-diversity quota (dial ≥ 7 / expressive+).** Floors measure the
-  weakest item; quotas measure the whole page. Across the blueprint's media +
-  interaction columns count the DISTINCT mechanisms (curtain reveal, media
-  plane, drag gallery, cursor torch, disintegration… — by name) and the
-  DISTINCT drivers (scroll, cursor/hover, drag, click, time/idle): the page
-  needs **≥ 4 distinct mechanisms spanning ≥ 3 distinct drivers, and no
-  mechanism used more than twice**. Every hero/key image gets BOTH an idle
-  life and an input response — one or the other is the floor, not the plan.
-  "Curtain reveal ×5 + one set-piece" fails the quota: that is a page grazing
-  its rules, not a designed page. The quota tallies go in the plan file and
-  are re-counted at verify.
-- **motion treatment** — from motion.md/immersive.md/cinematic.md vocabulary,
-  with the dial-appropriate ambition. **motion.md §9's inventory is a hard
-  plan gate, not a target:** at expressive/award-site 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.
+  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 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 §0),
+element, animation stack (ONE system: GSAP+Lenis or motion/react — motion.md §2),
 and the mobile strategy per ambitious effect (DESIGN.md §13).
 
-## 3. The questions (ONE question per call, asked in sequence)
-
-Ask with the structured question tool (AskUserQuestion), **one question at a
-time** — never dump the whole pool in a single round; a wall of 4 simultaneous
-questions is exactly the failure this section prevents. Each answer can change
-what you ask next (e.g. a "cinematic" treatment pick makes the media question
-matter more; "restyle" depth kills the mockup question).
+**Signature-element plan gate.** The signature line is checked HERE, not
+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
+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
+⇒ the `custom 3D` option is presented as "3D-look props (photoreal cutouts
+sold with depth)" and every 3D cell is planned as a rung-2 billboard; coded
+geometry without a texture path is never planned "to be figured out at
+build".
+
+**Previous-run divergence (reruns over the same project).** If
+`.dreative/plan.md` (or verify.md) from an earlier run already exists in this
+project and the user asked for a NEW take (rather than iterating the shipped
+one), read the old plan first and diverge on at least: signature family,
+set-piece family, hero layout family, and palette strategy. Reusing the old
+run's choices because they're in context is the same reflex the entropy draw
+exists to break — a rerun that a user would describe as "the same site again"
+is a failed rerun. Record in the new plan file which axes diverged from the
+previous run.
+
+## 3. The decision phase
+
+Run one short decision phase containing several sequential single-question
+calls. Use the environment's structured question tool when available; otherwise
+ask in chat. Never dump the whole pool in one message: each answer can change
+what comes next (for example, a cinematic treatment makes the media question
+matter more, while restyle depth can remove the mockup question).
 
 **Skip what the prompt already answers.** Before asking anything, walk the pool
 below against the user's prompt + attachments: a question whose answer is
@@ -162,6 +231,33 @@ the ambiguity ("you said animated — full scroll choreography, or calm
 micro-interactions?"). Restate what you inferred from the prompt in the plan
 file so silently-skipped questions are still auditable.
 
+**Answers come only from the user, through the tool.** Never infer, assume,
+or self-supply an answer to a question you posed — an unanswered question
+blocks; a fabricated answer is a corrupted plan. If the user's reply to ANY
+question is itself a question, a request to re-see options, or free text that
+doesn't answer what was asked ("wait, what were the vibe options?"), that
+question is NOT answered: respond to what they asked first (re-present the
+options, clarify), then re-ask the original question as its own call. A
+question consumed by a side-exchange and never re-asked is a lost decision —
+track which pool items actually have answers, not which were merely posed.
+Free text volunteered mid-round (a new feature, a constraint) is captured in
+the plan file AND acknowledged in the next message, but doesn't substitute
+for pending questions.
+
+**Skip-honesty (the under-asking bug).** "Skip what the prompt already
+answers" has a strict test: a question may be skipped ONLY when the prompt
+LITERALLY contains its answer — and the plan file must QUOTE the prompt words
+that answer it next to the skip. "I can infer a reasonable choice" is not a
+skip license; silence in the prompt means ASK. In particular, **treatments
+(item 2), media/asset types (item 3), and references (item 5) are never
+skipped on inference at expressive/award ambition** — these are the three
+questions that most change the build, and a round that jumps from vibe →
+ambition → mockups → remarks without them delivered a design the user never
+chose. Questions that are genuinely N/A (depth on a from-scratch build, scope
+on a single page) are the only inference-skips allowed. If the asked count
+lands under 4 on a non-trivial build, re-check the pool — you almost
+certainly over-skipped.
+
 Order most-decision-changing first, keep the total short (typically 3–5 asked,
 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
@@ -169,7 +265,7 @@ 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 canonical skill-picker list). List every
+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
    can't select a subset of a bundle). Mark the ones the request obviously
@@ -190,16 +286,11 @@ should explicitly invite extra direction.
    - **cinematic** — "dark, moody, movie-like atmosphere: glow, particles, fluid surfaces (think film title sequence)"
    - **refined** — "quiet luxury: lots of space, beautiful photography, very little movement — Apple/fashion-brand calm"
    - **media** — "AI-generated images/video made for this page and woven into the motion (hero film loop, images that come alive)"
-   - **ux** — "everything actually works: menus, forms, cart, keyboard — pretty AND functional" (recommend by default)
-   - **mobile** — first-class phone experience: bespoke mobile choreography and
-     layout treatment beyond baseline responsiveness (thumb-ergonomic redesign,
-     animations re-authored for touch, not just scaled down). **NOT recommended
-     by default** — baseline responsive/working-on-phone is already guaranteed
-     for every build via `ux` + DESIGN.md §13's required mobile strategy line,
-     so don't mark this "(Recommended)" just because a build is ambitious.
-     Recommend it only when the user asks for it, or the brief signals mobile
-     is a primary surface (e.g. explicitly mobile-first, or a mobile-heavy
-     audience/product).
+   - **ux** — "everything actually works: menus, forms, cart, keyboard — pretty AND functional". This is always included; show it as locked/included rather than optional.
+   - **mobile** — first-class phone experience: thumb-ergonomic layout and
+     effects re-authored for touch, not merely scaled down. This is always
+     included at baseline; mark it as an emphasized treatment only when mobile
+     is the primary surface or the user explicitly asks for a mobile-first take.
    - **experimental** — user-facing phrasing: "go weird: images that tear/
      dissolve/reassemble as you scroll, the camera diving into scenes, one
      never-seen-before idea per section". Internally this is the
@@ -214,9 +305,18 @@ should explicitly invite extra direction.
      "never seen before", or award-tier + immersive/cinematic/3d stacked
      together — it's the difference between effects *placed on* the page and
      the page *behaving* like the reference sites when you interact with it.
-   Plus "none — plain design doctrine only". Skip only when the user already
+   Plus "none — no optional treatments" (`ux` and `mobile` still apply). Skip only when the user already
    named the treatments or the request is trivially a restyle; read each
-   chosen `skills/<name>.md` before designing.
+   chosen `skills/<name>.md` before designing.
+
+   **For multi-page work, follow selection with one page-assignment matrix.**
+   Rows are pages and columns are the user-selected optional treatments. Let the
+   user pin any treatment to specific pages. For unpinned selections, propose a
+   distribution based on page purpose and intensity, then ask for one approval
+   of the complete matrix. User pins are authoritative; routing cannot move
+   them or activate unselected optional skills. `ux` and baseline `mobile` apply
+   to every page. Selecting all means every skill is used somewhere in the
+   overall plan—not that every page receives every effect.
 
    **Propose extra, request-specific skills beyond this fixed list** when the
    brief hints at something the 10 named treatments don't cover well (sound
@@ -241,18 +341,33 @@ should explicitly invite extra direction.
    tokens/time, so "images only" or "placeholders" is a legitimate budget
    choice, not a downgrade. If a needed tool is missing, this is where the
    install offer goes ("I can add <X> MCP for video generation — ok?").
+   **Set the iteration expectation honestly:** when the user picks `custom
+   3D`, `custom props`, or (later) the `award` tier, say plainly — in the
+   question's description or the plan recap — that complex 3D motion and prop
+   choreography rarely land perfectly in one pass: the first build ships a
+   working version (planned fallbacks where an effect fails verification),
+   and 1–2 follow-up prompts to tune specific moments are normal and
+   expected. This is a disclosure, not a discouragement; it prevents
+   "the plan promised more than the page shows" disappointment, and it never
+   licenses shipping less than the plan — the verify gates still apply in
+   full on pass one.
 4. **Ambition tier** — present each tier with a plain description, a
    best-fit use case, AND its honest tradeoff (a user choosing blind between
    "cool-sounding" labels is the failure this wording prevents):
-   - **safe** — polished, clean, light motion. *Best for:* dashboards, apps,
-     content-heavy sites, corporate audiences, tight deadlines. *Tradeoff:*
-     looks professional, won't turn heads.
-   - **expressive** — rich scroll motion, 3D accents, everything still
-     instantly usable. *Best for:* most product, e-commerce, and marketing
-     sites — the show/usability sweet spot and the default recommendation.
-     *Tradeoff:* heavier than safe, but visitors never fight the page.
-   - **award-site** — the page becomes an experience: immersive 3D, cinematic
-     pacing, experimental transitions (dial 9-10). *Best for:* portfolios,
+   - **Solid (`solid`)** — polished, complete, responsive, and light on custom
+     effects. *Best for:* dashboards, apps,
+     content-heavy sites, corporate audiences, tight deadlines. *Tradeoff:*
+     looks professional, won't turn heads.
+   - **Premium (`premium`)** — a strong design read, deliberate media, and one
+     signature detail with restrained motion. *Best for:* business, commerce,
+     and marketing work that should feel distinctive without becoming an
+     experience site. *Tradeoff:* more craft and media work than solid.
+   - **Expressive (`expressive`)** — rich scroll motion, 3D accents, everything still
+     instantly usable. *Best for:* most product, e-commerce, and marketing
+     sites — the show/usability sweet spot and the default recommendation.
+     *Tradeoff:* heavier than premium, but visitors never fight the page.
+   - **Award (`award`)** — the page becomes an experience: immersive 3D, cinematic
+     pacing, experimental transitions (dial 9-10). *Best for:* portfolios,
      launches, brand showcases, agency work — anywhere wow IS the goal.
      *Tradeoff:* heaviest build, longest load, and deliberately unconventional —
      visitors explore rather than skim, so it can frustrate someone who just
@@ -261,11 +376,11 @@ should explicitly invite extra direction.
    pass — state that cost too.
    **Which option gets "(Recommended)" is computed, and the default bias is
    UP:** when the brief carries no strong signal either way, recommend
-   **expressive** — unnamed ambition becomes beige (DESIGN.md §2), and this
-   skill exists for drastic change. Recommend **safe** only on concrete
+   **expressive** — unnamed ambition becomes beige (DESIGN.md §2), and this
+   skill exists for drastic change. Recommend **solid** only on concrete
    counter-signals: explicit "minimal / corporate / clean / subtle" language,
    a product/app/dashboard surface rather than a marketing page, or a hard
-   deadline constraint (item 7). Recommending safe to a signal-free brief is
+   deadline constraint (item 7). Recommending solid to a signal-free brief is
    a bug, same class as the item-8 mockup inversion.
 5. **References (ask unless the prompt already supplied them)** — "Do you have
    any reference — an image/screenshot, a website you love, or a video of a
@@ -300,17 +415,17 @@ should explicitly invite extra direction.
    assume "all" just because the brief said "redesign the site" — confirm it.
    Also capture 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).
+   implying the solid tier).
 8. **Mockups first?** — offer to build 1:1 mockups BEFORE the full build:
    "Mockup the key pages first" / "Straight to build". **Which one is marked
    "(Recommended)" is NOT static — compute it from the depth + ambition
-   answers already given:** reimagine or restructure depth, OR award-site
+   answers already given:** reimagine or restructure depth, OR `award`
    ambition, mean this is among the biggest changes the tool can make, so
    **"Mockup first" is the recommended option.** Recommend "Straight to
-   build" only when depth is restyle/re-layout AND ambition is safe/
-   expressive. Getting this backwards (recommending straight-to-build on a
-   reimagine + award-site combo) is a bug, not a stylistic choice. When depth
-   is restructure/reimagine OR ambition is award-site, also offer a third
+   build" only when depth is restyle/re-layout AND ambition is solid/premium/
+   expressive. Getting this backwards (recommending straight-to-build on a
+   reimagine + award combo) is a bug, not a stylistic choice. When depth
+   is restructure/reimagine OR ambition is `award`, also offer a third
    option: **"two divergent mockups"** — the two strongest concepts from the
    explore pass (DESIGN.md §2) each built as a mockup, user picks. State the
    honest cost (a second mockup is real tokens/time); it's an offer, never
@@ -337,7 +452,7 @@ defaults.
 
 ### Calibration references (what the top tiers actually look like)
 
-When the user picks award-site ambition or 3d/immersive/cinematic treatments,
+When the user picks the `award` tier or 3d/immersive/cinematic treatments,
 these are the bar (fetch and study whichever is closest before designing):
 
 - https://www.experiencethebestyou.com/en-GB/ — coordinated scroll choreography
@@ -353,7 +468,7 @@ these are the bar (fetch and study whichever is closest before designing):
   `TextureLoader` — one model, N palettes. Scroll drives it with plain
   `ScrollTrigger.create`; backgrounds are pre-rendered per-flavor video
   loops, not live sims. Lesson: photoreal product 3D = real GLB + real label
-  texture + HDRI environment — never coded geometry (3d.md §3) — and the
+  texture + HDRI environment — never crude organic coded geometry (3d.md §1) — and the
   cheap parts (backgrounds) are pre-rendered video.
 - https://www.cinetica.studio/ — the "composed chaos" register (stack
   verified): Webflow + the FULL GSAP plugin suite (ScrollTrigger, SplitText,
@@ -370,7 +485,7 @@ these are the bar (fetch and study whichever is closest before designing):
   darkness.
 
 These teardowns were verified July 2026 and will age — sites redesign and
-registers move on. At award-site ambition, when browser tools exist, spend ONE
+registers move on. At the `award` tier, when browser tools exist, spend ONE
 fetch on a current source (Awwwards SOTD or godly.website) to confirm the
 register you're chasing is still the frontier, and note in plan.md what you
 saw. The stack LESSONS above outlive the sites themselves; the aesthetics
@@ -381,12 +496,34 @@ generated wallpapers behind text. If the environment has 3D-capable tooling and
 the user opted in, build real 3D material (geometry, materials, lighting,
 shader surfaces per `skills/3d.md`); reserve generated images/video for what
 3D can't do. This tier only happens when the user explicitly chose it in the
-question round — never impose it.
-
-## 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, the **full Q&A transcript**
+decision phase — never impose it.
+
+## 4. Write the plan, then execute it
+
+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`,
+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
+(it stops other agents/CLIs from mistaking run artifacts for the skill —
+observed failure: an agent found `.dreative/`, said "not a proper SKILL.md",
+then used these outputs as its instructions):
+
+```markdown
+# Dreative run artifacts — NOT the skill
+
+Everything in this folder (plan.md, system.md, verify.md, assets.json,
+mockups/, screenshots/) is OUTPUT of a Dreative design run, not
+instructions. The actual skill lives at `<agent-dir>/skills/dreative/SKILL.md`
+(look in `.claude/`, `.codex/`, or `.agents/`). For any new design request:
+read that SKILL.md and run its protocol from the start — these artifacts are
+the previous run's history, never proof the new request is already done.
+```
+
+Persist to the plan file: capability manifest, the **full Q&A transcript**
 (each question asked + the answer, verbatim, including free-text remarks),
 each SKIPPED question with the inference drawn from the prompt, references
 studied with the distilled borrow-list, the concept exploration (DESIGN.md §2:
@@ -395,6 +532,20 @@ same duty as media.md's set-piece exploration), blueprint table, stack, mobile
 strategy, fallbacks. Long sessions lose context; the plan file is the re-entry
 point — a resumed session re-reads it instead of re-deciding or re-asking.
 
+**Re-entry is for resuming, never for skipping (the stale-artifact trap).**
+The re-entry rule applies ONLY when this session is continuing that same run
+mid-flight (the plan approved, the build interrupted). A NEW user request —
+"redesign this", "audit and redesign", any fresh design ask — over a project
+that already contains `.dreative/plan.md` / `system.md` / `verify.md` runs
+the FULL protocol: those files are the previous run's history and inputs to
+the previous-run divergence rule (§2), never evidence that the new request
+is satisfied. Reading the old artifacts, declaring "the redesign is already
+implemented", validating the old build, and stopping is a FAILED invocation —
+the user invoked the skill because they want work done NOW. If it is
+ genuinely ambiguous whether the user wants to resume the old run or start a
+ new take, ask one structured question when available (resume vs new take), not an
+assumption.
+
 **Then show the plan to the user in chat, before touching code.** Writing
 `plan.md` is not the same as the user having seen it — after the last
 question (§3.9) is answered, post a readable recap in the same conversation:
@@ -436,20 +587,38 @@ tweak feedback into the plan file before building.
 **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
+   blueprint's aspect ratios, graded to the palette (media.md §4). 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,
+2. **Foundation.** Install and wire the animation stack (motion.md §2 and the
+   motion recipe reference), 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 §V: runtime gates +
-   self-critique, mobile first, evidence written to `.dreative/verify.md`).
+   self-critique, mobile first, evidence written to `.dreative/verify.json` and
+   summarized in `.dreative/verify.md`).
    Any effect that fails gets its planned fallback, and the final report says
    so: "shipped the §2 fallback for X because Y".
 
+**Execution is mandatory, not advisory.** Once the plan is approved, it MUST be
+carried out in full:
+
+- Work through blueprint rows top to bottom; a row is only closed when its code
+  is written AND its verification gate passes (or its named fallback shipped).
+- Never end the session, summarize, or declare done while unshipped rows
+  remain. If interrupted or the context is compacted, re-read
+  `.dreative/plan.json` (using `plan.md` for narrative context) and resume from
+  the first unshipped row — do NOT
+  re-plan, re-ask, or restart.
+- Cutting a row requires an explicit user decision or a hard technical blocker
+  named in the report; "ran long" is not a reason.
+- Before the final report, walk `plan.json` row by row, mark each one, and run
+  `dreative audit`.
+
 Report against the plan when done: each blueprint row → shipped / fallback /
-cut (with reason), plus the motion inventory (motion.md §9) and the preservation
+cut (with reason), plus the motion inventory (motion.md §5) and the preservation
 ledger when §11 applies. A build that silently diverges from its approved plan
-is a bug even when it looks good.
+is a bug even when it looks good — and a plan left half-executed is a failed
+task, not a partial success.