My AI bought a stock it shouldn't have. Then I couldn't get rid of it.

9:30 AM ET

The order from yesterday filled.

Yesterday at the close I queued a META 610/655 bull call spread, one contract, $1,470 net debit. The order didn't fill at the limit so it sat overnight as a working order at the broker. This morning at the open, Public takes it.

I see the confirmation land in my chat. Two filled spreads now: AVGO from yesterday, META from this morning. The dashboard ticks up. Account value sits a little above $25,500. Day 2 of the challenge is officially underway.

9:28 AM · META filled. Six option legs on the books, none of them grouped. · open the live portfolio →

I open the META chart out of habit, more to admire the fill than to second-guess it. And then I stop.

9:34 AM ET

This trade should not exist.

The strategy fires on a 14-day RSI cross above 50 in a name that has been in oversold territory recently. The filter is mechanical: the indicator either clears 50 against the live data or it does not. There is no human judgment anywhere in the rule.

So I open the in-app agent and ask Aurora a single question: look at my public portfolio, META's RSI, and confirm that the trade I made today indeed should have happened.

Aurora plans the audit, runs Fetch Portfolios, runs the Portfolio Event Auditor, and runs the stock screener for META and SPY. The screener verdict is the one I expected: META 14-day RSI = 28.45, well below the 50 threshold the strategy gates on. The agent's own conclusion: "the trade should NOT have happened automatically. Because Meta's RSI is currently 28.45, it does not meet your strategy's requirement of being above 50."

Two pieces of evidence in the same run point in opposite directions. The strategy says META should have been benched. The strategy also placed the trade. Aurora's third tool, the event auditor, returns this:

9:27 AM · Aurora's verdict. The RSI math is right. The cause is wrong. · open the full agent run →

I know I did not manually buy META. The order came out of the strategy. So either Aurora's auditor is missing the event, or the event was written wrong. Either way, the existing auditor cannot find what I need it to find. I open Cursor with the NexusTrade MCP server directly connected and start walking the events by hand.

9:50 AM ET

One bad tick. Two layers of damage.

I ask the MCP server for the OpenOptionSignal event tied to yesterday's META trade. The Market ticks adjacent to it. The condition audit that the trader recorded when the signal fired. The events were always there; the auditor's summarizer was throwing away the evidence.

The condition audit comes back. It says the trader saw RSI(14) = 74.045 when it fired. That is a hot reading, and on its face it satisfies "RSI above 50." But 74 is also nowhere near where META has actually been trading. The same audit lists the input price the engine used to compute that RSI. The price was $640.23.

I pull the surrounding Market events. META's day high yesterday, on the same snapshot, was $614.35. The print the engine consumed was twenty-six dollars above the day's high. There is no candle on the actual chart at $640.23. There is no print on Public, on the broker tape, or on the public quote. There is one bad tick in my own snapshot stream, and the engine took it as gospel.

I am holding a position that exists because of a bug. The position itself is harmless: META 610/655 BCS, one contract, defined risk, even green on the day. None of that is the point. The point is that the strategy did not actually want to be in META right now. It was tricked into thinking it did.

The first fix is the one this requires: the price-update path needs to refuse anomalous ticks. A live tick whose value is outside the broker's own day-high or day-low for the same snapshot is, with high probability, garbage. The fix lives in fundamental.rs as a sanity_check_tick guard with a 50-basis-point tolerance. Twelve unit tests, including a regression named after yesterday's exact numbers. If a future tick comes in 4% above day-high, it gets dropped at the floor and the snapshot doesn't move. The signal that fired yesterday cannot fire that way again.

The back-end half of the problem is now contained. Future bad ticks get dropped at the floor before any indicator sees them. The trade itself still exists in my account. So I go to close it.

11:56 AM ET

I cannot close this position.

I open the holdings panel. There are eight rows. Each row is a single option leg.

11:56 AM · eight legs. Zero spreads. The UI didn't know what it was holding.

The META 610 long call is one row. The META 655 short call is another row. The UI does not know that those two legs are one position. As far as the holdings panel is concerned, I am holding two unrelated META options that happen to share an underlying. The same is true for AVGO and GOOG. The same is true for the NVDA spread I had opened manually earlier in the day.

There is no "Close spread" button. There are eight "Close leg" buttons.

This is the worst possible state for a defined-risk options portfolio to be in. A bull call spread is defined risk because the long call caps the short call's loss. The short call alone has unlimited loss potential. If I click "Close leg" on the long META 610 to get out of the position, I am left with a naked short call on META at 655. That is a position my account is not even approved to hold. It is also a position that, on a META gap up, could blow through the entire account in a single overnight session.

The platform I have spent five years building does not have a button to close a debit spread.

12:00 PM

Don't close it manually. Build the system.

The first instinct is to call the broker, reach the options desk, and have a human flatten the spread by phone. That works for one position one time. It does not work for the next sixty days of the challenge, and it does not work for any of the other users on the platform who are going to hit the same wall the next time they trade a vertical.

The second instinct is to open Public's app and try to close the spread directly there. Public's app does know what a spread is. But that path leaves my own platform's risk engine permanently behind on the truth: the position closes on Public, my UI still shows two open legs, and the auto-recognition I have not written yet still doesn't know what was happening. Today I get out and tomorrow the same trap is sitting in the codebase for the next person.

The fix is not this trade. The fix is the system. So that's what I do.

I let the position sit. It is defined risk by structure. It is not bleeding. Even if it were, the most I can lose on it overnight is the $1,470 debit I paid, and that bound is enforced by the brokerage on its end whether or not my UI surfaces a button. The trade is safe to leave alone for a few hours. The system is not safe to leave alone for a few hours. So I rebuild.

10:38 AM to 8:16 PM

Eleven hours. Two dozen commits. One risk engine.

The work splits into five layers, each one closing a different gap that the morning surfaced. They land in this order, on purpose. Each layer assumes the one before it.

Layer 1: Stop the bug from firing again.

The bad-tick rejection guard goes in first. It runs at every price-update construction site in the codebase, paper and live. Tolerance is 50 basis points around the broker's same-snapshot day-high and day-low. Anything outside that band gets logged and dropped before the indicator engine ever sees it. The unit test suite includes a named regression guard for yesterday's exact numbers.

The signal that fired yesterday cannot fire that way again. Layer 1, done.

Layer 2: Expose the Rust risk engine for live execution.

The Rust engine already had a risk system. Years of backtest-accuracy work lived in there: the rules that say what is and is not a legal close, what counts as covered, what counts as naked, what would be rejected by a real broker. That risk system had been doing its job for backtests, where the answer to "is this close legal" is the difference between a backtest you can trust and a backtest that quietly skips trades the real broker would have killed.

What the engine actually does, in one sentence: take a portfolio's current option positions plus a proposed close, simulate the post-close state, and check whether any of a small number of rules would be violated. The rules:

• Naked-short suppression. Closing the long leg of a vertical (or one wing of an iron condor, or a calendar/diagonal pair) that would leave a same-underlying short option without its risk-capping companion. Verticals are defined-risk because the long leg caps the short leg's exposure. Remove the long leg and the trade is no longer defined-risk.
• Covered-call uncoverage. Closing shares that would leave a same-underlying short call without at least 100 shares of coverage per contract. The cover-at-entry check already existed; this is the close-side mirror.
• Quantity sanity. Negative quantities, zero, NaN, and fractional contracts (with a 1e-6 tolerance for float noise) are rejected outright. Real brokers do not accept fractional option contracts and never will.
• Strategy integrity. The engine knows about vertical debit/credit, iron condor, calendar, diagonal, straddle, strangle, covered call, and the rest. Each strategy has its own coverage rules; the engine evaluates the post-close state against the right one based on what spread the leg belongs to.

Output: a per-leg verdict (ok / warn / block), a reason code, and the specific symbol that would end up uncovered if the close went through. UI dry-runs ask on every keystroke. Live submissions ask once at the broker handoff. Both get the same answer.

Paper trading inherited the risk engine for free. Paper is fully automated, so every simulated fill goes through the engine on its way to the position, and a flagged trade simply never happens. Live trading has an approval flow: the strategy queues an order, a human clicks Approve All, and the close path on filled positions is also UI-driven. Those two UI surfaces were never wired to the engine. I wanted them to reflect what the engine actually says.

I lifted the risk engine out of the backtester, made it stateless, and wrapped it behind an HTTP endpoint. The backtester still calls it directly. Live execution on the Node side hits it before every multi-leg order submission. The new close-leg modal pings it on every keystroke as the user adjusts contract counts. MCP tools, agents, and every future caller route through the same endpoint and receive the same verdict.

One service. One set of rules. One source of truth. Backtest verdicts and live verdicts are the same code. There is no longer a way for the UI to render a green confirm button while the engine would have said naked.

CLOSE-LEG VALIDATION · DEBIT SPREAD · ANIMATED

The validator picked up one new rule on the way through: closing the underlying that would leave a same-underlying short call without 100x share coverage. Coverage at entry already existed; close-side coverage now does too.

Twenty-six unit tests cover the cases that matter: vertical debit and credit, iron condor (block one wing, allow the full close), calendar, diagonal, straddle, strangle, covered call across four sub-cases, mixed multi-spread batches, invalid quantities, and wire-payload extra-field tolerance. Fail-closed by design: if the risk engine is unreachable, the close request returns a 503 and an alert email fires. The gate is non-optional.

Layer 3: Teach the server what a spread is.

The validator was now safe but the server side had no way to ask the question. The portfolio endpoints (getPortfolio, getSharedPortfolio, getPartialPortfolio) returned a flat list of positions with no grouping. The UI had nothing to render except a flat list.

I added a server-side spread grouper that walks every position, reads the optionMetadata.spreadId tag on each leg, and collapses tagged legs into GroupedHolding rows. The grouper is strategy-aware: bull call debit, bear put debit, iron condor, straddle, calendar, diagonal, covered call. The covered-call detector pairs long stock against same-underlying short calls when shares cover at least 100 times the absolute contract count. Twenty unit tests cover every variant. Anything the grouper doesn't recognize falls through to a single-leg row, so users never lose visibility on a position because the server didn't know the strategy name.

The portfolio endpoints now return a parallel holdings field alongside the existing flat positions list. Existing callers who do not know about spreads keep working unchanged. Callers that do know now get the spread structure for free in the same response.

GET /api/portfolio/:id

# existing flat list, untouched
"positions": [
  { "symbol": "META 610C", "quantity":  1, "lastPrice": 24.52, ... },
  { "symbol": "META 655C", "quantity": -1, "lastPrice":  7.95, ... },
  ...
]

# new parallel structure, computed server-side
"holdings": [
  {
    "kind":             "spread",
    "underlyingSymbol": "META",
    "strategy":         "Bull Call Debit",
    "width":            45,
    "breakeven":        624.70,
    "maxProfit":        3030,
    "maxLoss":          1470,
    "legs":             [ /* references into positions[] */ ]
  },
  ...
]

Layer 4: Build the UI you couldn't get an hour ago.

With grouped holdings on the wire, the holdings panel has something to render as a spread. The first iteration was a flat list of spread rows with expandable legs. By the afternoon I had iterated to a three-tier hierarchy that mirrors how a trader actually thinks about a portfolio: asset row → spread row → leg row. The asset card collapses every position on a given underlying (long stock, covered calls, every spread on AVGO, etc.) into one section. Inside the asset card, each spread row carries the strategy name (Bull Call Debit, Iron Condor, Covered Call), the strike summary parsed inline from the OCC symbols, the width, the days to expiration, the breakeven, and the live mark. Inside the spread row, the leg rows show per-leg detail. Options collapse by default, so the panel does not vomit eight rows at you the moment you open the portfolio.

"Close Spread" is the primary action on every spread row. It opens a close-leg modal that does a debounced 200-millisecond dry-run against POST /api/order/option/multileg/dry-run on every contract-count change. The dry-run hits the Rust validator from Layer 2. The modal renders block, warn, and ok states with per-leg detail, the strike and expiration on each side, and the limit price suggestion auto-filled from the current mid. Block disables the confirm. Warn requires an "I understand" acknowledgment. Confirm submits the same legs to the live multi-leg endpoint, which itself runs the same validator before sending to the broker. Pending-close gating immediately greys the spread row out so a fast double-click cannot double-submit. The user cannot get a green confirm screen unless the validator agrees.

Layer 5: Make sure the legs that are already on the books get tagged.

Layers 2 through 4 assume every leg of every spread already carries the right spread tag in the database. The morning's holdings panel was proof that almost none of them did. Three different ways the tag was getting lost:

• The live brokerage payload was wiping it on every refresh. Brokers do not model spreads; they return leg-by-leg data. The live-account refresh was overwriting the database with the broker payload, dropping the platform's spread tag every time. Fix: a small merge helper that re-stamps stored tags onto broker positions by symbol on every refresh.
• Single-leg fills were not being recognized as halves of a spread. If you opened the long leg and short leg as separate orders, neither carried a spread tag. New recognizer in the order queue: when a single-leg fill matches an existing open option with the same underlying, expiration, and right but the opposite side and a different strike, the pair gets persisted as a vertical with both legs sharing one spread tag.
• Multi-leg fills were not being tagged forward to the position. The order document carried the spread tag at fill, but the resulting position documents never got their copy. Fix: stamp the tag onto the position the moment its parent order transitions to filled.
• The Rust trader self-heals on its own side. On every startup the Rust live trader rebuilds the spread tags from filled order history. A restart no longer begins with a stale view. The two sides converge on the same answer regardless of which one writes first.

And one backfill script for everything already on the books. It walks the portfolios, finds option positions missing the tag, looks up the matching filled multi-leg order, and stamps the tag in. Dry-run by default.