Sydnee nightly — config_drift audit — 2026-04-19 P0 findings: 0 P1 findings: 3 Risks: 2 - Area: Config Drift (Sunday theme — env vars, constants, doc↔code parity) - Files/sources scanned: `bot.py`, `config.json`, `CLAUDE.md`, `docs/strategy_decisions.md`, `docs/peak_confirm_monitor_log.md`, `polygon_client.py`, `core/database.py`, `core/persistence.py` - Runtime source: dev.sydnee.ai unreachable from audit host (sandbox network block); code-only analysis - Bugs found (P0): 0 - Bugs found (P1): 3 - Risks noted: 2 - Already-found (weekly 2026-04-19): 4 items re-confirmed, not re-filed --- Full report (dev branch): https://github.com/kanex1/sydnee.signals/blob/dev/docs/audit_2026-04-19_config_drift.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-19 — CONFIG DRIFT ## Summary - Area: Config Drift (Sunday theme — env vars, constants, doc↔code parity) - Files/sources scanned: `bot.py`, `config.json`, `CLAUDE.md`, `docs/strategy_decisions.md`, `docs/peak_confirm_monitor_log.md`, `polygon_client.py`, `core/database.py`, `core/persistence.py` - Runtime source: dev.sydnee.ai unreachable from audit host (sandbox network block); code-only analysis - Bugs found (P0): 0 - Bugs found (P1): 3 - Risks noted: 2 - Already-found (weekly 2026-04-19): 4 items re-confirmed, not re-filed --- ## Findings ### BUG [P1]: RVOL blowoff ceiling in CLAUDE.md reads >2.0x; code enforces >5.0x **File:** `CLAUDE.md:59` vs `bot.py:3897` **Evidence:** ```markdown # CLAUDE.md (current, stale): | > 2.0x | ✅ enter (trend confirmed) | ❌ skip (blowoff risk) | ``` ```python # bot.py:3897 (actual): if _rv_ceil > 5.0 and _is_rsi_extreme: self._log_activity(sym, f"… high RV10 ({_rv_ceil:.2f}x > 5.0x, blowoff risk … ``` `strategy_decisions.md` documents the tune: "Tue 04-15: RV blowoff ceiling 3.0 → 5.0 on dev" (commit `b3aa738`). CLAUDE.md was not updated at that point; it still shows the pre-tune value of 2.0. **Impact:** Anyone reading CLAUDE.md to understand RVOL policy believes rsi_extreme is blocked above 2.0×. In reality the 2.0–5.0× bucket fires normally, which is correct and intentional. Mis-diagnosis of entry blocks, and the onboarding doc misleads any human reviewer or AI coding session. Additionally the bucket-analysis comment at `bot.py:3888–3895` references "3.0→5.0" — all three documents (CLAUDE.md, strategy_decisions.md, code comment) now express three different historical stages, making the current policy ambiguous without reading code. **Fix:** Update CLAUDE.md RVOL Policy table, row 3: ```markdown | > 5.0x | ✅ enter (trend confirmed) | ❌ skip (blowoff risk) | ``` (Also update row 2: `0.8 – 5.0x | ✅ enter | ✅ enter` to accurately show the rsi_extreme pass-through range.) --- ### BUG [P1]: `RSI_PEAK_CONFIRM_RTH` flag is live on dev with no strategy_decisions.md entry and a negative backtest **File:** `bot.py:3476–3488`, `docs/peak_confirm_monitor_log.md`, `docs/backtest_rsi_peak_confirm_fast_rth_2026-04-16.md` **Evidence:** - `bot.py:3476`: `_peak_confirm_on = (_in_rth_session and os.environ.get("RSI_PEAK_CONFIRM_RTH", "").lower() in ("1", "true", "yes"))` — gated but present and wired into the live entry path. - `docs/peak_confirm_monitor_log.md:4`: "Feature flag: `RSI_PEAK_CONFIRM_RTH=true` (dev)." Confirms the flag was set in the dev container. - `docs/backtest_rsi_peak_confirm_fast_rth_2026-04-16.md:10–19`: RTH-only backtest result: **17% WR, −$999 avg** vs baseline 32% WR, −$885 avg. Net conclusion: *"Much worse in RTH."* - `docs/strategy_decisions.md`: **zero entries for `RSI_PEAK_CONFIRM_RTH`**. No hypothesis, no validation window, no success criteria, no Final Call. - `docs/peak_confirm_monitor_log.md:47, 62`: monitor host had no visibility into whether the flag was actually exercising; possible silent deployment issue never ruled out. **Impact:** A feature that backtested worse than the baseline (17% WR vs 32%, −$999 avg vs −$885 avg) is deployed on dev with no formal decision entry, no validation window, and no success criteria. Under the freeze regime (freeze since 2026-04-15 per strategy_decisions.md), this represents both a freeze violation AND an undocumented algo change. If the flag is currently `true` on dev, every RTH `rsi_extreme` entry is going through peak-confirm logic that reduces win rate by ~15 percentage points — without anyone having formally approved running it. **Fix (two-part):** 1. **Immediate:** Confirm the current env value of `RSI_PEAK_CONFIRM_RTH` on dev staging. If `true`, disable it (`RSI_PEAK_CONFIRM_RTH=false` in dev docker-compose) given the negative backtest and freeze context. 2. **Documentation:** Add a `strategy_decisions.md` entry documenting the backtest result (negative), the disable decision, and park for post-freeze re-evaluation with a properly scoped experiment (e.g., limit to specific setups where peak-confirm adds value). --- ### BUG [P1]: `risk_per_trade_pct` fallback is 1.0% but config.json sets 2.0% **File:** `bot.py:602` vs `config.json:8` **Evidence:** ```python # bot.py:602 self.risk = RiskManager(RiskConfig( capital=self.cfg.get("capital", 25000), risk_per_trade_pct=self.cfg.get("risk_per_trade_pct", 1.0), # ← fallback 1.0 … )) ``` ```json // config.json:8 "risk_per_trade_pct": 2.0 ``` The fallback (1.0%) is half the configured value (2.0%). This was not caught in the weekly audit's CONFIG SPRAWL finding, which noted `capital`, `daily_loss_limit`, `max_daily_trades`, `max_shares`, and `max_concurrent_positions` mismatches but missed this one. **Impact:** If `config.json` fails to load (or `risk_per_trade_pct` key is absent), the bot silently drops to 1% risk per trade — halving position sizes for the entire session. This is in the "safer" direction (unlike the `daily_loss_limit` landmine), but it still silently mis-sizes every trade. In a real-money context, systematic under-sizing is a subtle P&L drag that would be hard to attribute to a config issue. **Fix:** Align the fallback: `self.cfg.get("risk_per_trade_pct", 2.0)`. Or better: remove fallbacks for risk-critical params and fail loudly at startup (see weekly P1 recommendation). --- ### RISK: FLASK_SECRET randomizes on every container restart — sessions killed on redeploy **File:** `bot.py:8471` **Evidence:** ```python app.secret_key = os.environ.get("FLASK_SECRET", _secrets.token_hex(32)) ``` If `FLASK_SECRET` env var is absent, the Flask secret key is a fresh random token each start. Every container restart (e.g., auto-deploy on push, crash recovery) invalidates all active browser sessions. The weekly audit flagged this as "should be pinned to a stable env var before go-live" but it remains unfixed. **Impact (sharpened with go-live 12 days out):** On a live-money trading day, a container restart (from a bugfix push or an OOM kill) will log out anyone monitoring the dashboard — exactly the moment the operator needs continuous visibility. This is particularly acute if a routine commit triggers a staging redeploy mid-session. **Recommendation:** Add `FLASK_SECRET=<stable-hex>` to both dev and prod docker-compose before 2026-05-01. One `python3 -c "import secrets; print(secrets.token_hex(32))"` generates a suitable value. --- ### RISK: Algo freeze violated — 3 strategy features landed after 2026-04-15 freeze **File:** `docs/strategy_decisions.md:27` ("Tue 04-15: FREEZE DEV ALGO") vs git log **Evidence:** ``` git log --oneline: 3b3f6e8 feat(exit): OBV_LOSS_EXIT flag — spot-exit when OBV rule F fires at a loss [2026-04-19] b7aad7d feat(exit): HOLD_CAP_MIN flag — time-based forced flat exit for mean_revert/ext_fade [2026-04-18] 2cadf00 feat(exit): FLAT_EXIT flag — collapse trim/target ladder into single exit at trim2 level [2026-04-18] ``` All three are new algo-affecting flags (`FLAT_EXIT`, `HOLD_CAP_MIN`, `OBV_LOSS_EXIT`) committed after the stated freeze date. `strategy_decisions.md` entries exist for each (as "Pending") with `Dev enabled` dates of 2026-04-18 or 2026-04-19. There is a note on the HOLD_CAP entry acknowledging the freeze: "bumps the 2026-04-15 dev freeze. Justified as risk-discipline…" **Impact:** These three flags ARE feature-flagged (default off unless env set), and each has a documented strategy_decisions.md entry with validation window and success criteria — so the concern is manageable. But the pattern is: 4 env flags added post-freeze (FLAT_EXIT, HOLD_CAP_MIN, OBV_LOSS_EXIT, and potentially RSI_PEAK_CONFIRM_RTH above). If all are enabled simultaneously on dev, they interact in ways none of the individual backtests account for. OBV_LOSS_EXIT + HOLD_CAP_MIN + FLAT_EXIT triple-interaction has no combined backtest. **Recommendation:** Confirm exactly which flags are currently `true` in dev docker-compose (the `docker inspect` or `docker exec env` output would settle this). Ensure no more than 2 of the 4 new flags are simultaneously enabled during the 2026-04-22 mid-week review. If `RSI_PEAK_CONFIRM_RTH` is also true, disable it first (see P1 above) before interpreting any combined-flag A/B data. --- ## OK (checked, working or recently fixed) - **RVOL gate logic (code):** Floor `rv < 0.8` correctly skips non-rsi_extreme; ceiling `rv_10m > 5.0` correctly skips rsi_extreme; fail-closed on `rv is None` for all triggers. `bot.py:3883–3898`. Correct. - **OBV_BE_STOP entry_time parse:** `bot.py:2897–2903` — `fromisoformat` fix confirmed in code; matches strategy_decisions.md "Fixed in commit 782e3b6" note. Correct. - **Time gate implementation (code):** `bot.py:3578–3595` correctly implements overnight gap, opening-30-min, close-hour, and off-hours blocks. Matches `strategy_decisions.md:2026-04-14` gate spec. (CLAUDE.md table is stale — already filed as P1 in weekly audit 2026-04-19.) - **Size caps (code):** Late session `_late_session_scale = 0.1` (15:00–16:00 ET) and off-hours `0.25` (outside 09:30–16:00 ET) match CLAUDE.md documented caps. `bot.py:3724–3728`. Correct. - **OBV_LOSS_EXIT + HOLD_CAP_MIN logic:** New exit flags gated on correct setup types (MEAN_REVERT/EXT_FADE only); HOLD_CAP exempt from trend setups; OBV_LOSS_EXIT properly nested inside OBV_BE_STOP path. Logic correct; no interaction bugs observed. - **FLAT_EXIT entry-sizing consistency:** Applied in both exit path (`bot.py:3336`) and entry-sizing (`bot.py:4334`) consistently; same guard conditions. Correct. - **Config fallback mismatches (`capital`, `daily_loss_limit`, `max_daily_trades`, `max_shares`, `max_concurrent_positions`, `atr_stop_multiplier`):** Already filed as P1 in weekly audit 2026-04-19. Not re-filed; still open. - **Symbol/cashtag drift in config.json (TSLA/META/PLTR vs KORU):** Already filed as P1 in weekly audit. Not re-filed; still open. - **`DATABASE_URL` env var:** Hard fail-fast at `core/database.py:25` — correct. - **`POLYGON_API_KEY` / `USE_POLYGON_DATA`:** Polygon gated correctly on `POLYGON_API_KEY` presence; Polygon data path gated on `USE_POLYGON_DATA=true`. No hardcoded keys. Clean. - **`GOLIVE_PEER_URL` default:** Falls back to hostname-sniff (`"dev." in host` → algo.sydnee.ai, `"algo." in host` → dev.sydnee.ai). Safe default; explicit env var takes precedence. Clean. - **Webhook secret:** `SYDNEE_WEBHOOK_SECRET` — `hmac.compare_digest`, fail-closed on empty expected. Clean. - **`rsi_upper`/`rsi_lower` in config (65/35):** These are divergence thresholds, distinct from the rsi_extreme entry thresholds (85/20 RTH, 85/15 off-hours). No cross-contamination. Clean. - **RSI asymmetry (ob=85 constant, os=20/15):** Documented asymmetry — "SELL stays at 85, blow-off top risk gated separately by RV." Off-hours ob=90 proposal is parked for post-freeze. Not a drift. Clean.