KYC, gates e o plano que vai levar isso pra produção
Dia de implementar a cascata de bloqueio KYC, corrigir bugs no painel admin e fechar o plano pré-produção em 5 módulos.
Implementar KYC não é só colocar um formulário. É uma cascata de estados, gates e verificações que tem que funcionar corretamente antes de ir pra produção.
Hoje o foco foi exatamente isso: fechar a lógica de KYC no kmaroteApp. Criei a função db_usuario_tem_kyc_aprovado(), adicionei o gate na cascata de bloqueio do admin/index.php e implementei o bloqueio permanente pra menoridade no kyc.php — com um banner de status pendente via gate pra quem ainda está no meio do processo.
// gate KYC na cascata de bloqueio
if (!db_usuario_tem_kyc_aprovado($usuario_id)) {
// redireciona para fluxo KYC ou exibe banner pendente
}A lógica parece simples no papel, mas cada estado tem ramificações. Usuário sem KYC, usuário com KYC pendente, usuário menor de idade (bloqueio permanente), usuário aprovado. Cada um desses estados precisa de um caminho diferente no sistema — e misturar qualquer um deles é um problema de compliance que não tem rollback fácil.
No meio do dia apareceu um fix que parecia menor mas revelou um buraco real: perguntas de uma categoria específica não estavam retornando resultado no painel admin. A raiz do problema era falta de null-safety no renderizar_input. Essas são as correções que nunca aparecem no roadmap, mas que aparecem sempre que alguém testa uma combinação fora do caminho feliz.
Fiz também uma limpeza nos docs de planejamento — removendo itens já implementados e descartados ao longo do caminho. Documentação que acumula decisões antigas e itens obsoletos polui mais do que ajuda. Se algo foi implementado ou descartado, sai do plano.
O fechamento do dia foi escrever o PLANO_MESTRE.md: plano detalhado pré-produção dividido em 5 módulos. A investigação KYC-05 está completa e aguardando checkpoint humano antes de avançar — algumas decisões não dá pra tomar sozinho no código.
Amanhã começa a execução.