khadhroony-solana-project/deltas/0.0.3/pre.002.md

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 :

0.0.3-pre.1

à :

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 :

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 :

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.