Como fazer auditoria de segurança com vibe coding: plano em docs/ antes do deploy

O primeiro prompt da sessão de Emanuel Limeira foi uma auditoria de segurança, com plano de ação em um MD na pasta docs/, com a área de membros já ao vivo. O site guarda dado de aluno e pagamento. A receita ainda é R$ 35,82 e o MD em docs/ entra antes do primeiro deploy da pasta das correções.

O motivo, nas palavras dele:

"a gente tá trabalhando com dados, dados sensíveis, gente, de verdade. e não dá pra gente colocar um site para produção e não ter, né, segurança."

Ele falava da área de membros e da área administrativa de um marketplace que já guarda aluno e pagamento. A área de membros já estava ao vivo, já existia, com o diretório em produção.

O primeiro prompt da auditoria

No começo da sessão ele mandou:

"faça uma análise completa de todos os problemas de segurança do projeto e [...] crie [...] um plano de ação para resolver esses problemas em um documento MD na pasta docs"

O pedido foi um arquivo no repositório, no mesmo lugar em que ele já usa Claude Code com plano em docs/. Análise completa e plano de ação no disco, para o próximo passo não depender do que ficou no chat.

No vibe coding com dado de aluno no banco, o plano escrito em docs/ entra antes do agente sair consertando o projeto. O túnel do webhook da Hotmart seguia em paralelo, sem atrasar o MD da auditoria.

Por que vibe coding pede o MD antes do deploy das correções

As correções saíam no projeto que já estava no ar, e o primeiro deploy daquela pasta ainda não tinha acontecido. Ele repetiu o critério:

"segurança em primeiro lugar"

O plano em docs/ existe para o humano não ter que guardar a lista de correções na cabeça e para o próximo prompt não começar do zero. Quem escreve o MD é o agente. O pedido que importa é análise completa de segurança com plano de ação gravado na pasta docs/.

No caso dele, como fazer auditoria de segurança com vibe coding foi mandar aquele prompt e exigir o MD em docs/ antes do primeiro deploy da pasta das correções.

O deploy das correções, com backup antes de sobrescrever

Quando ele mandou as correções do plano para o servidor, leu na tela o ritual que copiou de outro projeto: backup automático antes de sobrescrever e upload incremental. O backup entra antes de sobrescrever o que já estava no servidor. Na tela leu extração e migration pendentes rodando: estavam em execução. Nas palavras dele, "estamos só fazendo o deploy do das paradas dos paranos de segurança [...] para não dar treta."

Era o primeiro deploy nessa pasta e ele avisou que devia levar mais que 2 minutos. No meio da espera a conta do modelo apareceu: "Lá se foi 37.000 tokens." A live já ia em 2h43.

O Codex executou as correções do plano que o MD descrevia, e o deploy daquela pasta ficou só no que era segurança.

Credencial fora do chat

Na hora de autenticar o deploy, colar a chave no prompt deixaria o segredo no histórico do agente.

"As credenciais eu vou copiar de um arquivo temporário para não expor as chaves. [...] Tô com medo deles pôr aqui as credenciais."

Ele copia de um arquivo temporário no próprio disco, para a chave não entrar no prompt. O estilo do deploy veio de outro projeto. O arquivo temporário fica fora do chat: a chave passa dali para o ritual de deploy, e o agente não ganha o segredo colado na conversa. O cuidado veio do medo de eles "pôr aqui as credenciais."

Se o produto guarda dado de aluno, o primeiro prompt da sessão pede a análise completa e o plano de ação em um MD na pasta docs/.

A sessão está no YouTube para assistir à live, com o prompt no começo e o arquivo temporário na hora do medo.