Trading Strategy Generator

config.json Format

{
  "source": "auto",
  "codes": ["000001.SZ"],
  "start_date": "2016-03-18",
  "end_date": "2026-03-18",
  "warmup_bars": 0,
  "interval": "1D",
  "initial_cash": 1000000,
  "commission": 0.001,
  "extra_fields": null,
  "fundamental_fields": null,
  "optimizer": null,
  "optimizer_params": {},
  "engine": "daily",
  "position_adjustment": "rebalance",
  "rebalance_mask": null,
  "rebalance_tolerance": 0.05,
  "validation": null
}

• source: "auto" (recommended, auto-select by code format) / "tushare" / "yfinance" / "okx" / "akshare" / "ccxt"
  • "auto" supports mixed instruments. For example, ["000001.SZ", "BTC-USDT"] will be automatically routed to tushare and okx
  • Futures codes (e.g. "IF2406.CFFEX", "ESZ4") and forex pairs (e.g. "EUR/USD") are also auto-routed
• interval: candlestick interval, default "1D". Supported values: "1m" / "5m" / "15m" / "30m" / "1H" / "4H" / "1D" / "1W" / "1M" (weekly and monthly bars are built from daily ones; "1M" is a month, "1m" a minute)
  • The annualization factor for minute backtests is inferred automatically from source (252 trading days for China A-shares, 365 calendar days for crypto)
  • Minute backtests can be very data-heavy. Recommended limits are no more than 30 days for 1m, or 1 year for 1H
• warmup_bars: how many leading bars exist only to prime the indicators. They are loaded and fed to SignalEngine.generate(), then excluded from trades, the equity curve, the benchmark and every metric. Default 0 grades the whole loaded window.
  • Use it whenever you widen start_date for an indicator's lookback. start_date is the data window; start_date plus warmup_bars is the evaluation window, and the report describes the second one.
  • Size it from the longest lookback in the strategy, plus a margin: MA200 needs at least 200 daily bars, a 252-day rolling z-score needs 252. Then set start_date far enough back to supply them.
  • evaluation_start_date ("YYYY-MM-DD") is the same instruction stated as a date, for when the user names the period rather than the lookback. Declare one or the other — declaring both is rejected.
• extra_fields: China A-shares can use values such as ["pe", "pb", "roe"]; other markets should use null
• fundamental_fields: optional China A-share statement fields, such as {"income": ["total_revenue", "n_income"], "fina_indicator": ["roe"]}; use null unless the strategy needs financial statement pre-filtering
• optimizer: optional, one of "equal_volatility" / "risk_parity" / "mean_variance" / "max_diversification" / "turnover_aware" / null (equal-weight by default)
• optimizer_params: optimizer parameters, such as {"lookback": 60}. mean_variance additionally supports {"risk_free": 0.0}; turnover_aware supports {"risk_aversion": 1.0, "turnover_penalty": 0.5} (L1 penalty on weight changes; tune to data frequency)
• engine: backtest engine, default "daily". For options strategies, set "options" (requires OptionsSignalEngine)
• position_adjustment: always state this explicitly — the two modes produce different books from the same signals, and neither is right for every strategy.
  • "rebalance" executes every target change with market fills and weighted-average entry accounting. It also re-sizes whenever the held weight has drifted from the target, and a strategy restates its target on every bar, so a constant target means a fill on every bar: measured on a 40-bar rising series, a constant 20% target produced 40 fills instead of 1, with the fees, slippage and transaction taxes that follow. Use rebalance_mask when the strategy has its own execution cadence.
  • "hold" keeps a same-direction position until it exits or reverses, so the weight drifts with price and a requested resize is not executed. Dropped requests are counted in the report as dropped_target_adjustment_count, with the first twenty listed, so a rebalance count that does not match the trade log is explained rather than silent.
  • Rule of thumb: "rebalance" when the target weight itself carries the strategy (optimizers, risk budgets, continuous scaling); "hold" when entries and exits carry it and the weight in between is incidental.
• rebalance_mask: optional execution schedule used only under "rebalance". Use a pandas offset alias such as "MS", "W-FRI", or "QS", or an explicit ISO-date list such as ["2026-01-02", "2026-02-02"]. Each period/date selects the first aligned trading bar on or after it; ordinary bars HOLD even when the dense target is zero. An alias must not be finer than the aligned bar interval; W-FRI starts a Friday-anchored period and normally executes on the following Monday. Omit it to preserve every-bar execution. Do not combine it with "hold".
• rebalance_tolerance: drift band around the target, as a fraction of it, used only under "rebalance". A resize executes once the held weight has moved further than this from its target; a changed target breaches any sane band on its own, so target changes always execute. Default 0.0 means no band, and then the resize test is decided by the slippage width alone — measured on a constant 20% target over 60 bars, 0.0 produced 60 fills, 0.02 produced 12, and 0.05 produced 5 while the weight never left 0.21. Use rebalance_mask, not tolerance, to express a strategy's execution cadence. 0.05 is a reasonable starting point, not a recommendation with evidence behind it — it is your modelling choice and the report records the value the run used.
• initial_cash: default 1,000,000
• commission: default 0.1%
• validation: optional statistical validation after backtest completes. Omit to skip. Example:

  "validation": {
    "monte_carlo": {"n_simulations": 1000},
    "bootstrap": {"n_bootstrap": 1000, "confidence": 0.95},
    "walk_forward": {"n_windows": 5}
  }

  • monte_carlo: permutation test — shuffles trade order to compute p-value (is Sharpe significantly better than random?)
  • bootstrap: resamples daily returns to compute Sharpe 95% confidence interval
  • walk_forward: splits equity curve into N windows, checks performance consistency
  • Each key is optional — include only the validations you want
  • Can also run standalone on past results: python -m backtest.validation <run_dir>

Review Criteria

Hard Gates (any failure → passed=false)

1. artifacts/metrics.csv exists and is non-empty
2. artifacts/equity.csv exists and is non-empty
3. exit_code == 0 (backtest exits normally)
4. The equity column in equity.csv contains no NaN values
5. trade_count > 0 (zero trades = signal bug)

Scoring Rules

• Successful backtest + complete artifacts + at least 1 trade → score ≥ 60 → passed
• Poor return / low Sharpe alone should not push the score below 60; they are optimization suggestions only
• score ≥ 60 = passed=true

Bug Categories (reduce the score)

1. Zero trades (trade_count=0): signal-logic bug, conditions may be too strict
2. Late first trade (first trade > 2 years after backtest start): data-filtering bug or overly long lookback window
3. Capital utilization < 50%: position-management bug, portfolio is flat most of the time
4. Open position at the end (positions still open when backtest ends): exit-signal timing bug

action_items Format

If improvements are needed after evaluation, write action_items:

• Format: "Change X from A to B" or "Add X logic in signal_engine.py"
• Must be specific down to parameter values, file names, and function names
• At least 2 items
• Examples:
  • "Change short MA from 5 to 10 days to reduce whipsaw signals"
  • "Add stop-loss: force close when loss exceeds 5%"
  • "Add volume filter in signal_engine.py: only trigger buy on high volume"

Cross-Market Strategies

When the user requests a backtest with codes from different markets (e.g. ["000001.SZ", "BTC-USDT"]):

• Set source: "auto" in config.json
• The CompositeEngine handles calendar alignment, shared capital, and per-market rules automatically
• Use volatility-adjusted weights so high-vol assets (crypto) don't dominate the risk budget
• See the cross-market-strategy skill for per-market parameters, vol-adjustment, and example code

Supporting Files

• examples.md — example call sequence