v0.1.4-pre.019-fix.001
This commit is contained in:
183
prompts/005-V0_2_0_START_PROMPT.md
Normal file
183
prompts/005-V0_2_0_START_PROMPT.md
Normal 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.
|
||||
Reference in New Issue
Block a user