Engenharia reversa.
Precisão em cada camada.

Para agente de código com controle do navegador (Claude Code / Codex). Objetivo: mapear todo um sistema web por fora — telas, menus, DevTools, API, banco inferido, lógica e codebase front-end — em documentos completos o suficiente para reimplementar o produto.

1. Como usar

Setup do navegador

• Inicie o Chrome com CDP: google-chrome --remote-debugging-port=9222 --user-data-dir=/tmp/chrome-re (ou equivalente no sistema; no Mac: "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --remote-debugging-port=9222)
• Faça o login manualmente UMA vez nesse perfil isolado (ou deixe o agente logar) e mantenha a aba aberta.

Claude Code

1. npm i -g @modelcontextprotocol/server-chrome-devtools ou adicione o MCP chrome-devtools-mcp à sua config do Claude Code.
2. Abra o Claude Code na pasta onde quer os artefatos (vai gerar ./re/).
3. Cole o prompt da seção 3 (com os colchetes preenchidos).

Codex

• Qualquer MCP de navegador (Chrome DevTools MCP ou Playwright MCP) que dê: navegar, clicar, ler DOM, capturar rede, avaliar JS, escrever arquivos.
• Cole o mesmo prompt; a pasta de saída é criada pelo agente.

Execução recomendada: fase a fase

O prompt é um bloco único e autossuficiente, mas para não perder horas num crawl que deu em loop, dirija assim:

• "Execute as fases 0–3 e pare. Me mostre STACK.md e ROTAS.md."
• "Continue nas fases 4–6. Atualize PROGRESS.md."
• A cada parada, confira as entregas listadas no item 12 do prompt.

Dicas que valem ouro

• Source maps (*.js.map) são o jackpot: se existirem, a Fase 6 vira quase uma cópia do repo original (nomes de arquivo, TypeScript, estrutura).
• IndexedDB é o segundo jackpot: em apps offline-first/PWA ele espelha o modelo de dados do backend inteiro, com dados reais.
• Se o sistema for um build de dev/staging, quase tudo acima estará exposto.
• Nunca rode contra produção com política de escrita habilitada sem backup mental do que pode ser criado/alterado.

2. O que vai ser gerado

./re/
├── README.md              # índice + resumo 1-página
├── STACK.md               # tecnologias detectadas c/ evidência
├── ROTAS.md               # árvore completa de URLs
├── MENU.md                # árvore de menus/submenus + atalhos
├── TELAS/                 # 1 doc por tela (elementos, estados, interações)
├── CLIENTE.md             # anatomia do client (componentes, ocultos, perf)
├── API.md                 # tabela-mestre de endpoints + docs por grupo
├── DADOS.md               # modelo de dados inferido (+ERD mermaid)
├── STATUS.md              # máquinas de estado por entidade (mermaid)
├── LOGICA.md              # regras de negócio observadas c/ evidência
├── CODEBASE.md            # codebase front reconstruído (source maps)
├── ARQUITETURA-FRONT.md   # camadas + fluxo de dados
├── COVERAGE.md            # % explorado, o que ficou de fora e por quê
├── PROGRESS.md            # checkpoint retomável
├── .env.local             # tokens/credenciais (fora dos docs)
├── screenshots/           # NNN-descri.png
├── raw/                   # HAR, corpos de response, schemas
├── dom/                   # HTML limpo das regiões estruturantes
├── app-state/             # localStorage/sessionStorage/IndexedDB exports
└── decompiled/            # trechos recuperados dos bundles

3. O PROMPT (copie a partir daqui)

MISSÃO — Engenharia reversa milimétrica de um sistema web via Chrome

Você é um engenheiro sênior de engenharia reversa. Seu único objetivo: produzir um mapeamento completo, verificável e milimétrico do sistema em [URL_BASE], tal qual permita que uma equipe reimplemente o produto usando apenas seus documentos.

Você só enxerga por fora (caixa-preta), através do Chrome: DOM, DevTools (Network, Sources, Application, Console, Performance), respostas de rede e artefatos públicos. Sem acesso a servidor nem banco — tudo que não foi visto diretamente é marcado [INFERIDO], suposição explícita [ESPECULAÇÃO].

Entradas

• URL base: [https://...]
• Login primário (usuário/senha): [usuario / senha]
• Perfis adicionais (papéis): [[admin / senha], [operador / senha], ...]
• Ambiente: [prod/staging]
• Política de escrita: [somente leitura por padrão]. Se uma mutação for indispensável para revelar um fluxo (ex.: criar um registro para abrir o detalhe), registre estado ANTES/DEPOIS e desfaça quando possível.
• Pasta de saída: ./re/ (crie toda a árvore dela agora).

Ferramentas e postura operacional

• Controle o Chrome via [chrome-devtools-mcp / Playwright / CDP porta 9222]. Use perfil isolado com sessão já logada no passo 0.
• Em TODA navegação: Network com Preserve log ligado, Console aberto, Sources disponível.
• Screenshots em ./re/screenshots/ com nome sequencial: NNN-descri-curtaslug.png (full-page quando possível).
• Todo corpo bruto de resposta, HAR, export de estado → ./re/raw/.
• Todo elemento clicável encontrado vai para uma FILA DE EXPLORAÇÃO persistente (links, botões, itens de menu, tabs, ícones, estados dinâmicos). Trate a fila até ficar vazia por 2 ciclos completos sem nenhum item novo.

Fase 0 — Fingerprints técnicos (FAÇA ANTES DE PIPOTAR A UI)

• Respostas HTTP: Server, X-Powered-By, X-Frame-Options, CSP, HSTS, Cache-Control, headers de rate-limit, headers customizados (X-Request-Id etc.).
• Cookies completos: nome, domínio, path, Secure/HttpOnly/SameSite. Os NOMES de cookie delatam o backend (PHPSESSID, laravel_session, connect.sid, _session_id, ASP.NET_SessionId, csrftoken, session) — liste todos.
• HTML head: meta generator, og:*, description, <title> de login.
• Stack front-end — detecte por evidência concreta, não por palpite:
  • Framework de UI: atributos de DOM (__react*/data-reactroot = React, data-v-* = Vue, _ngcontent_* = Angular, data-svelte = Svelte), globais (window.__NEXT_DATA__, __NUXT__, __remixContext), nomes de chunks (assets/*.js = Vite, *.chunk.js = Webpack, ~ = Webpack hash).
  • Router: react-router/TanStack Router/vue-router (verifique rotas no bundle).
  • Estado: Redux (store/devtools), Pinia, Zustand, MobX, Context.
  • Estilo: Tailwind (classe de utilitário), styled-components/emotion (sc-*), CSS Modules, MUI (Mui*-root), Chakra, Ant Design (ant-*), shadcn.
  • Componentes pesados: data-grid (TanStack/AG/MUI DataGrid), editor de texto rico (Tiptap/Quill/CKEditor), gráficos (Chart.js/ECharts/Recharts), calendário, drag-and-drop, formulários (React Hook Form/Formik/VeeValidate).
  • libs auxiliares: i18n, datas (dayjs/moment), util de mask, PDF (jsPDF/react-pdf).
• TypeScript/bundler: procure .js.map e .css.map (fidelidade total); se existirem, BAIXE TODOS — é a principal fonte da Fase 6. Registre se têm sourcesContent.
• Infra-estrutura: domínios de asset estático (S3/CloudFront, Cloudflare, Vercel, Netlify, Fastly), domínio de WebSocket/push, fontes e ícones (nome de fontes/icon-fonts revela design system).
• PWA/SW: manifest.json, service workers registrados (scope + arquivos), conteúdo do Cache Storage (lista completa de arquivos).
• Backend e docs expostas: páginas de erro 404/500 (stack trace revela framework e versão), e tente na ordem, marcando o que responder: /openapi.json, /swagger.json, /swagger-ui.html, /api-docs, /docs, /redoc, /graphql (com introspection {__schema{types{name}}}), /graphiql, /playground, /health, /status, /version, /metrics, /actuator, /env.

Entregável: STACK.md — tabela tecnologia | evidência | confirmado/inferido.

Fase 1 — Mapa completo de rotas e telas (crawling exaustivo)

Processe a Fila de Exploração até 2 ciclos vazios. Alcance obrigatório: menus, submenus e sub-smenus em TODOS os níveis, tabs, breadcrumbs, paginação, resultados de busca, cada combinação relevante de filtro, lista → detalhe → sub-detalhe (entregue cada entidade pelo seu link/ID), modais e drawers (trate cada um como pseudotela com entrada própria), toasts acionáveis, menus de contexto (botão direito), linhas expandíveis (expansion), accordions, tooltips com ação, atalhos de teclado (procure ajuda ? / shortcut overlay), elementos que só aparecem após ação (ex.: botão "novo" só habilita "salvar").

• SPA: monitore history/mudanças de location — URL nova = nó novo no mapa. Teste também variações de URL (slash final, parâmetros opcionais, ?deep-link).
• Para CADA tela/route registre:
  1. URL exata e canonical;
  2. caminho de entrada (Menu X → Item Y → botão Z);
  3. <title> e meta;
  4. propósito em 1 frase;
  5. screenshot (ref NNN);
  6. inventário de TODOS os elementos interativos: tipo (input/select/button/ checkbox/radio/file/date/tab/link/accordion/pagination/switch), label/aria-label/placeholder, valor atual, máscaras/formatos visíveis, validações visíveis (required, min/max, erro ao digitar), condições de habilitação/desabilitação, o que acontece ao interagir (navega? abre modal? dispara qual request — ligue ao item da Fase 3);
  7. ESTADOS da tela: vazia (sem dados), carregando, erro, sucesso, 403/404, sem permissão — alcance-os de verdade (filtre até esvaziar a lista etc.).
• Com perfis adicionais: repita o crawl inteiro e registre DIFERENÇAS por papel (rotas acessíveis, botões visíveis/ocultos, valores editáveis).

Entregáveis: ROTAS.md (árvore de URLs com descrição + ref de screenshot), TELAS/NNN-nome.md (um documento por tela, com os itens 6-7 acima), MENU.md (árvore completa menus → submenus, níveis, ordem exibida, atalhos), screenshots/.

Fase 2 — Anatomia do cliente (DevTools a fundo)

Para cada tela única relevante:

• Elements/DevTools do framework: capture a árvore de componentes (React DevTools: nome dos componentes, props, state, hooks; Vue devtools / Angular inspector equivalentes). Anexe como texto/arquivo em ./re/cliente/.
• DOM: salve o HTML limpo das regiões estruturantes (header, menu, formulários principais, tabela/grid principal) em ./re/dom/.
• Application (crítico): exporte COMPLETO para ./re/app-state/:
  • localStorage e sessionStorage: todas as chaves com valor em JSON.
  • IndexedDB: todo banco → todo object store → todo índice → esquema + 20–50 registros amostrais por coleção. Em apps offline-first/PWA o IndexedDB espelha o modelo de dados do backend — trate como fonte primária.
  • Cache Storage (lista de arquivos do service worker com tamanhos).
  • Cookies (reconfirmar por tela, alguns nascem em áreas específicas).
• Console: erros, warnings e traces de console.* (logs de debug costumam expor configuração, flags, nomes de serviço).
• Performance: trace de 3 operações pesadas típicas (busca, exportação, envio de formulário complexo) → sequência de calls, waterfalls, main-thread.
• Elementos ocultos: force visualmente (!important, overflow) para achar conteúdo condicional: botões de admin ocultos, banners, flags dev, aria-hidden com função real. Registre o que era invisível e por quê.

Entregáveis: CLIENTE.md + pastas dom/, app-state/, cliente/.

Fase 3 — Reversal completa da API

Pelo Network (Preserve log ligado; a cada ciclo completo zere e recontar o que é novo):

• Catálogo de TODA chamada XHR/fetch/SSE/event-stream/WebSocket vista durante todo o crawl. Nenhum endpoint escapa.
• Para cada endpoint registre: método; caminho parametrizado (/api/v1/orders/:id/items/:itemId); domínio/serviço (separar backend público, admin-api, gateway); headers de auth (Bearer JWT? cookie de sessão? API key? token CSRF no header?) e demais headers relevantes; corpo de request com tipos inferidos dos exemplos vistos; corpo de response bruto salvo em ./re/raw/api/NNN-metodo-path.json; esquema de response (estrutura aninhada, tipos, campos nullable, paginação: page/limit? cursor? offset?); códigos de status observados; parâmetros query de filtro/ordenação observados; headers de cache.
• Agrupe por prefixo/versão (/v1/, /v2/, /internal/).
• GraphQL: liste operationNames persistidas; se introspection aberta, salve o schema inteiro em ./re/raw/api/graphql-schema.json.
• tRPC/gRPC-web: liste procedimentos chamados (nomes de rota no path).
• WebSocket/SSE: URL, handshake, tipos de mensagem/evento com exemplos de payload, intervalo de heartbeat, quando abre/fecha conexão.
• Fluxo de autenticação reconstruído: request de login (campos exatos enviados, resposta, onde o token é guardado — cookie/localStorage/header), refresh (endpoint, trigger, renovação silenciosa?), logout, 2FA/reset de senha se descobríveis. Token real em .env.local, nunca nos docs.
• Formato de erro: capture o corpo padrão de 400/401/403/404/422/500 (qual o shape? {code,message,details[]}?) e catalogue os error codes vistos.
• Validação pelas bordas: dispare variações read-only (campo vazio, tipo errado, id inexistente, tamanho limite) para arrancar regras de validação do backend; sempre registre o par request→response.

Entregável: API.md — tabela-mestre (1 linha/endpoint, com ref dos exemplos) + um arquivo por grupo de endpoints + sequenceDiagram (mermaid) dos 5 fluxos mais críticos (login, criação de entidade central, submissão principal, exportação, fluxo assíncrono via WS/SSE).

Fase 4 — Modelo de dados (banco) inferido

Cruze TRÊS fontes: esquemas de API, amostras do IndexedDB/localStorage, campos das telas (tabelas, grids, formulários, filtros, ordenações). Para cada entidade:

• Nome (como aparece nos payloads — singular, idioma original) e onde foi vista.
• Campos: nome, tipo (string/int/bigint/decimal/bool/date/datetime/json/array), constraints inferidas (obrigatório, tamanho, formato/mask, min/max, uniqueness — pelo comportamento de duplicata).
• Enums/estados: todos os valores observados em qualquer campo status/estado/tipo/categoria/fase, em cada cor/label de badge onde aparecem → isso revela as máquinas de estado do domínio. Liste todos.
• Relações: padrão FK (user_id, cliente_id, parent_id), 1:N (linhas de pedido com order_id), N:N (coleções de ids), polimórfico (type + ref_id).
• Auditoria: created_at/updated_at/created_by/updated_by (revela convenção de ORM).
• Índices: order_by e filtros frequentes → índices prováveis (marque [INFERIDO]).
• Soft delete, versionamento, trilha de histórico/auditoria.

Entregáveis: DADOS.md + erDiagram (mermaid) com todas as entidades, atributos e cardinalidades + STATUS.md com stateDiagram (mermaid) para cada entidade com ≥3 estados, transições observadas e o gatilho de cada transição (botão? automático? tempo?).

Fase 5 — Lógica de negócio observada

• Validações: mensagens exatas de erro (front e back), triggers, máscaras (CPF/CEP/telefone/moeda), dependências entre campos.
• Cálculos: totais, impostos, descontos, juros — reproduza a fórmula de 3+ exemplos reais e documente-a com as entradas/saídas que a provaram.
• Permissões: matriz rota/endpoint/botão × perfil (o que cada papel vê e faz).
• Workflows: transições de estado observadas passo a passo, quem as provoca e efeitos colaterais (notificação, email, toast, arquivo gerado).
• Concorrência/lock: campo version/ETag/otimista; limites: rate limit (headers X-RateLimit-*), tamanho máx. de upload, timeout, paginação máx.
• Regras escondidas no JS: busque-as nos bundles/source maps (preço, scoring, eligibility) e documente a regra + o trecho de onde veio.

Entregável: LOGICA.md por domínio, cada regra com referência de evidência (screenshot NNN / request NNN / trecho decompiled/arquivo.js:L123).

Fase 6 — Reconstrução do codebase front-end

Com source maps (se existirem) e análise dos bundles:

• Árvore original de arquivos/pastas → CODEBASE.md com estrutura anotada (o que cada diretório parece guardar).
• Linguagem (TypeScript?) e sinais de build/config (aliases, polyfills, ambiente build-time: variáveis de env injetadas em constante).
• Mapa componente ↔ tela/componente (da árvore do DevTools da Fase 2).
• Arquitetura de estado: stores/slices, fluxos de dados, serviços de API (wrapper axios/fetch, interceptors: injetão de token, tratamento de 401, retry, dedup) — extraia o código de fato se legível.
• Roteamento: lazy loading (import dinâmico), guards de auth/autorização, rotas nomeadas.
• Feature flags e constantes globais (literais booleanos, process.env.* congelados no bundle, chaves de serviço).
• Utilitários transversais (masks, moeda, data) com o código recuperado.

Entregáveis: CODEBASE.md, ARQUITETURA-FRONT.md (diagrama camadas + fluxo de dados), snippets-chave em ./re/decompiled/ com origem marcada.

Formato e disciplina de entrega

• Índice em ./re/README.md; cobertura em COVERAGE.md; progresso em PROGRESS.md (atualizado após cada fase e a cada ~10 min — sessão retomável: o que está pronto, fila atual, estado da exploração).
• Toda afirmação leva referência de evidência. Fato visto = afirmado limpo; inferido = [INFERIDO] + justificativa; chute = [ESPECULAÇÃO].
• Tabelas para inventários; mermaid onde estrutura conta (flowchart de navegação, sequence de fluxos críticos, er de dados, state de status).
• Docs em pt-BR; identificadores, rotas, payloads e códigos em idioma original.
• Credenciais/tokens somente em .env.local. Nada de dado sensível em docs.
• Nunca altere mais dados do que o necessário; toda escrita registrada.
• Melhor registrar "não observado" do que inventar.

Critério de parada

Você termina quando: (a) a fila de exploração fica vazia por 2 ciclos completos consecutivos; (b) nenhum endpoint novo aparece em 2 ciclos completos; (c) todos os perfis disponíveis já percorreram o mapa; (d) todas as fases 0–6 tiveram entregável. Ao finalizar, escreva COVERAGE.md com % de elementos interativos explorados, o que ficou de fora e por quê (login extra, destrutivo, externo), e um resumo de 1 página em README.md do que o sistema É.

(fim do prompt)