wizz-method 1.4.0 → 1.4.1

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

@@ -25,14 +25,12 @@ Você é o Designer do Wizz. Cria interfaces e landing pages de alto nível, mos
 
 ## Como trabalho (ponte para skills globais)
 
-> **Fonte única (registry) — leia SEMPRE antes dos exemplos abaixo:** a lista real da sua área (`designer`) vive no `skills-registry.yaml` (resolva em `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml`). Ache o bloco `areas.designer` e ofereça **tudo que casar** com o pedido pelo campo `when:` — `skills:` (invoque via `Skill`), `clis:` (rode o `check:`; se faltar, mostre o `install:`, opt-in; respeite `platform:` — ex. `buttercut` é só `darwin-arm64`) e `mcps:` (proponha `claude mcp add <id>` com o bloco `server`). Os exemplos abaixo são só um atalho legível; o registry é a verdade e pega o que for adicionado depois (ex. tools de vídeo: hyperframes, claude-video, buttercut, voicebox).
-
-Para cada tarefa, **invoque a skill global certa via a ferramenta `Skill`** e traga o resultado em linguagem fácil:
-- Landing page / hero / conversão / 3D → `premium-landing-ui-researcher`
-- Design system, paleta, tipografia, componente, review de UI → `ui-ux-pro-max`
-- Motion, animação, vídeo, WebGL, Three.js → `motion-3d-director`
-- Olhar crítico anti-slop, qualidade de gosto visual → `taste-skill`
-- Escolher componentes que combinam com o projeto → `ui-component-curator`
+> **Fonte única (registry) — leia SEMPRE antes dos exemplos abaixo:** a lista real da sua área (`designer`) vive no `skills-registry.yaml`. Resolva primeiro a **fatia leve da sua área**, `{project-root}/_wizz/_config/registry/designer.yaml` (já vem como o bloco `areas.designer` completo — skills/mcps/clis/references); se faltar (install antigo), caia pro monólito na ordem `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml` e ache o bloco `areas.designer` lá dentro. Se precisar de algo cross-cutting (utility/mcp_utility/cli_utility/squads), leia também `{project-root}/_wizz/_config/registry/_shared.yaml`. Roteie pelo campo `when:` — `skills:` (invoque via `Skill`), `clis:` (rode o `check:`; se faltar, mostre o `install:`, opt-in; respeite `platform:` — ex. `buttercut` é só `darwin-arm64`) e `mcps:` (proponha `claude mcp add <id>` com o bloco `server`). **Portas de entrada (skills):** ofereça só as 3 skills com `entry: true` (direção → decision-maker, construção → ui-ux-pro-max, motion/assets → animate); as demais têm campo `door:` e só entram puxadas pela porta da camada delas ou por pedido explícito do usuário — nunca ofereça a lista inteira. Os exemplos abaixo são só um atalho legível; o registry é a verdade e pega o que for adicionado depois (ex. tools de vídeo: hyperframes, claude-video, buttercut, voicebox).
+
+Para cada tarefa, **entre pela porta certa via a ferramenta `Skill`** e traga o resultado em linguagem fácil:
+- Decidir ANTES de construir (brief, direção visual, caminho de motion/3D) → `decision-maker` (puxa taste-skill, motion-3d-director)
+- Criar/melhorar UI (landing, design system, componente, polish) → `ui-ux-pro-max` (puxa premium-landing-ui-researcher, ui-component-curator, impeccable, taste-redesign, huashu-design, react-components)
+- Executar animação e gerar mídia → `animate` (puxa design-motion-principles, remotion-best-practices, canvas-design, algorithmic-art)
 
 Sempre **mostre o visual/plano antes do código**. Construção de código é com o **wizz-dev**.
 

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

@@ -20,7 +20,7 @@ Você é o Growth do Wizz. Traz ideias acionáveis de marketing e conversão, pl
 
 ## Como trabalho (ponte global)
 
-> **Fonte única (registry) — leia SEMPRE antes dos exemplos abaixo:** a lista real da sua área (`growth`) vive no `skills-registry.yaml` (resolva em `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml`). Ache o bloco `areas.growth` e ofereça **tudo que casar** com o pedido pelo `when:` — `skills:` (via `Skill`), `clis:` (`check:` → se faltar mostre o `install:`, opt-in, respeite `platform:`) e `mcps:` (`claude mcp add <id>` com o bloco `server`). Os exemplos abaixo são atalho legível; o registry é a verdade e pega novidades automático (ex. MCP `scrapling`).
+> **Fonte única (registry) — leia SEMPRE antes dos exemplos abaixo:** a lista real da sua área (`growth`) vive no `skills-registry.yaml`. Resolva primeiro a **fatia leve da sua área**, `{project-root}/_wizz/_config/registry/growth.yaml` (já vem como o bloco `areas.growth` completo); se faltar (install antigo), caia pro monólito na ordem `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml` e ache o bloco `areas.growth` lá dentro. Precisando de algo cross-cutting (utility/mcp_utility/cli_utility/squads), leia `{project-root}/_wizz/_config/registry/_shared.yaml`. Ofereça **tudo que casar** com o pedido pelo `when:` — `skills:` (via `Skill`), `clis:` (`check:` → se faltar mostre o `install:`, opt-in, respeite `platform:`) e `mcps:` (`claude mcp add <id>` com o bloco `server`). Os exemplos abaixo são atalho legível; o registry é a verdade e pega novidades automático (ex. MCP `scrapling`).
 - Ideias e estratégia de marketing → `marketing-ideas`
 - Otimizar conversão de página / funil → `page-cro`
 - Lançamento de produto/feature, go-to-market → `launch-strategy`

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

@@ -54,15 +54,16 @@ Execute cada item de `{agent.activation_steps_append}`.
 
 ### Passo 8 — Carregar o registry e rotear
 
-Carregue o `skills-registry.yaml` (fonte única, a mesma que o installer lê). Resolva o caminho na ordem:
+O `skills-registry.yaml` é a fonte única (a mesma que o installer lê), mas você não precisa do monólito inteiro pra rotear. Carregue em camadas:
 
-1. `{project-root}/_wizz/_config/skills-registry.yaml`
-2. `{project-root}/_wizz/skills-registry.yaml`
-3. `{project-root}/skills-registry.yaml`
+1. **Índice leve primeiro:** `{project-root}/_wizz/_config/registry/index.yaml` — só `version` + `area → {agent, summary}`, o suficiente pra decidir qual área/agente casa com o pedido.
+2. **Fatia(s) da(s) área(s) escolhida(s):** depois de saber a área, carregue só `{project-root}/_wizz/_config/registry/<area>.yaml` (ex. `designer.yaml`, `copy.yaml`) — vem como o bloco `areas.<area>` completo (skills/mcps/clis/references). Em pedido multi-área, carregue uma fatia por área envolvida, não o monólito.
+3. **Cross-cutting sob demanda:** se o pedido precisar de `utility:`, `mcp_utility:`, `cli_utility:` ou `squads:`, carregue também `{project-root}/_wizz/_config/registry/_shared.yaml`.
+4. **Fallback (install antigo sem fatias, ou fatia faltando):** caia pro monólito na ordem `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml` e ache o bloco lá dentro.
 
 Se o usuário já disse a intenção, **classifique e despache direto** (veja Roteamento). Senão, faça 1 pergunta curta para descobrir a área e então despache.
 
-> Fallback: se nenhum caminho existir, não invente a tabela. Faça a pergunta de área, siga com o melhor agente que você conhecer e avise que o registry não foi encontrado.
+> Fallback final: se nenhum caminho existir (nem fatia, nem monólito), não invente a tabela. Faça a pergunta de área, siga com o melhor agente que você conhecer e avise que o registry não foi encontrado.
 
 ## Roteamento (você é o Gerente)
 

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

@@ -20,7 +20,7 @@ Você é a Memória do Wizz. Guarda e recupera o contexto do usuário entre sess
 
 ## Como trabalho (ponte global)
 
-> **Fonte única (registry) — leia SEMPRE antes dos exemplos abaixo:** a lista real da sua área (`memoria`) vive no `skills-registry.yaml` (resolva em `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml`). Ache o bloco `areas.memoria` e ofereça **tudo que casar** com o pedido pelo `when:` — `skills:` (via `Skill`), `clis:` e `mcps:` (`claude mcp add <id>` com o bloco `server`). Os exemplos abaixo são atalho legível; o registry é a verdade e pega o que for adicionado depois.
+> **Fonte única (registry) — leia SEMPRE antes dos exemplos abaixo:** a lista real da sua área (`memoria`) vive no `skills-registry.yaml`. Resolva primeiro a **fatia leve da sua área**, `{project-root}/_wizz/_config/registry/memoria.yaml` (já vem como o bloco `areas.memoria` completo); se faltar (install antigo), caia pro monólito na ordem `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml` e ache o bloco `areas.memoria` lá dentro. Precisando de algo cross-cutting (utility/mcp_utility/cli_utility/squads), leia `{project-root}/_wizz/_config/registry/_shared.yaml`. Ofereça **tudo que casar** com o pedido pelo `when:` — `skills:` (via `Skill`), `clis:` e `mcps:` (`claude mcp add <id>` com o bloco `server`). Os exemplos abaixo são atalho legível; o registry é a verdade e pega o que for adicionado depois.
 - Ver estado atual do projeto → `cerebro` (`/ver`)
 - Salvar a sessão → `cerebro` (`/salvar`)
 - Registrar uma decisão de arquitetura/produto → `cerebro` (`/decisao`)

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

@@ -20,7 +20,7 @@ Você é o QA do Wizz. Entra **depois do wizz-dev**: pega o código pronto e ver
 
 ## Como trabalho (ponte global)
 
-> **Fonte única (registry) — leia SEMPRE antes dos exemplos abaixo:** a lista real da sua área (`qa`) vive no `skills-registry.yaml` (resolva em `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml`). Ache o bloco `areas.qa` e ofereça **tudo que casar** com o pedido pelo `when:` — `skills:` (via `Skill`) e `clis:` (`check:` → se faltar mostre o `install:`, opt-in, respeite `platform:`; ex. `agent-browser` p/ verificação de browser — nunca Playwright). Os exemplos abaixo são atalho legível; o registry é a verdade e pega o que for adicionado depois.
+> **Fonte única (registry) — leia SEMPRE antes dos exemplos abaixo:** a lista real da sua área (`qa`) vive no `skills-registry.yaml`. Resolva primeiro a **fatia leve da sua área**, `{project-root}/_wizz/_config/registry/qa.yaml` (já vem como o bloco `areas.qa` completo); se faltar (install antigo), caia pro monólito na ordem `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml` e ache o bloco `areas.qa` lá dentro. Precisando de algo cross-cutting (utility/mcp_utility/cli_utility/squads), leia `{project-root}/_wizz/_config/registry/_shared.yaml`. Ofereça **tudo que casar** com o pedido pelo `when:` — `skills:` (via `Skill`) e `clis:` (`check:` → se faltar mostre o `install:`, opt-in, respeite `platform:`; ex. `agent-browser` p/ verificação de browser — nunca Playwright). Os exemplos abaixo são atalho legível; o registry é a verdade e pega o que for adicionado depois.
 - Rodar a suíte de testes e reportar o que passou/falhou → executo os testes do projeto e resumo.
 - Gerar testes E2E e rodar fluxos críticos → `e2e-runner` (ou `wizz-qa-generate-e2e-tests`).
 - Revisão adversarial caçando bugs (assumir que tem bug) → `adversarial-reviewer`.

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

@@ -20,7 +20,7 @@ Você é o SEO do Wizz. Audita, prioriza e otimiza para Google e para buscas de
 
 ## Como trabalho (ponte global)
 
-> **Fonte única (registry) — leia SEMPRE antes dos exemplos abaixo:** a lista real da sua área (`seo`) vive no `skills-registry.yaml` (resolva em `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml`). Ache o bloco `areas.seo` e ofereça **tudo que casar** com o pedido pelo `when:` — `skills:` (via `Skill`), `clis:` (`check:` → se faltar mostre o `install:`, opt-in, respeite `platform:`) e `mcps:` (`claude mcp add <id>` com o bloco `server`). Os exemplos abaixo são atalho legível; o registry é a verdade e pega novidades automático (ex. `distribb`).
+> **Fonte única (registry) — leia SEMPRE antes dos exemplos abaixo:** a lista real da sua área (`seo`) vive no `skills-registry.yaml`. Resolva primeiro a **fatia leve da sua área**, `{project-root}/_wizz/_config/registry/seo.yaml` (já vem como o bloco `areas.seo` completo); se faltar (install antigo), caia pro monólito na ordem `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml` e ache o bloco `areas.seo` lá dentro. Precisando de algo cross-cutting (utility/mcp_utility/cli_utility/squads), leia `{project-root}/_wizz/_config/registry/_shared.yaml`. Ofereça **tudo que casar** com o pedido pelo `when:` — `skills:` (via `Skill`), `clis:` (`check:` → se faltar mostre o `install:`, opt-in, respeite `platform:`) e `mcps:` (`claude mcp add <id>` com o bloco `server`). Os exemplos abaixo são atalho legível; o registry é a verdade e pega novidades automático (ex. `distribb`).
 - Auditoria, por que não ranqueia, problemas técnicos → `seo-audit`
 - Aparecer em ChatGPT/Perplexity/AI Overviews → `ai-seo`
 - Dados estruturados / rich results → `schema-markup`

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

@@ -43,7 +43,7 @@ Opcionais (quando o tema pedir): **Novidade** (recém lançado? define Fórmula
 
 ## Como trabalho (ponte global)
 
-> **Fonte única (registry) · leia SEMPRE antes dos exemplos abaixo:** a lista real da sua área (`social`) vive no `skills-registry.yaml` (resolva em `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml`). Ache o bloco `areas.social` e ofereça **tudo que casar** com o pedido pelo `when:`. `skills:` (via `Skill`), `clis:` (rode o `check:`; se faltar mostre o `install:`, opt-in; respeite `platform:`, ex. `buttercut` é só `darwin-arm64`) e `mcps:`. Os exemplos abaixo são atalho legível; o registry é a verdade e pega o que for adicionado depois.
+> **Fonte única (registry) · leia SEMPRE antes dos exemplos abaixo:** a lista real da sua área (`social`) vive no `skills-registry.yaml`. Resolva primeiro a **fatia leve da sua área**, `{project-root}/_wizz/_config/registry/social.yaml` (já vem como o bloco `areas.social` completo); se faltar (install antigo), caia pro monólito na ordem `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml` e ache o bloco `areas.social` lá dentro. Ofereça **tudo que casar** com o pedido pelo `when:`. `skills:` (via `Skill`), `clis:` (rode o `check:`; se faltar mostre o `install:`, opt-in; respeite `platform:`, ex. `buttercut` é só `darwin-arm64`) e `mcps:`. As CLIs de vídeo (hyperframes, claude-video, buttercut, voicebox) pertencem à área `designer`; leia `{project-root}/_wizz/_config/registry/designer.yaml` (ou `_shared.yaml` para utility/mcp_utility/cli_utility/squads cross-cutting) pra pegar o bloco delas. Os exemplos abaixo são atalho legível; o registry é a verdade e pega o que for adicionado depois.
 
 Roteiro e conteúdo (você mesmo, com o blueprint + skills):
 - Roteiro viral de Reel/Short, qualquer formato (hook, corpo, CTA) → aplique o blueprint (Seções 1-11; Seção 12 para o formato 3D-personagem).

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

@@ -13,18 +13,18 @@ description: >
 
 ### Senhas
 - Hash com bcrypt (custo >= 12), Argon2id ou scrypt. Nunca MD5/SHA1 para senhas
-- Minimum 8 caracteres, sem restrição de caracteres especiais
+- Mínimo de 8 caracteres, sem restrição de caracteres especiais
 - Implemente bloqueio após N tentativas (lockout ou CAPTCHA)
-- Oferece 2FA: TOTP (Google Authenticator) é o padrão mínimo
+- Ofereça 2FA: TOTP (Google Authenticator) é o padrão mínimo
 
 ### JWT
-- Assine sempre com RS256 (assimétrico) em produção, nunca HS256 com secret fraco
+- 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)
-- Blacklist de tokens invalidados: Redis com TTL igual ao exp do token
 - **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) e invalide o refresh token. Sem isso o access token continua válido depois do logout até expirar sozinho
+- **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).
@@ -40,9 +40,10 @@ Evita que um atacante descubra quais e-mails existem na base (login, signup, res
 
 ### Stack Supabase + Clerk
 - Auth gerenciada pelo Clerk: nunca reimplementar flows de auth manualmente
-- Clerk webhook (`svix`) verificado por assinatura antes de processar — não confiar no body sem verificar
+- 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
 - Supabase RLS: toda tabela de domínio deve ter RLS ativo; queries devem filtrar por `workspace_id`/`user_id`
-- `SUPABASE_SERVICE_ROLE_KEY` só usada em server-side (API routes, never client), nunca exposta no frontend
+- `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
@@ -56,19 +57,36 @@ Evita que um atacante descubra quais e-mails existem na base (login, signup, res
 ### 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`
+- 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):
 ```ts
-// src/lib/crypto.ts — ler chave do env, nunca hardcodar
-const key = process.env.CREDENTIAL_ENCRYPTION_KEY
+// src/lib/crypto.ts: chave vem do env, nunca hardcodada
+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")
-// AES-256-GCM: chave base64 de 32 bytes
+
+export function encrypt(plain: string) {
+  const iv = randomBytes(12) // IV aleatório por registro, nunca reutilizar
+  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
 ```
 
 ### 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
 

package/src/skills-lib/desktop-security/SKILL.md

@@ -15,11 +15,32 @@ description: >
 - contextIsolation: true (obrigatório)
 - sandbox: true quando possível
 - webSecurity: false nunca em produção
+- Nunca carregue conteúdo remoto numa janela com acesso a APIs privilegiadas; conteúdo remoto = sandbox + sem preload sensível
+- Mantenha o Electron atualizado (patches de Chromium/Node chegam por release do Electron)
+
+### Navegação e janelas
+- Bloqueie navegação para fora do app: handler em `will-navigate` que cancela URLs fora da allowlist
+- `setWindowOpenHandler`: negue por padrão (`{ action: "deny" }`), abra externo só o que for aprovado
+- `shell.openExternal` só com URL validada (esquema `https:` e host esperado), nunca com input cru do renderer
 
 ### IPC (comunicação renderer <> main)
-- Valide e sanitize todos os dados vindos do renderer
-- Exponha apenas as funções necessárias via contextBridge
+- Valide e sanitize todos os dados vindos do renderer (o renderer é território hostil: trate como input de usuário)
+- Exponha apenas as funções necessárias via contextBridge, cada uma com assinatura fixa
 - Nunca exponha ipcRenderer diretamente ao renderer
+- Em `ipcMain.handle`, valide tipo e tamanho dos argumentos; se houver múltiplas janelas, cheque `event.senderFrame.url` contra o esperado
+
+```ts
+// preload.ts: superfície mínima, sem repassar ipcRenderer
+contextBridge.exposeInMainWorld("api", {
+  saveNote: (text: string) => ipcRenderer.invoke("notes:save", text),
+})
+
+// main.ts: valida antes de agir
+ipcMain.handle("notes:save", (event, text) => {
+  if (typeof text !== "string" || text.length > 10_000) throw new Error("input inválido")
+  // ...
+})
+```
 
 ### Atualizações automáticas
 - Assine o pacote de atualização com certificado de código (code signing)
@@ -29,8 +50,9 @@ description: >
 ## Armazenamento local
 
 ### O que armazenar localmente
-- Tokens de sessão: keychain do OS (electron-keytar), nunca localStorage
-- Dados do usuário: criptografados com chave derivada da senha do OS
+- Tokens de sessão: `safeStorage` do Electron (usa Keychain no macOS, DPAPI no Windows, libsecret no Linux), nunca localStorage
+  - `safeStorage.encryptString(token)` antes de gravar em disco; `keytar` está arquivado, não use em projeto novo
+- Dados sensíveis do usuário: criptografados via `safeStorage` ou AES-256-GCM com chave guardada no keychain do OS
 
 ### O que nunca armazenar localmente
 - Senhas em texto plano
@@ -41,3 +63,12 @@ description: >
 - Code signing obrigatório (Windows: Authenticode, macOS: Apple Developer ID)
 - Notarização no macOS para distribuição fora da App Store
 - Auto-update com verificação de integridade antes de executar
+
+## Checklist rápido (antes de empacotar)
+- [ ] `contextIsolation: true`, `nodeIntegration: false`, `sandbox: true` onde possível?
+- [ ] Nenhuma janela privilegiada carrega URL remota?
+- [ ] `will-navigate` e `setWindowOpenHandler` restringem navegação?
+- [ ] Todo handler de `ipcMain` valida os argumentos?
+- [ ] Tokens em `safeStorage`/keychain, nada sensível em localStorage?
+- [ ] Build assinado (e notarizado no macOS)? Auto-update valida assinatura?
+- [ ] Versão do Electron atual (sem CVE aberta)?