Sasedev/khadhroony-bot3
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
ec07ddbd801609b1afedd32b1f8230a205c9ab7d
khadhroony-bot3/olddocs/archivekbot3/docs/audits/V0_4_6_ALIGNMENT_AUDIT.md
SinuS Von SifriduS ae85852648 v0.4.6
2026-08-01 21:27:14 +02:00

15 KiB
Raw Blame History

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 :

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 :

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 :

kb-pipeline-demo-scenarios :
- 39 tests de bibliothèque
- 1 test de binaire

kb-app-demo-desktop :
- 117 tests

Audits connus :

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 :

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 :

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

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 :

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.

Reference in New Issue View Git Blame Copy Permalink