TASK FOR THE AGENT: build a TradingView Pine Script STRATEGY to honestly verify our BTC trading tactic in the Strategy Tester. This must be a strategy(), NOT a plain indicator() -- so TradingView shows net profit/loss, number of trades, drawdown, win rate and profit factor. TOP RULE: do not invent or embellish results. If something about the tactic is missing for exact code, ASK clarifying questions FIRST, then write the code. This script will be checked independently (in TradingView AND in a separate Python backtester), so the rules must match bit for bit. ================================================================ 1. HARD TECHNICAL REQUIREMENTS ================================================================ 1.1. Pine Script v5, use strategy(...), not indicator(). 1.2. NO repaint / NO look-ahead into the future: - every request.security() must use lookahead=barmerge.lookahead_off; - signals are computed on the CLOSED bar (unless the method is explicitly entry-on-touch); - pivots / swing high / swing low / CHoCH / BOS / zones must respect confirmation delay (do not use future bars as if they were known at entry time); - barmerge.lookahead_on and calc_on_every_tick are forbidden for the test; - never take today's zone/level and stretch it back over the past. 1.3. All key values must be input.* (position size, stop, take, max hold, commission, slippage, filter timeframes, entry mode, exit mode, indicator parameters). 1.4. alertcondition for entry and exit. 1.5. Plot on chart: any zones/levels used, entry points, stop and take levels, the current MTF trend/filter. ================================================================ 2. FIRST -- RULES IN PLAIN WORDS (MANDATORY, BEFORE CODE) ================================================================ Describe the tactic precisely and mechanically enough that ANOTHER engine can reproduce it (a human will re-check it in a separate Python backtester and compare it to TradingView). For each item give the exact formula and which bar it is computed on: - when LONG is allowed, when SHORT is allowed (exact filter conditions); - what exactly the entry trigger is (on close? on touching a level? on confirmation?); - where the stop is (exact distance/level formula); - where the take profit is (exact formula); - time-based exit (how many bars); - trend-flip exit (by which exact signal); - is there partial profit-taking; - is there a ban on re-entry until price returns to equilibrium / the middle zone. No vague "enter on the setup" -- only unambiguous rules. ================================================================ 3. IF THE TACTIC USES THESE COMPONENTS -- DEFAULTS ================================================================ 3.1. MTF SuperTrend: ATR Period and Factor as inputs (default ATR 10, Factor 3.0); default timeframes 1H/2H/4H/D1, optional W1 as a toggleable filter; compute via request.security(..., lookahead=barmerge.lookahead_off). 3.2. Premium/Discount/Equilibrium: pivot/swing length as input (default 14); zones are recomputed historically honestly, only from data known at that moment; add a comment that this approximates LuxAlgo zones if the exact code is unavailable. 3.3. Entry mode (input): Close in zone / Touch zone / Liquidity sweep / CHoCH-BOS confirmation. If a mode cannot be done honestly without repaint -- do NOT fake it, explain instead. 3.4. Exit mode (input): Fixed SL/TP / Middle-equilibrium / Opposite zone / Trend flip / Max hold. ================================================================ 4. MONEY AND RISK (CRITICAL FOR AN HONEST TEST) ================================================================ 4.1. FIXED position size (e.g. qty in BTC). Do NOT use percent-of-equity / reinvesting -- compounding inflates the curve and distorts the evaluation. 4.2. Always include commission (default 0.04%) and slippage -- without them the test is dishonest. 4.3. Pessimistic intrabar fill: if a single bar touches BOTH the stop AND the take, assume the STOP was hit (so the result is not embellished). 4.4. process_orders_on_close=false (fills on the next bar, realistic). ================================================================ 5. TEST DATA AND ROBUSTNESS ================================================================ 5.1. State the SPECIFIC exchange+symbol for the test (e.g. BINANCE:BTCUSDT.P), main TF 1H. 5.2. The strategy must hold up when the exchange is switched (Binance vs Bybit, same period). If it is positive on one exchange and negative on the other -- it is NOT a robust edge; say so plainly. 5.3. Report results NOT as one nice slice, but over all available history AND broken down BY YEAR. If possible, split in-sample (tuning) and out-of-sample (verification) and show both. 5.4. If there are fewer than 30 trades -- flag that the result is statistically insignificant. ================================================================ 6. WHAT TO RETURN (ANSWER FORMAT) ================================================================ 1) "Rules as I understood them" -- section 2 above, mechanically exact. 2) "What needs clarification" -- questions if anything is ambiguous (better to ask than invent). 3) "Pine Script strategy" -- full code in ONE block, compiles in Pine Editor. 4) "How to check in TradingView" -- how to paste it, settings for the first test, which numbers to read: Net Profit, Max Drawdown, Total Trades, Win Rate, Profit Factor, List of Trades. 5) "Results I actually got" -- honest test numbers + breakdown by year (or state plainly: "I did not run it, I am not inventing numbers"). 6) "Test limitations" and "Signs of a dishonest test": profit too large, lookahead_on, signals on future pivots, result changes after refreshing the chart, fewer than 30 trades, percent-of-equity instead of fixed lot, one cherry-picked slice instead of full history. ================================================================ 7. SELF-CHECK BEFORE DELIVERY ================================================================ - The code compiles in Pine Editor v5. - No secrets/keys/webhook secret/passwords, and NO real exchange orders -- TradingView Strategy Tester only. - If the rules are ambiguous -- ask first, do not invent.