Sasedev/khadhroony-solana-project
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v0.0.3-pre.005

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-14 11:42:19 +02:00
parent d33911f925
commit 63bb90a46d
13 changed files with 699 additions and 139 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
docs/architecture/002-LAYERS_AND_DEPENDENCIES.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/002-LAYERS_AND_DEPENDENCIES.md -->
<!-- version: 2 -->
<!-- version: 3 -->
# Couches et dépendances KSP
@@ -18,7 +18,11 @@ Positionnement actuellement retenu :
- `ksp-core-lib` — primitives et contrats fondamentaux réellement transversaux, type d'erreur commun KSP et responsabilité autrefois séparée des identifiants de programmes ;
- `ksp-interface-lib` — façade KSP des interfaces/wire on-chain nécessaires aux autres bibliothèques ;
- `ksp-config-lib` — contrats, chargement/résolution et manipulation autorisée de la configuration et des profils ;
- `ksp-logging-lib` — fondations communes de logging/tracing.
- `ksp-logging-lib` — façade commune de logging/tracing, propriétaire de l'initialisation et des dépendances directes `tracing`, `tracing-appender` et `tracing-subscriber`.
`ksp-logging-lib` peut dépendre de `ksp-core-lib` pour le contrat commun `Error` / `Result`. La relation inverse n'est pas requise : `ksp-core-lib` reste sans dépendance logging tant qu'aucun besoin réel ne la justifie.
Les crates KSP contenant du comportement/runtime peuvent dépendre directement de `ksp-logging-lib` afin de produire des logs structurés aux niveaux `error`, `warn`, `info`, `debug` et `trace`. Les crates `*-api` purement déclaratives n'ajoutent pas cette dépendance sans comportement réel à logger.
Une bibliothèque N1 ne doit pas dépendre d'une fonctionnalité métier située dans une couche supérieure.
@@ -68,9 +72,9 @@ W1 :
Les consommateurs des notifications W1 décident eux-mêmes s'ils doivent décoder, matérialiser ou effectuer un autre traitement.
### W2
### Workers de processing futurs
W2 est réservé à une phase ultérieure de processing. Son contrat précis sera défini après stabilisation du décodage, de la matérialisation et du store. Il ne doit pas être confondu avec W1.
Le processing continu n'est plus modélisé comme un unique W2. La direction actuelle sépare `ksp-worker-core-processor`, `ksp-worker-generic-materializer` et `ksp-worker-domain-projector` afin de respecter les frontières durables raw -> Core -> matérialisation générique -> projections de domaine. Leur détail sera repris dans la tranche consacrée aux workers/data.
## N4 — Exécutables