khadhroony-solana-project/deltas/0.0.2/pre.001-fix.004.md

Delta 0.0.2-pre.001-fix.004

Base requise

• dépôt KSP initialisé et 0.0.1 commitée ;
• 0.0.2-pre.001 appliquée ;
• correctifs pre.001-fix.001 à pre.001-fix.003 appliqués.

Type de livraison

ksp-general-0.0.2-pre.001-fix.004.zip

Objectifs

• introduire le ROADMAP.md général avec sa structure et ses statuts ;
• introduire docs/IDEAS.md pour conserver les pistes à explorer sans les transformer en engagements ;
• préciser la différence entre roadmap global et plan détaillé d'une version ;
• imposer qu'un plan établi en pre.001 fournisse une prévision souple du découpage des prereleases de la version ;
• enregistrer la convention Git des commits versionnés et du tag stable vX.Y.Z ;
• préciser le traitement possible des correctifs d'une livraison rel.NNN avant publication stable.

Version Cargo

Cette livraison ne modifie que des fichiers Markdown de documentation, de règles et de planification. Conformément à VER-ID-008, workspace.package.version n'est pas modifiée et reste celle du dernier correctif technique :

0.0.2-pre.1.fix.3

Fichiers ajoutés

ROADMAP.md
docs/IDEAS.md
deltas/0.0.2/pre.001-fix.004.md

Fichiers modifiés

docs/000-README.md
docs/rules/FILE_CONTRACTS.md
docs/rules/RULES_DOCUMENTATION.md
docs/rules/VERSION_WORKFLOW.md

Fichiers supprimés

Aucun.

Décisions validées

Roadmap

Chaque phase/version du roadmap peut contenir :

1. Objectifs : un ou plusieurs paragraphes décrivant l'état à atteindre ;
2. Étapes : grandes étapes avec cases [ ], [/], [X], [C], [R] ;
3. Status : bloc optionnel indiquant l'état global.

Légende canonique :

[ ] prévu / non commencé
[/] en cours
[X] réalisé et validé
[C] annulé
[R] reporté

Le roadmap n'est pas obligé d'être organisé une ligne par prerelease.

Planification de pre.001

La première prerelease d'une version produit ou révise un document de planification détaillant une prévision souple des prereleases de cette version. Le plan porte le découpage opérationnel plus fin que le roadmap et peut être réorganisé lorsque la réflexion ou le développement le justifie.

Le chemin et le nom canonique des futurs fichiers de planification pourront être fixés pendant la planification architecturale ; l'exigence de contenu est déjà normative.

Idées

docs/IDEAS.md devient le registre des idées, pistes, alternatives et questions à conserver sans les considérer comme planifiées. Une idée retenue est transférée vers le roadmap, un plan, une règle ou une décision selon sa nature.

Git et releases

• les commits de livraison utilisent le préfixe v suivi de l'identifiant de livraison ;
• les pre, fix et rel n'exigent pas de tag Git intermédiaire ;
• seul le commit considéré comme release stable reçoit le tag vX.Y.Z ;
• une livraison rel.NNN peut être corrigée avant le tag stable ; une release déjà publiée comme stable n'est normalement pas réécrite.

Validations exécutées

Aucune commande Cargo n'est requise par ce correctif purement documentaire.

Contrôles de livraison à effectuer :

• vérifier l'emplacement et les en-têtes file: / version: ;
• vérifier l'absence de modification de Cargo.toml ;
• vérifier que le contenu du roadmap ne duplique pas les futurs plans détaillés de version.

Questions restant ouvertes

• nom et emplacement canonique du document de planification créé/révisé en pre.001 ;
• détails du plan global des crates, apps, workers et dépendances ;
• nomenclature définitive des interfaces et environnements d'applications/demos ;
• structure détaillée des premières phases 0.1.x, 0.2.x, etc.