Sydnee nightly — EXECUTION_QUALITY audit — 2026-08-07 P0 findings: 0 P1 findings: 10 Risks: 2 - Area: Execution Quality (Friday theme) - Branch: `dev` (01b7a0f — docs(peak-monitor): hourly log 2026-08-06 13:09 PT) - Files scanned: `bot.py` (24,173 lines), `core/executor.py`, `docs/audit_2026-08-01_EXECUTION_QUALITY.md`, `git log --oneline -30` - **Bugs found (P0 / P1): 0 / 10 (1 new + 9 carried from 2026-08-01)** - **Risks noted: 2 (both carried from 2026-08-01)** **Cross-check:** `git log --oneline -30` shows zero commits to `bot.py`, `core/`, or any strategy/core file since 2026-07-17 (all subsequent commits are audit docs + peak-monitor hourly logs). All 9 P1 bugs and 2 risks from the 2026-08-01 EXECUTION QUALITY audit are re-verified at current line numbers — all present and unchanged. One new P1 found this session in the `Cancelled/Inactive` retry path. --- Full report (dev branch): https://github.com/kanex1/sydnee.signals/blob/dev/docs/audit_2026-08-07_EXECUTION_QUALITY.md Reply FROM [email protected] to [email protected] to request fixes, e.g.: "code_task on sydnee-signals-dev: apply fix for the P0 about RVOL threshold in bot.py" Sydnee Agent will propose + you APPROVE (or plain 'approve') + auto-push to dev. --- Full audit below (first 12 KB) --- # Nightly Audit 2026-08-07 — EXECUTION QUALITY ## Summary - Area: Execution Quality (Friday theme) - Branch: `dev` (01b7a0f — docs(peak-monitor): hourly log 2026-08-06 13:09 PT) - Files scanned: `bot.py` (24,173 lines), `core/executor.py`, `docs/audit_2026-08-01_EXECUTION_QUALITY.md`, `git log --oneline -30` - **Bugs found (P0 / P1): 0 / 10 (1 new + 9 carried from 2026-08-01)** - **Risks noted: 2 (both carried from 2026-08-01)** **Cross-check:** `git log --oneline -30` shows zero commits to `bot.py`, `core/`, or any strategy/core file since 2026-07-17 (all subsequent commits are audit docs + peak-monitor hourly logs). All 9 P1 bugs and 2 risks from the 2026-08-01 EXECUTION QUALITY audit are re-verified at current line numbers — all present and unchanged. One new P1 found this session in the `Cancelled/Inactive` retry path. --- ## Findings ### BUG [P1] (NEW 2026-08-07): `Cancelled/Inactive` retry in `_execution_qa` missing `start_time` reset — retry order killed by timeout after ≤6 seconds **File:** `bot.py:7984` (missing `start_time = time.time()` before `continue`) **Evidence:** ```python # bot.py:7966–7985 — Cancelled/Inactive retry path if status in ("Cancelled", "Inactive"): ... if not retried: retried = True ... exec_trade = self._place_order_with_overnight_fallback(_ct2, order2, ss.contract) oid = exec_trade.order.orderId self._active_order_ids.add(oid) continue # ← no start_time = time.time() before this # bot.py:8031-8034 — PreSubmitted MKT→LMT path (correctly resets): # "Reset budget so the retry order gets its own MAX_WAIT window — # otherwise a slow placeOrder can chew through the original budget # and the next loop iteration immediately kills the new order." start_time = time.time() # bot.py:8047-8050 — 30s timeout path (correctly resets): # (same comment, same fix) start_time = time.time() ``` The `Cancelled/Inactive` retry path places a new order via `_place_order_with_overnight_fallback` but does NOT reset `start_time`. The two other retry paths (PreSubmitted at line 8034, 30s timeout at line 8050) both explicitly reset `start_time` with identical comments explaining the race. The Cancelled path has the same `_place_order_with_overnight_fallback` call that can be slow, but no budget reset. Worst case: an IOC entry cancelled by IBKR at t=113s (e.g., pre-market thin book) → `_place_order_with_overnight_fallback` consumes 2–3s → `continue` fires at t≈116s → while check passes (116 < 120) → `self.ib.sleep(3)` → loop exits at t=119s → `self.ib.cancelOrder` kills the retry order. The retry order may have received a fill in those 3s that goes undetected, creating an orphaned IBKR position. **Impact:** Retry order for `Cancelled`/`Inactive` entries gets ≤6 seconds of fill monitoring instead of a full 120s window. On active market hours when IBKR sends rapid cancels (IOC on low-liquidity names), the retry is guaranteed to be killed. Entry is silently dropped with a misleading "EXEC QA: TIMEOUT 120s, killing order" log (which references MAX_WAIT, not the exhausted-budget root cause). **Fix:** Add `start_time = time.time()` at `bot.py:7985`, after `self._active_order_ids.add(oid)` and before `continue`: ```python self._active_order_ids.add(oid) # Reset budget so the retry order gets its own MAX_WAIT window — # otherwise a slow placeOrder can chew through the original budget # and the next loop iteration immediately kills the new order. start_time = time.time() continue ``` --- ### BUG [P1] (carried from 2026-07-10 / 2026-08-01): `OBV LOSS EXIT` fires on profitable trades below cushion threshold **File:** `bot.py:5113–5128` **Evidence:** ```python _min_cushion = max(float(t.entry_price) * _cushion_pct, atr_val * 0.25) if _profit_guard and profit_per_share < _min_cushion: # ← always positive if _loss_exit: hit = True reason = (f"OBV rule F against {_dir_lbl_ex} at loss after ...") self._log_activity(sym, "OBV LOSS EXIT: ... at loss ...", "trade") # ← log wrong ``` Guard is `< _min_cushion` (always > 0, e.g. $0.75/sh on $100 stock with $3 ATR). Profitable trades with small gain below cushion are force-exited at market with a misleading "at loss" log entry. **Impact:** On dev (`OBV_LOSS_EXIT=true`): winners held past 5 bars with a small favourable move are ejected before profit target. Prod safe (flag default off). **Fix:** ```python if _loss_exit and profit_per_share < 0: hit = True ... ``` --- ### BUG [P1] (carried since 2026-07-04): `risk.state.trade_count` not restored from DB on restart — `max_daily_trades` global cap bypassed **File:** `core/risk.py:118`, `bot.py:23458–23460` **Evidence:** ```python # bot.py:23458-23460 — startup only calls set_open_positions(): open_count = len(self.open_trades()) if open_count > 0: self.risk.set_open_positions(open_count) # trade_count stays 0 ``` `risk.state.trade_count` remains 0 after every restart. Each mid-day restart resets the global trade cap. `RSI_TICK_FIRE` can re-fire up to `max_daily_trades` additional times after each restart. **Fix:** In startup, query `self.db.get_today_trades()` and restore `trade_count` from the result count. --- ### BUG [P1] (carried since 2026-07-03): `_execution_qa` IndexError when `"Filled"` arrives before fill detail — orphaned IBKR position **File:** `bot.py:7946–7951` **Evidence:** ```python if status == "Filled" or (exec_trade.fills and filled > 0): fp = float(exec_trade.orderStatus.avgFillPrice or 0) or \ float(exec_trade.fills[0].execution.price) # ^^^ IndexError if exec_trade.fills == [] and avgFillPrice == 0 ``` When IBKR fires `"Filled"` before `execDetails` populates `fills`, `fills[0]` raises `IndexError`. No `Trade` record is created → orphaned IBKR position not tracked in DB. **Fix:** ```python fp = float(exec_trade.orderStatus.avgFillPrice or 0) if not fp: if exec_trade.fills: fp = float(exec_trade.fills[0].execution.price) else: continue # fills not yet populated — wait one more poll ``` --- ### BUG [P1] (carried since 2026-07-03): `broker_executions.timestamp_sent` always equals `timestamp_filled` — order-to-fill latency unmeasurable **File:** `bot.py:7898–7909` **Evidence:** ```python ts_filled = _dt.datetime.now(_dt.timezone.utc) # ← captured at fill-detect time ... VALUES (%s,%s,...,%s,%s) (... ts_filled, ts_filled)) # ← both columns = post-fill now() ``` `start_time` (captured at line 7933) is never threaded into `_persist_broker_execution`. `timestamp_filled − timestamp_sent` is always 0 ms for every row. **Fix:** Thread `start_time` into `_persist_broker_execution`: ```python ts_sent = _dt.datetime.fromtimestamp(order_start_time, tz=_dt.timezone.utc) ts_filled = _dt.datetime.now(_dt.timezone.utc) VALUES (... ts_sent, ts_filled) ``` --- ### BUG [P1] (carried since 2026-07-03): `signals.tempo` uses P&L/share as execution-quality proxy — actual slippage never queried **File:** `bot.py:11147–11148` **Evidence:** ```python per_share = t.pnl / t.shares if t.shares > 0 else 0 # ← P&L/share, not slippage slippages.append(per_share) # ← variable name misleading ``` `broker_executions.slippage` is never read by `_tempo_daily_analysis`. Hourly breakdown reflects trade profitability, not execution degradation. Bad fills are invisible in the tempo output. **Fix:** In `_tempo_daily_analysis`, join `broker_executions` on `symbol + timestamp_filled` grouped by hour; report `avg(slippage)` separately. --- ### BUG [P1] (carried since 2026-06-12): `config_syms` NameError in `_exec_qa_patrol` — position mismatch check never runs **File:** `bot.py:8333` **Evidence:** ```python # bot.py:8272: watchlist_syms = set(self.symbols) ← defined here # bot.py:8333: if ib_qty != bot_qty and sym in config_syms: # ← NameError: config_syms undefined ``` `watchlist_syms` is defined at `bot.py:8272`; `config_syms` is undefined. The `except Exception: pass` at `bot.py:8336` silently swallows the `NameError` every patrol cycle. IBKR/bot position mismatches are never detected. **Fix:** `bot.py:8333` — replace `config_syms` with `watchlist_syms`. --- ### BUG [P1] (carried since 2026-06-12): `_execution_qa` 30s MKT fallback outside RTH cancels valid resting LMT, places rejected MKT, silently drops entry **File:** `bot.py:8037–8044` **Evidence:** ```python if elapsed > RETRY_AT and not retried and not is_manual: # RETRY_AT=30, no RTH guard retried = True self.ib.cancelOrder(exec_trade.order) # ← cancels valid resting off-hours LMT ... order2 = MarketOrder(action, shares) # ← IBKR rejects MKT outside RTH ``` No RTH guard. Off-hours resting LMT cancelled after 30s and replaced with a GTC-wrapped MKT that IBKR rejects. `retried=True` → next rejection → entry silently dropped. **Fix:** Add RTH check at `bot.py:8037`: ```python if elapsed > RETRY_AT and not retried and not is_manual and in_rth: ``` Outside RTH, refresh the aggressive limit price and re-place a new LMT instead. --- ### BUG [P1] (carried since 2026-06-12): `RSI_TICK_FIRE` window ends at 780 (13:00 ET) — three peak RTH hours cut **File:** `bot.py:22189` **Evidence:** ```python if not (570 <= t_min < 780) or now_et.weekday() >= 5: # 780 = 13:00 ET, RTH = 960 ``` RTH closes at 960 (16:00 ET). `rsi_extreme` entries and tick-fire state machine are blocked 13:00–16:00 ET. The 13:00 ET bucket yielded +0.534% avg / 67.2% WR in the 2026-05-19 backtest. **Fix:** `bot.py:22189` — change `780` → `960`: ```python if not (570 <= t_min < 960) or now_et.weekday() >= 5: ``` --- ### BUG [P1] (carried since 2026-06-19): `_tape_last_loss_ms` in-memory only — TAPE loss cooldown resets on every bot restart **File:** `bot.py:21312–21314` (write), `bot.py:21706–21708` (read) **Evidence:** ```python # bot.py:21312-21314 — write on stop hit self._tape_last_loss_ms[sym] = now_ms # ← dict in memory, no Redis write # bot.py:21706-21708 — gate at entry _last_loss = self._tape_last_loss_ms.get(sym, 0) # ← always 0 after restart ``` `TAPE_LOSS_COOLDOWN_MIN` gate resets on every container restart (6+ per day on dev). Back-to-back stop pattern can recur across any restart between the two stops. **Fix:** Write `tape:loss_cooldown_ms:{sym}` to Redis on stop hit (TTL = `TAPE_LOSS_COOLDOWN_MIN × 60`); restore from Redis on cold cache. --- ## Risks ### RISK (carried since 2026-07-03): `broker_executions.slippage` measures fill vs retry-order limit — not signal-to-fill slippage **File:** `bot.py:7896` ```python slippage = round((fill_price - req_px) * direction, 4) if (req_px > 0 and fill_price > 0) else 0.0 ``` For MKT retry orders (`lmtPrice=0`), slippage records as `0.0`. True signal-to-fill slippage requires joining `broker_executions` with `trades.signal_price`. Understates execution degradation on retried fills. --- ### RISK (carried since 2026-07-03): `_active_order_ids` retains cancelled order ID after retry — set grows without bound **File:** `bot.py:7937` (add), `bot.py:8082` (discard only final `oid`) On retry, `oid` is reassigned to the new order's ID. The `finally` block discards only the current `oid`; the original cancelled order's ID remains in `_active_order_ids` indefinitely. No functional consequence (`_exec_qa_patrol` guards against stale by age); set grows by ~5–10 entries per active trading day. **Fix:** `self._active_order_ids.discard(original_oid)` before reassigning `oid` to the retry order. --- ## OK (checked, working or recently fixed) - **No new commits since 2026-08-01 execution audit:** Only peak-monitor docs appear in `git log --oneline -30`. All findings above are unambiguously unaddressed. ✓ - **`core/executor.py` `place_limit` RTH gap:** `OrderExecutor` only instantiated for the AB strategy (dev paper only) — not the main entry path. Acceptable scope. ✓ - **IOC partial fill handling:** `bot.py:7946` — `(exec_trade.fills an