SpotMajorsLongFlatTrendOverlayFixedWeightSleeves

Spot Majors Long/Flat Trend Overlay, Long-Only Independent Fixed-Weight Sleeves (BTC/ETH/SOL on BINANCE_SPOT, Daily Bars, Each Asset Held at a FIXED Weight When Its Own Trend Is Up Else Cash — NOT a Rotation Book, No Leverage, Low-Turnover, Low-Parameter)

A LONG-ONLY, multi-instrument trend-following overlay on the three spot majors where the factory's trend edge is EMPIRICALLY VALIDATED — BTCUSDT, ETHUSDT, SOLUSDT on BINANCE_SPOT. Each asset is an INDEPENDENT, FIXED-WEIGHT sleeve: when that asset's own daily trend is up it is held at its fixed target weight; when its trend is down the sleeve sits in USDT (cash). Multiple sleeves are held SIMULTANEOUSLY at fixed weights — this is deliberately NOT a single-position rotation book, which dodges the HIGH-PRIORITY engine accounting bug the analyst just flagged (the dual-momentum ROTATION run produced impossible 1180%-position / +80,644%-day metrics because the engine mis-accounts equity/return for SINGLE-POSITION multi-instrument ROTATION strategies; a fixed-weight book that holds several positions at once is the normal multi-position case and is not implicated). It is engineered around every other lesson in the failure log: (1) asset-selectivity — it uses trend ONLY on BTC/ETH/SOL, the high-beta majors that trend cleanly, and explicitly NOT laggard/range-bound alts like LTC where TS-momentum was just decisively falsified (16.8% win rate, account wipeout); (2) event risk — it is LONG-ONLY with NO leverage and a cash filter, so it can never be short into an intraday news pump (the mechanism that wiped the XRP short -95% in a day), and it is diversified across three names so no single asset dominates; (3) regime risk — the absolute-trend cash filter moves each sleeve to USDT in its own downtrend, sidestepping the bear-market drawdowns that sink naive long-only crypto; (4) no fragile data — pure OHLCV (no OI/funding/options/microstructure data walls); (5) fees — weekly decision cadence + fixed weights = low turnover, so the ~0.20% spot round trip is immaterial. It fills the under-weight, highest-survival BINANCE_SPOT venue (9.5% vs ≥15% target) and the multi-instrument scope, with a tiny parameter count (2).

Iteration 6 fixes exactly the reported failure and nothing else. The iteration-5 sandbox showed primary_bars_received=112 against waiting_on_extra_legs=2404 with all returns in Sep-Dec 2020: the base template's cross-leg alignment barrier (_maybe_process_primary defers the primary bar until every same-timeframe extra leg has a bar at that timestamp) held the whole book hostage to the youngest leg, so BTC/ETH could not evaluate before SOL listed in 2020-08 and only ~112 bars ever produced a decision. The single behavioural change is clearing self._sync_extra_iids after super().__init__, which removes that barrier for this strategy: every primary bar is evaluated on arrival, each sleeve trades as soon as IT ALONE has trend_len+1 of its own closes (_metric stays None, _trend_up returns None = idle, never a forced exit), and a sleeve with no data yet has no price so it is skipped in reconciliation and contributes nothing to book value. Book value is therefore computed over whatever sleeves currently have data, exactly as the feedback asks, and BTC/ETH now evaluate from the start of their history with SOL joining in 2020. Dropping the barrier is safe here because the book takes no cross-asset spread or ratio - each sleeve is priced and sized off its own latest close, so a T-1 sleeve price is conservative, not a look-ahead. Mechanism, the two tunables, book-value sizing, max_gross, the resize band and the O(1) per-bar SMA state are byte-for-byte the logic that already passed Layers 1-2; imports are unchanged.

Promote is impossible — the HARD PBO gate fails (0.6204 > 0.5, parameter selection more likely than not overfit, unwaivable) — and the strategy has no genuine edge to salvage by iterating. Independent of the deflation, information_ratio is -0.26 vs equal_weight_basket (benchmark_meaningful=true): the long/flat trend overlay risk-adjusted UNDERPERFORMS simply equal-weighting BTC/ETH/SOL, so the timing adds no alpha and the +219%/+3521% headline is crypto beta (beta 0.32, MTM) carried with a 40.9% drawdown. It is also not significant (deflated_sharpe 0.946 < 0.95, is_significant=false, fails programme FDR keeping 3 of 232) and OOS is inconsistent (windows 1.98/0.89/-0.09). Crucially there is no parameter region to tune toward: optimization DEGRADED the result (Sharpe 1.23 -> 1.08), the chosen trend_len=30 sat on the search boundary, and the whole 2-tunable sensitivity surface is flat at ~0.70-1.09 Sharpe — far below the 1.5 floor everywhere. With only trend_len and sleeve_weight to move, a second optimization attempt cannot manufacture alpha the surface does not contain, and reframing the same long/flat-trend-on-spot-majors mechanism onto another instrument just reproduces long crypto beta (every near-sibling — dual-momentum rotation, vol-managed long/flat, static 60/30/10, monthly TS-momentum timer, ETH/BTC ratio — was already abandoned). Failure pattern: no risk-adjusted edge over benchmark / overfit selection (long-only spot majors trend beta).

Long-only spot trend overlay on the three majors (BTCUSDT/ETHUSDT/SOLUSDT, BINANCE_SPOT, daily bars, no leverage). Each asset is an INDEPENDENT fixed-weight sleeve: while its own close is above its own SMA(trend_len) the sleeve is held at sleeve_weight of book value; when its own trend turns down the sleeve is sold to USDT. Sleeves are held simultaneously, so the book runs 0/3 to 3/3 invested; gross is capped at 0.75 of book so a CASH account always keeps a USDT buffer. Two tunables (trend_len, sleeve_weight), pure OHLCV, no shorts, low turnover.

None required. If strict weekly cadence is desired, gate decisions on day-of-week derived from bar.ts_init; otherwise treat 'weekly' as descriptive of effective turnover.

Hypothesis prose claims a 'weekly decision cadence', but the code evaluates the per-asset SMA trend gate on EVERY daily bar and can enter/exit/resize any day. Turnover stays low in practice via trend persistence + the 0.30 resize band (sandbox turnover 12.8), and the hypothesis title itself specifies daily bars, so this is a loose-wording discrepancy, not a mechanism mismatch. Config bar_type (1-DAY) matches the title.

No change needed; the override is respected by the base template.

min_bars_required(self) overrides the framework method (static-analysis base_shadow warning). Confirmed the base template DOES call self.min_bars_required() in _maybe_process_primary (line 472), so the override is honored for warm-up gating. Additionally, each sleeve self-guards via _metric staying None until trend_len+1 of its own closes, so warm-up is enforced defensively even if the override were ignored.

Sandbox is a truncated 296-day window (2020, largely a bull leg) — its +50% / Sharpe 1.96 does not exercise a full bear cycle, and regime_performance shows the 'normal' vol tercile at -14.8% (Sharpe -1.58). The cash filter's real value (avoiding bear drawdowns) is untested here. information_ratio is -0.49 vs the equal-weight basket, so on this slice the trend gate did not add over buy-and-hold. Not blocking — the full-history backtest over 2017-2026 is where the long/flat overlay's regime protection should be judged.

Iteration-6 structural fix is confirmed working: entry_diag now shows primary_bars_received=1203 with waiting_on_extra_legs=0 (was 112/2404 in iter 5). The equity curve trades continuously from 2017-08 and the sleeves correctly sit flat in USDT through the 2018/2019 downtrends (visible plateaus) — this is finally a valid ~9-year full-history test.

Numerically viable for a review gate: metrics_reliable=true, 66 trades, PF 2.66, Sharpe 1.23 (CI [0.10, 2.27], positive), CAGR 44.6%, recovery_factor 7.3, avg_trade_return_pct 8.40% (far above the ~0.25% spot fee floor; commission only 1.92% of gross).

Trades match the hypothesis: long-only (0 short trades), trend-gated, 17-day avg hold, 21% win rate with 10:1 win/loss geometry — the classic trend-following signature, not a mismatch.

Regime protection — the whole point of the cash filter — now validates on full history: positive across all three vol terciles (calm +75.7%/Sh 2.36, normal +40.4%/Sh 1.21, stressed +28.3%/Sh 0.77) and only -5.8% / 16.4% DD in the covid crash. This is what the QA edge-concern flagged as untested on the truncated iter-5 window; it holds up.

Positive alpha (0.26) with modest beta (0.34); Binance-SPOT trend on majors is the survivable venue/mechanism class (L82).

information_ratio is essentially flat (-0.06) vs the fair equal-weight-basket benchmark (benchmark_meaningful=true) — on a risk-adjusted, tracking-error basis the trend gate does not yet clearly beat simply equal-weighting the three majors. The value is in drawdown reduction (43.8% vs the 70%+ a buy-hold basket eats), which optimization of trend_len should sharpen.

max_drawdown 43.8% is under the 50% bar but the DD CI high is 60.4% — long-only crypto tail risk is real; the promotion drawdown floor will be the binding constraint after optimization.

exposure_pct 99.2% means the book is rarely fully in cash; regime de-risking is partial (0/3..3/3 sleeves) rather than a hard off-switch.

Only 2 tunables and 66 trades — a thin sample for the walk-forward; deflation/holdout will be the real test.

Iteration-6 structural fix is genuinely working: entry_diag shows primary_bars_received=3306 / waiting_on_extra_legs=0, so the full 2017-2026 history is now evaluated and the sleeves correctly sit flat in USDT through the 2018/2022 bear markets.

Holdout passed (Sharpe 1.78 on 74 trades, ratio 1.92, consistent_with_oos=true) and sensitivity shows no cliffs (cliff_count=0).

Per-trade economics are far above the spot fee floor (avg_trade_return_pct 7.1%), so this is NOT a fee-edge death; commissions are only 3.46% of gross.

HARD gate failure (unwaivable): PBO 0.6204 > 0.5 — parameter selection is more likely than not overfitting, so a promote verdict is impossible.

No risk-adjusted edge over its own fair benchmark: information_ratio -0.26 vs equal_weight_basket with benchmark_meaningful=true. The trend overlay risk-adjusted UNDERPERFORMS simply equal-weighting BTC/ETH/SOL — the positive raw alpha (0.26) is only a low-beta (0.32) artifact. This is long crypto beta, not timing alpha.

Not statistically significant: deflated_sharpe 0.946 < 0.95, is_significant=false, and it does not survive programme-level FDR (Benjamini-Hochberg keeps 3 of 232).

Optimization DEGRADED the result (default trend_len=50/weight=0.30 Sharpe 1.23 -> optimized trend_len=30/weight=0.199 Sharpe 1.08) — the classic curve-fit signature, and the chosen trend_len=30 sits on the edge of the search bound.

The entire 2-parameter sensitivity surface is flat and sub-floor (~0.70-1.09 Sharpe everywhere vs the 1.5 promotion floor), so there is no robust region a second iteration could tune toward.

Big-drawdown crypto beta: max_drawdown 40.9% (>10% floor), win_rate 0.24, worst stress window china_ban_2021 -27.0% / 35.4% DD, max_consecutive_losses 17.

Whole family precedent is negative: every near-sibling (dual-momentum rotation fee_edge, vol-managed long/flat overfit, static 60/30/10 other, monthly TS-momentum timer overfit, ETH/BTC ratio overfit) was abandoned.

The run is not a valid full-history test: entry_diag reports primary_bars_received=112 with waiting_on_extra_legs=2404 (bars_processed=3306), and every populated return bucket sits in Sep-Dec 2020. The book appears gated on ALL three sleeves being present/warmed before it will trade, so once SOL's data starts (2020-08) evaluation effectively stalls and only ~112 primary bars ever produce decisions (7 trades vs the ~15-25 you estimated). This contradicts the hypothesis's own 'independent sleeves' premise. FIX: make each sleeve trade as soon as IT alone has trend_len+1 of its own closes, and mark/idle any sleeve whose data hasn't started yet (SOL) without blocking BTC/ETH — so BTC and ETH evaluate from 2017/2018 and SOL joins in 2020. Book value should be computed over whatever sleeves currently have data. Re-run and confirm you get the full 2017/2020-2026 span with trades spread across multiple years/regimes before this is worth 2h of optimization.

Benjamini-Hochberg at q=0.10 over 232 programme candidates keeps 3. A candidate that does not survive here is not distinguishable from the programme's own noise, however good its individual statistics look.

SpotBtcLongFlatTrendOverlaySingleSleeve

Verification failed (Layer 4 — QA review) [class=hypothesis_mismatch]: - [edge_concern] As a standalone single-BTC book, the sandbox is mostly long-BTC beta, not the diversified overlay the hypothesis proposes: benchmark_correlation 0.707, beta 0.484, and the +1039% return / Sharpe 1.06 largely tracks BTC buy-and-hold with a trend filter (annualized alpha 0.21 is real but modest, IR -0.10). Secondary to the alignment issue, but it underlines that a single sleeve is a materially different (concentrated) risk profile from the 3-asset diversified book, so this sandbox cannot stand in for the hypothesis's thesis. - INSTRUMENT MISMATCH. The hypothesis is explicitly a MULTI-INSTRUMENT, 3-sleeve fixed-weight book on BTC/ETH/SOL held SIMULTANEOUSLY ('deliberately NOT a single-position book'), with cross-asset diversification as a named risk pillar. The code trades ONLY BTCUSDT.BINANCE_SPOT — extra_instruments empty, ETH and SOL removed, class renamed ...SingleSleeve. Per checklist item 1, the hypothesis's asset set (BTC/ETH/SOL) must equal the config/code asset set; two of three are missing and the defining multi-sleeve/diversification structure is absent. The artifact implements one sleeve of the hypothesis, not the hypothesis. - The developer's iteration-1 diagnosis appears correct: collapsing to a single instrument produced a sane equity curve (+1039%, DD 37.5%, vol 40.9%) where the multi-instrument version reported impossible values (+22,716% single-day, 5,839% DD, 58,000% vol), confirming a genuine engine artifact in multi-leg CASH-spot equity aggregation. The full hypothesis cannot be validly backtested until that is fixed. Infra/engine limitation (not data-coverage not_measurable, not this code being wrong) — flagged for engineering.

sandbox_timeout: Verification failed (Layer 3 — sandbox backtest): smoke test exceeded the 300s wall-clock limit on a ~20000-bar window (2400 days of BTCUSDT.BINANCE_SPOT-1-DAY-LAST-EXTERNAL). This almost always means per-bar work that scales with history — e.g. rescanning the full funding/supplementary series, or rebuilding a list and calling min()/sorted() inside calculate_signal()/on_bar() on every bar. Precompute sorted timestamp arrays ONCE in __init__ and use bisect, or cache lookups keyed by timestamp, so per-bar cost is O(log n) not O(n).