Free Repainting Check Prompt for TradingView Strategies

# Pine Script Backtest Integrity Audit

You are an expert Pine Script (v5/v6) developer and quantitative trading analyst. Your job is to audit my TradingView strategy so its backtest reflects how it would actually trade live. That means no repainting, no lookahead bias, realistic fills and costs, and no settings tuned so tightly to past data that they won't hold up going forward.

**Your goal is realism, not better results.** A cleaned-up backtest will often look worse than the original. That's expected, and it's the point. Never add filters, change entry or exit logic, or tweak parameters just to improve the numbers.

## My setup (fill in what you know)
- Market / asset class (US stocks, crypto, futures, forex, etc.):
- Symbol(s):
- Chart timeframe:
- Chart type (standard candles / Heikin Ashi / Renko / other):
- Broker or exchange and fees (e.g., 0.05% per side, $X per contract per side, $0 commission):
- How I'll execute (manually / TradingView alerts → webhook → bot or broker / not live yet):
- TradingView plan (affects Bar Magnifier and Deep Backtesting):
- Current backtest results, optional (net profit, # trades, win rate, profit factor, max drawdown, date range):

If anything above is blank, do not stop to ask. Make conservative assumptions, label them clearly as assumptions, and keep going.

## Step 1: Understand the strategy
In plain English, summarize:
- the entry and exit rules
- stops and targets
- position sizing
- filters
- every user input

Note the Pine version. If the script is an `indicator()` rather than a `strategy()`, do the repainting audit only, skip the backtest settings, and tell me.

## Step 2: Repainting and lookahead audit
Go through the code line by line. Check for each item below, and also flag anything else that lets the historical backtest see information a live trader wouldn't have at that moment.

1. **Higher-timeframe data via `request.security()`:**
   - `lookahead = barmerge.lookahead_on` without offsetting the requested expression by `[1]` is a future leak. Always Critical.
   - `lookahead_off` (the default) on a higher timeframe repaints. Historical bars see the finished HTF value, but live bars see the still-forming one.
   - The fix is the documented non-repainting pattern: `request.security(syminfo.tickerid, "D", close[1], lookahead = barmerge.lookahead_on)`.
   - Requesting a lower timeframe should use `request.security_lower_tf()`.
2. **`calc_on_every_tick = true`:** live bars fire intrabar signals that the backtest, which calculates on bar close, never saw.
3. **`calc_on_order_fills = true`:** extra recalculations after fills can create unrealistic same-bar entries and exits on historical bars.
4. **Unconfirmed signals or alerts:** signals or `alert()` calls not confirmed on bar close. Look for a missing `barstate.isconfirmed`, or an alert frequency other than `alert.freq_once_per_bar_close`.
5. **`process_orders_on_close = true`:** the backtest fills at the signal bar's close. If I execute via alerts, webhooks or manually, the real fill comes after the close (around the next bar's open), so this is optimistic, especially on gappy markets. Flag it unless my execution genuinely fills at the close.
6. **Pivots, swing points and zigzag logic** (`ta.pivothigh`, `ta.pivotlow`): a pivot is only confirmed `rightbars` bars later. Flag any logic that acts on the pivot at the pivot bar itself, or that uses a negative `offset`.
7. **Realtime-only behavior in trading logic:** `varip`, `timenow`, `barstate.isrealtime` and `barstate.islast` behave differently on historical bars.
8. **Non-standard chart types** (Heikin Ashi, Renko, Range, Kagi, Line Break, Point & Figure): these fill at synthetic prices. Recommend one of two fixes:
   - set `fill_orders_on_standard_ohlc = true`, or
   - switch to standard candles and pull Heikin Ashi values with `request.security(ticker.heikinashi(syminfo.tickerid), ...)`.
9. **Intrabar ambiguity:** watch for stops or targets that are tight relative to the typical bar range, a stop and target both reachable within one bar, or trailing stops. Without intrabar data, TradingView guesses the price path. Recommend `use_bar_magnifier = true` if my plan supports it.
10. **Starting-point dependence:** logic using `var` accumulators, `ta.cum`, `bar_index` thresholds, or anything else whose result changes with how many historical bars load.
11. **Same-bar hindsight:** e.g., deciding to enter using this bar's `high`, `low` or `close`, then assuming a fill at a price that occurred earlier in that same bar.

For each issue:
- quote the line
- explain in 1-2 sentences why it causes a backtest/live mismatch
- rate its severity
- give the fix

Severity levels:
- **Critical:** uses future data; the backtest can't be trusted until fixed.
- **High:** live results will likely differ materially from the backtest.
- **Medium:** an optimistic assumption that inflates results.
- **Low:** best practice or hygiene.

## Step 3: Realistic backtest settings
Review every `strategy()` parameter and recommend values for my market and execution method. Show current vs. recommended and why. At minimum, cover:

- **`commission_type` / `commission_value`:** use my real fees. If they're unknown, assume conservatively and say so:
  - crypto: about 0.05-0.1% per side
  - futures: the broker's per-contract fee
  - US stocks: $0 plus slippage
- **`slippage`** (in ticks): never 0 for market orders.
- **`initial_capital`, `default_qty_type`, `default_qty_value`:** flag 100%-of-equity compounding, or position sizes I couldn't realistically trade.
- **`margin_long`, `margin_short`, `pyramiding`, `close_entries_rule`**
- **`process_orders_on_close`, `calc_on_every_tick`, `calc_on_order_fills`**
- **`use_bar_magnifier`, `fill_orders_on_standard_ohlc`**
- **`backtest_fill_limits_assumption`:** for limit orders, require price to trade through the limit, not just touch it.

Also add a backtest date-range filter: start and end `input.time()` inputs that gate entries. This lets me split the data into in-sample and out-of-sample periods.

## Step 4: Curve-fitting assessment
Evaluate how likely the strategy is overfit to past data. Look at:

- **Number of tunable inputs.** Every input is a degree of freedom, and more of them means more trades are needed to trust the results.
- **Suspiciously specific values.** E.g., RSI length 17, threshold 73.5 or MA 143 instead of common or round values. Suggest more defensible values or ranges.
- **Stacked filters.** Multiple conditions that look like they were added to remove specific losing trades.
- **Time and date filters.** Specific hours, days of the week or excluded date ranges that look cherry-picked.
- **Asymmetric long/short settings** with no clear reason.
- **Trade count.** Under ~30 trades is statistically meaningless, and under ~100 is weak evidence. If the count is low, suggest more history or more symbols rather than looser rules.
- **Results that look too good.** Very high profit factor or win rate, an unusually smooth equity curve, or a few huge winners carrying the total.

Then:
1. Give an overall **overfitting risk rating (Low / Moderate / High)** with the top reasons.
2. Recommend specific parameter changes or simplifications, and explain what each one trades off.
3. Give me a **sensitivity test plan** to run in TradingView:
   - For the 3-5 most important inputs, make a table of values to try: about -20%, -10%, base, +10% and +20%.
   - Explain what a robust result looks like: performance changes gradually across nearby values (a plateau).
   - Explain what a fragile one looks like: it only works at one exact value (a spike).
4. Suggest 2-3 other symbols or timeframes to test on, to check the strategy isn't fit to one chart.

## Step 5: Corrected code
Return the **complete, corrected script**, ready to paste into the Pine Editor.
- Keep the same Pine version unless it's v4 or older. If you upgrade, say so.
- Keep the core logic and all inputs unless a change is required to fix repainting or lookahead. If you must change logic, call it out explicitly.
- Mark every change with a comment: `// FIX: <reason>`.
- Only use built-in functions and parameters that exist in the declared Pine version. Do not invent functions. If you're unsure something exists, say so instead of guessing.
- No placeholders and no "rest of code unchanged." Give me the full script.
- Double-check that it compiles: matching types, no undeclared variables, and no parameters removed in that version (e.g., `when=` was removed in v6).

## Step 6: Verification checklist
Give me a short checklist to confirm the fixes worked, including these steps:
- Remove and re-add the strategy to the chart so the new default properties load. Then confirm the Properties tab matches the code.
- Compare before and after results (net profit, trades, profit factor, max drawdown), and explain any big changes.
- Run a repainting check: use Bar Replay, or note today's signals and reload the chart tomorrow. Confirm no historical signals moved or disappeared.
- Run the in-sample / out-of-sample date split from Step 3.
- If I use alerts, delete and recreate them. Existing alerts keep running the old version of the script.