v0.4.6
This commit is contained in:
8
prompts/001.README.md
Normal file
8
prompts/001.README.md
Normal file
@@ -0,0 +1,8 @@
|
||||
<!-- file: prompts/001.README.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Prompts actifs
|
||||
|
||||
Ce répertoire contient uniquement les prompts nécessaires aux prochaines versions fonctionnelles. Les prompts utilisés pendant la migration bot3 sont archivés sous `olddocs/archivekbot3/prompts/`.
|
||||
|
||||
- [`027_v0_4_7_metaplex_token_metadata_completion.md`](027_v0_4_7_metaplex_token_metadata_completion.md) : reprise après `0.4.6` et achèvement de Metaplex Token Metadata.
|
||||
193
prompts/027_v0_4_7_metaplex_token_metadata_completion.md
Normal file
193
prompts/027_v0_4_7_metaplex_token_metadata_completion.md
Normal file
@@ -0,0 +1,193 @@
|
||||
<!-- file: prompts/027_v0_4_7_metaplex_token_metadata_completion.md -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Prompt de session — `0.4.7` Achèvement de Metaplex Token Metadata
|
||||
|
||||
## 1. Mission
|
||||
|
||||
Reprendre `khadhroony-bot3` après la clôture validée de `0.4.6` et achever la surface Metaplex Token Metadata partiellement développée dans bot2. Tout ce qui avait été réalisé dans bot2 a été migré dans bot3 ; la reprise doit donc partir de cette base migrée complète, sans présenter la migration comme partielle.
|
||||
|
||||
Le travail ne consiste pas à recommencer le décodeur ni les matérialisations déjà présentes. Il doit partir de l’état réel du code, établir un plan de travail fermé, puis compléter l’exécuteur, les contrats stateful, le pipeline, les scénarios réutilisables, le CLI, le desktop et les validations finales.
|
||||
|
||||
Program ID canonique :
|
||||
|
||||
```text
|
||||
metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s
|
||||
```
|
||||
|
||||
## 2. Base validée `0.4.6`
|
||||
|
||||
La base comprend :
|
||||
|
||||
- architecture bot3 consolidée en onze crates ;
|
||||
- Solana Core, SPL Memo, SPL Token classique, ATA et Token-2022 ;
|
||||
- transports HTTP/WebSocket, stockage PostgreSQL, extraction Core et replay ;
|
||||
- exécution simulation-first, confirmations, signers et postvalidation ;
|
||||
- décodeur Metaplex Token Metadata d’instructions ;
|
||||
- décodeur des comptes Metaplex avec owners, PDA, seeds, bornes et variantes historiques ;
|
||||
- matrice `test-fixtures/contract-matrices/METAPLEX_TOKEN_METADATA_MATRIX.json` ;
|
||||
- matérialisation metadata déjà substantielle ;
|
||||
- coexistence explicite avec les metadata incorporées de Token-2022 ;
|
||||
- workspace, matrices, registres et bindings TS-RS validés.
|
||||
|
||||
Exception conservée : le registre ElGamal n’est pas déclaré validé réellement sur réseau. Cette exception ne doit pas être mêlée au jalon Metaplex.
|
||||
|
||||
## 3. Lectures obligatoires
|
||||
|
||||
1. `RULES.md`, `README.md`, `ROADMAP.md`, `CHANGELOG.md` et ce prompt ;
|
||||
2. `kb-lib/README.md`, `kb-lib/USAGE.md`, `kb-lib/TODO.md` ;
|
||||
3. `kb-pipeline/README.md`, `kb-pipeline-demo-scenarios/README.md` et `kb-app-demo-desktop/README.md` ;
|
||||
4. la matrice Metaplex active et les tests existants ;
|
||||
5. l’IDL archivée `idls/metadata.metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s.metaplex_token_metadata.V1_14_0.from_github_mpl-token-metadata.json` ;
|
||||
6. le prompt historique `olddocs/archivekbot2/prompts/026_v0_4_7_metaplex_token_metadata.md`, uniquement comme source historique à confronter au code bot3 actuel.
|
||||
|
||||
## 4. Première prerelease — plan de travail et brainstorming
|
||||
|
||||
La première prerelease de `0.4.7` est consacrée exclusivement à la préparation du développement. Elle ne doit pas introduire l’exécuteur, le pipeline Metaplex ou les démonstrations finales.
|
||||
|
||||
Elle doit :
|
||||
|
||||
- relire le code, les matrices, les tests, les documents actifs et les sources officielles retenues ;
|
||||
- inventorier les instructions et comptes déjà décodés ;
|
||||
- inventorier les projections metadata, admin, lifecycle et risk/compliance déjà présentes ;
|
||||
- identifier les opérations actuelles, historiques decode-only et non supportées ;
|
||||
- distinguer les travaux certains, les choix d’architecture et les questions encore ouvertes ;
|
||||
- proposer plusieurs options lorsque des choix structurants existent ;
|
||||
- produire un plan de travail ordonné par prerelease, avec dépendances, critères d’acceptation et validations prévues ;
|
||||
- établir une liste fermée des manques réels ;
|
||||
- confirmer explicitement qu’aucune capacité déjà couverte ne sera réimplémentée.
|
||||
|
||||
Cette première prerelease doit aboutir à un plan accepté avant le commencement du développement fonctionnel.
|
||||
|
||||
## 5. Frontière fonctionnelle
|
||||
|
||||
Metaplex Token Metadata reste distinct de :
|
||||
|
||||
- metadata incorporées de Token-2022 ;
|
||||
- SPL Token Metadata, prévu en `0.4.8` ;
|
||||
- Metaplex Core ;
|
||||
- JSON off-chain référencé par URI.
|
||||
|
||||
Le fetch HTTP/IPFS/Arweave et la création éventuelle de `kb-offchain-transport` sont hors périmètre de `0.4.7`. Cette décision sera étudiée en `0.4.8` avec SPL Token Metadata.
|
||||
|
||||
## 6. Matérialisation
|
||||
|
||||
Auditer les projections existantes et compléter uniquement les faits stables manquants :
|
||||
|
||||
- metadata : nom, symbole, URI, seller fee, créateurs, collection, uses, token standard, mutabilité et programmable config ;
|
||||
- admin : update authority, collection authority, delegates et changements d’autorité ;
|
||||
- lifecycle : création, mise à jour, vérification, édition, burn, lock/unlock et transitions prouvées ;
|
||||
- risk/compliance : royalties, mutabilité, créateurs non vérifiés, rule sets et délégations sensibles.
|
||||
|
||||
Chaque fait doit avoir un propriétaire unique. Ne jamais fusionner silencieusement metadata Metaplex et metadata Token-2022.
|
||||
|
||||
## 7. Exécution
|
||||
|
||||
Implémenter dans `kb-lib` :
|
||||
|
||||
- intents typés ;
|
||||
- builders validés contre les interfaces officielles ;
|
||||
- liste exacte des signers et comptes ;
|
||||
- coûts et plafonds de dépense ;
|
||||
- dry-run par défaut et simulation obligatoire ;
|
||||
- confirmation opérateur dédiée pour burn, changement d’autorité, verify/unverify, delegate/revoke, lock/unlock ;
|
||||
- classification explicite des opérations historiques decode-only.
|
||||
|
||||
## 8. Préflight et postconditions
|
||||
|
||||
Vérifier selon l’opération :
|
||||
|
||||
- owner et Program ID ;
|
||||
- PDA et seeds ;
|
||||
- mint, metadata, edition, token account, collection et authority ;
|
||||
- état de mutabilité, vérification, délégation, token standard et programmable config ;
|
||||
- cohérence des rule sets et comptes d’autorisation ;
|
||||
- postconditions stateful après soumission.
|
||||
|
||||
Tout écart doit échouer avant signature ou être classé explicitement non applicable.
|
||||
|
||||
## 9. Pipeline
|
||||
|
||||
Intégrer dans `kb-pipeline` :
|
||||
|
||||
- lectures stateful bornées ;
|
||||
- préparation et orchestration d’exécution ;
|
||||
- corrélation des comptes Metaplex ;
|
||||
- postvalidation ;
|
||||
- insertion canonique, extraction Core, replay et matérialisation idempotente ;
|
||||
- diagnostics stables et résultats exploitables par les scénarios.
|
||||
|
||||
## 10. Scénarios et démonstrations
|
||||
|
||||
Ajouter dans `kb-pipeline-demo-scenarios` :
|
||||
|
||||
- scénarios simulation-only par défaut ;
|
||||
- CLI pour les opérations retenues ;
|
||||
- fixtures synthétiques et, si possible, réseau ;
|
||||
- résultats structurés et preuves de postcondition.
|
||||
|
||||
Ajouter dans `kb-app-demo-desktop` uniquement les adaptateurs Tauri et panneaux nécessaires. La logique fonctionnelle doit rester dans les crates réutilisables.
|
||||
|
||||
## 11. Corpus et validations
|
||||
|
||||
Couvrir au minimum :
|
||||
|
||||
- NFT, SFT, token fongible, collection et programmable NFT ;
|
||||
- outer et CPI ;
|
||||
- transactions réussies et échouées ;
|
||||
- mauvais Program ID, owner, PDA, comptes, payload tronqué, suffixe et discriminant inconnu ;
|
||||
- conflits entre metadata Metaplex et metadata Token-2022 ;
|
||||
- replay PostgreSQL idempotent ;
|
||||
- simulation, confirmation, envoi et postconditions pour les opérations exécutables.
|
||||
|
||||
Ne pas déclarer une validation réseau si les fixtures ou préconditions ne sont pas disponibles.
|
||||
|
||||
## 12. Documentation pendant le développement
|
||||
|
||||
Mettre à jour au fil des prereleases uniquement les documents nécessaires pour refléter les décisions et contrats réellement introduits :
|
||||
|
||||
- les quatre documents des crates modifiées ;
|
||||
- la matrice Metaplex active ;
|
||||
- la documentation des opérations supportées, decode-only et non supportées ;
|
||||
- les rapports de validation propres aux capacités effectivement testées.
|
||||
|
||||
La mise à jour générale de clôture appartient à la dernière prerelease.
|
||||
|
||||
## 13. Dernière prerelease — clôture de `0.4.7`
|
||||
|
||||
La dernière prerelease doit être réservée à la clôture de la version. Elle ne doit pas introduire une nouvelle surface fonctionnelle majeure.
|
||||
|
||||
Elle doit obligatoirement :
|
||||
|
||||
- exécuter les tests finaux, les audits de conformité et les validations applicatives nécessaires ;
|
||||
- vérifier l’alignement entre code, matrices, registres, bindings TS-RS et documentation ;
|
||||
- mettre à jour définitivement `README.md`, `ROADMAP.md` et `CHANGELOG.md` ;
|
||||
- mettre à jour les `README.md`, `TODO.md`, `USAGE.md` et `CHANGELOG.md` des crates concernées ;
|
||||
- retirer des TODO les tâches terminées et transférer les travaux reportés vers la version correcte ;
|
||||
- archiver les prompts, plans, rapports ou documents de travail devenus historiques ;
|
||||
- supprimer les outils temporaires, fichiers de validation et références obsolètes qui ne doivent pas rester dans la version publiée ;
|
||||
- préparer le prompt complet de la session `0.4.8 — SPL Token Metadata et décision off-chain metadata` ;
|
||||
- vérifier que ce prompt commence lui aussi par une prerelease de planification et se termine par une prerelease de clôture ;
|
||||
- préparer la livraison finale de `0.4.7` selon les règles du workspace.
|
||||
|
||||
## 14. Validation finale
|
||||
|
||||
Exécuter :
|
||||
|
||||
```bash
|
||||
cargo fmt --all
|
||||
cargo check --workspace
|
||||
cargo clippy --all-targets
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
cargo test --workspace
|
||||
```
|
||||
|
||||
Si le desktop est modifié, valider avec :
|
||||
|
||||
```bash
|
||||
cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
|
||||
```
|
||||
|
||||
## 15. Livraisons
|
||||
|
||||
Après l’archive complète de départ, livrer uniquement des ZIP delta contenant `delta.md`, sans SHA-256. Les correctifs d’une même prerelease utilisent `-delta-fix-XXX.zip`, avec une numérotation recommençant à `fix-001` pour chaque nouvelle prerelease.
|
||||
Reference in New Issue
Block a user