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

Delta 0.0.3-pre.009

Base requise

v0.0.3-pre.008.

Objectif

Transformer le roadmap fonctionnel en une première séquence de releases concrètes, sélectionner 0.1.1 et produire son prompt quasi-final sans sur-numéroter prématurément les séries futures.

Version Cargo

workspace.package.version passe de :

0.0.3-pre.8

à :

0.0.3-pre.9

Le header de Cargo.toml passe de version 14 à 15.

Fichiers ajoutés

• docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
• prompts/001-V0_1_1_START_PROMPT.md
• deltas/0.0.3/pre.009.md

Fichiers modifiés

• Cargo.toml
• ROADMAP.md
• docs/architecture/004-COMPONENT_INVENTORY.md
• docs/plans/001-V0_0_3_PLAN.md
• docs/rules/RULES_KSP.md
• docs/IDEAS.md

Fichiers supprimés

• prompts/001-V0_1_X_START_PROMPT.md

La suppression est explicite dans ce delta : le nouveau prompt V0_1_1 remplace le brouillon générique.

Décisions principales

Première release

La première release fonctionnelle est fixée :

0.1.1 — ksp-core-lib

Mission : stabiliser le contrat Core N1 sans ouvrir les couches supérieures.

0.1.x

Séquence par défaut :

0.1.1  Core
0.1.2  Logging
0.1.3  Config
0.1.4  Config desktop

0.1.1 et 0.1.2 sont fixées.

Si 0.1.3-pre.001 démontre que Config doit être scindé, une release est insérée et l'app Config est décalée.

0.1.1

Périmètre candidat :

• ksp_core_lib::Error ;
• Result<T> ou équivalent ;
• Program IDs fondamentaux ;
• primitives N1 réellement nécessaires ;
• API/reexports/tests/docs.

ksp-core-lib ne dépend pas de Logging/Config ni des couches Solana supérieures.

0.1.2

ksp-logging-lib dépend de Core et possède directement :

• tracing ;
• tracing-appender ;
• tracing-subscriber.

Il expose sa façade/settings sans dépendre de Config.

0.1.3 / 0.1.4

Config puis son app desktop spécialisée constituent la séquence par défaut.

L'app sert de validation réelle de Config et de la frontière Tauri.

Séries futures

0.2.x+ reste ordonné fonctionnellement mais n'est pas numéroté finement.

Cette politique évite de figer des numéros qui seront probablement modifiés par les dépendances réelles découvertes pendant les premières releases.

Git

À partir de 0.1.x, chaque delta est commité.

Une étape erronée reste dans l'historique et est corrigée par un delta suivant.

Seul le commit stable reçoit le tag vX.Y.Z.

Lifecycle

Le premier pre.001 d'une release fonctionnelle est une phase de brainstorming/audit/plan détaillé/dimensionnement.

La dernière prerelease réalise validations finales, documentation, nettoyage/archivage, changelog et prompt de la release suivante.

Prompt

Le brouillon :

prompts/001-V0_1_X_START_PROMPT.md

est remplacé par :

prompts/001-V0_1_1_START_PROMPT.md

Le nouveau prompt est quasi-final et sera seulement confirmé/corrigé en clôture pre.010.

Plan restant

pre.010

• audit global final ;
• cohérence docs/règles/architecture/roadmap/plans ;
• validations workspace applicables ;
• nettoyage/archivage ;
• changelog si disponible dans la base ;
• finalisation du prompt 0.1.1 ;
• préparation de la release stable 0.0.3.

pre.010 ne doit pas rouvrir une tranche de brainstorming architectural sauf incohérence critique.

Validations

• headers file: / version: vérifiés ;
• Cargo.toml parsé et version 0.0.3-pre.9 vérifiée ;
• ROADMAP.md contient les releases concrètes 0.1.1–0.1.4 par défaut ;
• docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md ajouté ;
• prompt V0_1_1 ajouté et ancien prompt V0_1_X déclaré supprimé ;
• première release 0.1.1 cohérente avec la dépendance ksp-logging-lib -> ksp-core-lib ;
• numérotation fine 0.2.x+ laissée volontairement ouverte ;
• plan pre.010 limité à la clôture ;
• aucune commande Cargo build/test exécutée : ce delta reste documentaire.