Every surface is tables and lists, but a solved block IS a graph — recipes as nodes, item flows as edges — and Py blocks routinely have 20+ recipes with cycles. A flow diagram makes structure visible that tables cannot: where the main trunk runs, which loops recycle, where imports enter and byproducts leave.
Shape:
- Per-block sankey/flow view as an alternative tab to the recipe table: recipe nodes (icon, machine count), edges weighted by solved rate, imports/exports as boundary nodes, cycles rendered sanely (Py recycle loops are the norm, not the edge case — layout must not assume a DAG).
- Hover uses the existing rich icon cards; clicking a node focuses the corresponding table row.
- Possible second application: the coherence page's block-to-block links as a factory-level graph (blocks as nodes, goods flowing between them), since that data already exists in
factoryCoherence.
Server-side graph data largely exists (recipeGraph already serves the AI assistant); the work is layout and rendering. Needs a layout approach that tolerates cycles (e.g. layered layout with back-edges) rather than a strict DAG library.
Part of #35 or #31 depending on where it lands — primarily a UI feature over existing solve data.
Every surface is tables and lists, but a solved block IS a graph — recipes as nodes, item flows as edges — and Py blocks routinely have 20+ recipes with cycles. A flow diagram makes structure visible that tables cannot: where the main trunk runs, which loops recycle, where imports enter and byproducts leave.
Shape:
factoryCoherence.Server-side graph data largely exists (
recipeGraphalready serves the AI assistant); the work is layout and rendering. Needs a layout approach that tolerates cycles (e.g. layered layout with back-edges) rather than a strict DAG library.Part of #35 or #31 depending on where it lands — primarily a UI feature over existing solve data.