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

v0.0.3-pre.007

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-14 12:14:00 +02:00
parent 2cb9f809b7
commit 3b5d1a8f7a
13 changed files with 1447 additions and 121 deletions
Download Patch File Download Diff File Expand all files Collapse all files

36
docs/plans/001-V0_0_3_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/001-V0_0_3_PLAN.md -->
<!-- version: 10 -->
<!-- version: 11 -->
# Plan KSP 0.0.3
@@ -13,7 +13,7 @@ Transformer le brainstorming KSP en architecture, règles, inventaire et plan su
- `pre.002` — inventaire initial des composants ;
- `pre.003` — graphe de dépendances, correction de l'inventaire et stabilisation des frontières de composition.
Les tranches `pre.004` (Wire/Program), `pre.005` (Execution/Policy) et `pre.006` (Data/Materialization/Store) sont maintenant livrées séparément afin de conserver des prereleases de planification bornées.
Les tranches `pre.004` (Wire/Program), `pre.005` (Execution/Policy), `pre.006` (Data/Materialization/Store) et `pre.007` (Acquisition/Workers/Jobs) sont maintenant livrées séparément afin de conserver des prereleases de planification bornées.
## Décisions structurantes actuelles
@@ -33,7 +33,8 @@ Les tranches `pre.004` (Wire/Program), `pre.005` (Execution/Policy) et `pre.006`
- `ksp-store-api` reste indépendant de Program/Materializer/Transport.
- Les workers/jobs spécialisés convertissent explicitement les modèles entre transport, processing et persistence.
- `ksp-store-api` possède les notifications canoniques de données persistées ; leur transport concret reste séparé.
- Aucun `ksp-data-api`, `ksp-pipeline-lib`, `ksp-scenario-api`, `ksp-onchain-transport-api`, `ksp-offchain-transport-api` ou `ksp-wallet-api` n'est prévu actuellement.
- Aucun `ksp-data-api`, `ksp-pipeline-lib` monolithique, `ksp-scenario-api`, `ksp-onchain-transport-api`, `ksp-offchain-transport-api` ou `ksp-wallet-api` n'est prévu actuellement.
- Quatre pipelines spécialisés sont désormais retenus pour les frontières durables : raw ingestion, Core processing, generic materialization et domain projection.
- Les scenarios restent des crates spécialisées régies d'abord par une norme souple.
## Prévision souple des prereleases restantes
@@ -101,15 +102,22 @@ Livré :
### `pre.007` — Acquisition, workers de processing et jobs
- détailler `ksp-worker-raw-retriever` ;
- détailler `ksp-worker-core-processor` ;
- détailler `ksp-worker-generic-materializer` ;
- détailler `ksp-worker-domain-projector` et réévaluer son nom ;
- détailler `ksp-job-backfill` ;
- définir les jobs de replay D1 -> D2, D2 -> D3, D3 -> D4 ;
- définir backlog/checkpoints/cursors ;
- traiter batching, concurrence, reprise et hot reconfiguration ;
- choisir le mécanisme de notification de référence sans en faire la source de vérité.
Livré :
- quatre pipelines spécialisés réutilisant chaque frontière durable entre worker live et job ;
- `ksp-worker-api` maintenu comme lifecycle API continue ;
- `ksp-job-api` maintenu comme lifecycle API terminable séparée ;
- `ksp-worker-raw-retriever` avec hot reconfiguration desired/effective ;
- `ksp-worker-core-processor`, `ksp-worker-generic-materializer`, `ksp-worker-domain-projector` ;
- `ksp-job-backfill` strictement D1 ;
- `ksp-job-replay-core`, `ksp-job-replay-generic-materialization`, `ksp-job-replay-domain-projection` ;
- backlog par input + processor/version/capability ;
- processing outcomes explicites même sans output ;
- claim/lease et reprise après crash ;
- at-least-once + idempotence ;
- replay normal vs force replay ;
- PostgreSQL LISTEN/NOTIFY comme wake-up initial de référence + periodic polling ;
- batching/concurrence bornés et principe de backpressure observable mais non automatique.
### `pre.008` — Applications, managers, scenarios et orchestration
@@ -118,13 +126,15 @@ Livré :
- définir la norme des crates scenario et leurs apps demo ;
- traiter les processus/IPC/managers ;
- cadrer l'orchestrateur futur ;
- inventorier les pipelines spécialisés réellement nécessaires.
- déterminer comment apps/managers pilotent workers et jobs sans fusionner leurs lifecycle APIs ;
- inventorier les autres pipelines spécialisés seulement si un besoin concret apparaît.
### `pre.009` — Plan des premières releases fonctionnelles
- transformer les séries `0.1.x+` en premières releases concrètes ;
- dimensionner chaque release concrète ;
- choisir la première release `0.1.N` ;
- vérifier l'ordre réel core/logging/config/interface/program/store/transport/workers sans introduire de dépendances circulaires ;
- transformer le brouillon de prompt en prompt quasi-final de cette release concrète.
### `pre.010` — Clôture fondatrice