0.5.1-pre.002
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/architecture/ARCHITECTURE.md -->
|
||||
<!-- version: 6 -->
|
||||
<!-- version: 7 -->
|
||||
|
||||
# Architecture générale
|
||||
|
||||
@@ -12,7 +12,7 @@ configuration ─────┐
|
||||
logging ───────────┼──────────────┐
|
||||
program IDs ───────┘ │
|
||||
v
|
||||
transport -> store -> pipeline -> kb-lib
|
||||
transport -> store -> pipeline -> ks-lib
|
||||
│ │
|
||||
v v
|
||||
demo scenarios wallet/signers
|
||||
@@ -28,32 +28,32 @@ Cette représentation indique les relations dominantes. Elle ne remplace pas le
|
||||
|
||||
### 2.1 Fondations
|
||||
|
||||
- `kb-core` fournit les erreurs et identités transversales minimales.
|
||||
- `kb-config` charge, résout et valide la configuration.
|
||||
- `kb-logging` initialise le logging et le tracing.
|
||||
- `kb-program-ids` centralise les identifiants de programmes et comptes connus.
|
||||
- `ks-core` fournit les erreurs et identités transversales minimales.
|
||||
- `ks-config` charge, résout et valide la configuration.
|
||||
- `ks-logging` initialise le logging et le tracing.
|
||||
- `ks-program-ids` centralise les identifiants de programmes et comptes connus.
|
||||
|
||||
### 2.2 Noyau métier
|
||||
|
||||
`kb-lib` contient quatre familles principales :
|
||||
`ks-lib` contient quatre familles principales :
|
||||
|
||||
- modèles et contrats partagés ;
|
||||
- décodeurs ;
|
||||
- exécuteurs ;
|
||||
- matérialisateurs.
|
||||
|
||||
La façade publique est constituée par les réexports de `kb-lib/src/lib.rs`. Les modules internes conservent leurs frontières et leurs conventions de nommage.
|
||||
La façade publique est constituée par les réexports de `ks-lib/src/lib.rs`. Les modules internes conservent leurs frontières et leurs conventions de nommage.
|
||||
|
||||
### 2.3 Acquisition et stockage
|
||||
|
||||
- `kb-onchain-transport` fournit les clients HTTP/WebSocket, pools, rôles d’endpoints, méthodes RPC standard et contrats liés à l’exécution RPC.
|
||||
- `kb-store` regroupe les contrats store-neutral et l’implémentation PostgreSQL.
|
||||
- `ks-onchain-transport` fournit les clients HTTP/WebSocket, pools, rôles d’endpoints, méthodes RPC standard et contrats liés à l’exécution RPC.
|
||||
- `ks-store` regroupe les contrats store-neutral et l’implémentation PostgreSQL.
|
||||
|
||||
Les transports n’effectuent pas la matérialisation métier. Le stockage ne décide pas quelle surface protocolaire doit être décodée.
|
||||
|
||||
### 2.4 Orchestration
|
||||
|
||||
`kb-pipeline` orchestre :
|
||||
`ks-pipeline` orchestre :
|
||||
|
||||
- backfill ;
|
||||
- extraction Core ;
|
||||
@@ -62,14 +62,14 @@ Les transports n’effectuent pas la matérialisation métier. Le stockage ne d
|
||||
- corrélation stateful ;
|
||||
- préflight et orchestration d’exécution pour les surfaces prises en charge.
|
||||
|
||||
Il dépend des contrats de `kb-lib`, des données de `kb-store` et des capacités de `kb-onchain-transport` sans absorber leurs responsabilités.
|
||||
Il dépend des contrats de `ks-lib`, des données de `ks-store` et des capacités de `ks-onchain-transport` sans absorber leurs responsabilités.
|
||||
|
||||
### 2.5 Démonstrations et applications
|
||||
|
||||
- `kb-pipeline-demo-scenarios` fournit les fixtures et campagnes réseau réutilisables spécifiques aux validations Devnet/Testnet. Les scénarios réutilisables doivent être appelables sans dépendre du desktop.
|
||||
- Le binaire `kb-pipeline-demo-scenarios-cli` reste un outil ciblé ; son existence n’impose pas d’exposer chaque scénario par un CLI.
|
||||
- `kb-app-demo-desktop` est une crate mixte : bibliothèque Tauri et binaire desktop. Les commandes et projections UI y restent, tandis que la logique de scénario réutilisable doit être déléguée à `kb-pipeline-demo-scenarios`. Le reliquat éventuel de scénarios encore déclarés directement dans le desktop sera audité en `0.5.4`.
|
||||
- `kb-wallet` fournit actuellement une frontière limitée de wallet temporaire et de signataire. Elle devient `ks-wallet` en `0.5.1`, puis sa restructuration fonctionnelle est planifiée en `0.5.2`.
|
||||
- `ks-pipeline-demo-scenarios` fournit les fixtures et campagnes réseau réutilisables spécifiques aux validations Devnet/Testnet. Les scénarios réutilisables doivent être appelables sans dépendre du desktop.
|
||||
- Le binaire `ks-pipeline-demo-scenarios-cli` reste un outil ciblé ; son existence n’impose pas d’exposer chaque scénario par un CLI.
|
||||
- `kb-app-demo-desktop` est une crate mixte : bibliothèque Tauri et binaire desktop. Les commandes et projections UI y restent, tandis que la logique de scénario réutilisable doit être déléguée à `ks-pipeline-demo-scenarios`. Le reliquat éventuel de scénarios encore déclarés directement dans le desktop sera audité en `0.5.4`.
|
||||
- `ks-wallet` fournit actuellement une frontière limitée de wallet temporaire et de signataire. Elle devient `ks-wallet` en `0.5.1`, puis sa restructuration fonctionnelle est planifiée en `0.5.2`.
|
||||
|
||||
## 3. Flux principal de données
|
||||
|
||||
@@ -77,18 +77,18 @@ Il dépend des contrats de `kb-lib`, des données de `kb-store` et des capacité
|
||||
Solana RPC / WebSocket
|
||||
│
|
||||
v
|
||||
kb-onchain-transport
|
||||
ks-onchain-transport
|
||||
│
|
||||
v
|
||||
kb-store (données brutes/canoniques)
|
||||
ks-store (données brutes/canoniques)
|
||||
│
|
||||
v
|
||||
kb-pipeline
|
||||
ks-pipeline
|
||||
│
|
||||
├── extraction Core
|
||||
├── sélection des décodeurs
|
||||
├── décodage via kb-lib
|
||||
├── matérialisation via kb-lib
|
||||
├── décodage via ks-lib
|
||||
├── matérialisation via ks-lib
|
||||
└── stockage des résultats
|
||||
```
|
||||
|
||||
@@ -96,11 +96,11 @@ L’exécution suit un flux séparé : intention typée, construction, préfligh
|
||||
|
||||
## 4. Frontières obligatoires
|
||||
|
||||
- Les IDs canoniques ne doivent pas être dispersés lorsqu’ils appartiennent au registre de `kb-program-ids`.
|
||||
- Les APIs publiques de modèles, décodeurs, exécuteurs et matérialisateurs sont exposées par `kb-lib`.
|
||||
- Les IDs canoniques ne doivent pas être dispersés lorsqu’ils appartiennent au registre de `ks-program-ids`.
|
||||
- Les APIs publiques de modèles, décodeurs, exécuteurs et matérialisateurs sont exposées par `ks-lib`.
|
||||
- Les commandes Tauri et payloads frontend spécifiques restent dans `kb-app-demo-desktop`.
|
||||
- Les scénarios réseau réutilisables spécifiques à Devnet/Testnet appartiennent à `kb-pipeline-demo-scenarios`, future `ks-pipeline-demo-scenarios`. `kb-app-demo-desktop` doit se limiter à l’adaptation Tauri, aux payloads UI, à la présentation et à l’appel de ces scénarios ; les doublons résiduels seront réconciliés en `0.5.4`.
|
||||
- Toute primitive ou orchestration réellement généraliste, indépendante de l’UI et d’une campagne de démonstration précise, appartient à `kb-pipeline` ou à la crate métier propriétaire.
|
||||
- Les scénarios réseau réutilisables spécifiques à Devnet/Testnet appartiennent à `ks-pipeline-demo-scenarios`, future `ks-pipeline-demo-scenarios`. `kb-app-demo-desktop` doit se limiter à l’adaptation Tauri, aux payloads UI, à la présentation et à l’appel de ces scénarios ; les doublons résiduels seront réconciliés en `0.5.4`.
|
||||
- Toute primitive ou orchestration réellement généraliste, indépendante de l’UI et d’une campagne de démonstration précise, appartient à `ks-pipeline` ou à la crate métier propriétaire.
|
||||
- Les fixtures contractuelles communes restent sous `test-fixtures/contract-matrices/` lorsqu’elles sont consommées par plusieurs tests.
|
||||
- Les archives documentaires ne participent ni au build ni aux décisions normatives.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user