I'm a beginner programmer building a personal Windows app for intraday SPX analysis, using Codex and Claude to help with development. ChatGPT/Codex also helped organize and draft this post from my project material. I've reached the point where I need an experienced developer to challenge the design, not another AI explanation of why it ought to work.

The app doesn't place trades. My question is about making the whole application usable and consistent, rather than adding another indicator or making one benchmark faster.

What I want to do with it

Leave data capture running in the background, open today's screen, and see SPX prices alongside the full eligible set of same-day, standard PM-settled SPXW options. The intended analysis includes Gamma/GEX, a gamma-flip level, call/put walls, max pain and options flow with clear source limitations. ES futures volume is supporting context, not SPX's own traded volume.

I want to switch between 1-, 5-, 15-, 30- and 60-minute views, inspect history, save exactly the analysis I saw, and reopen that same result later. Reopening shouldn't silently substitute newer inputs or a different calculation. Research scenarios are additional features, not a prerequisite for opening today's screen.

How the pieces are supposed to fit

The stack is C#/.NET 10 on Windows, SQLite and Protobuf, with Interactive Brokers and Moomoo OpenD adapters. Capture runs separately from analysis. The intended path is:

Provider callbacks → recorded batches confirmed complete → one reducer updating accumulated state → transaction saving facts, restart state and progress together → commit → published progress → calculation from fixed inputs → stored result → screen → save → reopen.

One transaction can contain up to eight complete batches. The intention is that calculations only use committed progress, and that the same state-building rules apply throughout. This is the design, not proof that every handoff already works.

What works, and what doesn't yet

Prices, SPX/ES bars, open interest, a source-gamma/OI proxy, trades and limited save/reopen checks have working pieces. The ordinary gamma/flip workflow is still missing from the continuous service and UI. A separate conditional research calculation exists, but that doesn't complete the daily viewing workflow. Calculating my own implied volatility is planned rather than validated.

Quote qualification, carry assumptions and asynchronous snapshots remain unresolved. The gamma/OI result is a positioning proxy, not observed dealer inventory. Those limitations need to survive the journey to the screen and saved history, not disappear behind a plausible-looking chart.

Startup, recovery, saving after a lost response and realistic capacity also need work. An AI-assisted source read-through flagged three concerns I would like a person to check:

  • Price bars and trade bars appear to use different 60-minute boundaries.
  • A normal save gets its ID from the server, which makes a lost reply ambiguous.
  • The screen's full redraw depends on the combination ID changing, although data qualification can change separately.

I haven't had an independent human review confirm these concerns or the proposed fixes.

An older candidate reached a roughly 300,000-record checkpoint in 88.93 seconds, then hit a shared 120-second limit before a roughly 803,000-record checkpoint. Later deletion-key and resource-ownership fixes have small functional evidence, including a 45-record synthetic end-to-end example. There is no new large-sample benchmark for that corrected candidate in the material. An older instrumented run used a different, larger recording; it doesn't establish the current bottleneck.

Where I need help

If you were taking this over, what is the next complete, useful workflow you would finish and prove before adding more features? I'd like it to start with incoming data and end with reopening the saved observation, rather than stop at a passing calculation or database write.

What would the smallest convincing acceptance example look like? In particular, what should it prove about interrupted capture, stale inputs, restart and an uncertain save response?

If you spot a design mistake in one stage, please also tell me what your change would require upstream and what it would change downstream. I'm worried about collecting individually reasonable fixes that no longer agree about what the user actually saw and saved.

The project snapshot ends at 26 October 2026, 04:13 UTC, before any new profiled product run. My supporting material contains source reading copies, design notes, test evidence and disagreements between AI reviews. It isn't a runnable reproduction: raw recordings, SDK binaries, full machine details and a current trace are absent. I'm asking for a grounded next step, not claiming this material proves the architecture is sound.