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

v0.1.4-pre.019-fix.001

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-17 09:04:34 +02:00
parent 8099b6cb39
commit 9aa5f171f7
7 changed files with 289 additions and 78 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -1,5 +1,5 @@
<!-- file: docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md -->
<!-- version: 23 -->
<!-- version: 24 -->
# Séquence des releases fonctionnelles KSP
@@ -441,13 +441,26 @@ prompts/001-V0_1_1_START_PROMPT.md
prompts/002-V0_1_2_START_PROMPT.md
```
## Ouverture de `0.2.1`
## Ouverture de `0.2.0`
Après publication stable de `0.1.4`, la session suivante s’ouvre avec :
```text
0.2.1-pre.001
prompts/005-V0_2_1_START_PROMPT.md
0.2.0-pre.001
prompts/005-V0_2_0_START_PROMPT.md
```
Cette première prerelease reste une tranche de brainstorming/audit/planification. Elle doit réévaluer les dépendances réelles et sélectionner un **premier périmètre N2 borné** parmi Wallet, transport on-chain et Interface/wire au lieu d’implémenter les trois simultanément. La mission concrète de `0.2.1` est figée dans son plan après cette sélection.
`0.2.0` est une **release intermédiaire de cadrage de la série `0.2.x`**. Sa mission n'est pas de choisir immédiatement un premier composant N2 à implémenter, mais de reprendre méthodiquement les capacités pertinentes de `khadhroony-bot3` et de définir le plan de migration/refondation de la série.
La série `0.2.0` doit notamment produire :
- un inventaire des fonctionnalités `khadhroony-bot3` pertinentes pour `0.2.x` ;
- pour chaque capacité, une décision explicite `reprendre / adapter / refondre / abandonner / ajouter` ;
- les écarts entre les contrats historiques et les règles KSP déjà stabilisées en `0.1.x` ;
- une cartographie des dépendances entre Wallet, transport on-chain, Interface/wire, Program API/Program, policy/execution et les éventuels besoins off-chain ;
- les nouvelles fonctionnalités nécessaires qui n'existaient pas dans bot3 ou dont le contrat doit être modifié ;
- le découpage concret du reste de `0.2.x` en releases bornées `0.2.1`, `0.2.2`, etc., avec ordre, objectifs, dépendances, hors-périmètre et critères de clôture ;
- le prompt de démarrage de la première release fonctionnelle résultant de ce découpage.
Le document directeur attendu pour cette session est `docs/plans/007-V0_2_0_SERIES_PLANNING.md`. Les numéros et périmètres des releases `0.2.1+` ne deviennent contractuels qu'après validation de ce plan.

4
docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md -->
<!-- version: 23 -->
<!-- version: 24 -->
# Plan `0.1.4` — `ksp-app-config-desk`
@@ -1293,7 +1293,7 @@ Ce découpage est une **prévision**, pas une obligation de produire exactement
### 18.1 État de clôture `pre.019`
La tranche finale remet la configuration Logging canonique à une baseline de release `info`/`warn`, retire le profil de test de la source de référence, ferme les TODO bloquants `0.1.4`, crée une matrice de validation durable sous `docs/validation/`, et prépare le prompt d’ouverture de `0.2.1-pre.001`.
La tranche finale remet la configuration Logging canonique à une baseline de release `info`/`warn`, retire le profil de test de la source de référence, ferme les TODO bloquants `0.1.4`, crée une matrice de validation durable sous `docs/validation/`, et prépare le prompt d’ouverture de `0.2.0-pre.001`, release intermédiaire consacrée à l’audit de `khadhroony-bot3` et au découpage du reste de `0.2.x`.
La validation finale suit KSP-APP-034 : tous les contrôles Rust et frontend, puis le parcours `tauri dev`, puis **`cargo tauri build` en toute dernière opération**. `rel.001` ne doit être préparée qu’après succès de cette matrice.