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

10
ROADMAP.md
View File

@@ -1,5 +1,5 @@
<!-- file: ROADMAP.md -->
<!-- version: 18 -->
<!-- version: 19 -->
# Roadmap KSP
@@ -42,6 +42,14 @@ Les contrats publics supplémentaires ne sont introduits que lorsqu'une release
## 0.2.x — Accès Solana et fondation programmes
### Release de cadrage `0.2.0`
- [ ] `0.2.0` — Auditer les fonctionnalités pertinentes de `khadhroony-bot3`, décider ce qui doit être repris, refondu, abandonné ou ajouté dans KSP, puis découper et ordonner les releases fonctionnelles restantes de `0.2.x`.
`0.2.0` est une release intermédiaire de transition et de planification de série. Elle ne doit pas démarrer par l'implémentation arbitraire d'un composant N2 : elle établit d'abord la cartographie fonctionnelle, les écarts avec KSP, les dépendances, les contrats à préserver ou redéfinir et le découpage concret de `0.2.1`, `0.2.2`, etc.
### Capacités à répartir dans les releases fonctionnelles suivantes
- [ ] Introduire `ksp-onchain-transport-lib` avec des modèles de transport homogènes indépendants du store.
- [ ] Introduire `ksp-wallet-lib` et `ksp-app-wallet-desk`.
- [ ] Développer la première surface utile de `ksp-interface-lib`.

75
deltas/0.1.4/pre.019-fix.001.md Normal file
View File

@@ -0,0 +1,75 @@
<!-- file: deltas/0.1.4/pre.019-fix.001.md -->
<!-- version: 1 -->
# Delta `0.1.4-pre.019-fix.001` — reprise suivante en `0.2.0`
## Base
`0.1.4-pre.019` a préparé à tort un prompt ouvrant directement `0.2.1` et demandant de sélectionner immédiatement un premier périmètre N2. La direction attendue est une version intermédiaire `0.2.0` consacrée à l'étude de `khadhroony-bot3` et à la planification de l'ensemble du reste de `0.2.x`.
## Objectif
Corriger uniquement le cadrage de la reprise après `v0.1.4` :
- `0.2.0` devient la release de transition/audit/planification ;
- l'inventaire bot3 doit couvrir les fonctions à reprendre, adapter, refondre ou abandonner ;
- les fonctionnalités nouvelles ou modifiées doivent être identifiées ;
- les dépendances et l'ordre d'introduction doivent être explicités ;
- le découpage concret de `0.2.1`, `0.2.2`, etc. doit être un **résultat** de `0.2.0`, pas une hypothèse préalable.
## Changements
### Prompt suivant
Le prompt erroné :
```text
prompts/005-V0_2_1_START_PROMPT.md
```
doit être **supprimé** et remplacé par :
```text
prompts/005-V0_2_0_START_PROMPT.md
```
Le nouveau prompt définit `0.2.0-pre.001` comme une tranche de méthode/inventaire et demande un plan directeur `docs/plans/007-V0_2_0_SERIES_PLANNING.md`.
### Roadmap et séquence
`ROADMAP.md` et `docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md` distinguent désormais :
- `0.2.0` : audit bot3 + décisions de reprise/refondation + nouvelles fonctions + découpage de série ;
- `0.2.1+` : releases fonctionnelles dont les missions seront définies à partir du résultat de `0.2.0`.
Le plan `0.1.4` et l'index des prompts sont synchronisés sur cette reprise.
## Version technique
Aucun fichier participant au code/build/runtime/config n'est modifié. Conformément au workflow KSP, la version Cargo **ne change pas** :
```text
workspace.package.version = 0.1.4-pre.19
```
Le suffixe `pre.019-fix.001` identifie le delta documentaire, pas une nouvelle version technique Cargo.
## Application
Après extraction des fichiers du ZIP, supprimer explicitement l'ancien prompt :
```bash
rm prompts/005-V0_2_1_START_PROMPT.md
```
Puis vérifier :
```bash
grep -RIn "0\.2\.1-pre\.001\|V0_2_1_START_PROMPT" ROADMAP.md docs/plans prompts
```
La commande ne doit plus trouver de référence présentant `0.2.1` comme session directement ouverte après `0.1.4`. Les mentions de `0.2.1+` comme futures releases issues du découpage `0.2.0` restent normales.
## Suite
La validation technique/fonctionnelle de `0.1.4-pre.019` reste inchangée. Après clôture stable `v0.1.4`, la session suivante doit être `0.2.0-pre.001`.

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.

4
prompts/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: prompts/000-README.md -->
<!-- version: 7 -->
<!-- version: 8 -->
# Prompts KSP
@@ -25,4 +25,4 @@ Le prompt générique `0.1.x` a été affiné pendant `0.0.3` puis remplacé par
- [`002-V0_1_2_START_PROMPT.md`](002-V0_1_2_START_PROMPT.md) — prompt final destiné à ouvrir `0.1.2 — Logging foundation` après publication stable de `0.1.1`.
- [`003-V0_1_3_START_PROMPT.md`](003-V0_1_3_START_PROMPT.md) — prompt historique destiné à ouvrir `0.1.3 — Configuration foundation` après publication stable de `0.1.2` ;
- [`004-V0_1_4_START_PROMPT.md`](004-V0_1_4_START_PROMPT.md) — prompt final destiné à ouvrir `0.1.4 — ksp-app-config-desk` après publication stable de `0.1.3`.
- [`005-V0_2_1_START_PROMPT.md`](005-V0_2_1_START_PROMPT.md) — prompt de reprise préparé à la clôture de `0.1.4`; il ouvre `0.2.1-pre.001` par un brainstorming visant à sélectionner le premier périmètre N2 borné.
- [`005-V0_2_0_START_PROMPT.md`](005-V0_2_0_START_PROMPT.md) — prompt de reprise préparé à la clôture de `0.1.4`; il ouvre `0.2.0-pre.001`, release intermédiaire d'audit de `khadhroony-bot3`, de comparaison avec KSP et de planification/découpage du reste de `0.2.x`.

183
prompts/005-V0_2_0_START_PROMPT.md Normal file
View File

@@ -0,0 +1,183 @@
<!-- file: prompts/005-V0_2_0_START_PROMPT.md -->
<!-- version: 1 -->
# Prompt de démarrage `0.2.0` — audit bot3 et planification de la série `0.2.x`
## Contexte de reprise
La base attendue est la release stable `v0.1.4` de `khadhroony-solana-project`. Les fondations N1 `ksp-core-lib`, `ksp-logging-lib`, `ksp-config-lib` et la première application Tauri de référence `ksp-app-config-desk` sont alors stabilisées.
La série `0.2.x` doit ouvrir les capacités Solana suivantes, mais **leur ordre et leur découpage ne sont pas encore considérés comme figés** :
- Wallet et application wallet spécialisée ;
- transport on-chain ;
- Interface/wire Solana/SPL/Metaplex ;
- contrats Program API et implémentations Program ;
- policy/execution lorsque les premiers scénarios réels le justifient ;
- transport off-chain seulement au premier besoin réel ;
- scénarios/demos nécessaires pour valider chaque capacité sans dupliquer les bibliothèques.
`0.2.0` est volontairement une **release intermédiaire de transition, d'audit et de planification de série**. Elle ne doit pas être traitée comme la première release d'implémentation N2.
## Mission de `0.2.0`
Étudier méthodiquement `khadhroony-bot3` afin de déterminer ce que KSP doit reprendre conceptuellement ou fonctionnellement, ce qui doit être adapté ou refondu pour respecter les nouvelles règles KSP, ce qui doit être abandonné, et quelles nouvelles fonctionnalités doivent être ajoutées.
À partir de cet audit, établir le **découpage concret du reste de `0.2.x`** en releases bornées (`0.2.1`, `0.2.2`, etc.) avec un ordre justifié par les dépendances et les scénarios d'utilisation.
Aucune fonctionnalité de bot3 ne doit être migrée mécaniquement uniquement parce qu'elle existe. Inversement, aucune capacité utile ne doit être oubliée simplement parce qu'elle n'apparaît pas dans la roadmap actuelle.
## Première mission : `0.2.0-pre.001`
La première prerelease est une tranche de **brainstorming, inventaire et méthode d'audit**. Elle ne développe pas de capacité N2 fonctionnelle.
Elle doit :
1. relire `ROADMAP.md`, `docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md`, les règles KSP et les décisions d'architecture stabilisées en `0.1.x` ;
2. définir la méthode d'analyse de `khadhroony-bot3` : crates, applications, workers/jobs, transports, interfaces, wallet, decoders/executors, scénarios/demos, documentation et conventions utiles ;
3. construire un premier inventaire des fonctionnalités et contrats de bot3 pertinents pour `0.2.x` ;
4. distinguer clairement **fonctionnalité**, **implémentation historique**, **contrat public**, **dépendance externe** et **convention de projet** afin de ne pas confondre réutilisation fonctionnelle et copie mécanique ;
5. ouvrir le plan directeur `docs/plans/007-V0_2_0_SERIES_PLANNING.md` avec une prévision souple des prereleases de `0.2.0` ;
6. définir les critères qui permettront de classer chaque élément audité en `reprendre`, `adapter`, `refondre`, `abandonner` ou `ajouter` ;
7. ne figer aucun découpage `0.2.1+` tant que l'inventaire n'est pas suffisamment complet.
## Axes d'audit obligatoires
### 1. Cartographie de `khadhroony-bot3`
Pour les parties pertinentes de bot3, inventorier au minimum :
- rôle fonctionnel ;
- crate/application/service propriétaire ;
- APIs publiques et DTOs réellement utiles ;
- dépendances externes ;
- dépendances entre composants ;
- configuration/environnement nécessaires ;
- exigences Logging/Tracing ;
- scénarios de validation et demos existants ;
- tests et invariants importants ;
- limitations, dette ou décisions historiques à ne pas reproduire.
Les fondations déjà refondues dans `0.1.x` ne doivent pas être remigrées. Elles servent de **contraintes** pour juger les capacités historiques.
### 2. Matrice de décision de reprise
Pour chaque capacité significative, produire une décision documentée :
```text
capacité / contrat
source bot3
statut : reprendre | adapter | refondre | abandonner | ajouter
justification
propriétaire KSP pressenti
dépendances
risques / dette à éviter
release 0.2.x candidate
```
`reprendre` signifie reprendre le besoin/contrat utile, pas nécessairement copier le code.
### 3. Fonctionnalités à modifier
Identifier explicitement les fonctions de bot3 dont le comportement ou l'ownership doit changer dans KSP, notamment lorsque les règles stabilisées imposent une autre frontière :
- Config et environnement sous ownership exclusif de `ksp-config-lib` ;
- Logging/runtime tracing sous ownership exclusif de `ksp-logging-lib` ;
- applications Tauri minces avec DTOs applicatifs ;
- dépendances externes communes centralisées au workspace ;
- interfaces/wires isolées de manière à éviter les dépendances métier externes dans les couches supérieures ;
- séparation entre Program API, implémentations Program, policy et orchestration d'exécution ;
- services/workers autonomes et scénarios/demos spécialisés lorsqu'ils deviendront pertinents.
### 4. Fonctionnalités à ajouter
Rechercher également ce qui manque à bot3 pour atteindre les objectifs KSP. Pour chaque ajout proposé, préciser :
- besoin concret ;
- raison pour laquelle bot3 ne suffit pas ;
- dépendances ;
- emplacement architectural KSP ;
- release `0.2.x` candidate ;
- nécessité réelle ou simple idée à reporter dans `docs/IDEAS.md`.
### 5. Dépendances et ordre d'introduction
Construire un graphe de dépendances fonctionnelles entre au moins :
- Wallet ;
- transport on-chain ;
- Interface/wire ;
- Program API / Program ;
- policy/execution ;
- éventuels besoins off-chain ;
- scénarios/demos nécessaires à la validation.
L'ordre final doit venir de ce graphe et des premiers cas d'usage, pas de l'ordre historique des crates de bot3.
## Livrable principal de `0.2.0`
Le document directeur est :
```text
docs/plans/007-V0_2_0_SERIES_PLANNING.md
```
Il doit contenir au minimum :
1. inventaire et synthèse bot3 ;
2. matrice `reprendre / adapter / refondre / abandonner / ajouter` ;
3. écarts et nouvelles exigences KSP ;
4. dépendances et ordre d'introduction ;
5. découpage proposé des releases `0.2.1+` ;
6. pour chaque release : mission, périmètre, hors-périmètre, dépendances, critères de clôture et estimation souple des prereleases ;
7. risques et sujets restant en `IDEAS`;
8. décision sur la **première release fonctionnelle `0.2.x`** et préparation de son prompt de démarrage.
Le nombre de releases `0.2.1+` n'est pas fixé à l'avance. Il doit être déterminé par la taille réelle des capacités et la règle KSP de tranches bornées.
## Périmètre pressenti à étudier — sans préjuger du découpage final
### Wallet
Étudier les capacités historiques de création/import/export, gestion de clés, signature, séparation secret/public, organisation des wallets/profils, interactions avec Config et besoins de l'application wallet. Les secrets wallet ne doivent pas être déplacés dans Config par commodité.
### Transport on-chain
Étudier HTTP/WS, providers/endpoints, subscriptions, timeouts, retry/backoff, concurrence, modèles de réponse, observabilité et frontière avec les futurs Store/workers. Reprendre les besoins utiles de bot3 sans importer ses couplages historiques.
### Interface/wire
Inventorier les interfaces Solana/SPL/Metaplex utilisées dans bot3 et décider lesquelles doivent être réexportées, encapsulées ou réimplémentées de façon compatible dans `ksp-interface-lib`, notamment pour éviter les doublons de versions et les dépendances métier directes des couches supérieures.
### Program / execution
Étudier les contrats historiques de decoders/executors, les règles de compatibilité/deprecation, la séparation entre préparation d'instruction, policy de sécurité et orchestration d'exécution, puis décider à quel moment ces surfaces deviennent nécessaires dans `0.2.x`.
### Scénarios, demos et infrastructure de validation
Identifier ce qui, dans les scenarios/demos de bot3, doit être repris comme méthode de validation des nouvelles crates KSP et ce qui doit être remplacé par le modèle Tauri/scénarios désormais établi.
## Contraintes architecturales à préserver
- Rust 2024, `unsafe` interdit, pas de `unwrap`/`expect`/`panic` ni opérateur `?` selon les règles KSP ;
- dépendances externes communes sous `[workspace.dependencies]` puis `.workspace = true` ;
- `ksp-config-lib` reste seul propriétaire de Config, `.env`, environnement et persistence Config ;
- `ksp-logging-lib` reste seule façade/propriétaire du runtime `tracing` ;
- les applications Tauri suivent le modèle validé par Config Desk et restent minces ;
- `cargo tauri build -c ...` reste la toute dernière opération de validation lorsqu'une application Tauri est concernée ;
- les executables KSP ne dépendent pas directement des crates Solana/protocoles au-delà des exceptions bas niveau explicitement autorisées ;
- `ksp-interface-lib` doit réduire les dépendances directes des couches supérieures aux bibliothèques externes métier ;
- les APIs extensibles utilisent les crates `*-api` prévues lorsque le besoin réel est démontré ;
- les demos/scénarios restent spécialisés et ne dupliquent pas la logique des bibliothèques ;
- ne pas introduire Store/Materializer/worker par anticipation si leur besoin appartient à `0.3.x`.
## Discipline de `0.2.0`
- `pre.001` : méthode, inventaire initial et plan d'audit ;
- prereleases intermédiaires : audit bot3 par domaines, matrices de décision, dépendances et propositions de découpage ;
- dernière prerelease : validation de la cartographie, découpage final `0.2.1+`, documentation, nettoyage et prompt de la première release fonctionnelle ;
- `rel.001` : publier le cadrage stable de la série `0.2.x` ;
- un défaut livré reçoit un `fix.NNN`, il n'est pas réécrit silencieusement ;
- tous les deltas `0.2.0` sont commités.
Commencer la session par `0.2.0-pre.001` : relire les règles et plans, définir la méthode d'audit de `khadhroony-bot3`, puis établir la première cartographie des capacités avant toute modification fonctionnelle.

68
prompts/005-V0_2_1_START_PROMPT.md
View File

@@ -1,68 +0,0 @@
<!-- file: prompts/005-V0_2_1_START_PROMPT.md -->
<!-- version: 1 -->
# Prompt de démarrage `0.2.1` — ouverture des capacités Solana N2
## Contexte de reprise
La base attendue est la release stable `v0.1.4` de `khadhroony-solana-project`. Les fondations `ksp-core-lib`, `ksp-logging-lib`, `ksp-config-lib` et la première application de référence `ksp-app-config-desk` sont alors stabilisées.
`0.2.x` ouvre les capacités Solana N2. Les candidats déjà retenus par l’architecture sont notamment :
- `ksp-wallet-lib` puis une application wallet spécialisée ;
- `ksp-onchain-transport-lib` ;
- `ksp-interface-lib` pour les contrats wire/réexports/réimplémentations compatibles ;
- plus tard `ksp-program-api` / `ksp-program-lib` puis la chaîne d’exécution.
Wallet, transport on-chain et Interface sont partiellement indépendants. **Ne pas supposer leur ordre sans le réévaluer.**
## Première mission : `0.2.1-pre.001`
La première prerelease est une tranche de **brainstorming, audit et planification**, pas une grosse implémentation.
Elle doit :
1. partir de la base stable `v0.1.4` et relire `ROADMAP.md`, `docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md`, les règles N1/N2 et les décisions d’architecture ;
2. inventorier les besoins réels et dépendances pour Wallet, transport on-chain et Interface/wire ;
3. sélectionner **un seul premier périmètre fonctionnel borné** pour `0.2.1` ;
4. justifier cet ordre par les premiers scénarios d’usage et les dépendances réelles, pas par symétrie avec bot2/bot3 ;
5. définir les contrats publics minimaux, hors-périmètre, risques, dépendances externes, tests et critères de clôture ;
6. produire le plan détaillé `docs/plans/007-V0_2_1_..._PLAN.md` avec une prévision souple des prereleases ;
7. ne commencer le développement fonctionnel qu’après validation de ce plan.
## Contraintes architecturales à préserver
- Rust 2024, `unsafe` interdit, pas de `unwrap`/`expect`/`panic` ni opérateur `?` selon les règles KSP ;
- dépendances externes communes sous `[workspace.dependencies]` puis `.workspace = true` ;
- `ksp-config-lib` reste seul propriétaire de Config, `.env`, environnement et persistence Config ;
- `ksp-logging-lib` reste seule façade/propriétaire du runtime `tracing` ;
- les applications Tauri restent minces et suivent le modèle validé par Config Desk ;
- `cargo tauri build -c ...` reste la dernière opération de validation Tauri ;
- les executables KSP ne dépendent pas directement des crates Solana/protocoles au-delà des exceptions bas niveau explicitement autorisées ;
- `ksp-interface-lib` possède les interfaces/wires Solana/SPL/Metaplex nécessaires lorsqu’un réexport contrôlé ou une réimplémentation compatible est préférable à une dépendance métier directe ;
- les APIs publiques extensibles utilisent les crates `*-api` prévues par l’architecture ;
- les demos/scénarios restent spécialisés et ne dupliquent pas la logique des bibliothèques.
## Points à réexaminer explicitement
### Wallet
Évaluer format KSP, stockage/chiffrement, import/export, pubkey/signature, séparation secret/public, profils/réseaux et frontière avec Config. Ne pas déplacer les secrets wallet dans Config par commodité.
### Transport on-chain
Évaluer RPC HTTP/WS, providers, timeouts/retry/backoff, subscriptions, modèles de réponse homogènes, séparation transport/store et configuration des endpoints. Aucun Store n’est introduit dans `0.2.1` sauf décision explicite de replanification.
### Interface/wire
Réévaluer la politique de réexport/réimplémentation pour les interfaces Solana/SPL/Metaplex déjà identifiées. La crate doit éviter les doublons de versions et permettre aux crates KSP supérieures de ne pas dépendre directement des bibliothèques métier externes.
## Discipline de session
- `pre.001` : réflexion + plan ;
- prereleases suivantes : tranches bornées ;
- dernière prerelease : validations finales, documentation, nettoyage, changelog et prompt suivant ;
- un défaut livré reçoit un `fix.NNN`, il n’est pas réécrit silencieusement ;
- tous les deltas `0.2.1` sont commités.
Commencer la session par l’audit/brainstorming de `0.2.1-pre.001` et proposer la sélection du premier périmètre N2 avant toute modification fonctionnelle.