Elquer Carlos

Painel admin de contratos, ZapSign corrigido e o loop do Codex no Kmarote

Dia denso: docs de contratos alinhadas ao código, bug de redirect resolvido, ZapSign corrigido (inputs[] não signers[0]) e painel admin entregue.

O dia começou com uma dívida em aberto: a documentação dos contratos de cessão do Kmarote estava destoando do que o código faz de verdade. Antes de qualquer feature nova, quis resolver isso.

Documentação dos contratos alinhada ao código

Pedi ao Claude Code para ler a documentação e o código completos e confirmar objetivamente se estavam alinhados — sem presumir, sem usar memória de sessões anteriores. Apareceram divergências.

O Claude Code apresentou cada uma individualmente, com opções. As decisões que tomei a partir disso:

  • O sistema de contratos é entre criadores (não entre criador e plataforma)
  • A geração é sob demanda (não automática no onboarding)
  • O fluxo de assinatura é em 2 passos com CPF + confirmação
  • O status do KYC é lido para proteger campos, mas o Didit não dispara nessa etapa

Saiu o commit ded7d8af ajustando os marcadores reais do perfil vivo e a regra de dedup contra registros ATIVO/PENDENTE.

O ponto de dedup mereceu atenção extra: perguntei diretamente se o sistema acumulava informação igual ou só gravava quando era algo novo. Estava acumulando. Decidi criar a verificação para não duplicar dados no banco.

Bug do redirect /admin/index.php

À tarde descobri que ao logar eu estava sendo mandado para /admin/index.php — erro óbvio, já que o servidor mapeia admin como pasta principal.

Pedi ao Claude Code para identificar apenas o que tinha mudado nas últimas alterações que causou isso. Confirmou a regressão, mandei corrigir e verificar se outros erros do mesmo tipo tinham sido introduzidos nos commits recentes.

Saiu o commit 56abe878 editando o index.php. Acabei completando a correção direto no GitHub depois porque os tokens da sessão tinham acabado. Na sessão seguinte pedi ao Claude Code para espelhar a alteração local sem mexer em mais nada.

No meio disso entrou o commit ade70631: botão de logout no navmenu lateral com reformatação de SVGs.

ZapSign: o campo certo é inputs[], não signers[0].uploads

Um ticket de suporte do ZapSign estava aberto. Levei a conversa pro Claude Code: queria um trecho real do JSON do GET /api/v1/docs/{token}, com ofuscação só de dados sensíveis, para entender a estrutura.

O Claude Code entregou uma resposta com valores cortados em "...". Cortei: o value terminando em "..." era ofuscação dele ou era a resposta real? E mais — a resposta tinha vindo de uma chamada real, ou estava inventando estrutura?

Forcei a entrega do trecho íntegro, com ofuscação só de dados sensíveis. Quando veio, o achado foi claro:

Os uploads das fotos (frente e verso do documento) ficam em inputs[] com input_type=upload, não em signers[0].uploads — que sequer existe na resposta.

Saiu o commit c9980db1: itera inputs[] diretamente, filtra input_type=upload com value preenchido, usa upload_url direto sem array intermediário confuso. Testado em 4 documentos locais (template sem uploads, comportamento correto).

Painel admin de gestão de contratos

A última peça da noite foi grande. Defini o escopo:

  • Na área administrativa, um card de Gestão de Contratos
  • Tabela com todos os contratos assinados (nome dos dois usuários, status do PDF e das imagens)
  • Filtro por usuário: nome, CPF, email, @
  • Padrão visual e de UX igual às outras áreas administrativas
  • Tela inicial sem botão de download — só indicativo de que a imagem existe no servidor
  • Download apenas dentro do “ver contrato”

O Claude Code entregou o commit 8de22cd7:

  • db_contrato_listar_admin() com subquery para nome do criador, contagem de fotos, filtros por busca e status, PDO com prepared statements
  • gestao_contratos.php com lista e detalhe (read-only, gate ADMIN)
  • Rota nova no painel admin
  • download_contrato.php ajustado para o ADMIN acessar qualquer contrato, não só os do dono

Antes do push, perguntei se 100% das alterações seguiram o padrão do projeto. Confirmou. Mandei commit e push.

Codex: design do fluxo de cadastro CPF-first

Em paralelo a tudo isso, deixei o Codex rodando uma tarefa de design pesada: refazer o fluxo de cadastro do Kmarote para começar pelo CPF — verificar se já existe, então confirmar identidade ou seguir fluxo novo. Cadastro exclusivo para CRIADOR. Cadastro de usuário comum fora do escopo por enquanto; cadastro de afiliado vira dívida técnica documentada com regras próprias.

O Codex entrou num ciclo que me cansou. Pedi um plano completo e ele veio com texto genérico sobre o que tinha errado e o que pretendia acertar. Cortei: não quero debate, quero o plano para avaliar. Se a cada pergunta minha você descartar o plano e recomeçar, nunca vamos terminar.

Quando voltou com algo mais específico, achei outro problema: o plano referenciava usuarios_perfil.cpf como se ter um perfil com CPF significasse ter conta. Não significa — um usuário pode ter cadastrado dois perfis solo (um casal, por exemplo), o casal se separa, a segunda pessoa precisa criar sua própria conta usando o CPF que já está num perfil de terceiro. Cobrei se a leitura da documentação do Kmarote estava sendo feita de verdade.

Depois entrei num modo pergunta-a-pergunta para definir cenários: o que fazer quando o CPF já tem conta (oferecer recuperar senha ou criar conta nova mostrando email ofuscado, listando todas as contas se houver mais de uma). O Codex insistia em perguntas que para mim eram óbvias e adicionavam complicação desnecessária no fluxo. Cobrei mais de uma vez: leia os padrões do sistema, consulte especialista em UX antes de perguntar.

Nenhum código novo desse fluxo foi para o repo nesta janela — fica para a próxima.

Fricção com os agentes

Dois pontos voltaram a aparecer nesta janela.

Consumo de tokens: em uma sessão do Claude Code, um comando que era basicamente um rebase simples queimou ~7% da sessão de 5 horas; depois outra ação foi para 27%. Cobrei se estava realmente otimizado, porque a tarefa não justificava esse drain. O Claude Code reconheceu que estava provavelmente tentando adivinhar caminhos e piorando a cada alteração. Cortei: você tem acesso a tudo, preciso de fatos e caminhos exatos baseados em análise e resultados reais, não em achismo.

Adoção de padrões: perguntei se faz sentido usar GSD workflow e Kotlin no Kmarote. O Claude Code é quem conhece o código — a pergunta era para ele responder com base no que existe, não para empurrar uma stack porque está na moda.

Pendências

  • Fluxo de cadastro CPF-first (Codex): design ainda não fechado, nenhum código no repo desta janela
  • As demais frentes (redirect, ZapSign, admin de contratos) estão fechadas e em produção

Estatísticas do dia (geradas automaticamente):

Atividade no PC:

  • Tempo ativo: 8h29min (janela de 48h monitorada)

Por categoria:

  • AI Chat: 2h17min
  • Browsing: 1h58min
  • Coding: 1h52min
  • Uncategorized: 1h36min
  • Communication: 29min
  • Larissa Project: 14min

Top apps: chrome.exe (3h47min) · Codex.exe (1h59min) · Antigravity IDE (1h52min) · WhatsApp (35min)

Top sites navegados: chatgpt.com (27min) · instagram.com (15min) · claude.ai (12min) · PRIVATE-HOST (8min)

Trabalho com IA:

  • Conversas claude.ai: 0
  • Sessões Claude Code Windows: 5 (kmaroteApp)
  • Sessões Codex Windows: 1 (kmaroteApp)
  • Claude Code Larissa: SSH indisponível (host unreachable)

Código produzido:

  • Commits: 6 (kmaroteApp) + 1 (elquercarlos)
Fim do ato