Task: Give the commodity products their own facts where the family can state them

The products the family can state are constructed whole, and the ones it cannot are named rather than silently drawn as something simpler.

• CommodityAsianOption states an average type and its averaging window, and the constructor requires them.
• The basket option, rainbow, best entry and worst-of basket swap state numbered constituents, and their constructors refuse an empty basket.
• A provisioning run books every routed code, with constituents and averaging present, and the suites are green.
• The products the family still cannot distinguish are recorded, with what each one is missing.

Two products the family can already state correctly, and one gap to name.

The Asian option gains its own terms: an average type and the window it averages over, both required, because an Asian without an average is not an Asian.

The four basket products gain members. The family already has commodity_basket_constituents, a table nothing wrote to; a basket product now constructs its members and numbers them, and refuses a basket of fewer than two, because one member is not a basket.

The rest of the codes stay as they are, and the task records what each one is missing rather than drawing it as something simpler without saying so.

Every number this task claims about a tree, with the command that produced it and the commit it was measured at. A number without both is not a measurement, because a clean-up record describes a tree and trunk moves under a branch: a consumer count, a gate's component count and a suite's size all change with no code changing, and the reader of a bare number cannot tell which tree it came from. Where the raw output matters, put it in an evidence/ file beside the task and name that file in the Command column.

Manual QA scenarios (scaffolded via compass add test_scenario) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

Two more products state what they are. CommodityAsianOption requires an average type and its averaging window, and the planner now draws them instead of leaving the product as a plain option. The three basket option codes and the worst-of basket swap construct numbered members, so the commodity_basket_constituents table is written for the first time.

Proved by a provisioning run on a recreated database: 25 rows over 25 codes, 12 constituents over 4 products (three members each), and the Asian option's row carries Arithmetic and a window. The suites are green: ores.trading.api.tests at 485 assertions in 130 test cases, ores.synthetic.core.tests at 1741 assertions in 79.

This is the part worth reading. Several of the twenty-five codes are still drawn as a plainer shape, because the table has nowhere to put their facts:

So the basket products can name their members but not say what they do with them, and the TaRF cannot state a target at all. Those need the family's own tables, the way the equity family has nine, which is a modelling task and not a constructor's.