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

v0.2.0-rel.001

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-17 16:21:04 +02:00
parent e721464a7c
commit 24cf2c5a11
10 changed files with 190 additions and 41 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
docs/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/000-README.md -->
<!-- version: 19 -->
<!-- version: 20 -->
# Documentation KSP
@@ -60,7 +60,7 @@ D'autres sous-répertoires seront ajoutés uniquement lorsque leur rôle aura é
## Documents de planification
Le plan historique de la phase fondatrice clôturée est conservé dans [`plans/001-V0_0_3_PLAN.md`](plans/001-V0_0_3_PLAN.md). La séquence active des premières releases fonctionnelles est définie dans [`plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md`](plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md). Le plan détaillé de la release stable `0.1.1` est conservé comme historique clôturé dans [`plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md`](plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.2` est conservé comme historique clôturé dans [`plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md`](plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.3 — Configuration foundation` est conservé comme historique clôturé dans [`plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`](plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.4 — ksp-app-config-desk` est conservé comme historique clôturé dans [`plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md`](plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md), avec sa matrice finale [`validation/001-V0_1_4_CONFIG_DESKTOP.md`](validation/001-V0_1_4_CONFIG_DESKTOP.md). Son prompt d'ouverture historique reste [`../prompts/004-V0_1_4_START_PROMPT.md`](../prompts/004-V0_1_4_START_PROMPT.md). La session active est `0.2.0`, ouverte par [`../prompts/005-V0_2_0_START_PROMPT.md`](../prompts/005-V0_2_0_START_PROMPT.md). Son plan directeur d'audit et de découpage de série est [`plans/007-V0_2_0_SERIES_PLANNING.md`](plans/007-V0_2_0_SERIES_PLANNING.md), créé par `0.2.0-pre.001`, restructuré par `0.2.0-pre.002` puis audité/finalisé par `0.2.0-pre.003` autour de la séquence Transport HTTP -> Wallet -> transports live -> off-chain -> Interface/Program et de l'architecture RAW -> CORE -> DECODE -> SPECIALIZED. Sa matrice de clôture est [`validation/002-V0_2_0_SERIES_PLANNING.md`](validation/002-V0_2_0_SERIES_PLANNING.md). Le prompt préparatoire de la première release fonctionnelle est [`../prompts/006-V0_2_1_START_PROMPT.md`](../prompts/006-V0_2_1_START_PROMPT.md).
Le plan historique de la phase fondatrice clôturée est conservé dans [`plans/001-V0_0_3_PLAN.md`](plans/001-V0_0_3_PLAN.md). La séquence active des premières releases fonctionnelles est définie dans [`plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md`](plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md). Le plan détaillé de la release stable `0.1.1` est conservé comme historique clôturé dans [`plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md`](plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.2` est conservé comme historique clôturé dans [`plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md`](plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.3 — Configuration foundation` est conservé comme historique clôturé dans [`plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`](plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.4 — ksp-app-config-desk` est conservé comme historique clôturé dans [`plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md`](plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md), avec sa matrice finale [`validation/001-V0_1_4_CONFIG_DESKTOP.md`](validation/001-V0_1_4_CONFIG_DESKTOP.md). Son prompt d'ouverture historique reste [`../prompts/004-V0_1_4_START_PROMPT.md`](../prompts/004-V0_1_4_START_PROMPT.md). La release stable `0.2.0` clôt l'audit de bot3 et le découpage de la série. Son plan directeur est conservé comme historique clôturé dans [`plans/007-V0_2_0_SERIES_PLANNING.md`](plans/007-V0_2_0_SERIES_PLANNING.md), avec sa matrice finale [`validation/002-V0_2_0_SERIES_PLANNING.md`](validation/002-V0_2_0_SERIES_PLANNING.md). La prochaine release fonctionnelle est `0.2.1 — ksp-onchain-transport-lib / HTTP Solana foundation`, à ouvrir avec [`../prompts/006-V0_2_1_START_PROMPT.md`](../prompts/006-V0_2_1_START_PROMPT.md).
`IDEAS.md` conserve les pistes et questions qui ne sont pas encore des engagements du roadmap ni des décisions architecturales.

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

@@ -1,5 +1,5 @@
<!-- file: docs/plans/000-README.md -->
<!-- version: 27 -->
<!-- version: 28 -->
# Plans KSP
@@ -15,7 +15,7 @@ Un plan décrit le périmètre, les décisions déjà acquises, les questions ou
- [`004-V0_1_2_LOGGING_FOUNDATION_PLAN.md`](004-V0_1_2_LOGGING_FOUNDATION_PLAN.md) — plan historique clôturé de la release stable `0.1.2`, établi par `0.1.2-pre.001` puis consolidé jusqu'à `0.1.2-rel.001`.
- [`005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`](005-V0_1_3_CONFIG_FOUNDATION_PLAN.md) — plan historique clôturé de la release stable `0.1.3 — Configuration foundation`, établi par `0.1.3-pre.001`, exécuté jusqu'à `pre.015` puis publié par `0.1.3-rel.001`.
- [`006-V0_1_4_CONFIG_DESKTOP_PLAN.md`](006-V0_1_4_CONFIG_DESKTOP_PLAN.md) — plan historique clôturé de la release stable `0.1.4 — ksp-app-config-desk`, établi par `0.1.4-pre.001` puis consolidé jusqu'à `0.1.4-rel.001`.
- [`007-V0_2_0_SERIES_PLANNING.md`](007-V0_2_0_SERIES_PLANNING.md) — plan actif de `0.2.0`, ouvert par `pre.001`, consolidé par `pre.002` puis finalisé/audité par `pre.003` avec l'ordre `0.2.1+`, la stratégie RAW/CORE/DECODE/SPECIALIZED, les vertical slices Program, les fiches de release et le prompt finalisé `0.2.1`.
- [`007-V0_2_0_SERIES_PLANNING.md`](007-V0_2_0_SERIES_PLANNING.md) — plan historique clôturé de la release stable `0.2.0`, ouvert par `pre.001`, consolidé par `pre.002`, audité par `pre.003` puis publié par `rel.001`; il fixe l'ordre `0.2.1+`, la stratégie RAW/CORE/DECODE/SPECIALIZED, les vertical slices Program et le prompt `0.2.1`.
Le `pre.001` de chaque release fonctionnelle peut introduire son propre plan détaillé lorsque la release s'ouvre.

8
docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md -->
<!-- version: 28 -->
<!-- version: 29 -->
# Séquence des releases fonctionnelles KSP
@@ -351,7 +351,7 @@ Par défaut :
# Série `0.2.x` — accès Solana, Wallet et contrats initiaux
`0.2.0` reste la release de cadrage. `0.2.0-pre.002` a fixé le début de la séquence fonctionnelle suivante et `0.2.0-pre.003` en réalise l'audit final de cohérence avant publication stable :
`0.2.0` est publiée stable par `0.2.0-rel.001`. `pre.002` a fixé le début de la séquence fonctionnelle suivante et `pre.003` en a réalisé l'audit final de cohérence :
```text
0.2.1 on-chain transport HTTP foundation
@@ -538,7 +538,7 @@ Chaque release concrète doit pouvoir être ouverte et clôturée dans une seule
Les releases `0.1.1` à `0.1.4` sont stables et leurs plans/prompts restent historiques.
# Ouverture de `0.2.0`
# Clôture stable de `0.2.0` et ouverture de `0.2.1`
`0.2.0` a été ouverte par :
@@ -552,4 +552,4 @@ prompts/005-V0_2_0_START_PROMPT.md
prompts/006-V0_2_1_START_PROMPT.md
```
Le prompt `0.2.1` est finalisé côté contenu par `0.2.0-pre.003`; il ne devient applicable qu'après publication stable de `v0.2.0`.
`0.2.0-rel.001` publie ce cadrage sous la version stable `0.2.0`. Après validation du commit de release et création du tag `v0.2.0`, le prompt `0.2.1` devient le point d'entrée actif de la série.

20
docs/plans/007-V0_2_0_SERIES_PLANNING.md
View File

@@ -1,8 +1,10 @@
<!-- file: docs/plans/007-V0_2_0_SERIES_PLANNING.md -->
<!-- version: 4 -->
<!-- version: 5 -->
# Plan `0.2.0` — audit bot3 et planification de la série `0.2.x`
> **Statut : plan historique clôturé par `0.2.0-rel.001`.** La première release fonctionnelle suivante est `0.2.1 — ksp-onchain-transport-lib / HTTP Solana foundation`, ouverte avec `prompts/006-V0_2_1_START_PROMPT.md`.
## 1. Statut et objectif
`0.2.0` est une release intermédiaire de transition, d'audit et de planification. Elle ne livre pas directement une nouvelle capacité Solana complète ; elle transforme l'expérience de `khadhroony-bot3` en une trajectoire KSP cohérente, bornée et compatible avec les règles stabilisées en `0.1.x`.
@@ -698,15 +700,15 @@ Il est volontairement prématuré de figer maintenant chaque numéro jusqu'aux D
Aucune `pre.004` n'est prévue. Elle ne serait créée que si la validation de `pre.003` révélait un nouveau défaut ou une omission substantielle qui ne peut pas être honnêtement corrigée dans `rel.001`.
Après validation de `pre.003`, `0.2.0-rel.001` doit rester une publication de cadrage :
`0.2.0-rel.001` publie le cadrage sans nouvelle décision architecturale :
- passer `workspace.package.version` à `0.2.0` ;
- marquer `0.2.0` stable dans ROADMAP/indices/plans ;
- ajouter l'entrée stable `0.2.0` au `CHANGELOG.md` ;
- créer `deltas/0.2.0/rel.001.md` ;
- exécuter les validations globales de clôture disponibles ;
- commit `v0.2.0-rel.001`, puis tag stable Git `v0.2.0` ;
- ne modifier le prompt `0.2.1` que si une validation de clôture révèle un écart réel.
- `workspace.package.version = 0.2.0` ;
- `0.2.0` est marqué stable dans ROADMAP/indices/plans ;
- `CHANGELOG.md` reçoit l'entrée stable `0.2.0` ;
- `deltas/0.2.0/rel.001.md` enregistre la publication ;
- les validations finales de `pre.003` communiquées par le user sont reportées dans la matrice de clôture ;
- le commit attendu est `v0.2.0-rel.001`, puis le tag stable Git `v0.2.0` ;
- le prompt `0.2.1` reste inchangé et devient le prochain point d'entrée après le tag stable.
La matrice de clôture durable est `docs/validation/002-V0_2_0_SERIES_PLANNING.md`.

4
docs/validation/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/validation/000-README.md -->
<!-- version: 2 -->
<!-- version: 3 -->
# Validations KSP
@@ -10,4 +10,4 @@ Les deltas restent l’historique autoritatif des livraisons ; une matrice de va
Documents :
- [`001-V0_1_4_CONFIG_DESKTOP.md`](001-V0_1_4_CONFIG_DESKTOP.md) — matrice finale de `0.1.4 — ksp-app-config-desk`.
- [`002-V0_2_0_SERIES_PLANNING.md`](002-V0_2_0_SERIES_PLANNING.md) — audit final de cohérence et matrice de clôture documentaire de `0.2.0`.
- [`002-V0_2_0_SERIES_PLANNING.md`](002-V0_2_0_SERIES_PLANNING.md) — matrice finale de la release stable `0.2.0`, avec audit de cohérence et preuves opérateur de `pre.003`.

56
docs/validation/002-V0_2_0_SERIES_PLANNING.md
View File

@@ -1,11 +1,11 @@
<!-- file: docs/validation/002-V0_2_0_SERIES_PLANNING.md -->
<!-- version: 2 -->
<!-- version: 3 -->
# Validation `0.2.0` — audit bot3 et planification de la série `0.2.x`
## Objet
Cette matrice synthétise l'audit final de `0.2.0` et vérifie que le cadrage demandé par `prompts/005-V0_2_0_START_PROMPT.md` est suffisamment complet avant publication stable.
Cette matrice synthétise l'audit final de `0.2.0`, les preuves opérateur de `pre.003` et la clôture publiée par `0.2.0-rel.001` conformément au cadrage demandé par `prompts/005-V0_2_0_START_PROMPT.md`.
Elle ne remplace ni `docs/plans/007-V0_2_0_SERIES_PLANNING.md` ni les deltas `0.2.0`.
@@ -148,25 +148,49 @@ deltas/0.1.4/pre.016-fix.002.md
qui ne possède pas les deux commentaires d'en-tête `file/version` utilisés par la convention actuelle. Ce fichier appartient à l'historique publié `0.1.4` et n'est **pas réécrit silencieusement** dans `0.2.0-pre.003`, conformément à la règle d'immutabilité pratique des deltas livrés. Cette anomalie ne modifie aucune règle/architecture active et ne bloque pas `0.2.0`.
## Statut de clôture
## Preuves opérateur finales de `pre.003`
Après application et validation de `0.2.0-pre.003`, aucun développement N2 n'est attendu dans `0.2.0`.
La publication `0.2.0-rel.001` peut être préparée si les validations locales ne révèlent pas d'écart supplémentaire.
Le `rel.001` doit essentiellement :
Le user a communiqué le 2026-08-17, sur le commit :
```text
workspace.package.version -> 0.2.0
ROADMAP / plans / indices -> 0.2.0 stable
CHANGELOG.md -> entrée stable 0.2.0
deltas/0.2.0/rel.001.md
validations globales finales
commit v0.2.0-rel.001
tag Git v0.2.0
e721464a7c2cbf4c564757061a2a44dd7913facb
v0.2.0-pre.003
```
Le prompt à utiliser ensuite est :
les validations suivantes avec succès :
```bash
cargo fmt --all
cargo check --workspace
cargo clippy --workspace --all-targets
cargo test --workspace
git diff --check
git status --short
```
Résultats synthétiques :
- `cargo check --workspace` : succès ;
- `cargo clippy --workspace --all-targets` : succès sans warning communiqué ;
- `cargo test --workspace` : **241 tests réussis**, aucun échec ; le probe diagnostic d'overhead de `ksp-logging-lib` reste volontairement `ignored` ;
- `git diff --check` : aucune sortie ;
- `git status --short` : aucune sortie, working tree propre ;
- `git log -1 --oneline --decorate` confirme `e721464 (HEAD -> master, origin/master) v0.2.0-pre.003`.
Aucun écart supplémentaire n'a été révélé par cette validation. Aucune `pre.004` n'est donc requise.
## Statut de clôture
`0.2.0-rel.001` publie le cadrage sous `workspace.package.version = "0.2.0"` sans développement N2 ni nouvelle décision architecturale.
Après validation du delta stable, les identifiants Git attendus sont :
```text
commit : v0.2.0-rel.001
tag : v0.2.0
```
La release suivante s'ouvre avec :
```text
prompts/006-V0_2_1_START_PROMPT.md