# Optimization Roadmap & "Shower Thoughts"

**Created:** 2026-03-04
**Status:** Draft / Planning

This document captures strategic questions and actionable tasks regarding the auto-optimization workflow (`auto_optimize_loop.py` and `optimize_strategy.py`).

## 1. LLM Usage & Quotas

### Questions
*   **What is being sent?** The script sends the current parameter JSON, the "Best Result" metrics (Sharpe, Trades, etc.), and a summary history of previous iterations.
*   **Is it heavy lifting?** No. The LLM is acting as a "heuristic guide" to adjust search boundaries. The heavy lifting (math) is done by the GPU.
*   **Local vs. Cloud?** Cloud (Gemini) is preferred for its superior instruction following (JSON formatting). Local (Llama 3) often fails to produce valid JSON or hallucinates syntax errors, as seen in logs.
*   **Why Quota Errors?**
    *   **Gemini Code Assist (VS Code):** Likely uses a separate, enterprise, or "Trusted Tester" quota pool.
    *   **Auto-Optimizer:** Uses your personal API key (`GOOGLE_API_KEY`). The "Resource Exhausted" error typically refers to the **Requests Per Minute (RPM)** or **Tokens Per Minute (TPM)** limit of the free tier.
    *   **Action:** If errors persist, consider a separate API key or implementing a "wait and retry" logic in the script.

## 2. Parameter Step Values & "Round Numbers"

### Problem
Current step values (e.g., `0.5`, `10.0`) are arbitrary artifacts from the Pine Script UI. They may be too coarse, causing the optimizer to miss optimal values between the "round numbers."

### Action Items
*   **[Immediate] Prompt Engineering:** Update `auto_optimize_loop.py` to instruct the AI to calculate step sizes relative to the range magnitude (e.g., `step = (stop - start) / 20`) rather than using arbitrary integers.
*   **[Future] Dynamic Grid Density:** Modify `optimize_strategy.py` to accept `num_steps` instead of `step_size`, allowing `np.linspace` to automatically determine density.

## 3. Iteration Counts & Time Estimation

### Clarification
*   **Current Count:** We are running **10,000,000 (10 Million)** combinations per iteration.
*   **Benchmarks:**
    *   **GPU:** ~1.5 seconds per 1 Million combos (15s for 10M).
    *   **CPU:** ~4 hours per 1 Million combos.

### Action Items
*   **[Done]** Updated `auto_optimize_loop.py` to reflect the 10M count and accurate GPU time estimates.
*   **[Future]** Implement a "Micro-Benchmark" at startup: Run 10k combos, measure time, and extrapolate the total ETA dynamically to account for different hardware.

## 4. Overfitting & Generalization

### Problem
Running the optimization loop repeatedly on a single dataset (e.g., BTC 1D) risks **overfitting** or "curve fitting." The resulting parameters may be perfectly tuned to historical data but fail on live or different data.

### Multi-Stage Strategy to Ensure Robustness

To combat this, we will adopt a multi-stage approach. The goal is not just to find the best parameters, but to find **robust** parameters.

1.  **Stage 1: Parameter Discovery (Current Loop)**
    *   **Goal:** Efficiently search the vast parameter space to find high-potential regions.
    *   **Process:** This is the `auto_optimize_loop.py` we are using now. It "hill-climbs" on a single, primary dataset (e.g., BTC 1D) to find a set of parameters that performs very well on that specific data.
    *   **Outcome:** A `optimization_winner_...csv` file containing a locally-optimal parameter set.

2.  **Stage 2: Robustness Validation**
    *   **Goal:** Test the "winner" from Stage 1 against a diverse range of data to see if its performance holds up. A truly robust strategy should be profitable across different assets and timeframes.
    *   **Process:** A new script, `tools/validate_robustness.py`, will be created. It will take the winner parameters and run backtests against a folder of validation data (e.g., `data/validation/ETH-1D.csv`, `data/validation/BTC-4H.csv`, `data/validation/SOL-1D.csv`).
    *   **Outcome:** A "Robustness Score" report, showing the Sharpe Ratio, P&L, and drawdown for each validation dataset. This will tell us if the strategy is truly general-purpose or just a one-trick pony.

3.  **Stage 3: Ensemble & Specialization (Future)**
    *   **Goal:** If Stage 2 reveals that one set of parameters is not universally optimal, we can create specialized parameter sets.
    *   **Process:** We might run the Stage 1 loop on different categories of data (e.g., once for high-volatility assets, once for low-volatility) to find "specialist" parameter sets.
    *   **Outcome:** A collection of vetted parameter presets (e.g., `params_btc_1d.json`, `params_eth_4h.json`) that can be used for more targeted trading.

This structured approach ensures we use the speed of the optimizer to find promising candidates, but then apply rigorous validation to avoid the common pitfall of overfitting.

## 5. TradingView Synchronization

### Problem
Manually copying dozens of parameters from JSON/CSV to TradingView is tedious and error-prone.

### Action Items
*   **[High Priority] Parameter Exporter:** Create a tool (`tools/export_params_to_tv.py`) that reads `optimization_winner_*.csv` and generates a valid Pine Script text block.
    *   *Format:* `i_param_name = input.float(1.234, ...)`
    *   *Usage:* Copy-paste the block into the Pine Editor to update defaults instantly.