# Backlog Tracked feature ideas and known issues. Items are not prioritized — evaluate before starting. --- ## OOS Results Accumulation for IS→OOS Correlation Analysis **Problem**: We have a top-N OOS table but no persistent record across runs. To know which IS metrics genuinely predict OOS performance for this strategy, we need 50–100 (params, IS metrics, OOS P&L) data points across multiple optimization runs and combos. **Proposed implementation**: After each `auto_optimize_loop.py` run, append the top-N results (with OOS P&L and OOS trades computed) to a persistent CSV or separate DB table: `results/oos_results.csv` with columns `(run_date, asset, tf, composite, calmar, sortino, pnl, dd, trades, oos_pnl, oos_trades)`. Once 50+ rows accumulate, regress OOS P&L on IS metrics to find real predictors — then consider adjusting the composite formula based on actual evidence rather than theory. **When to implement**: After several multi-combo optimization cycles have run. No value in building the accumulation machinery before there's meaningful data to accumulate. --- ## Composite Metric: IS P&L Cap on Geo Factor (deferred) **Context**: The P&L floor (1,000%) and geometric composite (`sqrt(Calmar × Sortino) × ln(1 + P&L/1000)`) were already implemented. This item is about additionally capping the geo factor so that extreme IS P&L (e.g., 163,801%) doesn't disproportionately reward a result over one with, say, 50,000%. **Hypothesis**: Very high IS P&L may correlate with strategies that captured one specific bull run and don't generalise. Cap the geo bonus at e.g. 50,000%: `min(ln(1 + P&L/1000), ln(51))`. **When to revisit**: Once the OOS results accumulation table (see above) has 50+ rows. If high IS P&L shows negative correlation with OOS P&L in that data, implement the cap. If no correlation, skip — the cap is arbitrary without evidence. --- ## Top-N DB Viewer **Problem**: No easy way to sanity-check the distribution of results in the sweep DB for a given asset/TF. Currently only the single winner is surfaced. **Proposed fix**: Add `--top N` flag to `mine_sweep_db.py` to print the top N results from the DB for a given asset/TF ranked by Composite, showing P&L, DD, Calmar, Trades, Composite columns in a table. --- ## Pre-Replace Winner Guard **Problem**: Each optimization run can silently replace a winner CSV with a marginally higher Composite but much worse P&L or Calmar. No alert is generated. **Proposed fix**: In `auto_optimize_loop.py` winner-save logic, compare new result vs. existing winner CSV. Warn (print + ntfy) if new Composite is <95% of existing, or new P&L is <50% of existing. Block the replacement unless forced (e.g., `--force-replace` flag or `--hours` > some threshold). --- ## Pine Preset Auto-Detection Bug **Problem**: When switching TF in TradingView, the preset auto-detection occasionally doesn't apply the new preset on the first bar after the switch. The blank `i_preset_override` input is supposed to trigger auto-detection, but there is a timing issue in Pine's input system. **Proposed investigation**: Check whether using `request.security` for `syminfo.ticker` / `timeframe.period` is causing the delay, and whether re-ordering the preset lookup to use `var` persistence avoids the miss. **Workaround**: Manually set `i_preset_override` to the desired preset key, then blank it back. --- ## Wire `i_mvrv_suppress_bear` into Python Optimizer **Problem**: `i_mvrv_suppress_bear` (Pine line 1419) blocks long entries when MVRV z-score < bear threshold, but it only exists in Pine — the Python backtest ignores it and the optimizer never searches over it. **Required changes**: 1. Confirm `mvrv_regime` column is present in all 20 data CSVs (or add it to the Pine export if missing). 2. In `strategy_activation_scores.py`, read `params.get('i_mvrv_suppress_bear', False)` and apply as a boolean gate on entries alongside the existing `regime_window` check. 3. Add `"i_mvrv_suppress_bear": {"values": [false, true]}` to all 20 params JSON files (via `sync_params.py` after updating `config.py` or directly). 4. Add the column to `auto_optimize_loop.py`'s DB schema and non-weight params set (similar to `i_regime_window`). 5. Add to `generate_pine_presets.py`'s `_BOOL_PARAMS` set so it renders correctly in Pine presets. **When to implement**: When MVRV bear suppression is a real candidate for improving OOS performance — i.e., after enough OOS data accumulates to show bear-regime entries are hurting returns. --- ## Regime-Specific Weights **Problem**: Current strategy uses the same weights in all MVRV regimes (bull/bear/sideways). Signals that work well in bull markets (e.g., momentum) may be counter-productive in bear markets. **Context**: `--regime bull/bear/sideways` flag exists for running separate optimizations per regime and already provides the main benefit (understanding which signals matter in each regime). The Pine strategy has `i_regime_entry_min_score` and `i_regime_window` for regime-gated entry. **Why this is probably not worth building:** - Adds ~3× the parameter space in Pine (separate weight sets per regime) - The interaction between regime-gated entry filter and per-regime weights is complex and hard to debug - Optuna importance analysis (e.g., `i_w_m2_div_osc` is #1 across all regimes) suggests some signals are universally important — per-regime weights may just be overfitting - The existing `--regime` flag lets you explore this question empirically without any code changes: run `--regime bull`, `--regime bear`, `--regime sideways` separately on the same combo and compare resulting weight sets **If ever revisited**: evaluate only after 20-combo optimization is saturated and per-regime importance analysis shows large, consistent divergence in weight signs across regimes. --- ## Optuna Importance Analysis Threshold (Minor) **Note**: The "≥30 trials" message from `optimize_strategy.py` is about the post-run Optuna importance analysis, NOT the biased sampling. Biased sampling uses the DB directly in `auto_optimize_loop.py` before launching the subprocess. This is documented but worth keeping visible. **Optional improvement**: Lower the importance analysis threshold to 15–20 rows, or make it optional/logged-only rather than a warning. Currently it's just informational.