Sasedev/khadhroony-solana-project
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v0.0.3-pre.010

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-14 13:05:50 +02:00
parent 2dada316c1
commit 5e169af906
16 changed files with 283 additions and 105 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
docs/plans/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/000-README.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Plans KSP
@@ -7,8 +7,11 @@ Ce répertoire contient les plans actifs ou historiques des versions et phases d
Un plan décrit le périmètre, les décisions déjà acquises, les questions ouvertes, les validations attendues et la prévision souple des prereleases. Il ne remplace pas le `ROADMAP.md`, qui reste global, ni les deltas qui enregistrent le travail réellement livré.
## Plan actif
## Plans de référence
- [`001-V0_0_3_PLAN.md`](001-V0_0_3_PLAN.md) — plan de la phase de brainstorming et planification `0.0.3`.
- [`001-V0_0_3_PLAN.md`](001-V0_0_3_PLAN.md) — plan de la phase fondatrice `0.0.3`, en clôture ;
- [`002-FUNCTIONAL_RELEASE_SEQUENCE.md`](002-FUNCTIONAL_RELEASE_SEQUENCE.md) — séquence de référence des premières releases fonctionnelles, dont `0.1.1`.
Le préfixe numérique sert ici à maintenir le plan actif prioritaire après `000-README.md`. Lorsqu'un autre ordre devient préférable, la convention documentaire permet de le réorganiser explicitement.
Le `pre.001` de chaque release fonctionnelle peut introduire son propre plan détaillé lorsque la release s'ouvre.
Le préfixe numérique maintient un ordre documentaire explicite après `000-README.md`.

35
docs/plans/001-V0_0_3_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/001-V0_0_3_PLAN.md -->
<!-- version: 13 -->
<!-- version: 14 -->
# Plan KSP 0.0.3
@@ -157,13 +157,28 @@ Livré :
### `pre.010` — Clôture fondatrice
- relire les règles, architecture, roadmap, plans et IDEAS pour détecter les contradictions restantes ;
- vérifier que la documentation racine/indexée disponible est cohérente ;
- vérifier les versions de fichiers et le versionnement Cargo ;
- effectuer les validations workspace applicables à la fondation ;
- mettre à jour/nettoyer/archiver ce qui doit l'être ;
- synchroniser le changelog si le fichier existe dans la base de travail ;
- finaliser `prompts/001-V0_1_1_START_PROMPT.md` ;
- produire le delta/release stable `0.0.3` et préparer le démarrage de `0.1.1`.
Livré :
`pre.010` n'est pas une nouvelle tranche de brainstorming architectural. Une évolution de fond n'y est ouverte qu'en cas d'incohérence critique détectée pendant l'audit final.
- reconstruction/audit de la fondation complète `0.0.2` + deltas `0.0.3` disponibles ;
- correction des références documentaires obsolètes ;
- correction des doublons normatifs `KSP-MAT-001/002` ;
- remplacement des derniers termes `executor` devenus ambigus par `ProgramExecutionPreparer`/execution preparation ;
- mise à jour des index docs/plans/prompts ;
- finalisation de `prompts/001-V0_1_1_START_PROMPT.md` ;
- audit automatique des headers, liens locaux et IDs de règles ;
- passage Cargo à `0.0.3-pre.10`.
Les validations Cargo ont été tentées dans l'environnement de génération mais ne sont pas exécutables car la commande `cargo` n'y est pas installée.
Avant `0.0.3-rel.001`, exécuter sur le dépôt réel :
```bash
cargo fmt --all -- --check
cargo check --workspace
cargo test --workspace
cargo clippy --workspace --all-targets
```
La publication stable `0.0.3-rel.001` passe ensuite `workspace.package.version` à `0.0.3`, marque la fondation terminée dans le roadmap et prépare le commit/tag stable `v0.0.3`.
`pre.010` clôt le brainstorming architectural. `rel.001` ne doit contenir aucune nouvelle architecture sauf correction bloquante issue des validations.