feat(planner): count pin on a goal's producer supply-pushes instead of fighting the goal

Pinning a recipe's building count (exact) while it also produces a pinned
goal created two independent LP constraints that fought: 2 foundries make
0.133/s steel, a 0.14/s goal needs 2.1, and =-count plus >=-floor can't
both hold, so the block went infeasible over a rounding sliver. But
pinning a building count IS the user switching that block to supply-push
('I built N of these, size around them'), so the goal should yield.

A count pin on a producer of a pinned goal now relaxes that goal's rate
floor (the pin drives output); the doc goal is untouched, so naming and
factory rollups are unaffected. Scope keeps the honest cases: a CAP pin
still lets the shortfall flag (a ceiling the goal may exceed), and a count
pin on a mid-chain row stays a hard constraint that can legitimately
conflict. The result carries goalSuperseded (target vs what the pinned
buildings make, and whole buildings the target would need); the goal card
shows it as a soft note so the relaxation isn't silent.

Mirrors YAFC, where fixing a row is the spec and output is a consequence
with no separate goal to collide. Verified live on the steel-plate block:
2 foundries, 0.133/s, note 'pinned 2 -> 0.13/s . 0.14/s needs 3'.

Closes #121

Author: ApocDev

app/src/components/block/goal-card.tsx

@@ -4,7 +4,7 @@ import { Card, CardContent, CardHeader, CardTitle } from "#/components/ui/card.t
 import { STOCK_WINDOW_DEFAULT } from "../../lib/goals";
 import { Icon } from "../../lib/icons";
 import { EditableRate } from "./editable-rate.tsx";
-import { ENERGY_PSEUDO } from "./format.ts";
+import { ENERGY_PSEUDO, num } from "./format.ts";
 import { EditableStock } from "./editable-stock.tsx";
 import { LogiTag } from "./logi-tag.tsx";
 import type { BlockDocStore } from "./doc-store.ts";
@@ -166,6 +166,23 @@ export function GoalCard({
                     launch={logi.launchInfo(g, Math.abs(goal.rate))}
                   />
                 )}
+                {/* supply-push note (#121): a count pin on this goal's producer
+                    drives output — the goal rate no longer binds. Show what the
+                    pinned buildings make, and (if short) what the target needs. */}
+                {(() => {
+                  const ss = res?.goalSuperseded?.find((x) => x.item === g);
+                  if (!ss) return null;
+                  const short = ss.actualRate < ss.goalRate - 1e-9;
+                  return (
+                    <span
+                      className="flex items-center gap-0.5 text-sm text-info"
+                      title={`This goal's producer is pinned to ${ss.pinnedCount} building${ss.pinnedCount === 1 ? "" : "s"}, so the count drives output and the ${num(ss.goalRate)}/s target no longer binds.${short ? ` Reaching ${num(ss.goalRate)}/s would take ${ss.buildingsForGoal} buildings.` : ""}`}
+                    >
+                      <Lock className="size-3" /> pinned {ss.pinnedCount} → {num(ss.actualRate)}/s
+                      {short && ` · ${num(ss.goalRate)}/s needs ${ss.buildingsForGoal}`}
+                    </span>
+                  );
+                })()}
               </div>
             );
           })}

app/src/server/block-compute.server.ts

@@ -559,7 +559,29 @@ export async function computeBlock(rawData: SolveInput) {
   // Explicit doc state wins; a legacy doc (no `made`) derives it from its old
   // dispositions via the migration mapping the parity report validated. The
   // derived set is echoed back on the result so the editor persists it.
-  const goals = targets.map((t) => ({ name: t.name, rate: t.rate }));
+  // Supply-push (#121): a COUNT pin on a recipe that PRODUCES a pinned goal good
+  // re-states the block's size from that building count, so the goal's rate stops
+  // forcing total output. Without this the two fight — 2 foundries make 0.133/s,
+  // a 0.14/s goal needs 2.1, and an exact-count pin plus a ≥-floor can't both
+  // hold → a spurious infeasibility over a rounding sliver. Only COUNT pins (exact
+  // "I built N of these") 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, so its
+  // shortfall must still flag, and a count pin on a mid-chain row stays a hard
+  // constraint that can honestly conflict. The doc goal is untouched (naming,
+  // rollups); only the solver floor is relaxed, and `goalSuperseded` reports the
+  // gap so the UI can note "N buildings make X/s; your target needs M".
+  const productsByRecipe = new Map(defs.map((d) => [d.name, d.products.map((p) => p.name)]));
+  const supersededGoals = new Map<string, { recipe: string; count: number }>();
+  for (const p of data.pins ?? []) {
+    if (p.kind !== "count") continue;
+    for (const prod of productsByRecipe.get(p.recipe) ?? [])
+      if (targets.some((t) => t.name === prod && t.rate != null) && !supersededGoals.has(prod))
+        supersededGoals.set(prod, { recipe: p.recipe, count: p.count });
+  }
+  const goals = targets.map((t) => ({
+    name: t.name,
+    rate: supersededGoals.has(t.name) ? 0 : t.rate,
+  }));
   const made =
     data.made ??
     migrateToLpInput({ targets: goals, recipes: defs, dispositions: data.dispositions }).made ??
@@ -594,6 +616,26 @@ export async function computeBlock(rawData: SolveInput) {
       rate: p.count * perBuilding,
     });
   }
+  // Gap report for each superseded goal: what the pinned buildings actually make
+  // (exact, since a count pin fixes the rate) vs the original target, and how many
+  // whole buildings the target WOULD need — the UI shows this as a soft note so
+  // the relaxation isn't silent ("2 foundries make 0.13/s; 0.14/s needs 3").
+  const goalSuperseded = [...supersededGoals].flatMap(([item, { recipe, count }]) => {
+    const goalRate = targets.find((t) => t.name === item)?.rate ?? 0;
+    const def = defs.find((d) => d.name === recipe);
+    const perCraft = def?.products.filter((c) => c.name === item).reduce((s, c) => s + c.amount, 0);
+    const perBuilding = (perCraft ?? 0) * (craftRate(recipe) ?? 0);
+    if (perBuilding <= 0) return [];
+    return [
+      {
+        item,
+        goalRate,
+        pinnedCount: count,
+        actualRate: perBuilding * count,
+        buildingsForGoal: Math.ceil(goalRate / perBuilding - 1e-9),
+      },
+    ];
+  });
   const defaultTemp = (f: string) => q.getFluid(f)?.defaultTemperature ?? null;
   // Sub-blocks v2 (#76): a COMPOSED group is solved as its own module and pulled
   // out of the parent solve, replaced by a synthetic recipe carrying only its
@@ -1184,6 +1226,8 @@ export async function computeBlock(rawData: SolveInput) {
     made,
     // temperature qualifier per unmade item (#110): "water" unmade at "≤101°"
     unmadeTemp,
+    // goals whose rate a count pin superseded (#121) — the soft supply-push note
+    goalSuperseded,
     diagnosis,
     power,
     fuelItems,

app/src/server/block-compute.test.ts

@@ -791,3 +791,67 @@ describe("fluid-fuel supplier designation (#115)", () => {
     expect(res.imports.map((f) => f.name)).not.toContain("pyops-fluid-fuel");
   });
 });
+
+describe("count pin supersedes a goal it produces (#121)", () => {
+  let fx: TestDb;
+
+  beforeEach(async () => {
+    fx = await makeTestDb();
+    // steel from iron: 1 iron -> 1 steel, 1s craft, foundry at speed 1 → one
+    // building makes exactly 1 steel/s. A second recipe makes iron, so a count
+    // pin can be placed on a NON-goal producer too.
+    fx.db.exec(`
+      INSERT INTO recipes (name, kind, category, energy_required, allow_productivity, enabled, hidden) VALUES
+        ('mk-steel','real','smelting',1,0,1,0),
+        ('mk-iron','real','smelting',1,0,1,0);
+      INSERT INTO recipe_ingredients (recipe, idx, kind, name, amount) VALUES ('mk-steel',0,'item','iron',1);
+      INSERT INTO recipe_products (recipe, idx, kind, name, amount) VALUES
+        ('mk-steel',0,'item','steel',1),
+        ('mk-iron',0,'item','iron',1);
+      INSERT INTO items (name, display) VALUES ('iron','Iron'),('steel','Steel');
+      INSERT INTO crafting_machines (name, kind, crafting_speed, module_slots, energy_usage_w, energy_source)
+        VALUES ('foundry','assembling-machine',1,0,100000,'electric');
+      INSERT INTO machine_categories (machine, category) VALUES ('foundry','smelting'),('mk-iron','smelting');
+    `);
+    fx.db.close();
+    switchDatabase(fx.file);
+  });
+
+  afterEach(() => fx.cleanup());
+
+  it("relaxes the goal so a count pin drives output instead of fighting it", async () => {
+    // one foundry = 1 steel/s; pin 2 → 2 steel/s. Goal 2.5/s would need 3.
+    const res = await computeBlock({
+      goals: [{ name: "steel", rate: 2.5 }],
+      recipes: ["mk-steel", "mk-iron"],
+      pins: [{ kind: "count", recipe: "mk-steel", count: 2 }],
+    });
+    expect(res.status).toBe("solved"); // NOT infeasible over the 0.5/s gap
+    expect(res.rows.find((r) => r.recipe === "mk-steel")?.rate).toBeCloseTo(2);
+    expect(res.goalSuperseded).toEqual([
+      { item: "steel", goalRate: 2.5, pinnedCount: 2, actualRate: 2, buildingsForGoal: 3 },
+    ]);
+  });
+
+  it("a CAP pin does NOT supersede — the goal still binds and the shortfall flags", async () => {
+    const res = await computeBlock({
+      goals: [{ name: "steel", rate: 2.5 }],
+      recipes: ["mk-steel", "mk-iron"],
+      pins: [{ kind: "cap", recipe: "mk-steel", count: 2 }],
+    });
+    expect(res.status).toBe("infeasible"); // 2.5/s needs 3 buildings, cap says ≤ 2
+    expect(res.goalSuperseded).toEqual([]);
+  });
+
+  it("a count pin on a NON-goal producer leaves the goal binding", async () => {
+    // pin iron production; steel goal is unrelated and must still be met exactly
+    const res = await computeBlock({
+      goals: [{ name: "steel", rate: 1.5 }],
+      recipes: ["mk-steel", "mk-iron"],
+      pins: [{ kind: "count", recipe: "mk-iron", count: 5 }],
+    });
+    expect(res.status).toBe("solved");
+    expect(res.goalSuperseded).toEqual([]);
+    expect(res.rows.find((r) => r.recipe === "mk-steel")?.rate).toBeCloseTo(1.5); // goal still drives
+  });
+});

docs/solver.md

@@ -65,6 +65,16 @@ single-`target` shape. The item rules:
   applies it after count-pinned consumers' fixed intake). Counts convert to
   rates at solve time via the row's real per-building craft rate, so pins follow
   module/machine changes.
+- **Count pins supersede a goal they produce** (#121): a `count` pin on a recipe
+  that makes a pinned goal good re-states the block's size from that building
+  count, so the goal's rate floor stops binding — the pin drives output. Without
+  this the two fight (2 foundries make 0.13/s, a 0.14/s goal needs 2.1, and
+  exact-count + ≥-floor can't both hold → a spurious infeasible). Only `count`
+  pins on a goal *producer* relax the goal; a `cap` there still lets the
+  shortfall flag, and a count pin on a mid-chain row stays a hard constraint that
+  can honestly conflict. The doc goal is untouched (naming, rollups) — only the
+  solver floor relaxes, and `goalSuperseded` reports the gap so the goal card can
+  note "pinned N → X/s; R/s needs M".
 
 **Fluid temperatures are real identities** (#110, `temps.ts`): when any enabled
 consumer declares an accepted temperature range, that fluid expands — each