Files
khadhroony-solana-project/deltas/0.0.3/pre.002.md
2026-08-14 07:23:56 +02:00

140 lines
3.8 KiB
Markdown

<!-- file: deltas/0.0.3/pre.002.md -->
<!-- version: 1 -->
# Delta 0.0.3-pre.002
## Base requise
`v0.0.3-pre.001` incluant les corrections `pre.001-fix.001` à `pre.001-fix.004`.
## Objectif
Produire le premier inventaire formel des composants KSP et enregistrer les dernières frontières décidées avant l'étude du graphe de dépendances.
## Version Cargo
`workspace.package.version` passe de :
```text
0.0.3-pre.1
```
à :
```text
0.0.3-pre.2
```
Le header de `Cargo.toml` passe de version 7 à 8.
## Fichiers ajoutés
- `docs/architecture/004-COMPONENT_INVENTORY.md`
- `deltas/0.0.3/pre.002.md`
## Fichiers modifiés
- `Cargo.toml`
- `ROADMAP.md`
- `docs/architecture/000-README.md`
- `docs/architecture/003-COMPONENT_CONTRACTS.md`
- `docs/rules/RULES_KSP.md`
- `docs/rules/PROMPT_STRUCTURE.md`
- `docs/IDEAS.md`
- `docs/plans/001-V0_0_3_PLAN.md`
- `prompts/001-V0_1_X_START_PROMPT.md`
## Fichiers supprimés
Aucun.
## Décisions principales
### Séries et releases
`0.1.x`, `0.2.x`, etc. sont des séries fonctionnelles et peuvent couvrir plusieurs releases/sessions.
Le contrôle de charge porte sur chaque release concrète (`0.1.1`, `0.1.2`, etc.) et ses prereleases, pas sur toute la série.
### Workers
Noms retenus :
```text
ksp-worker-raw-retriever
ksp-worker-core-processor
ksp-worker-generic-materializer
ksp-worker-domain-projector
```
Le nom du dernier reste révisable.
Le processing futur n'est donc plus modélisé comme un unique W2 monolithique.
### Execution policy / orchestration
`ksp-execution-policy-api` devient un candidat fort pour permettre des policies différentes selon le contexte.
`ksp-execution-lib` devient un candidat fort d'orchestration spécialisée entre programme, policy, wallet et transport.
Le graphe exact est explicitement reporté à `pre.003`.
### Transport
Aucune `ksp-onchain-transport-api` ni `ksp-offchain-transport-api`.
`ksp-onchain-transport-lib` ne dépend pas du store mais doit exposer des modèles homogènes facilement convertibles vers les modèles raw de `ksp-store-api`.
`ksp-offchain-transport-lib` reste volontairement hétérogène.
### Wallet
Aucune `ksp-wallet-api`.
Des applications wallet futures sont ajoutées aux idées : Android, extensions Firefox/Chrome et wallet web.
### Worker/job lifecycle
`ksp-worker-api` et `ksp-job-api` sont confirmées comme lifecycle APIs séparées.
`ksp-worker-control-lib` est destiné à être réutilisé par les managers/apps/orchestrateur.
Aucune `ksp-job-control-lib` n'est prévue actuellement.
### Notifications de données
Les notifications restent normalisées selon la donnée persistée et non selon le producteur. `ksp-store-api` reste leur propriétaire candidat.
### Scénarios
`ksp-scenario-api` n'est pas retenu actuellement. Une norme souple de scénarios spécialisés est préférée.
Les apps desktop de démonstration utilisent la forme :
```text
ksp-app-scenario-<domain>-<environment>-desk-demo
```
et réutilisent `ksp-scenario-<domain>-lib`.
### Pipelines
Toujours aucun `ksp-pipeline-lib` monolithique. Des pipelines spécialisés sont créés uniquement à la demande.
## Questions reportées à pre.003
- graphe exact program/execution/policy/wallet/transport ;
- choix `ksp-program-api` vs `ksp-program-lib` comme dépendance de l'orchestration ;
- frontières des modèles d'exécution préparée ;
- modèles de transport homogènes et conversion vers store raw ;
- dépendances materializer/store/notifications ;
- prévention des cycles ;
- corrections éventuelles de l'inventaire `pre.002`.
## Validations
- en-têtes `file:` / `version:` vérifiés sur les fichiers Markdown livrés ;
- `Cargo.toml` vérifié syntaxiquement et versionné `0.0.3-pre.2` ;
- cohérence des références vers `004-COMPONENT_INVENTORY.md` vérifiée ;
- aucune commande Cargo exécutée sur l'archive delta seule, qui ne contient pas le workspace complet.