MockHunter — Verificação em Tempo Real de Páginas Ativas

Visão Geral

MockHunter é uma habilidade do Claude Code que audita uma página web ativa e informa, para cada valor visível, se ele é real, simulado (mocked), gerado por LLM, codificado manualmente (hardcoded), quebrado ou desconhecido. Ele foi desenvolvido para aplicativos "vibe-coded" (Lovable, Bolt, v0, Replit, AI Studio, Cursor Composer), onde a interface do usuário pode parecer completa, mas a camada de dados muitas vezes não está. Ele usa Playwright MCP para controlar um navegador real, depois rastreia cada valor visível através da rede e do DOM até sua origem.

Esta habilidade adapta o projeto upstream CodeShuX/mockhunter (fonte comunitária).

Como este fluxo de trabalho controla um navegador real em páginas ativas, trate-o como uma ferramenta de auditoria interativa, não como um auxiliar somente leitura seguro para plugins. Prefira o modo de observação até que o usuário confirme que o alvo é dele, identifique uma conta de teste ou ambiente seguro e aprove explicitamente qualquer clique, envio ou ação autenticada que possa modificar o estado.

Quando Usar Esta Habilidade

• Use ao auditar uma interface gerada por IA para descobrir quais valores estão realmente conectados.
• Use ao revisar um entregável de um contratado ou colega de equipe antes da aprovação.
• Use antes de mostrar um MVP "vibe-coded" a um cliente ou investidor.
• Use quando um painel "parece limpo demais" — cada métrica uniformemente redonda, todos os carimbos de data/hora agrupados, sem variação — e você suspeita de dados semeados.

Como Funciona

Fase 1: Configuração e Perguntas Inteligentes

1. Cumprimente o usuário, peça a URL de destino.
2. Detecte automaticamente a stack a partir da URL (*.lovable.app, *.bolt.new, *.v0.app, *.replit.app, aistudio.google.com, caso contrário, Personalizado).
3. Faça 3-5 perguntas direcionadas: modo de autenticação (público / localhost / formulário / pular), acesso ao banco de dados (opcional), suspeitas, objetivo da página.
4. Confirme o plano de auditoria, propriedade/permissão, ambiente de destino e classes de ação permitidas antes de prosseguir.

Fase 2: Navegar e Catalogar

1. browser_navigate para a URL de destino.
2. Lide com a autenticação de acordo com o modo escolhido (login por formulário: preencha os campos, clique em enviar).
3. Aguarde a rede ficar ociosa (máximo de 10s).
4. Tire uma captura de tela de página inteira, capture um snapshot de acessibilidade.
5. Inventarie cada: título, botão, link, campo de entrada, card, selo, estatística, célula de tabela, estado vazio, imagem.
6. Capture erros de console iniciais e requisições de rede.

Fase 3: Testar Interatividade

1. Para cada aba: clique somente após o usuário ter aprovado interações do tipo navegação, depois tire um snapshot, role até o final, recataloge.
2. Para cada botão: clique somente em controles aprovados pelo usuário, permitidos (allowlisted), que sejam claramente não destrutivos por função, nome acessível, texto próximo, ícone, URL/alvo de ação e efeito esperado na rede; pule controles destrutivos ou ambíguos em vez de depender apenas de uma regex de rótulo.
3. Para cada formulário: identifique campos obrigatórios e prefira validação de envio vazio; envie dados descartáveis somente quando o usuário tiver aprovado explicitamente o formulário exato, o ambiente de destino e a conta de teste.
4. Registre o comportamento por elemento.

Fase 4: Rastrear Proveniência

Para cada valor visível, execute esta árvore de decisão:

Did any network request return this value?
├── YES — found in a response:
│   ├── Status 4xx/5xx → BROKEN
│   ├── Endpoint matches /ai|openai|generate|llm|chat → LLM
│   ├── Response shape matches mock library (faker, MSW, mockoon) → MOCK
│   ├── Uniformity flags trigger → MOCK or LLM (review)
│   ├── DB connection provided?
│   │   ├── Run read-only SELECT, value matches DB row → REAL
│   │   └── Value not in DB → MOCK
│   └── No DB → UNKNOWN (best-guess)
└── NO — value not in any network response:
    ├── String literal in DOM source → HARDCODED
    ├── Computed from Math.random / Date.now / faker → MOCK
    └── Cannot determine → UNKNOWN

Heurísticas de uniformidade sinalizam dados suspeitos:

• Todos os valores numéricos idênticos entre linhas.
• Todas as porcentagens redondas (50%, 75%, 90%).
• Todos os carimbos de data/hora agrupados em um único minuto.
• Menos de 3 valores únicos em mais de 10 linhas.

Fase 5: Relatório

Gere mockhunter-report.md com:

• Tabela de resumo (contagem de veredictos).
• Achados por seção/aba (elemento / valor / veredicto / origem / gravidade / ação).
• Erros de console e falhas de rede.
• Botões NO-OP (sem operação).
• Padrões suspeitos.
• Perguntas de acompanhamento inteligentes para o usuário.

Exemplos

Exemplo 1: Auditoria de um painel administrativo Lovable

Usuário: /mockhunter audit https://my-app.lovable.app/admin
Habilidade: [Fase 1] Stack detectada: Lovable. Autenticação: pular. BD: não.
       [Fase 2] Catálogo: 6 cards de estatísticas, 4 filas de verificação, 8 itens de atividade.
       [Fase 3] Caixa de pesquisa: NO-OP (zero requisições de rede). Link de atividade → 404.

…