Sydnee nightly — exit_flow audit — 2026-04-21 P0 findings: 0 P1 findings: 2 Risks: 1 - Area: Exit Flow (Tuesday theme — stop-loss, trim ladder, OBV exits, HOLD_CAP, FLAT_EXIT, EOD/weekend flat) - Branch: `dev` (9577695) - Files scanned: `bot.py` (13 238 lines), `core/persistence.py`, `docs/strategy_decisions.md` - Bugs found (P0 / P1): 0 / 2 - Risks noted: 1 --- Full report (dev branch): https://github.com/kanex1/sydnee.signals/blob/dev/docs/audit_2026-04-21_exit_flow.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-21 — EXIT FLOW ## Summary - Area: Exit Flow (Tuesday theme — stop-loss, trim ladder, OBV exits, HOLD_CAP, FLAT_EXIT, EOD/weekend flat) - Branch: `dev` (9577695) - Files scanned: `bot.py` (13 238 lines), `core/persistence.py`, `docs/strategy_decisions.md` - Bugs found (P0 / P1): 0 / 2 - Risks noted: 1 --- ## Findings ### BUG [P1]: FLAT_EXIT leaves zombie parent trade with 0 shares permanently open **File:** `bot.py:3354` (TRIM1 block, FLAT_EXIT path) **Evidence:** With `FLAT_EXIT=true` and a `mean_revert` or `extension_fade` setup, TRIM1 closes 100 % of shares via a child trade record: ```python # bot.py:3354 trim_shares = t.shares if _flat_exit else t.shares // 2 # = t.shares (100%) # bot.py:3387-3388 remaining = t.shares - trim_shares # = 0 self._update_trade_field(t.trade_id, shares=remaining) # t.shares → 0 in memory + DB ``` The child `trim_trade` (id = `t.trade_id + "_trim"`) is appended to `_deferred_closes` and processed by `_close_trade`, which records it as a closed trim row. The **parent** trade record is never closed — `exit_price` stays `None`. `persistence.py:50`: ```python @property def is_open(self) -> bool: return self.exit_price is None ``` So `open_trades()` returns the parent forever (0 shares, `is_open=True`). On every subsequent 5-minute bar: 1. **Entry blocked permanently.** `_open_trade` at line 4430: `existing = [t for t in self.open_trades() if t.symbol == sym]` — finds the zombie, logs "Entry blocked — already have open LONG 0sh @$..." and returns. No new entries possible for that symbol for the rest of the session. 2. **Exit loop spam.** EXIT 0 (OBV), EXIT 0B (HOLD_CAP), EXIT 1 (stop-loss), EXIT 2 (RSI extreme) all fire `hit=True` on the 0-share parent. `_close_trade` is called, places `MarketOrder(action, 0)` — IBKR rejects. `_execution_qa` returns `None` → `_close_trade` returns at line 5389 without closing. Repeats every bar. 3. **Activity log noise.** `_log_activity` at line 3441 emits "LONG 0sh @$..." every bar; every entry signal logs the "Entry blocked" message. FLAT_EXIT has been live on dev since 2026-04-18. Every mean_revert or extension_fade trade that reached its 1.0×ATR trim level since then would have created this zombie, silently blocking that symbol. **Impact:** Critical — any FLAT_EXIT trade that trims creates a permanent entry block for its symbol and generates IBKR API spam. Symbol is effectively dead for the session. Affects the validation data being collected for the 2026-04-29 freeze decision. **Fix (minimal):** After setting `remaining`, detect the 0-share case and close the parent in-store immediately, bypassing the IBKR order: ```python remaining = t.shares - trim_shares self._update_trade_field(t.trade_id, shares=remaining) if remaining == 0: # FLAT_EXIT took 100 % — close the parent record directly (no order needed, # all shares were already closed via the trim child above) self._close_trade_in_store(t.trade_id, live_price) ``` Alternatively, add a guard at line 2882 (before any exit logic runs): ```python open_trades = [t for t in self.open_trades() if t.symbol == sym and t.shares > 0] ``` --- ### BUG [P1]: FLAT_EXIT + monotonicity override stores wrong TRIM1 price in DB **File:** `bot.py:4619–4620` (monotonicity override) and `bot.py:4695` (`trade._trim_price` assignment) **Evidence:** When FLAT_EXIT is active, `_compute_exits` sets both `trim_dist` and `tgt_dist` to `1.0 × daily_atr_dollar`: ```python # bot.py:4367-4370 if os.environ.get("FLAT_EXIT", "").lower() in ("1", "true", "yes") \ and setup in ("mean_revert", "extension_fade"): trim_dist = 1.0 * daily_atr_dollar tgt_dist = 1.0 * daily_atr_dollar ``` Back in `_open_trade`, the trim-level computation: ```python # bot.py:4604-4606 trim1_price_lvl = round(float(trim_target_price), 4) # = price + 1.0×ATR trim2_offset = 1.0 * sizing_atr_dollar trim2_price_lvl = round(float(price + trim2_offset * direction), 4) # = price + 1.0×ATR ``` `_t1_dist = _t2_dist = 1.0 × ATR`. The monotonicity override fires (condition is ≥ 95 %, and `1.0 / 1.0 = 1.0 ≥ 0.95`): ```python # bot.py:4619-4620 if _t1_dist >= _t2_dist * 0.95: trim1_price_lvl = round(price + 0.50 * _t2_dist * direction, 4) # → 0.5×ATR ``` Then the two assignments diverge: ```python # bot.py:4685 — stored in DB trim1_price column trim1_price=trim1_price_lvl, # 0.5 × ATR (overridden) # bot.py:4695 — stored as in-memory _trim_price (used by EXIT 4) trade._trim_price = trim_target_price # 1.0 × ATR (original, un-overridden) ``` **Result:** - **Before restart**: TRIM1 fires at `1.0 × ATR` (correct per FLAT_EXIT backtest) - **After restart**: `_load_trades_from_db` at line 761 restores `t._trim_price = float(t.trim1_price)` = `0.5 × ATR` (overridden DB value) → TRIM1 fires at half the intended distance The FLAT_EXIT backtest (strategy_decisions.md 2026-04-18) explicitly shows that `0.5 × ATR` ("flat at trim1") delivers `-$40,776/wk` vs `1.0 × ATR`'s `-$22,855/wk` improvement. A bot restart during a live FLAT_EXIT trade degrades it to the provably worse level without any alert. The log at line 4632 records `T1 ${trim_target_price:.2f}` (1.0×ATR), while the dashboard displays `trim1_price` from DB (0.5×ATR) — inconsistency visible to the user. **Impact:** Any FLAT_EXIT trade held through a container restart (daily on dev, restart-on-deploy) fires TRIM1 too early, exits at the suboptimal level, and then creates the zombie bug above. **Fix (two-line):** In `_open_trade`, skip the monotonicity override for FLAT_EXIT setups (they intentionally set t1 = t2 = 1.0×ATR): ```python # bot.py:4619 — add guard: _flat_exit_on = os.environ.get("FLAT_EXIT", "").lower() in ("1", "true", "yes") if not (_flat_exit_on and setup_mode in ("mean_revert", "extension_fade")) \ and _t1_dist >= _t2_dist * 0.95: trim1_price_lvl = round(price + 0.50 * _t2_dist * direction, 4) ``` This keeps the override for normal ladder setups while letting FLAT_EXIT use t1 = t2 = 1.0×ATR as designed. Also ensures DB and in-memory stay consistent. --- ### RISK: Stale EOD-flat comment in `stop()` implies a hard close that doesn't exist **File:** `bot.py:13217` **Evidence:** ```python def stop(self) -> None: ... # EOD flat-by-close (3:55 PM ET) handles end-of-day exits. ← line 13217 open_count = len(self.open_trades()) if open_count: logger.info("Shutdown with %d open positions — preserving for restart", open_count) ``` The "EOD flat-by-close" sweep is commented out at lines 13022–13031 with the note "EOD sweep DISABLED per user request — positions roll into the next session". Mon–Thu positions intentionally roll overnight. The comment in `stop()` is a stale artifact from before that decision and actively contradicts the real behavior. **Risk:** During incident response or on-call debugging, a developer reading `stop()` would expect open Mon–Thu positions to have been cleared by 3:55 PM ET. They'd waste time looking for the close before realising the sweep is disabled. With real-money go-live on 2026-05-01 approaching, any confusion about overnight position state is dangerous. **Fix:** Remove or replace line 13217: ```python # Positions roll overnight Mon–Thu; Friday flat handled in _evaluate_symbol. ``` --- ### OK (checked, working or recently fixed): - **Rule F `entry_time` parse fix** (`bot.py:2914–2920`): ISO string correctly parsed via `datetime.fromisoformat` before `.tzinfo` access. Fix from commit `782e3b6` in place; no regression expected. - **RSI_TRIM_PROFIT_GUARD**: correctly guards TRIM1 (`bot.py:3374`), TRIM2 (`bot.py:3321`), and OBV-BE Rule F (`bot.py:2941–2962`) from slamming stop above/below current price when position is at a loss. - **OBV_LOSS_EXIT spot-exit path** (`bot.py:2945–2957`): fires `hit=True` with `reason` set when `_profit_guard AND profit_per_share < 0`; `_obv_be_applied` correctly set one-shot to prevent re-fire on subsequent bars. - **HOLD_CAP strategy_reason match** (`bot.py:2991–2992`): `strategy_reason` contains `setup_mode.upper()` (appended at line 4630), so "MEAN_REVERT" and "EXTENSION_FADE" are correctly found. The redundant "EXT_FADE" check is harmless. - **TRIM2 / TRIM3 share guards**: `if trim2_shares > 0:` at line 3304 and `if trim3_shares > 0:` at line 3271 prevent 0-share child trims on already-thin runners. - **Trailing stop high/low-water mark persistence** (`bot.py:742–743`): `extreme_since_trim` correctly restored from DB on restart; no trail-loosening on SHORT or premature stop on LONG after restart. - **BXt reversal pending flag persistence** (`bot.py:750–751`): `pending_reversal` restored from DB — 2-bar confirmation survives container restart mid-sequence. - **Force-trim flags persistence** (`bot.py:754–759`): `force_trim_pending`, `force_trim2_pending`, `force_trim_reason` all restored on load; RSI/BXt-forced trim fires correctly after restart. - **Friday EOD flat** (`bot.py:2695–2773`): closes ALL positions by 3:50 PM ET RTH, no rsi_extreme carve-out (fix from 2026-04-17). AH backup flat at 7:50 PM ET catches any positions entered after RTH close. - **RSI EXIT on losing position** (`bot.py:3133–3136`): correctly fires full close (`hit=True`) instead of trying to tighten stop, bypassing the original stop-above-price pathology for losing trades. - **BXt reversal profit-path routing** (`bot.py:3238–3259`): correctly routes to TRIM1/TRIM2/runner-exit based on trim state instead of always doing a full close. Damage-control path for losing BXt reversals (line 3243) confirmed separate. - **HOLD_CAP fires full close on runner after TRIM1** (normal 50% mode): this is intentional per strategy_decisions.md — if TRIM2 hasn't fired by 120 min, the runner is stale. Only becomes a zombie issue in the FLAT_EXIT 0-share case (P1 above).