verify_state
Evaluates state assertions independently and requires evidence from multiple signal channels before returning pass, fail, or unverifiable, preventing single-source claims from being silently accepted.
Instructions
出一份可证伪的验收结论：每条断言独立求值，并要求足够多的独立证据才判成立。
为什么必须有它（这是从 reverse-skill 的证据链契约学来的一条硬规则）
单条证据不得静默提升为「已验证」。它那条契约的原文是：
validated需要 >=2 independent Evidence（最好 1 静态 + 1 动态）； 单条证据不得静默提升为 validated。
我们自己的实战正好印证了这条：在 CatapultHero 验收 Mod 时，
我同时看了日志（已修改 精核 = 108）与屏幕 OCR（精核：108）——
两个互相独立的来源给出同一个结论，才敢说「Mod 真的生效了」。
只看日志的话，日志本身是 Mod 打的，Mod 写错了照样打日志。
所以本工具把「要几条独立证据」变成显式参数，而不是留给 Agent 的直觉。
参数 checks 怎么传
逗号分隔的条目，每条形如 kind=参数，与 wait_for 共用同一套条件语义
（_eval_condition，所以两处结论必然一致）：
写法 | 含义 |
| 日志里有匹配行（只读不消费） |
| 屏幕上 OCR 到该文本 |
| 存在该窗口 |
| 该字段当前等于期望值 |
| 该类活实例数达到下限 |
示例（双证据验收 Mod 生效）：
verify_state(checks="log=D:\\Game\\UE4SS.log#已修改 精核,"
"ocr=精核")返回
· verdict —— pass / fail / unverifiable（三态，与 wait_for 同源）
pass要求：成立条数 >= require_independent，且这些成立的条目 来自 >= require_independent 条不同的信号通道全部条件都成立但只有 1 条 → 判
fail并说明「证据不足」， 不是 pass —— 这正是「单条证据不得静默提升」多条成立但全是同一条通道（如两条
ocr=）→ 同样判fail， 并说明「同源，缺独立第 2 通道」—— 同一张截图上的两条断言会一起 对、也会一起错，不是「互相独立」的证据 ·evidence—— 每条断言各自的{check, hit, detail}·independent_count—— 成立的不同通道数（按 kind 去重）， 与passed（成立的条数）不同；independent_kinds列出是哪几种 ·require_independent/verdict_reason—— 门槛值与判定理由
Args:
checks: 逗号分隔的断言列表，见上表。
require_independent: 判 pass 所需的成立条数下限（默认 2）。
设 1 会退化成「单条证据即通过」—— 只在确实只有一个可靠来源时用。
Returns: {ok, verdict, verdict_reason, evidence, independent_count, require_independent, passed, unverifiable_count}
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| checks | Yes | ||
| require_independent | No |