开发移动UI自动化框架，并在产品中而非CI里修复问题

## 把每处改动放进负责该行为的模块 维护一份简洁的模块图，说明代码在哪里运行，以及其产物由谁使用。至少应分离以下职责： - 设备端驱动程序及其生成的二进制文件； - 主机端平台适配器和协议客户端； - 命令解释、重试、生命周期控制和错误分类； - 共享命令模型和数据模型； - 命令行接口和面向代理的接口； - Web驱动程序、传输格式定义、工具以及跨模块测试。 将变更放在拥有该行为的模块中。设备交互和系统对话框处理属于平台驱动程序或主机适配器；重试和命令排序属于编排层；共享请求格式属于模型或协议模块。不得仅因为在远处的模块中更容易打补丁，就在那里解决归属问题。 将该模块图作为工作流和专业代理所依赖的唯一事实来源。模块职责发生变化时，应同步更新，避免下游指引产生偏差。 ## 选择能证明行为的最低成本测试层 使用分层测试策略，并默认选择能够证明该行为的最低成本测试层： 1. 对独立类、解析逻辑、小型工具和局部决策逻辑使用单元测试。 2. 对无需设备即可运行的命令编排、取消、脚本引擎、网络边界和多模块协作使用集成测试。 3. 对真实驱动程序、设备或浏览器行为、操作系统集成和完整用户流程使用端到端测试。 4. 当产品提供面向AI的协议时，对模型行为和工具正确性使用代理接口评估。 如果fake或进程内组件能够准确表达契约，就不要把测试提升到成本更高的层级。反之，如果风险来自平台行为，也不得用mock代替设备层证据。 ## 把必须通过和必须失败的测试套件分开 按照预期结果分离端到端流程。正向测试套件包含必须成功的流程，任何失败都是回归。负向测试套件包含有意无效的断言或命令，并且必须以预期方式失败。 测试框架可能会反转负向测试套件的成功判定，因此解释产物时必须保留测试套件标签。绝不能把符合预期的负向结果诊断为产品回归，也不能为了让负向流程通过而削弱或改写它。 当自动诊断流程读取产物时，除非其契约明确支持负向路径分析，否则只能处理正向测试套件中的真实失败。将产物存放在可预测的层级中，并包含应用、平台、测试套件和运行标识。 ## 用同一个fixture应用在所有平台上做端到端测试 使用一个默认fixture应用，在所有支持的平台上覆盖完整命令面。将同一组流程用于两个目的：对当前平台版本执行回归冒烟测试，以及对新引入的操作系统版本执行兼容性验证。 如果某种行为只属于特定框架，应添加专用fixture工作区，而不是扭曲默认应用。每个工作区拥有自己的流程和构建产物，并允许手动调度只执行一个应用或一个流程。 测试驱动程序应以平台和明确的环境输入为参数。在准备昂贵基础设施之前验证调度输入，尽早拒绝不支持的系统版本、缺失的工作区和含义不明确的流程选择器。 ## 设备上的失败要改驱动程序，不靠CI设置掩盖 如果端到端流程因为平台驱动程序无法处理真实设备行为而失败，应修复用户实际运行的驱动程序、主机适配器或fixture应用。不得通过向CI工作流添加模拟器设置、shell命令、命令行调整或预配置来掩盖缺口。 工作流变更只适合处理工作流本身的形态，例如矩阵、保留期限、触发器、已验证的调度输入，或范围明确且有文档说明的基础设施例外。它不能替代产品行为。 验证新的操作系统版本时也应遵循同一原则。如果某个流程只有在CI专用准备之后才能通过，那么除非该准备是明确告知用户的前提条件，否则产品仍存在兼容性缺陷。 ## 按能否重试区分错误，并始终清理临时文件 使用带有明确dispatcher或executor的结构化异步执行。阻塞式桥接只保留在应用入口。对外暴露的失败必须分类，使编排层能够区分可重试状态和终止错误，而不是对所有失败一律重试。 临时文件和目录必须通过拥有其生命周期的资源管理器处理。在拥有这些资源的操作附近创建管理器，通过其API分配资源，并在`finally`路径中关闭，使递归清理在成功、失败或取消后都能执行。 不得绕过资源管理器直接调用临时文件API。未受管理的文件会在长时间运行的worker中累积，使故障更难复现。不需要设备时，应使用行为确定的fake驱动程序和真实编排，测试取消、超时、supervisor行为和清理。 ## 分别测试面向代理的工具和模型行为 当命令行应用同时提供面向代理的服务器时，应保持两类不同的测试： - 验证请求、响应、设备设置和失败行为的工具功能测试； - 衡量代理能否正确选择并使用工具的模型行为评估。 使用声明式评估用例和平台专用设置脚本，确保覆盖范围可复现。普通实现变更运行快速工具测试；prompt、工具说明、schema、routing或代理可见行为发生变化时，运行速度较慢的模型评估。 不得把模型分数视为底层工具正常工作的证明，也不得把工具功能测试视为代理能够正确使用工具的证明。两个契约都需要各自的证据。 ## 通过构建重新生成二进制文件，不要手动修改 将已纳入版本控制的驱动程序二进制文件、打包runner、checksum以及其他派生产物视为生成器产物。绝不能手工编辑。运行所属的构建任务或finalizer，并将生成这些产物的源代码变更与产物一起提交。 完成前确认： 1. 变更位于拥有该行为的模块中。 2. 已运行足以成立的最低测试层，以及任何直接受影响的更高层测试。 3. 已按照各自契约解释正向与负向测试套件。 4. 已验证临时资源在成功、失败和取消后都会关闭。 5. 已通过官方构建路径重新生成派生产物。 6. 已确认CI变更描述的是基础设施形态，而不是在掩盖产品缺陷。 同步维护工作流文档、fixture布局和模块归属说明，使后续贡献者与自动代理遵守相同边界。