Fix the three PR #249 review findings that arrived after the merge

[wormeyman]

PR #249 drew seven review findings. Four arrived while it was open and were fixed in 2809e8d6. The other three were posted at 22:47:0x, three minutes and thirty-nine seconds after the squash merge at 22:43:28Z, so they shipped unaddressed. This is those three.

No production code. vp check is clean, and both touched fixtures regenerate byte for byte from their original capture streams.

The unguarded read that would hide its own control

analyze-rail-box-orientation.mjs read .bounding_box off dump.directions.find(d => d.created). find answers undefined when no direction placed anything - every create_entity failing, or the Lua pcall raising before created is set - and that is precisely the case the "every direction produced a placement" and "the probe recorded no Lua errors" controls exist to report.

Instead it threw a TypeError while building the fixture literal, and controlsAllPassed is not consulted until after that literal is built. So a total failure exited with a stack trace naming neither the probe nor the failed control. actualPosition two lines above already guarded the same emptiness with placed[0]?.position; this was the one read that did not.

Regenerating rail-box-orientation.json from the original dump produces a byte-identical file, so the guard is confirmed to change nothing on real data.

A suppression rule wider than the thing it excused

The game refuses some grid positions - run 2's layout rejected 3,5 on the parity rule after run 1 accepted it - so SESSION.md tells the operator to substitute the nearest accepted value. analyze-blueprint-grid-position-gui.mjs suppressed the asked-for label from stepsNotCaptured so a substitution would not read as a skipped step.

It did that with a single boolean over every gridpos- label. Two substitutions therefore excused three missing steps, and gridpos-0-0 vanished - a step genuinely never run, and the one that establishes the non-default check, disappearing from the list whose only job is to name what was skipped.

That is the silent cap stepsNotCaptured was written to prevent, reproduced inside the code written to prevent it. One substitution now excuses one missing step, counted and spent in the order SESSION.md walks them. The gridpos- pattern also moves into a named GRIDPOS_LABEL constant: expectedFor matched /^gridpos-(-?\d+)-(-?\d+)$/ while this filter used a bare startsWith, and the looser copy was the one in charge.

The fixture is regenerated from the original run's capture stream, not edited. It reproduces byte for byte apart from the one restored entry:

 "stepsNotCaptured": [
     "untouched",
+    "gridpos-0-0",
     "abs-2-6",
     "snap-off"
 ]

One note on the review that found this: it cited a case labelled gridpos-3-5-saved as live evidence. That label is real, but it belongs to run 1 - it was in the fixture from e165d3a4 through 6f1ed55a and was replaced twelve minutes before the review posted, when run 2's fixture landed in 55533bda. The mechanism was live regardless, through gridpos-0-0 instead.

A README predicting numbers the probe had already corrected

probe-blueprint-grid-position-gui/README.md still described run 2 with pre-measurement figures:

It said	The code says
Run 2 "replaces the assembling machine"	LAYOUT keeps assembling-machine-1, moves it to (10.5, 30.5) and adds the rail as a fourth entity
rail at y=20, box edge 17.764	control.lua:100 places it at y=21; its own header at line 77 predicts box edge 19.102

Both errors compound. The rail sits at 21 because probe-rail-box-orientation measured that one requested at (20, 20) is placed at (21, 21). Its box edge is 21 - 1.8984375 = 19.102 off the measured runtime box; data.json says -2.236, which the game disagrees with, rails being the only entities the two disagree about at all (#251). The old 17.764 took the wrong box from the wrong position: 20 - 2.236.

This matters because the README is what an operator reads while the run is in front of them, and it promises that a wrong prediction "is not silent". It is not - but it looks identical to a bad run, and all three predictions would have missed.

analyze-blueprint-grid-position-gui.mjs:63 and control.lua:77 already carried 19.102; the README was the last file with the old number.

CLAUDE.md

The stepsNotCaptured paragraph gains the worked example, because the failure is more instructive than the field: a suppression rule has to be as narrow as the thing it excuses.

🤖 Generated with Claude Code

https://claude.ai/code/session_013SHoE9cH9kd6vtpHM1PzZ1