0.7.41

ROADMAP.md

@@ -981,21 +981,23 @@ Décision : `0.7.40` est clos. `Demo3` et Demo Pipeline 2 suffisent pour constit
 ### 6.073. Version `0.7.41` — Raydium AMM v4 swap decoder v1
 Objectif : ajouter un premier décodeur fiable pour les swaps Raydium AMM v4 observés dans le corpus constitué avec Demo3 et Demo Pipeline 2.
 
-À faire :
+Réalisé :
 
-- créer ou compléter le décodeur `raydium_amm_v4` pour les instructions de swap AMM v4 ;
-- traiter explicitement les inner instructions dont `program_id = 675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8`, notamment lorsqu’elles sont appelées via Jupiter ou un autre routeur top-level ;
-- conserver dans le payload décodé les informations de routage utiles : `routeSource`, `topLevelProgram`, `innerInstruction`, `instructionIndex`, `innerInstructionIndex` ;
-- extraire les comptes selon le layout observé lorsque le format est compatible : token program, pool/state candidat, authority, vault A, vault B, comptes intermédiaires, comptes utilisateur ;
-- utiliser les deltas SPL Token et/ou les transferts inner instruction-scoped pour dériver les montants `base_amount_raw` et `quote_amount_raw` ;
-- marquer `eventActionability = trade_candidate` seulement si les montants et les mints sont exploitables ;
-- classer en `non_actionable_trade` les swaps ou routes dont les montants sont absents, ambigus, multi-hop non isolables ou issus de transactions failed ;
-- matérialiser `trade_events`, metrics et candles uniquement pour les transactions OK avec payload de montants exploitable ;
-- matérialiser ou mettre à jour pools/paires/listings uniquement lorsque les comptes permettent un rattachement fiable ;
-- ajouter des tests de non-régression sur les signatures et patterns Raydium AMM v4 observés localement ;
-- maintenir `blockingIssueCount = 0`, `actionableMissingTradeEventCount = 0`, `missingTradeEventCount = 0` après replay/validation.
+- ajout du décodeur `raydium_amm_v4.swap` pour les instructions de swap AMM v4 ;
+- prise en charge des inner instructions dont `program_id = 675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8`, notamment lorsqu’elles sont appelées via Jupiter ou un autre routeur top-level ;
+- conservation dans le payload décodé des informations de routage utiles : `routeSource`, programme parent, `innerInstruction`, `instructionIndex`, `innerInstructionIndex` et comptes complets ;
+- extraction des comptes selon les layouts observés : token program, pool/state, authority, vault A, vault B, comptes intermédiaires et comptes utilisateur lorsque disponibles ;
+- dérivation des mints et montants via deltas SPL Token et transferts instruction-scoped, avec refus des cas sans payload exploitable ;
+- production de `eventActionability = trade_candidate` uniquement lorsque les mints et montants sont exploitables ;
+- matérialisation des pools, paires, listings, `trade_events`, metrics et candles uniquement pour les transactions OK ;
+- maintien des transactions failed comme traçables mais sans `trade_events`, metrics ni candles ;
+- ajout du profil `0.7.41_raydium_amm_v4_swap_decoder` dans la validation locale et dans Demo Pipeline 2 ;
+- mise à jour de la matrice DEX : `raydium_amm_v4` passe en `observed = true`, `status = supported`, `confidence = high`, sans `skipReason` ;
+- validation locale confirmée avec `validationPassed = true`, `blockingIssueCount = 0`, `warningCount = 0`, `actionableMissingTradeEventCount = 0`, `missingTradeEventCount = 0`, `decodedTradeCandidateWithoutAmountPayloadCount = 0` et `invalidTradeEventCount = 0`.
 
-Corpus de travail initial : comptes candidats tels que `48yaEzz1JSHoghWYg3RGE31srN66ubfPgm4Wc5556YTG`, `SJmR8rJgzzCi4sPjGnrNsqY4akQb3jn5nsxZBhyEifC`, `EMFHrMra2GepQK9KtkQ9C65zxqdDCpQM2uKySPyNEFDA`, `58oQChx4yWmvKdwLLZzBi4ChoCc2fqCUWBkwMihLYQo2`, et les signatures associées issues de Demo3.
+Résultat de corpus validé : `raydium_amm_v4` produit 58 decoded events, 58 trade candidates, 58 trade events, 11 pools/paires et 147 candles sur la base de test Raydium AMM v4. Les routes Jupiter ou routeurs top-level restent annotées comme sources de route, tandis que le decoded event métier est attribué au DEX effectif `raydium_amm_v4`.
+
+Décision : `0.7.41` est clos. La suite immédiate est `0.7.42_raydium_family_consolidation` afin de verrouiller ensemble `raydium_cpmm`, `raydium_clmm`, `raydium_amm_v4` et les surfaces Raydium non encore matérialisées.
 
 ### 6.074. Version `0.7.42` — Raydium effectif : famille Raydium consolidée
 Objectif : consolider la famille Raydium après le premier décodeur AMM v4.
@@ -1270,30 +1272,30 @@ Le projet doit maintenir au minimum :
 
 ## 12. Priorité immédiate
 
-La priorité immédiate après `0.7.40` est `0.7.41_raydium_amm_v4_swap_decoder_v1`. `Demo3` et le backfill par signature donnent maintenant assez de corpus on-chain pour travailler sur Raydium AMM v4 sans inventer de layout ni promouvoir de faux pool.
+La priorité immédiate après `0.7.41` est `0.7.42_raydium_family_consolidation`. `raydium_amm_v4.swap` v1 est maintenant validé sur corpus réel, avec trades/candles matérialisés et aucun warning de validation. La suite doit verrouiller la famille Raydium complète avant de passer aux autres DEX effectifs.
 
-Préconditions validées avant `0.7.41` :
+Préconditions validées avant `0.7.42` :
 
 1. validation `0.7.36` acquise : Meteora consolidé, transactions failed traçables mais non actionnables, swaps sans amounts classés `non_actionable_trade`, aucun diagnostic bloquant masqué ;
 2. validation `0.7.37` acquise : compteurs metadata/catalog exposés, backfill metadata idempotent, `pair_symbol` rafraîchissables, metadata manquantes non bloquantes ;
 3. validation `0.7.38` acquise : `tokenMetadataGapSamples` priorisés, Demo Pipeline 2 raccordé, `validationPassed = true`, `blockingIssueCount = 0`, registre local `WSOL`/`USDC`/`USDT`/`JUP`/`RAY`/`BONK` disponible ;
 4. validation `0.7.39` acquise : matrice DEX-first, suppression de l’alias `raydium`, `metaDAO` et `Printr` en `to_verify`, aucun `program_id` fictif ;
 5. validation `0.7.40` acquise : `Demo3` découvre on-chain des signatures, mints, deltas et comptes candidats ; Demo Pipeline 2 peut backfiller une signature précise ; les instructions Raydium AMM v4 sont persistées en base ;
-6. aucune transaction failed ne doit alimenter `trade_events`, metrics ou candles ;
-7. aucun decoded event AMM v4 ne doit être promu `trade_candidate` sans montants exploitables.
+6. validation `0.7.41` acquise : `raydium_amm_v4.swap` décode les inner instructions `675kPX...`, produit des trades/candles lorsque les montants sont exploitables, et conserve les transactions failed sans matérialisation marché ;
+7. aucune transaction failed ne doit alimenter `trade_events`, metrics ou candles ;
+8. aucun decoded event ne doit être promu `trade_candidate` sans montants exploitables.
 
-Ordre de travail recommandé pour `0.7.41+` :
+Ordre de travail recommandé pour `0.7.42+` :
 
-1. implémenter `raydium_amm_v4.swap` v1 à partir du corpus local : instructions internes `675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8`, comptes, `data_json`, deltas SPL Token et routes Jupiter ;
-2. distinguer `routeSource` / routeur top-level et DEX effectif : une transaction Jupiter peut contenir un leg Raydium AMM v4, mais le decoded event métier doit rester attribué au DEX effectif ;
-3. matérialiser trades/candles uniquement pour transactions OK et montants fiables ;
-4. conserver les swaps ambigus ou multi-hop non isolables en `non_actionable_trade` ;
-5. consolider ensuite la famille Raydium (`cpmm`, `clmm`, `amm_v4`, `stable_swap`, router et launch surfaces reportées) ;
-6. reprendre Meteora, Orca, FluxBeam, DexLab, metaDAO et Printr avec la même approche corpus-first ;
-7. décaler `Demo4` après la première consolidation Raydium AMM v4, car la découverte on-chain locale suffit pour la suite immédiate ;
-8. ajouter ensuite `Demo10` pour le watcher WebSocket live DEX avec start/stop, subscribe/unsubscribe et écriture en base via le pipeline existant ;
-9. reprendre seulement après cela les launch surfaces spécialisées ;
-10. passer ensuite à la couche wallet : création de wallet/keypair, inspection et transfert de fonds vers un autre account.
+1. consolider ensemble `raydium_cpmm`, `raydium_clmm` et `raydium_amm_v4` comme surfaces Raydium effectives supportées ;
+2. ajouter des diagnostics Raydium par surface : decoded events, trades, candles, route sources, pools, pairs, comptes pool/state, vaults et mints ;
+3. vérifier que `raydium_router` reste un `aggregator_router` non matérialisé comme DEX direct ;
+4. garder `raydium_stable_swap`, `raydium_launchlab` et `raydium_launchpad` en surfaces non matérialisées tant qu’un corpus dédié ne prouve pas leur exploitation ;
+5. reprendre Meteora, Orca, FluxBeam, DexLab, metaDAO et Printr avec la même approche corpus-first ;
+6. décaler `Demo4` après la consolidation Raydium, car la découverte on-chain locale suffit pour la suite immédiate ;
+7. ajouter ensuite `Demo10` pour le watcher WebSocket live DEX avec start/stop, subscribe/unsubscribe et écriture en base via le pipeline existant ;
+8. reprendre seulement après cela les launch surfaces spécialisées ;
+9. passer ensuite à la couche wallet : création de wallet/keypair, inspection et transfert de fonds vers un autre account.
 
 Garde-fous constants :