⭐ Orion Dashboard

Methodology

Entry: bar AFTER the signal fires, at the close, only if that bar closes in the signal's direction (green for BUY, red for SELL). If next bar closes against the signal → SKIPPED per Coulling's patience rule.

Stop loss by signal type:

• Hammer BUY: hammer low − 5pt cushion
• Shooting Star SELL: SS high + 5pt cushion
• Bullish Breakout (BO+): 1/3 inside broken zone, below ceiling
• Bearish Breakout (BO−): 1/3 inside broken zone, above floor

Take profit / runner: TP1 = 1R (close half, SL → BE). TP2 = 2R (close half of remaining). Runner = hold until opposite VPA signal OR EOD flatten.

Discipline filter: any SELL with Trend = UP, or any BUY with Trend = DOWN → SKIPPED regardless of other filters. This rule proved itself in real-time on 6/09.

Trades (2 MNQ contracts, $4/pt) — outcome range shown

PnL ranges reflect runner-exit timing — low end = exited at TP2 close, high end = held to opposite signal or extreme low/high.

| Date | Signal | Dir | Risk | Risk $ | Outcome | PnL Low | PnL High |

|---|---|---|---|---|---|---|---|

| 5/11 | BO+ | LONG | 60pt | $240 | TP2 + runner | +$480 | +$920 |

| 5/12 ⭐ | BO− | SHORT | 60pt | $240 | Runner caught dump | +$480 | +$2,520 |

| 5/14 | BO+ | LONG | 90pt | $360 | TP1 + runner | +$420 | +$480 |

| 5/19 | SS | SHORT | 135pt | $540 | TP1 + scale-out | +$380 | +$380 |

| 5/29 | BO− | SHORT | 95pt | $380 | SL HIT | −$400 | −$400 |

| 6/04 ⭐ | Hammer ULTRA | LONG | 100pt | $400 | TP1 + runner to EOD | +$816 | +$816 |

| 6/09 ⭐⭐ | BO− | SHORT | 150pt | $600 | Runner caught 1,190pt dump | +$1,262 | +$2,680 |

Net P&L Range (2 contracts)

| Scenario | Total |

|---|---|

| Worst case (all runners exited at TP2 only) | +$3,438 |

| Mid case (runners exited mid-bounce) | ~$5,400 |

| Best case (runners held to opposite signal / extreme) | +$7,396 |

Day-by-day Summary

| Date | Result | PnL Range |

|---|---|---|

| 5/08 | No trade | $0 |

| 5/11 | BO+ BUY win | +$480 to +$920 |

| 5/12 ⭐ | BO− SELL big win | +$480 to +$2,520 |

| 5/14 | BO+ BUY win (test of demand) | +$420 to +$480 |

| 5/15 | No trade | $0 |

| 5/18 | No trade | $0 |

| 5/19 | SS SELL win (climax) | +$380 |

| 5/20 | Skipped (counter-trend) | $0 |

| 5/21 | No trade | $0 |

| 5/22 | No trade | $0 |

| 5/25 | Memorial Day | — |

| 5/26 | Skipped (counter-trend) | $0 |

| 5/27 | No trade | $0 |

| 5/28 | Skipped (counter-trend) | $0 |

| 5/29 | BO− SELL LOSS | −$400 |

| 6/01 | No trade | $0 |

| 6/02 | No trade | $0 |

| 6/03 | No trade | $0 |

| 6/04 ⭐ | Hammer BUY A+ | +$816 |

| 6/05 | No trade | $0 |

| 6/08 | No trade | $0 |

| 6/09 ⭐⭐ | BO− SELL — call of the backtest | +$1,262 to +$2,680 |

Stats

| Metric | Value |

|---|---|

| Trading days observed | 22 |

| Days with trades | 7 (32%) |

| Wins / Losses | 6 / 1 |

| Hit rate | 86% |

| Avg R per trade | ~+3.1R (best) / ~+1.6R (worst) |

| Best single trade | +$2,680 (6/09 BO−, best case) |

| Worst single trade | −$400 (5/29 BO− SL hit) |

| Net paper P&L range (2 contracts) | +$3,438 to +$7,396 |

Caveats

• N=7 trades is not statistically significant. Need N=30+ minimum, N=100+ ideal.
• Mostly trending regime during the test window.
• No slippage or commission modeled.
• Visual backtest is subject to confirmation bias — Python backtest with years of data is the next rigor step.
• Real execution will land somewhere in the worst-to-mid range, not best case.

Stopping volume — NOT scanned (TOP PRIORITY to build)

• Coulling's primary BOTTOM-detection tool. In BOTH the NWL and Oil/CL examples it's the stopping volume that calls the low ("big operators moved in to buy") — the hammer / two-bar reversal only CONFIRMS it after.
• Pattern: wide-spread DOWN bar on ULTRA volume that closes off its lows, mid-decline (NOT at a swing extreme). Selling effort absorbed = bullish precursor. Mirror at tops = buying/selling climax.
• Our gap: we catch the hammer that FOLLOWS, but not the stopping volume itself → we're one signal late on the bottoms she's best at calling, and we miss the turn entirely when no clean hammer forms.
• Topping mirror confirmed (NI example): high-vol candle with deep UPPER wick mid-decline = "market makers selling into weakness" = distribution/climax at tops. Build both ends.
• Candidate: add stopping volume (and its topping-climax mirror) as a new signal. Highest-value add from the 2020 book examples.

Effort vs Result / absorption — NOT scanned (TOP PRIORITY — it's the core VPA law)

• The foundation of the whole method: compare EFFORT (volume) to RESULT (price spread).
• High vol + WIDE spread = harmony (genuine move).
• High vol + NARROW spread = ANOMALY = absorption (someone stopping/absorbing the move). Bullish at support / in an uptrend = "market maker buying."
• Low vol + wide spread = anomaly (false move, no real participation).
• Low vol + narrow spread = no demand / no supply.
• PH example: narrow-spread up candles on HIGH volume in an uptrend, labeled "market maker buying ...and again ...and again" — the absorption REPEATS and the stock keeps climbing.
• Our gap: our indicator reads candle SHAPES only; it has no effort-vs-result engine at all. This is arguably a bigger hole than any single pattern because every other VPA signal is downstream of this law.
• Candidate: build an effort-vs-result anomaly detector (start with high-vol + narrow-spread = absorption, both bull and bear).

Wyckoff / Weis blueprint — the post-sprint rebuild plan

Source: David Weis, "Trades About to Happen" (2013) — a modern Wyckoff adaptation. VPA descends from this. Effort-vs-Result is one of Wyckoff's 3 laws; springs/upthrusts/accumulation are all Wyckoff.

Weis Wave = the mechanization path. Sum volume per price WAVE (each up-leg / down-leg), then compare the wave's effort (total volume) to its result (price progress). This reads effort-vs-result ACROSS a sequence of bars — solving BOTH our top gaps (effort/result + sequence reading) in one model. Existing Weis Wave indicators exist = proven and codeable. He says it's intraday-applicable.

Weis's analytical checklist → our status:

1. Effort vs reward (volume vs price progress) — our #1 gap. → Weis Wave.

2. Ease vs lack of movement (wide vs narrow bars) — we have WIDE (continuation tint); MISSING narrow=absorption.

3. Close position within the bar's range — we DON'T use it. Close near high = strength / near low = weakness. EASY, high-value add (a quick win).

4. Shortening of thrust (each push makes less progress = exhaustion) — not detected; wave/sequence concept.

5. Follow-through vs failure after S/R penetration = springs & upthrusts (failed breakouts that reverse) — we have breakouts but NOT the failed-break reversal. (Spring/Upthrust already on the uncoded list.)

6. Tests of high-volume / "vertical" (climactic) areas — not detected; ties to test bar + volume-at-price.

7. Price interaction with trendlines / channels / S-R — we have congestion boxes only; no trendlines/channels.

Where trades happen: the range-edge map (Weis Fig 1.1) — incl. a RISK in our current code

Weis's organizing diagram: big trades cluster at the EDGES of trading ranges. Action signals = shortening of thrust, upthrust, breakout, test of breakout, absorption, spring, test of spring, breakdown, test of breakdown. Behavior is the same on all timeframes. Step 1 of his method = draw the range S/R lines.

• RISK (not just a gap): our breakout logic can fire INTO springs/upthrusts. A spring = false breakDOWN that reverses up; an upthrust = false breakOUT that reverses down. Our BO−/BO+ fire on ANY break that holds one bar — so a spring would trigger BO− (wrong side, price rips back up) and an upthrust would trigger BO+. Spring/upthrust detection is therefore BOTH a new signal AND a guard on existing breakouts. High priority — it's actively costing us, not just missing.
• Test of breakout / breakdown (the retest of the broken level) = often the better, lower-risk entry. We fire on the break itself and don't flag the retest. Add as an action signal.
• Absorption at the edge = effort-vs-result (our #1 gap). Shortening of thrust = checklist #4.
• We're partly set up: congestion box = the "range" seed; we already have genuine breakouts. Need the failed-break (spring/upthrust) + retest variants to complete the edge-of-range playbook.

Drawing Lines: the structure engine (Weis Ch 2, checklist #7 expanded) — LOWER priority for automation

The structural half of Weis's method (lines), separate from the volume half. Maps to checklist #7.

• Horizontal S/R placed to "dramatize the failures" — levels where price repeatedly FAILED to move up/down (not just any high/low). Our congestion box = primitive version.
• Axis lines — a level acting as BOTH support and resistance (price revolves around it). High significance; mechanizable (detect levels tested from both sides). We don't track these.
• Nested trading ranges (ranges within ranges, fractal across TFs). Our box finds one range at a time.
• Touch points add validity — more tests = more significant. Could weight levels by touch count (we already require 2+ aligned pivots = primitive).
• Trend lines = dynamic S/R: downtrend across lower highs = "supply line"; uptrend across rising lows = "demand line"; combined = channels. We have NONE of this.
• Reinforces: closes-near-high + controlled = "strong hands" (checklist #3); "the break itself guarantees little — what preceded it matters" (spring/upthrust + effort-result guard).
• Priority call: this is the HARDER-to-automate half (auto trendlines / axis detection / nested ranges = fiddly, partly discretionary). Weis draws lines by eye and puts them first; for US the volume-wave engine (Weis Wave) is higher-ROI and more mechanizable. Rank lines BELOW the volume engine in the rebuild.

Wick position as a story — partial (we catch extremes only)

• ORLY example: clusters of UPPER wicks in an uptrend = supply/weakness ("lacking conviction"); wicks shifting BELOW the body = support/buying; hanging man = weakness ahead.
• We catch the single-bar extremes (hammer = long lower wick, shooting star / hanging man = long upper wick) but NOT the gradual multi-bar wick-shift narrative.
• Ties into the "read as sequences" note — same single-bar limitation.

Doji = indecision, NOT a reversal (already aligned — keep it)

• Coulling: a long-legged doji, even on HIGH volume, is indecision, not a reversal — wait for confirmation.
• Our code already won't fire a reversal on a doji: the hammer test requires a small upper wick, but a long-legged doji has deep wicks both sides, so it fails and stays silent. Good — no change needed.
• Optional polish: explicitly tag a high-vol long-legged doji as "indecision / wait" so it's visible rather than silent.

Read VPA as SEQUENCES, not single candles (design note)

• Coulling reads a STORY across bars: stopping volume -> reversal candle -> rally -> climax -> roll over. Each example is a sequence.
• Our indicator fires ISOLATED single-bar signals with no memory of the sequence. The "story across bars" is the part we don't capture — arguably the core of VPA. Long-term design direction, not a quick fix.

Two-bar reversal — NOT scanned (add it)

• Seen TWICE now (AAP "two bar reversal", Oil/CL April move) — recurring, worth building.
• Coulling flags a "two bar reversal" (a 2-candle turn on volume — one bar's move reversed by the next) as a real signal.
• Our indicator has ZERO two-bar logic — only single-bar shapes (hammer / shooting star / hanging man / LLD) + breakouts + continuation tints.
• Candidate: add two-bar reversal as a new signal (v1.6).

Hammer swing-low rule is too strict

• hammerReversal requires the bar to be the lowest of the last ~20 bars (absolute swing low).
• Catches absolute bottoms (e.g. the "first hammer" in the AAP example) but MISSES higher-low reversal hammers inside an uptrend (the "second hammer") — those just get a continuation tint, no BUY triangle.
• Candidate: loosen so a higher-low hammer in an uptrend also fires a BUY, not only absolute bottoms.

Volume gate looks ineffective intraday — task #89

• Valid signal currently needs vol >= 1.5x a 20-bar volume SMA.
• That baseline spans overnight + RTH, so RTH bars trivially clear 1.5x → gate is near-toothless intraday → signals fire almost regardless of volume.
• Fix: time-of-day-relative / RTH-only / session-anchored volume baseline. Keep the 1.5x multiplier, fix the baseline. (This is Coulling's "all volume is relative" point.)

How to read this list

• These are captured, not done. Indicator changes wait until after the 5x12 sprint (through July 4) unless trivial.
• Add new findings here as they come up while reading / forward-testing.

1. Right now: learn what's true

The forward test is a learning machine, not a scoreboard. Its job is to separate real edge from noise and find the leaks. A losing paper day that produces a true lesson is the test DOING its job. We pay tuition in fake money so we don't pay it in real money. By this measure, the rough weeks worked — they taught us the stop-level leak, the dip-buyer-fights-trends construct, and the heartbeat-vs-jackie_asks momentum gap.

2. Mid-term: a validated edge worth real money

Everything points at the Lucid eval. The validation bar says we only risk real capital on something PROVEN, not something that "felt good." So the goal of all this testing is to build that proof — or honestly disprove it and move on. jackie_asks is the lab; the edge is the product. We're not trying to win paper trades; we're earning the conviction to act when real money is on the line.

3. Underneath it all: the off-ramp

This is you building a real skill and a real edge so that someday it's a genuine way out — the same theme as the writing: escaping autopilot, building a door where there isn't one. The trades are the vehicle. The point is the trader you're becoming — someone with a tested, mechanical, honest edge instead of a hope.

So what is jackie_asks?

The cheapest classroom we've got. Its value was never "does it win" — it's "what does it teach us about building the thing that will." Keep it as a teacher until it stops teaching. Repurposing it isn't a consolation prize; it's the most honest use of it there ever was.

launchd jobs (the scheduling layer)

• launchd = macOS's built-in scheduler. A .plist says "run THIS command at THIS time / on this interval / keep alive."
• Everything Orion does on a clock is a launchd job calling claude --print HEADLESS — no terminal, no open Claude window needed.
• What we already run as launchd jobs: jackie_asks ×3 fires, heartbeat, dashboard refresh (every 300s), dashboard tunnel, VPA EOD capture (1:20p), Orion Thinks (5:15a), the Telegram bridge.
• launchd is just the trigger mechanism. It doesn't care whether the job does something mechanical or something "thinking."

launchd job vs thinking job (the real distinction)

• launchd job = HOW/WHEN it fires (the scheduler). A "mechanical" job does a defined action: scrape data, rebuild the dashboard, send a file. Deterministic, no judgment.
• thinking job = WHAT it produces. The product is Claude reasoning — an analysis, a digest, a written note, a read of the tape. Orion Thinks is the cleanest example: scheduled by launchd, but its output is a judgment call, not a fixed action.
• So they're not opposites — a thinking job is usually triggered by a launchd job. launchd = the clock; thinking job = the brain it wakes up.

Hosting thinking jobs for someone who doesn't want Claude

• Premise: the end user never installs Claude, never opens a terminal. They just receive the output.
• The Claude-powered jobs run on YOUR machine (launchd + claude --print). The product gets delivered to them by a channel they already use.
• Delivery channels we already have working: the Cloudflare tunnel (a phone URL → live dashboard) and the Telegram bridge (texts).
• So the recipe is: their job runs on your Mac on a schedule → writes a file (note/digest/dashboard panel) → pushed to a hosted URL or texted to them. They get the thinking; they never touch the tool.
• This is basically a productizable service: "I host your thinking job." Same plumbing as Orion, pointed at someone else's question.

Putting it on the dashboard

• The dashboard is already file-driven: any .md dropped in orion/scratch/ auto-renders as its own panel (this recap is one).
• A hosted thinking job for someone else = same pattern: its scheduled run writes a markdown file, build_dashboard.py renders it, the tunnel serves it to their phone.
• Open question for you: keep one shared dashboard, or spin a separate per-person dashboard/URL so their stuff isn't mixed with trading?

Option 1 — Skylight Calendar

• Cost: $300-400 (one-time)
• Touchscreen, purpose-built for this exact use case
• Family members can add events on the screen OR via email/text/app
• Color-coded by person
• Caveat: has its own cloud backend (Skylight's). Not Google, but not local-only either.
• Verdict: ✓ if "not Google" is the rule; ✗ if "nothing leaves the house" is the rule

Option 2 — DIY (touchscreen + custom local app)

• Cost: $200-450 hardware + my build time (~weekend)
• 24-27" touchscreen monitor OR wall-mounted Android tablet
• Raspberry Pi 4 ($45) running browser in kiosk mode
• I'd build a touch-friendly web calendar — tap day, on-screen keyboard, save
• Data stored locally (SQLite or JSON on the Pi/tablet)
• Truly zero cloud, nothing leaves the house
• Most flexible, fully owned

Option 3 — Wall-mounted iPad (offline mode)

• Cost: $30 wall mount (if iPad already owned) or ~$200 for a tablet
• Apple Calendar app with iCloud sync DISABLED
• Walk up, tap date, add event
• Free, fastest to set up
• Caveat: harder to color-code per family member; calendar belongs to whoever's iPad it is

Decision driver

How strict is the "no cloud" requirement?

• "Just not Google" → Skylight (Option 1)
• "Nothing leaves the house" → DIY (Option 2)
• "I'd just like to walk up and tap" (loose) → iPad on wall (Option 3)

Notes from the conversation

• Wife and son both need to be able to add events
• Display should feel like a paper calendar (always-on, visible from a distance)
• The "pen on paper" feel = direct touch input on the wall display, not phone-driven