SpotEightMajorsRelativeStrengthWeeklyRotationLongOnly

Cross-Sectional Momentum Weekly Rotation across Eight SPOT Majors, Long-Only (BINANCE_SPOT — the Correct No-Leverage Venue: BTC/ETH/SOL/BNB/AVAX/LINK/ADA/XRP, Hold Top-3 by 30-Day Relative Strength, Absolute-Momentum Cash Filter, 3-Parameter)

The factory's single most robust long-only survivor is cross-sectional relative-strength momentum weekly rotation (deployed on 8 USD-M PERPS, Sharpe 2.6). That strategy is long-only and unleveraged, yet it sits on futures — paying futures fees and carrying liquidation/funding machinery for zero shorting or leverage benefit. Per the project's own venue-routing rule ('long-only-no-leverage strategies belong on BINANCE_SPOT, not futures'), the CORRECT venue for this edge is spot. This hypothesis implements exactly that: the identical proven relative-strength mechanism on the eight SPOT majors, filling the genuinely under-represented BINANCE_SPOT venue (12.1% vs >=15% target, and binance_spot is the best-surviving price tag at 2%). It is differentiated from the deployed perp version by venue (a real quota gap, correct venue routing, no funding drag or liquidation risk — the CASH account cannot blow up, unlike the -100% intraday-leverage death), from my pending mid-cap rotation by universe, and from the pending low-vol rotation by signal. It avoids every confirmed dead class: not carry (all carry except BTC now dead), not a grid (fat-tail risk_reject), not a pairs bet (SOL-AVAX -82%), not options (trade-count wall), not liquidations (data wall), not a market-neutral basket (L12). Only 3 parameters against the overfit graveyard.

Iteration 6 addresses the ONLY reported failure: the submitted class name 'SpotMajorsMomentumRotationLong' was already bound to a different hypothesis (29ce1b4b), so the output could not be attributed to this one. The class is renamed to SpotEightMajorsRelativeStrengthWeeklyRotationLongOnly — a name that specifically describes this hypothesis (eight SPOT majors, relative-strength ranking, weekly rotation, long-only) — and nothing else was changed, so every layer that already passed (static analysis, hypothesis consistency, synthetic scenarios, sandbox execution continuity) runs byte-identical logic. The implementation matches the hypothesis exactly: the proven cross-sectional relative-strength rotation mechanism, moved to BINANCE_SPOT because it is long-only and unleveraged (the project's own venue-routing rule), with the absolute-momentum cash filter as the third tuned parameter and no funding, liquidation or shorting machinery. Only three tuned parameters (lookback_days, max_holdings, abs_mom_threshold) drive selection; the regime SMA and trailing stop are standard structural defenses carried over from the prior iterations' analyst/QA feedback, and every clamp in the code is declared in _param_bounds.

coding_stuck_3_timeouts

Long-only weekly cross-sectional relative-strength rotation across eight BINANCE_SPOT majors (BTC/ETH/SOL/BNB/AVAX/LINK/ADA/XRP) on 1-DAY bars. Every 7 calendar days (clock = the primary bar's UTC day index, so the schedule is restart-invariant) it ranks the eight names by their 30-day return, keeps the top 3 that also pass an absolute-momentum cash filter (own 30d return > 0), and equal-weights them to 97% gross of true total equity (residual USDT cash + mark value of open spot holdings) via delta-to-target orders; everything else sits in cash. A portfolio-level regime gate holds the book in cash whenever BTC closes below its 100-day SMA, and a per-name 15% trailing stop, evaluated on every bar rather than only at rebalance, closes any holding that breaks down mid-week. CASH account, no leverage, never sells to open.

developer output rejected: strategy_name 'SpotMajorsMomentumRotationLong' already belongs to another hypothesis (29ce1b4b) — this code is not an implementation of THIS hypothesis. Implement the hypothesis in the brief under a new, specific class name.

Either fix regime_sma_days and stop_pct as non-optimized structural defaults (keep them out of the walk-forward search space) or update the hypothesis text to acknowledge the dual-momentum overlay + trailing stop so the '3-parameter' claim is honest.

The hypothesis explicitly claims '3 parameters against the overfit graveyard' (lookback_days, max_holdings, abs_mom_threshold). The code adds two additional structural mechanisms NOT named in the hypothesis: a portfolio-level BTC regime SMA gate (regime_sma_days=100, book-to-cash when BTC < SMA) and a per-name 15% trailing stop (stop_pct). These were carried over from prior QA/analyst iterations and materially change the return profile vs the stated pure cross-sectional rotation. The core relative-strength edge is intact, so this is not a fail, but the effective tunable surface is larger than advertised — the optimizer should be aware and the analyst should watch for overfitting across the extra dimensions.

No code change needed; optionally clarify the hypothesis text to say '1-DAY bars, 30-day lookback, weekly rebalance' to avoid future confusion.

Advisory only (consistency warning in the brief): hypothesis title says '30-Day / Weekly' while config.bar_type is 1-DAY. This is NOT an actual mismatch — 1-DAY is the correct base timeframe, 30-day is the lookback window (lookback_days=30), and 'weekly' is the rebalance cadence (rebalance_days=7). Daily bars + 30-day relative-strength lookback + 7-day rotation is internally consistent and matches the deployed sibling.

Sandbox headline is favorable (avg_trade_return_pct 8.2%, PF 1.65, positive total return) but note (1) exposure_pct 139.88% and turnover 1179 are higher than a 0.97-gross CASH long-only book implies — likely mtm metric artifacts (a CASH account cannot buy beyond available cash), but the analyst should confirm gross never exceeds 1x in the full backtest positions report; (2) the reported Sharpe (-0.01) is flagged incoherent by the engine (computed off mtm_equity_curve) — judge edge on the equity curve / per-trade return, not this Sharpe. Core momentum-rotation edge is the factory's single most robust long-only survivor, so the mechanism is sound; the spot fee drag (~2x futures) is the main thing to watch at full backtest.

Backtest gate: - metrics unreliable: Incoherent: Sharpe -2.14 disagrees in sign with total_return 80563.92% — the Sharpe is computed from the mtm_equity_curve series while the return comes from the equity curve. Judge on the equity curve.

SpotMajorsMomentumRotationLong

Verification failed (Layer 4 — QA review): - The developer's core continuity evidence does NOT reproduce in the real engine. The rationale claims an offline harness produced '470 weekly rebalances across 2017-2026, last rebalance at day 3283 of 3285' over 9 years of data. But the Layer-3 sandbox (real catalog data) reports data_days=363 and total_trades=35. Either (a) the real aligned BINANCE_SPOT history for this 8-major set is ~1 year, in which case 35 trades is the FULL count and the strategy is permanently sub-measurable (far below the ~100-trade floor; Sharpe CI [-2.71, +0.60] straddles zero, probabilistic_sharpe 0.077), or (b) 363 days is a sandbox cap, in which case the strategy still posts a hard-abandon-level drawdown in a single year (see below). The 9-year/470-rebalance claim is offline-only and is contradicted by the engine, so the measurability the developer asserts is unverified. This is the same offline-does-not-reproduce-in-engine pattern that has sunk siblings this session. - The sandbox max_drawdown is 50.41% (CI high 70.2%), at/above the factory's 50% hard-abandon threshold, alongside total_return -38.3%, profit_factor 0.36, Sharpe -1.14, and win_rate 0.286 over just 363 days. The hypothesis is built on the claim that this is 'the factory's single most robust long-only survivor (Sharpe 2.6 on perps)' merely re-venued to spot — but that claim does not transfer: spot round-trip cost is ~2x futures (0.10% vs 0.05% taker) and at turnover 13.4 the fee drag is material, and this window is a down/choppy period that chops long-only momentum rotation to a 50% drawdown. This is the pure-OHLCV cross-sectional momentum-rank class, which has no survivors historically. A 3-parameter rotation cannot be tuned out of a 50% DD / negative-expectancy result — it is a design-level non-viability, not a parameter miss. - The iteration-3 execution fix itself is correct and successful: overriding on_bar to maintain symbol-keyed buffers and drive the rebalance off the primary BTC UTC-day index bypasses the cross-leg alignment barrier that froze iters 1-2, and the engine now trades continuously (35 trades vs the prior ~3-then-freeze). Sizing is also correct and safe: gross capped at gross_exposure=0.97 (<1x), delta-to-target with no double-counting, spot-long-only discipline maintained (SELL only trims/exits existing longs, never opens a short). No code defect remains.

Verification failed (Layer 4 — QA review): - avg_trade_return_pct is -0.127% (% of notional) -- NEGATIVE per-trade expectancy, below the fee-viability floor (0.15% futures / 0.25% spot; spot round-trip cost is ~0.20%). profit_factor 0.90, total_return -1.9%, expectancy -$135/trade. The iter-4 BTC regime gate successfully cut max_drawdown from 50.4% to 20.3% (below the hard-abandon line), but it did so by sitting in cash through most of the down/choppy window, which removed the drawdown WITHOUT creating a positive edge: the trades that remain still lose money net of spot fees (avg_loss $3,144 vs avg_win $2,120, so a 57% win rate still nets negative). A strategy whose average trade loses money after fees is not viable regardless of drawdown control. - Sub-measurability, now worse than iter-3. The engine produced only 14 trades over data_days=363 (iter-3 had 35; the regime gate roughly halved the count by holding cash more). 14 trades is far below the ~100-trade floor needed to distinguish edge from noise: Sharpe 0.029 with CI [-1.45, +1.90] straddles zero, probabilistic_sharpe 0.51 (coin-flip). The developer's rationale again cites an offline harness ('~52 weekly rebalances / 363 days', '5 seeds', 'DD ~27%'), but the real engine shows 14 trades and 20.3% DD -- the offline numbers do not reproduce in the engine, the same discrepancy flagged in iter-3. On the ~1-year aligned spot window that actually exists for this 8-major set, this strategy cannot generate a measurable sample. - The code itself is correct: the portfolio-level BTC regime gate (_regime_ok, BTC close > 100-day SMA) is implemented cleanly, integrates into _maybe_rebalance so risk-off flattens the whole book to cash, preserves the iter-3 execution fix and delta-to-target sizing (gross <=0.97x), and maintains spot long-only discipline (SELL only trims/exits longs). No code defect. This is a viability failure, not a correctness one -- and this is now the fourth iteration in which each fix (execution -> drawdown -> now expectancy/measurability) simply exposes the next wall. return_skew -3.33 / kurtosis 42.6 show the fat left tail is reduced but not gone.

Verification failed (Layer 4 — QA review): - The iter-5 trailing stop FAILED to fix the negative per-trade expectancy it targeted. avg_trade_return_pct is still -2.32% (negative, below the fee floor), total_return -14.63% (worse than iter-4's -11.6%), profit_factor 0.49, Sharpe -0.48. The specific reward/risk asymmetry QA identified is UNRESOLVED: avg_win $2,021 vs avg_loss $2,877 (losers still larger), and largest_loss actually got WORSE (-$11,303 vs the prior -$8,671), with return_skew -4.57 and kurtosis 51.9 -- the fat left tail the stop was meant to cut is intact and slightly worse. Mechanistic reason: a 15% trailing stop on daily bars cannot cap a tail produced by overnight/multi-day GAPS on volatile spot majors -- price gaps straight through the 15%-below-peak trigger and the stop books a LARGER realized loss, not a smaller one. So the stop adds fee-bearing churn without cutting the loser tail, and expectancy stays negative. - This closes the iteration arc for this sibling with no viable configuration found. iter-3 (gates off) = 35 trades, 50% DD; iter-4 (regime gate) = 14 trades, negative expectancy; iter-5 (trailing stop) = 17 trades, still -2.32%/trade and a WORSE largest loss. Every lever -- selection filter, regime gate, tail stop -- has been tried and none produces a fee-clearing edge, and the trade count stays sub-measurable (17 over 363 days) throughout. The developer's own rationale concedes the point: it states full measurability 'may require ... relaxing the absolute filter (which would change the hypothesis's defining feature) -- a scope decision beyond this fix.' That is an admission the strategy cannot be made both measurable AND edge-positive within the hypothesis as written. - The iter-5 code is correct: the per-name trailing stop is wired properly (per-bar evaluation, peak tracking, full long-only exit via _submit_exit_position, peak cleared on flat/re-entry), and it composes correctly with the iter-4 regime gate, iter-3 execution, delta-to-target sizing (gross <=0.97x), and spot long-only discipline. No code defect. The failure is viability, not implementation. max_drawdown rose to 30.6% (CI high 55%), so the tail stop did not even improve drawdown control here.