63 lines
2.3 KiB
Markdown
63 lines
2.3 KiB
Markdown
<!-- file: idls/001.README.md -->
|
||
<!-- version: 2 -->
|
||
|
||
# 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 :
|
||
|
||
```text
|
||
<PROGRAM_ID>.<protocol_type>.<protocol_code>.json
|
||
```
|
||
|
||
Exemple actif :
|
||
|
||
```text
|
||
metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s.metadata.metaplex_token_metadata.json
|
||
```
|
||
|
||
Lorsqu’il faut conserver plusieurs versions réellement distinctes d’une même IDL :
|
||
|
||
```text
|
||
<PROGRAM_ID>.<protocol_type>.<protocol_code>.<version>.json
|
||
```
|
||
|
||
Suffixes admis, par ordre de préférence :
|
||
|
||
```text
|
||
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.
|