为机器人与 AI 开发 Rust 数据流框架，按变更选对测试

## 搭建 Rust 工作区，把运行时分成四种角色 将系统组织为带有Python、C和C++绑定的Rust工作区。把最低工具链版本和共享包元数据放在工作区根目录，同时允许有明确文档说明的crate或示例固定独立版本。 使用四种职责明确的运行时角色： - 命令行客户端负责构建、启动、停止和检查数据流。 - 协调器负责管理跨机器的分布式生命周期。 - 每台机器上的一个守护进程负责生成节点，并管理本地与远程通信。 - 节点以进程方式运行用户代码；需要降低开销时，操作器在进程内运行。 将消息和协议定义放在共享库中，将描述符解析和构建工具放在核心库中，并将各语言API放在独立包中。不得让语言绑定的构建要求污染普通的纯Rust构建。 ## 语言绑定与 Rust 工作区分开构建 构建Rust工作区时，排除需要独立打包工具的语言绑定包。通过它们原生的绑定工具链构建这些包，不要强迫它们经过普通工作区命令。 支持三个迭代层级：整个工作区、单个包和单个测试目标。通过工作区的规范命令运行检查、测试、lint和格式化，并使用锁定的依赖项安装本地命令行工具。 在运行lint、测试、集成快照或文档检查之前先进行构建。普通工作区检查可能不会编译示例目标，因此示例目标需要显式的示例检查。 迭代期间可使用快速的包级测试，但发布前必须回到完整的受影响工作区。如果新增示例数据流，应在受支持的语言模式下运行示例冒烟测试套件。 ## 明确三种通信模式和共享内存的使用规则 以声明方式定义数据流。节点订阅命名输出，并声明自己的输出。提供定时器源，并在描述符中明确其频率或间隔。 保留三种彼此不同的用户通信模式： - Topic是默认的发布/订阅流。 - Service是请求/响应模式，通过`request_id`关联消息。 - Action通过`goal_id`和`goal_status`表示目标、反馈、结果和取消。 内部事件路由使用有界的多生产者通道，编排使用`async`运行时。机器之间使用分布式发布/订阅传输，并通过混合逻辑时钟维护因果顺序。 对于本地节点流量，大于4 KB的消息通过零拷贝共享内存发送，较小的消息通过TCP发送。明确记录阈值、所有权和回退行为；绝不得把本地共享内存与远程网络的语义合并成一条没有文档说明的路径。 ## 每次提交先审查和简化，再跑测试 每次提交在发布之前都必须完成以下门控： 1. 审查差异中的结构、安全和逻辑缺陷。 2. 简化不必要的复杂性、重复和低效。 3. 验证格式，以警告即错误的方式运行lint，至少运行受影响包的测试，并在发布前运行完整工作区测试。 4. 编译示例目标，防止API签名破坏隐藏在普通工作区依赖图之外。 每次提交前使用快速本地门控，包括格式、lint、依赖项审计、危险捷径用量和拼写检查。然后在发布前运行完整的必需测试命令。 不得跳过失败的门控，也不得依赖更慢的远程CI来发现问题。修复失败并重新运行受影响的门控。保持顺序不变：先审查和简化，再运行广泛测试，可以用更低成本修复设计缺陷。 ## 按风险选择耗时的深度测试，而不是每次都跑 不得在每次提交时运行所有深度套件，也不得把它们全部加入拉取请求CI。根据变更范围选择： - 需要更高置信度的重要发布之前，使用包含覆盖率的完整本地套件。 - 高风险或Tier 1变更使用包含变异测试和兼容性分析的深度验证。 - 跨平台、属性、解释器、形式证明和端到端覆盖使用耗时数小时的夜间同等验证。 - 分发前使用发布门控；独立安全审查、实际使用测试和迁移验证保持为由人工主导的独立门控。 - 完整变异审计可能耗时10至18小时，因此仅用于发布级测试评估或聚焦调查。 - 更改节点API、命令行为或描述符之后，端到端运行示例数据流。 - 更改受证明约束的模块时运行形式证明；性能剖析不能跨平台移植，因此应在目标操作系统和架构上运行配置文件引导优化。 将覆盖率、变异测试、兼容性、示例、形式验证和性能分析视为互补证据，而不是可以相互替代的手段。 ## 保持拉取请求 CI 快速，把耗时任务放到夜间 使拉取请求CI保持精简，以便快速提供阻塞式反馈。它应覆盖格式、警告即错误的lint、核心测试、端到端故障路径、语义契约、基准回归、拼写、供应链检查、危险捷径用量和许可证。 不得用耗时数小时的任务扩充阻塞式流水线。广泛验证应单独调度： - 在Linux、macOS和Windows上运行平台测试。 - 检查示例、命令行模板、动态语言节点、基准测试和交叉编译。 - 覆盖分布式生命周期、记录/重放、重连、状态重建、CPU亲和性、存储后端和桥接适配器。 - 验证最低支持编译器以及所有形式证明测试工具。 夜间任务失败应产生可跟踪的回归信号，但不必阻塞无关的拉取请求。如果变更依赖非默认平台或示例路径，则合并前应在本地运行相应检查。 ## 先写会失败的测试，再写刚好让它通过的代码 所有新功能和缺陷修复都遵循RED-GREEN-IMPROVE： 1. RED：编写定义预期行为的最小测试，并确认它因预期原因而失败。 2. GREEN：只实现足以让该测试通过的代码。 3. IMPROVE：在聚焦测试和受影响包测试持续通过的前提下重构。 根据行为选择首个测试层级。库函数从单元测试开始，协调器或守护进程行为从集成测试开始，命令变更从联网冒烟测试开始，数据流功能同时从联网和本地冒烟测试开始，缺陷修复则从能复现缺陷的最窄回归测试开始。 聚焦测试通过后，运行受影响包的测试、警告即错误的lint以及格式检查。如果变更涉及命令客户端、协调器或守护进程，则在共享端口或进程需要隔离的地方串行运行冒烟测试。 ## 示例数据流要在网络模式和本地模式下都跑冒烟测试 提供两种冒烟模式： - 联网模式启动分布式运行时，以分离方式启动数据流，轮询至完成，然后停止并拆除运行时。 - 本地模式在一个进程中运行数据流，并设置明确的停止期限。 新的示例数据流应同时通过两种模式。通过一次性守卫共享耗时的构建准备，不要为每个测试重新构建。 将命令传输和容错的端到端测试与普通单元测试分开。冒烟套件在成功和失败时都必须清理进程与端口，避免污染后续测试。 默认冒烟集合可排除需要不可用硬件、交互输入、多机器设置或不受支持的原生工具链的示例，但必须记录排除边界，并提供定向运行这些示例的方法。 ## 保持补丁范围小，并如实报告跑过哪些检查 提交变更之前，使用仓库默认格式化工具处理代码。非平凡设计变更应在实现前通过项目的决策渠道讨论。 不得在同一变更中修复无关警告或重构无关代码。限制补丁范围，使失败、审查和回滚仍可明确归因。 将语言包和命令行二进制文件视为不同的分发面。分别验证对应的包、绑定、兼容性和发布检查。 只有正确性门控通过后，才使用优化的发布配置。性能工作必须报告目标平台，并将可复现基线与优化构建进行比较。 交接之前，报告实际运行了快速、完整、深度、夜间、示例、证明或性能门控中的哪些，以及哪些仍未验证。绝不得暗示一个层级通过就证明另一个层级也已通过。