Cinco agentes de IA, um checkout só, e um comando que juntou trabalho de sessões diferentes

O jeito que este projeto é trabalhado

Neste site, várias sessões de Claude Code costumam rodar em paralelo, dividindo o mesmo diretório de trabalho local. Cada sessão cuida de uma tarefa diferente, e é comum que a raiz do repositório acumule dezenas de arquivos soltos de trabalhos simultâneos: rascunhos de análise, relatórios temporários, planilhas exportadas. Nenhum desses arquivos pertence necessariamente à tarefa que uma sessão específica está executando naquele momento.

Nesse terreno, um comando que costuma ser inofensivo em outros contextos deixa de ser um atalho e passa a ser um risco: git add -A, ou sua variação git add ., que adiciona ao commit absolutamente tudo o que está modificado ou novo no diretório, sem distinguir o que pertence à tarefa em andamento do que pertence a outra sessão.

O que aconteceu

Duas sessões diferentes estavam ativas na mesma janela de tempo. Uma delas usou git add -A ao preparar seu commit, e isso incluiu, sem intenção, dois arquivos que pertenciam ao trabalho de outra sessão. Esses arquivos entraram em pull requests que não tinham relação com eles.

Isso aconteceu em 09 de setembro de 2026, e o dado que importa não é a data em si, é a origem: nenhuma das duas sessões tinha como saber que a outra existia. A primeira tentativa de resposta foi de processo: combinar entre as sessões que ninguém usaria git add -A daquele momento em diante. Isso não resolveu, pelo motivo mais simples possível: a sessão que causou o incidente já tinha encerrado antes de qualquer combinado existir. Um acordo só vale para quem está presente para ouvi-lo, e não há garantia de que a próxima sessão a rodar nesse ambiente vai conhecer o combinado da sessão anterior.

A resposta que não depende de lembrança

A correção que ficou não foi um novo combinado, foi um hook determinístico: um script que roda antes de qualquer comando Git ser executado, verifica se o comando é uma das formas de "adicionar tudo" (-A, --all, ., ./, :/, *, e as formas agrupadas como -Av), e bloqueia a execução se for.

O escopo do bloqueio foi definido de forma estreita, de propósito. Ele não impede git add de um caminho específico, não impede git add -p (que adiciona trechos escolhidos interativamente), não impede commit nem push. Uma sessão que já trabalha do jeito correto, adicionando só os arquivos da própria tarefa, nunca esbarra no bloqueio. O guardrail existe só para o caminho que causou o problema.

Por que um script, e não uma instrução

A diferença entre as duas abordagens é a diferença entre lembrar e não poder esquecer. Uma instrução escrita, por mais clara que seja, depende de cada sessão futura ler, entender e aplicar corretamente, todas as vezes. Um hook determinístico roda como processo separado, inspeciona o comando antes dele executar, e recusa a ação incompatível, independentemente de qualquer sessão ter lido ou lembrado de alguma regra.

A regra em si (adicionar só o que pertence à própria tarefa) sempre existiu como boa prática. O que mudou não foi a regra. Foi o mecanismo que garante que ela se aplica mesmo quando ninguém está prestando atenção nela.

Como o guardrail foi verificado, não só escrito

A parte que dá confiança nesse tipo de mecanismo não é o bloqueio em si, é a prova de que ele não atrapalha o que devia continuar funcionando. Foram escritos 23 casos de teste, chamando o hook como processo separado, com o mesmo formato de entrada que o Claude Code usa de verdade. Uma parte desses casos testa o que deve ser bloqueado (-A, --all, ., ./, :/, *, e formas agrupadas como -Av). A outra parte, igualmente importante, testa o que precisa continuar passando: git add de um caminho específico, o modo interativo -p, e até texto que menciona o comando bloqueado sem executá-lo de fato. Um guardrail sem essa segunda categoria de teste corre o risco de virar tão inconveniente que alguém acaba contornando ele, o que anularia o motivo de existir.

Veja as outras peças desta série: o cache de borda que derrubou a produção duas vezes, a migração que estourou o tempo limite do Postgres, e a calculadora que recusava toda execução em silêncio.