v0.4.8
This commit is contained in:
@@ -0,0 +1,158 @@
|
||||
<!-- file: prompts/028_v0_4_8_spl_token_metadata_and_offchain_decision.md -->
|
||||
<!-- version: 3 -->
|
||||
|
||||
# Prompt de session — 0.4.8 Solana Program Metadata et complétude Token-2022
|
||||
|
||||
## Mission
|
||||
|
||||
Reprendre `khadhroony-bot3` après la clôture de `0.4.7`, implémenter Solana Program Metadata (`ProgM6JCCvbYkfKqJYHePx4xxSUSqJp7rh8Lyv7nk7S`) comme surface indépendante, puis auditer et compléter le contrat `spl-token-metadata-interface` déjà implémenté par Token-2022. Metaplex Token Metadata, Token-2022 Token Metadata et Solana Program Metadata doivent rester strictement séparés.
|
||||
|
||||
La session doit commencer par une planification complète et structurée, puis conserver une planification vivante pendant tout le développement. Le plan initial doit couvrir l’ensemble de la version, mais il peut être corrigé, enrichi, réordonné ou regrouper des phases lorsque l’état réel du code le justifie.
|
||||
|
||||
Le plan actif est `docs/plans/V0_4_8_SOLANA_PROGRAM_METADATA_AND_TOKEN_2022_COMPLETENESS_PLAN.md`.
|
||||
|
||||
## Exigences de départ obligatoires
|
||||
|
||||
Avant toute proposition d’architecture, modification de code ou création de delta :
|
||||
|
||||
1. lire les documents racine actifs, notamment `README.md`, `ROADMAP.md`, `RULES.md` et les documents auxquels ils renvoient ;
|
||||
2. lire intégralement les règles et normes actives du projet :
|
||||
- `docs/rules/RULES_GENERAL.md` ;
|
||||
- `docs/rules/RULES_RUST.md` ;
|
||||
- `docs/rules/RULES_SPECIFIC_KHADHROONY.md` ;
|
||||
- `docs/rules/CRATE_DOCUMENTATION_RULES.md` ;
|
||||
- `docs/rules/VERSION_DEVELOPMENT_LIFECYCLE.md` ;
|
||||
3. relever et appliquer les conventions portant notamment sur :
|
||||
- Rust 2024 et les restrictions du workspace ;
|
||||
- visibilité, exports publics, imports et documentation Rust ;
|
||||
- interdictions `unsafe`, `unwrap`, `expect`, `panic` et règles Tauri spécifiques ;
|
||||
- entêtes `file:` et `version:` ;
|
||||
- incrémentation des versions locales des fichiers modifiés ;
|
||||
- lignes vides, fins de fichier et organisation des modules ;
|
||||
- emplacement attendu de chaque type de code, test, fixture, IDL et document ;
|
||||
- format, contenu et rôle de `README.md`, `USAGE.md`, `TODO.md`, `CHANGELOG.md`, rapports, guides, prompts et archives ;
|
||||
- documents à mettre à jour selon la nature de chaque modification ;
|
||||
- ordre antéchronologique des changelogs et limitation de chaque changelog à son propre périmètre ;
|
||||
- politique des prereleases, deltas, correctifs et archivages ;
|
||||
4. inspecter les `README.md`, `USAGE.md`, `TODO.md` et `CHANGELOG.md` des crates directement concernées avant de les modifier ;
|
||||
5. inspecter les audits, matrices, IDL, rapports de validation et archives pertinentes sans modifier les archives historiques ;
|
||||
6. vérifier l’état réel du workspace avant d’utiliser une hypothèse issue d’une ancienne session ou d’un ancien document.
|
||||
|
||||
Une règle découverte en cours de session doit être intégrée immédiatement au travail courant ; elle ne doit pas être reportée à la clôture.
|
||||
|
||||
## Première prerelease obligatoire
|
||||
|
||||
La première prerelease est consacrée au plan et au brainstorming. Avant le code, elle doit :
|
||||
|
||||
- inventorier les programmes, Program ID, interfaces, comptes, instructions, builders et sources officielles ;
|
||||
- distinguer précisément Solana Program Metadata, Metaplex Token Metadata, Token-2022 Token Metadata et le rôle contractuel de `spl-token-metadata-interface` ;
|
||||
- identifier ce qui existe déjà dans `kb-program-ids`, `kb-lib`, `kb-pipeline`, `kb-pipeline-demo-scenarios`, `kb-app-demo-desktop`, `kb-store`, les matrices et les documents ;
|
||||
- fixer séparément le périmètre decoder/materializer/executor/pipeline/desktop de `ProgM6…` et les compléments nécessaires dans les modules Token-2022 existants ;
|
||||
- décider les fixtures et scénarios réseau nécessaires ;
|
||||
- découper les prereleases et définir leurs critères d’acceptation ;
|
||||
- enregistrer le report de `kb-offchain-transport` à l’horizon `0.15+` sans commencer son implémentation ;
|
||||
- préciser les documents, changelogs, TODO, matrices et rapports à maintenir pendant chaque phase.
|
||||
|
||||
Le plan doit couvrir la version complète dès le départ, y compris les scénarios Devnet réels. Il reste toutefois souple : des étapes peuvent être ajoutées, déplacées, fusionnées ou séparées si les découvertes techniques l’exigent.
|
||||
|
||||
L’objectif opérationnel est de conserver des deltas petits et testables, dont la préparation reste généralement compatible avec une livraison toutes les 10 à 15 minutes de travail effectif. Une phase trop large doit être divisée ; des phases devenues artificiellement petites peuvent être regroupées.
|
||||
|
||||
## Scénarios Devnet réels obligatoirement prévus
|
||||
|
||||
L’erreur à ne pas reproduire depuis `0.4.7` est de ne pas avoir prévu les scénarios réels dans la planification initiale.
|
||||
|
||||
Pour chaque capacité exécutable retenue, le plan doit prévoir dès le départ, puis maintenir pendant le développement :
|
||||
|
||||
1. tests contractuels et synthétiques ;
|
||||
2. campagne réutilisable dans `kb-pipeline-demo-scenarios` lorsque cela apporte une validation automatisable ;
|
||||
3. panneau ou parcours réel dans `kb-app-demo-desktop` ;
|
||||
4. fixture Devnet reproductible et préparée par les APIs Rust du workspace lorsque cela est approprié ;
|
||||
5. simulation RPC du message exact ;
|
||||
6. soumission confirmée lorsque l’opération est sûre et réalisable ;
|
||||
7. lectures stateful, postconditions et matérialisation observables ;
|
||||
8. état de validation explicite : synthétique, simulé Devnet, soumis Devnet, non applicable, indisponible ou reporté avec justification.
|
||||
|
||||
La mise en œuvre peut évoluer pendant la version, mais les scénarios réels ne doivent jamais disparaître du plan. Une surface ne doit pas être annoncée comme validée réseau sans preuve d’exécution réelle observée.
|
||||
|
||||
## Audit et gestion des IDL
|
||||
|
||||
Avant le code :
|
||||
|
||||
1. vérifier l’IDL officielle et les sources officielles de Solana Program Metadata ;
|
||||
2. examiner l’IDL déjà présente :
|
||||
`idls/metadata.ProgM6JCCvbYkfKqJYHePx4xxSUSqJp7rh8Lyv7nk7S.solana_program_metadata.V0_0_0.from_github_solana_program.json` ;
|
||||
3. déterminer, depuis les sources officielles, si cette IDL correspond exactement au programme `ProgM6…` et à son contrat ;
|
||||
4. ne pas assimiler deux surfaces seulement parce que leurs noms contiennent « metadata ».
|
||||
|
||||
Lorsqu’une IDL officielle pertinente est trouvée :
|
||||
|
||||
- conserver une copie brute et non réécrite sous `idls/` ;
|
||||
- appliquer la convention de nommage documentée dans `idls/001.README.md` ;
|
||||
- encoder la provenance et la version dans le nom ;
|
||||
- vérifier le Program ID déclaré, la validité JSON et l’empreinte ;
|
||||
- mettre à jour au minimum :
|
||||
- `idls/001.README.md` ;
|
||||
- `docs/IDL_AUDIT.md` ;
|
||||
- `docs/IDL_TO_KB_LIB_NOMENCLATURE.md` ;
|
||||
- `docs/MISSING_PROGRAM_IDLS.md` si le statut « manquante » change ;
|
||||
- les documents de classification ou de surface IDL concernés ;
|
||||
- mettre à jour les compteurs, inventaires, provenance, nomenclature cible et décisions architecturales associées ;
|
||||
- ne jamais inventer une version ou une provenance absente de la source.
|
||||
|
||||
Si aucune IDL officielle exploitable n’existe, documenter cette absence et utiliser les crates/interfaces officielles comme source de vérité sans fabriquer d’IDL.
|
||||
|
||||
## Frontières
|
||||
|
||||
- `spl-token-metadata-interface` ne doit pas être présenté comme un programme autonome ;
|
||||
- Solana Program Metadata est une surface indépendante de Token-2022 Token Metadata ;
|
||||
- les metadata Token-2022 restent dans les modules Token-2022 existants et ne sont pas un décodeur partiel de `ProgM6…` ;
|
||||
- le fetch off-chain n’est pas incorporé au décodeur canonique ;
|
||||
- les IDL et interfaces archivées restent des références statiques ;
|
||||
- les archives sous `olddocs/` ne doivent pas être modifiées hors opération d’archivage explicitement prévue.
|
||||
|
||||
## Décision `kb-offchain-transport`
|
||||
|
||||
`kb-offchain-transport` est hors périmètre de `0.4.8` et reportée à l’horizon `0.15+`. Aucun module HTTP(S), IPFS ou Arweave ne doit être créé pendant cette version.
|
||||
|
||||
La frontière architecturale reste documentée : timeout, taille, MIME, redirections, cache, hash, provenance, résolution DNS contrôlée, protection SSRF et interdiction des réseaux locaux seront obligatoires lorsqu’un consommateur réel justifiera cette crate. Le contenu distant ne modifiera jamais le statut canonique du replay on-chain.
|
||||
|
||||
## Discipline documentaire pendant la version
|
||||
|
||||
À chaque delta :
|
||||
|
||||
- mettre à jour uniquement les documents rendus faux ou incomplets par les modifications du delta ;
|
||||
- conserver les `README.md` et `USAGE.md` généralistes, structurés par fonction ou groupe, jamais comme journaux de prerelease ;
|
||||
- réserver les détails chronologiques aux changelogs et rapports de validation ;
|
||||
- supprimer des TODO les tâches réellement terminées ;
|
||||
- ajouter seulement des TODO explicites, encore actionnables et placés dans le bon périmètre ;
|
||||
- maintenir les changelogs du plus récent au plus ancien et limiter chaque entrée aux changements de son emplacement ;
|
||||
- réconcilier les matrices, guides, rapports, nomenclatures et documents IDL avec le code livré ;
|
||||
- archiver les documents de travail devenus historiques plutôt que de les laisser parmi les documents actifs.
|
||||
|
||||
## Dernière prerelease obligatoire
|
||||
|
||||
La dernière prerelease doit être réservée à :
|
||||
|
||||
- validations finales et conformité ;
|
||||
- documentation générale et par crate ;
|
||||
- nettoyage des TODO ;
|
||||
- mise à jour du ROADMAP et des changelogs ;
|
||||
- réconciliation des documents IDL ;
|
||||
- archivage du plan, des rapports intermédiaires et du prompt de session ;
|
||||
- préparation du prompt suivant ;
|
||||
- préparation de la release finale.
|
||||
|
||||
La dernière prerelease ne doit pas servir à découvrir tardivement des scénarios Devnet qui n’auraient jamais été planifiés.
|
||||
|
||||
## Contrôles finaux
|
||||
|
||||
```bash
|
||||
cargo fmt --all
|
||||
cargo check --workspace
|
||||
cargo clippy --all-targets
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
cargo test --workspace
|
||||
cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
|
||||
```
|
||||
|
||||
Les validations Devnet doivent être exécutées selon les parcours documentés dans `kb-app-demo-desktop`, avec conservation des signatures, résultats de simulation, confirmations, postconditions et preuves de matérialisation pertinentes.
|
||||
Reference in New Issue
Block a user