@fontdata/ai-harness 2.0.0

package/templates/commands/validar-commands.md

@@ -0,0 +1,24 @@
+---
+description: Audita a pasta .claude — valida os modelos dos agents, aponta commands redundantes/pouco úteis e sugere novos commands úteis.
+---
+
+# Auditoria do harness (.claude)
+
+Analise a pasta `.claude` do projeto (commands, agents, skills, rules, hooks) e produza uma auditoria em três frentes. **Explique o motivo** de cada avaliação — nada de veredito sem justificativa.
+
+## 1. Agents — modelo adequado
+
+Para cada agent, diga se o **model** escolhido (Haiku/Sonnet/Opus) está correto para o trabalho dele. Aponte **sub** ou **superdimensionamento** (ex.: Opus para uma task mecânica, Haiku para arquitetura) e recomende o ajuste.
+
+## 2. Commands — uso e redundância
+
+- Diga quais slash commands tendem a ser **mais usados** neste projeto e quais são **pouco úteis** no contexto dele.
+- Aponte **sobreposições de escopo** entre comandos — candidatos a remoção ou fusão.
+
+## 3. Novos commands sugeridos
+
+Sugira **novos slash commands** úteis para este projeto específico. Para cada um: o que faria, quando seria usado e qual **dor recorrente** ele eliminaria.
+
+## Fechamento
+
+Consolide tudo em quatro listas — **manter / ajustar / remover / criar** — e **pergunte o que devo aplicar** antes de mexer em qualquer arquivo.

package/templates/commands/validar-ideia.md

@@ -0,0 +1,36 @@
+---
+description: Valida se a ideia do projeto cabe na janela de tempo com multi-agents (entrevista + diagnóstico honesto + veredito acionável).
+---
+
+# Validação de ideia de projeto
+
+Você é um **arquiteto de software sênior**, especialista em dimensionar escopo de projetos construídos com Claude Code e orquestração de multi-agents. Sua função é dar um diagnóstico **honesto e acionável** sobre se a ideia abaixo cabe na janela de tempo disponível — sem otimismo de wishful thinking. Prefira errar para o lado pessimista.
+
+## Contexto
+
+- **Ideia:** $ARGUMENTS
+- **Janela de tempo:** se eu não informei explicitamente em `$ARGUMENTS`, assuma **~4 horas** (formato imersão) e **diga que assumiu isso**.
+- **Modo de execução:** TDD obrigatório + sub-agents especializados implementando módulos independentes em paralelo (o harness deste projeto).
+
+Se eu **não descrevi a ideia** ou descrevi de forma vaga demais para avaliar, **pare e faça as perguntas mínimas** necessárias — uma pergunta por vez — antes de qualquer avaliação. Não avalie no escuro.
+
+## Como avaliar
+
+Percorra os critérios abaixo. Para cada um, dê um veredito curto com a **evidência ou o risco concreto** — nada de respostas genéricas.
+
+1. **Decomposição em módulos** — Quebre a ideia em 2 a 4 módulos que agents separados implementariam de forma **genuinamente independente** (não tocam os mesmos arquivos, não dependem um do outro para começar). Se não der para quebrar assim, isso já é um sinal de alerta sobre o escopo.
+2. **Fatia vertical entregável** — Descreva o menor caminho ponta-a-ponta que estaria **funcionando** ao fim da janela, mesmo que simples ou feio. Se não existe uma fatia demonstrável, o escopo está errado.
+3. **Complexidade oculta / risco de explosão** — Aponte dependências que costumam estourar o tempo: autenticação de terceiros, pagamentos, uploads, real-time/websockets, integrações externas, processamento pesado, mobile nativo, infra/deploy. Para cada uma presente, diga como **cortar, mockar ou adiar** no dia.
+4. **Stack** — A stack está clara e é dominada? Se precisa ser decidida antes de começar, sinalize como pré-requisito bloqueante.
+5. **Testabilidade (TDD)** — Para pelo menos 2 módulos, quais seriam os **testes críticos** (um de input válido + um de caso de erro) escritos ANTES do código? Se o comportamento essencial é difícil de testar, explique por quê.
+6. **Estimativa realista** — Dê uma estimativa grosseira de esforço por módulo, some e compare com a janela. Seja pessimista onde houver incerteza.
+
+## Veredito
+
+Feche com **um** dos três, justificando em até 3 linhas com base na análise acima:
+
+- ✅ **APROVADO** — cabe na janela. Pode seguir para `/gerar-spec`. Liste em 1 linha os módulos e a fatia vertical alvo.
+- ✂️ **AJUSTAR** — boa ideia, grande demais. **Reescreva a ideia já recortada em 2–3 frases**, preservando a essência e o "uau", pronta para virar SPEC. Diga explicitamente o que ficou de fora (backlog para depois).
+- ❌ **REPROVAR** — inviável mesmo recortada na janela dada. Explique o porquê e **proponha uma ideia alternativa no mesmo domínio** que caiba, mantendo a mesma estrutura de módulos.
+
+Responda em português do Brasil.

package/templates/commands/versao.md

@@ -0,0 +1,159 @@
+---
+description: Detecta como o versionamento funciona no projeto atual (qualquer stack) e aplica o bump de versão + changelog, com gate de aprovação. Para antes do push.
+argument-hint: "[X.Y.Z | major | minor | patch | build]"
+---
+
+# /versao — Bump de versão (agnóstico de stack)
+
+Você é o **orquestrador de release** deste projeto. Sua tarefa é **descobrir como o versionamento já
+funciona aqui** (React+Vite, React+Next, Node, Delphi, .NET, Flutter, etc.) e **replicar exatamente esse
+padrão** ao aplicar o novo bump. Não imponha um formato seu: o projeto manda.
+
+> **🚦 Há um GATE de aprovação obrigatório** antes de qualquer escrita. **PARE antes de `git push`** —
+> push é sempre ação manual do usuário.
+
+## Uso
+
+- `/versao` — **infere** a próxima versão pelos commits (regra SemVer abaixo) ou pelo padrão do projeto.
+- `/versao X.Y.Z` — usa a versão explícita como **override** (único caminho que permite subir `major`).
+- `/versao major|minor|patch|build` — incrementa o segmento indicado, respeitando o **número de segmentos**
+  que o projeto usa (3 segmentos `X.Y.Z` ou 4 segmentos `X.Y.Z.W`, comum em Delphi/.NET).
+
+## Passo 0 — Pré-checagem (abortar se falhar)
+
+1. **Working tree limpo:** rode `git status --short`. Se houver saída → **abortar** e instruir a
+   commitar/limpar antes (sugerir `/git-commit-push`). Não bumpar com árvore suja.
+2. **Base (última versão registrada):** `git describe --tags --abbrev=0 --match "v*"`. Se não houver tag,
+   use o primeiro commit (`git rev-list --max-parents=0 HEAD`) como base e avise que é o primeiro release.
+
+## Passo 1 — Detectar o mecanismo de versionamento (somente leitura)
+
+Investigue o projeto e **identifique TODAS as fontes de verdade da versão**. Não assuma; confirme lendo.
+Possíveis fontes, por stack:
+
+- **Node / React+Vite / React+Next / qualquer JS-TS:** campo `version` em `package.json` (e
+  `package-lock.json`/`pnpm-lock.yaml`/`yarn.lock` se contiverem a versão do pacote raiz).
+- **Delphi:** `*.dproj` (chaves `VerInfo_Keys`, `FileVersion`/`ProductVersion` e os campos
+  `MajorVersion/MinorVersion/Release/Build`) **e** constantes de versão em `.pas` (ex.: `About*`,
+  `BibVariavel`). Liste cada `arquivo:linha`.
+- **.NET / C#:** `*.csproj` (`<Version>`, `<AssemblyVersion>`, `<FileVersion>`), `AssemblyInfo.cs`,
+  `Directory.Build.props`.
+- **Flutter / Dart:** campo `version:` do `pubspec.yaml`.
+- **Python:** `pyproject.toml` (`[project] version` ou `[tool.poetry] version`), `setup.py`,
+  `__version__` em `__init__.py`.
+- **Outras:** procure por arquivos `VERSION`, constantes `VERSION`/`APP_VERSION`, badges no README.
+
+Use `grep`/busca para encontrar **toda ocorrência** do número de versão atual, garantindo que nenhuma
+fique para trás. Determine também:
+
+- O **formato/número de segmentos** vigente (`X.Y.Z` ou `X.Y.Z.W`, com ou sem zero à esquerda).
+- Onde mora o **changelog**, replicando o que existir:
+  - `CHANGELOG.md` (formato Keep a Changelog ou similar);
+  - arquivos de "Novidades" consumidos pela UI (ex.: `src/data/novidades.ts`);
+  - arquivos texto de histórico (ex.: `Versoes.txt` na raiz, com padrão de espaçamento/formatação próprio).
+- Se há **automação de tag** (ex.: `.github/workflows/auto-tag.yml` que cria a tag na `main`). Se houver,
+  **NÃO crie a tag** — apenas commite; a Action cria a tag quando o commit chega na branch alvo.
+- O **gerenciador de pacotes / runner de testes** do projeto (npm/pnpm/yarn, `dotnet`, etc.), lendo
+  `package.json` scripts ou os manifestos.
+
+> Se não encontrar nenhuma fonte de versão, **pergunte ao usuário** onde a versão deve ser registrada
+> antes de prosseguir.
+
+## Passo 2 — Levantar commits e calcular a nova versão
+
+- `git log <base>..HEAD --pretty=format:%H%x09%s`. Liste ao usuário os commits considerados (título +
+  tipo semântico) e a base usada.
+- **Se veio versão explícita `X.Y.Z`:** assuma exatamente ela (override total).
+- **Se veio um tipo (`major|minor|patch|build`):** incremente esse segmento e zere os à direita,
+  respeitando o número de segmentos do projeto.
+- **Senão, infira por SemVer** (precedência minor > patch, com reset em cascata):
+  1. Algum `feat:` → **minor**: `Y = Y + 1`, demais à direita = `0`.
+  2. Senão, algum `fix:`/`chore:`/`refactor:`/`docs:`/`style:`/`perf:`/`test:` → **patch**.
+  3. Senão → sem bump elegível: avise e **peça confirmação** (abortar ou versão explícita).
+- **`major` é SEMPRE manual** — só sobe quando o usuário passa `X.Y.Z` explícito ou `major`. A inferência
+  jamais sobe major.
+
+## Passo 3 — Gerar o changelog (no padrão do projeto)
+
+Este comando é **autossuficiente**: gere aqui mesmo o changelog **amigável ao usuário final** (pt-BR,
+sem hash/arquivo/jargão) a partir dos commits do intervalo **`<base>..HEAD`** (a base do Passo 0), sem
+depender de nenhuma skill ou comando externo. Quem grava os artefatos é o Passo 5.
+
+**3.1 — Leia os commits.** Use os commits já levantados no Passo 2 (`git log <base>..HEAD`); leia o corpo
+quando precisar de contexto para entender o que a mudança entrega.
+
+**3.2 — Categorize (modo compacto, 3 categorias).** Agrupe mapeando os prefixos semânticos:
+
+- **✨ Novidades** — `feat:`
+- **🐛 Correções** — `fix:`
+- **⚡ Melhorias** — `perf:`/`refactor:`/`chore:`/`style:`/`docs:`/`test:`/`build:`/`ci:`
+
+Mantenha **⚠️ Mudanças importantes** (`BREAKING CHANGE`/`!:` — destaque o que o usuário precisa fazer) e
+**🔒 Segurança** como blocos próprios **só se houver itens**. Commits sem prefixo: classifique pelo
+conteúdo da mensagem. Inclua apenas as seções que tiverem itens.
+
+**3.3 — Traduza técnico → usuário final.** Para cada item que vai aparecer:
+
+- Reescreva em **linguagem clara e não técnica**, focando no **benefício para quem usa o produto**, não na
+  implementação. Quando fizer sentido, use **negrito com o nome do recurso + frase do ganho**
+  (ex.: `**Sincronização mais rápida**: arquivos sincronizam 2x mais rápido entre dispositivos`).
+- **Filtre o ruído**: descarte merges, bumps triviais de versão, ajustes de lint/formatação e commits
+  puramente internos sem impacto perceptível. O bloco "Melhorias" deve ser um resumo curto, não um
+  despejo de commits. Ignore `docs:`/`chore:` puramente internos quando o projeto assim fizer no histórico.
+- Não invente recursos que os commits não suportam; em dúvida, descreva de forma conservadora.
+- **Sem emoji dentro dos itens** — os emojis ficam apenas nos títulos das seções.
+
+**3.4 — Siga o estilo do projeto.** Se existir um `CHANGELOG_STYLE.md` na raiz, **siga as diretrizes dele**
+(tom, formato, seções). De todo modo, **replique o formato existente** do arquivo de changelog/novidades/
+`Versoes.txt` do projeto (espaçamento, cabeçalho, formato do número de versão). Não introduza um formato
+novo — o Passo 5 é quem grava, seguindo exatamente esse padrão.
+
+## Passo 4 — 🚦 GATE de aprovação (obrigatório)
+
+Apresente ao usuário, **antes de escrever qualquer coisa**:
+
+- versão atual → nova versão;
+- a lista completa de **arquivos:linha** que serão alterados (todas as ocorrências do Passo 1);
+- o changelog proposto e **o bloco exato** que será anexado a cada arquivo de histórico.
+
+**Peça aprovação explícita.** Não grave nada sem o "ok". Se o bump tocar arquivos sensíveis (ex.: `.dproj`,
+`.csproj`), destaque o risco.
+
+## Passo 5 — Aplicar artefatos (somente após aprovação)
+
+- Atualize **todas** as ocorrências da versão de forma **consistente** (todas as fontes do Passo 1).
+- Atualize o(s) arquivo(s) de changelog/novidades seguindo **exatamente o padrão existente**:
+  - `CHANGELOG.md`: nova seção `## [X.Y.Z] - <currentDate>` no topo (após o cabeçalho); crie com cabeçalho
+    se não existir.
+  - Arquivo de novidades da UI (se houver): adicione o release no topo do array, no mesmo tipo/formato já
+    usado (datas no formato local do arquivo).
+  - `Versoes.txt`/histórico texto (se houver): anexe ao final, com o **mesmo espaçamento** entre blocos e o
+    **mesmo formato de número** (inclusive zeros à esquerda) das entradas existentes.
+- Use a data de `currentDate`; **nunca invente data**.
+
+## Passo 6 — Validar (abortar se vermelho)
+
+- Rode os testes do projeto (ex.: `pnpm test`/`npm test`/`dotnet test`). Se fizer sentido para o escopo do
+  release, rode também o build (`pnpm build`/`npm run build`/`dotnet build`).
+- Se algo falhar → **abortar** sem commitar e reportar o erro.
+
+## Passo 7 — Finalizar (somente commit — SEM push)
+
+1. Estagie **apenas** os arquivos do release (nunca `git add -A`): liste explicitamente os arquivos
+   alterados nos passos anteriores.
+2. Commit semântico (1ª letra maiúscula após `: `): `chore: Release vX.Y.Z` (ou, em projetos Delphi que já
+   usem o padrão, `build: Modificada versão do sistema no projeto`). Finalize com a linha
+   `Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>`.
+3. **Tag:** se existir automação de tag (Action na `main`), **NÃO crie a tag** — informe que ela será criada
+   automaticamente quando o commit chegar na branch alvo. Caso contrário, e somente se o usuário pedir,
+   ofereça criar a tag `v<X.Y.Z>` localmente.
+4. **PARE. Nunca `git push`.** Informe o fluxo manual de push ao usuário.
+
+## Guardrails
+
+- **NUNCA** `git push`. Não criar tag se houver automação que já faça isso.
+- **Sempre** confirmar versão + changelog no GATE antes de gravar.
+- **Abortar** se a working tree estiver suja ou se os testes/build falharem.
+- **Replicar o padrão do projeto** (formato de versão, changelog, commit) — nunca impor um novo.
+- `major` só por argumento explícito; a inferência jamais sobe major.
+- Changelog em **pt-BR**, voltado ao usuário final; usar a data de `currentDate`.

package/templates/skills/lgpd-checker/ORIGEM.md

@@ -0,0 +1,21 @@
+# Origem desta skill
+
+A skill `lgpd-checker` foi obtida do projeto público
+[bittencourtthulio/lgpd-checker](https://github.com/bittencourtthulio/lgpd-checker)
+e é redistribuída aqui como vendor (cópia versionada), sem alterações no conteúdo de
+`SKILL.md` nem de `references/`. Créditos ao autor original.
+
+Arquivos vendorizados:
+
+- `SKILL.md` — instruções da skill (11 categorias de análise LGPD).
+- `references/checklist.md` — checklist completo de verificações por categoria.
+- `references/lgpd-artigos.md` — artigos da Lei nº 13.709/2018 usados como referência.
+- `references/report-template.md` — template do relatório de conformidade.
+
+## Como atualizar
+
+Rebaixe os quatro arquivos do repositório de origem (branch `main`) para
+`templates/skills/lgpd-checker/`, mantendo a estrutura de pastas. Não edite os
+arquivos vendorizados: ajustes específicos do harness (onde gravar o relatório,
+integração com `/auditar-seguranca`) ficam no próprio comando, em
+`templates/commands/auditar-seguranca.md`.

package/templates/skills/lgpd-checker/SKILL.md

@@ -0,0 +1,152 @@
+---
+name: lgpd-checker
+description: >
+  Analisa um projeto de software em busca de falhas de conformidade com a LGPD (Lei Geral de Proteção de Dados — Lei nº 13.709/2018) e gera um relatório detalhado classificando os problemas encontrados por categoria e severidade. Use este skill SEMPRE que o usuário mencionar LGPD, proteção de dados, privacidade, compliance de dados pessoais, adequação à lei de privacidade brasileira, verificação de privacidade em código, auditoria de dados pessoais, ou quando perguntar se o sistema está em conformidade com a lei brasileira de dados. Também acione este skill quando o usuário quiser revisar código em busca de problemas relacionados a: coleta de consentimento, criptografia de dados pessoais, direitos dos titulares, logs de acesso, retenção de dados, ou política de privacidade.
+---
+
+# LGPD Checker — Skill de Análise de Conformidade
+
+Você é um especialista em LGPD (Lei nº 13.709/2018) com profundo conhecimento técnico de desenvolvimento de software. Sua missão é analisar o projeto do desenvolvedor, identificar lacunas de conformidade e entregar um relatório acionável com recomendações concretas.
+
+## Fase 1 — Reconhecimento do Projeto
+
+Antes de qualquer análise, mapeie o projeto respondendo a estas perguntas internamente:
+
+1. **Tipo de aplicação**: Web? Mobile? API? Backend? Desktop? SaaS?
+2. **Stack tecnológica**: Qual linguagem, framework, banco de dados?
+3. **Escopo de dados**: O sistema coleta, armazena ou processa dados pessoais de pessoas físicas?
+
+Para fazer esse mapeamento, explore os arquivos do projeto:
+- Leia `README.md`, `package.json` / `requirements.txt` / `pom.xml` / `Gemfile` (ou equivalente) para entender a stack
+- Explore os diretórios principais (`src/`, `app/`, `api/`, `models/`, `controllers/`, `routes/`, etc.)
+- Identifique arquivos relacionados a: autenticação, banco de dados, formulários, APIs, configurações de segurança
+
+Se o projeto não coletar dados pessoais de pessoas físicas, informe o usuário e encerre a análise com justificativa clara.
+
+## Fase 2 — Análise por Categorias LGPD
+
+Para cada categoria abaixo, realize uma **busca ativa** no código antes de concluir. Não assuma conformidade sem verificar. Leia `references/checklist.md` para a lista completa de verificações.
+
+### CAT-1: Bases Legais e Consentimento (Art. 7, 8, 9, 10)
+Busque por:
+- Formulários de cadastro, login, checkout, newsletter
+- Campos de checkbox/opt-in/opt-out
+- Strings como "consent", "agreement", "aceito", "concordo", "termos"
+- Mecanismo de revogação de consentimento
+- Registro da data/hora e versão do consentimento dado
+- Finalidade da coleta declarada ao usuário
+
+### CAT-2: Minimização de Dados (Art. 6, III)
+Busque por:
+- Models/schemas/entidades de banco de dados — liste todos os campos
+- Campos marcados como "required" em formulários
+- Dados coletados mas não utilizados em nenhuma lógica de negócio
+- Campos como `birth_date`, `cpf`, `rg`, `address`, `phone` sem justificativa de uso
+
+### CAT-3: Dados Pessoais Sensíveis (Art. 5, II; Art. 11)
+Busque por nomes de campos, variáveis e comentários que indiquem:
+- Origem racial ou étnica
+- Convicção religiosa ou política
+- Dados de saúde, prontuários, diagnósticos
+- Orientação sexual
+- Dados biométricos (fingerprint, face_id, iris)
+- Dados genéticos
+- Filiação sindical
+
+### CAT-4: Segurança Técnica (Art. 46, 47, 48)
+Busque por:
+- Configurações de HTTPS/TLS (arquivos de configuração de servidor, `.env`, nginx/apache configs)
+- Criptografia de senhas: uso de bcrypt, argon2, scrypt (NÃO MD5, SHA1 puro, ou texto claro)
+- Criptografia em repouso para campos sensíveis
+- Variáveis de ambiente para credenciais (não hardcoded no código)
+- Tokens JWT: verificação de assinatura, expiração
+- Proteção contra SQL Injection (queries parametrizadas vs. concatenação de strings)
+- Rate limiting e proteção contra força bruta
+- Headers de segurança HTTP (CORS, CSP, HSTS, etc.)
+
+### CAT-5: Logs e Auditoria (Art. 37)
+Busque por:
+- Sistema de logging no projeto
+- Se logs registram acesso/modificação de dados pessoais
+- Se logs NÃO expõem dados pessoais em texto claro (senha, CPF, cartão)
+- Retenção e rotação de logs
+
+### CAT-6: Direitos dos Titulares (Art. 18)
+Busque por endpoints, funções ou telas que implementem:
+- **Acesso**: usuário pode ver todos os dados que possui no sistema
+- **Correção**: usuário pode editar/corrigir seus dados
+- **Eliminação**: usuário pode excluir sua conta e dados (Art. 18, VI)
+- **Portabilidade**: exportação dos dados em formato estruturado (JSON/CSV)
+- **Revogação**: cancelamento de consentimento
+- **Oposição**: opt-out de processamento
+
+### CAT-7: Retenção e Eliminação de Dados (Art. 15, 16)
+Busque por:
+- Política de retenção (documentação ou configuração no código)
+- Jobs/tasks de limpeza automática de dados expirados
+- Soft delete vs. hard delete — dados de usuários excluídos ainda existem?
+- Backups: política de retenção de backups com dados pessoais
+- Prazo de retenção definido e documentado
+
+### CAT-8: Privacy by Design (Art. 46, §2)
+Busque por:
+- Anonimização ou pseudonimização de dados onde possível
+- Dados pessoais em URLs (ex.: `/users/joao.silva@email.com`)
+- Dados pessoais em logs de erro ou stack traces
+- Campos de identificação em analytics/telemetria
+- Configurações de privacidade como padrão mais restritivo
+
+### CAT-9: Transferência Internacional (Art. 33–36)
+Busque por:
+- Integrações com serviços externos (AWS, Google, Stripe, SendGrid, etc.)
+- Configurações de região/localização de dados
+- Contratos ou configurações com cloud providers fora do Brasil
+- Compartilhamento de dados com terceiros
+
+### CAT-10: Documentação e Governança (Art. 37, 38, 41)
+Busque por:
+- Arquivo de Política de Privacidade (privacy policy)
+- Registro de Atividades de Tratamento (RAT/ROPA)
+- Identificação do DPO/Encarregado de Dados (contato)
+- RIPD (Relatório de Impacto à Proteção de Dados) para operações de alto risco
+- Documentação de bases legais para cada operação de tratamento
+
+### CAT-11: Notificação de Incidentes (Art. 48)
+Busque por:
+- Processo documentado para resposta a incidentes de segurança
+- Mecanismo de detecção de vazamentos (alertas, monitoramento)
+- Contato/canal para reporte de incidentes
+
+## Fase 3 — Geração do Relatório
+
+Após a análise, gere o relatório seguindo o template abaixo. Seja específico: cite arquivos, linhas de código e funções encontradas. Evite afirmações genéricas.
+
+Leia `references/report-template.md` para o template completo.
+
+### Regras de Severidade
+
+Classifique cada problema encontrado em:
+
+| Severidade | Critério | Símbolo |
+|---|---|---|
+| **CRÍTICO** | Violação direta da lei, multa potencial, risco de vazamento imediato | 🔴 |
+| **ALTO** | Lacuna significativa, risco elevado de não-conformidade | 🟠 |
+| **MÉDIO** | Boa prática ausente, conformidade parcial | 🟡 |
+| **BAIXO** | Melhoria recomendada, impacto menor | 🟢 |
+| **INFO** | Observação, sem impacto direto na conformidade | ℹ️ |
+
+### Regras de conclusão de conformidade
+
+No cabeçalho do relatório, classifique o projeto como:
+- ✅ **CONFORME** — Nenhum item CRÍTICO ou ALTO encontrado
+- ⚠️ **PARCIALMENTE CONFORME** — Itens MÉDIO ou BAIXO encontrados, nenhum CRÍTICO/ALTO
+- ❌ **NÃO CONFORME** — Um ou mais itens CRÍTICO ou ALTO encontrados
+
+## Instruções Gerais
+
+- Sempre citar o artigo da LGPD relevante para cada achado.
+- Sempre fornecer uma recomendação técnica concreta e acionável (não apenas "implemente segurança melhor").
+- Se não encontrar código suficiente para avaliar uma categoria, diga explicitamente: "Não foi possível avaliar [CAT-X] — arquivos de [tipo] não encontrados."
+- Quando encontrar algo correto e conforme, registre como ponto positivo.
+- Priorize os itens CRÍTICOS no início do relatório para que o desenvolvedor saiba o que atacar primeiro.
+- Ao final, forneça um Plano de Ação em ordem de prioridade.

package/templates/skills/lgpd-checker/references/checklist.md

@@ -0,0 +1,155 @@
+# Checklist LGPD — Verificações por Categoria
+
+Use este checklist durante a análise do projeto. Para cada item, determine: ✅ Conforme | ❌ Não conforme | ⚠️ Parcial | 🔍 Não encontrado/Não avaliado
+
+---
+
+## CAT-1: Bases Legais e Consentimento (Art. 7, 8, 9, 10)
+
+| # | Verificação | Severidade | Artigo |
+|---|---|---|---|
+| 1.1 | Existe uma base legal definida para cada operação de tratamento de dados | CRÍTICO | Art. 7 |
+| 1.2 | Quando a base é consentimento, ele é coletado de forma **explícita** (opt-in ativo) | CRÍTICO | Art. 8 |
+| 1.3 | O consentimento é **específico por finalidade** (não genérico/agrupado) | ALTO | Art. 8, §4 |
+| 1.4 | A **finalidade** do tratamento é informada ao usuário no momento da coleta | ALTO | Art. 9 |
+| 1.5 | Existe mecanismo para o usuário **revogar o consentimento** a qualquer momento | ALTO | Art. 8, §5 |
+| 1.6 | A **data, hora e versão** do consentimento são registradas com o dado | MÉDIO | Art. 8, §2 |
+| 1.7 | O consentimento de **menores de 16 anos** exige confirmação dos pais/responsáveis | CRÍTICO | Art. 14 |
+| 1.8 | Não há pré-marcação de checkboxes de consentimento | ALTO | Art. 8 |
+| 1.9 | O controlador (empresa) está identificado nos formulários de coleta | MÉDIO | Art. 9 |
+
+---
+
+## CAT-2: Minimização de Dados (Art. 6, III)
+
+| # | Verificação | Severidade | Artigo |
+|---|---|---|---|
+| 2.1 | Somente dados estritamente necessários para a finalidade são coletados | ALTO | Art. 6, III |
+| 2.2 | Campos opcionais estão claramente marcados como opcionais nos formulários | MÉDIO | Art. 6, III |
+| 2.3 | Não há campos coletados mas nunca utilizados na lógica de negócio | MÉDIO | Art. 6, III |
+| 2.4 | A coleta de dados pessoais em APIs é proporcional ao objetivo do endpoint | MÉDIO | Art. 6, III |
+| 2.5 | Campos sensíveis (CPF, RG, etc.) são solicitados apenas quando realmente necessários | ALTO | Art. 6, III |
+
+---
+
+## CAT-3: Dados Pessoais Sensíveis (Art. 5, II; Art. 11)
+
+| # | Verificação | Severidade | Artigo |
+|---|---|---|---|
+| 3.1 | Dados sensíveis são identificados e explicitamente marcados no sistema | ALTO | Art. 5, II |
+| 3.2 | O consentimento para dados sensíveis é **específico e destacado** (separado do geral) | CRÍTICO | Art. 11, I |
+| 3.3 | Dados biométricos (foto de rosto, digital) têm tratamento especial de segurança | CRÍTICO | Art. 11 |
+| 3.4 | Dados de saúde só são tratados quando há base legal específica | CRÍTICO | Art. 11 |
+| 3.5 | Não há tratamento de dados sensíveis para fins de discriminação | CRÍTICO | Art. 11, §1 |
+| 3.6 | O acesso a dados sensíveis é mais restrito que dados pessoais comuns | ALTO | Art. 46 |
+
+---
+
+## CAT-4: Segurança Técnica (Art. 46, 47, 48)
+
+| # | Verificação | Severidade | Artigo |
+|---|---|---|---|
+| 4.1 | Todas as conexões usam **HTTPS/TLS** (nenhum endpoint HTTP em produção) | CRÍTICO | Art. 46 |
+| 4.2 | Senhas são hasheadas com algoritmo seguro (**bcrypt, argon2, scrypt**) — não MD5/SHA1 | CRÍTICO | Art. 46 |
+| 4.3 | Credenciais (API keys, senhas de BD) estão em **variáveis de ambiente** e não no código | CRÍTICO | Art. 46 |
+| 4.4 | Campos sensíveis no banco de dados são **criptografados em repouso** | ALTO | Art. 46 |
+| 4.5 | Tokens JWT possuem **expiração** definida e assinatura verificada | ALTO | Art. 46 |
+| 4.6 | Queries SQL usam **parâmetros preparados** (não concatenação de strings) | CRÍTICO | Art. 46 |
+| 4.7 | Existe **rate limiting** em endpoints de autenticação | ALTO | Art. 46 |
+| 4.8 | Headers de segurança HTTP estão configurados (CORS, CSP, HSTS, X-Frame-Options) | MÉDIO | Art. 46 |
+| 4.9 | Não há dados pessoais expostos em URLs (ex: `/user/email@domain.com`) | ALTO | Art. 46 |
+| 4.10 | Dados pessoais não aparecem em respostas de erro/stack traces | ALTO | Art. 46 |
+| 4.11 | Existe política de atualização de dependências com vulnerabilidades conhecidas | MÉDIO | Art. 46 |
+| 4.12 | Dados pessoais em cache são tratados com as mesmas proteções | MÉDIO | Art. 46 |
+
+---
+
+## CAT-5: Logs e Auditoria (Art. 37)
+
+| # | Verificação | Severidade | Artigo |
+|---|---|---|---|
+| 5.1 | O sistema possui logs de acesso e modificação de dados pessoais | ALTO | Art. 37 |
+| 5.2 | Logs registram **quem** acessou, **quando** e **quais dados** | ALTO | Art. 37 |
+| 5.3 | Logs **NÃO** contêm dados sensíveis em texto claro (senha, CPF, cartão) | CRÍTICO | Art. 46 |
+| 5.4 | Logs têm política de retenção definida | MÉDIO | Art. 37 |
+| 5.5 | Logs são protegidos contra alteração/exclusão não autorizada | MÉDIO | Art. 37 |
+| 5.6 | Existe rastreabilidade de operações de exclusão de dados | ALTO | Art. 37 |
+
+---
+
+## CAT-6: Direitos dos Titulares (Art. 18)
+
+| # | Verificação | Severidade | Artigo |
+|---|---|---|---|
+| 6.1 | Existe funcionalidade para o titular **acessar todos os seus dados** | ALTO | Art. 18, II |
+| 6.2 | Existe funcionalidade para o titular **corrigir** seus dados | ALTO | Art. 18, III |
+| 6.3 | Existe funcionalidade para o titular **excluir** sua conta e dados | CRÍTICO | Art. 18, VI |
+| 6.4 | Existe funcionalidade de **portabilidade** (exportar dados em JSON/CSV) | MÉDIO | Art. 18, V |
+| 6.5 | Existe funcionalidade para o titular **revogar consentimento** | ALTO | Art. 18, IX |
+| 6.6 | Existe canal de atendimento para solicitações de titulares (email/formulário) | ALTO | Art. 18, §1 |
+| 6.7 | Solicitações de titulares são respondidas em prazo definido (máx. 15 dias úteis) | MÉDIO | Art. 18, §3 |
+| 6.8 | A exclusão remove dados de **todos os sistemas** (backups, logs, serviços terceiros) | ALTO | Art. 16 |
+
+---
+
+## CAT-7: Retenção e Eliminação de Dados (Art. 15, 16)
+
+| # | Verificação | Severidade | Artigo |
+|---|---|---|---|
+| 7.1 | Existe política de retenção de dados **documentada** (quanto tempo cada tipo de dado é mantido) | ALTO | Art. 15 |
+| 7.2 | Existe **processo automatizado** de eliminação de dados após o prazo de retenção | ALTO | Art. 16 |
+| 7.3 | Dados de usuários que excluíram a conta são eliminados no prazo correto | CRÍTICO | Art. 16 |
+| 7.4 | Backups têm política de retenção alinhada com a política de dados | MÉDIO | Art. 16 |
+| 7.5 | Dados de logs são eliminados após o prazo de retenção | MÉDIO | Art. 16 |
+| 7.6 | Dados de testes/desenvolvimento não usam dados pessoais reais | ALTO | Art. 46 |
+
+---
+
+## CAT-8: Privacy by Design (Art. 46, §2)
+
+| # | Verificação | Severidade | Artigo |
+|---|---|---|---|
+| 8.1 | Dados pessoais são **anonimizados ou pseudonimizados** quando possível | MÉDIO | Art. 46, §2 |
+| 8.2 | Configurações de privacidade têm o **modo mais restritivo** como padrão | MÉDIO | Art. 46, §2 |
+| 8.3 | Dados pessoais não aparecem em URLs publicamente acessíveis | ALTO | Art. 46 |
+| 8.4 | Analytics e telemetria não transmitem dados pessoais identificáveis | ALTO | Art. 46 |
+| 8.5 | IDs internos usam UUIDs ou IDs opacos (não IDs sequenciais expostos) | BAIXO | Art. 46 |
+| 8.6 | Campos de busca não permitem enumeração de usuários | MÉDIO | Art. 46 |
+
+---
+
+## CAT-9: Transferência Internacional (Art. 33–36)
+
+| # | Verificação | Severidade | Artigo |
+|---|---|---|---|
+| 9.1 | Está mapeado **quais dados** são enviados para serviços externos e para quais países | ALTO | Art. 33 |
+| 9.2 | Serviços externos processando dados de brasileiros têm **nível de proteção adequado** ou salvaguardas | ALTO | Art. 33 |
+| 9.3 | Existe cláusula de proteção de dados nos contratos com fornecedores externos | MÉDIO | Art. 36 |
+| 9.4 | Cloud providers têm opção de manter dados no Brasil ou em países adequados | MÉDIO | Art. 33 |
+| 9.5 | O titular é informado sobre a transferência internacional de seus dados | MÉDIO | Art. 33 |
+
+---
+
+## CAT-10: Documentação e Governança (Art. 37, 38, 41)
+
+| # | Verificação | Severidade | Artigo |
+|---|---|---|---|
+| 10.1 | Existe **Política de Privacidade** pública e atualizada | ALTO | Art. 9 |
+| 10.2 | A Política de Privacidade está acessível antes da coleta de dados | ALTO | Art. 9 |
+| 10.3 | Existe **Registro de Atividades de Tratamento (RAT/ROPA)** documentado | ALTO | Art. 37 |
+| 10.4 | Existe **DPO/Encarregado de Dados** designado com contato público | ALTO | Art. 41 |
+| 10.5 | RIPD foi elaborado para operações de alto risco | MÉDIO | Art. 38 |
+| 10.6 | Contratos com operadores (subprocessadores) incluem cláusulas de proteção de dados | ALTO | Art. 36 |
+| 10.7 | Existe treinamento/documentação de LGPD para a equipe de desenvolvimento | BAIXO | Art. 50 |
+
+---
+
+## CAT-11: Notificação de Incidentes (Art. 48)
+
+| # | Verificação | Severidade | Artigo |
+|---|---|---|---|
+| 11.1 | Existe **processo documentado** de resposta a incidentes de segurança | ALTO | Art. 48 |
+| 11.2 | Existe **monitoramento** de acesso não autorizado ou vazamentos | ALTO | Art. 48 |
+| 11.3 | Existe **canal de comunicação** para report de incidentes | MÉDIO | Art. 48 |
+| 11.4 | O processo define o prazo de notificação à ANPD (máx. 72h recomendado) | ALTO | Art. 48 |
+| 11.5 | O processo define como notificar os titulares afetados | ALTO | Art. 48 |