Nenhuma Daquelas Correções Funcionou Depois de Atualizar a Página

As rotas estavam corrigidas. O endpoint de estado foi reescrito. O formato dos dados foi corrigido. Cada mudança confirmada no repositório, visível no arquivo, exatamente como pretendido.

Atualizei o navegador. Nada mudou.

A mesma tabela quebrada. O mesmo canvas em branco.

O Que Estava Realmente Acontecendo

A plataforma roda localmente em Docker — um conjunto de containers, cada um executando um serviço, conectados através de uma configuração compartilhada. A aplicação web front-end é montada por volume: os arquivos fonte no disco são mapeados diretamente para o container. O Vite, a ferramenta de build, observa mudanças de arquivos e recarrega o navegador automaticamente.

Exceto que não estava observando.

No Windows com Docker rodando sobre WSL2 — a camada de compatibilidade Linux que o Windows usa para containers — as notificações de eventos do sistema de arquivos das quais o Vite depende para detectar mudanças não se propagam corretamente através da fronteira de virtualização. O sistema de notificação do Linux reporta a mudança. O Windows não a encaminha. O Vite nunca vê a atualização do arquivo. O navegador continua servindo o código que estava lá antes.

A correção foi uma linha na configuração do Vite: usePolling: true. Em vez de esperar ser notificado das mudanças, o Vite verifica a cada 300 milissegundos. É ligeiramente menos eficiente. Funciona.

O table engine — o serviço backend que gerencia o estado real do jogo — tinha sua própria versão do mesmo problema. Serviços backend nesta stack não rodam com modo watch. Mudanças de código requerem reiniciar o container manualmente. Comportamento padrão para um serviço de produção. Você só precisa saber que tem que reiniciar.

A Outra Coisa Que Estava Errada

Uma vez resolvidos os problemas de ambiente, um terceiro bug surgiu: a rota da mesa tinha um auth guard que sempre mandava o navegador para a página de login.

Não porque o usuário não estivesse logado. Estava. O guard estava verificando um valor de contexto do TanStack Router que nunca era populado — o router foi configurado sem um context provider, então context.auth sempre era undefined. O guard lia "não autenticado", redirecionava para login. Login via uma sessão autenticada, redirecionava de volta para o lobby. O navegador entrava em loop.

Uma linha alterada. O guard foi atualizado para ler diretamente do authentication store, o mesmo padrão que toda outra rota na aplicação usa. Corrigido.

O Que Isto Exige da Pessoa No Teclado

As correções estavam corretas. O sistema não estava captando elas. Essa observação — que código correto e código rodando são duas coisas diferentes — exigiu conhecer o ambiente de desenvolvimento bem o suficiente para fazer a pergunta certa.

O agente pode escrever a correção. Pode rastrear o bug uma vez que você o descreve. Não pode notar que o navegador está servindo uma versão em cache do código de antes da mudança de configuração. Essa observação é humana.

Conhecer o sistema bem o suficiente para diagnosticar por que uma correção correta não está surtindo efeito — essa é a parte que não se automatiza.

Depois da configuração de polling, depois dos restarts de container, depois da correção do auth guard: a mesa carregou. Os assentos apareceram. O diálogo de buy-in renderizou. Os cards do lobby tinham a altura certa. Tudo funcionou.

O próximo post cobre como ficou o integration testing uma vez que tínhamos um sistema funcionando para testar — e por que essa fase se parece igual independente de quem escreveu o código, AI ou humanos.

Para a perspectiva do founder sobre navegar esse tipo de processo de debugging — o que o papel human-in-the-loop realmente exige quando AI escreveu a maior parte do codebase — está em The Salty Korean.

Stay salty.