When a recipe's building count is pinned (exact count) and that recipe produces one of the block's goals, the goal's ≥-rate floor and the pin's =-count are two independent LP constraints that fight: e.g. 2 foundries make 0.133/s steel, a 0.14/s goal needs 2.1, and neither will yield → a spurious "infeasible" over a rounding sliver.
Users pinning a building count are switching that block to supply-push ("I built N of these, size the block to them"), so the goal should yield: the pinned count drives output and the goal rate stops binding. This mirrors YAFC, where fixing a row IS the spec and output is a consequence (Yafc.Model sets the row variable's bounds to the fixed rate; there is no separate goal to conflict).
Scope:
- Only COUNT pins (exact) relax the goal, and only on a producer OF that goal. A CAP pin ("at most N") is a ceiling the goal may legitimately exceed — its shortfall must still flag. A count pin on a mid-chain row stays a hard constraint that can honestly conflict.
- Keep the goal untouched in the doc (naming, factory rollups); relax only the solver floor.
- Surface the gap as a soft note on the goal so the relaxation isn't silent: "pinned N → X/s; your R/s target needs M buildings."
When a recipe's building count is pinned (exact count) and that recipe produces one of the block's goals, the goal's ≥-rate floor and the pin's =-count are two independent LP constraints that fight: e.g. 2 foundries make 0.133/s steel, a 0.14/s goal needs 2.1, and neither will yield → a spurious "infeasible" over a rounding sliver.
Users pinning a building count are switching that block to supply-push ("I built N of these, size the block to them"), so the goal should yield: the pinned count drives output and the goal rate stops binding. This mirrors YAFC, where fixing a row IS the spec and output is a consequence (Yafc.Model sets the row variable's bounds to the fixed rate; there is no separate goal to conflict).
Scope: