# 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---desk-demo ``` et réutilisent `ksp-scenario--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.