Ce fichier est temporaire. Il doit disparaître lorsque la migration est close, que la documentation active décrit uniquement `khadhroony-bot3`, et que la version du workspace est alignée sur `0.4.7`.
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`.
## Principes de clôture
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.
- Une case n’est cochée qu’après preuve par recherche, compilation, test, audit, requête SQL ou validation runtime.
- Les noms, modules et documents actifs doivent décrire Bot3 comme le produit courant, sans récit permanent de migration depuis Bot2.
- Les protocoles applicatifs Pump.fun, Raydium, Meteora, Jupiter, autres AMM et launchpads restent hors périmètre tant que Solana Core, SPL, Metaplex Token Metadata et Anchor ne sont pas clôturés.
- Les rappels d’amélioration non bloquants doivent être déplacés vers `docs/IDEA_REMINDERS.md`, pas conservés dans cette checklist.
- La documentation finale décrit l’état courant. Elle ne doit pas accumuler un journal de changements par version dans les README.
## 1. Preuves déjà acquises
## État validé de `0.1.0-pre.061`
- [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.
- [x] Suite ciblée complète : toutes les crates principales réussissent leurs tests.
- [x] Aucune erreur de matérialisation observée pendant la campagne propre.
- [x] Les trois erreurs supplémentaires du replay ont été identifiées comme timeouts transitoires du pool PostgreSQL, distincts des échecs fonctionnels de décodage.
- [x] Revalider les suites après les correctifs `pre.061-delta-fix-004` et `pre.061-delta-fix-005` : 116 tests desktop, 625 tests `kb-lib`, suites consolidées et replay propre.
## 2. Nomenclature et données persistées
# 0. `0.1.0-pre.062` — validation Devnet
- [ ] 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.
- [x] Séparer les DSN PostgreSQL Mainnet, Devnet et tests par variables d’environnement.
- [x] Résoudre les profils Devnet sans dépendre du nom historique `local_devnet`.
- [x] Autoriser une sélection explicite par l’interface ou `KB_DEVNET_PROFILE` pour les scénarios CLI/tests.
- [x] À l’ouverture des fenêtres Exécution Solana Core et Exécution SPL, connecter la base du profil sélectionné.
- [x] Créer les tables manquantes uniquement lorsque `auto_initialize_schema` l’autorise.
- [x] Refuser l’activation des commandes Devnet lorsque PostgreSQL est désactivé, non PostgreSQL ou incomplet.
- [x] Valider visuellement la préparation de la base Devnet dans les deux fenêtres : seul le profil `local_devnet` est proposé et les 13 tables PostgreSQL sont créées ou détectées.
- [ ] Exécuter les scénarios Devnet selon `docs/DEVNET_EXECUTION_GUIDE.md`.
- [x] Préparer le terminal Bash de contrôle et stocker les preuves sous `/tmp/devnet-validation/pre.062`.
- [x] Vérifier les CLI Solana/Agave et le genesis hash Devnet.
- [x] Financer le wallet persistant `local_devnet` via faucet Web.
- [x] Valider le transfert System de bout en bout : simulation, envoi, confirmation, balances, backfill, Core extraction et Decode replay sans erreur.
- [ ] Valider registre ElGamal selon les prérequis disponibles.
## 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.
# 1. Nettoyage structurel et nomenclature
## 4. Cycle de vie WebSocket
## 1.0 Convention globale des identités persistées
Exécuter le scénario [`docs/validation/WEBSOCKET_LIFECYCLE_VALIDATION_SCENARIO.md`](docs/validation/WEBSOCKET_LIFECYCLE_VALIDATION_SCENARIO.md).
- [x]Arrêter la notation hiérarchique par points pour les identités runtime et les codes persistés.
- [x]Ajouter la documentation normative `docs/OPERATION_NAMING_CONVENTION.md`.
- [x]Ajouter la matrice machine-readable `test-fixtures/contract-matrices/OPERATION_NAMING_MATRIX.json`.
- [x]Migrer les constantes et attentes actives de Solana Core, SPL Memo, SPL Token, Token-2022, ATA, registre ElGamal et Metaplex vers la notation canonique.
- [x]Ajouter une règle courte renvoyant vers la documentation et la matrice.
- [ ]Purger ou recréer la base `solana_devnet`, puis rejouer les preuves System Transfer et Memo v4 avec les nouveaux codes.
- [ ]Ajouter un audit final empêchant la réintroduction des anciennes valeurs contractuelles.
- [x]Corriger la frontière entre codes de registre `lower_snake_case` et identités persistées en notation par points.
- [x] Corriger le test de matrice pour rester propre sous Clippy sans assertion constante fausse.
- [x] Corriger la référence IDL Metaplex vers le nom canonique local.
- [x] Documenter quelles surfaces actives disposent réellement d’une IDL officielle et lesquelles reposent sur des crates d’interface.
- []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 restentactives.
- []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
## 1.1 Règles
- [ ] 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.
- [x] Reprendre dans les règles Bot3 toutes les règles Bot2 encore applicables.
- [x] Remplacer les anciens fichiers de règles par `docs/rules/RULES_GENERAL.md`, `docs/rules/RULES_RUST.md`, `docs/rules/RULES_SPECIFIC_KHADHROONY.md` et un index `RULES.md`.
- [x] Adapter le workflow des deltas à Bot3.
- [ ] Effectuer une dernière lecture croisée des règles portant sur imports, réexports, façades, Tauri, TS-RS, logging, versionnement et archives.
- [ ] Supprimer de cette checklist toute demande de justification historique sans valeur normative.
## 6. PostgreSQL et pipeline
## 1.2 Anciennes crates, imports et chemins
- [ ] 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`.
- [x] Confirmer l’absence d’import, réexport ou dépendance active vers les anciennes crates `kb_executor_*`.
- [x] Confirmer l’absence d’import, réexport ou dépendance active vers les anciennes crates `kb_decoder_*`.
- [x] Confirmer l’absence d’import, réexport ou dépendance active vers les anciennes crates `kb_materializer_*`.
- [x] Confirmer l’absence d’import, réexport ou dépendance active vers l’ancienne crate `kb_model`.
- [x] Confirmer l’absence de dépendance ou de crate `kb_store_pg`.
- [x] Confirmer l’absence de dépendance ou de crate `kb_store_core`.
- [x] Confirmer qu’aucune ancienne crate supprimée n’a été recréée sous un autre chemin.
- [x] Auditer `kb-app-demo-desktop/**/*.rs` pour les anciens chemins structurels actifs.
- [x] Vérifier les bindings TS-RS générés : aucun ancien chemin de crate actif n’est exporté.
- [x] Classer les anciennes chaînes runtime et les remplacer par les identités consolidées `kb-lib.decoder.*`, `kb-lib.executor.*` et `kb-lib.materializer.*`.
- [ ] Réécrire lors de la refonte documentaire finale les commentaires et documents qui racontent encore la consolidation depuis les anciennes crates.
## 7. Validation desktop des surfaces `0.4.6`
Contrôles exécutés : aucune correspondance structurelle `ancienne_crate::`, aucune dépendance Cargo correspondante et aucun répertoire de crate supprimée.
- [x] Vérifier les matrices actives ; corriger la dernière commande historique dans `SPL_TOKEN_2022_MATRIX.json`.
- [x] Découpler les assertions structurelles des matrices des compteurs globaux et volatils de `cargo test`.
- [ ] Réauditer progressivement chaque matrice active lors de la reprise de sa surface ; les preuves opérateur restent informatives et les invariants doivent être dérivés des lignes de matrice et des registres compilés.
- [ ] Refaire l’audit Python de nomenclature lors de la stabilisation finale des helpers de migration.
- [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`.
# 2. Frontend et application desktop
## 2.1 Menu, contrôles et HTML
- [x] Ordre principal du menu corrigé : Configuration, Transport et collecte, Pipeline, SQL, Exécution.
- [ ] Vérifier une dernière fois les séparateurs du menu.
- [ ] Supprimer les entrées de menu, boutons, onglets et liens sans backend accessible.
- [ ] Vérifier qu’une sortie ne possède qu’une seule paire de contrôles Copier/Effacer.
- [x] Vérifier toutes les balises HTML après les derniers remaniements ; les quatre conteneurs finaux manquants ont été refermés et le parseur HTML local ne signale plus de déséquilibre.
- [ ] Vérifier que chaque option HTML correspond à une commande Tauri et à un scénario backend réellement accessible.
## 2.2 Viewers et journaux
- [x] HTTP utilise un composant texte borné pour le résultat brut.
- [x] WebSocket utilise un composant texte/log borné et persistant pendant la session.
- [x] Extraction Core place paramètres, journaux et résultats dans une structure cohérente.
- [x] Réserver les viewers JSON au JSON structuré nécessitant exploration ou formatage ; HTTP endpoints/résultat et WebSocket statut/endpoints utilisent désormais `@andypf/json-viewer`.
- [x] Utiliser des textareas pour texte brut, logs et diagnostics concaténés ; les messages WebSocket restent textuels avec Copier/Effacer.
- [ ] Vérifier ce contrat dans Decode replay, Exécution Solana Core et Exécution SPL.
- [x] Convertir Statut et Endpoints WebSocket en viewers JSON structurés après contrôle runtime.
- [x] Matérialisation : aucune erreur de matérialiseur observée.
- [x] PostgreSQL : reconstruction et persistance validées.
- [x] Identifier les 3 erreurs de campagne résiduelles comme timeouts transitoires du pool PostgreSQL, sans échec final de décodeur persisté.
- [x] Séparer dans le résumé `failedInputs` des erreurs d’orchestration ou de stockage via `processingErrorInputs`.
- [ ] Dimensionner le pool et ajouter un retry borné pour les timeouts transitoires avant la campagne finale.
## 7.2 Transport et infrastructure
- [x] Backfill HTTP validé en runtime.
- [x] HTTP JSON-RPC validé en runtime.
- [x] WebSocket validé en runtime.
- [x] Logging validé sur `mainnet_research`.
- [x] Configuration principale chargée et utilisée en runtime.
- [ ] Valider les profils `local_devnet` et `mainnet` lors de la campagne finale.
### 7.2.1 Stabilisation frontend avant `0.1.0-pre.062`
- [x] Corriger les quatre conteneurs HTML finaux signalés par RustRover.
- [x] Remplacer les favicons absentes par `imgs/logo.png`.
- [x] Valider visuellement les fenêtres Config, HTTP, WebSocket, Backfill, Core extraction, Decode replay et SQL.
- [x] Séparer les JSON viewers des sorties textuelles et conserver Copier/Effacer sur les sorties sans viewer selon leur volatilité.
- [x] Rendre le journal des annotations responsive et paginé avec DataTables.
- [x] Étendre DataTables aux tableaux de diagnostic SQL.
- [x] Corriger les avertissements frontend connus : API Rollup `names`, exception locale, initialiseur redondant et sélecteur de custom element.
- [ ] Revalider le frontend en runtime après application du dernier correctif.
# 7.3 Exécution
- [ ] Vérifier Exécution Solana Core via la fenêtre desktop et les scénarios Devnet.
- [ ] Vérifier Exécution SPL via la fenêtre desktop et les scénarios Devnet.
- [ ] Comparer les options de `demo_execution_spl.html` aux scénarios réellement supportés.
- [ ] Supprimer les options mortes.
- [ ] Raccorder ou documenter `execute_devnet_spl_token_lifecycle` s’il reste non exposé par l’application.
- [ ] Vérifier simulation, envoi, progression, résumé et diagnostics.
- [ ] Vérifier replay post-exécution et matérialisation pour chaque famille supportée.
# 8. Guide Devnet des exécuteurs
Créer une documentation dédiée, distincte des README généraux :
- [x] Créer la première version de `docs/DEVNET_EXECUTION_GUIDE.md` avant les tests ; la compléter et la corriger pendant les campagnes Devnet.
- [ ] Documenter la création en ligne de commande d’un wallet de démonstration.
- [ ] Documenter la récupération de la pubkey.
- [x] Imposer l’utilisation d’un faucet Web pour financer le wallet Devnet ; ne pas dépendre de `solana airdrop`, non fonctionnel dans l’environnement de validation.
- [ ] Documenter les champs à saisir dans l’interface desktop.
- [ ] Documenter chaque scénario Solana Core étape par étape.
- [ ] Documenter chaque scénario SPL étape par étape.
- [ ] Documenter les préconditions, comptes, signers, frais estimés et résultats attendus.
- [ ] Documenter le replay et les projections à vérifier après chaque exécution.
- [ ] Ajouter ensuite les scénarios Metaplex Token Metadata.
# 8.1 Convention et admission des IDL
- [x] Documenter la convention `<PROGRAM_ID>.<protocol_type>.<protocol_code>[.<version>].json` dans `idls/001.README.md`.
- [x] Renommer l’IDL active Metaplex Token Metadata avec le segment `metadata`.
- [x] Conserver le contenu JSON des IDL strictement inchangé.
- [x] Décider que la classification et le renommage des autres IDL seront effectués au moment où leur décodeur ou exécuteur devient actif.
- [ ] Maintenir progressivement un inventaire des sources, versions ou commits des IDL actives.
# 8.1 Ordre metadata après validation des exécuteurs existants
- [ ] Créer le pipeline metadata général et la fenêtre desktop spécialisée `demo_execution_metadata`.
- [ ] Traiter ensuite le programme Metaplex Token Metadata et son exécuteur.
- [ ] Décider ensuite de la création de `kb-offchain-transport` comme transport off-chain général : metadata HTTP(S)/IPFS/Arweave, prix et taux, APIs Jupiter et autres fournisseurs ; évaluer séparément les opérations off-chain mutables.
# 9. Metaplex Token Metadata — décodeur
- [x] IDL JSON local présent et renommé selon `<PROGRAM_ID>.<protocol_type>.<protocol_code>.json`.
- [ ] Vérifier l’absence de secrets dans l’archive.
- [ ]Vérifier l’absence de `target`, `node_modules`, `dist`, logs, bases, `.env`, `Cargo.lock`, `package-lock.json` et bindings générés exclus par les règles de livraison.
- [ ]Valider Exécution Solana Core et Exécution SPL sur Devnet.
- [ ]Valider Metaplex Executor et replay post-exécution sur Devnet.
- [ ] Valider configuration, logging et PostgreSQL sur les profils requis.
- [ ] Vérifier que les protocoles applicatifs différés sont documentés hors de cette checklist.
# 15. Critères de clôture
- [ ] Aucun import ou chemin d’ancienne crate ne subsiste.
- [ ] Convention Token-2022 définitivement appliquée et, si nécessaire, données dérivées migrées ou rejouées.
- [ ] Tauri ne contient plus de logique métier substantielle.
- [ ] UI sans contrôle mort ou dupliqué.
- [ ] Configuration et secrets validés.
- [ ] Logging propre sur tous les profils requis.
- [ ] Reconstruction PostgreSQL documentée et reproductible.
- [ ] Solana Core, SPL, Metaplex Token Metadata et Anchor au niveau requis avant protocoles applicatifs.
- [ ] Exécuteurs supportés validés sur Devnet.
- [ ] Documentation active entièrement réécrite pour Bot3.
- [ ]`USAGE.md` disponibles pour les surfaces publiques et binaires.
- [ ] Workspace aligné sur `0.4.7`.
- [ ] Cette checklist est supprimée.
### 0.1.0-pre.062 — séparation du socle Devnet commun
- [x] Garder `kb-app-demo-desktop/src/tauri.rs` comme couche mince de wrappers `#[tauri::command]`.
- [x] Déplacer `DemoExecutionDevnetStoreReadinessPayload`, `bounded_u32` et `prepare_devnet_profile_store` dans `kb-app-demo-desktop/src/demo_devnet_common.rs`.
- [x] Revalider `cargo fmt --all`, `cargo test -p kb-app-demo-desktop -p kb-pipeline-demo-scenarios`, `cargo check --workspace` et `cargo clippy --all-targets` : 117 tests desktop et 37 tests scénarios réussis.
- [x] Renommer l’en-tête du menu desktop `Exécution` en `Exécution Devnet`.
- [x] Déplacer l’idée de profils de logging indépendants vers `docs/IDEA_REMINDERS.md` sans ouvrir de développement dans `pre.062`.
- [x] Corriger l’audit d’ordre des exports pour le cas lexical Token-2022 sans imposer un réordonnancement contraire à rustfmt.
- [x] Aligner les tests `kb-store` sur `materializer.transaction.annotations`.
- [x] Réorganiser `docs/DEVNET_EXECUTION_GUIDE.md` autour de commandes communes référencées et de scénarios Devnet séparé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.
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.
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 :
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.