Design the object model and public APIs for the core of a stock-brokerage account: the object graph that holds a client's cash and holdings, accepts orders of several types, drives each order through its lifecycle, and matches crossable orders against a per-symbol order book. This is the trading kernel that a UI, a market-data feed, or a network layer would drive, not any of those layers themselves.

Operating context. One in-memory brokerage running many client accounts, each with a cash balance and a set of holdings (quantity per symbol). Clients submit orders to buy or sell a symbol; the kernel supports market, limit, and stop (stop-loss / stop-limit) order types, each validated on entry and then advanced through a state machine as the market moves. Buy orders reserve cash (or margin) and sell orders reserve shares before an order is accepted. A per-symbol order book holds resting limit orders; incoming crossable orders match against the opposite side by price-time priority, producing fills that settle cash and holdings. A single thread drives the matching loop per symbol; accounts may be touched from more than one symbol's loop, so balance mutation must be safe.

Out of scope. The market-data feed and quote source, network / FIX protocol and session management, persistence and end-of-day settlement with a clearing house, fees / commissions / tax-lot accounting, and multi-currency. Assume one currency and reference the last-traded price without designing its transport.

What to produce. The class hierarchy (Account, Holding, an abstract Order with per-type subtypes, the OrderBook, and the matching / risk-check seams), the public API each class exposes, and the order lifecycle state machine (new -> accepted -> working -> partially-filled -> filled / cancelled / rejected / expired). Be explicit about: how each order type contributes its own trigger and pricing rules polymorphically, how buying power and share reservations are checked before acceptance, how the book matches by price-time priority to produce fills, and how a new order type (e.g. trailing-stop) is added without editing existing order classes or the matching core.