v0.4.8-pre.001

prompts/028_v0_4_8_spl_token_metadata_and_offchain_decision.md

@@ -1,14 +1,16 @@
 <!-- file: prompts/028_v0_4_8_spl_token_metadata_and_offchain_decision.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
-# Prompt de session — 0.4.8 SPL Token Metadata et décision off-chain
+# 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` et étudier SPL Token Metadata comme surface distincte de Metaplex Token Metadata et des metadata incorporées Token-2022.
+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 :
@@ -43,12 +45,12 @@ Une règle découverte en cours de session doit être intégrée immédiatement
 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 SPL Token Metadata, Solana Program Metadata, Metaplex Token Metadata et les metadata incorporées Token-2022 ;
+- 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 le périmètre decoder/materializer/executor/pipeline/desktop ;
+- 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 ;
-- décider séparément le périmètre éventuel de `kb-offchain-transport` ;
+- 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.
@@ -76,10 +78,10 @@ La mise en œuvre peut évoluer pendant la version, mais les scénarios réels n
 
 Avant le code :
 
-1. vérifier si une IDL officielle existe pour la surface SPL Metadata visée ;
+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 et au contrat étudiés ;
+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 :
@@ -101,18 +103,18 @@ Si aucune IDL officielle exploitable n’existe, documenter cette absence et uti
 
 ## Frontières
 
-- SPL Token Metadata reste distinct de Metaplex Token Metadata ;
-- Solana Program Metadata doit être identifié exactement avant d’être assimilé ou non à SPL Token Metadata ;
-- les metadata incorporées Token-2022 gardent leur propre contrat ;
+- `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`
 
-Étudier une crate dédiée pour HTTP(S), IPFS et Arweave avec : timeout, taille, type MIME, redirections, cache, hash, provenance, protection SSRF et interdiction des réseaux locaux. Le contenu distant ne modifie jamais le statut canonique du replay on-chain.
+`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.
 
-Cette décision doit rester séparée de l’implémentation canonique on-chain. Elle peut être reportée à une version suivante si son périmètre rend `0.4.8` trop large.
+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