工程端 · ATH

在 ATH 里验证

交付之前，先自己用真机走一遍。验证的目标不是「页面动起来了」，而是「判定结果符合预期」。

先把三件事分开

现象	含义
收到数据	设备发来了报文，不代表它有意义。
输入发生变化	活动状态改变，组件与指示线据此高亮。
测试通过	判定引擎按规则得出结论，只有这种情况才算 PASS。

页面上的高亮只能证明第二件事。要不要算通过，看的是判定结果，两者不能互相代替。

接真机走一遍

01连接设备在设备栏选中并连接待测设备；连不上时按设备与连接里的顺序排查。
02按序列操作按测试序列操作设备，观察组件与指示线是否在同一帧高亮 —— 这一步确认「页面对不对」。
03读判定看每条规则的状态是否从「监测中」走到「已满足」，最终整体结论是不是 PASS。没走到位就看证据，而不是先改规则。
04记录结果有偏差时用 ath feedback add 把观察记进项目，别只留在脑子里；之后可以在不改项目的前提下分析这些反馈。

没有设备时怎么验

ath judgment replay ./frames.jsonl          # 用录制帧离线跑判定
ath dr test <RULE_ID>                        # 用候选自带用例试跑一条规则
ath run ./scenario.yaml                      # 虚拟场景跑一次完整判定
ath simulate replay ./capture.jsonl          # 回放一份原始 HID 录制
ath preview --page <PAGE_ID>                 # 只看页面渲染模型

这几条都不访问真机。先用它们把逻辑跑顺，再接设备确认，能省下大量插拔时间。

收集证据

ath validate --output-ir ./ir.json          # 导出规范化的测试 IR
ath judgment explain --report <REPORT>      # 每条规则的状态与证据
ath judgment evidence --report <REPORT>     # 未通过规则的证据
ath frontend                                 # 观察 ATH 交给界面的数据（不回溯历史）

规范化的 IR 是「项目最终会被怎样执行」的权威表达，适合拿来做差异比较。
解释与证据输出都是为了回答「为什么它判成了这样」。
怀疑刷新或时序问题时，用 frontend 看界面实际收到了什么。

验完就存一版

ath version create --name "首版"     # 记录不可变快照
ath version validate                  # 校验并标记为已校验
ath version release                   # 标记为已发布

验证通过的状态值得被固定下来：产线换版、判定规则调整、出现争议需要回看时，快照是唯一的依据。