khadhroony-bot3/idls/001.README.md

IDL locales

Ce répertoire contient les IDL téléchargées depuis des sources officielles ou de référence et utilisées pour auditer les décodeurs, matérialiseurs et exécuteurs.

Règle d’admission

Une IDL devient une source locale active lorsqu’un décodeur ou un exécuteur correspondant est développé. À ce moment-là, il faut :

1. télécharger l’IDL utilisée ;
2. vérifier son Program ID et sa provenance ;
3. conserver son contenu JSON inchangé ;
4. la renommer selon la convention canonique ;
5. documenter sa version ou son commit lorsqu’ils sont connus ;
6. ajouter des tests comparant, selon le périmètre disponible, l’IDL, le runtime, les builders et l’interface officielle.

Les fichiers JSON ne doivent pas recevoir de commentaires ni être reformattés uniquement pour satisfaire la documentation.

Convention de nommage

Forme principale :

<PROGRAM_ID>.<protocol_type>.<protocol_code>.json

Exemple actif :

metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s.metadata.metaplex_token_metadata.json

Lorsqu’il faut conserver plusieurs versions réellement distinctes d’une même IDL :

<PROGRAM_ID>.<protocol_type>.<protocol_code>.<version>.json

Suffixes admis, par ordre de préférence :

v<semver>
commit-<short_hash>
slot-<deployment_slot>
date-YYYY-MM-DD

La version ne doit jamais être inventée. Tant qu’une seule IDL est conservée pour un programme, le suffixe de version reste facultatif.

Classification

• protocol_type représente la famille fonctionnelle stable, par exemple metadata, launchpad, amm, clmm, lending, router, vault ou orderbook.
• protocol_code représente le protocole ou la surface exacte, par exemple metaplex_token_metadata.
• La classification est validée lors de l’implémentation du décodeur ou de l’exécuteur ; les IDL de référence non encore utilisées ne doivent pas être renommées massivement sur une classification incertaine.

Intégrité

Le renommage du fichier est autorisé. Le contenu de l’IDL doit rester identique à la source téléchargée.

Les graphies externes telles que token2022, les noms de types Anchor et les identifiants publiés dans l’IDL ne doivent pas être adaptés à la nomenclature interne du workspace.