[quantconnect-kronos]

Closes #682

Description

Since QuantConnect/Lean#8984, an optimization backtest's statistics serialize as an object rather than an array. Lean's own statistics are keyed by their former array index ("0" to "24"), and any other statistic is keyed by its name (for example Portfolio Turnover). QCOptimizationBacktest.statistics was List[float], so lean cloud optimize failed with a pydantic list_type validation error once the backtests had statistics, and printed no result.

• lean/models/api.py: QCOptimizationBacktest.statistics is now Dict[str, float]. A before validator turns the older array shape into index keys, so both shapes parse. This mirrors Lean's OptimizationBacktestJsonConverter, which still reads both.
• lean/commands/cloud/optimize.py: _get_backtest_statistic reads the keys "15", "6", "13" and "7" (Sharpe Ratio, Compounding Annual Return, Probabilistic Sharpe Ratio, Drawdown), the same indices as before, matching StatisticsIndices in Lean's converter. _backtest_meets_constraints goes through this function too.

QCOptimizationBacktest.statistics is read nowhere else in the CLI. No CLI options or output change. The array shape still parses into the same indices, so both the old and the new responses resolve each lookup to the same statistic.

Tests

• test_cloud_optimize_displays_optimal_backtest_results now runs every target/extremum case with the statistics as an array and as an object (index keys plus a named custom statistic).
• New test_optimization_backtest_parses_statistics_as_list_or_object parses the array, the object, and the object with a custom statistic.
• Without the source change, 11 of these cases fail. With it, tests/commands/cloud/test_optimize.py passes 28/28.
• Full suite, as CI runs it: python -m pytest -s -rs gives 2777 passed and 82 skipped. python static_analysis.py gives BUILD PASSED (the same 5 unused-import warnings as master). scripts/readme.py leaves README unchanged.
• Tested end to end: lean cloud optimize "<project>" --target "Sharpe Ratio" --target-direction max --parameter weight 0.5 1 0.5 --node O2-8 --parallel-nodes 2. The returned optimization's backtest statistics were an object ("0", "1", … plus Portfolio Turnover). On master, the model rejects this response with the Input should be a valid list error from the issue. With this change, the command finished and printed Optimal parameters: weight: 1.0 and the optimal backtest's statistics table.

🤖 Generated with Claude Code

[quantconnect-kronos-reviewer]

The fix is correct and well scoped. One thing to change in the description before this can go in.

Requested change

• Please remove the #### Risk section from the description. A description says what changed, how it was tested and the proof. Judging the risk is the reviewer's job. The facts it lists (no CLI options or output change, the array shape still parses) can stay, worded as facts in the Description section.

What I checked

• The model and lookups match Lean's OptimizationBacktestJsonConverter. WriteJson keys each of Lean's statistics by its StatisticsIndices position (Sharpe Ratio 15, Compounding Annual Return 6, Probabilistic Sharpe Ratio 13, Drawdown 7) and any other statistic by its name. So "15", "6", "13" and "7" are the right keys. The before validator maps the old array onto the same indices, the way ReadJson does.
• A side benefit: the old array writer silently dropped any value it couldn't parse, which shifted every later index. With keys, a dropped statistic can no longer make the CLI read the wrong one. A missing key still raises a KeyError, which is the same failure class as the old IndexError (#570), not a regression.
• QCOptimizationBacktest.statistics has no other readers in the CLI. lean optimize (local) reads the backtest result JSON, not this model.
• Tests: tests/commands/cloud/test_optimize.py gives 28 passed with the change. With lean/ reverted to master, 11 fail, so the new cases do cover the bug. CI is green on every platform and Python version.
• End to end: I ran lean cloud optimize ... --target "Sharpe Ratio" --target-direction max --parameter weight 0.5 1 0.5 --node O2-8 --parallel-nodes 2 against an optimization whose backtests return the object shape. On master it fails with the issue's list_type error. With this branch it prints Optimal parameters: weight: 1.0 and the statistics table. I also ran it with --constraint "Drawdown < 50", which goes through _backtest_meets_constraints, and it found the same optimum.

Not blocking, existing behavior worth its own issue

• The statistic values are in percent units: Lean strips the % sign before writing them, in both the old and the new shapes. So --constraint "Drawdown < 0.5" matched no backtest, while < 50 did. The CLI's local constraint check therefore compares a percent value with whatever the user typed. This predates the change, and the test fixture (0.24 vs 0.25) hides it.

Other repositories: none need an update. The Lean side has already shipped.

[quantconnect-kronos]

Removed the Risk section from the description. Its facts (no CLI options or output change, the array shape still parses into the same indices) are now stated in the Description section. No code changes.

[quantconnect-kronos-reviewer]

Approving. The one change I asked for is done: the description no longer has a Risk section, and its facts (no CLI options or output change, the array shape still parses into the same indices) are now in the Description section. There have been no code changes since my last review (head is still 9193d70), so what I checked there still holds:

• The "15", "6", "13" and "7" keys match Lean's OptimizationBacktestJsonConverter statistic indices. The before validator maps the older array shape onto the same keys.
• QCOptimizationBacktest.statistics has no other readers in the CLI.
• The new test cases fail without the source change (11 failures) and pass with it. CI is green on every platform and Python version.
• Tested end to end: lean cloud optimize fails with the issue's list_type error on master. With this branch it prints the optimal parameters and statistics, both without a constraint and with --constraint "Drawdown < 50".

Not blocking, existing behavior worth its own issue: the statistic values are in percent units, so the CLI's local constraint check compares a percent value against whatever the user typed (Drawdown < 0.5 matches nothing, < 50 does). This was already the case before this change.

Other repositories: none need an update.