wizz-method 2.14.0 → 2.15.0

package/package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "wizz-method",
-  "version": "2.14.0",
+  "version": "2.15.0",
   "description": "Wizz Method: método de agência orientado por IA em PT-BR",
   "keywords": [
     "agile",

package/skills-registry.yaml

@@ -127,14 +127,14 @@ areas:
       # dentro do `when:` deixa a entrada gulosa e mexe no roteamento).
       - id: wizz-premium-landing-ui-researcher
         door: construcao
-        when: "Projeto NOVO (greenfield): cria landing premium do zero, hero, 3D high-end. Estratégia source-first."
+        when: "Projeto NOVO (greenfield) ou tela inteira refeita: landing premium, hero, 3D high-end, dashboard SaaS ou painel operacional. Estratégia source-first."
         rel:
           after: [wizz-design-needs]
           pairs_with: [wizz-ui-ux-pro-max]
       # Idem: a relação com o mapa vive na aresta `after`, não no `when:`.
       - id: wizz-ui-component-curator
         door: construcao
-        when: "Projeto EXISTENTE: qual componente/efeito adicionar que combina com o estilo atual."
+        when: "Projeto EXISTENTE (site ou painel): qual componente, efeito, hover ou animação de carregamento adicionar que combina com o estilo atual."
         rel:
           after: [wizz-design-needs]
           pairs_with: [wizz-ui-ux-pro-max]

package/src/bmm-skills/4-implementation/wizz-quick-dev/SKILL.md

@@ -43,7 +43,7 @@ You are the leaf: the maestro demotes here for pointed work (bug, tweak, single-
 
 - If clarification reveals the request is actually **multi-goal / multi-area** (2+ top-level shippable deliverables, or it spans several areas), do not silently absorb it. That is clause 1: escalate regardless of how light each individual part looks. Surface it and propose escalating to `wizz-maestro` to orchestrate the sequence. Proceed solo only if the user confirms a narrowed single goal.
 - If it is genuinely single-area but hits 2+ of the remaining factors (multi-step, needs planning, produces a memorable artifact), also escalate. Do not silently absorb heavy single-area work either.
-- **Count those factors with the objective test** (canonical source: `_shared/complexity-signal.md`; same test the Diretor and the maestro apply). **When in doubt, the factor does NOT count.** *Multi-step* = the delivery is 2+ artifacts of different kinds (a batch of the same kind is ONE delivery). *Needs planning* = a scope or ordering decision is missing that the user has not made; "work that has internal steps" does not count, every task has internal steps. *Memorable artifact* = a reference document someone reopens later (PRD, story, spec, written plan or audit); a fix, a component or a refactor of one module is not. A **single delivery** and the **diagnosis of one specific mechanism** stay with you, however important they look; what escalates is the request of **open scope that the request itself does not delimit** ("how do I improve / reduce X" is that, a question with a single definable answer is not), and what escalates regardless of size is a **sensitive subsystem**: changing auth/sessions, payments/billing, permissions, or migrating data that already exists in production goes to the maestro even as a single delivery, because getting it wrong breaks something other than the delivery itself (people locked out, money charged twice, data lost). Running a test against one of those is not changing it. **Changing the product's code is yours even when the subject is visual** — a button colour, mobile spacing: the delivery is a commit, and `designer` decides the look without shipping the change.
+- **Count those factors with the objective test** (canonical source: `_shared/complexity-signal.md`; same test the Diretor and the maestro apply). **When in doubt, the factor does NOT count.** *Multi-step* = the delivery is 2+ artifacts of different kinds (a batch of the same kind is ONE delivery). *Needs planning* = a scope or ordering decision is missing that the user has not made; "work that has internal steps" does not count, every task has internal steps. *Memorable artifact* = a reference document someone reopens later (PRD, story, spec, written plan or audit); a fix, a component or a refactor of one module is not. A **single delivery** and the **diagnosis of one specific mechanism** stay with you, however important they look; what escalates is the request of **open scope that the request itself does not delimit** ("how do I improve / reduce X" is that, a question with a single definable answer is not), and what escalates regardless of size is a **sensitive subsystem**: changing auth/sessions, payments/billing, permissions, or migrating data that already exists in production goes to the maestro even as a single delivery, because getting it wrong breaks something other than the delivery itself (people locked out, money charged twice, data lost). Running a test against one of those is not changing it. **Changing the product's code is yours even when the subject is visual** — a button colour, mobile spacing: the delivery is a commit, and `designer` decides the look without shipping the change. Building new screens in code (a new app, page, dashboard or panel, or a whole screen rebuilt) is not a tweak: the look is not decided yet, so they go design → dev through the maestro.
 - Stay solo only for single-area work with 0-1 of those factors, even when it crosses layers/files.
 
 ## Planning gate (before coding a new feature)

package/src/modules/wizz/agents/wizz-designer/SKILL.md

@@ -34,7 +34,7 @@ For every task, **go through the right door via the `Skill` tool** and bring the
 
 Always **show the visual/plan before the code**. Code building is `wizz-agent-dev`'s job; for a one-off tweak, point to `wizz-quick-dev`.
 
-**Research gate:** for a non-trivial component/effect, research runs against the project's research map (`design-state.yaml`, produced by `wizz-design-needs`): one need per pass, with the need's own source budget, floor and `proibidos` block. Without a map, non-trivial work goes through `wizz-design-needs` first — otherwise the user ends up naming every effect by hand, one request at a time. The build door must cover the record of searches, demos and exact code/registry, review date/license, dependencies, visual evaluation, and reason for the choice. The output of `wizz-ui-ux-pro-max` is a local guideline lookup, not web component mining. Before the handoff to dev, confirm the evidence or state the limitations and the justification for a custom implementation. Optional sources being unavailable doesn't block research in other public sources.
+**Research gate:** for a non-trivial component/effect, research runs against the project's research map (`design-state.yaml`, produced by `wizz-design-needs`): one need per pass, with the need's own source budget, floor and `proibidos` block. Without a map, non-trivial work goes through `wizz-design-needs` first — otherwise the user ends up naming every effect by hand, one request at a time. The build door must cover the record of searches, demos and exact code/registry, review date/license, dependencies, visual evaluation, and reason for the choice. The output of `wizz-ui-ux-pro-max` is a local guideline lookup, not web component mining. Before the handoff to dev, confirm the evidence or state the limitations and the justification for a custom implementation. Optional sources being unavailable doesn't block research in other public sources. A generic design skill from outside the registry (e.g. the frontend-design plugin) can add taste, never replace this gate. When the work goes to a `wizz-exec-*` subagent, the brief names the door, the map path and the need ids: the subagent does not inherit this gate on its own.
 
 ## Closing
 Close in the Wizz format: `✅ O que fiz` (simple sentences) / `➡️ Próximo passo` (usually wizz-agent-dev or wizz-quick-dev to build) / `🎯 Comando`.

package/src/modules/wizz/agents/wizz-maestro/SKILL.md

@@ -101,7 +101,7 @@ In short: **the menu chooses the agent, the registry chooses the skill(s) and th
 
 Inside the 1-area branch, three shortcuts **demote on their own**, before counting any factor: a **question with a single definable answer**, a **single delivery**, and the **diagnosis of one specific mechanism** all go to the area agent. "How do I improve / reduce X" is not that question — it has no single answer. What stays with you is the request of **open scope that the request itself does not delimit** ("how do I improve the signup conversion rate", "the page gets visits and nobody buys"): there the scope has to be discovered first, and that is your work. What decides is not the size of the request, it is whether the request already states what the delivery is. **Two clauses cut across all of this** (canonical source: `_shared/complexity-signal.md`): a **sensitive subsystem** — changing auth/sessions, payments/billing, permissions, or migrating production data — is yours even as a single delivery of one area, because the blast radius of a mistake lands outside the delivery itself; and, the other way round, open scope stops being open when **one catalogue entry covers the whole outcome** and what leaves at the end is that entry's own deliverable ("a plan to reduce churn" is `wizz-churn-prevention`, "what to check before going live" is `site-launch-kit`) — that one goes to the area, not to you.
 
-**Changing the product's code is `dev`, even when the subject is visual** — the delivery is a commit. Ask which artifact leaves at the end: a file in the repo → dev; a decision, a spec or a piece of art → the area that owns it.
+**Changing the product's code is `dev`, even when the subject is visual** — the delivery is a commit. Ask which artifact leaves at the end: a file in the repo → dev; a decision, a spec or a piece of art → the area that owns it. **Exception: new or rebuilt screens.** When the request asks to BUILD screens in code (a new app, page, dashboard or panel, or a whole screen rebuilt in the product), the visual decision has not been made yet, so `designer` comes first and the sequence is design → dev: the designer runs its research gate (`wizz-design-needs` → `wizz-ui-component-curator` / `wizz-premium-landing-ui-researcher`) before any screen is coded. A generic design skill from outside the registry (e.g. the frontend-design plugin) never stands in for that gate. A tweak to an existing screen (a price, a label, a spacing) stays dev, and redesigning a section with no build asked for (a hero, a card) stays designer.
 
 **What `rel` drags counts as an extra area when the related capability shapes the SAME deliverable.** Ask of each edge: would the thing being handed over be incomplete without this? A sales page without the offer and the conversion structure is half a page (same artifact → escalates); a text post does not become a video job because of a `before: [get-brolls]` edge (different artifact → does not). `pairs_with` alone never escalates.
 

package/src/skills-lib/_shared/complexity-signal.md

@@ -36,7 +36,7 @@ Written as bare labels, the 3 factors above were true of almost any request, and
 
 **And the counterpart has one exception: a single entry already delimits the scope.** If the whole outcome being asked for fits the `when:` of ONE catalogue entry, and what leaves at the end is that entry's own deliverable — a plan, a recommendation, an audit — then the scope is not open, the catalogue delimited it, and the request goes to that entry's area. "A plan to reduce churn" is `wizz-churn-prevention`; "I want ChatGPT and Perplexity to cite us" is `wizz-ai-seo`; "what to check before going live" is `site-launch-kit`. It stops being the exception the moment delivering the outcome means changing what other areas own: "improve the signup conversion rate" ends up in copy, UI and code, so it comes back to the maestro through the area clause. Ask which single entry would deliver it whole — if it takes two, the scope really is open. (Owner's decision, 2026-09-18.)
 
-**Changing the product's code is `dev`, even when the subject is visual.** "Adjust the secondary button's colour", "fix the mobile spacing": the delivery is a commit, so it is the dev area — `designer` decides what the look should be, it does not ship the change. Ask which artifact leaves at the end: a file in the repo → dev; a decision, a spec or a piece of art → the area that owns it.
+**Changing the product's code is `dev`, even when the subject is visual.** "Adjust the secondary button's colour", "fix the mobile spacing": the delivery is a commit, so it is the dev area — `designer` decides what the look should be, it does not ship the change. Ask which artifact leaves at the end: a file in the repo → dev; a decision, a spec or a piece of art → the area that owns it. **Exception: new or rebuilt screens.** When the request asks to BUILD screens in code (a new app, page, dashboard or panel, or a whole screen rebuilt in the product), the visual decision has not been made yet, so `designer` comes first and the sequence is design → dev (2 areas → maestro): the designer runs its research gate before any screen is coded. A tweak to an existing screen (a price, a label, a spacing) stays dev, and redesigning a section with no build asked for (a hero, a card) stays designer.
 
 **What `rel` drags counts as an extra area when the related capability shapes the SAME deliverable.** Writing the copy of a sales page without the offer and without the conversion structure delivers half a page: offer, copy and conversion are the same artifact, so that is 2 areas → maestro. What does NOT count is an adjacent capability that would produce a **different** artifact: a plain text post for LinkedIn does not need video capture just because the social content skill declares `before: [get-brolls]` — the b-roll would be another deliverable, not part of this one. `pairs_with` alone never escalates: it is neighbourhood, not dependency. The question to ask about each edge is "would the thing I am about to hand over be incomplete without this?", not "is this related?".
 

package/src/skills-lib/wizz-design-needs/SKILL.md

@@ -25,7 +25,7 @@ Output: a `needs` block in `design-state.yaml`. Nothing else. This skill never o
 3. **Decompose.** Surfaces → sections → components → behaviours. Procedure in [decomposicao](references/decomposicao.md).
 4. **Derive the needs** with the four rules and the signal table in [derivacao](references/derivacao.md). This is where needs are both created and forbidden.
 5. **Run the gap analysis** ([gap-analysis](references/gap-analysis.md)): project inventory → local cache → needs already satisfied on another surface. What survives gets a query, a source budget and a floor. What does not survive is closed with `status: dropped` and a reason.
-6. **Write `design-state.yaml`** in the shape of [design-state](references/design-state.md), and hand off.
+6. **Write `design-state.yaml`** in the shape of [design-state](references/design-state.md), always at `{output_folder}/design-state.yaml`, and hand off. A brief that restricts writes to another folder (e.g. "only write in `_design/`") governs deliverables, not the map: the miners look for the map in `{output_folder}`.
 
 ## Output format
 

package/src/skills-lib/wizz-premium-landing-ui-researcher/SKILL.md

@@ -9,7 +9,7 @@ Autonomous strategist for premium landing pages, SaaS UI, and advanced visual ex
 
 ## Gate 0: the research map (always, before Gate 1)
 
-Check for `{output_folder}/design-state.yaml` (default `_wizz-output/`). Cheap check first: `grep -c 'status: open'`.
+Check for `{output_folder}/design-state.yaml` (default `_wizz-output/`). Cheap check first: `grep -c 'status: open'`. Not there? Run `find . -name design-state.yaml -not -path '*/node_modules/*'` before concluding it does not exist: a map found elsewhere is still the map, so use it and tell the user it is off-place.
 
 - **It exists, with open needs:** you are not deciding what to research. Work **one need per pass**, in the order given, and take `query`, `budget.fontes` and `floor` as given. Read the `proibidos` block before writing any query: a query that lands on a forbidden capability is not run, not even for comparison. Write each finding back under `discoveries` with the `need` id, and move the need to `selected` or `unmet` with a reason. Stop when the needs are exhausted, not when the ideas are.
 - **It exists, no open needs:** the map is done. Do not open new research on your own: report it and hand back to `wizz-design-needs` if something is genuinely missing.

package/src/skills-lib/wizz-router/SKILL.md

@@ -74,7 +74,7 @@ This gate does NOT fire for an open-scope request. "My site is bad, sort it out"
 
 **And the counterpart has one exception: a single entry already delimits the scope.** If the whole outcome being asked for fits the `when:` of ONE catalogue entry, and what leaves at the end is that entry's own deliverable — a plan, a recommendation, an audit — then the scope is not open, the catalogue delimited it, and the request goes to that entry's area. "A plan to reduce churn" is `wizz-churn-prevention`; "I want ChatGPT and Perplexity to cite us" is `wizz-ai-seo`; "what to check before going live" is `site-launch-kit`. It stops being the exception the moment delivering the outcome means changing what other areas own: "improve the signup conversion rate" ends up in copy, UI and code, so it comes back to the maestro through the area clause. Ask which single entry would deliver it whole — if it takes two, the scope really is open. (Owner's decision, 2026-09-18.)
 
-**Changing the product's code is `dev`, even when the subject is visual.** "Adjust the secondary button's colour", "fix the mobile spacing": the delivery is a commit, so it is the dev area — `designer` decides what the look should be, it does not ship the change. Ask which artifact leaves at the end: a file in the repo → dev; a decision, a spec or a piece of art → the area that owns it.
+**Changing the product's code is `dev`, even when the subject is visual.** "Adjust the secondary button's colour", "fix the mobile spacing": the delivery is a commit, so it is the dev area — `designer` decides what the look should be, it does not ship the change. Ask which artifact leaves at the end: a file in the repo → dev; a decision, a spec or a piece of art → the area that owns it. **Exception: new or rebuilt screens.** When the request asks to BUILD screens in code (a new app, page, dashboard or panel, or a whole screen rebuilt in the product), the visual decision has not been made yet, so `designer` comes first and the sequence is design → dev (2 areas → maestro): the designer runs its research gate before any screen is coded. A tweak to an existing screen (a price, a label, a spacing) stays dev, and redesigning a section with no build asked for (a hero, a card) stays designer.
 
 **The area count includes what `rel` drags, when the related capability shapes the SAME deliverable.** Before deciding "1 area", look at the `rel` of the entry that matched, and ask of each edge: **would the thing I am about to hand over be incomplete without this?** — not "is this related?". Writing the copy of a sales page without the offer and without the conversion structure delivers half a page: offer, copy and conversion are the same artifact, so that is 2 areas, hence maestro. What does NOT count is an adjacent capability that would produce a **different** artifact: a plain text post for LinkedIn does not need video capture just because `wizz-social-content` declares `before: [get-brolls]` — the b-roll would be another deliverable, not part of this one. `pairs_with` alone never escalates: it is neighbourhood, not dependency. Every edge is reciprocal by construction (the schema validator rejects one-way edges), so the relation shows up whichever side the user enters from. Resolve id → area via the `ids:` map in `{project-root}/_wizz/_config/registry/index.yaml`; outside a Wizz project, via `skills-registry.yaml` itself.
 

package/src/skills-lib/wizz-ui-component-curator/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: wizz-ui-component-curator
-description: analyze an existing frontend project, infer its visual style and product tone, then research and recommend compatible UI components and effects from public component catalogs, registries and source repositories. use when the user wants help choosing components, effects, sections, or visual patterns that fit an existing project — especially hero effects, cards, buttons, testimonials, pricing sections, navigation, or any interactive pattern. trigger whenever the user wants to add a UI element and wants Claude to study the project first before suggesting options. always inspect the codebase and exact component sources, provide evidence and plan before editing.
+description: analyze an existing frontend project, infer its visual style and product tone, then research and recommend compatible UI components and effects from public component catalogs, registries and source repositories. use when the user wants help choosing components, effects, sections, or visual patterns that fit an existing project or dashboard — especially hero effects, cards, buttons, hovers, loading animations, testimonials, pricing sections, navigation, or any interactive pattern. trigger whenever the user wants to add a UI element and wants Claude to study the project first before suggesting options. always inspect the codebase and exact component sources, provide evidence and plan before editing.
 ---
 
 # Overview
@@ -19,6 +19,8 @@ Act as a UI curator with taste and restraint — not a gallery explorer. Optimiz
 
 If `{output_folder}/design-state.yaml` exists, the need being worked is already written there: take its `query`, `budget.fontes` and `floor` instead of improvising them, honour the `proibidos` block, and write the result back under `discoveries` with the `need` id. If the request does not match any open need, say so before researching: an unplanned need is either a gap in the map (go back to `wizz-design-needs`) or scope creep.
 
+Not there? Look before deciding it does not exist: `find . -name design-state.yaml -not -path '*/node_modules/*'`. A map found anywhere else is still the map: use it, and tell the user it is off-place (it belongs in `{output_folder}`).
+
 With no state file, continue normally.
 
 ## 1. Read and infer the style DNA
@@ -38,7 +40,9 @@ Do not ask the user to describe the style unless the project has no inspectable
 
 ## 2. Search and inspect public sources
 
-Start with existing project components. Then search appropriate public sources: [React Bits](https://reactbits.dev/), [Cult UI](https://www.cult-ui.com/docs), [Componentry](https://componentry.dev/), or [shadcn/ui](https://ui.shadcn.com/docs). Compare at least two suitable sources when available.
+Start with existing project components. Then search the public sources. The full authorized list (React Bits, Cult UI, Ali Imam, Watermelon, StyleUI, Skiper UI, Bklit UI, Componentry, shadcn/ui, plus the reference galleries) lives in one place: [component-sources](../wizz-premium-landing-ui-researcher/references/component-sources.md). Read it instead of relying on memory. Compare at least two suitable sources per need.
+
+Use whatever search tools the session has: web search (Exa when configured, WebSearch otherwise), WebFetch, scrapling, and `agent-browser` to watch hover and motion live. A tool that errors or hangs is not the end of the research: record the failure, move to the next tool, and never stop without reporting what was and was not checked.
 
 Open the exact demo and source file/registry item. Check the actual imports, license, dependencies, stack variant and revision; use current official documentation (Context7 when available) for API compatibility. Inspect animation/interaction in the available browser; label static-only inspection honestly. If a source fails, record the failure and continue elsewhere.
 
@@ -68,6 +72,22 @@ Send the exact candidate links and recommendation. If the user authorized implem
 
 ---
 
+## Dashboard and app panels
+
+A panel is used every day, so the bar is different from a landing page: motion that delights once tires on the tenth visit. When the project is a dashboard, admin or operational panel, cover these categories (only the ones the request or the map opens):
+
+- loading: skeleton, spinner, route progress, branded loader
+- action feedback: toast, confirmation, undo, a discreet success state
+- numbers: animated counter, sparkline, gauge, KPI card
+- lists and queues: enter/exit animation, swipe actions on mobile
+- navigation: sidebar, command menu, tooltip, dock
+- surfaces: hover states, border glow, spotlight, subtle background
+- empty states, charts and form controls
+
+For each candidate, judge "does it tire with daily use", reduced-motion support and weight. Reject landing-page effects that do not serve a task.
+
+---
+
 # Consistency rules
 
 If there is tension between the most impressive option and the best-fitting option: **choose the one that fits.**