# Audit d’alignement des TODO par crate ## Objectif Classer les tâches restantes des onze crates selon leur rapport à l’alignement fonctionnel de `khadhroony-bot3` sur `khadhroony-bot2 0.4.6`, à la reprise de l’objectif `0.4.7` et aux versions ultérieures. Cet audit ne constitue pas encore `V0_4_6_ALIGNMENT_AUDIT.md`. Il prépare cet audit en supprimant les ambiguïtés de calendrier dans les TODO. ## Règles de classement ### Bloquant avant `0.4.6` Une tâche appartient à cette catégorie lorsqu’elle doit démontrer ou rétablir une capacité attendue de bot2 `0.4.6`, ou lorsqu’elle est nécessaire à la clôture documentaire de la migration. ### Entre `0.4.6` et `0.4.7` Cette catégorie contient les travaux nécessaires pour reprendre et achever l’objectif Metaplex Token Metadata interrompu dans bot2. ### Version ultérieure Cette catégorie contient les travaux explicitement planifiés après `0.4.7`, notamment `0.5.x`, `0.6.x`, `0.9.x` et `0.13.x`. ### Report conditionnel Une tâche dépendante d’un déploiement, d’une preuve ou d’une source externe non confirmée n’est pas un blocant de version tant que cette dépendance n’est pas établie. ## Blocants identifiés avant `0.4.6` ### `kb-app-demo-desktop` - synchronisation complète Tauri/TS-RS ; - couverture explicite des cycles de fenêtres ; - maintien de la session WebSocket après fermeture de `demo_ws` ; - restauration de l’état WebSocket lors de la réouverture. Ces points sont des preuves de migration attendues, même lorsque leur comportement paraît déjà implicitement couvert. ### `kb-pipeline` - traitement des écarts concrets révélés par l’audit final ; - guide transversal replay, extraction Core et matérialisation. ### `kb-onchain-transport` - guide transversal RPC, backfill et WebSocket. ### `kb-store` - guide transversal PostgreSQL et contrats de stockage. ## Travaux entre `0.4.6` et `0.4.7` - exécuteur Metaplex Token Metadata dans `kb-lib` ; - vérification et complément de la matérialisation migrée ; - intégration replay et orchestration dans `kb-pipeline` ; - scénarios et validations dans `kb-pipeline-demo-scenarios` ; - panneaux applicatifs dans `kb-app-demo-desktop`. ## Exceptions documentées ### Registre ElGamal Le registre reste implémenté dans certaines couches, mais sa validation réseau dépend : - de la confirmation de son déploiement ; - d’une preuve `PubkeyValidity` ; - d’un compte `Proof Context State` valide. Ces tâches restent conditionnelles et ne bloquent pas l’alignement `0.4.6`, à condition que la documentation ne déclare jamais une validation réseau inexistante. ### `kb-wallet` Les capacités avancées sont affectées à `0.5.x`. Le wallet temporaire migré suffit au périmètre historique attendu avant l’alignement. ### Configuration et logging Le split de configuration appartient à `0.5.x` et ne bloque pas `0.4.6`. ### Transports avancés Helius étendu, LaserStream, Yellowstone et la résilience streaming appartiennent à `0.13.x`. ## Résultat Les TODO sont désormais classés par version ou dépendance. Le classement ne prouve pas encore que les blocants `0.4.6` sont satisfaits ; il définit les vérifications à exécuter dans les correctifs de `pre.072` et dans `V0_4_6_ALIGNMENT_AUDIT.md`.