0.7.57
This commit is contained in:
245
docs/prompts/PROMPT_0_7_58_DEMO4_PROGRAM_SURFACE_DISCOVERY.md
Normal file
245
docs/prompts/PROMPT_0_7_58_DEMO4_PROGRAM_SURFACE_DISCOVERY.md
Normal file
@@ -0,0 +1,245 @@
|
||||
<!-- file: docs/prompts/prompt_name_0_7_58_demo4_program_surface_discovery.md -->
|
||||
|
||||
# Prompt — 0.7.58 Demo4 Program Surface Discovery
|
||||
|
||||
## Contexte
|
||||
|
||||
Nous reprenons le workspace Rust/Tauri `khadhroony-bobobot` après la clôture de `0.7.57 meteora_dlmm`.
|
||||
|
||||
État validé :
|
||||
|
||||
```text
|
||||
0.7.57 meteora_dlmm clos
|
||||
cargo test -p kb_lib -> 460 passed
|
||||
cargo clippy -p kb_lib --all-targets -- -D warnings -> OK
|
||||
replay -> 769 replayed, 106 trades, 664 liquidity, 1107 lifecycle, 424 candles
|
||||
instructionObservations = 8062
|
||||
catalogue = 169 tokens / 218 pools / 218 pairs
|
||||
```
|
||||
|
||||
Contraintes projet à respecter :
|
||||
|
||||
- Rust 2024.
|
||||
- Code async-first.
|
||||
- Pas de `?`, `unwrap`, `expect` dans le code applicatif.
|
||||
- Pas de `anyhow`, pas de `thiserror`.
|
||||
- Pas de `mod.rs`.
|
||||
- Pas de `pub mod` ; utiliser `mod` privé + `pub use`.
|
||||
- Imports uniquement pour les traits quand c’est possible.
|
||||
- `#![deny(unreachable_pub)]` et `#![warn(missing_docs)]` doivent rester propres.
|
||||
- Tests offline.
|
||||
- Les nouvelles requêtes DB doivent mettre à jour les re-exports dans `kb_lib/src/db.rs` puis `kb_lib/src/lib.rs`.
|
||||
- Les structs DB doivent aller dans `kb_lib/src/db/entities/*.rs` et `kb_lib/src/db/dtos/*.rs`, pas dans les fichiers de requêtes.
|
||||
|
||||
## Objectif
|
||||
|
||||
Ajouter `Demo4` dans `kb_demo_app` et les fonctions de lecture associées dans `kb_lib` pour afficher les surfaces de programmes non encore prises en compte par le système.
|
||||
|
||||
Cette fonctionnalité est strictement un cockpit de découverte et de revue.
|
||||
|
||||
Elle ne doit pas :
|
||||
|
||||
- matérialiser automatiquement des contenus inconnus ;
|
||||
- promouvoir automatiquement des discriminators inconnus dans les décodeurs officiels ;
|
||||
- marquer automatiquement un `program_id` comme supporté ;
|
||||
- créer automatiquement des lignes `trade`, `candle`, `fee`, `liquidity`, `reward`, `admin` ou `orderbook` depuis un contenu inconnu.
|
||||
|
||||
Elle doit :
|
||||
|
||||
- afficher les surfaces inconnues ou non supportées ;
|
||||
- les regrouper de manière exploitable ;
|
||||
- montrer les preuves et signatures samples ;
|
||||
- aider à produire des prompts/patchs futurs validés manuellement.
|
||||
|
||||
## Comportement attendu côté utilisateur
|
||||
|
||||
Créer une nouvelle page ou fenêtre, selon le pattern existant :
|
||||
|
||||
```text
|
||||
kb_demo_app/src/demo4.html
|
||||
kb_demo_app/src/demo4.ts
|
||||
```
|
||||
|
||||
ou l’équivalent si l’application utilise un autre routage.
|
||||
|
||||
Demo4 doit proposer des vues pour :
|
||||
|
||||
1. discriminators inconnus sur des decoders connus ;
|
||||
2. `program_id` connus contenant des instructions non mappées par le decoder spécialisé ;
|
||||
3. `upstream_git.instruction_match` groupés par `upstreamDecoderCode`, `upstreamEntryName`, `upstreamDiscriminatorHex` ;
|
||||
4. `program_id` observés dans les transactions mais absents de la matrice de support ;
|
||||
5. logs Anchor `Program log: Instruction: ...` non mappés localement ;
|
||||
6. events Anchor `Program data:` non mappés localement ;
|
||||
7. layouts de comptes récurrents sur instructions inconnues ;
|
||||
8. répartition success/failed pour chaque surface candidate.
|
||||
|
||||
Filtres souhaités :
|
||||
|
||||
```text
|
||||
program_id
|
||||
candidate_decoder_code
|
||||
discriminator_hex
|
||||
instruction_name / nom log Anchor
|
||||
upstream decoder
|
||||
upstream entry name
|
||||
success only / failed only / both
|
||||
minimum observation count
|
||||
minimum tx count
|
||||
from slot / to slot
|
||||
signature contains
|
||||
show only unknown
|
||||
show only upstream fallback
|
||||
show only high-confidence candidates
|
||||
```
|
||||
|
||||
Colonnes souhaitées :
|
||||
|
||||
```text
|
||||
candidate_kind
|
||||
program_id
|
||||
candidate_decoder
|
||||
known/unknown status
|
||||
discriminator_hex
|
||||
log_instruction_name
|
||||
anchor_event_discriminator
|
||||
account_count
|
||||
layout_hash
|
||||
observed_count
|
||||
tx_count
|
||||
success_count
|
||||
failed_count
|
||||
first_slot
|
||||
last_slot
|
||||
sample_signature
|
||||
confidence_score
|
||||
confidence_reason
|
||||
status
|
||||
```
|
||||
|
||||
Le panneau de détail doit afficher :
|
||||
|
||||
```text
|
||||
sample signatures
|
||||
accounts_json
|
||||
data_json / data prefix
|
||||
logs de transaction
|
||||
inner instructions
|
||||
parsed_json si disponible
|
||||
decoded_payload_json si disponible
|
||||
entrées upstream registry correspondantes
|
||||
preuve de hash Anchor si un nom d’instruction est disponible
|
||||
```
|
||||
|
||||
## Design `kb_lib`
|
||||
|
||||
Ajouter des requêtes read-only et des DTOs. Fichiers suggérés :
|
||||
|
||||
```text
|
||||
kb_lib/src/program_surface_discovery.rs
|
||||
kb_lib/src/db/dtos/program_surface_candidate_summary.rs
|
||||
kb_lib/src/db/dtos/program_surface_candidate_sample.rs
|
||||
kb_lib/src/db/queries/program_surface_discovery.rs
|
||||
```
|
||||
|
||||
Si un statut persistant est nécessaire, ajouter :
|
||||
|
||||
```text
|
||||
kb_lib/src/db/entities/program_surface_candidate.rs
|
||||
kb_lib/src/db/queries/program_surface_candidates.rs
|
||||
```
|
||||
|
||||
Ne pas placer les DTO/entities dans les fichiers de requêtes.
|
||||
|
||||
Statuts candidats suggérés :
|
||||
|
||||
```text
|
||||
new
|
||||
reviewed
|
||||
accepted
|
||||
rejected
|
||||
promoted
|
||||
ignored
|
||||
```
|
||||
|
||||
Si une table persistante est ajoutée, la migration doit être explicite, idempotente et testée.
|
||||
|
||||
## Scoring de découverte
|
||||
|
||||
Le scoring est indicatif uniquement. Il ne doit jamais déclencher une matérialisation.
|
||||
|
||||
Signaux de confiance possibles :
|
||||
|
||||
| Signal | Effet |
|
||||
|---|---:|
|
||||
| `program_id` connu, discriminator inconnu | +20 |
|
||||
| log Anchor `Instruction: X` trouvé | +30 |
|
||||
| `sha256("global:x")` correspond au discriminator | +50 |
|
||||
| observations success répétées | +10 |
|
||||
| account count/layout stable | +10 |
|
||||
| inner instruction family cohérente avec l’action | +10 |
|
||||
| uniquement des transactions failed | -20 |
|
||||
| nom très générique comme `swap`, `claim`, `initialize` sans autre preuve | -15 |
|
||||
| `program_id` inconnu et observation unique | -25 |
|
||||
|
||||
## Helper Anchor
|
||||
|
||||
Ajouter un helper qui normalise les noms d’instructions Anchor depuis les logs :
|
||||
|
||||
```text
|
||||
Program log: Instruction: InitializePresetParameterV2
|
||||
-> initialize_preset_parameter_v2
|
||||
-> sha256("global:initialize_preset_parameter_v2")[0..8]
|
||||
```
|
||||
|
||||
Ce helper doit seulement produire une preuve/candidate record. Il ne doit pas modifier les mappings de decoder.
|
||||
|
||||
## Export Markdown
|
||||
|
||||
Demo4 doit permettre d’exporter un groupe candidat en Markdown pour une future session d’implémentation.
|
||||
|
||||
L’export doit inclure :
|
||||
|
||||
```text
|
||||
candidate decoder
|
||||
program_id
|
||||
discriminator_hex
|
||||
candidate name
|
||||
confidence score
|
||||
preuves/evidence
|
||||
sample signatures
|
||||
account layout
|
||||
logs
|
||||
inner instruction summary
|
||||
proposed target table éventuelle
|
||||
warning explicite : non implémenté, non matérialisé
|
||||
```
|
||||
|
||||
## Tests
|
||||
|
||||
Ajouter des tests offline pour :
|
||||
|
||||
- normalisation des noms Anchor depuis logs ;
|
||||
- calcul de discriminators Anchor pour des noms samples ;
|
||||
- groupement par program/discriminator/layout ;
|
||||
- ordre de score ;
|
||||
- sérialisation/désérialisation des DTOs si utilisés ;
|
||||
- validation des paramètres de commandes UI.
|
||||
|
||||
Aucun test ne doit dépendre de RPC ou du réseau.
|
||||
|
||||
## Validation
|
||||
|
||||
```bash
|
||||
cargo fmt
|
||||
cargo test -p kb_lib program_surface
|
||||
cargo test -p kb_lib
|
||||
cargo clippy -p kb_lib --all-targets -- -D warnings
|
||||
```
|
||||
|
||||
Pour Tauri/frontend, lancer la commande de build/test existante du projet si elle existe.
|
||||
|
||||
## Résultat attendu
|
||||
|
||||
L’utilisateur peut ouvrir Demo4 et voir immédiatement les surfaces unsupported/upstream/unknown présentes dans la base SQLite courante, sans rescanner la blockchain.
|
||||
|
||||
Demo4 est un cockpit de découverte uniquement. Il ne change pas la matérialisation métier.
|
||||
245
docs/prompts/PROMPT_0_7_58_demo4_program_surface_discovery.md
Normal file
245
docs/prompts/PROMPT_0_7_58_demo4_program_surface_discovery.md
Normal file
@@ -0,0 +1,245 @@
|
||||
<!-- file: docs/prompts/PROMPT_0_7_58_demo4_program_surface_discovery.md -->
|
||||
|
||||
# Prompt — 0.7.58 Demo4 Program Surface Discovery
|
||||
|
||||
## Contexte
|
||||
|
||||
Nous reprenons le workspace Rust/Tauri `khadhroony-bobobot` après la clôture de `0.7.57 meteora_dlmm`.
|
||||
|
||||
État validé :
|
||||
|
||||
```text
|
||||
0.7.57 meteora_dlmm clos
|
||||
cargo test -p kb_lib -> 460 passed
|
||||
cargo clippy -p kb_lib --all-targets -- -D warnings -> OK
|
||||
replay -> 769 replayed, 106 trades, 664 liquidity, 1107 lifecycle, 424 candles
|
||||
instructionObservations = 8062
|
||||
catalogue = 169 tokens / 218 pools / 218 pairs
|
||||
```
|
||||
|
||||
Contraintes projet à respecter :
|
||||
|
||||
- Rust 2024.
|
||||
- Code async-first.
|
||||
- Pas de `?`, `unwrap`, `expect` dans le code applicatif.
|
||||
- Pas de `anyhow`, pas de `thiserror`.
|
||||
- Pas de `mod.rs`.
|
||||
- Pas de `pub mod` ; utiliser `mod` privé + `pub use`.
|
||||
- Imports uniquement pour les traits quand c’est possible.
|
||||
- `#![deny(unreachable_pub)]` et `#![warn(missing_docs)]` doivent rester propres.
|
||||
- Tests offline.
|
||||
- Les nouvelles requêtes DB doivent mettre à jour les re-exports dans `kb_lib/src/db.rs` puis `kb_lib/src/lib.rs`.
|
||||
- Les structs DB doivent aller dans `kb_lib/src/db/entities/*.rs` et `kb_lib/src/db/dtos/*.rs`, pas dans les fichiers de requêtes.
|
||||
|
||||
## Objectif
|
||||
|
||||
Ajouter `Demo4` dans `kb_demo_app` et les fonctions de lecture associées dans `kb_lib` pour afficher les surfaces de programmes non encore prises en compte par le système.
|
||||
|
||||
Cette fonctionnalité est strictement un cockpit de découverte et de revue.
|
||||
|
||||
Elle ne doit pas :
|
||||
|
||||
- matérialiser automatiquement des contenus inconnus ;
|
||||
- promouvoir automatiquement des discriminators inconnus dans les décodeurs officiels ;
|
||||
- marquer automatiquement un `program_id` comme supporté ;
|
||||
- créer automatiquement des lignes `trade`, `candle`, `fee`, `liquidity`, `reward`, `admin` ou `orderbook` depuis un contenu inconnu.
|
||||
|
||||
Elle doit :
|
||||
|
||||
- afficher les surfaces inconnues ou non supportées ;
|
||||
- les regrouper de manière exploitable ;
|
||||
- montrer les preuves et signatures samples ;
|
||||
- aider à produire des prompts/patchs futurs validés manuellement.
|
||||
|
||||
## Comportement attendu côté utilisateur
|
||||
|
||||
Créer une nouvelle page ou fenêtre, selon le pattern existant :
|
||||
|
||||
```text
|
||||
kb_demo_app/src/demo4.html
|
||||
kb_demo_app/src/demo4.ts
|
||||
```
|
||||
|
||||
ou l’équivalent si l’application utilise un autre routage.
|
||||
|
||||
Demo4 doit proposer des vues pour :
|
||||
|
||||
1. discriminators inconnus sur des decoders connus ;
|
||||
2. `program_id` connus contenant des instructions non mappées par le decoder spécialisé ;
|
||||
3. `upstream_git.instruction_match` groupés par `upstreamDecoderCode`, `upstreamEntryName`, `upstreamDiscriminatorHex` ;
|
||||
4. `program_id` observés dans les transactions mais absents de la matrice de support ;
|
||||
5. logs Anchor `Program log: Instruction: ...` non mappés localement ;
|
||||
6. events Anchor `Program data:` non mappés localement ;
|
||||
7. layouts de comptes récurrents sur instructions inconnues ;
|
||||
8. répartition success/failed pour chaque surface candidate.
|
||||
|
||||
Filtres souhaités :
|
||||
|
||||
```text
|
||||
program_id
|
||||
candidate_decoder_code
|
||||
discriminator_hex
|
||||
instruction_name / nom log Anchor
|
||||
upstream decoder
|
||||
upstream entry name
|
||||
success only / failed only / both
|
||||
minimum observation count
|
||||
minimum tx count
|
||||
from slot / to slot
|
||||
signature contains
|
||||
show only unknown
|
||||
show only upstream fallback
|
||||
show only high-confidence candidates
|
||||
```
|
||||
|
||||
Colonnes souhaitées :
|
||||
|
||||
```text
|
||||
candidate_kind
|
||||
program_id
|
||||
candidate_decoder
|
||||
known/unknown status
|
||||
discriminator_hex
|
||||
log_instruction_name
|
||||
anchor_event_discriminator
|
||||
account_count
|
||||
layout_hash
|
||||
observed_count
|
||||
tx_count
|
||||
success_count
|
||||
failed_count
|
||||
first_slot
|
||||
last_slot
|
||||
sample_signature
|
||||
confidence_score
|
||||
confidence_reason
|
||||
status
|
||||
```
|
||||
|
||||
Le panneau de détail doit afficher :
|
||||
|
||||
```text
|
||||
sample signatures
|
||||
accounts_json
|
||||
data_json / data prefix
|
||||
logs de transaction
|
||||
inner instructions
|
||||
parsed_json si disponible
|
||||
decoded_payload_json si disponible
|
||||
entrées upstream registry correspondantes
|
||||
preuve de hash Anchor si un nom d’instruction est disponible
|
||||
```
|
||||
|
||||
## Design `kb_lib`
|
||||
|
||||
Ajouter des requêtes read-only et des DTOs. Fichiers suggérés :
|
||||
|
||||
```text
|
||||
kb_lib/src/program_surface_discovery.rs
|
||||
kb_lib/src/db/dtos/program_surface_candidate_summary.rs
|
||||
kb_lib/src/db/dtos/program_surface_candidate_sample.rs
|
||||
kb_lib/src/db/queries/program_surface_discovery.rs
|
||||
```
|
||||
|
||||
Si un statut persistant est nécessaire, ajouter :
|
||||
|
||||
```text
|
||||
kb_lib/src/db/entities/program_surface_candidate.rs
|
||||
kb_lib/src/db/queries/program_surface_candidates.rs
|
||||
```
|
||||
|
||||
Ne pas placer les DTO/entities dans les fichiers de requêtes.
|
||||
|
||||
Statuts candidats suggérés :
|
||||
|
||||
```text
|
||||
new
|
||||
reviewed
|
||||
accepted
|
||||
rejected
|
||||
promoted
|
||||
ignored
|
||||
```
|
||||
|
||||
Si une table persistante est ajoutée, la migration doit être explicite, idempotente et testée.
|
||||
|
||||
## Scoring de découverte
|
||||
|
||||
Le scoring est indicatif uniquement. Il ne doit jamais déclencher une matérialisation.
|
||||
|
||||
Signaux de confiance possibles :
|
||||
|
||||
| Signal | Effet |
|
||||
|---|---:|
|
||||
| `program_id` connu, discriminator inconnu | +20 |
|
||||
| log Anchor `Instruction: X` trouvé | +30 |
|
||||
| `sha256("global:x")` correspond au discriminator | +50 |
|
||||
| observations success répétées | +10 |
|
||||
| account count/layout stable | +10 |
|
||||
| inner instruction family cohérente avec l’action | +10 |
|
||||
| uniquement des transactions failed | -20 |
|
||||
| nom très générique comme `swap`, `claim`, `initialize` sans autre preuve | -15 |
|
||||
| `program_id` inconnu et observation unique | -25 |
|
||||
|
||||
## Helper Anchor
|
||||
|
||||
Ajouter un helper qui normalise les noms d’instructions Anchor depuis les logs :
|
||||
|
||||
```text
|
||||
Program log: Instruction: InitializePresetParameterV2
|
||||
-> initialize_preset_parameter_v2
|
||||
-> sha256("global:initialize_preset_parameter_v2")[0..8]
|
||||
```
|
||||
|
||||
Ce helper doit seulement produire une preuve/candidate record. Il ne doit pas modifier les mappings de decoder.
|
||||
|
||||
## Export Markdown
|
||||
|
||||
Demo4 doit permettre d’exporter un groupe candidat en Markdown pour une future session d’implémentation.
|
||||
|
||||
L’export doit inclure :
|
||||
|
||||
```text
|
||||
candidate decoder
|
||||
program_id
|
||||
discriminator_hex
|
||||
candidate name
|
||||
confidence score
|
||||
preuves/evidence
|
||||
sample signatures
|
||||
account layout
|
||||
logs
|
||||
inner instruction summary
|
||||
proposed target table éventuelle
|
||||
warning explicite : non implémenté, non matérialisé
|
||||
```
|
||||
|
||||
## Tests
|
||||
|
||||
Ajouter des tests offline pour :
|
||||
|
||||
- normalisation des noms Anchor depuis logs ;
|
||||
- calcul de discriminators Anchor pour des noms samples ;
|
||||
- groupement par program/discriminator/layout ;
|
||||
- ordre de score ;
|
||||
- sérialisation/désérialisation des DTOs si utilisés ;
|
||||
- validation des paramètres de commandes UI.
|
||||
|
||||
Aucun test ne doit dépendre de RPC ou du réseau.
|
||||
|
||||
## Validation
|
||||
|
||||
```bash
|
||||
cargo fmt
|
||||
cargo test -p kb_lib program_surface
|
||||
cargo test -p kb_lib
|
||||
cargo clippy -p kb_lib --all-targets -- -D warnings
|
||||
```
|
||||
|
||||
Pour Tauri/frontend, lancer la commande de build/test existante du projet si elle existe.
|
||||
|
||||
## Résultat attendu
|
||||
|
||||
L’utilisateur peut ouvrir Demo4 et voir immédiatement les surfaces unsupported/upstream/unknown présentes dans la base SQLite courante, sans rescanner la blockchain.
|
||||
|
||||
Demo4 est un cockpit de découverte uniquement. Il ne change pas la matérialisation métier.
|
||||
@@ -0,0 +1,249 @@
|
||||
<!-- file: docs/prompts/prompt_name_0_7_59_sqlite_db_transaction_merger_binary.md -->
|
||||
|
||||
# Prompt — 0.7.59 Binaire de fusion de bases SQLite transactionnelles
|
||||
|
||||
## Contexte
|
||||
|
||||
Nous reprenons le workspace Rust `khadhroony-bobobot` après la clôture de `0.7.57 meteora_dlmm` et après/ou en parallèle de `0.7.58 demo4_program_surface_discovery`.
|
||||
|
||||
L’utilisateur possède plusieurs bases SQLite dédiées construites pendant les tranches Raydium, Pump et Meteora. L’objectif est d’éviter de rescanner/backfiller des signatures déjà présentes dans ces bases.
|
||||
|
||||
## Objectif
|
||||
|
||||
Ajouter un module binaire qui utilise `kb_lib` pour fusionner des données de corpus transactionnel depuis plusieurs fichiers SQLite `.db` vers une base SQLite de sortie unique.
|
||||
|
||||
Le merger doit copier suffisamment de données brutes transaction/instruction pour permettre un replay local dans la base consolidée, sans refaire les appels RPC.
|
||||
|
||||
Ce binaire est un outil de consolidation de corpus. Ce n’est pas un scanner blockchain.
|
||||
|
||||
## Forme recommandée
|
||||
|
||||
Créer un nouveau package workspace :
|
||||
|
||||
```text
|
||||
kb_tools/
|
||||
Cargo.toml
|
||||
src/bin/kb_db_merge.rs
|
||||
```
|
||||
|
||||
Le binaire doit dépendre de `kb_lib` et réutiliser autant que possible les fonctions de schéma/setup/query existantes.
|
||||
|
||||
Alternative acceptable si le workspace préfère ce pattern :
|
||||
|
||||
```text
|
||||
kb_lib/src/bin/kb_db_merge.rs
|
||||
```
|
||||
|
||||
Préférer `kb_tools` si cela évite de mélanger du code CLI-only dans `kb_lib`.
|
||||
|
||||
## Interface CLI
|
||||
|
||||
Commande suggérée :
|
||||
|
||||
```bash
|
||||
cargo run -p kb_tools --bin kb_db_merge -- \
|
||||
--output ./merged_corpus.db \
|
||||
--input ./raydium.db \
|
||||
--input ./pump.db \
|
||||
--input ./meteora.db \
|
||||
--mode raw-corpus \
|
||||
--dry-run
|
||||
```
|
||||
|
||||
Options requises ou utiles :
|
||||
|
||||
```text
|
||||
--output <path>
|
||||
--input <path> répétable
|
||||
--mode <mode>
|
||||
--dry-run optionnel
|
||||
--replace-output optionnel ; sinon refuser si output existe
|
||||
--source-label optionnel ou inféré depuis le nom de fichier
|
||||
--limit optionnel pour tests
|
||||
```
|
||||
|
||||
Modes initiaux :
|
||||
|
||||
```text
|
||||
raw-corpus
|
||||
full-copy-safe
|
||||
signatures-only
|
||||
```
|
||||
|
||||
## Mode `raw-corpus`
|
||||
|
||||
Mode par défaut recommandé.
|
||||
|
||||
Copier les données brutes canonique nécessaires au replay local sans RPC :
|
||||
|
||||
```text
|
||||
k_sol_chain_transactions
|
||||
k_sol_chain_instructions
|
||||
```
|
||||
|
||||
Si le schéma contient d’autres tables brutes/contextuelles strictement nécessaires, les inspecter avant de les ajouter. Ne copier que les tables sûres, sans duplication sémantique.
|
||||
|
||||
La base output doit ensuite pouvoir exécuter le replay/décodage local depuis les transactions persistées.
|
||||
|
||||
## Mode `full-copy-safe`
|
||||
|
||||
Mode optionnel pour plus tard.
|
||||
|
||||
Copier aussi des lignes décodées/matérialisées seulement si les foreign keys, versions de decoder et versions de schéma sont cohérentes.
|
||||
|
||||
Ne pas l’implémenter comme mode par défaut. Il est plus dangereux car les lignes matérialisées dépendent de la version du code.
|
||||
|
||||
## Mode `signatures-only`
|
||||
|
||||
Copier uniquement les signatures/slots dans une table de staging afin qu’un outil futur décide quoi importer/rejouer.
|
||||
|
||||
## Politique de déduplication
|
||||
|
||||
Identité primaire :
|
||||
|
||||
```text
|
||||
signature
|
||||
```
|
||||
|
||||
Règles :
|
||||
|
||||
- Une même signature dans plusieurs inputs doit produire une seule transaction dans l’output.
|
||||
- Si `meta_json`, `transaction_json`, `slot` ou `err_json` diffèrent pour une même signature, enregistrer un conflit ; ne pas écraser silencieusement.
|
||||
- Préférer la ligne brute la plus complète uniquement si le conflit est explicable et journalisé.
|
||||
- Conserver la provenance dans des tables d’audit de merge.
|
||||
|
||||
Tables suggérées :
|
||||
|
||||
```text
|
||||
k_sol_db_merge_sources
|
||||
k_sol_db_merge_transactions
|
||||
k_sol_db_merge_conflicts
|
||||
```
|
||||
|
||||
Champs source suggérés :
|
||||
|
||||
```text
|
||||
source_id
|
||||
source_path
|
||||
source_label
|
||||
source_schema_version
|
||||
source_created_at
|
||||
input_transaction_count
|
||||
copied_transaction_count
|
||||
skipped_duplicate_count
|
||||
conflict_count
|
||||
```
|
||||
|
||||
Pour chaque signature copiée :
|
||||
|
||||
```text
|
||||
signature
|
||||
slot
|
||||
source_id
|
||||
source_transaction_id
|
||||
copied_at
|
||||
copy_status
|
||||
conflict_status
|
||||
```
|
||||
|
||||
## Règles de sécurité
|
||||
|
||||
- Ne pas appeler RPC.
|
||||
- Ne pas backfiller.
|
||||
- Ne pas décoder DEX pendant le merge.
|
||||
- Ne pas matérialiser trades/candles pendant le merge.
|
||||
- Ne pas supposer une compatibilité de schéma sans inspection.
|
||||
- Ne pas utiliser `ATTACH` avec des chemins non validés/échappés.
|
||||
- Pas de `?`, `unwrap`, `expect` dans le code applicatif.
|
||||
- Les erreurs doivent être explicites, typées projet, et lisibles.
|
||||
- Le mode dry-run doit indiquer exactement ce qui serait copié, ignoré ou marqué conflictuel.
|
||||
|
||||
## Compatibilité de schéma
|
||||
|
||||
Le binaire doit inspecter `sqlite_master` et `PRAGMA table_info(...)` dans chaque DB input.
|
||||
|
||||
Tables requises pour `raw-corpus` :
|
||||
|
||||
```text
|
||||
k_sol_chain_transactions
|
||||
k_sol_chain_instructions
|
||||
```
|
||||
|
||||
Vérifier les colonnes requises par nom. Si une colonne optionnelle manque, l’indiquer clairement et continuer seulement si la copie reste suffisante pour un replay local fiable.
|
||||
|
||||
Si le schéma est incompatible, échouer proprement avec un résumé court.
|
||||
|
||||
## Stratégie de copie
|
||||
|
||||
Algorithme recommandé :
|
||||
|
||||
1. Ouvrir/créer la base output et initialiser le schéma courant via `kb_lib`.
|
||||
2. Pour chaque input DB :
|
||||
- inspecter le schéma ;
|
||||
- enregistrer la source ;
|
||||
- itérer les transactions par slot/signature ;
|
||||
- si la signature est absente de l’output, insérer la transaction et ses instructions enfants ;
|
||||
- si la signature existe, comparer les champs canoniques et ignorer ou enregistrer un conflit ;
|
||||
- préserver le mapping `source_transaction_id -> output_transaction_id` pour les instructions.
|
||||
3. Commit par batches.
|
||||
4. Imprimer un résumé final.
|
||||
|
||||
La taille de batch doit être configurable ou conservatrice.
|
||||
|
||||
## SQL de validation
|
||||
|
||||
Ajouter :
|
||||
|
||||
```text
|
||||
validation_sql/SQL_VALIDATION_DB_MERGE_0_7_59.sql
|
||||
```
|
||||
|
||||
Checks minimaux :
|
||||
|
||||
```sql
|
||||
-- duplicate signatures in output should be empty
|
||||
SELECT signature, COUNT(*)
|
||||
FROM k_sol_chain_transactions
|
||||
GROUP BY signature
|
||||
HAVING COUNT(*) > 1;
|
||||
|
||||
-- orphan instructions should be empty
|
||||
SELECT ins.id
|
||||
FROM k_sol_chain_instructions ins
|
||||
LEFT JOIN k_sol_chain_transactions tx ON tx.id = ins.transaction_id
|
||||
WHERE tx.id IS NULL;
|
||||
|
||||
-- conflicts summary
|
||||
SELECT *
|
||||
FROM k_sol_db_merge_conflicts
|
||||
ORDER BY id DESC
|
||||
LIMIT 100;
|
||||
```
|
||||
|
||||
## Tests
|
||||
|
||||
Ajouter des tests offline avec bases SQLite temporaires :
|
||||
|
||||
1. merge d’une DB vers un output vide ;
|
||||
2. merge de deux DBs avec signatures disjointes ;
|
||||
3. merge de deux DBs avec signature identique et contenu identique ;
|
||||
4. signature dupliquée avec conflit slot/meta et ligne conflict enregistrée ;
|
||||
5. instructions recopiées avec le nouveau `transaction_id` output ;
|
||||
6. dry-run sans écriture des lignes output ;
|
||||
7. table requise manquante -> erreur propre.
|
||||
|
||||
## Documentation
|
||||
|
||||
Mettre à jour :
|
||||
|
||||
```text
|
||||
README.md
|
||||
ROADMAP.md
|
||||
CHANGELOG.md
|
||||
validation_sql/SQL_VALIDATION_DB_MERGE_0_7_59.sql
|
||||
docs/reports/SQLITE_DB_TRANSACTION_MERGER_0_7_59.md
|
||||
```
|
||||
|
||||
## Résultat attendu
|
||||
|
||||
L’utilisateur peut consolider ses anciennes bases Raydium/Pump/Meteora dans une base output et relancer un replay local depuis les lignes brutes existantes, sans refaire les backfills RPC de signatures.
|
||||
@@ -0,0 +1,249 @@
|
||||
<!-- file: docs/prompts/PROMPT_0_7_59_sqlite_db_transaction_merger_binary.md -->
|
||||
|
||||
# Prompt — 0.7.59 Binaire de fusion de bases SQLite transactionnelles
|
||||
|
||||
## Contexte
|
||||
|
||||
Nous reprenons le workspace Rust `khadhroony-bobobot` après la clôture de `0.7.57 meteora_dlmm` et après/ou en parallèle de `0.7.58 demo4_program_surface_discovery`.
|
||||
|
||||
L’utilisateur possède plusieurs bases SQLite dédiées construites pendant les tranches Raydium, Pump et Meteora. L’objectif est d’éviter de rescanner/backfiller des signatures déjà présentes dans ces bases.
|
||||
|
||||
## Objectif
|
||||
|
||||
Ajouter un module binaire qui utilise `kb_lib` pour fusionner des données de corpus transactionnel depuis plusieurs fichiers SQLite `.db` vers une base SQLite de sortie unique.
|
||||
|
||||
Le merger doit copier suffisamment de données brutes transaction/instruction pour permettre un replay local dans la base consolidée, sans refaire les appels RPC.
|
||||
|
||||
Ce binaire est un outil de consolidation de corpus. Ce n’est pas un scanner blockchain.
|
||||
|
||||
## Forme recommandée
|
||||
|
||||
Créer un nouveau package workspace :
|
||||
|
||||
```text
|
||||
kb_tools/
|
||||
Cargo.toml
|
||||
src/bin/kb_db_merge.rs
|
||||
```
|
||||
|
||||
Le binaire doit dépendre de `kb_lib` et réutiliser autant que possible les fonctions de schéma/setup/query existantes.
|
||||
|
||||
Alternative acceptable si le workspace préfère ce pattern :
|
||||
|
||||
```text
|
||||
kb_lib/src/bin/kb_db_merge.rs
|
||||
```
|
||||
|
||||
Préférer `kb_tools` si cela évite de mélanger du code CLI-only dans `kb_lib`.
|
||||
|
||||
## Interface CLI
|
||||
|
||||
Commande suggérée :
|
||||
|
||||
```bash
|
||||
cargo run -p kb_tools --bin kb_db_merge -- \
|
||||
--output ./merged_corpus.db \
|
||||
--input ./raydium.db \
|
||||
--input ./pump.db \
|
||||
--input ./meteora.db \
|
||||
--mode raw-corpus \
|
||||
--dry-run
|
||||
```
|
||||
|
||||
Options requises ou utiles :
|
||||
|
||||
```text
|
||||
--output <path>
|
||||
--input <path> répétable
|
||||
--mode <mode>
|
||||
--dry-run optionnel
|
||||
--replace-output optionnel ; sinon refuser si output existe
|
||||
--source-label optionnel ou inféré depuis le nom de fichier
|
||||
--limit optionnel pour tests
|
||||
```
|
||||
|
||||
Modes initiaux :
|
||||
|
||||
```text
|
||||
raw-corpus
|
||||
full-copy-safe
|
||||
signatures-only
|
||||
```
|
||||
|
||||
## Mode `raw-corpus`
|
||||
|
||||
Mode par défaut recommandé.
|
||||
|
||||
Copier les données brutes canonique nécessaires au replay local sans RPC :
|
||||
|
||||
```text
|
||||
k_sol_chain_transactions
|
||||
k_sol_chain_instructions
|
||||
```
|
||||
|
||||
Si le schéma contient d’autres tables brutes/contextuelles strictement nécessaires, les inspecter avant de les ajouter. Ne copier que les tables sûres, sans duplication sémantique.
|
||||
|
||||
La base output doit ensuite pouvoir exécuter le replay/décodage local depuis les transactions persistées.
|
||||
|
||||
## Mode `full-copy-safe`
|
||||
|
||||
Mode optionnel pour plus tard.
|
||||
|
||||
Copier aussi des lignes décodées/matérialisées seulement si les foreign keys, versions de decoder et versions de schéma sont cohérentes.
|
||||
|
||||
Ne pas l’implémenter comme mode par défaut. Il est plus dangereux car les lignes matérialisées dépendent de la version du code.
|
||||
|
||||
## Mode `signatures-only`
|
||||
|
||||
Copier uniquement les signatures/slots dans une table de staging afin qu’un outil futur décide quoi importer/rejouer.
|
||||
|
||||
## Politique de déduplication
|
||||
|
||||
Identité primaire :
|
||||
|
||||
```text
|
||||
signature
|
||||
```
|
||||
|
||||
Règles :
|
||||
|
||||
- Une même signature dans plusieurs inputs doit produire une seule transaction dans l’output.
|
||||
- Si `meta_json`, `transaction_json`, `slot` ou `err_json` diffèrent pour une même signature, enregistrer un conflit ; ne pas écraser silencieusement.
|
||||
- Préférer la ligne brute la plus complète uniquement si le conflit est explicable et journalisé.
|
||||
- Conserver la provenance dans des tables d’audit de merge.
|
||||
|
||||
Tables suggérées :
|
||||
|
||||
```text
|
||||
k_sol_db_merge_sources
|
||||
k_sol_db_merge_transactions
|
||||
k_sol_db_merge_conflicts
|
||||
```
|
||||
|
||||
Champs source suggérés :
|
||||
|
||||
```text
|
||||
source_id
|
||||
source_path
|
||||
source_label
|
||||
source_schema_version
|
||||
source_created_at
|
||||
input_transaction_count
|
||||
copied_transaction_count
|
||||
skipped_duplicate_count
|
||||
conflict_count
|
||||
```
|
||||
|
||||
Pour chaque signature copiée :
|
||||
|
||||
```text
|
||||
signature
|
||||
slot
|
||||
source_id
|
||||
source_transaction_id
|
||||
copied_at
|
||||
copy_status
|
||||
conflict_status
|
||||
```
|
||||
|
||||
## Règles de sécurité
|
||||
|
||||
- Ne pas appeler RPC.
|
||||
- Ne pas backfiller.
|
||||
- Ne pas décoder DEX pendant le merge.
|
||||
- Ne pas matérialiser trades/candles pendant le merge.
|
||||
- Ne pas supposer une compatibilité de schéma sans inspection.
|
||||
- Ne pas utiliser `ATTACH` avec des chemins non validés/échappés.
|
||||
- Pas de `?`, `unwrap`, `expect` dans le code applicatif.
|
||||
- Les erreurs doivent être explicites, typées projet, et lisibles.
|
||||
- Le mode dry-run doit indiquer exactement ce qui serait copié, ignoré ou marqué conflictuel.
|
||||
|
||||
## Compatibilité de schéma
|
||||
|
||||
Le binaire doit inspecter `sqlite_master` et `PRAGMA table_info(...)` dans chaque DB input.
|
||||
|
||||
Tables requises pour `raw-corpus` :
|
||||
|
||||
```text
|
||||
k_sol_chain_transactions
|
||||
k_sol_chain_instructions
|
||||
```
|
||||
|
||||
Vérifier les colonnes requises par nom. Si une colonne optionnelle manque, l’indiquer clairement et continuer seulement si la copie reste suffisante pour un replay local fiable.
|
||||
|
||||
Si le schéma est incompatible, échouer proprement avec un résumé court.
|
||||
|
||||
## Stratégie de copie
|
||||
|
||||
Algorithme recommandé :
|
||||
|
||||
1. Ouvrir/créer la base output et initialiser le schéma courant via `kb_lib`.
|
||||
2. Pour chaque input DB :
|
||||
- inspecter le schéma ;
|
||||
- enregistrer la source ;
|
||||
- itérer les transactions par slot/signature ;
|
||||
- si la signature est absente de l’output, insérer la transaction et ses instructions enfants ;
|
||||
- si la signature existe, comparer les champs canoniques et ignorer ou enregistrer un conflit ;
|
||||
- préserver le mapping `source_transaction_id -> output_transaction_id` pour les instructions.
|
||||
3. Commit par batches.
|
||||
4. Imprimer un résumé final.
|
||||
|
||||
La taille de batch doit être configurable ou conservatrice.
|
||||
|
||||
## SQL de validation
|
||||
|
||||
Ajouter :
|
||||
|
||||
```text
|
||||
validation_sql/SQL_VALIDATION_DB_MERGE_0_7_59.sql
|
||||
```
|
||||
|
||||
Checks minimaux :
|
||||
|
||||
```sql
|
||||
-- duplicate signatures in output should be empty
|
||||
SELECT signature, COUNT(*)
|
||||
FROM k_sol_chain_transactions
|
||||
GROUP BY signature
|
||||
HAVING COUNT(*) > 1;
|
||||
|
||||
-- orphan instructions should be empty
|
||||
SELECT ins.id
|
||||
FROM k_sol_chain_instructions ins
|
||||
LEFT JOIN k_sol_chain_transactions tx ON tx.id = ins.transaction_id
|
||||
WHERE tx.id IS NULL;
|
||||
|
||||
-- conflicts summary
|
||||
SELECT *
|
||||
FROM k_sol_db_merge_conflicts
|
||||
ORDER BY id DESC
|
||||
LIMIT 100;
|
||||
```
|
||||
|
||||
## Tests
|
||||
|
||||
Ajouter des tests offline avec bases SQLite temporaires :
|
||||
|
||||
1. merge d’une DB vers un output vide ;
|
||||
2. merge de deux DBs avec signatures disjointes ;
|
||||
3. merge de deux DBs avec signature identique et contenu identique ;
|
||||
4. signature dupliquée avec conflit slot/meta et ligne conflict enregistrée ;
|
||||
5. instructions recopiées avec le nouveau `transaction_id` output ;
|
||||
6. dry-run sans écriture des lignes output ;
|
||||
7. table requise manquante -> erreur propre.
|
||||
|
||||
## Documentation
|
||||
|
||||
Mettre à jour :
|
||||
|
||||
```text
|
||||
README.md
|
||||
ROADMAP.md
|
||||
CHANGELOG.md
|
||||
validation_sql/SQL_VALIDATION_DB_MERGE_0_7_59.sql
|
||||
docs/reports/SQLITE_DB_TRANSACTION_MERGER_0_7_59.md
|
||||
```
|
||||
|
||||
## Résultat attendu
|
||||
|
||||
L’utilisateur peut consolider ses anciennes bases Raydium/Pump/Meteora dans une base output et relancer un replay local depuis les lignes brutes existantes, sans refaire les backfills RPC de signatures.
|
||||
198
docs/prompts/PROMPT_0_7_60_METEORA_DAMM_NEXT_DEX.md
Normal file
198
docs/prompts/PROMPT_0_7_60_METEORA_DAMM_NEXT_DEX.md
Normal file
@@ -0,0 +1,198 @@
|
||||
<!-- file: docs/prompts/prompt_name_0_7_60_meteora_damm_next_dex.md -->
|
||||
|
||||
# Prompt — 0.7.60 Meteora DAMM v1 puis DAMM v2
|
||||
|
||||
## Décision
|
||||
|
||||
Ne pas fusionner Meteora DAMM v1 et Meteora DAMM v2 dans une seule tranche d’implémentation.
|
||||
|
||||
Utiliser des versions séparées :
|
||||
|
||||
```text
|
||||
0.7.60 -> meteora_damm_v1
|
||||
0.7.61 -> meteora_damm_v2
|
||||
```
|
||||
|
||||
Raison :
|
||||
|
||||
- `program_id` différents ;
|
||||
- surfaces IDL/discriminators différentes ;
|
||||
- corpus historiques et besoins de validation différents ;
|
||||
- clôture SQL plus lisible ;
|
||||
- risque réduit de faux positifs cross-version ;
|
||||
- rollback plus simple si une version contient une hypothèse incorrecte.
|
||||
|
||||
Partage autorisé :
|
||||
|
||||
- helpers communs privés ;
|
||||
- patterns communs de récupération fee/reward amounts ;
|
||||
- conventions communes de coverage/tests ;
|
||||
- structure commune de rapport ;
|
||||
- template SQL commun.
|
||||
|
||||
Ne pas partager la classification de decoder d’une manière qui masque les discriminators version-spécifiques ou les layouts propres à chaque programme.
|
||||
|
||||
## Contexte
|
||||
|
||||
`0.7.57 meteora_dlmm` est clos. Les tranches intermédiaires planifiées sont :
|
||||
|
||||
```text
|
||||
0.7.58 -> demo4_program_surface_discovery
|
||||
0.7.59 -> sqlite_db_transaction_merger
|
||||
```
|
||||
|
||||
La prochaine tranche DEX doit reprendre la famille Meteora après DLMM/DBC, en commençant par DAMM v1.
|
||||
|
||||
Surfaces Meteora connues :
|
||||
|
||||
```text
|
||||
meteora_dbc -> clos 0.7.56
|
||||
meteora_dlmm -> clos 0.7.57
|
||||
meteora_damm_v1 -> 0.7.60
|
||||
meteora_damm_v2 -> 0.7.61
|
||||
meteora_vault -> plus tard, surface séparée
|
||||
```
|
||||
|
||||
## Cible 0.7.60 — meteora_damm_v1
|
||||
|
||||
Program id depuis la roadmap :
|
||||
|
||||
```text
|
||||
Eo7WjKq67rjJQSZxS6z3YkapzY3eMj6Xy8X5EQVn5UaB
|
||||
```
|
||||
|
||||
Objectif principal :
|
||||
|
||||
```text
|
||||
Full decode + full materialization pour toutes les instructions/events DAMM v1 disponibles depuis les IDL locales et les sources upstream.
|
||||
```
|
||||
|
||||
Familles attendues :
|
||||
|
||||
```text
|
||||
swap
|
||||
pool_create
|
||||
add_liquidity
|
||||
remove_liquidity
|
||||
lock/unlock liquidity si présent
|
||||
fee/admin/config
|
||||
lifecycle/migration si présent
|
||||
```
|
||||
|
||||
Règles :
|
||||
|
||||
- Pas de decoded-only pour une entrée utile observée si elle peut être matérialisée sûrement.
|
||||
- Ne pas créer de trade/candle depuis des non-swaps.
|
||||
- Ne pas matérialiser les transactions failed.
|
||||
- Ne pas agréger artificiellement les fees multi-mint.
|
||||
- Utiliser `k_sol_fee_event_amounts` pour les legs fee fiables.
|
||||
- Utiliser la récupération inner SPL transfer seulement avec allowlist explicite et tests.
|
||||
- Conserver toutes les entrées IDL/upstream non observées dans la coverage avec `0/0` et proof status clair.
|
||||
|
||||
## Sources à vérifier
|
||||
|
||||
Inspecter d’abord le répertoire local :
|
||||
|
||||
```text
|
||||
idls/
|
||||
```
|
||||
|
||||
Puis comparer avec :
|
||||
|
||||
```text
|
||||
Carbon decoders
|
||||
Pinax/substreams-solana-idls
|
||||
0xfnzero sol-parser-sdk / solana-streamer
|
||||
ancien code local et rapports historiques du projet
|
||||
samples Solscan / backfills Demo3
|
||||
```
|
||||
|
||||
Ne pas considérer les anciens résultats `0.7.36` ou `0.7.46` comme clôture finale. Revalider depuis le schéma courant et les règles actuelles de matérialisation.
|
||||
|
||||
## Plan de travail
|
||||
|
||||
1. Créer ou rafraîchir les entrées coverage `meteora_damm_v1`.
|
||||
2. Vérifier le `program_id` et la surface IDL locale.
|
||||
3. Étendre l’enum/local classifier des discriminators.
|
||||
4. Ajouter le naming dans `instruction_observation_index`.
|
||||
5. Décoder toutes les instructions et tous les events Anchor disponibles.
|
||||
6. Matérialiser swaps, liquidity, lifecycle, fee, reward/admin/orderbook si applicable.
|
||||
7. Ajouter des tests synthétiques pour chaque instruction/event IDL, y compris non observé.
|
||||
8. Ajouter le SQL de validation.
|
||||
9. Rejouer sur base fraîche avec :
|
||||
|
||||
```text
|
||||
skipDexDecode=no
|
||||
forceDexDecode=yes
|
||||
deferInstructionObservations=yes
|
||||
```
|
||||
|
||||
10. Clore seulement si les gates SQL sont propres.
|
||||
|
||||
## Gates SQL obligatoires
|
||||
|
||||
Reprendre le pattern DLMM :
|
||||
|
||||
```text
|
||||
fallback upstream pour entrées localement couvertes -> vide
|
||||
instruction_name null/blank -> vide
|
||||
decoded sans coverage -> vide
|
||||
successful non-materialized without skip/policy -> vide
|
||||
failed tx materialization -> vide
|
||||
multi-target materialization -> vide
|
||||
non-swap trade/candle -> vide
|
||||
fee scalar parent without leg -> vide
|
||||
orphan fee legs -> vide
|
||||
coverage logical duplicates -> vide
|
||||
watchlist sans backlog meteora_damm_v1
|
||||
```
|
||||
|
||||
## Cible 0.7.61 — meteora_damm_v2
|
||||
|
||||
Program id depuis la roadmap :
|
||||
|
||||
```text
|
||||
cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG
|
||||
```
|
||||
|
||||
N’ouvrir cette tranche qu’après clôture DAMM v1.
|
||||
|
||||
La tranche v2 peut réutiliser le template et des helpers privés, mais doit conserver ses propres éléments :
|
||||
|
||||
```text
|
||||
decoder code
|
||||
coverage entries
|
||||
instruction enum
|
||||
event mapping
|
||||
synthetic tests
|
||||
SQL validation
|
||||
rapport
|
||||
```
|
||||
|
||||
## Livrables attendus pour 0.7.60
|
||||
|
||||
Fichiers probables :
|
||||
|
||||
```text
|
||||
kb_lib/src/dex/meteora_damm_v1.rs
|
||||
kb_lib/src/dex_event_coverage.rs
|
||||
kb_lib/src/dex_event_classification.rs
|
||||
kb_lib/src/instruction_observation_index.rs
|
||||
kb_lib/src/non_trade_event_materialization.rs
|
||||
validation_sql/SQL_VALIDATION_METEORA_DAMM_V1_0_7_60.sql
|
||||
docs/reports/METEORA_DAMM_V1_EVENT_COVERAGE_REPORT.md
|
||||
```
|
||||
|
||||
Mettre à jour les re-exports si des modules ou requêtes sont ajoutés :
|
||||
|
||||
```text
|
||||
kb_lib/src/dex.rs
|
||||
kb_lib/src/lib.rs
|
||||
kb_lib/src/db.rs
|
||||
```
|
||||
|
||||
## Note finale
|
||||
|
||||
Si la découverte corpus montre que DAMM v1 et v2 partagent une logique basse-niveau précise, créer des helpers privés communs.
|
||||
|
||||
Ne pas fusionner les deux protocoles dans un seul decoder, une seule coverage ou un seul rapport de clôture.
|
||||
198
docs/prompts/PROMPT_0_7_60_meteora_damm_next_dex.md
Normal file
198
docs/prompts/PROMPT_0_7_60_meteora_damm_next_dex.md
Normal file
@@ -0,0 +1,198 @@
|
||||
<!-- file: docs/prompts/PROMPT_0_7_60_meteora_damm_next_dex.md -->
|
||||
|
||||
# Prompt — 0.7.60 Meteora DAMM v1 puis DAMM v2
|
||||
|
||||
## Décision
|
||||
|
||||
Ne pas fusionner Meteora DAMM v1 et Meteora DAMM v2 dans une seule tranche d’implémentation.
|
||||
|
||||
Utiliser des versions séparées :
|
||||
|
||||
```text
|
||||
0.7.60 -> meteora_damm_v1
|
||||
0.7.61 -> meteora_damm_v2
|
||||
```
|
||||
|
||||
Raison :
|
||||
|
||||
- `program_id` différents ;
|
||||
- surfaces IDL/discriminators différentes ;
|
||||
- corpus historiques et besoins de validation différents ;
|
||||
- clôture SQL plus lisible ;
|
||||
- risque réduit de faux positifs cross-version ;
|
||||
- rollback plus simple si une version contient une hypothèse incorrecte.
|
||||
|
||||
Partage autorisé :
|
||||
|
||||
- helpers communs privés ;
|
||||
- patterns communs de récupération fee/reward amounts ;
|
||||
- conventions communes de coverage/tests ;
|
||||
- structure commune de rapport ;
|
||||
- template SQL commun.
|
||||
|
||||
Ne pas partager la classification de decoder d’une manière qui masque les discriminators version-spécifiques ou les layouts propres à chaque programme.
|
||||
|
||||
## Contexte
|
||||
|
||||
`0.7.57 meteora_dlmm` est clos. Les tranches intermédiaires planifiées sont :
|
||||
|
||||
```text
|
||||
0.7.58 -> demo4_program_surface_discovery
|
||||
0.7.59 -> sqlite_db_transaction_merger
|
||||
```
|
||||
|
||||
La prochaine tranche DEX doit reprendre la famille Meteora après DLMM/DBC, en commençant par DAMM v1.
|
||||
|
||||
Surfaces Meteora connues :
|
||||
|
||||
```text
|
||||
meteora_dbc -> clos 0.7.56
|
||||
meteora_dlmm -> clos 0.7.57
|
||||
meteora_damm_v1 -> 0.7.60
|
||||
meteora_damm_v2 -> 0.7.61
|
||||
meteora_vault -> plus tard, surface séparée
|
||||
```
|
||||
|
||||
## Cible 0.7.60 — meteora_damm_v1
|
||||
|
||||
Program id depuis la roadmap :
|
||||
|
||||
```text
|
||||
Eo7WjKq67rjJQSZxS6z3YkapzY3eMj6Xy8X5EQVn5UaB
|
||||
```
|
||||
|
||||
Objectif principal :
|
||||
|
||||
```text
|
||||
Full decode + full materialization pour toutes les instructions/events DAMM v1 disponibles depuis les IDL locales et les sources upstream.
|
||||
```
|
||||
|
||||
Familles attendues :
|
||||
|
||||
```text
|
||||
swap
|
||||
pool_create
|
||||
add_liquidity
|
||||
remove_liquidity
|
||||
lock/unlock liquidity si présent
|
||||
fee/admin/config
|
||||
lifecycle/migration si présent
|
||||
```
|
||||
|
||||
Règles :
|
||||
|
||||
- Pas de decoded-only pour une entrée utile observée si elle peut être matérialisée sûrement.
|
||||
- Ne pas créer de trade/candle depuis des non-swaps.
|
||||
- Ne pas matérialiser les transactions failed.
|
||||
- Ne pas agréger artificiellement les fees multi-mint.
|
||||
- Utiliser `k_sol_fee_event_amounts` pour les legs fee fiables.
|
||||
- Utiliser la récupération inner SPL transfer seulement avec allowlist explicite et tests.
|
||||
- Conserver toutes les entrées IDL/upstream non observées dans la coverage avec `0/0` et proof status clair.
|
||||
|
||||
## Sources à vérifier
|
||||
|
||||
Inspecter d’abord le répertoire local :
|
||||
|
||||
```text
|
||||
idls/
|
||||
```
|
||||
|
||||
Puis comparer avec :
|
||||
|
||||
```text
|
||||
Carbon decoders
|
||||
Pinax/substreams-solana-idls
|
||||
0xfnzero sol-parser-sdk / solana-streamer
|
||||
ancien code local et rapports historiques du projet
|
||||
samples Solscan / backfills Demo3
|
||||
```
|
||||
|
||||
Ne pas considérer les anciens résultats `0.7.36` ou `0.7.46` comme clôture finale. Revalider depuis le schéma courant et les règles actuelles de matérialisation.
|
||||
|
||||
## Plan de travail
|
||||
|
||||
1. Créer ou rafraîchir les entrées coverage `meteora_damm_v1`.
|
||||
2. Vérifier le `program_id` et la surface IDL locale.
|
||||
3. Étendre l’enum/local classifier des discriminators.
|
||||
4. Ajouter le naming dans `instruction_observation_index`.
|
||||
5. Décoder toutes les instructions et tous les events Anchor disponibles.
|
||||
6. Matérialiser swaps, liquidity, lifecycle, fee, reward/admin/orderbook si applicable.
|
||||
7. Ajouter des tests synthétiques pour chaque instruction/event IDL, y compris non observé.
|
||||
8. Ajouter le SQL de validation.
|
||||
9. Rejouer sur base fraîche avec :
|
||||
|
||||
```text
|
||||
skipDexDecode=no
|
||||
forceDexDecode=yes
|
||||
deferInstructionObservations=yes
|
||||
```
|
||||
|
||||
10. Clore seulement si les gates SQL sont propres.
|
||||
|
||||
## Gates SQL obligatoires
|
||||
|
||||
Reprendre le pattern DLMM :
|
||||
|
||||
```text
|
||||
fallback upstream pour entrées localement couvertes -> vide
|
||||
instruction_name null/blank -> vide
|
||||
decoded sans coverage -> vide
|
||||
successful non-materialized without skip/policy -> vide
|
||||
failed tx materialization -> vide
|
||||
multi-target materialization -> vide
|
||||
non-swap trade/candle -> vide
|
||||
fee scalar parent without leg -> vide
|
||||
orphan fee legs -> vide
|
||||
coverage logical duplicates -> vide
|
||||
watchlist sans backlog meteora_damm_v1
|
||||
```
|
||||
|
||||
## Cible 0.7.61 — meteora_damm_v2
|
||||
|
||||
Program id depuis la roadmap :
|
||||
|
||||
```text
|
||||
cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG
|
||||
```
|
||||
|
||||
N’ouvrir cette tranche qu’après clôture DAMM v1.
|
||||
|
||||
La tranche v2 peut réutiliser le template et des helpers privés, mais doit conserver ses propres éléments :
|
||||
|
||||
```text
|
||||
decoder code
|
||||
coverage entries
|
||||
instruction enum
|
||||
event mapping
|
||||
synthetic tests
|
||||
SQL validation
|
||||
rapport
|
||||
```
|
||||
|
||||
## Livrables attendus pour 0.7.60
|
||||
|
||||
Fichiers probables :
|
||||
|
||||
```text
|
||||
kb_lib/src/dex/meteora_damm_v1.rs
|
||||
kb_lib/src/dex_event_coverage.rs
|
||||
kb_lib/src/dex_event_classification.rs
|
||||
kb_lib/src/instruction_observation_index.rs
|
||||
kb_lib/src/non_trade_event_materialization.rs
|
||||
validation_sql/SQL_VALIDATION_METEORA_DAMM_V1_0_7_60.sql
|
||||
docs/reports/METEORA_DAMM_V1_EVENT_COVERAGE_REPORT.md
|
||||
```
|
||||
|
||||
Mettre à jour les re-exports si des modules ou requêtes sont ajoutés :
|
||||
|
||||
```text
|
||||
kb_lib/src/dex.rs
|
||||
kb_lib/src/lib.rs
|
||||
kb_lib/src/db.rs
|
||||
```
|
||||
|
||||
## Note finale
|
||||
|
||||
Si la découverte corpus montre que DAMM v1 et v2 partagent une logique basse-niveau précise, créer des helpers privés communs.
|
||||
|
||||
Ne pas fusionner les deux protocoles dans un seul decoder, une seule coverage ou un seul rapport de clôture.
|
||||
Reference in New Issue
Block a user