Malte Langkabel 1caf43c86a test the unlock rules that nothing was holding in place
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
2026-08-21 23:29:07 +02:00
2026-07-12 09:16:49 +02:00
2026-07-22 21:44:20 +02:00
Description
No description provided
8.7 MiB
Languages
C++ 96%
CMake 2.2%
Python 1.1%
C 0.7%