Daily Trading Report: 2026-06-03

Daily holder split

Daily holder earnings are separated first, matching the weekly close format. AB includes abe_1 and abe_2. VB includes Lucid accounts. Breakout/Kraken stays out of holder P&L unless it produces separate broker-reconciled P&L.

AB Daily

VB Daily

Primary readout

Today was dominated by execution-control repair: stale/delayed TradingView sources, malformed source_symbol JSON, paused-webhook readiness, Abe token refresh, MNQ alert pausing, and the MES 7/8 routing correction. Financial values here are bot-log estimates until broker snapshots or statements are reconciled.

Source of truth

This is the concise operational issue summary. Source of truth remains reports/trading-journal/daily/2026-06-03.md, which contains the full timeline, evidence, validation, and operator-control notes.

01:17 ET TP/SL Control Incident And Recovery Plan

- Incident: Codex/Claude changes conflated Pine strategy behavior with backend execution safety. Pine scripts and chart HUDs were modified to mirror backend bracket ticks, and Tradovate MES/MNQ execution was later changed to ignore Pine-sent `tp_price` / `sl_price` and force backend ticks.

- Business impact: operator reported the system earned less and less after May 21, and current reports show no daily total has come close to `$1,700` since May 22. This note records the suspected process/root-cause link for review; broker statements remain the financial source of truth.

- 2026-06-03: recovery rule adopted: Pine alert payload is execution truth when it sends valid `tp_price` / `sl_price` legs; backend validates and executes, with tick settings used only as fallback for Pine-missing exit legs.

- Restore MES #4 to Pine-managed exits: `useStaticTPSL=false`, static TP input remains `8.0`, static SL remains `4.75`, and alert payload keeps `MES1!`, `mes_gk_sniper_1m_full_input_match`, `MES-4-HP-GK-Sniper-Full-Input-Match`, and `MES #4 HP GK Sniper - Full Input Match`.

01:40 ET Recovery Validation And TV Desktop Caveat

- Runtime check after safe restart: `/status` flat with no active trades or Rithmic pending state; `/webhooks/status` returned `paused=false`; `/accounts/status` showed 13 live rows: 10 Lucid, 2 Abe, and `breakout_01`.

- TradingView Desktop caveat: operator confirmed TV Desktop is the required surface, not a browser URL. `/tmp/tradingview-mcp-9224` was rebuilt and patched for CDP port `9224`, but the currently open TradingView Desktop process was not listening on `127.0.0.1:9224`; MCP chart/Pine/alert inspection remains blocked until TV Desktop is relaunched with `--remote-debugging-port=9224`.

- `/webhook/test` dry-runs approved current representative live payloads for MES #2, MES #4, MNQ #1, MNQ #2, BTC #1-#4, and ETH #1-#2.

- Dry-run proof showed Tradovate futures previews honoring Pine-sent TP/SL prices:

01:55 ET MES/MNQ Live Pine Bridge Audit

- Bridge-only Pine fixes applied:

- `MES-Alignment.pine`: hardcoded alert symbol to `MES1!`.

- `MES-Holy-Grail-Session.pine`, `MES-Holy-Grail-Macro.pine`, `MES-Judas-Swing.pine`, and `MES-Lunch-Breakout.pine`: hardcoded alert symbol to `MES1!` and added existing Pine target variables as `tp_price` so backend execution matches displayed target lines instead of fallback ticks.

- MES Alignment, Holy Grail Session, Holy Grail Macro, Judas, Lunch, and MNQ Alignment were parser/registry-valid but session-blocked at 01:53 ET, with expected account preview sets and qty `0`.

02:03 ET Abe-Style MES/MNQ Restore

- `MES #2 HP GK Sniper.pine`: restored TP `ATR * 0.65` and SL `ATR * 0.40`; removed fixed 3.0/1.5 TP/SL and fixed-RR HUD row.

- `MES-Alignment.pine`: restored target `4.5` and stop `2.5`; removed fixed-RR HUD row.

- `MNQ-1-HP-GK-Sniper.pine`: restored `mainLen=25`, TP `5.5`, SL `3.0`, ER min `0.30`, cooldown `20`; removed fixed-RR HUD row.

- `MNQ-2-HP-GK-Sniper.pine`: restored `mainLen=55`, TP `max(ATR * 0.85, 5.0)`, SL `ATR * 0.55`, ER min `0.32`, cooldown `30`; removed fixed-RR HUD row.

10:06 ET Retired MES #1 Legacy Key Still Traded

- Incident: a stale TradingView MES alert fired at 09:53 ET with `strategy="mes_gk_sniper_1m_24_7_high_probability"` and no `script_id` / `script_title`.

- Backend accepted it because the legacy key was still parser-valid and registered in `REGISTRY`, mapped to the generic `gk_sniper` guard. That allowed a retired alert route to place live MES orders.

- Impact: orders were placed across the 12 enabled Tradovate Lucid/Abe accounts. They closed about 15 seconds later and bot ledger recorded `result=sl`, `pnl=0.0`; operator saw roughly `-$1.25` per account, consistent with near-breakeven/fee or one-tick display rather than a full configured SL.

- Root cause: retirement was documented operationally but not enforced in parser/registry. A retired TradingView script key must fail closed if it appears again.

10:45 ET MNQ Stale Alert MCP Diagnosis

- Important finding: current chart symbol is `CME_MINI_DL:MNQ1!`, not `CME_MINI:MNQ1!`. The `_DL` suffix strongly suggests a delayed-data TradingView symbol variant.

- Runtime caveat: `/webhooks/status` showed `paused=true` during this diagnosis, so new live alerts would be accepted at the HTTP layer and then dropped until webhooks are resumed.

- Missing-alert finding: TradingView internal alert API listed alert id `4845824070` for `MNQ #1 HP · GK Sniper`, symbol `CME_MINI_DL:MNQ1!`, created `09:51:13 ET`, last fired `10:19:00 ET`, currently `active=false`.

- Current likely causes: inactive/stale TradingView alert snapshot, old alert instance, wrong saved alert source, delayed `_DL` feed, or a different alert/layout/account than the visible chart. The bot did not invent the value; it rejected the order because Tradovate live price was 236 ticks away.

10:52 ET MES/MNQ Delayed-Source Guard Deployed

- Incident expansion: MCP alert inventory showed the same TradingView source problem on MES. Active MES alerts were attached to `CME_MINI_DL:MES1!`; one active MES #4-style alert also had MNQ confirmation input `CME_MINI_DL:MNQ1!`.

- Active TradingView MES alert ids found by MCP on `_DL` source:

- `4845789836`: active, `CME_MINI_DL:MES1!`, last fired 09:53 ET; likely stale MES #4/MES GK snapshot and tied to the retired-key incident.

- `4845734143`, `4845734790`, `4846045271`: active MES alerts on `CME_MINI_DL:MES1!`, no latest fire in inventory.

10:58 ET Postmortem Timeline - How The `_DL` Alert Issue Happened

- The `_DL` source came from TradingView alert/chart state, not from the bot inventing a symbol.

- Result: the bot could reject a stale price after comparing against Tradovate, but it could not identify that the alert came from a delayed `_DL` TradingView source until the new `source_symbol` guard was added.

- This made Pine alert payloads more important as execution truth, but payloads still did not include chart source.

- Tradovate MES/MNQ stale alert guard was added.

11:18 ET Abe Premium TradingView Restore

- alert payload still sends `source_symbol`

- Operator action required: repaste MES #4 from the updated repo file into Abe TradingView on a non-`_DL` MES chart, then recreate the alert with `Any alert() function call`.

- Operator moved to Abe premium TradingView, so the repo copy no longer needs the MES-only data-plan workaround on MES #4.

- Restored `/Users/cerebro/vb/ab-trade-x/src/pine/MES/live-indicators/MES #4 HP GK Sniper - Full Input Match.pine` to premium MNQ confirmation behavior:

11:19 ET MES #1 Abe Copy Confirmed

- Operator provided the Abe-style MES #1 HP GK Sniper source.

- Repo file `/Users/cerebro/vb/ab-trade-x/src/pine/MES/live-indicators/MES #1 HP GK Sniper.pine` already matched the strategy body: ATR TP-only scoring, no SL accounting in chart HUD, `scoreToPrint=7`, `tpATRMult=0.65`, 24/7 by default with optional RTH filter.

- Kept required bridge footer only:

- `symbol="MES1!"`

11:34 ET MES Webhook Failed From Malformed JSON

- Operator reported the latest MES failed.

- webhooks `paused=false`

- `data/trades.jsonl` showed no new MES order after the 10:58 blocked stale-alert row, meaning this latest MES failed before order placement/logging.

- Interpretation: the TradingView alert body was malformed JSON. It did not reach strategy validation, source-symbol validation, stale-price validation, or account routing.

11:20 ET Live Webhook Misses And Final Hotfix

- Operator stated more than 10 alerts had already been missed due to Codex confusion, repeated wrong readiness calls, and wrong TradingView/Pine alert input assumptions.

- Confirmed missed/failed live alert causes in `/tmp/bot_cron.log` and `data/trades.jsonl`:

- Webhooks were left paused after restart until 11:17 ET. One accepted MES alert at 11:14 ET was then dropped by the paused gate.

- Multiple MES/MNQ live alerts between 11:13 and 11:18 ET were rejected before order routing because `source_symbol` expanded into malformed JSON containing `settlement-as-close` and nested `symbol`.

13:22 ET Five-Pass Adversarial Misrouting Audit

- Operator requested a quintuple/adversarial check for every possible mistake like the missed-alert and wrong-input incidents.

- `/webhooks/status` was `paused=false`.

- Missing source, `_DL` source, source mismatch, script/strategy mismatch, unknown futures script, missing script id, wrong futures symbol, futures strategy on crypto symbol, and crypto strategy on futures symbol all blocked.

- Final `/webhooks/status` remained `paused=false`; final `/status` remained flat.

14:36 ET Alignment Turned Off + Post-GK Cooldown Fix

- Operator turned off MES/MNQ Alignment alerts after reviewing the live hit rate and the 14:15 ET loss burst.

- Source fix added: backend now remembers recent MES/MNQ GK outcomes and blocks MES/MNQ Alignment for 5 minutes after a same-direction GK TP. Block reason format: `alignment_after_recent_gk_tp:<gk_strategy>:<age>s`.

- This is a backup guard only. The operator TV-side disable is still the immediate live control. Source change requires safe restart to load. At 14:36 ET `/status` was not safe to restart because Breakout had an active ETH trade; a later 14:37 ET check showed `active_trades=0`, `safe_to_restart=true`, and `/webhooks/status paused=false`, so the source fix can be loaded after explicit operator restart approval.

- Root issue: Alignment fired into the same equity-index futures move immediately after GK had already won. At 14:14 ET `MNQ #1 HP · GK Sniper` shorted MNQ and hit TP on `lucid_pro_7`/`lucid_pro_8`; around 14:15 ET MNQ Alignment and MES Alignment re-entered short and both stopped out.

16:07 ET BTC Breakout Protection-Side Check

- Source fix added: Kraken/Breakout UI orders now validate the final visible TP/SL snapshot after submit against the filled entry direction. If a future snapshot is inverted, the bot marks the trade active to keep the single-position gate closed, attempts an emergency UI close/cancel, then raises instead of silently tracking bad protection.

- Operator questioned the active BTC TP being below the opening/entry price.

- Diagnosis: the BTC trade was `sell`/short (`PF_XBTUSD`, entry about `65912.8`, TP `65829.0`, SL `66029.5`). For a short, TP below entry and SL above entry is correct. The Breakout UI labels the closing TP leg as `Long(Reduce)` because reducing a short requires a buy/long reduce order.

- This is a source guard only until a safe restart loads it. It does not change BTC/ETH Pine TP/SL levels.

16:50 ET Tradovate Token Refresh Churn Fix

- Operator reported Tradovate browser logins were happening more often than the intended 70-minute cadence.

- Fix: `scripts/get_tradovate_token.mjs` and `scripts/get_tradovate_token_abe.mjs` now enforce a per-account `/tmp` lock plus a 70-minute cooldown before opening a browser login. Duplicate auth responses inside one run are ignored after the first captured token.

- Operational fix: unloaded and disabled the duplicate user launch agent `com.abtradex.tokenrefresh`. The root daemon could not be disabled from this user session (`Operation not permitted`), but it now hits the same guarded script and exits before browser login during cooldown.

- Diagnosis: multiple launchd jobs pointed at the VB token script: canonical `com.tradovate.tokenrefresh` every `4200` seconds, duplicate user agent `com.abtradex.tokenrefresh` at 06:45/14:50, and root daemon `com.cerebro.token-refresh` every `4200` seconds. The token script could also see duplicate `accessTokenRequest` responses inside one browser login.

16:06 ET MES 7/8 Routing Correction

- Impact confirmed in `data/trades.jsonl`: the 15:22 ET `MES #2 HP GK Sniper` sell routed to enabled Lucid/Abe accounts and stopped out, but skipped `lucid_pro_7` and `lucid_pro_8` because both were runtime-disabled.

- Correction completed at 16:06 ET:

- `/webhooks/status` returned `paused=false`; `/status` returned flat and `safe_to_restart=true`.

- Current operating model: MNQ is off via paused TradingView MNQ alerts, not via account disables. Do not disable `lucid_pro_7` or `lucid_pro_8` to control MNQ while MES should remain live. If backend-side MNQ-only disable is needed later, use a strategy/script-level gate and safe restart after explicit operator approval.

16:39 ET Final Trade Result And Alert Pause

- Operator reported that all TradingView alerts are now paused after this final trade. Treat this as the current TV-side operating state unless a later TV alert inventory check says otherwise.

- Runtime check at 16:39 ET: `/webhooks/status` was still `paused=false`; `/status` was flat with `active_trades=0`, `rithmic_pending=[]`, and `safe_to_restart=true`. This means bot webhooks are unpaused, but the operator-side alert source is paused.

- Latest completed bot-ledger trade group was `MES #1 HP GK Sniper` / `mes_gk_sniper_1`, short `MESM6`, entered at 16:38 ET.

- Outcome group completed at 16:38:32 ET with 12 tracked Tradovate account outcomes, all `tp`, gross bot-ledger P&L `+$69.00` before estimated fees.

Fix policy

Current futures execution policy: valid Pine-sent TP/SL prices are execution truth for MES/MNQ Tradovate brackets; backend tick settings are fallback for Pine-missing exit legs and guard rails only. Live readiness requires /webhooks/status paused=false after every restart. MNQ is currently controlled from TradingView alert pause state, not by disabling lucid_pro_7 or lucid_pro_8.