v0.1.0-pre.074-fix001

docs/audits/V0_4_6_ALIGNMENT_AUDIT.md

@@ -1,5 +1,5 @@
 <!-- file: docs/audits/V0_4_6_ALIGNMENT_AUDIT.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Audit ciblé d’alignement `0.4.6`
 
@@ -243,59 +243,161 @@ Les différences suivantes sont des choix bot3 validés, pas des régressions :
 - maintien de `kb-app-demo-desktop` comme package mixte ;
 - maintien d’un wallet minimal avant sa complétion en `0.5.x`.
 
-## 9. Blocants démontrés avant passage officiel à `0.4.6`
+## 9. Blocants ou vérifications à clôturer avant passage officiel à `0.4.6`
 
-### 9.1 Desktop et contrat Tauri
+La checklist historique contient encore de nombreuses tâches non cochées. Certaines sont déjà réalisées mais non réconciliées, certaines appartiennent à `0.4.7+`, et d’autres restent réellement à vérifier.
 
-Il reste à obtenir une validation explicite et complète de :
+La liste suivante remplace la précédente liste trop restrictive.
 
-1. la synchronisation des adaptateurs Tauri et des payloads TS-RS avec les APIs réutilisables ;
-2. la couverture des cycles d’ouverture, fermeture et réouverture des fenêtres concernées.
+### 9.1 Réconciliation de la checklist historique
 
-### 9.2 Cycle de vie WebSocket
+Avant toute conclusion finale :
 
-Le code place la session WebSocket dans `AppState`, distinctement de la fenêtre, et expose des commandes explicites de statut, connexion, désabonnement et déconnexion.
+- confronter chaque tâche non cochée à l’état actuel du code, des tests et de la documentation ;
+- cocher les tâches déjà prouvées ;
+- retirer ou archiver les formulations obsolètes ;
+- transférer vers les TODO ou le ROADMAP les travaux `0.4.7+` ;
+- ne conserver comme blocants `0.4.6` que les écarts encore démontrables.
 
-Il reste néanmoins à valider explicitement :
+La checklist demande encore un alignement final sur `0.4.7`, ce qui ne correspond plus à la trajectoire décidée : clôture de migration en `0.4.6`, puis reprise séparée de `0.4.7`.
 
-1. que fermer `demo_ws` ne ferme pas une session active ;
-2. que rouvrir `demo_ws` récupère l’état courant ;
-3. que l’arrêt intervient uniquement sur déconnexion explicite, fermeture de l’application ou timeout prévu.
+### 9.2 Preuves Devnet du périmètre `0.4.6`
 
-Ces validations doivent être couvertes par des tests ou une campagne reproductible avant retrait des tâches du TODO.
+La validation ATA, SPL Token classique et Token-2022 est documentée comme réalisée dans le prompt de reprise, alors que la checklist historique conserve ces tâches ouvertes.
 
-### 9.3 Validation complète dans le workspace réel
+Il faut :
 
-Avant le changement de version, exécuter :
+- rattacher les preuves disponibles aux tâches correspondantes ;
+- fermer ATA classique, ATA Token-2022, SPL Token classique et les huit opérations Token-2022 réellement validées ;
+- conserver ElGamal comme exception conditionnelle et non comme validation manquante bloquante ;
+- vérifier si le replay System Transfer et Memo v4 après changement de nomenclature a déjà été exécuté ou doit être rejoué.
+
+### 9.3 Nomenclature et contrats persistés
+
+Vérifier avant alignement :
+
+- l’audit empêchant la réintroduction des anciennes identités persistées ;
+- l’état réel de la base Devnet après changement de nomenclature ;
+- l’audit Python final de nomenclature ;
+- la cohérence entre matrices actives et registres compilés pour les surfaces `0.4.6`.
+
+La réévaluation complète de chaque matrice lors de futures surfaces n’est pas un blocant global `0.4.6`.
+
+### 9.4 Règles et documentation active
+
+Clôturer :
+
+- la lecture croisée finale des règles ;
+- la suppression des demandes historiques sans valeur normative ;
+- la vérification qu’aucun document actif ne raconte encore la migration comme dépendance conceptuelle nécessaire ;
+- la confirmation que les README et USAGE des onze crates correspondent à l’état actuel ;
+- la documentation de reconstruction PostgreSQL encore explicitement demandée par la checklist.
+
+L’inventaire complet Program IDs/IDL peut être traité ultérieurement, après rescan des archives, sauf lorsqu’une source est nécessaire pour valider une surface `0.4.6`.
+
+### 9.5 Desktop, Tauri et interface
+
+Vérifier explicitement :
+
+- synchronisation Tauri/TS-RS ;
+- cycles d’ouverture, fermeture et réouverture ;
+- séparateurs de menu ;
+- absence de contrôles morts ou dupliqués ;
+- correspondance entre options HTML, commandes Tauri et scénarios backend ;
+- contrat de fenêtre pour Decode replay, Exécution Solana Core et Exécution SPL ;
+- absence de logique métier substantielle restante dans `tauri.rs` ;
+- tests unitaires placés dans les modules fonctionnels ;
+- timeout HTTP et arrêt global de l’application.
+
+### 9.6 Cycle de vie WebSocket
+
+Valider :
+
+- fermer `demo_ws` ne ferme pas une session active ;
+- rouvrir `demo_ws` récupère l’état courant ;
+- l’arrêt intervient uniquement sur déconnexion explicite, fermeture de l’application ou timeout prévu ;
+- les diagnostics et contrôles reflètent l’état réel de la session.
+
+### 9.7 Configuration, secrets et logging
+
+Confirmer :
+
+- seul `kb-config` charge `.env` ;
+- ordre de priorité des variables et fichiers ;
+- comportement `${VAR}` et `${VAR:-fallback}` ;
+- absence de fuite de secrets ;
+- résolution réelle de `HELIUS_API_KEY` ;
+- absence de dépendance directe `dotenvy` dans les scénarios ;
+- routes console `local_devnet` et `mainnet` ;
+- targets `kb-lib.decoder.*`, `kb-lib.executor.*`, `kb-lib.materializer.*` ;
+- absence de recréation de répertoires de logs d’anciennes crates.
+
+### 9.8 PostgreSQL et fiabilité du pipeline
+
+Décider et valider avant alignement :
+
+- documentation des tables conservées, dérivées et de leur ordre de reconstruction ;
+- contrôle des index et contraintes après reconstruction ;
+- dimensionnement du pool ou justification du report ;
+- retry borné pour les timeouts transitoires, ou preuve que ce correctif n’est pas requis pour l’équivalence `0.4.6` ;
+- profils `local_devnet` et `mainnet` pendant la campagne finale.
+
+### 9.9 Validation des surfaces desktop
+
+Vérifier :
+
+- Exécution Solana Core ;
+- Exécution SPL ;
+- options réellement exposées ;
+- suppression des options mortes ;
+- statut de `execute_devnet_spl_token_lifecycle` ;
+- simulation, envoi, progression, résumé et diagnostics ;
+- replay et matérialisation post-exécution pour les familles supportées.
+
+### 9.10 Documentation opérateur minimale
+
+Avant `0.4.6`, confirmer que la documentation active permet au minimum :
+
+- création ou sélection du wallet de démonstration ;
+- récupération de la clé publique ;
+- saisie des champs desktop ;
+- exécution des scénarios Solana Core et SPL ;
+- compréhension des préconditions, signers, frais et résultats ;
+- vérification du replay et des projections.
+
+Les scénarios Metaplex appartiennent à `0.4.7`.
+
+### 9.11 Validation finale du workspace
+
+Exécuter dans le workspace réel :
 
 ```bash
 cargo fmt --all
+cargo test --workspace
 cargo check --workspace
 cargo clippy --all-targets
 python3 scripts/audit_rust_workspace_rules.py
-cargo test -p kb-pipeline-demo-scenarios
-cargo test -p kb-app-demo-desktop
 ```
 
-Exécuter également les tests ciblés de toute crate modifiée par les correctifs issus de cet audit.
+Exécuter également :
 
-La validation frontend doit utiliser :
+- vérification des bindings TS-RS régénérés ;
+- validation runtime de toutes les fenêtres ;
+- validation HTTP, WebSocket, Backfill, Core extraction, Decode replay et SQL ;
+- validation Solana Core et SPL sur Devnet ;
+- vérification de l’archive finale et absence de secrets ou artefacts exclus.
 
-```bash
-cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
-```
+## 10. Éléments explicitement reportés après `0.4.6`
 
-## 10. Liste fermée des écarts à traiter
+Ne doivent pas bloquer la version :
 
-Avant `0.4.6`, traiter uniquement :
-
-- validation Tauri/TS-RS ;
-- validation des cycles de fenêtres ;
-- validation du cycle de vie persistant de `demo_ws` ;
-- éventuelles corrections directement révélées par ces validations ;
-- exécution finale des commandes de validation du workspace.
-
-Aucun nouvel audit complet des protocoles déjà validés n’est requis.
+- Metaplex Token Metadata complet, exécuteur et validations, pour `0.4.7` ;
+- Anchor générique, pour `0.6.x` ;
+- registre Program IDs/IDL complet après rescan historique ;
+- workers W1/W2 et applications associées tant que leur version ROADMAP n’est pas décidée ;
+- wallet complet et split de configuration, pour `0.5.x` ;
+- transports streaming avancés, pour `0.13.x` ;
+- ElGamal réseau tant que son déploiement et ses preuves ne sont pas disponibles.
 
 ## 11. Conclusion
 
@@ -303,12 +405,12 @@ Aucun nouvel audit complet des protocoles déjà validés n’est requis.
 NOT_READY_FOR_0_4_6
 ```
 
-Le périmètre fonctionnel historique de bot2 `0.4.6` est largement migré et les différences architecturales sont documentées. Le passage officiel reste bloqué par des validations desktop/WebSocket explicites et par la validation finale du workspace réel.
+Le périmètre historique `0.4.6` paraît largement présent, mais la liste de cinq blocants précédemment publiée était incomplète. La checklist doit d’abord être réconciliée et les familles de vérification des sections 9.2 à 9.11 doivent être clôturées ou explicitement reportées avec justification.
 
-Après clôture de ces points, la conclusion pourra devenir :
+La conclusion pourra devenir :
 
 ```text
 READY_WITH_DOCUMENTED_EXCEPTIONS
 ```
 
-Les exceptions documentées attendues sont le registre ElGamal non validé sur réseau et les travaux Metaplex Token Metadata réservés à `0.4.7`.
+lorsque les vérifications restantes seront prouvées et que les seules exceptions seront explicitement documentées, notamment ElGamal non validé sur réseau et Metaplex réservé à `0.4.7`.