release: v0.13.0

docs/gpu-derived-series-plan.md

@@ -0,0 +1,152 @@
+# Plan — Séries dérivées hoistées sur GPU (« option C ») (2026-07-17)
+
+Objectif : permettre aux ops fenêtrées du transpileur (`ZScore`, `RollingMean`,
+`Rsi`, `Roc`, futurs `RollingStd/Sum/...`) de prendre une **expression** en
+entrée, pas seulement une colonne brute — ce qui débloque l'exemple 16
+(`zscore(price_ratio - hr_ratio, zwin)`) et toute la famille « indicateur d'un
+spread/ratio » sur GPU.
+
+## Le problème (analysé le 2026-07-17, voir la discussion du rapport)
+
+Le kernel évalue en **streaming** : les intermédiaires vivent une barre dans des
+registres. Une op fenêtrée doit évincer la valeur qui sort de la fenêtre
+(`sum -= x[jj-w]`) : pour une colonne (`CCOL`) ou une série hoistée (`HIND`)
+c'est un accès mémoire ; pour une expression dérivée, la valeur d'il y a `w`
+barres a été jetée. Le CPU n'a pas ce problème : son évaluateur matérialise
+chaque nœud du DAG en array.
+
+Seul `EwmMean` accepte une expression aujourd'hui — une EMA ne regarde jamais
+en arrière. `RollingMean`, `Rsi`, `ZScore` exigent tous une colonne brute ;
+cette limite est **préexistante et structurelle**, pas un choix de mon ZScore.
+
+## Le design
+
+**Matérialiser l'expression d'entrée comme lignes `hind` supplémentaires**,
+dédupliquées par résolution de paramètres, remplies par un kernel généré ; l'op
+fenêtrée reste un **fold in-thread** (par combo) qui lit la ligne dérivée en
+accès aléatoire (`HINDAT(j, jj)` / `HINDAT(j, jj-w)`).
+
+```
+stage 1  hoist_fill    : indicateurs feuilles (SMA/EMA/RSI/ROC/ZScore sur colonnes)
+stage 2  derived_fill  : expressions POINTWISE sur (cols ∪ lignes stage 1)   ← NOUVEAU
+sim      sweep_t       : folds fenêtrés in-thread lisant les lignes dérivées ← ÉTENDU
+```
+
+Décisions clés :
+
+- **Éligibilité** : l'entrée doit être pointwise sur (colonnes brutes ∪ feuilles
+  hoistables ∪ littéraux ∪ params). Sinon → CPU, raison nommée (Phase 0 style) :
+  « windowed op over a non-pointwise expression ».
+- **Dédup** : clé = empreinte structurelle de l'expression + bits résolus de
+  CHAQUE param référencé (vecteur, pas un seul u64 — une expression peut lire
+  plusieurs params). Même mécanique HashMap que `build_hoist_plan`. Nombre de
+  lignes = résolutions distinctes de l'ENTRÉE (ex. 16 : #smooth distincts, PAS
+  #(smooth × zwin) — la fenêtre reste par combo, in-thread). C'est ce qui rend
+  la VRAM raisonnable à 1M combos.
+- **`derived_fill` est un kernel GÉNÉRÉ** (comme `sweep_t`), pas un kernel fixe :
+  le corps pointwise vient du MÊME `PipeCtx::emit` que le sim (mêmes sémantiques
+  NaN, division-par-zéro → NaN, etc. — zéro seconde implémentation qui dérive).
+  Pointwise ⇒ barres indépendantes ⇒ un thread par (ligne, barre), coalescé,
+  ~1 ms pour 1000 lignes × 44k barres. Lancé entre hoist_fill et sweep_t.
+- **Chaînage limité en V1** : dérivé = pointwise uniquement. Un fenêtré DANS un
+  fenêtré sur expression (`zscore(sma(expr))`) → CPU, raison nommée. (Extensible
+  plus tard en étages topologiques ; hors périmètre V1.)
+- **Folds in-thread** : sémantique `*_no_nulls` de bt-expr AU COMPLET, y compris
+  `nan_count` — voir P0 ci-dessous. État ZScore in-thread ≈ 4-6 registres.
+- **fp32 scan** : lignes dérivées calculées en f64, stockées f32 en mode scan
+  (même argument que le float-hind de la Part 5 : identique au cast côté
+  lecteur).
+- **Garde VRAM** : bytes(hind + derived) > free/2 → CPU, raison nommée.
+- **Multi-asset** : hors V1 (comme l'exo), raison nommée.
+
+## Bit-identité (la chaîne de preuve)
+
+CPU : matérialise l'entrée (array) puis `zscore_no_nulls(vals)`. GPU : la ligne
+dérivée doit être **bit-identique à l'array CPU** (mêmes ops pointwise dans le
+même ordre via le même emit(), fmad off, mêmes sources : cols identiques,
+lignes stage-1 déjà pinnées à bt-expr) ; puis le fold in-thread refait
+exactement `zscore_no_nulls` sur les mêmes valeurs. Chaque maillon testé.
+
+## Étapes
+
+### P0 — Bug latent découvert par l'analyse (à faire AVANT tout)
+Le fold SMA **in-thread** (`ss += CCOL(...)`, chemin non-hoisté = multi-asset)
+n'a AUCUNE gestion NaN, alors que `rolling_mean_pair` (bt-expr) exclut les NaN
+de ses sommes (`bad_a`/`bad_b`). Divergence silencieuse sur données à trous en
+multi-asset — même famille que `804de5e`, invisible parce que les tests NaN
+tournent en mono (hoisting actif) et que le e2e multi n'a pas de NaN.
+- Auditer les 3 folds in-thread (SMA / RSI / ROC) contre bt-expr sur NaN.
+- Test : e2e multi avec NaN closes (étendre `gpu_sweep_multi_e2e`), vérifier
+  qu'il MORD (rituel du bug délibéré), corriger les folds.
+- Estimation : ½ journée. Indépendant de C mais bloquant : les folds dérivés
+  réutiliseront ce code.
+
+### P1 — Enregistrement des lignes dérivées (host)
+- `PipeCtx` : détection d'éligibilité (fn `is_pointwise_over_leaves`),
+  empreinte, `derived_slot(expr) -> dj`, table `derived: Vec<DerivedSpec>`.
+- `build_hoist_plan` étendu : résolution par combo des params de chaque
+  expression dérivée, dédup, `hrow` étendu aux lignes dérivées, garde VRAM.
+
+### P2 — Kernel `derived_fill` généré + wiring
+- Génération du source (corps par ligne via emit(), switch sur le kind de
+  ligne), compile NVRTC (cache par hash), launch stage 2, slot dans
+  `MBT_GPU_PROBE`.
+- `ptxas -v` sur le kernel généré (attendu trivial : pointwise, pas d'état).
+
+### P3 — Folds in-thread sur lignes dérivées
+- Macro `HINDAT(j, idx)` (HIND à index arbitraire).
+- `ZScore` d'abord (débloque ex. 16), puis `RollingMean`, `Rsi`, `Roc` :
+  entrée Column → chemins existants ; entrée dérivée-éligible → fold in-thread
+  avec sémantique bt-expr complète.
+- **GATE ptxas** : le sim est à 48/48 registres. Si le fold in-thread fait
+  spiller, relâcher `__launch_bounds__` UNIQUEMENT pour les sources générées qui
+  contiennent des folds in-thread (le bound est par source générée, donc par
+  sweep) — mesurer, pas supposer.
+
+### P4 — Tests (chaque test vérifié MORDANT via bug délibéré)
+- `derived_fill_matches_bt_expr` : ligne dérivée vs array intermédiaire bt-expr,
+  barre par barre, NaN gaps inclus (harnais `hoist_fill_matches_bt_expr` étendu).
+- Fold in-thread vs bt-expr : zscore(expr) complet, barre par barre.
+- e2e forme exemple 16 (exo + spread + zscore, périodes en params) :
+  bit-identité CPU==GPU + non-vacuité + appel direct `run_sweep_lite_gpu`
+  (une retombée = échec, pas une comparaison CPU-vs-CPU silencieuse).
+- Retombées nommées : non-pointwise, fenêtré imbriqué, VRAM, multi-asset.
+
+### P5 — Bench + rapport
+- Exemple 16 réel (hashrate), grille ~10k : cible GPU >> CPU (aujourd'hui :
+  2 589 c/s CPU, GPU retombe). Section dans `gpu_funding_bench.md`.
+- Mettre à jour `docs/gpu-sweep-coverage-plan.md` (la Phase 2b absorbe C).
+
+## Estimation & risques
+
+| | |
+|---|---|
+| P0 | ½ j (correction comprise si le bug se confirme) |
+| P1+P2 | ~1 j |
+| P3 | ½ j + gate registres |
+| P4+P5 | ½ j |
+| **Total** | **~2-2,5 jours** |
+
+Risques : (1) pression registres des folds in-thread — gate ptxas, bounds par
+source ; (2) explosion du nombre de lignes dérivées si une expression référence
+plusieurs params à forte cardinalité — garde VRAM + retombée nommée ; (3) toute
+divergence NaN — couverte par les tests barre-par-barre ancrés bt-expr, jamais
+par des miroirs.
+
+---
+
+## STATUT : LIVRÉ (2026-07-17)
+
+- P0 : fold SMA in-thread corrigé (bad-count miroir de `rolling`), RSI/ROC
+  audités conformes ; e2e `gpu_multi_sma_nan_volume_{2,5}` vérifié mordant.
+- P1-P2 : `DerivedReg`/`derived_slot`, plan étendu (dédup multi-params, hrow
+  absolu, garde VRAM sur le total), `derived_fill` généré par le même emit
+  (macros remappées), `hoist_fill` a un stride explicite.
+- P3 : fold ZScore in-thread sur ligne dérivée via `HINDAT` ; GATE ptxas :
+  bounds relâchés à 7 (f64) / 8 (fp32) blocs pour les sources à folds, zéro
+  spill ; fold-free inchangé (48 regs @10).
+- P4 : `derived_fill_matches_bt_expr` (mord sur +1e-12 que l'e2e ne voit pas),
+  e2e bit-identité + retombée nommée fenêtré-imbriqué.
+- P5 : exemple 16 réel, 102x à 30k combos, Part 11 du rapport.
+- Reste (hors V1, repris en Phase 2b) : `RollingMean`/`Rsi`/`Roc` sur entrée
+  dérivée (mécanique identique au ZScore), multi-asset, chaînage fenêtré.

docs/gpu-sweep-coverage-plan.md

@@ -0,0 +1,242 @@
+# Plan — Couverture GPU du sweep (2026-07-17)
+
+Contexte : le sweep GPU fait 300k combos/s (fp64 bit-identique) / 676k (fp32 scan),
+mais seules les stratégies dans un périmètre étroit en profitent. Tout le reste
+retombe sur le CPU (~1-20k combos/s) **en silence**. Ce plan séquence l'élargissement
+du périmètre, du moins cher au plus cher, avec un gate data-driven au milieu.
+
+État de départ : PR #74 (18 commits GPU) en attente de merge ; branche
+`perf/python-metrics-extraction` (3 commits : dicts directs, `sweep_columns`,
+fix du pool VRAM) prête. Les phases ci-dessous partent au-dessus.
+
+Log de mesures : `gpu_funding_bench.md`. Toute nouvelle phase y ajoute sa section.
+
+---
+
+## Les trois couches qui bloquent une stratégie
+
+1. **Ops transpileur manquants** : `Eq, Lag, Lead, RollingStd, RollingSum,
+   RollingMin, RollingMax, Scan` (→ Kalman et tout indicateur à état custom).
+2. **Périmètre fast-path** (11 conditions) : la plus coûteuse est probablement
+   `orders.is_empty()` — **toute stratégie avec SL/TP retombe**. Aussi :
+   AtClose only, FixedBps only, frais mono-venue, pas de borrow rate, etc.
+3. **Garde-fous sweep** : MTF, exogène, multi-source, cross-sectionnel,
+   funding multi-asset.
+
+Tri technique de la couche 3 : funding multi = ~15 lignes (terme déjà écrit pour
+le mono) ; exogène = ~30 lignes (l'exo est ASOF-joint sur la grille de barres au
+chargement → colonne ordinaire pour le kernel) ; cross-sectionnel = moyen (le
+kernel multi a déjà tous les symboles dans le thread, restructuration en 2
+passes) ; MTF = moyen-lourd ; multi-source = lourd.
+
+---
+
+## Phase 0 — Rendre la retombée visible (≈1 h) — À FAIRE EN PREMIER
+
+**Problème** : `run_sweep_lite(device="cuda")` retombe en silence. L'utilisateur
+paie Pro, voit 12k combos/s, ne saura jamais que retirer son SL/TP le rendrait
+25x plus rapide. Et nous, on priorise les phases suivantes à l'aveugle.
+
+**Livrable**
+- La raison de retombée (déjà construite : `gpu-sweep-unsupported: <raison>`)
+  remonte à l'utilisateur : `warnings.warn` une fois par sweep, et champ
+  `profile["gpu_fallback_reason"]` sur les résultats.
+- Les raisons sont des chaînes stables (elles le sont déjà) → agrégeables plus
+  tard en télémétrie si souhaité.
+
+**Validation** : sweep avec SL/TP → warning avec la raison exacte ; sweep GPU
+nominal → aucun warning, champ absent ; e2e inchangés.
+
+**Gate de décision** : après quelques jours d'usage réel (et un tour des
+exemples/notebooks), la fréquence des raisons décide l'ordre des phases 2-4.
+Sans données, l'ordre ci-dessous est notre meilleure estimation.
+
+---
+
+## Phase 1 — Quick wins périmètre (≈½ journée)
+
+### 1a. Funding multi-asset dans `sweep_t_multi` (~15 lignes)
+Le terme funding est déjà dans `sweep_t` (mono) : `capital += -position * close
+* rate` par barre, par symbole ici. Retirer le garde-fou
+`"multi-asset funding not yet on the GPU kernel"`.
+- **Validation** : colonne funding synthétique injectée, e2e multi bit-identique
+  CPU==GPU (même harnais que le fix funding mono).
+
+### 1b. Colonnes exogènes dans le sweep GPU (~30 lignes)
+`load_exo_columns` ASOF-joint déjà l'exo sur `master_timestamps` → un
+`Float64Array` de `num_bars`, indistinguable de `close` pour le kernel. Étendre
+la résolution des `col_names` du transpileur aux colonnes exo alignées, retirer
+`!config.exo_data.is_empty()` du garde-fou (garder `exo_sources`/multi-source
+exclus).
+- **Validation** : e2e avec exo synthétique bit-identique CPU==GPU ; l'exemple
+  `16_hashrate_exogene.py` passe sur GPU ; NaN de tête d'ASOF (avant le premier
+  point exo) couverts par le test.
+- **Attention** : chemin multi-asset — un exo est global (pas par symbole), le
+  layout `cols [n_cols][n_sym][num_bars]` duplique par symbole ou garde-fou
+  multi+exo conservé en V1.
+
+---
+
+## Phase 2 — Ops transpileur faciles (≈½ journée) — **FAIT 2026-07-17**
+
+**Livré** : ZScore/RollingStd/RollingSum/RollingMean/Rsi/Roc sur colonne OU
+expression pointwise (séries dérivées), Eq, RollingMin/Max (hoistés, rescan
+exact), scan sans param → colonne hôte. **Refusé avec raison nommée** :
+Lag/Lead — mur sémantique null-vs-NaN (le CPU garde la position sur cible
+null, le kernel n'a qu'un encodage) ; il faudrait un canal de validité.
+Détails : Part 14 du rapport.
+
+`ZScore`, `RollingStd`, `Eq`, `Lag`, `Lead`, `RollingSum`, `RollingMin`, `RollingMax`.
+
+Débloque : Bollinger (rolling_std), breakouts (rolling_max/min), signaux à
+retard (lag), et retire un pan de retombées silencieuses.
+
+**`ZScore` en tête de liste** : mesuré 2026-07-17, c'est ce qui bloque
+`examples/16_hashrate_exogene.py` (la Phase 1b a débloqué son exo, mais il bute
+maintenant sur `indicator ZScore is not supported`). ZScore est une op à part
+entière dans bt-expr, pas un `rolling_std` déguisé — je l'avais manquée dans
+l'inventaire initial ; c'est le warning de la Phase 0 qui l'a nommée.
+
+**Mise à jour 2026-07-17 (suite)** : ZScore-sur-colonne est livré (`d883edd`),
+mais l'exemple 16 fait `zscore(EXPRESSION)` et retombe encore : TOUTES les ops
+fenêtrées du transpileur exigent une colonne brute (limite structurelle
+préexistante — l'éviction `sum -= x[jj-w]` exige un accès aléatoire que le
+streaming n'a pas ; seule l'EMA, sans regard arrière, accepte une expression).
+Le correctif structurel est le **plan « séries dérivées »** :
+[`gpu-derived-series-plan.md`](gpu-derived-series-plan.md) (~2-2,5 j, P0 = bug
+NaN latent des folds in-thread multi-asset découvert par l'analyse).
+
+**Mise à jour 2026-07-17 (fin de journée) : plan séries dérivées LIVRÉ
+(P0-P5).** Le bug NaN du fold SMA in-thread est corrigé (e2e multi NaN-volume,
+rouge-puis-vert), et `zscore(EXPRESSION)` tourne sur GPU : l'entrée pointwise
+est matérialisée en lignes dérivées (kernel `derived_fill` généré par le même
+emit), le fold z-score lit la ligne via `HINDAT` in-thread. Exemple 16 réel :
+**102x** à 30k combos (0.43 s vs 43.6 s CPU), bit-identique. Rapport : Part 11
+de `gpu_funding_bench.md`. Reste de la Phase 2 : brancher `RollingMean`/`Rsi`/
+`Roc` sur le même chemin dérivé, puis les ops manquantes ci-dessus.
+
+**Trou distinct découvert au passage** : une stratégie SANS périodes dynamiques
+part dans `transpile_sizing` (pointwise uniquement) et meurt sur le premier
+`EwmMean`, bien avant le pipeline. L'exemple 16 tel quel tombe là-dessus. Peu
+grave pour un sweep (on paramètre les fenêtres, donc on passe par
+`transpile_pipeline`), mais à garder en tête pour `run_batch`.
+
+**Règles héritées de la campagne (non négociables)**
+- Chaque fold miroir **bt-expr op-pour-op**, y compris NaN : le bug des folds
+  NaN (Part 5) venait exactement d'un miroir non ancré au moteur.
+  Pièges connus : `Eq` = `(a-b).abs() < f64::EPSILON` (pas `==`) ;
+  `RollingStd` : même formule de Welford/somme que bt-expr, même fenêtre sale.
+- Tests de parité **contre bt-expr** (pattern `gpu_fold_nan_gaps_*`), jamais
+  contre un miroir du même algorithme.
+- Hoisting : chaque nouveau kind hoistable rejoint `hoist_fill` (kind + period),
+  sinon état par thread via `state_decls` — attention au **cap 48 registres**
+  (ptxas -v systématique, la table des résultats négatifs Parts 4-5 fait foi).
+
+---
+
+## Phase 3 — `scan` sur GPU → Kalman — **FAIT 2026-07-17**
+
+**Livré** : gate 3a passé (bande Kalman dépliée + fold = 94 regs, zéro
+spill) ; `lower_scan_tape` extrait dans bt-expr (une bande, deux exécuteurs) ;
+traduction 1:1 ScanOp→CUDA (Eq EPSILON du VM répliqué, ≠ du == array) ;
+`derived_fill` séquentiel par ligne → fenêtré-sur-scan-sweepé OK (dédup par
+bits résolus) ; fix param()-dans-scan (has_dynamic_periods + collecteur
+Python). Surface (q,w) 1M réelle : 25.8 s. Refus nommés : log/exp, inits
+non-pointwise, colonnes à nulls. Phase 5 (dispatch auto) : device="auto",
+seuil mesuré 1k combos, Part 15.
+
+## Phase 3 (plan d'origine, conservé pour référence)
+
+### 3a. Sonde registres (30 min, GATE)
+Écrire À LA MAIN le kernel Kalman (bande ScanOp dépliée en CUDA), `ptxas -v`
+sm_86. Le kernel sim est à 48/48 registres **zéro marge** : si la bande scan
+spille, le gain s'évapore → **stop, on documente, on ne construit pas le
+générateur**.
+
+### 3b. Générateur ScanOp → CUDA
+La bande `CompiledScan.instructions` est en SSA plat (24 opcodes scalaires) →
+traduction mécanique, 1 ligne CUDA par opcode, branchée sur
+`state_decls`/`state_init`/`body` existants.
+Sémantiques à mirrorer exactement (source de vérité : `evaluator.rs`) :
+- `Div` : dénominateur `== 0.0` → **NaN** (pas l'inf IEEE)
+- `Eq` : `(a-b).abs() < f64::EPSILON`
+- init : `prev_state[i] = init_arr.value(0)`, null → `0.0`
+- ordre d'exécution : registre = pointeur d'instruction, writeback après output
+
+### 3c. `param()` dans un nœud scan (bug indépendant, petit)
+`CompiledScan.param_names` existe déjà ; c'est la **découverte des paramètres de
+stratégie** qui ne descend pas dans les nœuds scan ("uses undefined parameters:
+q"). Fix côté validation/collecte → débloque le sweep de `q` (la dimension la
+plus intéressante du filtre), même sur CPU.
+
+### 3d. Acceptance
+- Parité GPU vs VM bt-expr bit-identique, NaN gaps inclus.
+- e2e sweep Kalman CPU==GPU bit-identique.
+- **La heatmap 1M Kalman (w×en, puis q×en) sur GPU** — l'objectif d'origine.
+  Budget attendu : quelques secondes au lieu de 15 min CPU.
+- fp32 : vérifier le ranking (le scan ajoute des Div/Sqrt → sensibilité à
+  mesurer, pas à supposer).
+
+---
+
+## Phase 4 — SL/TP sur le fast path GPU (gros ; décision APRÈS Phase 0)
+
+`orders.is_empty()` est probablement le garde-fou le plus coûteux en usage réel
+(hypothèse à confirmer par les données de la Phase 0). Résolution intra-bar
+SL/TP = high/low + sémantique de priorité déjà fixée à la 0.12.0 côté lite CPU.
+Design séparé — ne pas commencer avant d'avoir les données de fréquence et le
+merge des phases précédentes.
+
+## Phase 5 — Dispatch GPU/CPU (à faire À LA FIN)
+
+**Mesuré 2026-07-17** : sur une grille de 100 combos, le GPU est **6x plus LENT**
+que le CPU (882 vs 5 327 combos/s) — les coûts fixes (upload, launch, hoist,
+compile) écrasent le gain. À 6 000 combos le GPU gagne 7x. Il existe donc un
+seuil de rentabilité, et aujourd'hui l'utilisateur qui passe `device="cuda"` sur
+une petite grille **paie pour être ralenti, sans rien qui le prévienne**.
+
+Deux options, à trancher le moment venu :
+1. **Bascule automatique** sous un seuil (attention : `device="cuda"` explicite
+   qui exécute sur CPU, c'est exactement le genre de magie silencieuse que la
+   Phase 0 vient de supprimer — il faudrait le dire).
+2. **Warning symétrique** : « grille trop petite pour amortir le GPU (N combos,
+   seuil ~M) », et laisser l'utilisateur décider.
+
+Le seuil dépend de num_bars, n_sym et de la complexité du pipeline : à calibrer
+par mesure, pas à coder en dur (cf. [[feedback_portability_first]] : pas de
+seuil spécifique à une machine). Placé en fin de plan volontairement : c'est du
+polish, les phases 1-3 débloquent des stratégies entières.
+
+## Phase 6 — Backlog (ordre selon Phase 0)
+
+- Cross-sectionnel dans `sweep_t_multi` (2 ops, restructuration 2 passes).
+- Exo en multi-asset (broadcast de la série globale dans chaque slab symbole).
+- MTF (grilles multiples, mapping d'index par timeframe).
+- Multi-source / cross-exchange (chemin général, lourd).
+- Frais par venue, borrow rate, AtOpen (extensions du fast path).
+- `transpile_sizing` (chemin sans params) limité au pointwise → bloque `run_batch`
+  sur toute stratégie à indicateurs.
+
+---
+
+## Invariants transverses (toutes phases)
+
+1. **Bit-identité fp64 CPU==GPU** : chaque phase ajoute ses cas au harnais e2e
+   (`to_bits` par métrique). Les checksums 21-métriques du bench servent de
+   non-régression (`14fabff006fda0a0` fp64 / `c1be6db787e2f49f` fp32 sur la
+   grille de référence).
+2. **Parité ancrée à bt-expr**, jamais à un miroir (leçon Part 5).
+3. **ptxas -v à chaque changement de kernel** (cap 48 regs, spills interdits).
+4. **Un garde-fou ne se retire qu'avec le test qui prouve le remplacement.**
+5. **Chaque phase = sa branche + sa PR + sa section dans le bench log.**
+   Livraison incrémentale, pas de méga-branche de 18 commits une deuxième fois.
+
+## Estimation d'ensemble
+
+| Phase | Effort | Gain |
+|---|---|---|
+| 0 — retombée visible | ~1 h | priorisation data-driven + UX Pro |
+| 1 — funding multi + exo | ~½ j | 2 familles débloquées, quasi sans risque |
+| 2 — 7 ops faciles | ~½ j | Bollinger/breakout/lag sur GPU |
+| 3 — scan → Kalman | 1-2 j (gate 30 min) | la stratégie de l'article sur GPU + échappatoire universel |
+| 4 — SL/TP | gros | à chiffrer après Phase 0 |