v0.2.0-pre.002

docs/architecture/006-WIRE_AND_PROGRAM.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/006-WIRE_AND_PROGRAM.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Wire, Program API et implémentations Program
 
@@ -46,6 +46,21 @@ Les Program IDs fondamentaux restent possédés par `ksp-core-lib`.
 - policy/safety ;
 - lifecycle d'exécution réseau.
 
+## API publique de `ksp-interface-lib`
+
+`ksp-interface-lib` reste une seule crate pour l'instant : aucune `ksp-interface-api` séparée n'est créée.
+
+La façade doit néanmoins exposer une API publique wire stable et réutilisable par :
+
+```text
+ksp-program-lib
+external ksp-program-<name>-lib
+```
+
+Une implementation externe peut donc expérimenter contre les mêmes contrats wire publics avant intégration officielle dans KSP. Lorsqu'un wire externe devient officiel, son intégration dans `ksp-interface-lib` doit rester compatible avec l'API publique retenue, sauf évolution de contrat explicitement versionnée/documentée.
+
+Si une future contrainte de dépendances démontre qu'un split `ksp-interface-api` apporte une valeur réelle, il pourra être étudié selon `KSP-API-007`; la symétrie avec Program ne suffit pas.
+
 ## Propriété des codecs wire
 
 Pour le code KSP officiel, les dépendances directement utilisées pour encoder/décoder les formats wire, notamment `borsh`, `wincode` ou codecs équivalents, appartiennent normalement à `ksp-interface-lib`.
@@ -403,6 +418,18 @@ Les validations peuvent combiner selon le cas :
 
 Une crate externe provoquant volontairement une génération incompatible de dépendances fondamentales ne doit pas être ajoutée au workspace simplement pour faciliter un test si des fixtures/vecteurs indépendants permettent la même vérification.
 
+## Progression verticale par groupe
+
+Après les couches RAW/CORE, les Program implementations ne sont pas développées horizontalement comme une longue liste de decoders isolés. Chaque groupe prioritaire avance successivement :
+
+```text
+wire -> decode -> materialize -> specialized -> execution preparation -> policy -> execution -> scenario
+```
+
+Un composant satellite nécessaire à un protocole reste dans son groupe : Meteora vaults avec Meteora, Pump fee avec Pump, etc.
+
+Ordre prioritaire actuel : Solana Core Programs, SPL token/trading, token metadata, Anchor, Meteora, Raydium, Pump, Orca, routing, trading-adjacent puis décodage généraliste.
+
 ## Questions laissées ouvertes
 
 La première implémentation Program devra encore fixer précisément :
@@ -415,4 +442,4 @@ La première implémentation Program devra encore fixer précisément :
 - stratégie précise de warning/log pour opérations abandonnées ;
 - convention finale `dec` / `exec_prep`.
 
-La tranche suivante doit traiter `ksp-execution-policy-api` et `ksp-execution-lib` sans rouvrir les responsabilités Program définies ici.
+Les releases exactes d'introduction de `ksp-program-lib`, `ksp-execution-policy-api` et `ksp-execution-lib` suivent désormais les vertical slices définis par le roadmap ; les responsabilités Program décrites ici restent valables.