Task: Read the child-row outputs

The three child-row families are read into typed rows that keep the key that gives each figure its meaning.

• flows, stresstest_flows and todaysmarketcalibration_cashflows each have a typed row and a reader.
• A flow row keeps its trade, leg, cashflow number and pay date, and the reader refuses a row that omits one of them.
• A stressed flow states base, scenario and difference for each figure, and the reader refuses a row that states fewer than three.
• The tests read the checked-in sample of each family.

Three families, three typed rows, three readers, because their meaning is the relation between columns rather than a bag of figures. Each reader asks for the columns that make the row a row — trade, leg, cashflow number and pay date — and refuses a row that omits one. A figure the engine states as its null string stays empty, so a flow with no fixing is not a flow with a zero fixing.

Two cases the corpus does not ship are stated as fixtures beside the suite: a flow row without its pay date, and a stressed flow that states a base without a scenario. The reader's rules came from the corpus first: the volatility figures are stated with a base and a scenario and no difference, so a difference is optional and only the base and the scenario are required.

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.

• The corpus states the floor and cap volatilities with a base and a scenario and no difference, so a stressed figure requires two parts and carries a third when it exists. The fixture states the refusal case: a base with no scenario.
• A flow without its pay date is a fixture rather than a corpus case, because every checked-in flow states one. The reader refuses it rather than guessing a date.
• The three families are read by three functions rather than one generic one because the row types differ: a flow, a stressed flow and a calibration flow share almost no columns.

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.

Three typed readers, one for each child-row family, and 42 assertions over 7 cases. A flow keeps its trade, leg, cashflow number, pay date, flow type and currency, and carries each figure as an optional, so a null fixing is absent rather than zero. A stressed flow carries its base, scenario and difference per figure, with the difference optional because the corpus omits it for the volatilities. A calibration flow keeps the market object, pillar and rate helper that made the flow.

The suite reads the checked-in sample of each family and three synthetic fixtures for what the corpus does not show.

Superseded on 2026-10-31 by the next task in the story. A typed row carried eight of the figures a family states and the store needs them all, so the three readers were replaced by one reader driven by the catalogue, which names each figure by its heading and each part of a stressed figure by the part it is.

Open at close: the light gate's curve-sections-wiring check fails on this branch, and the generated file it names is not one this branch touches: main is inconsistent there and another environment owns it.