v0.1.1-pre.003

docs/plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md -->
-<!-- version: 5 -->
+<!-- version: 6 -->
 
 # Plan KSP 0.1.1 — Core foundation
 
@@ -127,11 +127,18 @@ ksp_core_lib::Result
 ksp_core_lib::Pubkey
 ksp_core_lib::ProgramIdEntry
 ksp_core_lib::ProgramIdFilter
+ksp_core_lib::ProgramIdKind
 ksp_core_lib::entries
 ksp_core_lib::program_ids
+ksp_core_lib::program_ids_by_domain
+ksp_core_lib::program_ids_by_family
+ksp_core_lib::program_ids_by_protocol
 ksp_core_lib::native_program_ids
 ksp_core_lib::find_program_id
+ksp_core_lib::find_program_pubkey
 ksp_core_lib::declare_program_id!
+ksp_core_lib::PRGID_*
+ksp_core_lib::PRGIDPK_*
 ```
 
 Les modules d'implémentation restent privés conformément aux règles Rust du dépôt.
@@ -213,13 +220,13 @@ Ne pas ajouter :
 - crates RPC/client ;
 - Borsh/Wincode/Serde pour une hypothétique future surface wire.
 
-La génération actuelle de `solana-pubkey` requiert Rust 1.89.0. Avant son ajout en `pre.003`, la toolchain réelle du dépôt devra donc être vérifiée. Une toolchain plus ancienne ne doit pas conduire silencieusement à choisir une vieille génération Solana uniquement pour contourner cette exigence.
+La génération retenue de `solana-pubkey` requiert Rust 1.89.0. La validation `pre.002-fix.001` a été exécutée avec une génération Clippy Rust 1.94.0, donc la toolchain observée satisfait ce MSRV. Une future révision ne devra pas revenir silencieusement à une vieille génération Solana uniquement pour contourner une exigence de toolchain.
 
 ## Program IDs retenus pour la première surface Core
 
-Le nombre exact de Program IDs de la première surface Core n'est plus figé à `17`.
+`pre.003` fixe la première surface Core à **18 Program IDs**.
 
-`pre.001` retient les familles fondamentales suivantes comme inventaire de départ à vérifier une dernière fois contre les sources officielles au moment de `pre.003` :
+Les 17 identifiants fondamentaux exposés par la surface officielle actuelle `solana-sdk-ids` sont recopiés comme valeurs KSP sans créer de dépendance Cargo vers cette crate :
 
 - System ;
 - Stake ;
@@ -228,13 +235,16 @@ Le nombre exact de Program IDs de la première surface Core n'est plus figé à
 - Feature ;
 - Compute Budget ;
 - Address Lookup Table ;
-- loaders BPF historiques/actuels et Loader v4 ;
+- BPF Loader historique v1 ;
+- BPF Loader v2 ;
+- BPF Loader Upgradeable ;
+- Loader v4 ;
 - Native Loader ;
 - précompiles Ed25519, Secp256k1 et Secp256r1 ;
-- programmes ZK fondamentaux actuellement exposés par la surface Anza/Solana ;
-- tout programme natif/historique supplémentaire réellement encore pertinent pour la frontière Core.
+- ZK ElGamal Proof ;
+- ZK Token Proof.
 
-L'ancien `ks-program-ids` de bot3 est utilisé comme inventaire historique complémentaire, pas comme source de vérité. Il rappelle notamment une entrée `slashing` dans son ensemble `native_program_ids()`. Sa présence dans la première surface KSP doit être décidée à partir de son statut officiel réel au moment de `pre.003`, plutôt que déduite d'un nombre figé ou d'une ancienne liste.
+Le dix-huitième identifiant est le Slashing Program `S1ashing11111111111111111111111111111111111`. Il n'est pas encore publié dans `solana-sdk-ids`, mais son statut de programme enshrined et son adresse sont confirmés par SIMD-0204 et la documentation Anza. L'ancien `ks-program-ids` de bot3 avait déjà cette entrée ; `pre.003` ne la conserve toutefois qu'après cette revérification officielle indépendante.
 
 ### Exclusions volontaires de `0.1.1`
 
@@ -374,7 +384,7 @@ L'audit de l'ancien registre bot3 et des IDLs archivées montre qu'un seul axe h
 - `kind` : classification technique nécessaire aux vues Core telles que les programmes natifs/loaders/précompiles ;
 - le code KSP unique, la chaîne Base58 `PRGID_*` et le `Pubkey` `PRGIDPK_*` restent les identités de l'entrée.
 
-Les vocabulaires exacts de `domain`, `family`, `protocol`, `subfamily` et `kind` doivent rester extensibles. Core ne doit pas créer une enum fermée contenant tous les futurs protocoles Solana. Des identifiants statiques/constantes KSP ou des newtypes légers peuvent être utilisés ; le choix syntaxique exact est finalisé en `pre.003`.
+Les vocabulaires de `domain`, `family`, `protocol`, `subfamily` et `program_version` restent des chaînes extensibles : Core ne crée aucune enum fermée des futurs protocoles Solana. `kind` est volontairement une petite enum technique `ProgramIdKind` (`Program`, `Loader`, `Precompile`, `EnshrinedProgram`) parce qu'elle décrit la nature de l'entrée plutôt qu'un catalogue de protocoles.
 
 `family = amm` est retenu comme famille agrégatrice future pour les modèles AMM. Les variantes `cpmm`, `clmm`, `dlmm`, `damm`, `stable_swap`, `weighted_swap`, `gamma`, `ssl` ou équivalentes appartiennent au niveau `subfamily` lorsqu'elles représentent réellement une branche architecturale du protocole. Cela permettra à une future vue `amm_program_ids()` de retrouver l'ensemble de ces programmes au lieu de limiter la recherche à l'ancien préfixe bot3 `AMM_*`.
 
@@ -454,7 +464,7 @@ amm_program_ids()
 
 Cette fonction devra être une vue de la classification canonique (`family = amm`) et non un second registre manuel. `0.1.1` ne crée pas un helper AMM vide puisque les Program IDs AMM restent hors scope de la release, mais son ajout futur ne doit nécessiter aucune refonte de `ProgramIdEntry`.
 
-Les vues filtrées peuvent retourner un iterator/view au lieu d'un `&'static [ProgramIdEntry]` si cela évite de dupliquer des tableaux statiques. Le contrat exact de retour est décidé en `pre.003` en privilégiant une API stable et sans allocation inutile.
+Les vues filtrées retournent des iterators paresseux sur le registre canonique et n'allouent pas de collection intermédiaire. `entries()` reste la vue exhaustive sous forme de slice statique. `native_program_ids()` et les helpers `program_ids_by_domain(...)`, `program_ids_by_family(...)` et `program_ids_by_protocol(...)` sont des vues de cette même source.
 
 `registered_program_ids()` de bot3 reste considéré comme un alias redondant de `entries()` et n'est pas repris automatiquement. Les well-known accounts suivent un registre/naming distinct lorsqu'ils deviennent nécessaires.
 
@@ -597,17 +607,17 @@ Aucune dépendance Solana n'est nécessaire à cette tranche.
 Objectifs :
 
 - revérifier les versions Solana/Anza au jour de l'implémentation ;
-- vérifier `rustc` par rapport au MSRV de la génération retenue ;
+- vérifier la toolchain observée par rapport au MSRV de la génération retenue ;
 - ajouter `solana-pubkey` uniquement au propriétaire `ksp-core-lib` ;
 - réexporter `Pubkey` ;
 - implémenter `declare_program_id!` et la paire `PRGID_*` / `PRGIDPK_*` ;
-- finaliser l'inventaire des Program IDs fondamentaux à partir des sources officielles actuelles ;
-- implémenter `ProgramIdEntry`, `ProgramIdFilter`, `entries()`, `program_ids(...)`, `native_program_ids()` et `find_program_id()` ;
+- finaliser à 18 l'inventaire des Program IDs fondamentaux à partir des sources officielles actuelles ;
+- implémenter `ProgramIdEntry`, `ProgramIdFilter`, `ProgramIdKind`, `entries()`, `program_ids(...)`, les vues domain/family/protocol, `native_program_ids()`, `find_program_id()` et `find_program_pubkey()` ;
 - implémenter la taxonomie extensible `domain` / `family` / `protocol` / `subfamily` / `program_version` / `kind` sans enum centrale fermée des protocoles ;
 - garantir que les futurs helpers spécialisés comme `amm_program_ids()` puissent être des vues du registre canonique sans duplication ;
-- ajouter les tests de conformité, d'unicité et de filtrage ;
+- ajouter les tests de conformité, d'unicité, de filtrage et de façade publique ;
 - confirmer l'absence totale de dépendance `solana-sdk-ids` ;
-- auditer le graphe/features réels.
+- auditer le graphe/features réels après validation Cargo par le user.
 
 ### `0.1.1-pre.004` — intégration Core + audits
 
@@ -657,7 +667,6 @@ Un `pre.NNN-fix.NNN` corrige la tranche correspondante sans réécrire son histo
 
 ## Questions ouvertes non bloquantes
 
-- Revérifier en `pre.003` la version publiée de `solana-pubkey`, son API compile-time pertinente et le MSRV officiel au jour du code.
 - Décider en `pre.005`, à partir de l'API réellement stabilisée, si un `README.md`/`USAGE.md` de crate apporte suffisamment de valeur pour être créé maintenant.
 
 Aucune de ces questions ne justifie d'élargir le périmètre fonctionnel de `0.1.1`.