88 lines
4.5 KiB
Markdown
88 lines
4.5 KiB
Markdown
<!-- file: docs/plans/001-V0_0_3_PLAN.md -->
|
|
<!-- version: 6 -->
|
|
|
|
# Plan KSP 0.0.3
|
|
|
|
## Mission
|
|
|
|
Transformer le brainstorming KSP en architecture, règles, inventaire et plan suffisamment précis pour ouvrir la première série fonctionnelle `0.1.x` sans développement fonctionnel prématuré.
|
|
|
|
## État courant
|
|
|
|
`pre.001` est considérée stabilisée et commitée comme `v0.0.3-pre.001`.
|
|
|
|
`pre.002` produit le premier inventaire des composants et responsabilités. Cet inventaire est volontairement révisable dans `pre.003` lorsque le graphe de dépendances sera étudié.
|
|
|
|
## Décisions structurantes actuelles
|
|
|
|
- `0.1.x`, `0.2.x`, etc. sont des **séries fonctionnelles**, pas des unités de session.
|
|
- Chaque release concrète d'une série doit être dimensionnée séparément pour une session raisonnable.
|
|
- Les bibliothèques d'implémentation utilisent `ksp-<role>-lib` ; les contrats publics extensibles utilisent `ksp-<domain>-api`.
|
|
- Program, materializer et store ont un couple API/implémentation séparé.
|
|
- Workers et jobs ont des lifecycle APIs distinctes.
|
|
- `ksp-worker-raw-retriever` réalise uniquement l'acquisition live/quasi-live raw.
|
|
- Le processing futur est séparé en `ksp-worker-core-processor`, `ksp-worker-generic-materializer` et `ksp-worker-domain-projector` (nom du dernier provisoire).
|
|
- `ksp-job-backfill` réalise l'acquisition historique à la demande.
|
|
- `ksp-worker-control-lib` est destiné à être réutilisé par managers/apps/orchestrateur ; aucune `ksp-job-control-lib` n'est prévue sans besoin concret.
|
|
- `ksp-execution-policy-api` et `ksp-execution-lib` sont des candidats forts pour séparer policy et orchestration d'exécution de `ksp-program-lib`.
|
|
- Pas de `ksp-onchain-transport-api`, `ksp-offchain-transport-api` ou `ksp-wallet-api` dans l'architecture actuelle.
|
|
- `ksp-onchain-transport-lib` expose des modèles de transport homogènes mais indépendants du store.
|
|
- Pas de `ksp-scenario-api` pour l'instant : privilégier une norme souple de scénarios spécialisés.
|
|
- Pas de `ksp-pipeline-lib` monolithique ; pipelines spécialisés uniquement à la demande.
|
|
|
|
## Prévision souple des prereleases restantes
|
|
|
|
### `pre.002` — Inventaire initial des composants
|
|
|
|
- créer `docs/architecture/004-COMPONENT_INVENTORY.md` ;
|
|
- fixer les responsabilités et statuts initiaux des composants ;
|
|
- enregistrer les workers/jobs/scénarios/apps actuellement prévus ;
|
|
- documenter les candidats `ksp-execution-policy-api` et `ksp-execution-lib` ;
|
|
- corriger la règle de charge série/release/session ;
|
|
- préparer explicitement les questions à résoudre dans `pre.003`.
|
|
|
|
### `pre.003` — Graphe de dépendances et correction de l'inventaire
|
|
|
|
- construire le graphe autorisé/interdit ;
|
|
- décider si `ksp-execution-lib` dépend de `ksp-program-api`, `ksp-program-lib` ou reçoit des implémentations injectées ;
|
|
- définir la frontière program -> execution plan -> policy -> wallet/transport ;
|
|
- vérifier que transport ne dépend pas du store tout en gardant une conversion simple des modèles ;
|
|
- positionner materializer/store/notifications ;
|
|
- rechercher et supprimer les cycles ;
|
|
- corriger `004-COMPONENT_INVENTORY.md` si nécessaire.
|
|
|
|
### `pre.004` — Programmes, wire et exécution
|
|
|
|
- détailler `ksp-interface-lib`, `ksp-program-api`, `ksp-program-lib` ;
|
|
- détailler l'execution policy/orchestration si validées ;
|
|
- cadrer conformité wire, historique/deprecated et sécurité supérieure.
|
|
|
|
### `pre.005` — Données, store et acquisitions
|
|
|
|
- détailler materializer/store ;
|
|
- finaliser les modèles raw et notifications ;
|
|
- détailler W1 et backfill ;
|
|
- cadrer les trois workers de processing futurs ;
|
|
- revisiter les niveaux durables/replay.
|
|
|
|
### `pre.006` — Applications, workers, jobs, scenarios et pipelines spécialisés
|
|
|
|
- formaliser les apps spécialisées ;
|
|
- détailler `ksp-worker-control-lib` ;
|
|
- définir la norme des crates scénario et leurs apps demo ;
|
|
- inventorier les pipelines spécialisés réellement nécessaires.
|
|
|
|
### `pre.007` — Plan des premières releases fonctionnelles
|
|
|
|
- transformer les séries `0.1.x+` en premières releases concrètes ;
|
|
- dimensionner chaque release concrète plutôt que toute la série ;
|
|
- préparer le prompt de la première release `0.1.x` réellement choisie.
|
|
|
|
### `pre.008` — Clôture fondatrice
|
|
|
|
- validations finales de cohérence ;
|
|
- documentation/nettoyage/archivage ;
|
|
- finalisation du prompt de la première release fonctionnelle.
|
|
|
|
Le nombre de prereleases reste révisable si une tranche dépasse le budget de planification ou si une nouvelle frontière apparaît.
|