Alpaca options: verify the venue reality before any commitment — agreement, cash-account support, multi-leg, assignment events

[eaitbrahim]

Options on Alpaca collide with keel's constitution by construction — and the decision (the ADR-0005 issue) must not be made from documentation alone. #412's lesson applies verbatim: Robinhood's order-object shapes were doc-only until one real order was observed. Discovery first, decision second, code never before both.

What must be verified on the venue, not in the docs

• Cash-account options: can an Alpaca cash account trade options at all, or does the options agreement imply the margin agreement? (keel enforces multiplier == 1 at broker build via CashAccountRequired — Cash-account posture: encode and document no-margin / PDT-adjacent constraints #372 — so this is the load-bearing question)
• Multi-leg order support in the Trading API: spreads as single orders, or leg-by-leg? (keel's port carries no multi-leg order kind today)
• Contract multiplier semantics: how the venue reports quantity/notional for multiplier-100 contracts, and where that would collide with the cash rail
• Exercise and assignment events: does the stream/webhook deliver assignments, what does an assignment do to a cash position, and can it arrive outside the trading session
• Cash-securedness enforcement: can the venue reject a naked leg on a cash account, or must keel enforce covered-call/cash-secured-put-only itself at order construction
• Expiry cadence interactions: expiry-week and PDT interactions for an hourly-cadence engine

Rules of engagement

• Discovery only. No code, no posture change, no config flag. Read-only API calls against a paper/options-enabled account are in scope; live trading is not.
• Findings land on this issue; the ADR-0005 issue consumes them.
• If any answer is "the venue cannot tell us," that itself is a finding, and it weights the decision toward holding the line at cash-spot.