Sydnee nightly — execution audit — 2026-04-17 P0 findings: 1 P1 findings: 2 Risks: 2 - Area: execution quality (Friday theme) - Day of week: Friday (4) - Files/sources scanned: 3 (bot.py, docs/proposal_smart_order_execution.md, docs/strategy_decisions.md) - Recent fixes cross-checked: git log --oneline -30 (no execution fixes in window) - **API CAVEAT**: dev.sydnee.ai returns `x-deny-reason: host_not_allowed` from audit environment. Runtime data (fill latency, block counts, today's trades) could NOT be pulled. All findings are static code analysis only. Runtime portion remains unaudited. - Bugs found (P0): 1 - Bugs found (P1): 2 - Risks noted: 2 --- Full report (dev branch): https://github.com/kanex1/sydnee.signals/blob/dev/docs/audit_2026-04-17_execution.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-04-17 — EXECUTION QUALITY ## Summary - Area: execution quality (Friday theme) - Day of week: Friday (4) - Files/sources scanned: 3 (bot.py, docs/proposal_smart_order_execution.md, docs/strategy_decisions.md) - Recent fixes cross-checked: git log --oneline -30 (no execution fixes in window) - **API CAVEAT**: dev.sydnee.ai returns `x-deny-reason: host_not_allowed` from audit environment. Runtime data (fill latency, block counts, today's trades) could NOT be pulled. All findings are static code analysis only. Runtime portion remains unaudited. - Bugs found (P0): 1 - Bugs found (P1): 2 - Risks noted: 2 --- ## Findings ### BUG [P0]: Multi-leg fill — `fills[0]` price used instead of average fill price **File:** `bot.py:4654` (entry), `bot.py:5079` (exec-qa patrol) **Pattern:** Partial fill aggregation — first fill leg price recorded, not VWAP **Evidence:** ```python # bot.py:4653-4655 if status == "Filled" or (exec_trade.fills and filled > 0): fp = exec_trade.fills[0].execution.price # ← FIRST fill only fq = int(filled) # ← correct total qty ``` `exec_trade.orderStatus.filled` correctly totals all legs; `fills[0].execution.price` is only the first leg's price. For orders split across multiple venues (common on liquid names with >300 shares), each leg has its own price. The last legs can be 1-5¢ higher than the first on a fast-moving name. Same bug at bot.py:5079 in the exec-qa patrol manual-fill path: ```python fp = float(et.fills[0].execution.price) if et.fills else 0.0 ``` **Impact:** - `entry_price` stored in DB is wrong → all P&L calculations drift - Stop-to-fill distance displayed in push notification (`_risk_dollar`, `_rr`, line 4595-4596) is wrong - In paper trading, IBKR typically fills as a single leg (low immediate risk), but with real-money go-live 2026-05-01, split fills will be common on any position >200 shares in mid-cap names. **Fix:** ```python # Replace fills[0] with avgFillPrice (weighted average across all legs): fp = exec_trade.orderStatus.avgFillPrice or exec_trade.fills[0].execution.price fq = int(filled) ``` Apply at both `bot.py:4654` and `bot.py:5079`. --- ### BUG [P1]: `signal_price` not persisted — slippage measurement falls back to P&L/share proxy **File:** `bot.py:7572-7596` (Tempo daily), `bot.py:449/459` (PendingPullback) **Pattern:** Missing field propagation — signal_price lives in PendingPullback but never reaches Trade/DB **Evidence:** `PendingPullback` captures `signal_price` at detection time (line 459). It's passed as `price` to `_open_trade` but never stored on the Trade object or in the DB INSERT. The Tempo daily analysis at line 7566 explicitly acknowledges this gap: ```python # Analyze slippage: compare entry_reason price expectation vs actual fill # (Approximate — we don't store the original limit price, but we can # compare entry_price to the signal bar close if available) ... per_share = t.pnl / t.shares if t.shares > 0 else 0 # P&L/share ≠ slippage ``` P&L/share mixes alpha with slippage — can't distinguish a bad fill from a bad signal. `proposal_smart_order_execution.md:79` already calls for `{signal_price, lmt_price_attempted, fill_price, slippage_vs_signal}` logging but that proposal is post-go-live. The gap exists today. **Impact:** - Execution quality reporting is blind to true slippage (fill vs signal bar close) - Can't diagnose whether IOC limit misses are causing worse-than-market fills - Pre-go-live baseline slippage is unestablished **Fix (minimal):** Store `signal_price` on the Trade object at `_open_trade` entry and persist to DB. One new column `signal_price DECIMAL(12,4)` in schema + `ensure_trade_state_columns()`. ```python # bot.py:_open_trade, after Trade() construction: trade.signal_price = price # signal bar close # bot.py:_add_trade → pass to insert_trade ``` --- ### BUG [P1]: `entry_time` records fill-completion timestamp, not signal time **File:** `bot.py:4533` **Pattern:** Timestamp semantics — entry_time set after exec_qa, not at signal detection **Evidence:** ```python # bot.py:4533 (inside _open_trade, after _execution_qa returns) entry_time=datetime.now(ET).isoformat(), ``` `_execution_qa` sleeps up to 120s waiting for fill confirmation (loop at line 4647, `ib.sleep(3)` each iteration). For a 30-second IOC fill, `entry_time` lags signal detection by ~30-120s. `PendingPullback.signal_time` (line 462) captures the real signal moment but is never propagated to the Trade or DB. The exec-qa loop logs elapsed time in activity (line 4657: `"EXEC QA: ... FILLED in {elapsed}s"`) but activity logs aren't queryable for analytics. **Impact:** - Fill latency (signal → fill) is not computable from trade data - Hold duration computed as `exit_time - entry_time` is actually `exit_time - fill_time`, understating the real holding period for slow fills - Execution quality reviews (Tempo weekly, proposal audits) have no latency benchmark **Fix:** Pass `signal_time` through the call chain and store it on Trade: ```python # PendingPullback already has signal_time — pass through _deferred_trades tuple, # then set trade.signal_time = signal_time in _open_trade. # Add signal_time TIMESTAMPTZ column to schema. ``` --- ### RISK: Friday EOD 3:50 PM ET flat depends on bar events, no timer backup **File:** `bot.py:2670` (flat check), `bot.py:2221` (trigger path), main loop `bot.py:12539-12540` **Pattern:** Event-driven safety net — critical flatten has no independent periodic sweep **Evidence:** The `t_min >= 15 * 60 + 50` (3:50 PM ET) flat sweep (line 2670) lives inside `_evaluate_symbol(sym)`, which is called ONLY from `_handle_tick(sym, bars, has_new_bar)` at line 2221. `_handle_tick` is triggered by `rtb.updateEvent` (5-second real-time bars). Main loop at lines 12539-12540: ```python self._process_entry_candidates() self._process_deferred_orders() ``` There is **no** `for sym in self.symbols: _evaluate_symbol(sym)` timer call. The commented-out EOD sweep (lines 12767-12776, intentionally disabled) targeted 7:55 PM ET and is not a substitute for the 3:50 PM ET Friday flat. If a symbol's RTB feed goes quiet before 3:50 PM ET — thin tape, IBKR routing issue, or connection hiccup — that position will NOT be closed before weekend. **Today is Friday. This risk is active.** **Observed scope:** All liquid ETFs/stocks in the watchlist should fire RTB events continuously through 4:00 PM ET. Low-probability for core symbols. However, the watchlist includes some mid/small-cap names (COIN, HOOD, PLTR) that can thin out after 3:40 PM ET. **Fix:** Add a timer-based EOD Friday flat fallback in the main loop, triggered once per session at 3:55 PM ET Friday regardless of bar events: ```python # In main loop (after line 12541), Friday-only backup: if datetime.now(ET).weekday() == 4: t_min_now = datetime.now(ET).hour * 60 + datetime.now(ET).minute if t_min_now >= 15 * 60 + 55 and not getattr(self, '_fri_flat_sweep_done', False): for sym in list(self.sym_states.keys()): self._evaluate_symbol(sym) self._fri_flat_sweep_done = True ``` --- ### RISK: Runtime audit data unavailable — `dev.sydnee.ai` firewalled from audit host **File:** N/A (infrastructure) **Pattern:** Audit coverage gap **Evidence:** ``` HTTP/2 403 x-deny-reason: host_not_allowed ``` `curl -s "https://dev.sydnee.ai/api/trades" -H "X-API-Key: 8881"` from audit host returns 403. Today's fill latency, block reason distribution, and EOD flatten effectiveness (the three primary Friday audit metrics per spec) could not be measured at runtime. **Impact:** - No data on: fill latency histogram, IOC vs MKT retry rate, `Entry blocked` reason counts - Cannot verify: RV=None trades blocked (fail-closed fix validation), fill times vs signal times - Static code audit substituted; all three runtime metrics remain dark **Action:** The API allowlist should include the audit runner's egress IP, or audit should be scheduled to run from within the VPS/container network. --- ## OK (checked, working or recently fixed) - **IOC limit during RTH**: correctly set `tif="IOC"` on entry LimitOrder (bot.py:4515). Correct. - **Retry-on-cancel order cancellation**: timeout at bot.py:4767 calls `ib.cancelOrder(exec_trade.order)` which targets the retry order (exec_trade reassigned at 4681). GTC retry is properly killed on 120s timeout. OK. - **Pre/post-market → MarketOrder**: separate code path at line 4518, not IOC. Correct. - **ExecQA patrol**: runs every 15 min as backup (line 12834-12839); cancels stale orders not in `_active_order_ids`. Correct. - **Friday EOD 25% trim cadence**: 10-min cooldown (`_last_eod_trim_time`) persisted to DB (line 2658-2659). Restart-safe. - **RSI extreme vs divergence EOD exempt fix** (2026-04-15): `startswith('RSI extreme')` correctly excludes late RSI extreme only; confirmed via comment at line 2609-2614. OK. - **Sizing theater fix** (2026-04-15): `total_scale` now applied at line 4389-4393. Off-hours/close-hour/choppy multipliers are real. OK. - **RV fail-closed on None** (2026-04-14): `rv is None → skip entry` at line 3774-3776. Correct. - **Smart order execution proposal**: `fills[0]` issue and signal_price gap are documented in `proposal_smart_order_execution.md` as post-go-live work. Both findings here predate that proposal and are not yet addressed in code.