khadhroony-solana-project/prompts/005-V0_2_0_START_PROMPT.md

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 :

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 :

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.