khadhroony-bot3/olddocs/archivekbot3/docs/KHADHROONY_BOT3_MIGRATION_CLOSURE_TODO.md

Clôture de la migration vers 0.4.6

Ce document temporaire contient uniquement les tâches encore nécessaires pour aligner officiellement khadhroony-bot3 sur le périmètre fonctionnel de khadhroony-bot2 0.4.6.

Les travaux Metaplex Token Metadata sont reportés entre 0.4.6 et 0.4.7. Anchor, le wallet complet, le split de configuration, les protocoles applicatifs et les transports avancés restent dans leurs versions ROADMAP respectives.

1. Preuves déjà acquises

• Onze crates consolidées et documentées.
• Solana Core, SPL Memo, SPL Token classique, ATA et Token-2022 migrés jusqu’au périmètre historique 0.4.6.
• System Transfer et Memo v4 validés de bout en bout sur Devnet.
• ATA classique, ATA Token-2022, SPL Token classique et huit opérations Token-2022 déclarés validés dans le rapport pre.062.
• Registre ElGamal conservé comme exception documentée, sans validation réseau déclarée.
• Seul kb-config dépend directement de dotenvy.
• Tous les appels frontend invoke(...) détectés correspondent à une commande Tauri enregistrée.
• La session WebSocket est stockée dans AppState et la fermeture de la fenêtre demo_ws ne déclenche pas statiquement de déconnexion.
• La fermeture de la fenêtre principale déclenche la déconnexion globale de la session WebSocket.

2. Nomenclature et données persistées

• Exécuter l’audit statique scripts/audit_pre_0_4_6_static_contracts.py dans le workspace réel.
• Vérifier l’absence de réintroduction des anciennes crates, anciens targets et anciennes identités persistées.
• Confirmer que les matrices actives et les registres compilés utilisent les identités canoniques.
• Rejouer System Transfer et Memo v4 après purge ou reconstruction des données dérivées si cette preuve n’a pas déjà été conservée après la migration de nomenclature.
• Documenter la preuve ou fermer explicitement ce replay si les rapports existants suffisent.

3. Desktop, Tauri et frontend

• Réduire kb-app-demo-desktop/src/tauri.rs à une couche mince de commandes et d’adaptation.
• Déplacer l’orchestration Decode replay, PostgreSQL et exécution encore substantielle vers les modules fonctionnels appropriés.
• Vérifier que les tests unitaires associés suivent les fonctions déplacées.
• Valider visuellement une dernière fois menus, séparateurs et absence de contrôles morts ou dupliqués.
• Vérifier les viewers et sorties de Decode replay, Exécution Solana Core et Exécution SPL.
• Vérifier le timeout HTTP et le comportement d’arrêt global.

4. Cycle de vie WebSocket

Exécuter le scénario docs/validation/WEBSOCKET_LIFECYCLE_VALIDATION_SCENARIO.md.

• Souscrire à des logs mentionnant un Program ID actif.
• Fermer demo_ws sans unsubscribe ni disconnect.
• Confirmer dans les logs que la session et la subscription restent actives.
• Rouvrir demo_ws et confirmer la restauration du statut et de la subscription.
• Désinscrire explicitement la subscription.
• Souscrire de nouveau puis déconnecter explicitement la socket.
• Refaire un abonnement puis fermer l’application principale et confirmer la déconnexion globale.
• Archiver les logs et captures de preuve.

5. Configuration, secrets et logging

• Exécuter les tests kb-config et kb-logging dans le workspace réel.
• Confirmer la priorité KB_ENV_FILE, .env, variables d’environnement et fallbacks.
• Confirmer la résolution de HELIUS_API_KEY sans fuite dans les logs ou payloads frontend.
• Vérifier les routes console et fichiers des profils Devnet et Mainnet.
• Vérifier les targets consolidées kb-lib.decoder.*, kb-lib.executor.* et kb-lib.materializer.*.
• Confirmer l’absence de répertoires de logs dédiés aux anciennes crates supprimées.

6. PostgreSQL et pipeline

• Exécuter les tests kb-store et kb-pipeline.
• Exécuter un healthcheck PostgreSQL sur le profil Devnet.
• Vérifier les migrations et les diagnostics des tables raw, Core et decode/materialization.
• Exécuter une campagne complète raw → Core → Decode replay → Materialize.
• Vérifier l’idempotence d’un second replay.
• Contrôler les index et contraintes avec les diagnostics existants.
• Documenter le dimensionnement actuel du pool et les trois timeouts transitoires historiques.
• Décider si le retry PostgreSQL borné est requis avant 0.4.6 ou reporté à la refonte 0.5.x.

7. Validation desktop des surfaces 0.4.6

• Valider HTTP, WebSocket, Backfill, Core extraction, Decode replay et diagnostics SQL.
• Valider Exécution Solana Core sur Devnet.
• Valider Memo v4, ATA classique, ATA Token-2022, SPL Token classique et Token-2022 dans le desktop.
• Vérifier simulation, confirmation opérateur, envoi, progression, résumé et diagnostics.
• Vérifier backfill, Core extraction, replay et matérialisation post-exécution.
• Confirmer que toutes les options frontend correspondent à une capacité backend réelle.

8. Documentation opérateur minimale

• Ajouter docs/guides/DEVNET_0_4_6_OPERATOR_GUIDE.md.
• Relire le guide pendant la campagne runtime et corriger les champs ou commandes inexacts.
• Ajouter les preuves finales au rapport d’alignement.

9. Report explicite vers 0.4.7

• Conserver le décodeur Metaplex Token Metadata déjà migré.
• Reporter la vérification de la matérialisation, l’exécuteur, le pipeline, les scénarios et le desktop vers 0.4.7.
• Après publication de 0.4.6, créer la première prerelease de planification de 0.4.7 selon docs/rules/VERSION_DEVELOPMENT_LIFECYCLE.md.

10. Validation finale et changement de version

• cargo fmt --all.
• cargo test --workspace.
• cargo check --workspace.
• cargo clippy --all-targets.
• python3 scripts/audit_rust_workspace_rules.py.
• Vérifier les bindings TS-RS régénérés.
• Vérifier l’absence de secrets et artefacts exclus dans l’archive.
• Mettre à jour docs/audits/V0_4_6_ALIGNMENT_AUDIT.md vers READY_WITH_DOCUMENTED_EXCEPTIONS ou READY_FOR_0_4_6.
• Mettre les versions Cargo à 0.4.6.
• Ajouter la section fonctionnelle 0.4.6 au changelog général.
• Mettre à jour les changelogs des crates affectées.
• Archiver puis supprimer cette checklist après validation explicite.