wizz-method 2.2.0 → 2.3.1

package/src/skills-lib/site-launch-kit/references/15-medicao.md

@@ -1,35 +1,35 @@
-# Rodada 15 · Medição de lançamento
+# Round 15 · Launch measurement
 
-**Garante:** cada ação que vale dinheiro registrada com nome que faz sentido daqui a três meses.
-**Rode quando:** na véspera ou no dia do lançamento, com os pontos de contato finais no site.
+**Ensures:** every action that's worth money is tracked with a name that will still make sense three months from now.
+**Run when:** the day before or on launch day, with the final touchpoints on the site.
 
-Você é responsável pela medição deste site. Sua única tarefa nesta rodada: garantir que, no dia do lançamento, cada ação que vale dinheiro seja registrada com um nome que faça sentido daqui a três meses.
+You are responsible for this site's measurement. Your only task in this round: make sure that, on launch day, every action worth money is tracked with a name that makes sense three months from now.
 
-Antes de editar, detecte: framework, se já existe alguma ferramenta de medição instalada (analytics, pixel, tag manager), se há banner de consentimento e quais são os pontos de contato do site.
+Before editing, detect: framework, whether any measurement tool is already installed (analytics, pixel, tag manager), whether there's a consent banner, and what the site's touchpoints are.
 
-NÃO instale quatro ferramentas. NÃO envie dado pessoal como parâmetro de evento (nome, e-mail, telefone, CPF). NÃO invente conta nem identificador de medição: sem o identificador, deixe a variável de ambiente declarada e registre em PENDÊNCIAS.
+DO NOT install four tools. DO NOT send personal data as an event parameter (name, email, phone, national ID). DO NOT invent an account or measurement ID: without the ID, leave the environment variable declared and log it in PENDING ITEMS.
 
-1. LEVANTAMENTO
-   Liste o que já está instalado e o que cada coisa mede hoje. Duplicação é comum: analytics carregado duas vezes conta cada visita em dobro. Liste também todo ponto de contato: formulários, WhatsApp, telefone, e-mail, download, agendamento, CTA principal e o da barra fixa.
+1. SURVEY
+   List what's already installed and what each thing measures today. Duplication is common: analytics loaded twice counts every visit double. Also list every touchpoint: forms, WhatsApp, phone, email, download, scheduling, the main CTA, and the one on the sticky bar.
 
-2. NOMENCLATURA (faça isto antes de escrever código)
-   Defina o padrão e escreva-o em um arquivo de documentação do projeto: objeto_ação em minúsculas com sublinhado (formulario_enviado, whatsapp_clique, telefone_clique, orcamento_iniciado). Parâmetros úteis: origem do clique (herói, barra fixa, rodapé), página e identificador do formulário. Nada de dado pessoal. Uma constante por evento, em um arquivo só: nome de evento digitado à mão em cada componente diverge em uma semana.
+2. NAMING (do this before writing any code)
+   Define the standard and write it into a project documentation file: object_action in lowercase with underscores (formulario_enviado, whatsapp_clique, telefone_clique, orcamento_iniciado). Useful parameters: click origin (hero, sticky bar, footer), page, and form identifier. No personal data. One constant per event, in a single file: an event name typed by hand into each component drifts apart within a week.
 
-3. IMPLEMENTAÇÃO
-   - Script carregado sem travar a renderização.
-   - Nada dispara antes do consentimento, se houver banner.
-   - Anonimização de IP quando a ferramenta permitir.
-   - Um disparo por ação, protegido contra clique duplo e contra recarregamento da página de obrigado.
-   - Página de obrigado como conversão principal, ligada à rodada 03 (tempo de resposta).
-   - Se houver pixel de anúncio, dispare o mesmo evento nele, com o mesmo nome, para os relatórios baterem.
+3. IMPLEMENTATION
+   - Script loaded without blocking rendering.
+   - Nothing fires before consent, if there's a banner.
+   - IP anonymization when the tool allows it.
+   - One fire per action, guarded against double-clicks and against reloading the thank-you page.
+   - Thank-you page as the main conversion, tied to round 03 (response time).
+   - If there's an ad pixel, fire the same event on it, with the same name, so the reports match up.
 
-4. TESTE DE FUMAÇA
-   Em ambiente local ou de teste, execute cada ação e confirme o evento no depurador da ferramenta. Um evento não testado é um evento que não existe. Liste o que você conseguiu confirmar e o que ficou pendente.
+4. SMOKE TEST
+   In a local or staging environment, perform each action and confirm the event in the tool's debugger. An untested event is an event that doesn't exist. List what you were able to confirm and what's left pending.
 
-Formato de saída: depois de aplicar, uma tabela markdown, sem texto antes:
+Output format: after applying the changes, a markdown table, with no text before it:
 
-| Evento | Gatilho (arquivo · elemento) | Parâmetros | Testado? |
+| Event | Trigger (file · element) | Parameters | Tested? |
 
-Em seguida, PENDÊNCIAS (identificadores de conta, acessos, eventos não testados) e o padrão de nomenclatura em bloco de código, pronto para entrar na documentação do projeto.
+Then, PENDING ITEMS (account IDs, access, untested events) and the naming standard in a code block, ready to go into the project documentation.
 
-REGRA DE CORTE: meça poucas coisas e meça direito. Vinte eventos mal nomeados produzem um painel que ninguém abre; quatro eventos certos respondem à única pergunta que importa, que é de onde veio o cliente.
+CUTOFF RULE: measure a few things and measure them right. Twenty poorly named events produce a dashboard nobody opens; four well-named events answer the one question that matters, which is where the customer came from.

package/src/skills-lib/wizz-ai-product-design/SKILL.md

@@ -1,87 +1,87 @@
 ---
 name: wizz-ai-product-design
 description: >
-  Design de produtos e agentes de IA: como o agente se comporta, como escrever o prompt/system prompt,
-  guardrails e trust/safety, orquestração multi-agente e avaliação. Usar quando: criar ou melhorar um
-  agente/assistente/chatbot, escrever ou revisar system prompt, definir persona/tom/voz, montar few-shot,
-  chain-of-thought, guardrails, recusas, escalonamento pra humano, handoff entre agentes, detecção de
-  frustração, generative UI, ou medir qualidade de saída de IA. Base: Owl-Listener/ai-design-skills (MIT).
-  44 padrões em 6 categorias, cada um detalhado em references/. Use quando o pedido mencionar system
-  prompt, persona de agente, guardrails, orquestração multi-agente, handoff entre agentes ou avaliação
-  de qualidade de IA.
+  AI product and agent design: how the agent behaves, how to write the prompt/system prompt,
+  guardrails and trust/safety, multi-agent orchestration, and evaluation. Use when: creating or improving an
+  agent/assistant/chatbot, writing or reviewing a system prompt, defining persona/tone/voice, building few-shot
+  examples, chain-of-thought, guardrails, refusals, escalation to a human, agent handoff, frustration
+  detection, generative UI, or measuring AI output quality. Base: Owl-Listener/ai-design-skills (MIT).
+  44 patterns in 6 categories, each detailed in references/. Use when the request mentions system
+  prompt, agent persona, guardrails, multi-agent orchestration, agent handoff, or AI quality
+  evaluation.
 ---
 
-# AI Product Design — 44 padrões
+# AI Product Design — 44 patterns
 
-Biblioteca de padrões pra desenhar **como uma IA/agente se comporta** e **como o prompt dele é escrito**.
-Cada item abaixo tem o texto completo em `references/<categoria>/<nome>/SKILL.md`. Este arquivo é o índice:
-ache o padrão pela intenção, depois abra a reference pro detalhe.
+A pattern library for designing **how an AI/agent behaves** and **how its prompt is written**.
+Each item below has the full text in `references/<category>/<name>/SKILL.md`. This file is the index:
+find the pattern by intent, then open the reference for detail.
 
-> Uso no método: é a base pra construir e revisar os próprios agentes do Wizz Method (os 15 `customize.toml`,
-> system prompts, guardrails, handoffs). Consulte antes de criar/ajustar qualquer agente ou prompt.
+> Use in the method: this is the base for building and reviewing the Wizz Method's own agents (the 15 `customize.toml`,
+> system prompts, guardrails, handoffs). Consult it before creating/adjusting any agent or prompt.
 
-## 1. Comportamento do agente (`references/system-behavior-shaping/`)
-Como o agente soa e reage.
-- **persona-architecture** — define personagem, voz e traços uma vez, pra não derivar entre sessões
-- **tone-calibration** — botões de tom por contexto (formalidade, calor, confiança)
-- **emotional-design** — resposta a frustração, confusão, alegria, angústia (valida sem amplificar)
-- **error-personality** — como comunicar erro, incerteza e limite com elegância
-- **behavioral-consistency** — comportar-se previsível entre sessões, edge cases e modalidades
-- **domain-voice** — ajustar o comportamento pra um domínio profissional específico
-- **cultural-adaptation** — adaptar a contexto cultural, idioma e normas
+## 1. Agent behavior (`references/system-behavior-shaping/`)
+How the agent sounds and reacts.
+- **persona-architecture** — define character, voice, and traits once, so they don't drift across sessions
+- **tone-calibration** — tone dials per context (formality, warmth, confidence)
+- **emotional-design** — response to frustration, confusion, joy, distress (validates without amplifying)
+- **error-personality** — how to communicate error, uncertainty, and limits gracefully
+- **behavioral-consistency** — behaving predictably across sessions, edge cases, and modalities
+- **domain-voice** — adjusting behavior for a specific professional domain
+- **cultural-adaptation** — adapting to cultural context, language, and norms
 
-## 2. Interação humano-IA (`references/model-interaction-design/`)
-Como a conversa flui.
-- **conversation-patterns** — turnos, sequências de reparo, checkpoints de alinhamento
-- **frustration-detection** — ler frustração por caps, pontuação, repetição, latência e adaptar
-- **mixed-initiative-flow** — quando o agente lidera vs. quando o usuário lidera, com handoff limpo
-- **progressive-disclosure** — revelar o poder da ferramenta aos poucos, sem afogar no turno 1
-- **generative-ui** — quando renderizar um componente (date picker, card, gráfico) vs. texto puro
-- **multimodal-orchestration** — sequenciar texto, imagem, voz e uso de tool num fluxo só
-- **feedback-loops** — correção do usuário, thumbs, edição inline como sinal que muda o comportamento
-- **context-window-design** — orçamento de tokens, memória, resumir vs. buscar, degradação suave
+## 2. Human-AI interaction (`references/model-interaction-design/`)
+How the conversation flows.
+- **conversation-patterns** — turns, repair sequences, alignment checkpoints
+- **frustration-detection** — reading frustration via caps, punctuation, repetition, latency, and adapting
+- **mixed-initiative-flow** — when the agent leads vs. when the user leads, with a clean handoff
+- **progressive-disclosure** — revealing the tool's power gradually, without overwhelming turn 1
+- **generative-ui** — when to render a component (date picker, card, chart) vs. plain text
+- **multimodal-orchestration** — sequencing text, image, voice, and tool use in a single flow
+- **feedback-loops** — user correction, thumbs, inline editing as a signal that changes behavior
+- **context-window-design** — token budget, memory, summarizing vs. retrieving, graceful degradation
 
-## 3. Arquitetura de prompt (`references/prompt-architecture/`)
-Como o prompt é escrito. **A camada mais direta pra melhorar agentes.**
-- **system-prompt-structure** — anatomia: identidade, contexto, regras, formato, exemplos (o que importa no começo/fim)
-- **constraint-specification** — limites testáveis: formato, tamanho, tom, conteúdo proibido
-- **few-shot-patterns** — exemplos que miram os erros que o modelo insiste em cometer
-- **chain-of-thought-design** — cadeias de raciocínio deliberadas pra tarefa de vários passos
-- **template-design** — templates parametrizados com variáveis nomeadas e seções condicionais
-- **context-engineering** — o que entra no contexto e em que ordem
-- **prompt-versioning** — versionar prompts, testar mudanças, rastrear o que funciona
+## 3. Prompt architecture (`references/prompt-architecture/`)
+How the prompt is written. **The most direct layer for improving agents.**
+- **system-prompt-structure** — anatomy: identity, context, rules, format, examples (what matters at the start/end)
+- **constraint-specification** — testable limits: format, length, tone, prohibited content
+- **few-shot-patterns** — examples that target the errors the model keeps making
+- **chain-of-thought-design** — deliberate reasoning chains for multi-step tasks
+- **template-design** — parameterized templates with named variables and conditional sections
+- **context-engineering** — what goes into context and in what order
+- **prompt-versioning** — versioning prompts, testing changes, tracking what works
 
 ## 4. Trust & Safety (`references/ai-alignment-reasoning/`)
-O que o agente pode e não pode; como não enganar o usuário.
-- **guardrail-design** — limites de comportamento e padrões de recusa explícitos (o "pode/não pode")
-- **transparency-patterns** — mostrar o que o modelo sabe, não sabe e o quão certo está
-- **trust-calibration** — nem overtrust nem undertrust; sinalizar incerteza em vez de blefar
-- **escalation-design** — quando escalar pra humano, recusar, ou pedir esclarecimento
-- **harm-anticipation** — mapear failure modes, mau uso e consequências não intencionais
-- **value-specification** — traduzir valores da organização em constraints do sistema
-- **consent-and-agency** — consentimento informado, opt-out e override humano
-- **bias-detection-design** — workflows de review pra achar e mitigar viés
+What the agent can and can't do; how not to mislead the user.
+- **guardrail-design** — explicit behavior limits and refusal patterns (the "can/can't")
+- **transparency-patterns** — showing what the model knows, doesn't know, and how confident it is
+- **trust-calibration** — neither overtrust nor undertrust; signal uncertainty instead of bluffing
+- **escalation-design** — when to escalate to a human, refuse, or ask for clarification
+- **harm-anticipation** — mapping failure modes, misuse, and unintended consequences
+- **value-specification** — translating organizational values into system constraints
+- **consent-and-agency** — informed consent, opt-out, and human override
+- **bias-detection-design** — review workflows to find and mitigate bias
 
-## 5. Orquestração multi-agente (`references/design-agent-orchestration/`)
-Pra sistemas com vários agentes (o caso do próprio método: Diretor → maestro → agentes).
-- **agent-role-design** — o que cada agente faz, sabe e é dono num sistema multi-agente
-- **task-decomposition** — quebrar objetivo complexo em subtarefas que os agentes resolvem
-- **handoff-protocols** — transições suaves entre agentes e entre IA e humano
-- **state-management** — contexto, memória e estado compartilhados entre agentes
-- **human-in-the-loop** — pontos de intervenção onde o humano revisa, aprova ou redireciona
-- **failure-recovery** — quando um agente falha: retry, fallback, escalar, degradação suave
-- **observability-design** — tornar o workflow multi-agente visível e debugável
+## 5. Multi-agent orchestration (`references/design-agent-orchestration/`)
+For systems with multiple agents (the method's own case: Diretor → maestro → agents).
+- **agent-role-design** — what each agent does, knows, and owns in a multi-agent system
+- **task-decomposition** — breaking a complex goal into subtasks the agents solve
+- **handoff-protocols** — smooth transitions between agents and between AI and human
+- **state-management** — context, memory, and state shared across agents
+- **human-in-the-loop** — intervention points where the human reviews, approves, or redirects
+- **failure-recovery** — when an agent fails: retry, fallback, escalate, graceful degradation
+- **observability-design** — making the multi-agent workflow visible and debuggable
 
-## 6. Avaliação (`references/evaluation/`)
-Como saber se a IA está boa.
-- **output-quality-rubrics** — definir o que é "bom": acurácia, relevância, utilidade
-- **task-success-metrics** — medir se a IA de fato ajudou o usuário a concluir a meta
-- **user-satisfaction-signals** — ler sinais implícitos/explícitos: edições, regenerações, abandono
-- **failure-taxonomy** — classificar falhas: alucinação, recusa, irrelevância, tom errado, latência
-- **comparative-evaluation** — A/B, comparação lado a lado, ranking de preferência
-- **heuristic-evaluation-ai** — heurísticas de Nielsen adaptadas + heurísticas próprias de IA
-- **longitudinal-measurement** — qualidade ao longo do tempo: drift, degradação, melhoria
+## 6. Evaluation (`references/evaluation/`)
+How to know if the AI is good.
+- **output-quality-rubrics** — defining what "good" means: accuracy, relevance, usefulness
+- **task-success-metrics** — measuring whether the AI actually helped the user reach the goal
+- **user-satisfaction-signals** — reading implicit/explicit signals: edits, regenerations, abandonment
+- **failure-taxonomy** — classifying failures: hallucination, refusal, irrelevance, wrong tone, latency
+- **comparative-evaluation** — A/B, side-by-side comparison, preference ranking
+- **heuristic-evaluation-ai** — adapted Nielsen heuristics + AI-specific heuristics
+- **longitudinal-measurement** — quality over time: drift, degradation, improvement
 
 ---
 
-**Créditos:** Owl-Listener/ai-design-skills (licença MIT, ver `references/LICENSE`). Índice traduzido/curado para o Wizz Method.
+**Credits:** Owl-Listener/ai-design-skills (MIT license, see `references/LICENSE`). Index translated/curated for the Wizz Method.

package/src/skills-lib/wizz-auth-and-secrets/SKILL.md

@@ -1,100 +1,100 @@
 ---
 name: wizz-auth-and-secrets
 description: >
-  Segurança de autenticação e gestão de secrets. Usar quando: implementar auth, lidar com JWT/OAuth/SSO,
-  token no header vs URL, revogação de token no logout, enumeração de usuário/mensagem genérica,
-  guardar API keys ou credenciais, configurar Clerk/Supabase auth, revisar onde secrets estão armazenados,
-  rotação de credenciais, checar se .env está seguro. Use quando o usuário mencionar login, cadastro,
-  senha, JWT, OAuth, SSO, 2FA, sessão, logout, API key ou variável de ambiente/.env.
+  Authentication security and secrets management. Use when: implementing auth, handling JWT/OAuth/SSO,
+  token in header vs URL, token revocation on logout, user enumeration/generic messages,
+  storing API keys or credentials, configuring Clerk/Supabase auth, reviewing where secrets are stored,
+  credential rotation, checking whether .env is secure. Use when the user mentions login, signup,
+  password, JWT, OAuth, SSO, 2FA, session, logout, API key, or environment variable/.env.
 ---
 
 # Auth and Secrets
 
-## Autenticação
+## Authentication
 
-### Senhas
-- Hash com bcrypt (custo >= 12), Argon2id ou scrypt. Nunca MD5/SHA1 para senhas
-- Mínimo de 8 caracteres, sem restrição de caracteres especiais
-- Implemente bloqueio após N tentativas (lockout ou CAPTCHA)
-- Ofereça 2FA: TOTP (Google Authenticator) é o padrão mínimo
+### Passwords
+- Hash with bcrypt (cost >= 12), Argon2id, or scrypt. Never MD5/SHA1 for passwords
+- Minimum 8 characters, no restriction on special characters
+- Implement lockout after N attempts (lockout or CAPTCHA)
+- Offer 2FA: TOTP (Google Authenticator) is the minimum standard
 
 ### JWT
-- Na verificação, aceite só o algoritmo esperado: rejeite `alg: none` e não deixe o token escolher o algoritmo (ataque de confusão de algoritmo)
-- Prefira RS256 (assimétrico) quando mais de um serviço verifica o token. HS256 só com secret forte: 32+ bytes aleatórios, nunca uma palavra
-- exp curto para access token (15 min a 1h)
-- Refresh token com rotação: ao usar, invalide o anterior e emita novo
-- Nunca coloque dados sensíveis no payload (é base64, não criptografia)
-- **Token no header `Authorization: Bearer`, NUNCA na URL/query string** (a URL vaza em logs de servidor, histórico do browser, header `Referer` e analytics)
-- **Logout de verdade revoga o token**: coloque na blacklist (Redis, TTL = exp do token) e invalide o refresh token. Sem isso o access token continua válido depois do logout até expirar sozinho
-
-### Enumeração de usuário
-Evita que um atacante descubra quais e-mails existem na base (login, signup, reset de senha).
-- Resposta idêntica para e-mail existente e inexistente: "Se o e-mail existir, enviamos um link"
-- No login use mensagem genérica ("credenciais inválidas"), nunca "e-mail não cadastrado" vs "senha incorreta"
-- Responda em **tempo constante**: rode o hash da senha mesmo quando o usuário não existe (senão o tempo de resposta denuncia quem existe)
-- Reforce com rate limit por IP **e** por conta (ver wizz-web-security) para barrar varredura de e-mails
+- On verification, accept only the expected algorithm: reject `alg: none` and don't let the token choose the algorithm (algorithm confusion attack)
+- Prefer RS256 (asymmetric) when more than one service verifies the token. HS256 only with a strong secret: 32+ random bytes, never a word
+- Short exp for access tokens (15 min to 1h)
+- Refresh token with rotation: on use, invalidate the previous one and issue a new one
+- Never put sensitive data in the payload (it's base64, not encryption)
+- **Token in the `Authorization: Bearer` header, NEVER in the URL/query string** (the URL leaks into server logs, browser history, the `Referer` header, and analytics)
+- **A real logout revokes the token**: blacklist it (Redis, TTL = token exp) and invalidate the refresh token. Without this, the access token stays valid after logout until it expires on its own
+
+### User enumeration
+Prevents an attacker from discovering which emails exist in the database (login, signup, password reset).
+- Identical response for existing and non-existing email: "If the email exists, we sent a link"
+- On login use a generic message ("invalid credentials"), never "email not registered" vs "wrong password"
+- Respond in **constant time**: run the password hash even when the user doesn't exist (otherwise the response time gives away who exists)
+- Reinforce with rate limiting by IP **and** by account (see wizz-web-security) to block email scanning
 
 ### OAuth / SSO
-- Use biblioteca estabelecida, não implemente o flow manualmente
-- Valide state parameter para prevenir CSRF
-- PKCE obrigatório para flows em SPAs e apps mobile
-
-### Stack Supabase + Clerk
-- Auth gerenciada pelo Clerk: nunca reimplementar flows de auth manualmente
-- Toda rota protegida, Server Action e route handler chama `auth()` do Clerk no servidor. Nunca confiar em estado de sessão vindo do cliente
-- Clerk webhook (`svix`) verificado por assinatura antes de processar: não confiar no body sem verificar
-- Webhook de pagamento/provedor externo: além de verificar a assinatura, **nunca confie em valor de status, dinheiro ou permissão que veio no corpo**. Confirme com o provedor de origem (ex: re-buscar a sessão no Stripe pelo id) antes de liberar acesso ou creditar saldo. Assinatura válida só prova que o evento veio do provedor, não que o payload não foi remontado num replay.
-- Supabase RLS: toda tabela de domínio deve ter RLS ativo; queries devem filtrar por `workspace_id`/`user_id`
-- `SUPABASE_SERVICE_ROLE_KEY` bypassa RLS: só em server-side (API routes, jobs), nunca exposta no frontend
-- `NEXT_PUBLIC_*` = seguro expor no cliente; tudo sem `NEXT_PUBLIC_` = server-only
-
-## Secrets e credenciais
-
-### O que nunca fazer
-- Commitar .env no git (use .gitignore + git-secrets)
-- Hardcodar API keys no código-fonte
-- Logar credenciais mesmo em debug
-- Usar mesmas credenciais em dev e produção
-
-### Onde guardar secrets
-- Produção: variáveis de ambiente da plataforma (Vercel: `vercel env add`)
-- CI/CD: variáveis de ambiente criptografadas da plataforma (GitHub Actions Secrets, etc.)
-- Dev local: arquivo `.env.local` nunca commitado. Verificar com `git check-ignore -v .env.local`
-
-### API keys emitidas pelo próprio app
-Se o app gera API keys para os usuários:
-- Guarde só o hash (SHA-256) da key no banco, nunca a key em texto plano
-- Mostre a key completa uma única vez, na criação
-- Use prefixo identificável (ex: `wz_live_`) para facilitar detecção em scan de repositório
-- Permita revogar e listar keys por usuário
-
-### Cripto de credenciais de usuário (AES-256-GCM)
-Se o app armazena credenciais de terceiros do usuário (ex: SMTP, WhatsApp API):
+- Use an established library, don't implement the flow manually
+- Validate the state parameter to prevent CSRF
+- PKCE mandatory for SPA and mobile app flows
+
+### Supabase + Clerk stack
+- Auth managed by Clerk: never reimplement auth flows manually
+- Every protected route, Server Action, and route handler calls Clerk's `auth()` on the server. Never trust session state coming from the client
+- Clerk webhook (`svix`) verified by signature before processing: don't trust the body without verifying
+- Payment/external provider webhook: besides verifying the signature, **never trust a status, money, or permission value that came in the body**. Confirm with the originating provider (e.g. re-fetch the session from Stripe by id) before granting access or crediting a balance. A valid signature only proves the event came from the provider, not that the payload wasn't reassembled in a replay.
+- Supabase RLS: every domain table must have RLS enabled; queries must filter by `workspace_id`/`user_id`
+- `SUPABASE_SERVICE_ROLE_KEY` bypasses RLS: server-side only (API routes, jobs), never exposed on the frontend
+- `NEXT_PUBLIC_*` = safe to expose on the client; anything without `NEXT_PUBLIC_` = server-only
+
+## Secrets and credentials
+
+### What to never do
+- Commit .env to git (use .gitignore + git-secrets)
+- Hardcode API keys in the source code
+- Log credentials even in debug
+- Use the same credentials in dev and production
+
+### Where to store secrets
+- Production: the platform's environment variables (Vercel: `vercel env add`)
+- CI/CD: the platform's encrypted environment variables (GitHub Actions Secrets, etc.)
+- Local dev: `.env.local` file, never committed. Verify with `git check-ignore -v .env.local`
+
+### API keys issued by the app itself
+If the app generates API keys for users:
+- Store only the key's hash (SHA-256) in the database, never the plaintext key
+- Show the full key exactly once, at creation
+- Use an identifiable prefix (e.g. `wz_live_`) to make repository scan detection easier
+- Allow revoking and listing keys per user
+
+### Encrypting user credentials (AES-256-GCM)
+If the app stores the user's third-party credentials (e.g. SMTP, WhatsApp API):
 ```ts
-// src/lib/crypto.ts: chave vem do env, nunca hardcodada
+// src/lib/crypto.ts: key comes from env, never hardcoded
 import { createCipheriv, randomBytes } from "crypto"
 
 const key = process.env.CREDENTIAL_ENCRYPTION_KEY // base64, 32 bytes
-if (!key) throw new Error("CREDENTIAL_ENCRYPTION_KEY não configurada")
+if (!key) throw new Error("CREDENTIAL_ENCRYPTION_KEY not configured")
 
 export function encrypt(plain: string) {
-  const iv = randomBytes(12) // IV aleatório por registro, nunca reutilizar
+  const iv = randomBytes(12) // random IV per record, never reuse
   const cipher = createCipheriv("aes-256-gcm", Buffer.from(key, "base64"), iv)
   const enc = Buffer.concat([cipher.update(plain, "utf8"), cipher.final()])
   return { iv: iv.toString("base64"), data: enc.toString("base64"), tag: cipher.getAuthTag().toString("base64") }
 }
-// no decrypt: setAuthTag antes de final(), senão a integridade não é verificada
+// on decrypt: setAuthTag before final(), otherwise integrity isn't verified
 ```
 
-### Rotação de credenciais
-- Rotacione secrets de terceiros a cada 90 dias ou após qualquer saída de membro do time
-- Secret commitado por acidente: considere comprometido e rotacione na hora. Reescrever o histórico do git não basta
-- API keys de produção: uma por serviço/ambiente, nunca compartilhadas
-- Database passwords: use IAM auth quando disponível no cloud provider
+### Credential rotation
+- Rotate third-party secrets every 90 days or after any team member leaves
+- A secret committed by accident: treat it as compromised and rotate it immediately. Rewriting git history isn't enough
+- Production API keys: one per service/environment, never shared
+- Database passwords: use IAM auth when available on the cloud provider
 
-### Comparação de tokens
-- NUNCA comparar tokens com `===` ou `!==` (timing attack)
-- SEMPRE usar `crypto.timingSafeEqual`:
+### Token comparison
+- NEVER compare tokens with `===` or `!==` (timing attack)
+- ALWAYS use `crypto.timingSafeEqual`:
 ```ts
 import { timingSafeEqual } from "crypto"
 const expected = Buffer.from(process.env.MY_SECRET_TOKEN!)
@@ -104,9 +104,9 @@ if (expected.length !== received.length || !timingSafeEqual(expected, received))
 }
 ```
 
-### Checklist de secrets
-- [ ] `grep -r "sk_live\|sk_test\|service_role\|eyJ\|AAAA" src/` → vazio?
-- [ ] `.env*` no `.gitignore`?
-- [ ] `git log --all --diff-filter=A -- .env*` → vazio?
-- [ ] Secrets de produção diferentes dos de dev?
-- [ ] `SUPABASE_SERVICE_ROLE_KEY` nunca em variável `NEXT_PUBLIC_`?
+### Secrets checklist
+- [ ] `grep -r "sk_live\|sk_test\|service_role\|eyJ\|AAAA" src/` → empty?
+- [ ] `.env*` in `.gitignore`?
+- [ ] `git log --all --diff-filter=A -- .env*` → empty?
+- [ ] Production secrets different from dev?
+- [ ] `SUPABASE_SERVICE_ROLE_KEY` never in a `NEXT_PUBLIC_` variable?

package/src/skills-lib/wizz-caching-and-queues/SKILL.md

@@ -1,58 +1,58 @@
 ---
 name: wizz-caching-and-queues
-description: Caching e filas assíncronas — Redis cache-aside/write-through, TTL, rate limiting, BullMQ, SQS, Kafka. Use quando o pedido envolver cache, sessões, filas de job, processamento assíncrono.
+description: Caching and asynchronous queues — Redis cache-aside/write-through, TTL, rate limiting, BullMQ, SQS, Kafka. Use when the request involves cache, sessions, job queues, asynchronous processing.
 ---
 
 # Caching and Queues
 
-## Estratégias de cache
+## Caching strategies
 
 ### Cache-aside (Lazy Loading)
-1. App busca no cache
-2. Se não tem (miss), busca no banco
-3. Salva no cache e retorna
-Vantagem: cache só tem o que foi acessado
-Desvantagem: primeiro acesso é lento (cold start)
+1. App looks in the cache
+2. If it's not there (miss), look in the database
+3. Save to cache and return
+Advantage: the cache only holds what's been accessed
+Disadvantage: the first access is slow (cold start)
 
 ### Write-through
-1. App escreve no cache e no banco simultaneamente
-Vantagem: cache sempre atualizado
-Desvantagem: escreve em tudo mesmo para dados raramente lidos
+1. App writes to the cache and the database at the same time
+Advantage: the cache is always up to date
+Disadvantage: writes everything even for rarely-read data
 
 ### TTL (Time to Live)
-- Dados de sessão: 30 min a 24h
-- Respostas de API externa: conforme frequência de mudança
-- Contadores e rankings: 1 a 5 minutos
-- Configurações do sistema: 5 a 60 minutos
+- Session data: 30 min to 24h
+- External API responses: depends on how often they change
+- Counters and rankings: 1 to 5 minutes
+- System settings: 5 to 60 minutes
 
-## Redis: padrões de uso
+## Redis: usage patterns
 
-### Cache de resposta HTTP
-- Chave: hash da URL + query params + usuário
-- TTL: definido por tipo de dado
+### HTTP response cache
+- Key: hash of URL + query params + user
+- TTL: set per data type
 
 ### Rate limiting
-- Chave: user_id ou IP
-- Estrutura: INCR + EXPIRE
+- Key: user_id or IP
+- Structure: INCR + EXPIRE
 
 ### Session store
-- Mais rápido que banco para sessões ativas
-
-## Filas assíncronas
-
-### Quando usar fila
-- Processamento de imagem/vídeo
-- Envio de emails e notificações
-- Integração com sistemas externos lentos
-- Qualquer operação > 500ms que não precisa de resposta imediata
-
-### Ferramentas
-- BullMQ (Node.js + Redis): simples, confiável, boa UI com Bull Board
-- SQS (AWS): managed, sem infraestrutura para manter
-- RabbitMQ: roteamento complexo de mensagens
-- Kafka: streaming de alto volume, retenção de mensagens
-
-### Boas práticas de fila
-- Defina max retries e dead letter queue
-- Jobs devem ser idempotentes (reprocessamento seguro)
-- Monitore tamanho da fila (backlog crescendo = problema)
+- Faster than the database for active sessions
+
+## Asynchronous queues
+
+### When to use a queue
+- Image/video processing
+- Sending emails and notifications
+- Integration with slow external systems
+- Any operation > 500ms that doesn't need an immediate response
+
+### Tools
+- BullMQ (Node.js + Redis): simple, reliable, good UI with Bull Board
+- SQS (AWS): managed, no infrastructure to maintain
+- RabbitMQ: complex message routing
+- Kafka: high-volume streaming, message retention
+
+### Queue best practices
+- Define max retries and a dead letter queue
+- Jobs must be idempotent (safe to reprocess)
+- Monitor queue size (a growing backlog = a problem)