v0.4.6

olddocs/archivekbot3/001.README.md

@@ -1,5 +1,5 @@
 <!-- file: olddocs/archivekbot3/001.README.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Archive documentaire de khadhroony-bot3
 
@@ -20,3 +20,7 @@ Les documents archivés :
 - `prompts/` : prompts utilisés pendant la migration architecturale.
 
 La documentation active reste sous `docs/`. Le point d’entrée normatif reste `RULES.md`.
+
+## Clôture 0.4.6
+
+Les audits, guides et checklist temporaires utilisés pour clôturer la migration sont conservés sous `docs/` dans cette archive. Ils ne sont plus normatifs.

olddocs/archivekbot3/docs/KHADHROONY_BOT3_MIGRATION_CLOSURE_TODO.md

@@ -0,0 +1,106 @@
+<!-- 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.

olddocs/archivekbot3/docs/audits/PRE_0_4_6_STATIC_CODE_AUDIT.md

@@ -0,0 +1,57 @@
+<!-- file: docs/audits/PRE_0_4_6_STATIC_CODE_AUDIT.md -->
+<!-- version: 1 -->
+
+# Audit statique préalable à `0.4.6`
+
+## Résumé
+
+L’audit statique a été exécuté sur l’archive complète `v0.1.0-pre.074-fix001`.
+
+## Résultats propres
+
+- seul `kb-config` dépend directement de `dotenvy` ;
+- 50 commandes littérales appelées par le frontend ont été détectées ;
+- les 50 sont présentes dans `tauri::generate_handler!` ;
+- les huit commandes enregistrées non appelées directement depuis TypeScript correspondent aux ouvertures de fenêtres déclenchées depuis le menu Rust ;
+- `AppState` possède la session WebSocket persistante ;
+- la destruction de `demo_ws` ne contient pas de déconnexion statique ;
+- la destruction de la fenêtre principale appelle la déconnexion globale ;
+- aucune ancienne crate consolidée n’est redevenue une dépendance Cargo active ;
+- les onze crates possèdent les quatre documents obligatoires.
+
+## Écart démontré : `tauri.rs` reste trop substantiel
+
+`kb-app-demo-desktop/src/tauri.rs` contient encore environ 1 900 lignes et appelle directement :
+
+- `kb_pipeline::execute_decode_replay` ;
+- `kb_pipeline::execute_http_backfill` ;
+- `kb_store::PostgresStore::connect` et des repositories ;
+- les scénarios Devnet Solana Core, Memo, SPL Token, ATA et Token-2022 ;
+- la construction de listes de matérialisateurs et de filtres de diagnostics.
+
+Le fichier n’est donc pas encore uniquement une couche mince de wrappers `#[tauri::command]`.
+
+### Décision
+
+Avant `0.4.6`, déplacer l’orchestration vers les modules fonctionnels déjà présents :
+
+- `demo_backfill.rs` ;
+- `demo_core_extraction.rs` ;
+- `demo_decode_replay.rs` ;
+- `demo_execution_solana_core.rs` ;
+- `demo_execution_spl.rs` et ses sous-modules ;
+- modules SQL concernés.
+
+`tauri.rs` doit conserver l’assemblage Tauri, les wrappers de commandes, l’ouverture des fenêtres et les adaptations minimales d’erreur ou d’état.
+
+## Vérifications runtime encore nécessaires
+
+L’audit statique ne prouve pas :
+
+- la persistance réelle de la socket après fermeture de la fenêtre ;
+- la restauration visuelle du statut à la réouverture ;
+- les timeouts réseau ;
+- le comportement des profils et routes de logging ;
+- la campagne PostgreSQL et Devnet complète.
+
+Ces points doivent être validés avec les scénarios dédiés et leurs logs.

olddocs/archivekbot3/docs/audits/V0_4_6_ALIGNMENT_AUDIT.md

@@ -0,0 +1,416 @@
+<!-- file: docs/audits/V0_4_6_ALIGNMENT_AUDIT.md -->
+<!-- version: 2 -->
+
+# Audit ciblé d’alignement `0.4.6`
+
+## 1. Objet
+
+Cet audit détermine si `khadhroony-bot3` peut être officiellement aligné sur le périmètre fonctionnel de `khadhroony-bot2 0.4.6`.
+
+Il ne refait pas les audits protocolaires complets déjà réalisés pour Solana Core, SPL Memo, SPL Token, SPL Associated Token Account, Token-2022 et le registre SPL ElGamal. Il synthétise leur migration, les tests disponibles, les validations Devnet connues et les écarts résiduels démontrés.
+
+## 2. Base examinée
+
+Base documentaire et source :
+
+```text
+khadhroony-bot3 v0.1.0-pre.073
+```
+
+Le workspace contient onze crates :
+
+1. `kb-core` ;
+2. `kb-config` ;
+3. `kb-lib` ;
+4. `kb-logging` ;
+5. `kb-program-ids` ;
+6. `kb-pipeline` ;
+7. `kb-pipeline-demo-scenarios` ;
+8. `kb-onchain-transport` ;
+9. `kb-store` ;
+10. `kb-wallet` ;
+11. `kb-app-demo-desktop`.
+
+Toutes utilisent actuellement la version workspace `0.1.0`. Aucun changement vers `0.4.6` ne doit être effectué avant clôture des blocants de la section 9.
+
+## 3. Architecture migrée
+
+### 3.1 Consolidations principales
+
+| Bot2                               | Bot3                         | Statut                              |
+|------------------------------------|------------------------------|-------------------------------------|
+| modèles et contrats répartis       | `kb-core` et `kb-lib`        | migré et consolidé                  |
+| décodeurs séparés                  | modules de `kb-lib`          | migré                               |
+| exécuteurs séparés                 | modules de `kb-lib`          | migré                               |
+| matérialisateurs séparés           | modules de `kb-lib`          | migré                               |
+| stockage core et PostgreSQL séparé | `kb-store`                   | migré et consolidé                  |
+| crates RPC et transports           | `kb-onchain-transport`       | migré et renommé                    |
+| pipeline historique                | `kb-pipeline`                | migré                               |
+| scénarios dépendants du desktop    | `kb-pipeline-demo-scenarios` | extraits partiellement              |
+| application de démonstration       | `kb-app-demo-desktop`        | migrée et renommée                  |
+| wallet temporaire                  | `kb-wallet`                  | migré, capacités avancées reportées |
+
+La consolidation modifie la structure des crates, mais ne constitue pas en elle-même un écart fonctionnel.
+
+### 3.2 Binaires et crates mixtes
+
+- `kb-app-demo-desktop` reste une crate mixte bibliothèque et binaire ;
+- `kb-pipeline-demo-scenarios` reste une crate mixte ;
+- sa bibliothèque s’appelle `kb_pipeline_demo_scenarios` ;
+- son binaire explicite s’appelle `kb-pipeline-demo-scenarios-cli` ;
+- `autobins = false` empêche la création d’une cible implicite concurrente.
+
+## 4. Documentation et règles
+
+### 4.1 Contrat par crate
+
+Les onze crates disposent désormais de :
+
+```text
+README.md
+TODO.md
+USAGE.md
+CHANGELOG.md
+```
+
+Les TODO sont classés par échéance :
+
+- blocants avant `0.4.6` ;
+- travaux entre `0.4.6` et `0.4.7` ;
+- versions ultérieures ;
+- reports conditionnels.
+
+### 4.2 Documentation transversale
+
+Les documents actifs couvrent :
+
+- architecture générale et carte des crates ;
+- pipeline et stockage ;
+- configuration et logging ;
+- RPC, backfill et WebSocket ;
+- extraction Core, replay et matérialisation ;
+- PostgreSQL ;
+- validation Devnet ;
+- règles documentaires.
+
+Les anciens plans et prompts de migration ont été archivés sous `olddocs/archivekbot3/`.
+
+## 5. Capacités fonctionnelles alignées sur bot2 `0.4.6`
+
+### 5.1 Fondation et stockage
+
+- contrats d’erreur et identités de modules ;
+- configuration typée JSON et schéma embarqué ;
+- logging structuré ;
+- stockage canonique, observations, tables Core et decode/materialization ;
+- migrations PostgreSQL et diagnostics ;
+- pagination et requêtes de replay bornées.
+
+### 5.2 Transports et acquisition
+
+- JSON-RPC HTTP standard ;
+- WebSocket standard ;
+- pools et rôles d’endpoints ;
+- acquisition de signatures et transactions ;
+- adaptation canonique ;
+- simulation, soumission et confirmation ;
+- backfill HTTP, reprise et annulation coopérative.
+
+### 5.3 Pipeline
+
+- extraction Core ;
+- decode replay contextualisé ;
+- matérialisation optionnelle et idempotente ;
+- inspections stateful ;
+- corrélations et préflights Token-2022 ;
+- orchestration de preuves et postconditions.
+
+### 5.4 Solana Core et SPL
+
+Sont migrés jusqu’au périmètre historique de bot2 `0.4.6` :
+
+- Solana Core et programmes natifs ;
+- SPL Memo v1, v3 et v4 ;
+- SPL Token classique ;
+- SPL Associated Token Account ;
+- Token-2022 et extensions couvertes ;
+- registre SPL ElGamal dans les couches effectivement implémentées.
+
+Memo v1 et v3 restent non exécutables. Memo v4 reste la génération exécutable.
+
+## 6. Validations connues
+
+### 6.1 Base `pre.062`
+
+La base de migration a été déclarée validée avec :
+
+```text
+kb-pipeline-demo-scenarios :
+- 39 tests de bibliothèque
+- 1 test de binaire
+
+kb-app-demo-desktop :
+- 117 tests
+```
+
+Audits connus :
+
+```text
+General Rust rule audit: clean
+Rust export completeness audit: 0 candidate(s)
+Khadhroony workspace rule audit: clean
+```
+
+### 6.2 Devnet
+
+Ont été validés sur Solana Devnet :
+
+- System Transfer ;
+- Memo v4 ;
+- ATA classique ;
+- ATA Token-2022 ;
+- SPL Token `TransferChecked` ;
+- Token-2022 :
+  - `MintToChecked` ;
+  - `TransferChecked` ;
+  - `ApproveChecked` ;
+  - `Revoke` ;
+  - `BurnChecked` ;
+  - `FreezeAccount` ;
+  - `ThawAccount` ;
+  - `CloseAccount`.
+
+Les parcours couverts incluent simulation, confirmation opérateur, envoi, confirmation, insertion canonique, extraction Core, replay, matérialisation et idempotence.
+
+### 6.3 Validation exécutée pendant cet audit
+
+Avec le `Cargo.lock` de référence fourni séparément :
+
+```text
+General Rust rule audit: clean
+Rust export completeness audit: 0 candidate(s)
+Khadhroony workspace rule audit: clean
+```
+
+Les commandes Cargo n’ont pas pu être réexécutées dans l’environnement de production du delta, car le binaire `cargo` n’y est pas disponible. Les résultats historiques ne sont donc pas présentés comme nouvellement exécutés.
+
+## 7. Éléments non bloquants pour `0.4.6`
+
+### 7.1 Metaplex Token Metadata
+
+Le décodeur a été commencé dans bot2 `0.4.7`, puis migré dans bot3. La matérialisation historique doit être vérifiée et les éléments suivants restent à terminer après l’alignement `0.4.6` :
+
+- exécuteur ;
+- complément éventuel de matérialisation ;
+- orchestration pipeline ;
+- scénarios de démonstration ;
+- panneaux desktop ;
+- validations finales.
+
+Ces travaux appartiennent à la future version fonctionnelle `0.4.7`.
+
+### 7.2 Registre SPL ElGamal
+
+Le registre est implémenté dans certaines couches, mais n’est pas déclaré validé sur Devnet ou Mainnet.
+
+La validation dépend notamment :
+
+- de la confirmation du déploiement réseau ;
+- d’un générateur de preuve `PubkeyValidity` ;
+- d’un compte `Proof Context State` valide ;
+- d’un scénario opérateur fonctionnel.
+
+Cette absence de validation réseau ne bloque pas l’alignement sur bot2 `0.4.6`, car bot2 ne disposait pas non plus de cette validation réelle. Elle doit rester explicitement documentée.
+
+### 7.3 Capacités planifiées après `0.4.7`
+
+Ne bloquent pas `0.4.6` :
+
+- split de `kb-config` et configuration logging dédiée en `0.5.x` ;
+- complétion de `kb-wallet` en `0.5.x` ;
+- décodeur générique Anchor et surfaces complémentaires en `0.6.x` ;
+- protocoles Meteora, Raydium, Pump, Orca, Jupiter et autres ;
+- transports streaming avancés en `0.13.x`.
+
+## 8. Écarts architecturaux acceptés
+
+Les différences suivantes sont des choix bot3 validés, pas des régressions :
+
+- fusion des décodeurs, exécuteurs et matérialisateurs dans `kb-lib` ;
+- fusion des contrats et implémentations de stockage dans `kb-store` ;
+- renommage de `kb-rpc` en `kb-onchain-transport` ;
+- séparation des scénarios réutilisables dans `kb-pipeline-demo-scenarios` ;
+- maintien de `kb-app-demo-desktop` comme package mixte ;
+- maintien d’un wallet minimal avant sa complétion en `0.5.x`.
+
+## 9. Blocants ou vérifications à clôturer avant passage officiel à `0.4.6`
+
+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.
+
+La liste suivante remplace la précédente liste trop restrictive.
+
+### 9.1 Réconciliation de la checklist historique
+
+Avant toute conclusion finale :
+
+- 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.
+
+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`.
+
+### 9.2 Preuves Devnet du périmètre `0.4.6`
+
+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.
+
+Il faut :
+
+- 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
+```
+
+Exécuter également :
+
+- 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.
+
+## 10. Éléments explicitement reportés après `0.4.6`
+
+Ne doivent pas bloquer la version :
+
+- 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
+
+```text
+NOT_READY_FOR_0_4_6
+```
+
+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.
+
+La conclusion pourra devenir :
+
+```text
+READY_WITH_DOCUMENTED_EXCEPTIONS
+```
+
+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`.

olddocs/archivekbot3/docs/guides/DEVNET_0_4_6_OPERATOR_GUIDE.md

@@ -0,0 +1,75 @@
+<!-- file: docs/guides/DEVNET_0_4_6_OPERATOR_GUIDE.md -->
+<!-- version: 2 -->
+
+# Guide opérateur Devnet pour l’alignement `0.4.6`
+
+## 1. Objectif
+
+Ce guide regroupe les opérations minimales à valider avant le passage officiel de bot3 à `0.4.6`.
+
+## 2. Préparer le profil
+
+- sélectionner un profil Devnet valide ;
+- vérifier le RPC HTTP, le WebSocket et PostgreSQL ;
+- vérifier que `auto_initialize_schema` correspond à l’intention de la campagne ;
+- utiliser un wallet de démonstration persistant et financé par faucet Web.
+
+La clé privée ne doit jamais être copiée dans les logs ou l’interface.
+
+## 3. Vérifier PostgreSQL
+
+Depuis les fenêtres SQL :
+
+1. charger le diagnostic général ;
+2. vérifier les tables raw ;
+3. vérifier les tables Core ;
+4. vérifier les tables decode/materialization ;
+5. noter la version de migration et les anomalies d’index ou contraintes.
+
+## 4. Campagne raw → Core → Decode → Materialize
+
+1. Exécuter un backfill borné sur un Program ID ou une adresse connue.
+2. Vérifier l’insertion raw et les observations.
+3. Exécuter Core extraction sur les nouvelles lignes.
+4. Exécuter Decode replay avec les décodeurs adaptés.
+5. Activer la matérialisation.
+6. Vérifier les diagnostics et projections.
+7. Rejouer la même sélection.
+8. Confirmer l’idempotence et l’absence de duplications.
+
+## 5. Exécutions Solana Core déjà validées
+
+System Transfer et Memo v4 ont déjà été validés pendant `0.1.0-pre.062`. Leur réexécution n’est pas un prérequis systématique de `0.4.6`, sauf si une correction ultérieure touche directement leur exécuteur, leur transport, leur insertion canonique, leur replay ou leur matérialisation.
+
+La preuve active est conservée dans [`PRE_062_DEVNET_VALIDATION_REPORT.md`](../validation/PRE_062_DEVNET_VALIDATION_REPORT.md).
+
+## 6. Exécutions SPL déjà validées
+
+ATA classique, ATA Token-2022, SPL Token classique `TransferChecked` et les huit opérations publiques Token-2022 documentées ont déjà été validés pendant `0.1.0-pre.062`, avec PostgreSQL, insertion canonique, extraction Core, replay, matérialisation et idempotence.
+
+Ces scénarios ne doivent être rejoués que si une correction postérieure affecte leur parcours. La campagne `0.4.6` restante se concentre sur les écarts réellement modifiés et sur un backfill borné `mainnet_research`.
+
+## 7. WebSocket
+
+Exécuter intégralement [`WEBSOCKET_LIFECYCLE_VALIDATION_SCENARIO.md`](../validation/WEBSOCKET_LIFECYCLE_VALIDATION_SCENARIO.md).
+
+## 8. Résultats à consigner
+
+Pour chaque campagne, conserver :
+
+- profil et cluster ;
+- opération ;
+- comptes publics concernés ;
+- signature ;
+- résultat simulation ;
+- résultat envoi et confirmation ;
+- nombres raw/Core/decode/materialize ;
+- diagnostics ;
+- résultat du second replay ;
+- commande CLI ou RPC de vérification finale.
+
+## 9. Hors périmètre
+
+Metaplex Token Metadata complet n’est pas un critère de `0.4.6`. Il sera planifié et terminé dans `0.4.7`.
+
+Le registre ElGamal reste conditionnel tant que son déploiement réseau et les preuves nécessaires ne sont pas confirmés.

olddocs/archivekbot3/docs/validation/WEBSOCKET_LIFECYCLE_VALIDATION_SCENARIO.md

@@ -0,0 +1,116 @@
+<!-- file: docs/validation/WEBSOCKET_LIFECYCLE_VALIDATION_SCENARIO.md -->
+<!-- version: 2 -->
+
+# Validation du cycle de vie WebSocket desktop
+
+## Objectif
+
+Prouver qu’une session WebSocket appartient à l’application et non à la fenêtre `demo_ws`.
+
+## Préparation
+
+1. Configurer un endpoint WebSocket Devnet dans le profil utilisé.
+2. Activer une route de logs contenant au minimum `kb-app-demo-desktop` et `kb-onchain-transport` au niveau `debug`.
+3. Lancer :
+
+```bash
+cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json 2>&1 | tee /tmp/kbot3-pre075-ws.log
+```
+
+4. Ouvrir la fenêtre **WebSocket standard**.
+5. Rafraîchir les endpoints et vérifier qu’un rôle compatible est disponible.
+
+## Souscription principale recommandée
+
+Utiliser `logsSubscribe`, car elle permet de filtrer les transactions mentionnant un Program ID.
+
+| Champ       | Valeur                                                         |
+|-------------|----------------------------------------------------------------|
+| Rôle        | rôle WebSocket standard Devnet disponible                      |
+| Méthode     | `logsSubscribe`                                                |
+| Target      | vide                                                           |
+| Filter JSON | `{"mentions":["TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA"]}` |
+| Config JSON | `{"commitment":"confirmed"}`                                   |
+
+Le Program ID choisi est SPL Token classique. Il peut être remplacé par Token-2022 :
+
+```text
+TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb
+```
+
+## Scénario A — fermeture et réouverture de la fenêtre
+
+1. Cliquer **Souscrire**.
+2. Noter l’identifiant de subscription et vérifier :
+   - statut connecté ;
+   - `subscriptionCount = 1` ;
+   - méthode `logsSubscribe`.
+3. Attendre au moins une notification ou, à défaut, conserver la réponse de subscription.
+4. Fermer uniquement la fenêtre `demo_ws` avec le bouton de la fenêtre.
+5. Ne pas cliquer sur **Unsubscribe** ni **Déconnecter socket**.
+6. Attendre 15 à 30 secondes.
+7. Rouvrir **WebSocket standard** depuis le menu principal.
+8. Vérifier immédiatement :
+   - statut connecté ;
+   - même endpoint ;
+   - subscription toujours présente ;
+   - même identifiant distant ou identifiant remappé explicitement après reconnexion ;
+   - nouveaux messages reçus si le réseau en produit.
+
+### Critère de réussite
+
+La fenêtre restaurée affiche l’état réel de la session persistante. Aucun événement `Disconnected` ne doit être provoqué par la fermeture de `demo_ws`.
+
+## Scénario B — unsubscribe explicite
+
+1. Sélectionner la subscription active.
+2. Cliquer **Unsubscribe sélectionnée**.
+3. Vérifier :
+   - `subscriptionCount = 0` ;
+   - socket encore connectée ;
+   - message de désinscription ;
+   - absence de nouvelles notifications pour cette subscription.
+
+## Scénario C — nouvelle subscription puis déconnexion explicite
+
+1. Souscrire de nouveau avec le même filtre.
+2. Vérifier `subscriptionCount = 1`.
+3. Cliquer **Déconnecter socket**.
+4. Vérifier :
+   - statut déconnecté ;
+   - aucune subscription active ;
+   - événement ou diagnostic de déconnexion dans les logs.
+
+## Scénario D — arrêt global de l’application
+
+1. Souscrire de nouveau.
+2. Fermer la fenêtre `demo_ws`.
+3. Fermer ensuite la fenêtre principale de l’application.
+4. Vérifier dans `/tmp/kbot3-pre075-ws.log` que la déconnexion globale est exécutée.
+5. Vérifier que le processus Tauri se termine sans rester en arrière-plan.
+
+## Scénario optionnel — `programSubscribe`
+
+Pour observer les changements de comptes appartenant à Token-2022 :
+
+| Champ       | Valeur                                           |
+|-------------|--------------------------------------------------|
+| Méthode     | `programSubscribe`                               |
+| Target      | `TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb`    |
+| Filter JSON | vide                                             |
+| Config JSON | `{"commitment":"confirmed","encoding":"base64"}` |
+
+Cette souscription peut être très active. Les limites de débit et de taille de l’interface doivent rester fonctionnelles.
+
+## Preuves à archiver
+
+Fournir une archive contenant :
+
+- `/tmp/kbot3-pre075-ws.log` ;
+- copie du statut avant fermeture ;
+- copie du statut après réouverture ;
+- identifiants de subscription ;
+- résultat unsubscribe ;
+- résultat disconnect ;
+- heure approximative de chaque étape ;
+- anomalie éventuelle et reproduction minimale.