Files
khadhroony-bot3/docs/audits/PRE_0_4_6_STATIC_CODE_AUDIT.md
2026-08-01 11:28:43 +02:00

2.3 KiB
Raw Blame History

Audit statique préalable à 0.4.6

Résumé

Laudit statique a été exécuté sur larchive 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 nest 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 nest donc pas encore uniquement une couche mince de wrappers #[tauri::command].

Décision

Avant 0.4.6, déplacer lorchestration 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 lassemblage Tauri, les wrappers de commandes, louverture des fenêtres et les adaptations minimales derreur ou détat.

Vérifications runtime encore nécessaires

Laudit 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.