56 lines
2.9 KiB
Markdown
56 lines
2.9 KiB
Markdown
<!-- file: docs/architecture/PIPELINE_ARCHITECTURE.md -->
|
||
<!-- version: 1 -->
|
||
|
||
# Architecture du pipeline
|
||
|
||
## 1. Responsabilité
|
||
|
||
`kb-pipeline` coordonne des opérations qui traversent plusieurs crates sans devenir propriétaire de leurs implémentations : transport, stockage, contrats de décodage, matérialisation et exécution.
|
||
|
||
## 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
|
||
|
||
```text
|
||
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` doit contenir les scénarios réutilisables hors UI. `kb-app-demo-desktop` adapte leurs requêtes, progrès et résultats en payloads Tauri. Une dépendance à l’application desktop dans le sens inverse serait incorrecte.
|
||
|
||
## 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.
|
||
- Certains scénarios restent à rendre pleinement autonomes hors desktop.
|
||
- La documentation détaillée des APIs publiques du pipeline sera produite dans `kb-pipeline/USAGE.md` après inventaire des exports.
|