khadhroony-bot3/KHADHROONY_BOT3_MIGRATION_CLOSURE_TODO.md

<!-- file: KHADHROONY_BOT3_MIGRATION_CLOSURE_TODO.md -->
<!-- version: 27 -->

# 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

- [x] Onze crates consolidées et documentées.
- [x] Solana Core, SPL Memo, SPL Token classique, ATA et Token-2022 migrés jusqu’au périmètre historique `0.4.6`.
- [x] System Transfer et Memo v4 validés de bout en bout sur Devnet.
- [x] ATA classique, ATA Token-2022, SPL Token classique et huit opérations Token-2022 déclarés validés dans le rapport `pre.062`.
- [x] Registre ElGamal conservé comme exception documentée, sans validation réseau déclarée.
- [x] Seul `kb-config` dépend directement de `dotenvy`.
- [x] Tous les appels frontend `invoke(...)` détectés correspondent à une commande Tauri enregistrée.
- [x] 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.
- [x] 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`](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

- [x] Ajouter [`docs/guides/DEVNET_0_4_6_OPERATOR_GUIDE.md`](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`

- [x] Conserver le décodeur Metaplex Token Metadata déjà migré.
- [x] 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.