Task: Build Book a trade

trading.v1.ops.book_trade takes the trade's anchor, its booking, the activity_type_code that starts its state (new_booking for a live trade, draft_capture for a draft), its identifiers, and one batch of instrument rows. The service already refuses four things by name: an instrument array that does not belong to the trade type, a child row with no header, a bond part no writer handles, and a trade id that is already booked. The screen therefore states a request and reads the refusal; it does not decide whether a booking is legal.

No code in the trading component names a book status: grep -rn book_status projects/ores.trading finds nothing outside tests. So "a trade books into an open book and refuses a Frozen or Closed book" cannot be met by the screen alone. Two decisions to take, and the task should take one rather than both:

• Trading reads the book from refdata by id at booking time and refuses a book that is not open. That makes trading depend on a refdata read inside its transaction, and the status is current at the moment of the booking.
• Booking copies the status onto the booking row. That is cheaper and keeps trading self-contained, but a book frozen after the copy is not honoured, which is the case the rule exists for.

The first is the honest one. I would rather the service ask than keep a stale answer.

The anchor, the activity and the instruments are the same. What differs is the member row that names the structure, the leg's role, and the ordering. structure_members:write is already held by Trading, so the screen needs no new grant.

• A change reason that requires commentary. The rule is data: a change reason states whether it requires commentary. The service is the only place that can enforce it for every caller, and the screen should surface the same flag rather than invent it. Decision: enforce in the service against the reason's own flag, and let the screen mark the field as required when the chosen reason says so.
• A screen to add a Hedge or UserDefined link. A small form rather than a page: the trade, the other trade, and the link type. trade_links:write is held by Trading. It belongs on the trade page, beside Links, not in the booking screen.

trade_operations_service is a database service: it takes a context and nothing else. It holds no NATS client, and the handler that owns one is written to decide nothing — "the adapter decides nothing: it proves the request, checks the permission, decodes it, calls the service and replies with the service's answer". So a refdata read inside the booking cannot go into the service as it stands, and putting it in the adapter would break the rule the handler's own documentation states.

Three places it could go, with what each costs:

• The service gains a port — an interface it calls to ask a book's status, implemented by the service process with the NATS client. The service stays testable and the adapter decides nothing. This is the largest change and the only one that keeps the existing layering intact.
• The handler checks before it calls — small, and wrong by the file's own doctrine; it also means any other caller of the operation skips the rule.
• The caller states a precondition — the request already carries precondition, which the service enforces, so the BFF could read the book and state "this book is open". That is a client-side rule dressed as a precondition: a caller that lies is believed, and the acceptance criterion says the service refuses, not that the screen does.

I would take the first. It is not a screen change and should not be bundled with one.

projects/ores.refdata/client holds a cache and no typed read for a book, so the port's implementation cannot call a ready-made client method. It has to make the request itself, in the shape trading_trade_population_writer already uses when it calls other services over NATS: encode the list request, read the reply, and treat a refusal as "unknown" rather than as "open".

That makes the change a half-window one rather than a small edit: an interface, its implementation, the wiring in two places, and a test that a frozen book is refused. It is worth starting a fresh window with, not finishing at the end of one.

Three attempts at the bus-backed port each fell one layer lower, and the last one named the actual problem.

• The component did not depend on the refdata API. Fixed: ores.refdata.api.lib is declared in the component's model and the generated CMake carries it.
• The request needed rfl's uuid registration. Fixed the same way other code does it: ores.utility/rfl/reflectors.hpp, which the trade population writer includes for exactly this.
• Then the obstacle: ores::nats::service::client offers request_sync with hand-made headers, and the booking service holds no caller token. A read made by the service would be anonymous, and refdata would refuse it — correctly, because a book's visibility is the caller's, not the service's.

So the port's signature is wrong, not its body. It needs the caller's session token, which means either the port takes one and the booking service's signature carries it, or the read happens in the adapter that already holds the request context. That is a design decision I am not going to take in the last minutes of a window, having already reverted three times.

The dependency and the rfl registration stay: they are correct and were missing, and the next attempt starts from them rather than rediscovering them.

Two tests now hold it, and between them they cover the whole path.

The service's own case, a_booking_into_a_book_that_is_not_open_is_refused, states a port that says not_open and gets failed with book_not_open.

the port asks as the caller and maps the book's status covers what the service case cannot: the port over a real bus. It answers on a subject of its own and holds the port to four things — the question names the book asked about, the header is X-Delegated-Authorization: Bearer <the caller's token>, Active maps to open, and Frozen and Closed map to not open. That is the encoding, the delegation and the mapping in one place.

The whole trading suite is green on a freshly created database: 221 cases, 1416 assertions.

The books the party may book into, the counterparties it may trade with, the trade types with their product type (which decides the instrument table), the identifier schemes, and the instrument's terms for the chosen type. All of these are reads that exist; the books read needs the open rule above to be useful.