Nine days in and my AI increased my portfolio value by over $4,000. Then I panic sold.

The headline

The portfolio is up $4,059.15 in nine days.

Nine days in, my public live-trading portfolio is up 16.6%. Audit the results yourself.

This is a live brokerage portfolio, not a backtest or a paper-trading account. I used my agentic trading platform to manage real money in public, and the account is up sharply since launch.

I should be thrilled. I am thrilled. But the story this week is bigger than the portfolio working. It worked well enough to expose a process mistake.

The setup

I was not watching the portfolio.

For most of this week, I was heads down on platform work.

One thing has been bothering me: Aurora can create profitable trading strategies, but sometimes it takes too long. The current workflow is generative. The agent proposes an idea, backtests it, revises it, tests again, and slowly searches toward something better.

That works. It should not be the only path.

NexusTrade already has years of backtests sitting in the system. Instead of forcing the AI to invent every idea from scratch, I wanted it to search the strategies that already existed, find patterns that worked, and use those as starting points.

So I started building a research surface for the historical strategy universe. I called it the Backtest Corpus Explorer.

Then I checked the portfolio.

I checked the positions, cross-referenced them with Apple Stocks and the Public app, and saw that the portfolio was up 16.6% in nine days.

Then I saw NVDA.

The decision

NVDA was up huge. I thought the system should have sold.

The NVDA spread was up more than 100% in a few days. I vaguely remembered the exit rule: take profit at 50%. So the obvious question was:

Why is this still open?

I asked Aurora to audit the portfolio. The response confirmed what I already suspected.

Aurora audit · NVDA was skipped because it was missing from the underlyings filter

The audit revealed a configuration error in your CloseOption strategy. The system is skipping these trades with the code CLOSE_SPREAD_SKIPPED_UNDERLYING because NVDA is not included in the underlyings filter for that specific exit rule.

That was true. NVDA was missing from the underlyings filter for the close rule I expected to manage it. The system was following the rule I had actually configured instead of the rule I thought I had configured.

The disciplined move was simple: fix the configuration, then let the system re-evaluate the position.

I did not do that.

I manually sold.

The mistake

I found a real configuration mistake. Then I made a process mistake.

Selling a 100% winner is not crazy. If I were trading discretionary options, taking that profit would be easy to defend.

But this challenge is not supposed to be discretionary trading with better dashboards. The point is to define rules, let the system execute them, audit the results, and improve the rules.

The mistake was changing execution modes under pressure. I went from rule-based trading to "I found the issue, I will just handle it myself."

Then NVDA kept running.

I regretted the sale almost immediately. I bought the three NVDA spreads for about $2,385 and closed them for about $5,010. Right now, as I am writing this, those same spreads are worth about $6,219. That means the mistake has already cost me about $1,209 in missed upside, even while the portfolio is still having a monster week.

To make myself feel better, I told myself the engine would have sold earlier anyway if I had configured the rule correctly.

That was too convenient.

NVDA close audit · the first answer was correct, but incomplete

When I dug deeper, the truth was messier. Yes, the close rule was misconfigured. But that first audit result was incomplete. It surfaced the obvious blocker while leaving other blockers hidden. The DTE rule still mattered too, and Aurora missed that part of the close context. There were also additional close-path issues hiding behind that first explanation, including a same-tick duplicate-close case that could generate duplicated broker legs for a spread. I fixed that too, and added a regression test.

So the excuse "the engine would have sold anyway" was not clean. The right move was to repair the system, then let the system act.