Deterministic recipes could have several outputs produced together; a
probabilistic one could have several outputs of which exactly one happened.
Two shapes meant two rules everywhere -- sizing a buffer, deciding whether a
cycle fits, resolving what a cycle makes -- each written as a branch on
whether the building was a reprocessing plant.
New REQ-MAT-OUTPUT-GROUP merges them. A recipe has one or more output groups,
each with a weight and a list of items; a cycle produces exactly one group,
and the items within it together. One group is the ordinary recipe and is
always chosen, so the old deterministic and probabilistic cases are the same
shape with one group and with several -- and every rule downstream is written
over groups, needing no branch at all. Config keeps outputs = [...] as the
single-group form, so only the two reprocessing recipes change shape.
It also lets an outcome yield several items, which was unrepresentable, and
fixes a display bug on the way: the recipe summary drew all outputs as one
combined yield, so a plant read as if a cycle made all four items. Groups are
now separated by "/" and the items within one by "+".
REQ-LOCK-REPROCESSING-POOL now restricts the choice between groups rather
than the pool of output items, and says why that distinction is load-bearing:
implicit unlocking is demand-derived, so an ordinary recipe's output can be
producible while nothing yet calls for it. Testing eligibility there would not
gate a drop, it would stop the building producing at all -- so a recipe with
one group, having no choice to restrict, is never tested. A group is eligible
only if all of its items are unlocked, since they are produced together.
Requirements only; the implementation follows.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
