Desenvolva um framework de fluxos de dados em Rust para robótica e IA escolhendo os testes conforme a mudança

## Monte o espaço de trabalho Rust e divida o ambiente de execução em quatro papéis Organize o sistema como um espaço de trabalho Rust com bindings para Python, C e C++. Mantenha a versão mínima da cadeia de ferramentas e os metadados compartilhados dos pacotes na raiz do espaço de trabalho, permitindo que crates ou exemplos explicitamente documentados fixem versões independentes. Use quatro funções de execução com responsabilidades claras: - Um cliente de linha de comando compila, inicia, interrompe e inspeciona fluxos de dados. - Um coordenador gerencia o ciclo de vida distribuído entre máquinas. - Um daemon por máquina cria nós e gerencia a comunicação local e remota. - Os nós executam o código do usuário como processos, enquanto os operadores são executados dentro do processo quando é necessário reduzir a sobrecarga. Mantenha as definições de mensagens e protocolos em uma biblioteca compartilhada, a análise de descritores e os utilitários de compilação em uma biblioteca central, e as APIs de linguagem em pacotes separados. Não permita que os requisitos de compilação dos bindings contaminem as compilações normais exclusivas de Rust. ## Compile os bindings de linguagem separados do espaço de trabalho Rust Compile o espaço de trabalho Rust excluindo pacotes de bindings que exijam uma ferramenta de empacotamento separada. Compile esses pacotes com a cadeia de ferramentas nativa de bindings, em vez de forçá-los a passar pelo comando normal do espaço de trabalho. Ofereça três níveis de iteração: o espaço de trabalho completo, um pacote e um alvo de teste. Execute verificações, testes, lint e formatação por meio dos comandos canônicos do espaço de trabalho e instale ferramentas locais de linha de comando com dependências bloqueadas. Compile antes de executar lint, testes, snapshots de integração ou verificações de documentação. Os alvos de exemplo precisam de uma verificação explícita, pois uma verificação geral do espaço de trabalho pode não compilá-los. Use testes rápidos de pacote durante a iteração, mas volte ao espaço de trabalho afetado completo antes da publicação. Se um novo fluxo de dados de exemplo for adicionado, execute a suíte de testes de sanidade dos exemplos no modo de linguagem compatível. ## Deixe claros os três padrões de comunicação e a regra de memória compartilhada Defina fluxos de dados de forma declarativa. Os nós assinam saídas nomeadas e declaram suas próprias saídas. Forneça fontes temporizadoras e mantenha sua frequência ou intervalo explícito no descritor. Preserve três padrões distintos de comunicação voltados ao usuário: - Tópico é o fluxo padrão de publicação e assinatura. - Serviço usa solicitação e resposta e correlaciona mensagens por meio de `request_id`. - Ação representa objetivo, retorno, resultado e cancelamento por meio de `goal_id` e `goal_status`. Use canais limitados de múltiplos produtores para o roteamento interno de eventos e um ambiente de execução assíncrono para a orquestração. Use um transporte distribuído de publicação e assinatura entre máquinas e um relógio lógico híbrido para a ordem causal. Para o tráfego entre nós locais, envie mensagens maiores que 4 KB por memória compartilhada sem cópia e mensagens menores por TCP. Mantenha explícitos o limite, a propriedade e o comportamento alternativo; nunca reúna a semântica da memória compartilhada local e da rede remota em um único caminho não documentado. ## Revise e simplifique cada commit antes de rodar os testes Cada commit deve concluir estes controles antes da publicação: 1. Revise o diff em busca de defeitos estruturais, de segurança e de lógica. 2. Simplifique complexidade, duplicação e ineficiência desnecessárias. 3. Verifique a formatação, execute lint tratando avisos como erros, execute pelo menos os testes do pacote afetado e execute os testes do espaço de trabalho completo antes da publicação. 4. Compile os alvos de exemplo para que quebras de assinatura de API não fiquem ocultas fora do grafo normal do espaço de trabalho. Use um controle local rápido antes de cada commit, incluindo formatação, lint, auditoria de dependências, orçamento de atalhos inseguros e verificação de erros tipográficos. Em seguida, execute o comando completo de testes exigido antes da publicação. Não pule um controle que falhou nem dependa da CI remota, mais lenta, para detectar o problema. Corrija a falha e execute novamente o controle afetado. Preserve a ordem: revisão e simplificação tornam os defeitos de projeto mais baratos de corrigir antes dos testes amplos. ## Escolha os testes profundos pelo risco em vez de rodá-los a cada commit Não execute todas as suítes profundas em cada commit nem adicione todas elas à CI dos pull requests. Selecione-as conforme o escopo da alteração: - Use a suíte local completa, incluindo cobertura, antes de uma publicação importante quando for necessária confiança adicional. - Use validação profunda com análise de mutações e compatibilidade para alterações de alto risco ou de Tier 1. - Use uma validação equivalente à noturna, com várias horas de duração, para cobertura multiplataforma, de propriedades, interpretadores, provas formais e ponta a ponta. - Use o controle de lançamento antes da distribuição; mantenha a revisão de segurança independente, os testes de uso real e a validação de migração como controles separados conduzidos por pessoas. - Use uma auditoria completa de mutações apenas para avaliar testes com qualidade de lançamento ou para uma investigação específica, pois ela pode levar de 10 a 18 horas. - Execute os fluxos de dados de exemplo de ponta a ponta depois de alterar APIs de nós, comportamento de comandos ou descritores. - Execute provas formais ao alterar módulos sujeitos a elas e realize a otimização guiada por perfil no sistema operacional e na arquitetura de destino, pois os perfis não são transferíveis. Trate cobertura, mutações, compatibilidade, exemplos, verificação formal e análise de desempenho como evidências complementares, não como substitutos intercambiáveis. ## Mantenha a CI de pull request rápida e deixe os jobs longos para a noite Mantenha a CI dos pull requests leve o suficiente para fornecer rapidamente resultados bloqueantes. Ela deve abranger formatação, lint com avisos tratados como erros, testes centrais, caminhos de falha ponta a ponta, contratos semânticos, regressões de benchmark, erros tipográficos, verificações da cadeia de suprimentos, orçamentos de atalhos inseguros e licenciamento. Não amplie o pipeline bloqueante com tarefas de várias horas. Agende separadamente a validação ampla: - Execute testes de plataforma em Linux, macOS e Windows. - Exercite exemplos, modelos de linha de comando, nós de linguagens dinâmicas, benchmarks e compilação cruzada. - Cubra o ciclo de vida distribuído, gravação e reprodução, reconexão, reconstrução de estado, afinidade de CPU, backends de armazenamento e adaptadores de ponte. - Verifique o compilador mínimo compatível e todos os mecanismos de prova formal. Falhas noturnas devem gerar um sinal de regressão rastreável, mas não precisam bloquear um pull request não relacionado. Antes da mesclagem, execute localmente verificações de plataformas não padrão ou de exemplos quando a alteração depender desses caminhos. ## Escreva primeiro um teste que falhe e depois só o código para ele passar Todos os novos recursos e correções de falhas seguem RED-GREEN-IMPROVE: 1. RED: escreva o menor teste que defina o comportamento esperado e confirme que ele falha pelo motivo pretendido. 2. GREEN: implemente somente o código necessário para que esse teste passe. 3. IMPROVE: refatore mantendo aprovados os testes específicos e os testes do pacote afetado. Escolha o primeiro nível de teste conforme o comportamento. Comece funções de biblioteca com testes unitários, comportamento do coordenador ou daemon com testes de integração, alterações de comandos com testes de sanidade em rede, recursos de fluxo de dados com testes de sanidade em rede e locais, e correções de falhas com o teste de regressão mais restrito que reproduza o defeito. Depois que o teste específico passar, execute os testes do pacote afetado, lint tratando avisos como erros e verificações de formatação. Se a alteração afetar o cliente de comandos, o coordenador ou o daemon, execute também os testes de sanidade em série onde portas ou processos compartilhados precisarem de isolamento. ## Rode os fluxos de exemplo nos modos de smoke test em rede e local Forneça dois modos de teste de sanidade: - O modo em rede inicia o ambiente de execução distribuído, inicia um fluxo de dados desacoplado, consulta até a conclusão e depois interrompe e encerra o ambiente. - O modo local executa o fluxo de dados em um processo com um prazo explícito de interrupção. Novos fluxos de dados de exemplo devem passar nos dois modos. Compartilhe a preparação de compilação dispendiosa por meio de uma proteção de execução única, em vez de recompilar para cada teste. Mantenha os testes ponta a ponta de transporte de comandos e tolerância a falhas separados dos testes unitários comuns. As suítes de sanidade devem limpar processos e portas tanto em caso de sucesso quanto de falha, para não contaminar testes posteriores. Exclua do conjunto padrão de testes de sanidade os exemplos que exijam hardware indisponível, entrada interativa, configuração com várias máquinas ou cadeias de ferramentas nativas sem suporte; documente o limite de exclusão e forneça uma forma específica de executá-los. ## Mantenha as mudanças pequenas e informe exatamente quais verificações rodaram Formate com o formatador padrão do repositório antes de enviar alterações. Discuta alterações de projeto não triviais pelo canal de decisão do projeto antes da implementação. Não corrija avisos não relacionados nem refatore código fora do escopo na mesma alteração. Mantenha o patch limitado para que falhas, revisão e reversão continuem atribuíveis. Trate os pacotes de linguagem e os binários de linha de comando como superfícies de distribuição separadas. Verifique para cada um os controles apropriados de pacote, bindings, compatibilidade e lançamento. Use um perfil de lançamento otimizado somente depois que os controles de correção passarem. O trabalho de desempenho deve informar a plataforma de destino e comparar uma linha de base reproduzível com a compilação otimizada. Antes da entrega, informe quais controles rápidos, completos, profundos, noturnos, de exemplos, de provas ou de desempenho foram realmente executados e quais permanecem sem verificação. Nunca sugira que um nível aprovado comprova que outro nível também passou.