Browse answers "what recipes exist", but nothing answers the question that actually matters when planning a Py chain: of all the ways to make (or use) this good, which are practical right now, and why? Today that judgment lives in the user's head or gets delegated to the AI assistant.
The cost LP in app/src/server/cost-analysis.ts already computes a self-consistent economy over all goods and recipes. Two cheap extensions make it answer the practicality question directly:
- Per-recipe estimated flow: the dual (shadow price) of each recipe constraint in the LP solution — a measure of how much a sensible economy actually runs that recipe.
- Waste %:
1 - productValue / recipeCost — how much of a recipe's input value it destroys.
Then a good-centric explorer view: pick any item/fluid, see producing recipes and consuming recipes as two ranked lists — ordered by estimated flow, colored/annotated by waste %, grouped by research-horizon availability (available now / unlocked later / with the blocking tech named), with per-recipe machine and rate context. From any recipe, jump to its other ingredients/products to walk the graph.
This is inspired by YAFC's Never Enough Items Explorer, but built on our own primitives — the ranking comes from our cost analysis and the availability grouping from the research horizon (live research state), not a milestone system. It should reuse the existing hover-card/icon infrastructure rather than introducing a parallel recipe-rendering path.
Part of #31.
Browse answers "what recipes exist", but nothing answers the question that actually matters when planning a Py chain: of all the ways to make (or use) this good, which are practical right now, and why? Today that judgment lives in the user's head or gets delegated to the AI assistant.
The cost LP in
app/src/server/cost-analysis.tsalready computes a self-consistent economy over all goods and recipes. Two cheap extensions make it answer the practicality question directly:1 - productValue / recipeCost— how much of a recipe's input value it destroys.Then a good-centric explorer view: pick any item/fluid, see producing recipes and consuming recipes as two ranked lists — ordered by estimated flow, colored/annotated by waste %, grouped by research-horizon availability (available now / unlocked later / with the blocking tech named), with per-recipe machine and rate context. From any recipe, jump to its other ingredients/products to walk the graph.
This is inspired by YAFC's Never Enough Items Explorer, but built on our own primitives — the ranking comes from our cost analysis and the availability grouping from the research horizon (live research state), not a milestone system. It should reuse the existing hover-card/icon infrastructure rather than introducing a parallel recipe-rendering path.
Part of #31.