Sydnee WEEKLY (cross-cutting) audit — 2026-08-09 P0 findings: 0 P1 findings: 0 Risks: 0 - **Commits since last weekly (2026-08-02):** 48 total — all docs-only (7 daily audit files + 41 peak-monitor hourly logs). **Zero code changes for the 3rd consecutive week.** - **Files changed (code):** None — docs only - **Bot size:** bot.py 24,173 lines (+0); pages.py 13,447 lines; core/database.py 2,553 lines. CLAUDE.md still says "~10K lines" (stale since Jan 2026). | Category | Count | |---|---| | P0 | 0 | | P1 new (weekly cross-cutting) | 2 | | P1 carried (unfixed) | 12 | | Dead code (new) | 1 | | Dead code (carried) | 3 | | Security new | 3 (1 high + 1 medium + 1 config) | | Security carried | 1 cosmetic (API key default "8881") | | Dep hygiene | 1 (oracle requirements loose pins) | | Doc/arch drift (new) | 1 | | Doc/arch drift (carried) | 4 | | Perf | 0 new | **Pattern:** Three weeks of zero code commits while P1 backlog grows to 14 (12 carried + 2 new). The two new P1s are cross-cutting consistency issues uncovered by the weekly scope. Three security findings are also new this week — a hardcoded DB password in 6 committed scripts, hardcoded Azure IDs in a committed script, and a config/code sync gap in the RSI bias gate. No new runtime bugs introduced (zero code = zero regressions). --- Full report (dev branch): https://github.com/kanex1/sydnee.signals/blob/dev/docs/audit_2026-08-09_weekly.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) --- # Weekly Code Audit 2026-08-09 ## Summary - **Commits since last weekly (2026-08-02):** 48 total — all docs-only (7 daily audit files + 41 peak-monitor hourly logs). **Zero code changes for the 3rd consecutive week.** - **Files changed (code):** None — docs only - **Bot size:** bot.py 24,173 lines (+0); pages.py 13,447 lines; core/database.py 2,553 lines. CLAUDE.md still says "~10K lines" (stale since Jan 2026). | Category | Count | |---|---| | P0 | 0 | | P1 new (weekly cross-cutting) | 2 | | P1 carried (unfixed) | 12 | | Dead code (new) | 1 | | Dead code (carried) | 3 | | Security new | 3 (1 high + 1 medium + 1 config) | | Security carried | 1 cosmetic (API key default "8881") | | Dep hygiene | 1 (oracle requirements loose pins) | | Doc/arch drift (new) | 1 | | Doc/arch drift (carried) | 4 | | Perf | 0 new | **Pattern:** Three weeks of zero code commits while P1 backlog grows to 14 (12 carried + 2 new). The two new P1s are cross-cutting consistency issues uncovered by the weekly scope. Three security findings are also new this week — a hardcoded DB password in 6 committed scripts, hardcoded Azure IDs in a committed script, and a config/code sync gap in the RSI bias gate. No new runtime bugs introduced (zero code = zero regressions). --- ## New Findings --- ### [ARCH/CROSS-CUTTING] P1 (new): CLAUDE.md Architecture section describes neither the three live trading engines nor their 80+ env vars — all discovered implicitly by contributors reading 24K-line bot.py **Files:** `CLAUDE.md:5–9` (Architecture section); `bot.py:20476` (KCR engine comment), `bot.py:18390` (RSI_TICK section), `bot.py:21507` (TAPE section) **Evidence:** CLAUDE.md Architecture section (lines 5–9): ``` - **Bot**: Python trading bot (bot.py ~10K lines) using IBKR paper trading - **Dashboard**: Flask web app with HTML/JS (pages.py) - **Strategy**: RSI mean-reversion / trend following (strategy.py) - **Core modules**: /opt/trading/core/ (database, indicators, sentiment, executor, etc.) - **AI**: Uses Claude Opus for sentiment analysis, daily reviews, strategy signals ``` Reality as of today: | Engine | bot.py anchor comment | Env vars | Introduced | |---|---|---|---| | **KCR** (Keltner Channel + SPY regime) | `bot.py:20476` "built 2026-06-23" | 8 (`KCR_*`) | 2026-06-23 | | **RSI_TICK** (sub-second RSI curl detector) | `bot.py:18390` "Backtest 2026-04-29" | 13 (`RSI_TICK_*`, `WS_TICK_*`) | 2026-04-29 | | **TAPE** (order flow / L2 scanner) | `bot.py:21507` | 30+ (`TAPE_*`) | 2026-05-xx | Total env vars in bot.py: **238** (up from ~130 in the April-era CLAUDE.md). The three engines together account for ~5,000 lines (~20% of bot.py). `strategy.py` (115 lines) is the backtester strategy, not the live trading strategy — the live logic lives entirely in bot.py. Additionally: bot.py line count ("~10K lines") has been wrong since at least January 2026. Current: 24,173 lines. **Impact:** Every new Claude Code session (scheduled audits, ad-hoc sessions, on-call) starts with a materially wrong mental model. The Architecture section describes a bot that no longer exists. Any agent asked to "find the short entry logic" will search strategy.py before bot.py. The env var inventory is invisible: 238 env reads in bot.py with ~80 of them (`TAPE_*`, `KCR_*`, `RSI_TICK_*`) undocumented anywhere outside the source code. Contributors discovering these flags by reading 24K lines of bot.py is slow and error-prone. **Recommendation:** Update CLAUDE.md Architecture section (~30 lines): 1. Correct bot.py line count (24K, growing ~1K/month). 2. Add KCR, TAPE, and RSI_TICK engine bullets with entry-point line numbers and key env vars. 3. Note that `strategy.py` is the backtester's Strategy class, not the live trading engine. 4. Add a cross-reference to `strategy_decisions.md` for the env var changelog. This is documentation only — no code changes required. --- ### [DEAD CODE] P1 (new): `core/car_atm_monitor.py` hard-expiry date was 2026-04-30 — module has been a no-op for 3.5 months **Files:** `core/car_atm_monitor.py:61` (`WINDOW_END_PT`), `core/car_atm_monitor.py:158–161` (expiry check), `bot.py:23578–23590` (startup), `bot.py:16869–16884` (3 API endpoints) **Evidence:** `core/car_atm_monitor.py:61`: ```python WINDOW_END_PT = PT.localize(datetime(2026, 4, 30, 23, 59)) ``` `core/car_atm_monitor.py:158–161`: ```python if datetime.now(PT) >= WINDOW_END_PT: self._persist_state({"state": "expired", "expired_at": datetime.now(PT).isoformat()}) logger.info("CAR ATM monitor window expired") return # thread exits ``` Today is 2026-08-09 — 101 days past expiry. Every bot restart spins up the `CarAtmMonitor` thread (gated by `CAR_ATM_MONITOR=true`, off by default), which immediately hits the expiry check and terminates. When disabled (default), the three API endpoints (`/api/car-atm/state`, `/api/car-atm/dismiss`, `/api/car-atm/reset`) remain registered and return `{"ok": False, "error": "CAR ATM monitor not available"}`. Bot.py docstring at line 45: `# core.car_atm_monitor may not exist (module was added post-prod-sync).` — the conditional import remains live. **Impact:** Zero runtime risk (default-disabled, thread self-terminates when enabled). Pure dead weight: a 390-line module, a conditional import, three dead Flask endpoints, and a startup try/except block — all for a CAR-specific event monitor whose detection window closed three months ago. **Recommendation:** Remove `core/car_atm_monitor.py`, the `bot.py:45–49` conditional import, the `self.car_atm_monitor` attribute init, the `bot.py:23578–23590` startup block, the three `/api/car-atm/*` endpoints, and `_car_atm_on_detect` / `_car_atm_on_fire` callbacks. ~50 lines of bot.py, 390 lines of core/. Archive the module in git history if needed for reference. --- ## Additional New Findings (from cross-file security sweep) --- ### [SECURITY] HIGH (new): DB password "TradingDB2026" committed in plaintext as `os.environ.get()` default across 6 scripts **Files:** - `scripts/calibrate_stock.py:260` - `scripts/calibrate_spread.py:97` - `scripts/calibrate_obv_divergence.py:291` - `scripts/calibrate_tick_rv.py:90` - `scripts/backtest_rsi_exit_flow_gate.py:34` - `.claude/scripts/rvol_direction_analysis.py:23` **Evidence (representative):** ```python # scripts/calibrate_stock.py:260 db_url = os.environ.get("DATABASE_URL", "postgresql://trading_bot:TradingDB2026@trading-db:5432/trading_db") ``` ```python # .claude/scripts/rvol_direction_analysis.py:23 password=os.environ.get("DB_PASSWORD", "TradingDB2026"), ``` **Impact:** The password is embedded in git history across all clones. Even if the DB password is rotated, the old value persists permanently in the repository history and in any forks or backups. The database is exposed to the trading-db internal hostname (Docker network), reducing external attack surface — but any attacker with repo access can attempt direct DB connections from inside that network. Not flagged in any prior audit. **Recommendation:** Rotate the password immediately (it's in git history regardless). Remove the hardcoded defaults — scripts should require `DATABASE_URL` or fail explicitly (`os.environ["DATABASE_URL"]`), not fall back to a committed secret. Add `*.log`, `cookies.txt`, and a broader `DATABASE_URL` note to `.gitignore`. Consider a `git filter-repo` or BFG run to scrub history if the DB is externally reachable. --- ### [SECURITY] MEDIUM (new): Azure tenant ID and client ID hardcoded in `scripts/daily_report.py` **Files:** `scripts/daily_report.py:29–30` **Evidence:** ```python TENANT = os.environ.get("MS_TENANT_ID", "6952c239-4cb7-4127-889f-c75f1da90665") CID = os.environ.get("MS_CLIENT_ID", "f3e854dd-be2b-44fc-aaae-a979a5620a0f") ``` **Impact:** The client secret (`MS_CLIENT_SECRET`) defaults to `""` (correctly). Tenant + client IDs alone do not grant token access, but they are Azure-tenant identifiers that enable targeted authentication attempts against `https://login.microsoftonline.com/{TENANT}/oauth2/v2.0/token` (referenced at line 213). These are committed to git history. Not flagged in any prior audit. **Recommendation:** Remove the hardcoded defaults. Require env vars or fail with a clear message. If these IDs are not considered sensitive by Kelvin's Azure policy, add a comment explaining why — otherwise clean up the defaults. --- ### [CONFIG] MEDIUM (new): 15m RSI bias reduce gate uses hardcoded `65` / `35` literals — will not track `rsi_upper`/`rsi_lower` config.json changes **File:** `bot.py:6308` **Evidence:** ```python rsi15_high = (raw_sig == 1 and ss.last_15m_rsi >= 65) or (raw_sig == -1 and ss.last_15m_rsi <= 35) ``` `config.json` currently has `"rsi_upper": 65, "rsi_lower": 35` — matching today. But `self.rsi_upper` and `self.rsi_lower` are wired to config.json at `bot.py:769–770` and updated live by `_reload_config()` at `bot.py:2065–2066`. If `rsi_upper`/`rsi_lower` are changed in config.json (e.g., tuned per-symbol), the 15m bias reduce gate silently uses the old literals. No other gate in the bias section hardcodes these values. **Recommendation:** Replace `65` and `35` with `self.rsi_upper` and `self.rsi_lower` (2-character change per literal). This is 4 characters of code. --- ## Carried Findings (all unchanged from 2026-08-02 weekly — zero code commits) The following P1s are unchanged. Line numbers and evidence are identical to the 2026-08-02 weekly audit. Summarized here for visibility: ### [ARCH] P1 (carried 12 weeks): Oracle `classify_regime` and `bot.py:_classify_regime` diverged — stale "identical formula" comment **Files:** `oracle/service.py:100`, `oracle/config.py:34–35`, `bot.py:10001` Oracle dropped 240m weight (bot.py still has it at weight=5). Oracle added `REGIME_INTRADAY_WEIGHTS`; bot.py has none. Stale comment says "identical formula to bot.py:_classify_regime." Affects `EXTERNAL_ORACLE=true` regime gate. 12 weeks unresolved. ### [PERSISTENCE] P1 (carried 14 weeks): `risk.state.trade_count` and `risk.state.realized_pnl` not restored on restart **Files:** `core/risk.py:113,118`; `bot.py:23458–23461` Restart resets daily trade count and P&L to zero. 10-trade cap + $50K loss limit re-opens on any intraday restart. 4-line fix using `db.get_today_trades()` at startup. ### [PERSISTENCE] P1 (carried 4 weeks): `_ab_live_state` is memory-only — restart loses AB force-flat tracking **Files:** `bot.py:20237–20238`, `bot.py:20144` No Redis/DB backing. No Redis persistence was added this week (confirmed by zero code commits). Restart with `AB_EXECUTE=true` leaves open MES/MNQ position unmanaged. ### [PERSISTENCE] P1 (carried 4 weeks): AB bracket fills never written to DB **Files:** `bot.py:20109–20140` Zero DB writes when `AB_EXECUTE=true`. Fill prices, slippage, net P&L invisible in dashboard. ### [LOGIC] P1 (carried 9 weeks): `_generate_daily_summary()` reads in-memory `_build_performance()` — reports $0 on restart days **Files:** `bot.py:11681`, `bot.py:11728` Permanently writes wrong `daily_summaries` row on any restart day. 1-line fix: replace with `self.db.compute_performance(date_from=today_str)`. ### [LOGIC] P1 (carried 9 weeks): FLAT_EXIT parent `pnl=0` miscounted as loss in `_compute_period_stats()` **Files:** `bot.py:5718–5733`, `bot.py:1374`, `bot.py:8967` `t.shares` decremented to 0 before `_close_trade_in_store()` → pnl=0 → classified as loss. All FLAT_EXIT trades understate win rate and dilute the audit-scan's 20-trade window. ### [CROSS-CUTTING] P1 (carried 4 weeks): `_kcr_compute_regime()` comment "daily SPY closes" — actually queries 5m bars **Files:** `bot.py:20571` (comment), `bot.py:20577` (`timeframe = '5'`) ```python # Use bar_data table — daily SPY closes ← stale cur.execute("... WHERE symbol = 'SPY' AND timeframe = '5' ...") ← 5m bars ``` Misleads debugging of KCR vs BXt regime divergence (BXt uses Polygon daily via `_bxt_regime()`; KCR uses 5m `bar_data`). Both produce same label names but from different data.