工程端 · ATH

判定规则

判定规则回答一个问题：什么算通过。规则的唯一定义在项目的判定图里，由 Rust 判定，界面只显示结果。

三种规则

类型	含义	典型用法
需求（requirement）	条件必须成立。	「电量读数应大于 0」。
清单（checklist）	按顺序收集证据项，全部到齐才算满足。	测试序列生成的就是清单规则。
不变式（invariant）	当条件成立时，断言必须成立。	「进入高速档时，转速不得超过阈值」。

比较与容差

支持的比较是相等、不等、小于、小于等于、大于、大于等于，以及区间。模拟量通常用区间加容差表达，避免把测量噪声判成失败。

两种「状态」不要混

层级	取值	含义
单条规则	等待 / 监测中 / 已满足 / 已违反 / 错误	这条规则当前处在什么阶段；「监测中」表示它正在观察，还没下结论。
整次判定	PASS / FAIL / PENDING / 错误	全部规则汇总后的结论。PENDING 表示还有条件未满足，也没被违反。

怎么改规则

在 ATH 里改

「判定规则」视图提供规则的增删改与试跑，改动走的是同一套校验与写入路径，保存后立即写入项目的判定图。

用命令行改

ath app rule-add    --rule ./rule.yaml     # 新增一条
ath app rule-update --rule ./rule.yaml     # 整体替换一条
ath app rule-delete --rule <RULE_ID>
ath app rule-list

让外部智能体改

ath dr context                 # 得到 graph_sha256 与规则统计
ath dr features                # 当前项目里可被规则引用的输入
ath dr validate ./rules.json   # 校验候选：语法、编译、输入引用、自带用例
ath dr submit ./rules.json     # 校验通过后并入判定图，并记一条不可变修订

dr submit 按规则 id 覆盖同一条规则，其余规则不受影响；任一诊断未通过就完全不落盘。离线写入必须带上从 dr context 得到的 --expected-sha，不一致会返回 dr_revision_conflict，此时重新读取再生成候选。

判定图与修订历史

界面与命令都不直接改图：候选先编译成图上的规则节点，再并入现有图。
整图路径保留给高级用法：ath judgment export / check / sync / import。导出的 JDM 文档可以在 JDM Editor 里打开。
规则级历史：ath dr history、ath dr diff、ath dr revert。回滚产生一条新修订，不修改历史。

常见输出字段

ath dr context --json
  data.project_id, data.graph_sha256, data.rule_count,
  data.input_count, data.page_owned_rule_count, data.latest_revision

ath dr submit --json
  data.added, data.changed, data.graph_sha256, data.revision_id, data.cases

这些字段就是外部智能体判断「我要改的图是不是我读过的那一版」的依据：先读摘要，提交时带上它，冲突就重读再提交。

改完怎么确认

ath dr test <RULE_ID> --case <CASE_ID>   # 用候选自带用例离线跑判定
ath judgment replay ./frames.jsonl       # 用录制帧离线判定
ath judgment explain --report <REPORT>   # 解释每条规则的状态与证据
ath judgment evidence --report <REPORT>  # 导出未通过规则的证据