Unified Trade + Instrument Detail Dialog

• If the instrument changes, the trade version must also change so that downstream consumers are notified of any modification to the deal terms.
• If the trade envelope changes (counterparty, book, dates) but the instrument is untouched, the trade version bumps but the instrument version does not.
• A single change reason selection covers both records when both are saved together; it is applied identically to whichever entity records are written.

When Save is clicked the dialog applies the following logic:

if instrumentHasChanges_ and instrumentLoaded_:
    1. save instrument  (save_*_instrument_request)
    2. on success: save trade  (save_trade_request)  -- always bumps trade version
    3. on failure: surface error, do not save trade
elif hasChanges_ (trade only):
    1. save trade only

This client-side ordering guarantees the invariant in the happy path. A proper server-side atomic operation (single NATS call, single DB transaction) is a future enhancement noted in Open Questions.

A single "Provenance" tab contains two QGroupBox sections:

• Trade (top): version, modified_by, performed_by, recorded_at, change_reason_code, change_commentary — populated from the trade record.
• Instrument (bottom): same fields — populated from the instrument record once it loads. Hidden (group invisible) until an instrument is present.

Each section embeds an ores::qt::ProvenanceWidget via the existing custom widget promotion mechanism. The base-class provenanceWidget() override continues to return the trade's widget; the instrument widget is managed separately by TradeDetailDialog itself.

TradeDetailDialog gains instrument tabs alongside its existing trade tabs. The complete tab set for a trade with a loaded instrument is:

In create mode all instrument tabs are hidden. When an existing trade is opened and trade.instrument_family is set, the dialog loads the instrument via the existing get_instrument_for_trade_request NATS call and reveals the instrument tabs on success.

setTrade(trade)
  → populate trade fields
  → if trade.instrument_family != ""
      emit statusMessage("Loading instrument...")
      async: get_instrument_for_trade_request { instrument_family, instrument_id }
      → on success: setInstrumentFromResult(result)
          show family tabs + Instrument Provenance tab
          populate fields
      → on failure: log warning, leave tabs hidden

The async pattern is identical to the existing loadBooks() / loadCounterparties() calls in TradeDetailDialog: QtConcurrent::run + QFutureWatcher + QPointer guard.

A single Save button handles whichever entities have changed:

1. If instrument fields changed and instrument is loaded: call save_*_instrument_request.
2. If trade fields changed: call save_trade_request.
3. Either or both can be dirty independently; the Save button is enabled if either has changes.
4. The change reason prompt is shown once; the selected reason and commentary are applied to whichever entity records are being saved.
5. Partial failures (e.g. instrument save succeeds, trade save fails) are surfaced as error messages without closing the dialog.

Family tabs are shown or hidden as a unit when an instrument loads. Within a family, individual sub-tabs are shown or hidden based on the instrument's trade type (see per-family breakdown). This logic lives in a private updateInstrumentTabVisibility() helper that is called once after instrument data is populated, and again whenever the trade type changes.

Per family (template, applied to all 8):

Total: ~80 source/header/UI files deleted.

In MainWindow:

• All 8 per-family controller members, their constructor calls, and all signal/slot connections.
• Per-family menu actions and toolbar buttons (Instruments menu or submenu).
• openInstrumentResult signal dispatch (Phase 7 of prior plan).

In TradeMdiWindow / TradeController:

• openInstrumentAction_ toolbar button.
• TradeMdiWindow::openInstrumentSelected() slot and openInstrumentRequested signal.
• TradeController::onOpenInstrumentRequested() slot and openInstrumentResult signal.
• TradeController includes for instrument protocol headers.

Trade types: FxForward, FxSwap, FxOption, FxBarrierOption, FxDigitalOption, FxCollar, FxVarianceSwap, FxVolatilitySwap, FxAccumulator, FxTARF, and others.

The FX Options tab is hidden entirely for vanilla forwards and swaps. The presence/absence is driven by trade_type_code: if it contains "Option", "Barrier", "Digital", or "Collar" the tab is shown; otherwise hidden.

Trade types: Swap, ForwardRateAgreement, OvernightIndexedSwap, BasisSwap, CrossCurrencyBasisSwap, InflationSwap, BalanceGuaranteedSwap, KnockOutSwap, CallableSwap, RiskParticipationAgreement, and many others.

For plain Swap, OvernightIndexedSwap, BasisSwap, CrossCurrencyBasisSwap: the Rates Extensions tab is hidden. The rule is: show the tab if any of the extension fields are non-empty after loading, OR if the trade type string is in the extension-applicable set.

Trade types: Bond, ForwardBond, CallableBond, ConvertibleBond, BondRepo, BondFuture, BondOption, BondTRS, BondPosition, Ascot.

Bond is the most field-rich family; splitting into three tabs prevents the single-scroll-wall that the current 900px dialog produces.

Trade types: CreditDefaultSwap, CreditDefaultSwapOption, IndexCreditDefaultSwap, and others.

Exact field list and tab condition to be confirmed when reading the .ui file during implementation.

Trade types: ~16 variants including EquityForward, EquityOption, EquitySwap, EquityBarrierOption, EquityAsianOption, EquityVarianceSwap, EquityVolatilitySwap, EquityTRS, EquityPosition, and others.

Trade types: ~23 variants including CommodityForward, CommodityOption, CommoditySwap, CommodityFuture, CommoditySpreadOption, and others.

Exact split to be confirmed from CommodityInstrumentDetailDialog.ui during implementation.

Trade types: CompositeTrade, MultiLegOption.

The CompositeLegsWidget is already a reusable sub-widget; it can be promoted directly in the TradeDetailDialog.ui using the existing custom widget declaration.

Trade types: ScriptedTrade and variants.

Scripted is the simplest family to merge; no conditional tab logic.

• projects/ores.qt/ui/TradeDetailDialog.ui — new instrument tab pages for the family
• projects/ores.qt/include/ores.qt/TradeDetailDialog.hpp — instrument state members, async load helpers, instrumentHasChanges_ flag
• projects/ores.qt/src/TradeDetailDialog.cpp — instrument tab wiring, async load, updateInstrumentTabVisibility(), dual-entity save

• projects/ores.qt/include/ores.qt/*InstrumentController.hpp
• projects/ores.qt/src/*InstrumentController.cpp
• projects/ores.qt/include/ores.qt/*InstrumentDetailDialog.hpp
• projects/ores.qt/src/*InstrumentDetailDialog.cpp
• projects/ores.qt/ui/*InstrumentDetailDialog.ui
• projects/ores.qt/include/ores.qt/*InstrumentHistoryDialog.hpp
• projects/ores.qt/src/*InstrumentHistoryDialog.cpp
• projects/ores.qt/ui/*InstrumentHistoryDialog.ui
• projects/ores.qt/include/ores.qt/*InstrumentMdiWindow.hpp
• projects/ores.qt/src/*InstrumentMdiWindow.cpp
• projects/ores.qt/include/ores.qt/Client*InstrumentModel.hpp
• projects/ores.qt/src/Client*InstrumentModel.cpp

• projects/ores.qt/src/MainWindow.cpp — remove family controller, connections, menu items
• projects/ores.qt/include/ores.qt/MainWindow.hpp — remove controller member
• projects/ores.qt/CMakeLists.txt — remove deleted sources, add none

In PR 1 additionally:

• projects/ores.qt/include/ores.qt/TradeMdiWindow.hpp — remove openInstrumentAction_
• projects/ores.qt/src/TradeMdiWindow.cpp — remove action and slot
• projects/ores.qt/include/ores.qt/TradeController.hpp — remove signal/slot
• projects/ores.qt/src/TradeController.cpp — remove onOpenInstrumentRequested