proof-orchestrator 的用途是选择证明方案，而不是充当证明本身。核心规则是把声明映射到仍然诚实的最低证明级别；若用户要求更高级别，则采用更强级别。证明级别包括：implemented（文件、配置或文档已改动并检查）、code_proven（当前源码检查支持声明）、test_proven（有新鲜的自动化测试支持）、runtime_proven（在受支持的运行时路径上有新鲜证据）、end_to_end_proven（在真实用户可见路径上有新鲜证据）。不得把一级升级为另一级，证据弱于声明时应说 not_proven_yet。
使用流程：先把声明改写成可证伪句子；确定所需证明级别及原因；路由到能够证伪它的最小现有技能或证明面；运行或请求证明，不得把过期证明当作当前证明；报告最强安全真相、证明缺口和下一步证明。
证明路径按场景选择：Bug、回归、崩溃、变慢、不稳定行为先用 $diagnose 建立反馈回路，再用新鲜证据证明修复；带可测量基线/处理的具体声明用 $verify-this；代码审查或行为回归风险先走 review 模式，发现优先于总结；GitHub PR/CI 真相使用 GitHub/CI 证明面，只报告当前检查所证明的内容；UI 或浏览器行为在有条件时使用真实预览/浏览器路径，截图不足以支撑交互声明；CLI/TUI 行为使用真实终端记录或确定性命令输出，避免仅靠视觉推断；文档/当前版本真相应先检查源码文档或官方上游；安全或供应链安全优先源码检查、版本锁定、公告检查和最小执行；人在回路、审批、凭证、付费操作、私有数据、法律/商业决策应停在人工关口，重复/继续/恢复不视为批准。
措辞需精确：implemented 仅用于改动的文件或配置；test_proven 仅在相关新鲜测试实际运行并通过时使用；runtime_proven 仅在受支持运行时路径被执行时使用；end_to_end_proven 仅在真实用户可见流程被执行时使用；证明面失败、受阻或测量错误时用 inconclusive。输出格式为 Proof target、Required level、Route、Evidence collected、Verdict、Gap。证据过期、间接或仅来自跟踪器/文档时，应称其为弱证据而非证明。