Sub-blocks shipped as display-only row groups inside one block (#7): a collapsed group shows the chain's net flows, but it's still one solve and one recipe set. This issue tracks the fuller model, deferred until there's a concrete need for it.
The idea
A sub-block becomes its own solved unit — a "small module" — that the parent block (or factory) consumes from, with a key twist in how its goals are exposed:
- The sub-block's goals are internal: they size the module but are not published to the general factory as outputs. A module that exists to feed its parent shouldn't look like a factory-level producer of its goal good.
- Its surpluses stay visible: byproducts beyond what the parent consumes should still surface in the factory-wide coherence/byproduct model, since they physically exist and need routing.
- Intermediates stay hidden entirely, as in the display-only version.
Open questions (from #7, still open)
- How parent imports/exports wire to the sub-block's boundary flows — presumably the parent sees the module's outputs as in-block supply, like a recipe row with the module's aggregate I/O.
- Reuse: can one module be referenced by multiple parents, or is it inline-only? Reuse is where real composition beats display-only.
- Interaction with the factory coherence/seam model (
db/queries.ts), which currently treats every block's flows uniformly — needs a "internal goal" flow role or an ownership notion.
- Migration path from display-only groups (
rowGroups/recipeGroups in the block doc): ideally "promote this group to a real sub-block" is a one-click action.
Deferred deliberately: display-only covers the fold-a-long-chain need today, and the composition model should be driven by a real planning case that display-only can't serve.
Relates to #7 (shipped display-only), #33 (block composition epic).
Sub-blocks shipped as display-only row groups inside one block (#7): a collapsed group shows the chain's net flows, but it's still one solve and one recipe set. This issue tracks the fuller model, deferred until there's a concrete need for it.
The idea
A sub-block becomes its own solved unit — a "small module" — that the parent block (or factory) consumes from, with a key twist in how its goals are exposed:
Open questions (from #7, still open)
db/queries.ts), which currently treats every block's flows uniformly — needs a "internal goal" flow role or an ownership notion.rowGroups/recipeGroupsin the block doc): ideally "promote this group to a real sub-block" is a one-click action.Deferred deliberately: display-only covers the fold-a-long-chain need today, and the composition model should be driven by a real planning case that display-only can't serve.
Relates to #7 (shipped display-only), #33 (block composition epic).