wizz-method 1.16.0 → 1.17.0

package/src/skills-lib/launch-readiness/references/07-infra-deploy-rollback.md

@@ -0,0 +1,26 @@
+# Área 07 · Infra / Deploy / Rollback
+
+Checa se, quando (não "se") algo der errado no dia do lançamento, o time consegue reverter ou recuperar rápido. Ausência de plano de rollback é o achado mais caro desta área: um bug em produção sem caminho de volta vira incidente longo.
+
+## Checagens objetivas
+
+1. **Pipeline de deploy existe e é repetível.** Deploy manual/artesanal sem script/CI para o ambiente de produção é 🟠.
+2. **Rollback possível e testado.** Sem nenhuma forma de voltar pra versão anterior (revert de deploy, versionamento de release, feature flag) é 🔴 pra lançamento de risco alto (migração de banco, troca de fluxo de pagamento); 🟠 nos demais casos.
+3. **Migração de banco reversível.** Migration que altera/apaga coluna sem plano de reversão, rodando junto do lançamento, é 🔴.
+4. **Backup recente e testado.** Sem backup do banco de produção, ou backup nunca restaurado uma vez sequer pra validar que funciona, é 🔴 quando há dado de usuário real em jogo.
+5. **Domínio/DNS/SSL apontando pro ambiente certo.** Confirma o achado #7 da área 03 pelo lado de infra: domínio configurado mas TTL alto sem plano de propagação a tempo do lançamento é 🟠.
+6. **Paridade de ambiente (staging vs. produção).** Diferença conhecida entre o que foi testado em staging e o que vai pra produção (env var, versão de dependência, feature flag) é 🟠.
+7. **Plano de quem responde no dia.** Sem ninguém definido pra monitorar/responder no horário do lançamento (mesmo que informal) é 🟡; sobe pra 🟠 se o lançamento é fora do horário comercial normal do time.
+8. **Rate limiting / proteção contra pico na camada de infra.** Ausência de qualquer proteção (CDN, rate limit de borda) num lançamento com pico de tráfego esperado (campanha paga, imprensa) é 🟠.
+
+## Regra de corte
+
+"Rollback existe" só conta se alguém já testou o caminho de volta pelo menos uma vez, não só "em teoria dá pra reverter". Sem essa confirmação, marque PENDÊNCIA DE VERIFICAÇÃO em vez de 🟢.
+
+## Formato de saída
+
+```
+| # | Item | Onde (arquivo/rota) | O que falta ou está errado | Severidade | Executor da correção |
+```
+
+Sem achado que passe na régua: responda só `NENHUM ACHADO NESTA ÁREA`.

package/src/skills-lib/launch-readiness/references/08-fusao-priorizacao.md

@@ -0,0 +1,33 @@
+# Passo 08 · Fusão e Priorização
+
+Recebe as 7 tabelas das áreas (01 a 07) e funde num diagnóstico único. Não é uma nova rodada de investigação: é organização do que já foi levantado.
+
+## Como fundir
+
+1. **Cole as 7 tabelas** (ou as que rodaram, se alguma foi marcada `ITEM NÃO SE APLICA`).
+2. **Dedup por origem cruzada.** O mesmo problema pode aparecer em duas áreas (ex.: domínio apontando pro ambiente errado aparece na área 03 e na área 07). Mantenha uma linha só, citando as duas áreas de origem.
+3. **Ordene por severidade primeiro** (🔴 no topo, 🟢 no fim), e dentro da mesma severidade, pelo esforço estimado de correção (menor esforço primeiro): resolve mais rápido o que está mais perto do go-live.
+4. **Agrupe por executor.** Vários achados 🔴 que vão pro mesmo executor (ex.: 3 achados de `site-launch-kit`) formam um bloco só na entrega, pra virar um único despacho.
+5. **Conte pendências separadamente.** PENDÊNCIA DE VERIFICAÇÃO MANUAL não é severidade: é "não dá pra saber ainda". Liste à parte, com o que falta pra virar um veredito real.
+
+## Tabela final
+
+```
+| # | Área | Item | Severidade | Executor | Esforço estimado |
+```
+
+Seguida de:
+
+**Bloqueantes de hoje (🔴):** lista curta, só o que impede literalmente o go-live. Se a lista tiver mais de 5 itens, isso já é sinal pro dono do projeto de que o lançamento provavelmente precisa adiar, diga isso explicitamente.
+
+**Recomendação:** uma de três, nunca decidida pela skill sozinha, é leitura dos números:
+
+- **GO:** zero 🔴, poucos 🟠 documentados como aceitáveis pelo dono do projeto.
+- **GO COM RESSALVAS:** 🔴 zero, mas 🟠 relevante o suficiente pra avisar explicitamente antes do dono decidir.
+- **NO-GO:** qualquer 🔴 aberto.
+
+A recomendação é uma leitura objetiva da tabela (contagem de severidade), não um palpite. Explique o critério usado (ex.: "NO-GO porque há 2 achados 🔴 abertos: X e Y") em vez de só declarar o rótulo.
+
+## Regra de corte
+
+Não amenize a contagem pra chegar num "GO" mais confortável. Se há 🔴 aberto, a recomendação é NO-GO, mesmo que o prazo de lançamento esteja apertado: apertar o prazo é decisão do dono do projeto, não da skill.

package/src/skills-lib/launch-readiness/references/09-persistencia-project-context.md

@@ -0,0 +1,48 @@
+# Passo 09 · Persistência no project-context.md
+
+O resultado da auditoria não fica só na conversa: um resumo persiste no `project-context.md` do projeto, pra qualquer agente (ou humano) que abrir o projeto depois saber, sem re-perguntar, se ele já passou por uma auditoria de lançamento e como ficou.
+
+## Localizar o arquivo
+
+Mesmo padrão fail-open usado pelo router e pelo maestro: `grep -m1 '^stage:' {project-root}/**/project-context.md`.
+
+- **Achou o arquivo:** siga pra "Gravar a seção" abaixo.
+- **Não achou:** não bloqueie a entrega do diagnóstico por causa disso. Avise que não existe `project-context.md` pra persistir o resultado, ofereça rodar `wizz-generate-project-context` primeiro (cria o arquivo e o campo `stage:`), e entregue o diagnóstico normalmente mesmo sem persistir.
+
+## Gravar a seção
+
+A seção vive sob o cabeçalho `## Auditoria de Prontidão pra Lançamento`. Ela é SUBSTITUÍDA a cada nova rodada, não é um changelog acumulado: `project-context.md` existe pra ficar enxuto ("lean, LLM-optimized" é o objetivo declarado do próprio template), então o que importa pra um agente lendo depois é o estado ATUAL, não o histórico de rodadas antigas. Se encontrar uma seção com esse cabeçalho já existente, apague o conteúdo antigo e escreva o novo no lugar; não acumule.
+
+Template exato da seção:
+
+```markdown
+## Auditoria de Prontidão pra Lançamento
+
+Última rodada: {{YYYY-MM-DD}}. Resultado da skill `launch-readiness`; substitui a rodada anterior (não é histórico).
+
+**Resumo:** 🔴 {{n_bloqueante}} bloqueante(s) · 🟠 {{n_alto}} alto(s) · 🟡 {{n_medio}} médio(s) · 🟢 {{n_ok}} ok
+
+**Recomendação:** {{GO | GO COM RESSALVAS | NO-GO}}
+
+**Bloqueantes abertos (🔴):**
+- {{item 1, uma linha}}
+- {{item 2, uma linha}}
+
+_Sem bloqueante aberto, escreva "Nenhum bloqueante aberto." em vez da lista._
+
+**Diagnóstico completo** (as 7 tabelas por área) foi entregue na sessão de {{YYYY-MM-DD}}; esta seção é o resumo persistido, não a íntegra.
+```
+
+Insira a seção depois de `## Estado do Projeto` e antes de `## Technology Stack & Versions`, seguindo a ordem já usada pelo template (`project-context-template.md`). Se o arquivo tiver uma ordem diferente por já ter sido editado à mão, insira logo após `## Estado do Projeto`.
+
+## Atualizar o estágio (stage:)
+
+O campo `stage:` no frontmatter (`prototype|mvp|production|maintenance`) reflete o momento real do projeto, e a auditoria pode revelar que ele está desatualizado:
+
+- **Recomendação GO ou GO COM RESSALVAS, e o usuário confirma que vai lançar agora:** proponha atualizar `stage: mvp` → `stage: production` no frontmatter. Proponha, não edite sozinho: pergunte antes ("atualizo o stage do projeto pra `production`?"), porque esse campo direciona o comportamento de outros agentes (router, maestro) e mudar sem avisar é uma mutação silenciosa de configuração compartilhada.
+- **Recomendação NO-GO:** não sugira mudar o `stage:`. O projeto continua no estágio que já estava.
+- **Estágio já é `production`:** não mexa; a auditoria está sendo usada pra uma nova leva/feature, não pra estreia do projeto (ver gate de estágio no `SKILL.md`).
+
+## Regra de corte
+
+Não grave a seção com números inventados. O resumo tem que bater exatamente com a tabela final do passo 08 (fusão): mesma contagem, mesma recomendação. Se o passo 08 não rodou (ex.: usuário pediu só uma área isolada), não grave a seção completa: registre só o achado daquela área com a mesma data, deixando claro que não é uma rodada completa das 7 áreas.

package/src/skills-lib/site-launch-kit/SKILL.md

@@ -46,7 +46,7 @@ description: "Checklist operacional de pré-lançamento de site em 15 rodadas co
 
 ## O que esta skill NÃO faz
 
-- Não redesenha layout, paleta ou conteúdo de seções (use `taste-redesign` / `impeccable`).
+- Não redesenha layout, paleta ou conteúdo de seções (use `taste-skill` / `impeccable`).
 - Não cria a página do zero (use `premium-landing-ui-researcher`).
 - Não faz diagnóstico amplo de ranking/tráfego (use `seo-audit`).
 - Não escreve copy de venda nova (use `copywriting`); aqui só se ajusta rótulo e microcopy de atrito com material que já existe no site.

package/src/skills-lib/taste-skill/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: taste-skill
-description: Anti-slop frontend skill for landing pages, portfolios, and redesigns. The agent reads the brief, infers the right design direction, and ships interfaces that do not look templated. Real design systems when applicable, audit-first on redesigns, strict pre-flight check. Use when building or redesigning a landing page, portfolio, or marketing site that must not look AI-generated. Detailed rules live in references/, loaded on demand.
+description: Anti-slop frontend skill for landing pages, portfolios, and redesigns or audits of existing sites and apps. The agent reads the brief, infers the right design direction, and ships interfaces that do not look templated. On an existing project it audits the current design first, identifies generic AI patterns, lists every problem found, and prioritizes fixes without breaking functionality, working with any CSS framework or vanilla CSS. Real design systems when applicable, audit-first on redesigns, strict pre-flight check. Use when building, redesigning, or auditing a landing page, portfolio, or marketing site, or when upgrading an existing site or app that looks generic or AI-generated. Detailed rules live in references/, loaded on demand.
 ---
 
 # tasteskill: Anti-Slop Frontend Skill
@@ -14,7 +14,7 @@ This file is the index. The full rulebook is split into `references/*.md`, one f
 
 1. **Read the brief, not your defaults.** Infer page kind, vibe, audience, constraints. Output a one-line "Design Read" before any code. If genuinely ambiguous, ask exactly one question.
 2. **Set the three dials** (`DESIGN_VARIANCE / MOTION_INTENSITY / VISUAL_DENSITY`, baseline `8 / 6 / 4`) from the design read. Steps 1-2 protocol and tables: [brief-and-dials](references/brief-and-dials.md).
-3. **Redesign?** Detect the mode first (preserve vs overhaul) and audit before touching anything: [redesign-protocol](references/redesign-protocol.md).
+3. **Redesign or audit of an existing project?** Detect the mode first (preserve vs overhaul) and audit before touching anything: [redesign-protocol](references/redesign-protocol.md) for mode detection and preservation rules, [design-audit](references/design-audit.md) for the full audit checklist, and [upgrade-techniques](references/upgrade-techniques.md) for the fix techniques once the audit is done.
 4. **Pick the foundation.** Real design system (official package) vs honest aesthetic build: [design-systems](references/design-systems.md).
 5. **Build with the default stack and conventions** ([architecture-conventions](references/architecture-conventions.md)) and apply the bias-correction directives for typography, color, layout, images, copy ([design-directives](references/design-directives.md)).
 6. **Add motion only when motivated:** [motion-patterns](references/motion-patterns.md).
@@ -44,6 +44,8 @@ These apply to every task, no exceptions, before reading anything else:
 | [anti-slop-tells.md](references/anti-slop-tells.md) | Forbidden AI-tell patterns, production-test tells, em-dash ban | 9 |
 | [pattern-vocabulary.md](references/pattern-vocabulary.md) | Named patterns: heroes, nav, grids, cards, scroll, text, libraries | 10 |
 | [redesign-protocol.md](references/redesign-protocol.md) | Mode detection, audit-first, preservation, modernisation levers | 11 |
+| [design-audit.md](references/design-audit.md) | Full audit checklist for existing projects: typography, color, layout, interactivity, content, components, iconography, code quality, strategic omissions | 11.G |
+| [upgrade-techniques.md](references/upgrade-techniques.md) | High-impact fix techniques for redesigns: typography, layout, motion, surface upgrades | 11.H |
 | [block-library.md](references/block-library.md) | Block Library contract and file schema | 12 |
 | [preflight-checklist.md](references/preflight-checklist.md) | Final pre-flight check matrix (mandatory gate) | 14 |
 

package/src/skills-lib/{taste-redesign → taste-skill}/references/design-audit.md

@@ -1,74 +1,64 @@
-# Design audit — full checklist
+> taste-skill reference file. Loaded on demand from the SKILL.md index.
+> Cross-references like "Section N" map to sibling files via the index table in ../SKILL.md.
 
-Load this file during the Diagnose step. Full audit checklist across 9 categories — Typography, Color and Surfaces, Layout, Interactivity and States, Content, Component Patterns, Iconography, Code Quality, Strategic Omissions (what AI typically forgets) — each with the generic pattern to spot and the fix.
+## 11.G REDESIGN AUDIT CHECKLIST (detail)
 
-## Design Audit
+Full checklist for the Audit Before Touching step (Section 11.B). Scan the project against every category below and list every match found, feeding the "Patterns to retire" list in 11.B. Where a finding is already governed by an always-on directive elsewhere in this skill, the item below points to that section instead of repeating the fix, so there is one source of truth for the actual rule.
 
 ### Typography
 
-Check for these problems and fix them:
-
-- **Browser default fonts or Inter everywhere.** Replace with a font that has character. Good options: `Geist`, `Outfit`, `Cabinet Grotesk`, `Satoshi`. For editorial/creative projects, pair a serif header with a sans-serif body.
+- **Browser default fonts or Inter everywhere.** Replace per the approved font list and pairings in Section 4.1.
 - **Headlines lack presence.** Increase size for display text, tighten letter-spacing, reduce line-height. Headlines should feel heavy and intentional.
-- **Body text too wide.** Limit paragraph width to roughly 65 characters. Increase line-height for readability.
+- **Body text too wide.** Cap paragraph width per Section 4.1 (`max-w-[65ch]`) and increase line-height for readability.
 - **Only Regular (400) and Bold (700) weights used.** Introduce Medium (500) and SemiBold (600) for more subtle hierarchy.
 - **Numbers in proportional font.** Use a monospace font or enable tabular figures (`font-variant-numeric: tabular-nums`) for data-heavy interfaces.
 - **Missing letter-spacing adjustments.** Use negative tracking for large headers, positive tracking for small caps or labels.
-- **All-caps subheaders everywhere.** Try lowercase italics, sentence case, or small-caps instead.
+- **All-caps subheaders everywhere.** Try lowercase italics, sentence case, or small-caps instead. (Distinct from the eyebrow-frequency rule in Section 4.7: this is about styling, that is about how often an eyebrow appears at all.)
 - **Orphaned words.** Single words sitting alone on the last line. Fix with `text-wrap: balance` or `text-wrap: pretty`.
 
 ### Color and Surfaces
 
-- **Pure `#000000` background.** Replace with off-black, dark charcoal, or tinted dark (`#0a0a0a`, `#121212`, or a dark navy).
-- **Oversaturated accent colors.** Keep saturation below 80%. Desaturate accents so they blend with neutrals instead of screaming.
-- **More than one accent color.** Pick one. Remove the rest. Consistency beats variety.
-- **Mixing warm and cool grays.** Stick to one gray family. Tint all grays with a consistent hue (warm or cool, not both).
-- **Purple/blue "AI gradient" aesthetic.** This is the most common AI design fingerprint. Replace with neutral bases and a single, considered accent.
-- **Generic `box-shadow`.** Tint shadows to match the background hue. Use colored shadows (e.g., dark blue shadow on a blue background) instead of pure black at low opacity.
-- **Flat design with zero texture.** Add subtle noise, grain, or micro-patterns to backgrounds. Pure flat vectors feel sterile.
+- **Pure `#000000` background or oversaturated / multi-accent colors.** Governed by the Lila Rule and saturation cap in Section 4.2, and the Section 9.A bans. Flag any instance found on the existing site.
+- **Mixing warm and cool grays.** Governed by Section 4.2 ("one palette per project"). Flag any inconsistency found.
+- **Generic `box-shadow`.** Governed by Section 4.4 (tint shadows to the background hue). Flag any pure-black, untinted shadow found.
+- **Flat design with zero texture.** Add subtle noise, grain, or micro-patterns to backgrounds to break digital flatness. Apply per the DOM-cost rule in Section 6.E (fixed, `pointer-events-none` layer only, never on scrolling containers).
 - **Perfectly even gradients.** Break the uniformity with radial gradients, noise overlays, or mesh gradients instead of standard linear 45-degree fades.
 - **Inconsistent lighting direction.** Audit all shadows to ensure they suggest a single, consistent light source.
-- **Random dark sections in a light mode page (or vice versa).** A single dark-background section breaking an otherwise light page looks like a copy-paste accident. Either commit to a full dark mode or keep a consistent background tone throughout. If contrast is needed, use a slightly darker shade of the same palette — not a sudden jump to `#111` in the middle of a cream page.
-- **Empty, flat sections with no visual depth.** Sections that are just text on a plain background feel unfinished. Add high-quality background imagery (blurred, overlaid, or masked), subtle patterns, or ambient gradients. Use reliable placeholder sources like `https://picsum.photos/seed/{name}/1920/1080` when real assets are not available. Experiment with background images behind hero sections, feature blocks, or CTAs — even a subtle full-width photo at low opacity adds presence.
+- **Random dark section in an otherwise light page (or vice versa).** Governed by the Page Theme Lock in Section 4.11. Flag it as a redesign finding; fix by committing to one theme for the whole page.
+- **Empty, flat sections with no visual depth.** Sections that are just text on a plain background feel unfinished. Add background imagery, a pattern, or an ambient gradient, sourced per the priority order in Section 4.8.
 
 ### Layout
 
-- **Everything centered and symmetrical.** Break symmetry with offset margins, mixed aspect ratios, or left-aligned headers over centered content.
-- **Three equal card columns as feature row.** This is the most generic AI layout. Replace with a 2-column zig-zag, asymmetric grid, horizontal scroll, or masonry layout.
-- **Using `height: 100vh` for full-screen sections.** Replace with `min-height: 100dvh` to prevent layout jumping on mobile browsers (iOS Safari viewport bug).
+- **Everything centered and symmetrical.** Governed by the anti-center-bias rule in Section 4.3. Flag it as a finding on redesigns; the override there still applies for editorial/manifesto briefs.
+- **Three equal card columns as a feature row.** Banned outright per Section 9.C. Replace with a 2-column zig-zag, asymmetric grid, or horizontal scroll.
+- **Using `height: 100vh` for full-screen sections.** Replace with `min-height: 100dvh` to prevent layout jumping on mobile browsers (iOS Safari viewport bug). See the viewport-stability check in the pre-flight matrix (Section 14).
 - **Complex flexbox percentage math.** Replace with CSS Grid for reliable multi-column structures.
-- **No max-width container.** Add a container constraint (around 1200-1440px) with auto margins so content doesn't stretch edge-to-edge on wide screens.
+- **No max-width container.** Add a container constraint (around 1200-1440px) with auto margins so content does not stretch edge-to-edge on wide screens.
 - **Cards of equal height forced by flexbox.** Allow variable heights or use masonry when content varies in length.
-- **Uniform border-radius on everything.** Vary the radius: tighter on inner elements, softer on containers.
+- **Uniform border-radius on everything, with no documented rule.** Section 4.4's Shape Consistency Lock allows variation only when there is a documented rule (e.g. "buttons full-pill, cards 16px, inputs 8px") followed everywhere. An existing site with radius applied at random, with no rule at all, is the audit finding here.
 - **No overlap or depth.** Elements sit flat next to each other. Use negative margins to create layering and visual depth.
-- **Symmetrical vertical padding.** Top and bottom padding are always identical. Adjust optically — bottom padding often needs to be slightly larger.
+- **Symmetrical vertical padding.** Top and bottom padding are always identical. Adjust optically; bottom padding often needs to be slightly larger.
 - **Dashboard always has a left sidebar.** Try top navigation, a floating command menu, or a collapsible panel instead.
 - **Missing whitespace.** Double the spacing. Let the design breathe. Dense layouts work for data dashboards, not for marketing pages.
 - **Buttons not bottom-aligned in card groups.** When cards have different content lengths, CTAs end up at random heights. Pin buttons to the bottom of each card so they form a clean horizontal line regardless of content above.
 - **Feature lists starting at different vertical positions.** In pricing tables or comparison cards, the list of features should start at the same Y position across all columns. Use consistent spacing above the list or fixed-height title/price blocks.
 - **Inconsistent vertical rhythm in side-by-side elements.** When placing cards, columns, or panels next to each other, align shared elements (titles, descriptions, prices, buttons) across all items. Misaligned baselines make the layout look broken.
-- **Mathematical alignment that looks optically wrong.** Centering by the math doesn't always look centered to the eye. Icons next to text, play buttons in circles, or text in buttons often need 1-2px optical adjustments to feel right.
+- **Mathematical alignment that looks optically wrong.** Centering by the math does not always look centered to the eye. Icons next to text, play buttons in circles, or text in buttons often need 1-2px optical adjustments to feel right.
 
 ### Interactivity and States
 
-- **No hover states on buttons.** Add background shift, slight scale, or translate on hover.
-- **No active/pressed feedback.** Add a subtle `scale(0.98)` or `translateY(1px)` on press to simulate a physical click.
+- **No hover states, no active/pressed feedback, no loading or empty states.** Governed by Section 4.5 (Interactive UI States: skeletal loaders, composed empty states, `-translate-y-[1px]` / `scale-[0.98]` on press). Flag every missing state found on the existing site as a redesign fix.
+- **No error states, or errors handled with `window.alert()`.** Add clear, inline error messages for forms per Section 4.5. `window.alert()` specifically is banned; it is a jarring, unstyled browser dialog.
 - **Instant transitions with zero duration.** Add smooth transitions (200-300ms) to all interactive elements.
 - **Missing focus ring.** Ensure visible focus indicators for keyboard navigation. This is an accessibility requirement, not optional.
-- **No loading states.** Replace generic circular spinners with skeleton loaders that match the layout shape.
-- **No empty states.** An empty dashboard showing nothing is a missed opportunity. Design a composed "getting started" view.
-- **No error states.** Add clear, inline error messages for forms. Do not use `window.alert()`.
 - **Dead links.** Buttons that link to `#`. Either link to real destinations or visually disable them.
 - **No indication of current page in navigation.** Style the active nav link differently so users know where they are.
 - **Scroll jumping.** Anchor clicks jump instantly. Add `scroll-behavior: smooth`.
-- **Animations using `top`, `left`, `width`, `height`.** Switch to `transform` and `opacity` for GPU-accelerated, smooth animation.
+- **Animations using `top`, `left`, `width`, `height`.** Governed by Section 6.A: animate only `transform` and `opacity`.
 
 ### Content
 
-- **Generic names like "John Doe" or "Jane Smith".** Use diverse, realistic-sounding names.
-- **Fake round numbers like `99.99%`, `50%`, `$100.00`.** Use organic, messy data: `47.2%`, `$99.00`, `+1 (312) 847-1928`.
-- **Placeholder company names like "Acme Corp", "Nexus", "SmartFlow".** Invent contextual, believable brand names.
-- **AI copywriting cliches.** Never use "Elevate", "Seamless", "Unleash", "Next-Gen", "Game-changer", "Delve", "Tapestry", or "In the world of...". Write plain, specific language.
+- **Generic names, fake-perfect numbers, placeholder brand names, AI copywriting cliches.** Governed by Section 9.D. Flag every instance found on the existing site; do not repeat the banned-word list here, see that section.
 - **Exclamation marks in success messages.** Remove them. Be confident, not loud.
 - **"Oops!" error messages.** Be direct: "Connection failed. Please try again."
 - **Passive voice.** Use active voice: "We couldn't save your changes" instead of "Mistakes were made."
@@ -79,20 +69,20 @@ Check for these problems and fix them:
 
 ### Component Patterns
 
-- **Generic card look (border + shadow + white background).** Remove the border, or use only background color, or use only spacing. Cards should exist only when elevation communicates hierarchy.
+- **Generic card look (border + shadow + white background) with no elevation purpose.** Governed by Section 4.4: use cards only when elevation communicates hierarchy.
 - **Always one filled button + one ghost button.** Add text links or tertiary styles to reduce visual noise.
 - **Pill-shaped "New" and "Beta" badges.** Try square badges, flags, or plain text labels.
 - **Accordion FAQ sections.** Use a side-by-side list, searchable help, or inline progressive disclosure.
-- **3-card carousel testimonials with dots.** Replace with a masonry wall, embedded social posts, or a single rotating quote.
+- **3-card carousel testimonials with dots.** Replace with a masonry wall, embedded social posts, or a single rotating quote. See Section 4.10 for quote length and attribution rules once the format is fixed.
 - **Pricing table with 3 towers.** Highlight the recommended tier with color and emphasis, not just extra height.
 - **Modals for everything.** Use inline editing, slide-over panels, or expandable sections instead of popups for simple actions.
 - **Avatar circles exclusively.** Try squircles or rounded squares for a less generic look.
-- **Light/dark toggle always a sun/moon switch.** Use a dropdown, system preference detection, or integrate it into settings.
+- **Light/dark toggle always a sun/moon switch.** Use a dropdown, system preference detection, or integrate it into settings. See Section 8.C for when a manual toggle is warranted at all.
 - **Footer link farm with 4 columns.** Simplify. Focus on main navigational paths and legally required links.
 
 ### Iconography
 
-- **Lucide or Feather icons exclusively.** These are the "default" AI icon choice. Use Phosphor, Heroicons, or a custom set for differentiation.
+- **Lucide or Feather icons exclusively.** Governed by Section 9.E: use Phosphor, HugeIcons, Radix, or Tabler instead.
 - **Rocketship for "Launch", shield for "Security".** Replace cliche metaphors with less obvious icons (bolt, fingerprint, spark, vault).
 - **Inconsistent stroke widths across icons.** Audit all icons and standardize to one stroke weight.
 - **Missing favicon.** Always include a branded favicon.
@@ -104,12 +94,12 @@ Check for these problems and fix them:
 - **Inline styles mixed with CSS classes.** Move all styling to the project's styling system.
 - **Hardcoded pixel widths.** Use relative units (`%`, `rem`, `em`, `max-width`) for flexible layouts.
 - **Missing alt text on images.** Describe image content for screen readers. Never leave `alt=""` or `alt="image"` on meaningful images.
-- **Arbitrary z-index values like `9999`.** Establish a clean z-index scale in the theme/variables.
+- **Arbitrary z-index values like `9999`.** Governed by Section 6.F: establish a documented z-index scale instead.
 - **Commented-out dead code.** Remove all debug artifacts before shipping.
 - **Import hallucinations.** Check that every import actually exists in `package.json` or the project dependencies.
 - **Missing meta tags.** Add proper `<title>`, `description`, `og:image`, and social sharing meta tags.
 
-### Strategic Omissions (What AI Typically Forgets)
+### Strategic Omissions (what AI typically forgets)
 
 - **No legal links.** Add privacy policy and terms of service links in the footer.
 - **No "back" navigation.** Dead ends in user flows. Every page needs a way back.
@@ -117,4 +107,3 @@ Check for these problems and fix them:
 - **No form validation.** Add client-side validation for emails, required fields, and format checks.
 - **No "skip to content" link.** Essential for keyboard users. Add a hidden skip-link.
 - **No cookie consent.** If required by jurisdiction, add a compliant consent banner.
-

package/src/skills-lib/taste-skill/references/redesign-protocol.md

@@ -18,7 +18,7 @@ Document the current state before proposing changes:
 * **Information architecture** - page tree, primary nav, key conversion paths.
 * **Content blocks** - what exists, what's doing work, what's filler.
 * **Patterns to preserve** - signature interactions, recognisable hero, copy voice.
-* **Patterns to retire** - AI-slop tells, broken layouts, dead links, generic stock imagery, perf traps.
+* **Patterns to retire** - AI-slop tells, broken layouts, dead links, generic stock imagery, perf traps. Run the full checklist in [design-audit.md](design-audit.md) (Section 11.G) against the project and list every match here.
 * **Dial reading of the existing site** - infer current `DESIGN_VARIANCE` / `MOTION_INTENSITY` / `VISUAL_DENSITY`. That's your starting point, not the baseline.
 * **SEO baseline** - current ranking pages, meta titles, structured data, OG cards. **SEO migration is the #1 redesign risk.**
 
@@ -30,7 +30,7 @@ Document the current state before proposing changes:
 * **Respect existing analytics events.** Do not rename buttons, form fields, section IDs that downstream tracking depends on.
 
 ### 11.D Modernisation Levers (priority order)
-Apply in order - stop when the brief is satisfied:
+Apply in order - stop when the brief is satisfied. Concrete techniques for each lever live in [upgrade-techniques.md](upgrade-techniques.md) (Section 11.H).
 1. **Typography refresh** - biggest visual lift per unit of risk.
 2. **Spacing & rhythm** - increase section padding, fix vertical rhythm.
 3. **Color recalibration** - desaturate, unify neutrals, keep brand accent.

package/src/skills-lib/taste-skill/references/upgrade-techniques.md

@@ -0,0 +1,33 @@
+> taste-skill reference file. Loaded on demand from the SKILL.md index.
+> Cross-references like "Section N" map to sibling files via the index table in ../SKILL.md.
+
+## 11.H MODERNISATION TECHNIQUES (detail)
+
+High-impact techniques for the Modernisation Levers in Section 11.D, once the audit checklist (Section 11.G) has identified which categories need work. Grouped by Typography, Layout, and Motion/Surface. Where a technique already has a canonical skeleton or named pattern elsewhere in this skill, this file points there instead of restating it, so there is one implementation to maintain.
+
+### Typography Upgrades
+
+- **Variable font animation.** Interpolate weight or width on scroll or hover for text that feels alive.
+- **Outlined-to-fill transitions.** Text starts as a stroke outline and fills with color on scroll entry or interaction. Named pattern: "Gradient Stroke Animation" in Section 10.
+- **Text mask reveals.** Large typography acting as a window to video or animated imagery behind it. Named pattern: "Text Mask Reveal" in Section 10; use that vocabulary entry when scoping the work.
+
+### Layout Upgrades
+
+- **Broken grid / asymmetry.** Elements that deliberately ignore column structure: overlapping, bleeding off-screen, or offset with calculated randomness. Reach for this beyond the baseline anti-center-bias rule in Section 4.3 when the brief wants a stronger break from the grid.
+- **Whitespace maximization.** Aggressive use of negative space to force focus on a single element.
+- **Parallax card stacks.** Sections that stick and physically stack over each other during scroll. Implement with the canonical Sticky-Stack skeleton in Section 5.A; named pattern "Sticky Scroll Stack" in Section 10.
+- **Split-screen scroll.** Two halves of the screen sliding in opposite directions. Named pattern "Split-Screen Scroll" in Section 10.
+
+### Motion Upgrades
+
+- **Smooth scroll with inertia.** Decouple scrolling from browser defaults for a heavier, cinematic feel.
+- **Staggered entry.** Elements cascade in with slight delays, combining Y-axis translation with opacity fade. Never mount everything at once. Implement with the Scroll-Reveal Stagger skeleton in Section 5.C, or `staggerChildren` per Section 5.D.
+- **Spring physics.** Replace linear easing with spring-based motion for a natural, weighty feel on all interactive elements. Parameters and when to use them: Section 5 (Perpetual Micro-Interactions).
+- **Scroll-driven reveals.** Content entering through expanding masks, wipes, or draw-on SVG paths tied to scroll progress. Distinct from the simple enter-on-scroll stagger in Section 5.C: this is for a deliberate reveal choreography, not a generic list-item fade-in.
+
+### Surface Upgrades
+
+- **True glassmorphism.** Go beyond `backdrop-filter: blur`. Full technique (1px inner border, inset shadow, reduced-transparency fallback) and the honest Apple Liquid Glass distinction live in Section 5 (Liquid Glass / Glassmorphism) and design-systems.md Appendix C.
+- **Spotlight borders.** Card borders that illuminate dynamically under the cursor. Named pattern "Spotlight Border Card" in Section 10.
+- **Grain and noise overlays.** A fixed, `pointer-events-none` overlay with subtle noise to break digital flatness. Apply per the DOM-cost rule in Section 6.E: fixed layer only, never on a scrolling container.
+- **Colored, tinted shadows.** Shadows that carry the hue of the background rather than using generic black. Full rule in Section 4.4.

package/src/skills-lib/wizz-offer-forge/SKILL.md

@@ -49,8 +49,9 @@ Formule a Promessa Primária em 1 frase de alto impacto:
 Consulte `references/empilhamento-valor.md`:
 - **Produto Principal:** O caminho mais rápido e direto ao resultado.
 - **Bônus 1 (Velocidade):** Templates, atalhos, checklists prontos que encurtam a execução.
-- **Bônus 2 (Segurança):** Como evitar o erro mais comum ou o que fazer em caso de dúvida.
-- **Bônus 3 (Próximo Passo):** O que fazer depois de atingir o primeiro marco.
+- **Bônus 2 (Quebra de Objeção):** Elimina a maior desculpa para não comprar.
+- **Bônus 3 (Blindagem / Segurança):** Como evitar o erro mais comum ou o que fazer em caso de imprevisto.
+- **Bônus 4 (Próximo Nível):** O que fazer depois de atingir o primeiro marco.
 - **Order Bump Estratégico:** Complemento impulsivo de alta margem (30-50% de take rate).
 
 ### Passo 4 — Ancoragem de Preço & Garantia Reversa

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

@@ -10,7 +10,7 @@ description: "OBRIGATÓRIO: invoque ANTES de agir em qualquer pedido não-trivia
 
 Invoque esta skill ANTES de agir em pedidos não-triviais (feature, bug, design, marketing, SEO, infra, refactor, audit, review, integração, configuração — amplo OU específico).
 
-**Exceção única:** edições de 1 linha (typo, rename) e conversa pura.
+**Exceção única:** edições de 1 linha (typo, rename) e conversa pura. **Critério objetivo (TRIVIALITY GATE):** pedido que toca ≤1 arquivo, ~≤10 linhas, sem comportamento novo, mudança de tipo conhecido → executa direto, sem acionar router/maestro.
 
 **Fora do Plan Mode:** liste candidatas via `AskUserQuestion` e aguarde confirmação ANTES de disparar. Nunca auto-dispare fora do Plan Mode.
 **Dentro do Plan Mode:** auto-dispare todas as relevantes para enriquecer o plano.
@@ -24,6 +24,8 @@ Você é o **Diretor / porta de entrada** — não o orquestrador (esse é o `wi
 
 ## Triagem e delegação (o coração do Diretor)
 
+**Estágio do projeto (fail-open):** `grep -m1 '^stage:' {project-root}/**/project-context.md` (ex: `_wizz-output/project-context.md`, path configurável via `output_folder`). Se achar `prototype`/`mvp`, prefira solução leve e não recomende observabilidade/infra de produção; `production`, gates de qualidade valem integralmente. Sem arquivo: siga sem mencionar estágio.
+
 Descubra o contexto: **existe `{project-root}/_wizz/`?**
 
 ### A) Dentro de projeto Wizz — você DELEGA, nunca executa
@@ -42,6 +44,8 @@ Avalie a **Área**: quantas áreas o pedido toca (design, dev, copy, seo, growth
 
 > Um agente de área só cobre a área dele. 2+ áreas exigem coordenação = trabalho do maestro; a cláusula de área decide sozinha, sem somar com mais nada.
 
+**Descoberta de capacidade (índice, não atalho de delegação):** a [tabela de roteamento flat](references/routing-table-flat.md) também pode ser consultada aqui, dentro de projeto Wizz, quando o pedido não nomeia a capacidade certa (ex.: "quero um carrossel" → índice aponta `canvas-design`). Ela só serve pra achar o nome da capacidade; a entrega continua pelo dispatch normal acima (agente da área / maestro) — nunca dispare a skill direto a partir da tabela dentro de projeto Wizz.
+
 **Exemplos calibrados de borda** (do dataset de evals, `evals/routing/dataset.json`):
 
 - *Trivial → direto (sem router):* `t07` ("trocar 'envie' por 'enviar' na linha 42"): edição de 1 linha.
@@ -55,6 +59,8 @@ Ao delegar (pro maestro ou pro agente de área), declare o brief no formato do [
 
 Não há agentes wizz nem maestro. Você é a porta de descoberta global. Fluxo: analise a intenção (pode ter várias dimensões) → mapeie candidatas pela **[tabela de roteamento](references/routing-table-flat.md)** → fora do Plan Mode, apresente via `AskUserQuestion` e confirme → dispare as aprovadas via `Skill` (em paralelo quando independentes). Se nada cobrir, use o protocolo de **skill/MCP faltante** (no fim da mesma tabela).
 
+**Ao encerrar o modo flat**, emita 1 linha máquina-legível de decision-trace — telemetria de decisão coletada por hook — no formato exato: `🧭 {"rota":"flat:<skill>","sel":["id",...],"desc":[["id_descartado","motivo≤6 palavras"]],"gate":"n/a","repetiria":true}`
+
 ## Modo Auditoria 360°
 
 Ao detectar "auditoria completa / revisa tudo / 360 / análise geral", siga **[references/auditoria-360.md](references/auditoria-360.md)**.

package/src/skills-lib/wizz-router/references/routing-table-flat.md

@@ -1,6 +1,6 @@
 # Tabela de Roteamento — Modo Flat
 
-Use esta tabela **só fora de projeto Wizz** (sem `_wizz/`), quando o router mapeia skills/CLIs/MCPs direto. Dentro de projeto Wizz a delegação é decidida pela regra de dispatch no SKILL.md (maestro vs agente de área) e esta tabela não é necessária.
+Use esta tabela pra mapear skills/CLIs/MCPs direto **fora de projeto Wizz** (sem `_wizz/`) — aí o router dispara a skill sozinho. **Dentro de projeto Wizz** ela também pode ser consultada como ÍNDICE DE CAPACIDADES, pra descobrir uma capacidade relevante que o usuário não nomeou (ex.: "quero um carrossel" → `canvas-design`); mas a delegação continua sendo feita pelo dispatch normal do SKILL.md (agente da área / maestro) — a tabela nunca dispara a skill direto dentro de projeto Wizz.
 
 **Verificação de existência:** antes de oferecer qualquer skill, confirme que ela existe no ambiente (catálogo de skills da sessão ou `ls ~/.claude/skills`); se não existir, não ofereça: use o protocolo de skill faltante (`find-skills`).
 
@@ -16,6 +16,7 @@ Use esta tabela **só fora de projeto Wizz** (sem `_wizz/`), quando o router map
 | Dependências, packages, vulnerabilidades, npm audit | `database-and-deps` | 2 |
 | Segurança, XSS, CSRF, SQLi, IDOR, OWASP, rate limit, CORS, clickjacking, PII na resposta, enumeração de usuário, headers | `web-security` + `auth-and-secrets` | 1 |
 | Auditoria/pentest de segurança do app inteiro, "auditar segurança", "pentest", "encontrar vulnerabilidades", varredura antes de release | `security-audit-pentest` | 1 |
+| Auditoria de prontidão pra lançamento, "tá pronto pra lançar?", checklist de release amplo (técnico, segurança, SEO, analytics, conteúdo, legal, infra), "o que falta antes de ir pra produção" | `launch-readiness` | 1 |
 | Desktop, Electron, contextIsolation, code signing | `desktop-security` | 2 |
 
 ## Área Técnica — Código e Qualidade
@@ -77,7 +78,7 @@ Use esta tabela **só fora de projeto Wizz** (sem `_wizz/`), quando o router map
 | Copywriting, copy, persuasão, texto de venda | `copywriting` + `humanizer` | 1 |
 | Pesquisa de público de oferta, VoC, matriz de ângulos, léxico de infoproduto | `pesquisa-de-publico-do-piva` | 1 |
 | Forjar oferta, criar oferta irresistível, mecanismo único, bônus, garantia | `wizz-offer-forge` + `pricing-strategy` | 1 |
-| Pesquisa de mercado, inteligência competitiva | `deep-research` | 2 |
+| Pesquisa de mercado, inteligência competitiva | `deep-research` (plugin externo — só se instalado) | 2 |
 
 ## Contexto e Memória
 

package/tools/fetch-assets.mjs

@@ -4,8 +4,9 @@
 // Por que existe: `huashu-design/assets/**/*.mp3` (~30MB) e
 // `canvas-design/canvas-fonts/**/*.ttf` (~5.5MB) inflavam o pacote npm em
 // ~73%, mas só são necessários no primeiro uso real de export de vídeo
-// (BGM/SFX) ou de uma variante de fonte específica. Os arquivos continuam no
-// git (fonte de verdade); só saem do tarball publicado. Este script baixa o
+// (BGM/SFX) ou de uma variante de fonte específica. Fonte de verdade dos BGM
+// é o GitHub Release assets-v1 (fora do git e do tarball desde o P2 da
+// auditoria 360°); os SFX pequenos e as fontes seguem no git. Este script baixa o
 // bundle certo, no lugar certo, verificando sha256 (mesmo espírito do pin
 // com checksum do rtk — nunca extrai um bundle adulterado).
 //