Replit travado: falha do Agent em projeto comercial

Meu projeto comercial no Replit está parado desde 10 de setembro, quando o Agent passou a falhar em um ou dois segundos com a mensagem de erro genérica, mesmo depois de eu limpar todo o contexto. Já são mais de sete dias, cerca de vinte contatos e vários chamados abertos, e o Replit segue respondendo com autoajuda automática em vez de colocar um engenheiro para inspecionar e restaurar o meu ambiente. Continuo sem acesso, sem diagnóstico e sem previsão.

Por que toda solicitação ao Replit falhava em segundos

O último checkpoint bem-sucedido do meu projeto Squadsight HQ foi às 9h26, e a partir dali o Replit simplesmente parou de executar qualquer tarefa. Cada pedido que eu enviava ao Agent morria em um ou dois segundos com a mensagem de erro genérica da plataforma, inclusive depois de eu limpar todo o contexto da conversa, o que deveria eliminar qualquer suspeita de histórico corrompido do meu lado. Uma cópia duplicada do mesmo projeto também apareceu incompleta, o que reforça que o problema não estava no meu uso, mas em alguma condição interna do ambiente.

Tentei as variações que estavam ao meu alcance: reabri o workspace, refiz o pedido em uma sessão nova, esperei e testei outra vez em horários diferentes do dia. O comportamento foi idêntico durante sete dias seguidos, sem uma única execução concluída. Para um produto comercial que dependia daquele ambiente, cada dia parado significou desenvolvimento travado e nenhuma previsão de retomada. O ponto central é que o Replit reconhecia o padrão de erro, mas continuava tratando o caso como um problema de configuração meu, e não como uma falha da própria plataforma que precisava ser investigada por quem tem acesso ao backend.

A inspeção do diretório .git que o Replit empurrou para mim

Quando finalmente veio uma resposta menos automática, ela dizia que meu workspace estava sendo sinalizado para revisão de um colega de equipe e, na frase seguinte, me pedia para rodar comandos de Shell e verificar se o diretório .git passava de 8 GB. A mesma mensagem afirmava que aquele padrão é um indicador conhecido de saturação do diretório por uso intenso e que existe correção direta caso a condição se confirme.

Se a própria plataforma reconhece o padrão como conhecido, o trabalho de verificar, diagnosticar e reparar deveria ser feito pela engenharia do Replit, não por mim. Eu não tenho visibilidade do filesystem interno, do estado dos checkpoints, da autenticação do ambiente nem do consumo de quota da conta. Rodar comandos de diagnóstico no escuro não restaura o meu projeto e não devolve o acesso ao Agent. O que eu pedi, desde o primeiro dia, foi que alguém com acesso de arquitetura entrasse no workspace, confirmasse a condição, explicasse a causa e executasse o reparo com segurança, confirmando depois que código e arquivos continuavam íntegros.

Os chamados que o Replit encerrou sem restaurar o projeto

Foram cerca de vinte contatos distribuídos em vários chamados, e o padrão se repetiu em todos: confirmação automática, conversa de autoajuda, pedido para eu diagnosticar a falha da plataforma e, no fim, encerramento sem restauração, sem diagnóstico técnico e sem um responsável técnico identificado. Um dos chamados foi marcado como resolvido apenas porque ficou dois dias sem atualização. Um incidente de plataforma não vira resolvido porque um cronômetro automático expirou.

O que eu queria era objetivo: consolidar os chamados em um incidente único, inspecionar o workspace, verificar se a saturação do .git ou outra condição de backend causou a parada, checar estado de quota, autenticação e checkpoints, restaurar o Squadsight HQ a partir do último estado saudável e entregar um relatório técnico por escrito. Nada disso aconteceu. O Replit continuou fechando tickets enquanto o meu produto seguia parado, e a sensação é de que o suporte existe para encerrar conversa, não para resolver incidente.

Depois de sete dias e vinte contatos, eu não preciso de mais um artigo de autoajuda nem de mais uma tarefa de diagnóstico. Preciso que o Replit atribua um responsável técnico humano, consolide os chamados e faça a restauração do ambiente. Enquanto isso não acontece, minha avaliação é negativa e continua negativa: uma plataforma que reconhece um padrão de falha e ainda assim transfere o trabalho de reparo para o cliente não sustenta a confiança de quem depende dela para tocar um produto comercial.