1caf43c86a0053ee7f04d2f502638ce154f764d8
Four gaps, each covering a rule this design leans on rather than merely states. The single-group exemption was half tested: one case pinned that no randomness is drawn, none that the building still produces. That half is the load-bearing one. It is why the pool cannot test eligibility, and so why the display filters more strictly than the pool rather than the pool being brought into line with it -- an asymmetry a later reader would reasonably try to tidy away, with the suite staying green. Judging a group whole only differs from judging its items one by one when a group holds more than one item, and no shipped or fixture recipe does. The synthetic preview config now has such a group, and the same award is asked twice either side of its second item being wanted: alpha alone opens the alpha group, both open all three. Monotonicity was assumed in a comment and relied on in code -- an upgraded recipe is spotted by its group count having grown, which only means "gained" so long as nothing can be lost. And step 4's guarantee that an unlocked recipe has a group it can yield, which computeUsableRecipeGroups treats as impossible to violate rather than as a case to render, is now checked across a run of awards instead of trusted. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
Description
No description provided
Languages
C++
96%
CMake
2.2%
Python
1.1%
C
0.7%