Task: Generate the trading command units into ores.shell.trading

The 39 hand-written trading command units in the application part are the trading surface the shell uses today. Generate the trading units from their entity models into ores.shell.trading, register them from one generated aggregator, and delete the hand-written units, so the trading surface is codegen output and adding an entity's verbs touches no shared file.

• Every trading entity the hand-written surface serves has a generated unit in projects/ores.shell/trading/.
• The hand-written trading units and their headers are gone from the application part, and no submenu is registered twice.
• One call from the REPL host reaches every trading unit.
• The full preset build and the ctest suite are green, and the codegen drift gate reports no drift.
• The trading surface answers the live checks as it did before the change.

A survey of the 39 units splits them into two shapes. The split is exact: the 7 units in the second shape are the same 7 files, and they are the 7 trading models with no #+domain_audit_group:. The grep that proves it is render_history_diff, which appears in those 7 files and no others.

The 39 units are not 39 entities. A count of the files gives 30 instrument units, 7 no-audit-group units, the trading_commands.cpp aggregator, and ore_commands.cpp. The last is not an entity unit at all. It carries the ORE upload, import and export verbs, it is called without pagination, and it has no model to generate from, so it stays hand-written.

The 7 are not all lookups, though the earlier name for them said so. Six are reference or association tables around the trade. The seventh is trade itself, which carries no :profile: and therefore no audit group. The discriminator for the template is has_audit_group, not the entity's role.

The drift acceptance needs a caveat before work starts. trading-cpp sits outside KNOWN_DRIFT_FREE by the decision of 2026-09-06 in Entity classification and drift baseline: ores.trading, and the drift has grown since. A component-wide regeneration today rewrites 132 tracked files and materialises 44 untracked ones, none of them this task's.

The gate for this task is therefore the shell component, which is drift-free: check_component_drift.py --component shell passes because the generated units land in projects/ores.shell/trading/ and the run writes nothing outside the part. Do not run --component trading-cpp on this branch, and do not run --all before the trading estate is reworked. Generate one entity at a time, so a surprise in one entity's output is legible.

The facet's two archetypes serve one key shape and one audit shape today, and both gaps come due in this task. The delete and history verbs take a single key string, and the implementation template writes req.{{primary_key.column}} = ... and req.ids = {id}. That matches a single-column key and no other. A compound-key entity's request carries one field per key member, as delete_bond_leg_request does with ids, leg_roles and leg_numbers, so those verbs need one token per key member before the 14 compound-key trading entities can be generated. The audit assignments are also unconditional, so an entity with no #+domain_audit_group: has no v.audit and does not compile. Only 26 of the 64 trading models declare the audit group. Teach both shapes to the archetypes before opting those entities in.

The facet has two archetypes and no tests archetype, so each generated unit's test file is hand-written today. Review of the first unit asked for that test shape to travel with the generator. The shape is one case per handler guard, the arity check, a malformed token that names its field, and a valid token vector that reaches the transport. Writing the archetype is a candidate for this task, so every generated unit arrives with its own test.

Two documents still describe the hand-written flow, and they move with this task. Shell entity patterns gives the file locations and class shapes of a hand-written unit, and How do I create shell commands for a new entity? walks through writing one. Rewrite both for the generate-first flow when the hand-written units retire, so an agent adding an entity is not sent to write code the generator owns. The skill compass-codegen-add-surface-entity already carries the corrected gap note.

Four of the units have no model at all. scripted_instrument, credit_instrument, composite_instrument and commodity_instrument carry hand-written domain headers and share a hand-written ores.trading.api/messaging/instrument_protocol.hpp. Nothing can generate them until models exist. The acceptance criterion is therefore read as every trading entity that has a model, and these four are named in the Result.

The trade_type model needed :is_enum: true on product_type before its unit could be generated. Without the flag the column lands on the entity as a string and the history field mapper drops it without a word, so the field never appeared in a version diff. The flag regenerated three files and repaired the drop. A baseline regeneration of those same files had already shown zero drift, which is the evidence that no hand-written code lives in them.

The trade model cannot be regenerated on this branch. Its ** Custom repository methods section is empty, so regenerating the repository facet deletes 93 lines and four methods, read_latest, read_latest_for_node, read_trades_for_books and fetch_book_ids, and the presentation facet materialises two files that do not exist today. That regeneration was run, measured and reverted. A shell unit for trade is unaffected, because the shell facet reads the messaging protocol and never the repository.

trades history --diff is broken today, before this task touches it. The shell unit calls render_history_diff for entity type ores.trading.trade, and no provider is registered under that name, so the history service answers with a not-found error. The other six shape-two entities have providers. The defect is independent of this task and is recorded rather than fixed here.

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

Local review of bdc48fb93c..fcd29e7025, the five commits this task adds. The pass ran the misspell check and walked the hand-written half of the diff, which is the codegen engine, the three facet templates, the model opt-ins, the link, and the trade_type mapper changes. The generated half is 23 units and their tests, and the build and the suite cover it.

Row 6 records the GitHub review round on PR #2084. That finding arrived after the local pass and changed the unit count, so the Result below reads 22 where the local pass read 23.

Step 4 delivered 22 generated command units into projects/ores.shell/trading/, each with a header, an implementation, and a test file. The set is the 16 instrument units that have a generated protocol (the 9 equity and 7 fx instruments, one of which is the fx_forward_instrument probe), and the 6 shape-two units (lifecycle_event, party_role_type, trade_identifier, trade_id_type, trade_party_role, trade_type).

The build is green. compass build ores.shell.trading.tests compiles all 22 units and links the test binary. compass test run -- -R ores.shell.trading reports 100 per cent passed, 1 of 1 test, in 151 seconds.

The hand-written surface serves 37 entity units. Fifteen are excluded, in four groups, and none of the four can be closed on this branch.

• Four instruments have no model. commodity_instrument, composite_instrument, credit_instrument and scripted_instrument carry hand-written domain headers. Nothing can generate them until models exist. The Plan already names these four.
• Nine rates instruments cannot use the generated protocol dialect. The balance_guaranteed_swap, callable_swap, cap_floor, fra, inflation_swap, knock_out_swap, rpa, swaption and vanilla_swap instruments share the hand-written ores.trading.api/messaging/instrument_protocol.hpp. That header differs from the generated contract in three ways. Its list payload member is the generic instruments rather than entity_plural_short. Its history request key is id rather than the key column. Its save request carries no from() factory and adds a swap_leg legs member. A generated unit against that header fails to compile, with 20 errors of the form no member named 'balance_guaranteed_swap_instruments' in get_balance_guaranteed_swap_instruments_response. Two mechanisms were tried and reverted. A generated per-entity protocol would create two definitions of the same fully-qualified names, and a second dialect in the template would bake a hand-written header's quirks into the facet. The rates protocol and the aggregate rates_instrument_handler.hpp and registrar_rates.cpp must migrate to the generated contract first. That migration is the trading estate rework the Notes forbid on this branch.
• trade has no field-group information in its model. domain::trade is composed of five groups, identity, parties, classification, lifecycle and audit. The generated unit assigns flat members such as v.book_id and v.trade_date, and clang reports 20 errors of the form no member named 'book_id' in 'ores::trading::domain::trade'. The generator derives member_access for the identity group only. The trade model records the grouping solely in its ** Table display section, as dotted paths such as classification.trade_type, and the ** Columns section carries no property the generator reads. A shell-command unit for trade needs the model to state each column's group.
• bond_instrument needs a container add verb. The facet renders one row from one entity model. The bond add builds four rows across three services: the bond_issue that holds every term, the slim instrument that pins the trade to that issue, and the engaged bond_option or bond_trs fact row. The generated verb would save one instrument row and demand an issue_id that nothing else in the shell or Qt creates, so it cannot create a bond at all. This entity was opted in and generated in step 4; the review round below de-opted it and returned the hand-written unit. The container shape is CADAD363, a new task on this story.

The protocol_include mechanism built for the rates group was reverted once the group was excluded. With no consumer left it was speculative machinery. core.py returned to its task #186 state and both archetypes returned to their task #187 state. fx_forward_instrument regenerated byte-identical after the revert, which is the evidence that the refactor was behaviour-preserving for the 22 units.

The part's file lists were regenerated with regenerate_cmake_component_files.py --component ores.shell.trading, so they list 22 units and no rates files.