run-eval 的 exploredGhost 恒为 0：step_completed 不代表文件读到了

run-eval.mjs:352 用 !e.ok 统计幻觉文件名：

exploredGhost: eventDetails.explored.filter((e) => !e.ok && !e.path.includes('*')).length,

而 ok 来自 event.type === 'step_completed'（:225）。

实测

深层 fixture 两臂 36 个探索步骤，ok 全为 true，其中三条指向不存在的路径：

读一个不存在的文件不会让步骤失败——工具照常返回，错误在返回内容里。所以这个字段恒为 0。

为什么这个缺陷比看上去严重

它不报错，只输出零。而「幻觉 0 次」和「幻觉没测出来」在报告里长得完全一样，读的人会得出反向结论——「导航没解决幻觉」，实际是「工具没在测幻觉」。

分析器侧已修（文件系统探测为准，ok 降为辅证，工作区缺失时记不可判定而非命中）。run-eval 的落盘字段仍是坏的，本轮评测跑到一半，改它会换掉实验条件，所以留到跑完再动。

修的方向

不要新增一个「更可信的标记」——同一个陷阱换个位置而已。落盘时就地探测 existsSync，把存在性作为事实记进 payload；判据要么来自当时观测到的事实，要么来自事后可复算的载荷，不要来自一个恰好总为真的代理量。

同族：#386 #400 #403 #388 #415 #417 #429——算了、传了、消费端拿到的是恒定值。

Start in run-eval.mjs at lines 352 and 225, tracing how explored entries are written into the payload and how exploredGhost is calculated. Use the reported filesystem observation rather than step_completed as the existence fact, and ensure the persisted payload supports the same conclusion after the run. Verify that nonexistent paths no longer disappear into an exploredGhost count of zero.