修改设备自动化工具的代码，并在真机上确认行为

## 先给请求分类，只读与改动相关的代码 先对请求进行分类。除非明确要求编辑或执行，否则仅提供信息的评审、分诊或提问都属于只读任务。代码变更请求则授权进行最小实现及该变更面所需的检查。 编辑前应说明假设并定义可观察的成功标准。阅读持久有效的领域词汇、适用的架构决策，以及负责该功能的配置或契约。默认情况下不要读取整个代码库。 从有界搜索开始： - 使用快速文本搜索定位符号、命令、标志或错误。 - 阅读负责该功能的模块、一个共享辅助模块，以及一个下游调用方或适配器。 - 对于大型文件，先找到相关类型或函数，再打开限定范围。 - 只有证据需要时，才沿导入关系和测试向外追踪。 除非任务明确跨越边界，否则将变更限制在单个命令族、平台接合边界或模块组内。不要仅仅因为存在两种平台实现就同时检查它们。如果必须扩大范围，应停下来确认新的边界。 编码前确定对文档、帮助、模式和技能的影响。优先引用持久的事实来源，而不是会随时间失准的文件清单。 ## 把命令的名称和选项集中在一个注册表中 为每个命令设置一个拥有其身份、能力、超时策略、批处理策略和公共投影的规范描述符。将守护进程或服务路由保存在路由注册表中，将交互路径保证保存在类型化矩阵中，并将命令名称保存在统一目录中。不要在处理程序中重新创建字符串集合。 让顶层路由器保持轻量，只负责编排。将请求路由到负责该功能的处理程序族；不要在入口点累积命令逻辑。能力决策应位于能力事实来源中，而不是散落在各处的条件判断中。 让每个公共选项只流经能够理解它的层： 1. 定义公共标志及其语法。 2. 将其加入负责该命令的元数据和架构。 3. 将其解析为命令输入。 4. 只有运行时执行需要它时，才将其投影到服务请求中。 5. 只有相关接口会公开它时，才扩展类型化客户端和规范化器。 6. 只有公共契约证明它属于分派层和平台模块后，才将其传递到这些位置。 7. 在架构进度模型或覆盖模型中对每个公共选项进行分类。 集中处理选择器的语法解析、匹配、目标解析和谓词求值。针对元素的操作应接受稳定选择器或已记录引用，保留其选择器链，并将回放偏差作为建议呈现，而不是静默改写用户状态。 ## 确认快速路径和缓存路径的行为与主路径一致 应假设保证会在路径边界处弱化。添加快速路径、委托路径、缓存路径或平台专用路径时，必须先对所有受影响的命令与路径单元格进行分类，才能声称具有同等保证。 注册表条目并非语义证明。阅读实现并验证其满足保证的定义。只有在出错后才委托的回退不能证明成功路径具有同等行为；快速路径可能接受共享路径会拒绝的输入。 测量实验前，先证明每个实验分支都能执行。如果变更后的分支从未触发，那么两次通过的运行毫无意义。记录路径、后端、原因代码，以及证明由哪项实现处理请求所需的其他类型化证据。 使用结构化信号，不要解析面向人的消息。根据原因代码、类型化详情和明确的超时值进行分支判断；不要复制依靠嗅探错误文本的逻辑。任何不可避免的消息匹配都应在决策位置记录为技术债。 通过共享响应构建器组合警告，而不是覆盖先前的警告。响应级元数据只存储一次，不要为每个节点或项目重复相同字节。 保留兼容字段前，先确定它是否已经发布。未发布的表面可以直接移除；已发布的表面需要迁移和兼容性处理。 ## 保持文件短小，让测试与源码结构对应 只在信任边界使用`unknown`，例如已解析输入、运行时载荷、捕获的错误和通用I/O。验证一次后，将其收窄为领域类型或专用解析器，不要让不确定性继续穿过内部辅助函数和格式化程序。 当语言能够使遗漏情形变得不可能时，优先使用类型级完整性检查。将机器可读的声明与其描述的代码放在一起：注册表单元格放在约束执行位置的指针旁，覆盖清单放在契约测试旁，决策注释放在其所解释的分支处。 让每个模块只负责回答一个问题。作为实用警戒线，实现文件以大约300行为目标；超过500行后，应先改善局部性再添加行为；超过1,000行时，除非它是生成数据或夹具快照，否则应将该文件视为架构债务。 按文件所回答的领域概念命名。只在软件包边界使用聚合导出文件；内部聚合导出文件会增加导航跳转。仅当深层模块能改善概念归属时才提取它，而不是单纯为了减少行数。 在测试中镜像源代码拓扑。拆分源模块时，应在同一变更中拆分其测试。将可复用夹具放入具名的同级夹具模块，不要复制大型内联对象。不要仅仅为了便于测试私有细节而添加生产环境导出。 最终确定前，收紧已触及及其直接相邻的代码：移除过时分支、冗余测试、未使用的导入、陈旧夹具，以及因本次变更而不再必要的重复内容。避免无关清理。 ## 务必关闭设备会话，把日志和诊断分开保存 通过共享进程抽象路由进程执行。如果缺少某项能力，应扩展该抽象，而不是在整个代码库中导入底层进程原语。 将每个手动打开的设备会话视为一项资源。记录其会话名称、平台、设备标识符和状态目录，并在结束前用相同的值将其关闭，即使实验失败也不例外。只停止属于本次验证运行的确切过期进程；绝不能凭猜测终止大范围进程组。 明确区分应用程序日志、运行器输出和请求诊断。应用程序日志捕获应只由单一后端负责。将请求诊断存储在解析后的会话和请求标识符之下；顶层守护进程日志只用于生命周期，以及会话解析前发生的故障。 集中管理诊断范围、计时器、事件发出、脱敏和产物路径构建。诊断服务负责这些数据时，不要手工构造日志路径或添加临时文件。 将面向用户的故障规范化为稳定载荷，其中包含代码、简洁消息、恢复提示、诊断标识符、日志路径和类型化详情。包装错误时保留这些字段。说明失败了什么、已知时说明原因，并给出下一步恢复操作。 可选探测、缓存检查和预检应按尽力而为处理，除非功能契约规定它们为必需。为它们设置比必要操作更短的超时，并在其失败或返回不可用结构时回退到既定路径。 ## 根据改动的部分选择要运行的测试 如果代码库提供受影响检查规划器，应先使用它。它应从规范元数据推导聚焦测试和剩余门槛，而不是依赖手写清单。 将检查映射到变更表面： - 任何类型化源代码变更都需要类型检查和格式化。 - 工具链或编译器配置变更需要运行工具门槛和声明构建。 - 共享服务或处理程序变更需要运行聚焦单元测试包。 - 响应结构或提供商边界变更需要运行提供商集成和覆盖检查。 - 原生运行器变更需要重新构建原生测试产物。 - 跨平台行为需要运行跨平台集成测试套件。 - 只有更具体的契约提出要求时，纯文档工作才需要运行时测试。 当聚焦证据足够时，默认不要运行宽泛的集成测试。反过来，也不要仅凭单元测试就宣称面向设备的变更已准备就绪。 测试应关注行为。不要断言静态类型已经证明的内容。单元测试不得按真实时间等待；应注入时间预算、由预算推导节奏，或断言预算已正确接入。 当执行门槛发现未分类标志、保证单元格缺失、场景未覆盖、绕过响应构建或规则不一致时，应对新行为进行分类或补充覆盖。绝不能抑制门槛，也不能添加没有说明的允许列表条目。 ## 重新构建后，在真机或模拟器上确认行为 手动验证前，重新构建运行时实际使用的每项产物，重启无法热重载的服务，并使任何可能继续提供旧版原生二进制文件的已采用运行器失效或被替换。针对过期输出的测试属于假阴性，而不是产品证据。 证明由哪个后端处理了本次运行。捕获机器可读的快照或状态响应，并对照当前软件包验证后端标识符和辅助程序版本。只有正在测试的功能就是回退行为时，静默回退才算有效证据。 并发工作树应使用不同设备、模拟器或仿真器，因为隔离的守护进程状态并不能隔离物理目标。遵循测试应用自身的设置指南；仅安装应用还不够，除非构建、开发服务器和目标表面检查都证明运行的是预期版本。 调试产品代码前，先对环境噪声进行分类。在隔离环境和未变更基线上，以相同负载复现资源争用故障。故障集合不断变化但单独运行时通过，通常表明存在资源争用；变更路径上稳定出现的故障则是更有力的回归证据。 如果沙箱阻止所需的本地侦听器、设备桥接或原生工具，应通过已批准的提权路径重新运行，而不是将沙箱拒绝诊断为产品缺陷。如果现场验证仍受阻，应报告所需的确切设备、权限、命令或服务，并保留剩余风险。 ## 沿真实的命令路径评审，并附上真机结果汇报 评审应依据提出变更的议题和已接受的架构决策，而不应只看差异。沿生产路径从命令表面，经请求路由追踪到平台后端。绕过路由器或模拟关键接缝的测试不能证明已交付行为。 对每项关键回归测试，确定哪个旧实现、删除操作或还原操作应使其失败。如果缺陷重新出现后测试仍然通过，该测试就是空洞的，必须加强。 将预期重构与输出结构、警告传播、错误详情、产物路径、重试层级和回退中的隐藏行为变更区分开。实现依赖另一项变更时，应验证同级变更和分支顺序。 将对外发布或推送置于一条统一的成功链之后，使其无法在格式化、类型、lint或测试命令失败后运行。保持提交和拉取请求范围明确，使用项目惯用的标题风格，并且只在工作完成时才默认发起可立即评审的请求。 总结用户可见行为、有意义的验证、真实设备证据和实际取舍。不要凭本地单元测试就宣称CI通过，也不要在缺少当前现场证据时宣称平台变更已可合并。说明文档或帮助所受影响、触及范围、任何未验证路径以及确切阻碍因素。 交接前关闭所有会话，并说明验证期间打开的每项资源。报告任何无法清理的会话、进程、状态目录或产物。