Task: Flip commodity onto its rows

Table of Contents

This page documents a task in the Let the plan state domain rows, not a bag story. It captures the goal, current status, acceptance, and any notes or results.

1. Goal

A commodity trade states its rows in the plan, and the writer translates nothing for the family.

2. Status

Field Value
State DONE
Parent story Let the plan state domain rows, not a bag
Now Nothing.
Waiting on Nothing.
Next Nothing.
Last touched 2026-10-30

3. Acceptance

  • The planner builds the commodity rows and their basket constituents from what it draws.
  • The writer's commodity arm is gone and the batch is persisted with its audit columns stamped.
  • A provisioning run books the same 25 commodity rows and 12 constituents.

4. Plan

(Implementation strategy. Written when work starts; key decisions are distilled into the parent story's * Decisions at close, but the plan itself stays — it is the historical record of what we did.)

5. Measurements

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.

What Value Command Commit
Commodity instrument rows in a fresh tenant 25 select count(*) from ores_trading_commodity_instruments_tbl b621f3df19
Distinct commodity product codes booked 25 select trade_type_code, count(*) ... group by 1 b621f3df19
Basket constituent rows 12 select count(*) from ores_trading_commodity_basket_constituents_tbl b621f3df19
Basket products carrying constituents 4, three each select i.trade_type_code, count(c.sequence_number) ... left join b621f3df19
Bond issues written, none nil 18 select count(*) from ores_trading_bond_issues_tbl where issue_id = '000...0' b621f3df19
Bond instrument rows 24 select count(*) from ores_trading_bond_instruments_tbl b621f3df19
Total trades 863 select count(*) from ores_trading_trades_tbl b621f3df19
Planner suite 1,757 assertions in 79 cases publish/bin/ores.synthetic.core.tests b621f3df19
Build whole tree green ./compass.sh build b621f3df19

6. Notes

7. Test Scenarios

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.

Scenario State Notes
     

8. PRs

PR Title
#4084 [synthetic] Let a commodity trade state its rows

9. Review

Comment summary File Decision Notes
       

10. Result

The commodity family states its rows. The planner builds the instrument and its basket members beside the drawing that feeds them, and the writer persists what the plan carries. The writer's commodity arm is gone: 168 lines of translation left the writer and the mapping landed in one function in the planner.

The flip exposed a defect in the slot rather than in the family. A family that states rows leaves its bag unset, and the bag's variant defaulted to its first alternative, which was a bond. Every commodity slot therefore read as a bond with an empty security, and the run stopped when the writer tried to create an issue with a nil id:

new row for relation "ores_trading_bond_issues_tbl" violates check constraint
"ores_trading_bond_issues_tbl_issue_id_check"

The variant now holds std::monostate first, so a slot with no bag reads as no family, and the planner test asserts that rather than the absence of one family. The bond flip's next slice, the security, is unaffected.

One service was down before the run: ores.marketdata.official had no NATS client certificate, because it was added after the fleet's certificates were issued. compass nats certs issued the missing one and the fleet came up 25 of

  1. That is an environment gap and not a code change; it is noted here because

the run could not start without it.

Emacs 29.3 (Org mode 9.6.15)