KYC da Didit vira dado estruturado: plano revisto, 16 arquivos tocados, commit que fica para amanhã

O dia começou com duas decisões já tomadas: antes de tocar qualquer coisa nova no Kmarote, precisava varrer lixo do repositório. E enquanto o Claude Code cuidava dessa faxina e depois montava o hardening do KYC, o Codex rodava lado a lado em outro harness cuidando de testes do painel admin e de uma limpeza de base. Dia de dois harnesses em paralelo.

Faxina no repositório antes de codar

Primeira frente da manhã, com o Claude Code.

O database/EstruturaKmarote.sql estava sendo versionado sem precisar estar. É um dump local, volumoso e regenerável — nenhum motivo pra estar no histórico. Tirei do índice e joguei no .gitignore. Commit: parar de versionar database/EstruturaKmarote.sql.

Em seguida, a pasta docs/planejamento. Pedi ao Claude Code para varrer tudo que ainda fosse plano de cadastro ou de primeiro login e me trazer cada item resumido, sem alterar nada — eu decidiria item por item. A regra que passei: não apagar arquivos que citam o assunto de passagem, só os planos já concluídos que viraram código. Resultado: commit remover planos obsoletos de perfil/onboarding. Plano executado é plano que não precisa continuar pesando na pasta.

KYC da Didit: do plano desatualizado à implementação

O grosso do dia.

Depois que o CPF saiu do cadastro nos commits de ontem, o PLANO_HARDENING_KYC_DIDIT.md ficou desatualizado em vários pontos. Antes de implementar qualquer coisa, mandei o Claude Code ler a documentação atual dos fluxos de cadastro e primeiro login e conferir o plano linha a linha, trazendo cada divergência com opções e recomendação — sem presumir nada que não estivesse escrito no código real.

As decisões que saíram dessa revisão:

Cortar a comparação de CPF do plano. Sem CPF obrigatório no cadastro, a verificação não se sustentava mais. Antes de assumir que o KYC quebraria sem CPF, cobrei o que de fato a Didit devolve: verifique exatamente quais campos são retornados pela API. O CPF pode vir na resposta quando o documento enviado já carrega essa informação — a checagem bra_cpf é extra, não pré-requisito. Decisão: tirar do plano.

Registrar todo o retorno da Didit no perfil vivo, campo a campo. Em vez de guardar o JSON bruto em um campo só, cada campo da resposta vira um registro próprio seguindo o padrão do perfil vivo, dentro de uma categoria específica de KYC. A lógica que passei: se amanhã a Didit começar a mandar campos novos, eles entram nesse mesmo modelo sem precisar refatorar nada. Extensibilidade como design, não como feature adicional.

Baixar as imagens do KYC como já é feito nos contratos. Mesmo padrão da gestão de contratos: baixar a imagem e registrar o endereço no sistema. Consistência antes de inventar outro mecanismo.

Privacidade antes de garantir qualquer coisa. Levantei a dúvida diretamente: registrar tudo no perfil vivo campo a campo não acabaria expondo dado sensível como público? Mandei o Claude Code ler a documentação do perfil vivo e o código antes de garantir qualquer coisa. Resultado: o que é sensível fica visível só para o admin — o usuário comum não acessa.

Com o plano alinhado, veio a execução. Uma sessão longa que tocou cerca de dezesseis arquivos:

• kyc_didit.php (webhook)
• kyc_didit.inc.php e db.kyc.inc.php (funções)
• db_usuarios_perfil_dados.php (persistência no perfil vivo)
• publico_perfil.php (API)
• tela de admin existente

E dois arquivos novos: ajax_kyc_admin.php e kyc_imagem.php.

A ideia da tela de admin veio de um JSON real de resposta que colei na sessão: na lista de usuários, destacar quem precisa de atenção, e ao abrir o usuário ter uma aba/subtela com as informações e ações de KYC. Tudo passou no php -l. No fim da sessão, apaguei o PLANO_HARDENING_KYC_DIDIT.md — plano executado é plano que sai da pasta.

Uma ressalva honesta: isso ainda está no banco de trabalho, sem commit. Os dezesseis arquivos modificados e os dois novos estão não rastreados, e a validação no domínio de teste faz parte do mesmo ciclo que ainda não fechei. O que entrou no histórico do Kmarote hoje foram a faxina e os testes. O hardening do KYC fica para o commit do próximo ciclo.

Codex: testes visuais, migration e bug no primeiro login

Em paralelo ao Claude Code, o Codex tocou três frentes:

Testes visuais do painel admin — commit adicionar testes visuais do painel admin. Cobrei resposta clara ao terminar (“sempre que terminar algo deve dar respostas claras, evitando perguntas óbvias”) e que cada entrega viesse com opções de próximo passo. Pedi também um documento completo do fluxo de teste com criação de credenciais e lista dos testes disponíveis. Artefatos desnecessários foram removidos ou jogados no .gitignore.

Migration de limpeza de usuários. Precisava de uma query para apagar definitivamente todos os registros de nível USUARIO e os vínculos deles em outras tabelas. Fui explícito: “é para criar uma migration para limpeza, não execute direto.” Saiu como 2026_06_24_limpar_usuarios_nivel_usuario.sql com documentação ao lado, sem rodar nada no banco.

Bug de fluxo no primeiro login. Um usuário estava caindo no fluxo de casal no primeiro acesso, quando hoje só existe o fluxo solo — a seleção de casal já foi removida. Mandei o Codex analisar a documentação e o banco e dar uma query de correção (excluir os perfis 25 e 108, manter só o 109), com a instrução explícita de ler o código de primeiro login e ter certeza antes de montar qualquer query.

---

Estatísticas do dia (geradas automaticamente):

Atividade no PC:

• Tempo ativo: 3h23min na janela de ~24h (resto AFK)

Por categoria (do que ficou ativo):

• Coding: 1h27min
• Uncategorized: 1h19min
• Communication: 15min
• AI Chat: 14min
• Browsing: 9min

Top apps: Antigravity IDE (1h22min) · Chrome (1h02min) · Codex (41min) · WhatsApp (17min)

Top sites navegados: app.redeaz.com.br (5min) · claude.ai (4min) · google (3min) · ambiente local do Kmarote (2min)

Trabalho com IA:

• Conversas claude.ai: 0
• Sessões Claude Code: 3 · Sessões Codex: 3

Código produzido:

• Commits: 3 (kmaroteApp) + 1 (elquercarlos — devlog anterior)