khadhroony-bot3/olddocs/CODE_REUSE.md

Réutilisation de code

Ce document liste les composants de l'ancien workspace qui peuvent servir de référence pour le nouveau workspace. Le code ne doit pas être copié mécaniquement : chaque portion reprise doit être adaptée aux nouvelles frontières de crates, aux règles de nommage, aux règles crate:: et au backend PostgreSQL.

Composants candidats

Composant	Cible dans le nouveau workspace	Décision provisoire
Client RPC HTTP	kb_onchain_transport	Réutiliser les idées : retry, backoff, limites, traces, idempotence. Réécrire l'API selon les nouveaux modèles.
Pool RPC HTTP	kb_onchain_transport	Reprendre le principe de sélection d'endpoint et de contrôle de débit. Isoler les métriques et les erreurs dans kb_core.
Client WebSocket	kb_onchain_transport	Reprendre la gestion ping/pong, subscribe/unsubscribe, shutdown explicite et reconnexion contrôlée.
Pool WebSocket	kb_onchain_transport	Garder l'idée de pool, mais éviter toute dépendance vers les décodeurs ou le stockage concret.
Ledger de replay	kb_pipeline et kb_store_core	Réécrire en versionné par module, version, scope et input hash.
Validation SQL	validation_sql/	Porter seulement les contrôles encore utiles : doublons de signatures, events failed, non-swap vers trade, coverage résiduelle.
Découvertes de discriminators	docs/DECODER_SURFACE_AUDIT.md, idls/, futurs catalogues	Conserver comme corpus de décision, pas comme support automatique.
Matérialisations trade/liquidity/lifecycle	kb_materializer_*	Reprendre les règles validées, mais séparer strictement decode et materialize.

Interdictions

• Ne pas importer directement l'ancien schéma SQLite dans les nouveaux décodeurs.
• Ne pas faire dépendre kb_onchain_transport de kb_store_pg.
• Ne pas faire dépendre un décodeur de kb_pipeline.
• Ne pas conserver une fonction monolithique de replay global.

Critère d'acceptation

Une portion reprise est acceptée seulement si elle respecte les règles suivantes :

• responsabilité limitée à un crate cible ;
• documentation de code en anglais ;
• absence de use hors traits nécessaires ;
• erreurs typées via kb_core ;
• tracing target stable ;
• tests unitaires ou validation de build.

Interfaces officielles actuelles

La réutilisation prioritaire ne concerne pas uniquement l’ancien code. Les enums, types, IDs et encodeurs publiés dans les interfaces officielles Solana/SPL doivent être utilisés lorsqu’ils exposent un contrat compatible avec les règles du workspace. La matrice, les exceptions bincode et l’ordre wincode/Borsh/parser borné sont maintenus dans docs/SOLANA_INTERFACE_DEPENDENCIES.md.