Sydnee WEEKLY (cross-cutting) audit — 2026-06-07 P0 findings: 0 P1 findings: 0 Risks: 0 - **Commits since last weekly (2026-05-31):** 17 feature/fix commits (excl. peak-monitor logs and daily-audit docs) - **Files changed:** `bot.py`, `pages.py`, `core/database.py`, `core/risk.py` - **Major new work this week:** TV-BXt scale-in redesign (single-trade-record, 2026-06-04), `TV_BXT_RTH_ONLY` pre-market relaxation (04:00-16:00 ET), `DISABLE_DAILY_LOSS_LIMIT` risk gate for dev measurement, flow-confirm cap raised 5→10 attempts, tape-scanner 4/4-only filter, scalp exit-research horizon fields (MFE/MAE/flow/score at 30s/60s/120s/300s) | Category | Count | |---|---| | P1 carried | 3 | | P1 new | 1 | | P2 carried | 4 | | P2 new | 3 | | Dead code | 1 | | **Fixed this week** | 1 partial (`"8881"` — 3 of 9 sites migrated to `window.API_KEY`) | --- Full report (dev branch): https://github.com/kanex1/sydnee.signals/blob/dev/docs/audit_2026-06-07_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-06-07 ## Summary - **Commits since last weekly (2026-05-31):** 17 feature/fix commits (excl. peak-monitor logs and daily-audit docs) - **Files changed:** `bot.py`, `pages.py`, `core/database.py`, `core/risk.py` - **Major new work this week:** TV-BXt scale-in redesign (single-trade-record, 2026-06-04), `TV_BXT_RTH_ONLY` pre-market relaxation (04:00-16:00 ET), `DISABLE_DAILY_LOSS_LIMIT` risk gate for dev measurement, flow-confirm cap raised 5→10 attempts, tape-scanner 4/4-only filter, scalp exit-research horizon fields (MFE/MAE/flow/score at 30s/60s/120s/300s) | Category | Count | |---|---| | P1 carried | 3 | | P1 new | 1 | | P2 carried | 4 | | P2 new | 3 | | Dead code | 1 | | **Fixed this week** | 1 partial (`"8881"` — 3 of 9 sites migrated to `window.API_KEY`) | --- ## Fixed Since Last Weekly (2026-05-31) **Partial fix:** `pages.py` hardcoded `"8881"` — 3 of 9 sites now use `window.API_KEY||"8881"` (lines 1627, 5800, 8728). 5 sites still hardcode the literal (see P1 below). --- ## Findings --- ### [SECURITY] P1 (carried 6 weeks — 2026-05-03 → 2026-06-07): Hardcoded `"8881"` API key in client-side JavaScript — 5 sites remain **Files:** `pages.py:7035`, `pages.py:7279`, `pages.py:7843`, `pages.py:8130`, `pages.py:8135`, `pages.py:8138` **Evidence:** ```js // pages.py:7035 — stock add fetch('/api/stocks/add',{...,'X-API-Key':'8881'}...) // pages.py:7279 — screener scan apiPost("/api/screener/run",{...,password:"8881"}) // pages.py:7843 — cancel order fetch("/api/positions/cancel",{...,"X-API-Key":"8881"}...) // pages.py:8130, 8135, 8138 — QA approve/reject/defer apiPost('/api/qa/suggestion/'+id,{...,password:'8881'}) ``` Server default: `API_KEY = os.environ.get("API_KEY", "8881")` (bot.py:11140). Progress: lines 1627, 5800, 8728 now use `window.API_KEY||"8881"` (OBV-trail, tape-scanner fetch), showing the `window.API_KEY` injection path works — it just hasn't been applied to the 5 remaining sites. **Impact:** Credential visible in every page source load; rotation breaks these 5 write features silently with 401. **Recommendation:** Apply the same `window.API_KEY||"8881"` pattern (or the Jinja2 `{{ api_key }}` approach from the last weekly) to the 5 remaining hardcoded sites. The `window.API_KEY` approach already works — replicate it. ~10 min. --- ### [SCHEMA] P1 (carried 6 weeks — 2026-05-03 → 2026-06-07): 5 tables + 18 columns missing from `core/schema.sql` **Files:** `core/database.py:1869`, `2062`, `2074`, `2174`, `2195`; `core/database.py:310-356`; `core/schema.sql` **Evidence — missing tables (INSERT/CREATE but no schema.sql entry):** ``` change_requests (database.py:1869) qa_reports (database.py:2062) qa_suggestions (database.py:2074) screener_results (database.py:2174) screener_runs (database.py:2195) scalp_signal_log (database.py:310) ``` **Evidence — missing ALTER TABLE columns on `trades`:** ```python # database.py:230-231 (carried) tick_peak_signed_vol BIGINT DEFAULT 0 fri_ah_close_queued BOOLEAN DEFAULT FALSE ``` **Evidence — new this week: 16 ALTER TABLE columns on `scalp_signal_log`:** ```python # database.py:339-356 price_300s, ret_300s, flow_30s/60s/120s/300s, score_30s/60s/120s/300s, mfe_30s/60s/120s/300s, mae_30s/60s/120s/300s ``` `grep "scalp_signal_log\|change_requests\|qa_report\|screener_result\|screener_run\|tick_peak_signed_vol\|fri_ah_close" core/schema.sql` → zero results. **Impact:** Fresh DB provision produces a silently broken schema. The `IF NOT EXISTS` guards keep running instances healthy, but any new staging stand-up or disaster-recovery event starts with missing tables and columns; `_safe()` wrappers swallow the subsequent errors. **Recommendation:** Add `CREATE TABLE IF NOT EXISTS` blocks for all 6 tables and the 18 missing columns to `schema.sql`. Establish the convention: any `ALTER TABLE ADD COLUMN IF NOT EXISTS` in `database.py` also lands in `schema.sql` in the same commit. --- ### [CONFIG] P1 (carried 3 weeks — 2026-05-17 → 2026-06-07): `TV_BXT_TRAIL_AGAINST` default drift between live path and replay endpoint **Files:** `bot.py:3774`, `bot.py:14344` **Evidence:** ```python # bot.py:3774 — _obv_trail_stop_hit (LIVE TRADING): agnst = float(os.environ.get("TV_BXT_TRAIL_AGAINST", "1.0")) # bot.py:14344 — api_trade_obv_trail (HISTORY REPLAY endpoint): agnst = float(os.environ.get("TV_BXT_TRAIL_AGAINST", "1.5")) ``` Three weeks unfixed. When `TV_BXT_TRAIL_AGAINST` is unset, the dashboard's OBV-trail history panel reconstructs stop sequences using a 1.5× ATR against-stop, while the live engine ran a 1.0× against-stop. Every closed-trade stop timeline shown in the trade card is wrong on the default path. **Impact:** Post-trade stop analysis is systematically misleading. "The stop was too tight" conclusions drawn from the history panel may be wrong by 50% of the against-trail width. **Recommendation:** Change `bot.py:14344` default from `"1.5"` to `"1.0"`. One-line fix. --- ### [DOC] P1 (new): `DISABLE_DAILY_LOSS_LIMIT` absent from CLAUDE.md; not flagged as a production safety gate **Files:** `core/risk.py:106-116`; `CLAUDE.md` **Evidence:** ```python # core/risk.py:112 — wraps the daily-loss circuit breaker: if os.environ.get("DISABLE_DAILY_LOSS_LIMIT", "").lower() not in ("1", "true", "yes"): if self.state.realized_pnl <= -self.cfg.daily_loss_limit: return False, ... ``` `grep "DISABLE_DAILY_LOSS_LIMIT" CLAUDE.md` → zero results. The strategy_decisions.md entry for this flag explicitly states: **"Hard re-enable the gate before any real-money promotion — this flag is NOT for prod."** That critical warning exists nowhere in CLAUDE.md. On dev paper the daily-loss cap is ~$5K (5% of $100K NLV). With `DISABLE_DAILY_LOSS_LIMIT=true` set in the dev docker-compose, any AI session or operator who deploys to prod without checking the compose file will run prod with no daily drawdown limit. **Impact:** If the dev docker-compose environment block were copy-pasted to prod (or the flag were promoted with the service), the $5K daily-loss circuit breaker would be silently disabled on real money. The CLAUDE.md is the first reference an operator or AI session reads; the warning must live there. **Recommendation:** Add to CLAUDE.md's env-var reference section: ``` | DISABLE_DAILY_LOSS_LIMIT | "" (gate ON) | ⚠️ DEV ONLY — removes 5% NLV daily-loss circuit breaker. MUST be unset before real-money promotion. | ``` --- ### [SECURITY] P2 (carried 3 weeks — 2026-05-17 → 2026-06-07): XFF bypass in `_tv_webhook_client_ip` **Files:** `bot.py:3616-3623` **Evidence:** ```python def _tv_webhook_client_ip(self, req) -> str: """... X-Forwarded-For contains the original client IP (first entry).""" xff = req.headers.get("X-Forwarded-For", "") if xff: return xff.split(",")[0].strip() # ← takes attacker-controlled first entry return req.remote_addr or "" ``` `ProxyFix(x_for=1)` at bot.py:11389 already sets `request.remote_addr` to the real client IP by consuming the rightmost XFF entry added by Traefik. The manual split takes the leftmost entry — an attacker can prepend any TV relay IP to bypass the allowlist check (`X-Forwarded-For: 52.89.214.238`; Traefik appends the real attacker IP). The docstring still says "first entry" which is incorrect in a ProxyFix context. **Impact:** Defense-in-depth bypass only. Secret check (`_secrets.compare_digest`) still runs first. Spoofing only helps if the secret is also compromised. **Recommendation:** Replace lines 3620-3622 with `return req.remote_addr or ""`. ProxyFix has done the right thing already. Update the docstring. One-line fix. --- ### [DEP] P2 (carried ~3 weeks — 2026-05-17 → 2026-06-07): `requirements-oracle.txt` uses unpinned version ranges **Files:** `requirements-oracle.txt` **Evidence:** ``` numpy>=1.24 pandas>=2.0 psycopg2-binary>=2.9 redis>=5.0 requests>=2.31 ``` All other requirements files (`requirements.txt`, `requirements-ibkr_ws.txt`, `requirements-poly_ws.txt`) use `==` pins. The oracle sidecar is the only exception. A `pip install` today could pull `pandas 3.1` or `numpy 3.x` with breaking API changes; the oracle image build is non-deterministic. **Impact:** Reproducibility gap. The oracle container image built today vs 6 months from now may differ; silent breakage from upstream API changes. **Recommendation:** Pin all oracle deps to the currently-resolved versions. Run `pip install -r requirements-oracle.txt && pip freeze | grep -E "numpy|pandas|psycopg2|redis|requests"` on the current dev environment and hard-pin the output. ~5 min. --- ### [DOC] P2 (carried 3 weeks — 2026-05-17 → 2026-06-07): CLAUDE.md Architecture section stale **Files:** `CLAUDE.md:6-11`, `CLAUDE.md:75-80` **Evidence (same 3 sub-issues from 2026-05-31 weekly):** - `CLAUDE.md:6`: "bot.py ~10K lines" — actual is **18,489 lines** (1.8× wrong). `pages.py` at 10,781 lines not mentioned. - `CLAUDE.md:75-80`: "Polygon data layer" listed under Dev-Only Features with sub-note "Production: IBKR for everything (no env var set)" — directly contradicts the Architecture section which states `USE_POLYGON_DATA=true on both dev and prod docker-compose`. - Oracle sidecar (`oracle/service.py`), ibkr_ws sidecar (`ibkr_ws/service.py`), poly_ws sidecar (`poly_ws/service.py`), 4-way BXt model selector, tape-scanner page (`/scanner`), and Phase-0 scalp logger remain absent from the Architecture section. **Impact:** The Polygon contradiction misleads any operator or AI session reading CLAUDE.md about the production data source. The stale line count underestimates bot.py's complexity by half. **Recommendation (15 min):** 1. `CLAUDE.md:6`: update to "bot.py ~18K lines, pages.py ~11K lines". 2. Remove the Polygon "Dev-Only" bullet (it's prod-deployed per the Architecture section). 3. Add one sentence: "Sidecars: oracle (regime), poly_ws (Polygon WS), ibkr_ws (IBKR WS) — each with its own Dockerfile and requirements file." --- ### [DOC] P2 (carried 3 weeks — 2026-05-17 → 2026-06-07): Friday EOD entry cutoff absent from CLAUDE.md Entry Time Blockers table **Files:** `CLAUDE.md:40-45`, `bot.py:4552-4558` **Evidence:** ```python # bot.py:4552-4558: if now_et.weekday() == 4 and t_min >= 15 * 60: self._log_activity(sym, "FRI CUTOFF: no new entries Friday after 12:00 PM PT", "block") return ``` The CLAUDE.md "Net effect" summary still says "RSI extreme runs 24×5 except..." implying it runs Friday PM — it doesn't; the 12:00 PM PT Friday cutoff blocks all triggers. **Recommendation:** Add row to Entry Time Blockers table: ``` | Fri 12:00 PT (15:00 ET) onward | all entries blocked (weekend gap risk) | ALL triggers | ``` Update "Net effect" line to note the Friday cutoff. --- ### [DOC] P2 (new): `TV_BXT_RTH_ONLY` flag name no longer describes its behavior **Files:** `bot.py:4047-4065`; `docs/strategy_decisions.md` **Evidence:** ```python # bot.py:4047-4048 (comment explicitly acknowledges the name is wrong): # TV_BXT_RTH_ONLY=true (dev opt-in, kept name for compat): block NEW # entries outside the active session — pre-market + RTH = 04:00-16:00 ET ``` Commit `9603296` added `TV_BXT_RTH_ONLY` to gate entries to 09:30-16:00 ET (true RTH). Commit `82c80de` relaxed it to allow pre-market (04:00-16:00 ET). The flag name was kept "for compat" but now actively misleads: an operator reading `TV_BXT_RTH_ONLY=true` in a docker-compose would expect post-market entries to be blocked AND pre-market entries to be blocked — but pre-market entries (04:00-09:30 ET) are allowed when the flag is set. The strategy_decisions.md entry for this flag (2026-06-01) still describes it as "gate entries to 09:30-16:00 ET" which is no longer accurate. **Impact:** Doc/name mismatch. An operator reviewing the compose file cannot determine the actual entry window from the flag name alone. **Recommendation:** Either rename to `TV_BXT_SESSION_ONLY` (reflects the 04:00-16:00 ET session gate) with a one-time search-replace across bot.py + docker-com