Débitos técnicos

O servidor principal tem 145 arquivos de teste, mas rodar a suíte sempre termina em erro — mesmo que todos os testes passassem. A causa é uma exigência de cobertura mínima de 90% contra cerca de 15% reais: o Jest considera isso uma falha e encerra sinalizando erro. E eles não passam todos: o docs/ESTADO.md do core registra 11 falhas pré-existentes (trade-service, pagarme-service, notify-email-verification), escondidas atrás do erro de sempre.

Há ainda um efeito prático pior: com a cobertura ligada de forma fixa, a rodada completa leva perto de 5 minutos e trava a máquina de desenvolvimento. Por isso ela está proibida desde 24/08 — a verificação do dia a dia é o tsc --noEmit mais o teste do arquivo tocado. Ninguém roda a suíte inteira.

Um teste só vale enquanto alguém confia nele — e enquanto alguém o roda. Como o resultado é sempre “erro” e a rodada completa não pode acontecer, um teste que quebrasse fora do arquivo tocado passaria despercebido. As 11 falhas registradas são a prova: estão lá, conhecidas, e nada obriga a consertá-las.

É também o motivo de não existir portão automático nas mudanças: não dá para pedir que a esteira barre código quebrado quando a suíte reprova sempre.

Em toda alteração do servidor principal. É o débito que encarece todos os outros: sem rede de testes confiável, quebrar os serviços-monstro do item 02 fica bem mais arriscado do que precisaria ser.

1. Separar as duas coisas: desligar o collectCoverage fixo, para que um comando rode os testes e responda só sobre eles; outro, separado, mede cobertura.
2. Corrigir as 11 falhas pré-existentes, para a suíte voltar a sair limpa.
3. Ajustar a exigência de cobertura para o número real de hoje, travando o que existe.
4. Subir esse número aos poucos, conforme as extrações do item 02 forem trazendo testes novos.
5. Com o resultado voltando a ser confiável, ligar o portão na esteira.

Quase toda mudança de configuração, não de código — o melhor retorno de toda a lista. As 11 falhas são o único trabalho de verdade. Destrava a confiança na suíte inteira, permite rodá-la de novo e, com ela, dá a segurança para atacar o item 02.

A dashboard modela só metade das tabelas do sistema, e ainda lê uma que o 3.0 aposentou:

Parte do que o 3.0 criou já ganhou tela — o AZ Play, por consultas escritas à mão, e o sorteio, pelo core. O resto não tem: se uma proposta de troca precisar ser conferida ou uma moderação precisar de revisão, não há por onde — só consultando o banco à mão. E a tela de produto ainda mostra como propostas as linhas da tabela aposentada, que já não recebem nada novo.

E administrar pelo banco é o pior dos mundos: sem registro de quem fez, sem validação e com risco de escrever no lugar errado.

No atendimento e na moderação. Com o 3.0 nas lojas, o conteúdo 3.0 já é o volume principal — e o débito cresce sozinho a cada funcionalidade nova do core que nasce sem contrapartida no painel.

1. Regenerar a descrição do banco a partir do servidor principal, trazendo as 45 tabelas ausentes — o que também tira o AZ Play do SQL escrito à mão.
2. Remover o que ficou órfão, como a leitura da tabela de negociação substituída pelo chat.
3. Listar, com o time de atendimento, quais telas ainda faltam — provavelmente poucas: propostas (lidas do chat, que é o dono) e a fila de moderação.
4. Construir só essas.

Pôr a descrição do banco em dia é a parte barata, e já elimina o risco de administrar uma tabela morta. As telas novas vêm depois — e só as que o atendimento apontar como necessárias.

Todos os serviços rodam como um único processo, sem cópia de reserva. Se ele cai, reinicia, ou estoura o limite de memória configurado, o serviço fica fora do ar até subir de novo — alguns segundos em que nenhum colecionador é atendido.

E parte do código já depende disso: a varredura do sorteio avisa, no próprio arquivo, que só é segura com o core em instância única — duas instâncias rodariam duas varreduras disputando as mesmas linhas. Antes de duplicar, ela precisa de uma trava compartilhada.

Não é só o risco de queda: é que toda publicação de versão é uma pequena indisponibilidade. Com processo duplicado, dá para atualizar um de cada vez e ninguém percebe. Com processo único, toda entrega interrompe o atendimento.

No servidor principal, onde a interrupção atinge todos os colecionadores ao mesmo tempo. E na frequência de publicação: quando cada entrega custa uma pequena queda, o time naturalmente entrega menos vezes — o que torna cada entrega maior e mais arriscada.

Depende do item 06 estar resolvido. Com 2 núcleos e quatro serviços já disputando, duplicar hoje pioraria as coisas. Depois de separar as máquinas, o servidor principal fica sozinho e pode rodar em duas cópias, com atualização alternada — desde que as varreduras agendadas, como a do sorteio, ganhem trava compartilhada e o DB_POOL_SIZE seja recalculado para as duas cópias.

A mudança de configuração é de poucas linhas — quase todo o trabalho é teste. Só faz sentido depois da separação de servidores do item 06.

O aplicativo reporta hoje só o que o derruba: o Crashlytics captura o fechamento inesperado pelo lado nativo, com os símbolos que tornam a pilha legível, e o código escreve nele um único dado de contexto — quantos vídeos estão vivos na tela. Todo o resto passa calado: nenhum erro tratado é registrado (não há uma chamada de recordError no código), nenhuma tela crítica é marcada e nenhum aviso dispara quando a taxa de erro sobe.

E há duas ferramentas para o mesmo trabalho: o Bugsnag continua instalado, com chave no app.json, ao lado do Crashlytics — sem nenhuma linha de código que o use.

No servidor dá para ler os registros e investigar. No aplicativo, não: ele roda no aparelho do colecionador, em versões de sistema e modelos que ninguém tem à mão. A maior parte dos defeitos não fecha o app — é uma compra que falha, uma tela que fica vazia, um envio que não sai. Sem reporte desses erros, um defeito que atinge um aparelho específico pode durar semanas invisível, e a única forma de descobrir é o colecionador reclamar — ou avaliar mal na loja.

A ferramenta a mais cobra à parte: é dependência nativa para manter atualizada e uma dúvida para quem chega — qual dos dois painéis é o de verdade.

Na capacidade de reagir depois de cada publicação. Não impede publicar — define quanto tempo se leva para descobrir que algo deu errado.

1. Registrar no Crashlytics os erros que não derrubam o app, a começar pelos fluxos que movem dinheiro — checkout e pagamento —, associando cada um à versão do aplicativo.
2. Marcar as telas críticas — login, checkout, chat — para saber onde o erro aconteceu.
3. Configurar aviso automático quando a taxa de erro subir depois de uma publicação.
4. Decidir entre Bugsnag e Crashlytics e tirar o outro do projeto.

A captura de crash já está de pé; o trabalho é registrar o erro que não derruba, marcar as telas críticas e conferir que ele chega. É o que permite enxergar o que acontecer depois de cada publicação.

Os quatro serviços acessam banco com a mesma ferramenta, em quatro versões diferentes — três delas com anos de diferença entre si:

O conhecimento não transfere. A forma de escrever uma migração, o comportamento das transações e as mensagens de erro mudam entre versões maiores — então cada serviço tem particularidades próprias, e o que se aprendeu em um não vale no outro.

E o custo cresce sozinho: quanto mais tempo passa, maior o salto de versão acumulado e mais caro fica atualizar. É o exemplo mais literal de juros da lista.

Em quem trabalha em mais de um serviço — o que, num time pequeno, é todo o time. E aparece com força sempre que uma entrega precisa de migrações em mais de um serviço, rodando em ordem.

1. Escolher a versão alvo — a mais nova já em uso, a da dashboard.
2. Subir um serviço por vez, começando pelo de mídia, que é o menor e o mais isolado.
3. O servidor principal por último, porque é o que tem mais superfície e mais risco.
4. Fazer cada subida sozinha, sem migração de schema junto. Atualizar ferramenta de banco na véspera de uma migração grande é somar dois riscos sem necessidade.

Tarefa mecânica, com guia de migração público — o tipo em que a assistência de IA rende bem. O que importa é quando: numa entrega própria, nunca junto de uma migração grande.

Ao entrar no sorteio, o core guarda três sinais de risco para o antifraude: a marca do aparelho, a marca da faixa de rede e a idade da conta. A documentação do sorteio e o próprio schema prometem que eles são anulados 90 dias depois do sorteio — servem ao antifraude daquele sorteio e a nada mais. A coluna que registraria a anulação existe; nada a preenche.

É uma promessa de retenção escrita e não cumprida. Os sinais são pseudonimizados, não anônimos: combinados, ainda dizem algo sobre o aparelho e a rede de cada colecionador que participou. Guardá-los para sempre contraria a finalidade declarada — e a LGPD pede exatamente isso, que o dado viva só enquanto serve à finalidade.

Em todo colecionador que já entrou num sorteio. O volume cresce a cada edição, e o prazo de 90 dias de cada sorteio realizado passa sem que nada aconteça.

1. Acrescentar à varredura do sorteio um passo de retenção: para os sorteios realizados há mais de 90 dias, zerar deviceHash, networkHash e accountAgeDays e carimbar signalsPurgedAt.
2. Fazer o passo idempotente e em lote — a varredura roda a cada minuto, e a anulação só precisa acontecer uma vez por linha.
3. Mostrar no painel do sorteio quando os sinais já foram anulados, para ninguém estranhar a coluna vazia.

Pequeno e isolado: a coluna já existe e a varredura já roda. O que torna o item urgente não é o tamanho, é que a promessa está escrita — e cada sorteio novo aumenta o que precisa ser limpo.

Bilhetes e resultados do sorteio estão presos à conta do colecionador com exclusão em cascata. Se a linha do usuário for apagada de verdade, o banco apaga junto os bilhetes dele — e, se ele tiver ganhado, o próprio resultado. E o resultado não guarda uma cópia do nome do ganhador: sem a conta, não sobra registro de quem ganhou.

Hoje isso não acontece porque a exclusão de conta é soft delete — a linha fica, marcada como apagada. O único apagamento físico de usuário no código é o script de limpeza das contas de convidado, que não participam de sorteio.

O schema diz o contrário do que o sorteio promete: “vencedor nunca se edita” e a conta pode ser refeita por qualquer um a partir da semente revelada. Uma exclusão física — um pedido de apagamento pela LGPD atendido direto no banco, um script de limpeza novo — faria o resultado sumir, e a auditoria pública do sorteio passaria a apontar para um bilhete que não existe mais.

No histórico e na auditoria de todo sorteio já realizado, e na forma de atender um pedido de exclusão de dados. A proteção atual é uma convenção — ninguém apagar usuário de verdade —, não uma regra do banco.

1. Trocar a relação de raffleResult e raffleTicket com o usuário para onDelete: Restrict (ou SetNull, com o userId opcional), para que o banco recuse apagar a conta de quem tem bilhete ou resultado.
2. Copiar para o resultado, no momento do sorteio, o que precisa sobreviver à conta — o nome público do ganhador.
3. Definir o que a exclusão de conta faz com o sorteio: anonimizar o vínculo em vez de apagar a linha, preservando número do bilhete e resultado.

Uma migration pequena, mas com uma decisão por trás: o que o sorteio guarda de um colecionador que pediu para sair. Vale tomá-la antes que a primeira exclusão física aconteça, porque depois não há o que recuperar.