Task: Link trades into structures
Table of Contents
This page documents a task in the Model trade structures story. It captures the goal, current status, acceptance, and any notes or results.
1. Goal
A trade sits in at most one structure at a time, shares its party and counterparty, and fills a role the template allows.
2. Status
| Field | Value |
|---|---|
| State | DONE |
| Parent story | Model trade structures |
| Now | Nothing. |
| Waiting on | Nothing. |
| Next | Nothing. |
| Last touched | 2026-10-05 |
3. Acceptance
- structure_member is temporal and keyed by trade_id, so a trade is in at most one structure at a time and can be linked and unlinked.
- Composite foreign keys pin a leg's party and counterparty to the structure's.
- Linking a leg checks the template's roles and leg counts; a pgTAP test refuses a role the template lacks and a leg past the maximum.
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 |
|---|---|---|---|
| static checks on this branch | 4 of 4 pass | compass check --only sql-reachability --only handler-permissions --only model-drift --only cmake-sources |
feature/structure-members |
| pgTAP cases written for the members | 6, never executed | pg_prove test/trading_structure_members_test.sql |
feature/structure-members |
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
9. Review
| Comment summary | File | Decision | Notes |
|---|---|---|---|
10. Result
structure_member is keyed on the trade and is temporal, so a trade sits in at
most one structure at a time and unlinking closes the row rather than deleting
it. Its party and counterparty are copied from the structure and pinned to it,
which needed two unique keys on the structure table that this task adds.
The insert trigger holds a leg to the roles its template allows and to the number of legs the template states for that role, with a maximum of zero meaning no upper bound. A package rests on no template and is constrained by nothing.
Validation was static only: four checks pass, including sql-reachability, which is what confirms both the create and the drop aggregators name the new files. No build, no ctest and no database run happened, so the six pgTAP cases have never been executed and the trigger's behaviour is read, not observed.