4.1 KiB
Architecture du pipeline
1. Responsabilité
kb-pipeline coordonne des opérations généralistes qui traversent plusieurs crates sans devenir propriétaire de leurs implémentations : transport, stockage, contrats de décodage, matérialisation et exécution. Il ne dépend d’aucun scénario, wallet ou actif propre à un réseau de démonstration.
2. Familles de traitements
2.1 Backfill
Le backfill sélectionne des signatures ou transactions selon une adresse, un programme, un rôle d’endpoint et des bornes explicites. Il gère progression, reprise, annulation et résultats partiels selon les contrats exposés par le pipeline.
2.2 Extraction Core
L’extraction Core transforme les transactions stockées en représentations d’instructions contextualisées nécessaires aux décodeurs. Elle constitue une phase distincte du replay de décodage.
2.3 Replay de décodage
Le replay sélectionne des candidats, applique les décodeurs compatibles de kb-lib, conserve diagnostics et preuves, puis déclenche les matérialisateurs demandés. La reprise doit préserver l’idempotence et les frontières de campagne.
2.4 Traitements stateful
Les modules stateful corrèlent instructions, comptes, états précédents et résultats de transaction lorsque le protocole l’exige. Les surfaces SPL Token, ATA, Token-2022 et registre ElGamal disposent de traitements spécialisés à des niveaux différents.
2.5 Préflight et exécution
Le pipeline assemble les contrôles préalables, plans préparés, signataires, preuves, simulation et validation postérieure. Les exécuteurs restent définis dans kb-lib ; le pipeline orchestre leur utilisation.
3. Dépendances fonctionnelles
kb-onchain-transport -> acquisition et appels RPC
kb-store -> lecture/écriture canonique et replay
kb-lib -> contrats et implémentations métier
kb-config -> profils et paramètres opérationnels
kb-logging -> observabilité
kb-wallet -> signataires lorsque requis
4. Scénarios de démonstration
kb-pipeline-demo-scenarios contient les fixtures, aides de campagne et tests automatisés spécifiques à Devnet ou Testnet. Ses tests peuvent reproduire les mêmes parcours fonctionnels que les démonstrations UI afin de fournir une validation automatisée parallèle, sans retirer ni déplacer les scénarios Devnet/Testnet de kb-app-demo-desktop.
Cette crate peut préparer des wallets temporaires, demander des airdrops, créer des mints ou comptes de test, enchaîner plusieurs opérations et réunir les preuves d’une campagne réseau. Ces responsabilités spécifiques aux validations réseau ne doivent pas remonter dans kb-pipeline.
Le binaire kb-pipeline-demo-scenarios-cli est actuellement un outil ciblé de préparation des fixtures SPL Token-2022 réutilisées par les démonstrations Devnet. Son existence ne signifie pas que chaque scénario doit être exposé par un CLI ni que le desktop doit consommer ses scénarios.
kb-app-demo-desktop conserve ses commandes, états et parcours UI de démonstration Devnet/Testnet. Les tests parallèles de kb-pipeline-demo-scenarios vérifient des parcours équivalents à partir des APIs généralistes ; ils ne remplacent pas les démonstrations desktop. La dépendance inverse de kb-pipeline vers les scénarios reste interdite.
5. Contrats de preuve
Les tests unitaires, tests d’intégration et matrices de test-fixtures/contract-matrices/ participent à la preuve contractuelle. Une matrice peut être à la fois une référence lisible et une fixture chargée par le code de test ; elle ne doit pas être dupliquée sous docs/.
6. Limites connues
- Le registre ElGamal n’est pas déclaré validé sur Devnet ou Mainnet.
- La couverture automatisée parallèle des scénarios desktop reste à étendre progressivement dans
kb-pipeline-demo-scenarios, notamment pendant la série0.5.x. - La documentation détaillée des APIs publiques du pipeline sera produite dans
kb-pipeline/USAGE.mdaprès inventaire des exports.