--- name: rea-prompts-curso description: Método e prompts prontos para fazer engenharia reversa de um app web com a REA (Reverse Engineer Anything). Use junto com a skill reverse-engineer-anything sempre que for mapear um app, entender uma funcionalidade por dentro (telas, código da página, rede), gerar o relatório ou retomar um estudo longo. Em português. --- # REA Prompts: como pedir à REA (versão do curso) Adaptado do REA Prompts (REAP) de Joas A. Santos, github.com/JoasASantos/REA-Prompts, licença MIT. Esta versão é um resumo em português, organizada para o curso. Os prompts completos e as seções avançadas estão no repositório original. ## As 6 regras do método (seguir sempre) 1. **Uma funcionalidade por pedido.** Pergunta ampla dá resposta rasa; pergunta estreita dá o caminho completo, com as provas. 2. **Prova em toda afirmação:** arquivo, função, trecho do código, endereço ou a chamada de rede capturada. 3. **Três baldes:** CONFIRMADO / PROVÁVEL (com o porquê) / NÃO SEI. 4. **Olhar antes de mexer.** Primeiro a análise parada (o código, a página); usar o app de verdade só quando olhar não bastar. 5. **Terminar com um arquivo:** mapa, relatório ou especificação. Escrever obriga o agente a conferir o que afirmou. 6. **Dizer o escopo em voz alta:** "conta minha", "só observar", "documentar". ## Os limites do estudo Os mesmos dos projetos de port de jogos: - usar só a própria conta (de preferência uma conta e um perfil de navegador só para o estudo); - nunca burlar login, senha ou pagamento, nem liberar recurso pago; - nunca mexer em dados de outras pessoas; - não chamar no servidor o que o próprio app não chama; - **nunca fabricar progresso:** - não alterar nem repetir uma chamada para gerar XP, gemas, acertos ou resultados; - não automatizar a resolução de exercícios para pontuar; - não mexer em ranking ou liga. O XP legítimo é só o de uma lição feita normalmente, pelas mãos do usuário. A aprovação do usuário NÃO libera nada disso: testes desse tipo só no app que é seu; - não revender a marca do app estudado. O objetivo é **entender para reconstruir**: no fim, você escreve a sua versão, com a sua marca. ## Provas sem segredo (obrigatório) - Antes de MOSTRAR, SALVAR ou enviar ao Git qualquer prova, principalmente uma captura de rede, apague: - cookies; - cabeçalhos de autenticação; - tokens e chaves; - e-mails, nomes e qualquer dado pessoal. - Guarde o FORMATO (os nomes dos campos e o tipo de cada valor), nunca o valor. - Capture só a parte da tela necessária. Nomes, fotos e identificadores de OUTRAS pessoas (num ranking, por exemplo) saem antes de a prova ser mostrada ou salva. - Nunca exporte a captura bruta da rede (arquivo HAR) para "limpar depois": registre já sem os valores. - Nunca peça senha ou chave no chat, e nunca imprima um arquivo de configuração inteiro. ## O que o agente faz no app estudado - **Pode:** navegar e ler as telas (só leitura), observar a rede e analisar os arquivos da página. - **Nunca:** clicar em nada que grave, envie, compre ou publique; isso quem faz é o usuário. Exercícios e lições também quem faz é o usuário. - **Nunca, nem com aprovação:** alterar ou reenviar uma chamada. - **No app do próprio usuário:** o agente pode agir, sempre dizendo antes o que vai acontecer e como desfazer. ## O roteiro de um app web, na ordem Um arquivo entregue por etapa: 1. **Conferir as ferramentas:** quais ferramentas da REA estão disponíveis nesta máquina. 2. **O mapa** (`MAPA.md`): as partes principais, as telas, os caminhos (rotas) e as 3 funcionalidades que valem estudar primeiro, cada afirmação com prova. 3. **A estrutura do site:** as rotas, as chamadas de rede que cada tela faz e onde o app guarda o estado. 4. **Uma funcionalidade por vez:** do clique (entrada), passando pelas funções e pelos dados, até o efeito que se vê. Com o trecho do JavaScript de cada passo. 5. **Observar o uso:** a rede e as mudanças na tela enquanto a funcionalidade é usada; o que roda no navegador e o que roda no servidor. 6. **A especificação** (`ESPECIFICACAO.md`): tudo o que o usuário vê, com: - as telas e os estados; - as entradas, as saídas e os casos de borda; - os formatos dos dados; - o que é salvo; - como o app se comporta quando dá erro. Cada item com prova; o que faltar fica como NÃO SEI. 7. **Continuar outro dia** (`ESTUDO.md`): o que foi achado, as provas, as hipóteses descartadas e os próximos passos, priorizados pelo que mais reduz a dúvida. ## Prompts prontos (troque o que está entre `< >`) **Mapa:** > Use a REA para me dar o mapa de : as partes principais, as telas, os caminhos e as três funcionalidades que valem estudar primeiro. Seja curto e mostre a prova de cada afirmação. Salve em MAPA.md. **Uma funcionalidade:** > Use a REA para investigar como funciona em . Mostre o ponto de entrada (o clique), as funções envolvidas, o caminho dos dados e o efeito que se vê. Para cada conclusão, mostre a prova: arquivo, função ou trecho. Separe CONFIRMADO, PROVÁVEL e NÃO SEI. **Código minificado:** > Use a REA no JavaScript da página para seguir no código minificado. Separe os módulos, dê nomes legíveis às funções importantes, siga os dados do evento na tela até a chamada de rede e desenhe o caminho das chamadas. Cite o trecho do código em cada passo. **Site:** > Use a REA para inspecionar https:///. Recupere a estrutura das páginas, os caminhos (rotas), as chamadas de rede de cada tela e onde o app guarda o estado. Liste as chamadas e os scripts como prova, tela por tela. **Especificação para reconstruir:** > Use a REA para estudar como caixa-preta e escrever ESPECIFICACAO.md com: cada funcionalidade, tela e estado que o usuário vê; entradas, saídas e casos de borda; os formatos dos dados e da rede; o que é salvo; o comportamento de erro. Cada requisito com prova. O que não for confirmado fica como NÃO SEI. **Continuar outro dia:** > Leia as provas e as notas deste estudo. Liste o que ainda não foi demonstrado. Priorize as próximas análises pelo quanto reduzem a dúvida. Atualize ESTUDO.md com os achados, as provas, as hipóteses descartadas e os próximos passos. **Curinga:** > Use a REA para entender como funciona em . Confira primeiro quais ferramentas estão disponíveis. Comece pela análise parada e siga a funcionalidade até as funções responsáveis. Mostre a prova de cada conclusão, separe fato de hipótese e registre as limitações. No fim, escreva a especificação do comportamento e proponha testes para conferir. ## Junto com o RES (skill reverse-engineering-saas) **Num app de terceiro, o RES não grava nada no app.** Ele: - navega e lê; - usa os scripts de leitura, que guardam só formatos, nunca valores; - organiza a base e escreve o relatório. As ações que criariam, mudariam ou apagariam dados no app ficam com o usuário. - **O RES** estuda o app como PRODUTO: telas, regras, dados, o que impediria o lançamento e o relatório `REPORT.html`. - **A REA** responde COMO o app é feito por dentro: código, rede, formatos. - **No estudo de um app web, o RES conduz** e chama a REA onde a parte técnica importa. Os dois registram a prova de cada afirmação.