khadhroony-bobobot/docs/prompts/PROMPT_0_7_54_PUMP_FUN.md

Prompt de reprise — khadhroony-bobobot 0.7.54 — pump_fun

Tu reprends le workspace Rust/Tauri khadhroony-bobobot après clôture documentaire et fonctionnelle de 0.7.53 pump_swap.

1. Fichiers à utiliser comme base

Je fournis l’archive la plus récente du workspace, intégrant normalement les deltas de clôture 0.7.53.

À considérer comme sources locales de savoir :

• le code Rust du workspace ;
• les fichiers Markdown (README.md, ROADMAP.md, CHANGELOG.md, docs/**) ;
• les SQL de validation dans validation_sql/** ;
• le répertoire idls/**, ajouté au projet, contenant des IDL JSON téléchargés depuis Solscan ;
• les liens Git/upstream déjà documentés dans les docs ;
• les résultats SQL/logs que je colle dans la conversation.

Ne pas supposer que les docs sont parfaites : les vérifier contre le code et contre les IDL locales.

2. État validé avant cette version

La version 0.7.53 a fermé pump_swap côté transaction/log decoder :

• cargo test -p kb_lib : 421 passed;
• cargo clippy -p kb_lib --all-targets -- -D warnings : OK ;
• pump_swap.buy, pump_swap.sell, pump_swap.buy_exact_quote_in matérialisent correctement les trades ;
• buy_exact_quote_in utilise pump_swap_anchor_buy_event quand l’Anchor BuyEvent exact est disponible ;
• les *_event Anchor PumpSwap sont décodés en audit-only sauf exception métier explicite ;
• claim_token_incentives_event est prêt à matérialiser k_sol_reward_events si un event réussi apparaît ;
• pump_swap ne présente plus de decoded event sans coverage, ni fallback upstream résiduel, ni trade candidate réussi non matérialisé ;
• les surfaces Raydium déjà travaillées (raydium_amm_v4, raydium_clmm, raydium_cpmm) ne doivent pas être rouvertes sauf bug prouvé ;
• les petits gaps Meteora sont volontairement différés.

Ne pas modifier PumpSwap ou Raydium sauf preuve SQL/code claire d’une régression.

3. Objectif de la version 0.7.54

Objectif principal : ouvrir et avancer une tranche pump_fun.

Cette tranche doit traiter la surface launch/mint Pump.fun, qui est logiquement prioritaire avant pump_fees.

Le backlog global montre des entrées pump_fun encore en fallback upstream, notamment :

• pump_fun.collect_creator_fee / discriminator 1416567bc61cdb84 ;
• pump_fun.migrate_bonding_curve_creator / 577c34bf3426d6e8 ;
• pump_fun.distribute_creator_fees / a572670079cef751 ;
• pump_fun.admin_set_creator / 4519ab8e39ef0d04 ;
• pump_fun.extend_account / ea66c2cb96483ee5 ;
• pump_fun.set_creator / fe94ff70cf8eaaa5 ;
• pump_fun.migrate / 9beae792ec9ea21e ;
• pump_fun.claim_cashback / 253a237ebe35e4c5 ;
• pump_fun.sell / 33e685a4017f83ad ;
• autres discriminators pump_fun observés dans k_sol_instruction_observations.

L’objectif n’est pas seulement de faire disparaître un fallback : il faut couvrir proprement la surface pump_fun :

• registry/coverage ;
• decoder local ou statut local explicitement decoded-only/audit-only ;
• matérialisation métier si les données sont fiables ;
• tests unitaires ;
• SQL de validation ;
• documentation.

4. Périmètre

Inclus

• pump_fun launch/mint/bonding-curve surface ;
• instructions/events liés à création/migration/configuration/creator fees/cashback si présents dans IDL ou corpus ;
• intégration coverage ;
• matérialisation vers tables métier seulement si fiable.

Hors périmètre sauf nécessité démontrée

• pump_swap, déjà fermé en 0.7.53 ;
• raydium_*, sauf régression prouvée ;
• meteora_*, volontairement différé ;
• jupiter_swap, dflow_aggregator_v4, onchain_labs_dex_v2, orca_whirlpools, backlog futur ;
• pump_fees, qui doit venir après pump_fun, probablement en 0.7.55.

5. Méthode obligatoire

5.1 Nouvelle base SQLite

Créer une nouvelle DB dédiée à 0.7.54, ne pas travailler sur l’ancienne DB de validation PumpSwap.

Démarrage attendu :

• catalog initial propre ou connu ;
• backfills ciblés ;
• replay forcé ;
• validation SQL.

5.2 Backfill de corpus

Construire un corpus local à partir de :

1. filtres Solscan.io quand disponibles ;
2. Demo3 discovery quand nécessaire ;
3. batch backfill de groupes de signatures ;
4. program/signature backfill si pertinent ;
5. signatures issues des requêtes SQL sample_signature.

Utiliser d’abord les signatures fortes observées dans le backlog :

• pump_fun.collect_creator_fee;
• pump_fun.migrate_bonding_curve_creator;
• pump_fun.distribute_creator_fees;
• pump_fun.admin_set_creator;
• pump_fun.extend_account;
• pump_fun.set_creator;
• pump_fun.migrate;
• pump_fun.claim_cashback;
• puis autres discriminators observés.

Après chaque groupe de backfill :

• replay local avec skipDexDecode=no;
• utiliser forceDexDecode=yes quand le decoder/coverage change ;
• deferInstructionObservations=yes ;
• rafraîchir catalog ;
• relancer les SQL de surveillance.

5.3 Sources

Utiliser en priorité :

• idls/** local ;
• code existant ;
• docs existantes ;
• upstream_registry_generated.rs ;
• sources Git déjà référencées dans les docs ;
• Solscan signatures/logs ;
• payloads locaux DB.

Si une IDL locale contredit une source Git, signaler la divergence et ne pas inventer.

6. Contraintes de code Rust

Respecter strictement les conventions du projet :

• Rust 2024 ;
• pas de ? ;
• pas de unwrap() / expect() en code applicatif ;
• pas de anyhow / thiserror ;
• match / if let Err explicites ;
• async-first ;
• tracing obligatoire ;
• pas de mod.rs ;
• pas de pub mod ; utiliser mod + pub use ;
• imports limités, types appelés de façon qualifiée quand c’est la convention locale ;
• tests offline ;
• ne pas casser #![deny(unreachable_pub)] et #![warn(missing_docs)].

Si des requêtes DB sont ajoutées ou déplacées, penser aux re-exports :

• kb_lib/src/db.rs ;
• kb_lib/src/lib.rs.

7. Matérialisation attendue

Pour pump_fun, ne pas forcer une matérialisation si les montants/acteurs/comptes ne sont pas prouvés.

Classer explicitement chaque entrée :

• k_sol_launch_events pour les événements de launch/mint/migration ;
• k_sol_fee_events si l’instruction représente réellement des frais exploitables ;
• k_sol_pool_admin_events si c’est de la configuration/admin/creator ;
• k_sol_reward_events uniquement si c’est réellement une récompense/incitation/cashback fiable ;
• k_sol_dex_decoded_events_only si audit-only ou données insuffisantes ;
• k_sol_trade_events seulement si c’est un swap/trade fiable ;
• skip*Reason explicite quand non matérialisable.

Ne jamais matérialiser une transaction failed comme business event.

8. SQL de validation à utiliser

Utiliser et adapter :

• validation_sql/SQL_VALIDATION_DEX_COVERAGE_GLOBAL_0_7_53.sql;
• les SQL de validation PumpSwap comme modèle ;
• une nouvelle validation dédiée à pump_fun, par exemple :
  • validation_sql/SQL_VALIDATION_PUMP_FUN_0_7_54.sql.

Requêtes minimales attendues :

1. coverage pump_fun ;
2. instruction observations pump_fun ;
3. decoded events pump_fun sans coverage ;
4. fallback upstream pump_fun résiduel ;
5. successful non-materialized events sans skip reason ;
6. failed tx materialization safety ;
7. multi-target materialization safety ;
8. materialization summary ;
9. comparaison entre k_sol_instruction_observations et k_sol_dex_event_coverage_entries ;
10. global watchlist après replay.

9. Invariants de validation

Après correction, viser :

• pas de pump_fun decoded event local sans coverage ;
• pas de fallback upstream_git résiduel pour les entrées pump_fun couvertes localement ;
• pas de materialized business event sur failed transaction ;
• pas de multi-target incohérent ;
• tous les events/instructions observés ont :
  • un decoder local,
  • ou un statut audit-only,
  • ou un skip reason explicite,
  • ou une justification documentée s’ils restent upstream-only.

10. Documentation à mettre à jour

À la fin de la tranche, mettre à jour :

• CHANGELOG.md : une ligne ;
• README.md : état courant, nouvelle version, validation ;
• ROADMAP.md : phasage et clôture/état de pump_fun, puis annonce de pump_fees en version suivante ;
• docs/DEX_DECODER_MATRIX.md ;
• docs/DEX_EVENT_COVERAGE_MATRIX.md ;
• éventuellement un rapport :
  • docs/reports/PUMP_FUN_EVENT_COVERAGE_REPORT.md.

Ne pas gonfler les docs inutilement : noter les faits validés, les limites, et les prochaines tranches.

11. Format de livraison attendu

Ne pas fournir une archive complète du workspace sauf demande explicite.

Fournir un delta zip contenant uniquement les fichiers modifiés/ajoutés.

Nom recommandé :

khadhroony-bobobot-v0.7.54-pump_fun-delta-N-files.zip

Chaque réponse de livraison doit inclure :

• résumé des changements ;
• liste exacte des fichiers modifiés ;
• commandes à lancer :
  • cargo fmt
  • cargo test -p kb_lib
  • cargo clippy -p kb_lib --all-targets -- -D warnings
• replay recommandé ;
• SQL à exécuter ;
• ce qui est attendu dans les résultats.

12. Priorités si plusieurs gaps apparaissent

Ordre de priorité :

1. pump_fun ;
2. pump_fees seulement si strictement nécessaire pour comprendre un flux pump_fun ;
3. ne pas traiter Meteora dans cette version ;
4. ne pas rouvrir Raydium sauf régression démontrée ;
5. ne pas ouvrir Jupiter/dFlow/onchain_labs dans cette tranche sauf pour les classer en backlog.

13. Première tâche demandée

Commencer par analyser l’archive fournie :

1. identifier les fichiers existants liés à pump_fun, pump_fees, upstream registry, coverage, materialization ;
2. chercher dans idls/** s’il existe une IDL Solscan liée à pump_fun ;
3. produire un état des lieux court :
   • entrées upstream disponibles ;
   • entrées observées dans SQL/logs fournis ;
   • fichiers à modifier ;
   • hypothèse de classification par entry ;
   • SQL initial de backfill/validation ;
4. proposer puis produire le premier delta archive minimal.