v0.1.1-pre.005

docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Séquence des releases fonctionnelles KSP
 
@@ -48,27 +48,24 @@ Stabiliser `ksp-core-lib` comme fondation N1 minimale et durable.
 
 Le Core possède uniquement les contrats réellement transversaux nécessaires aux couches supérieures.
 
-### Périmètre initial
+### Surface stabilisée
 
-À auditer précisément dans `0.1.1-pre.001`, avec comme candidats acquis :
+`0.1.1` stabilise :
 
-- type public commun `ksp_core_lib::Error` ;
-- alias public commun `Result<T>` ou forme équivalente validée ;
-- architecture d'erreur permettant aux domaines supérieurs d'ajouter du contexte sans faire connaître tous les futurs domaines à Core ;
-- Program IDs fondamentaux appartenant à KSP Core ;
-- primitives/identités réellement communes et déjà justifiées ;
-- conventions de version/provenance N1 uniquement si un besoin concret existe ;
-- exports crate-root et documentation publique ;
-- tests unitaires/integration appropriés ;
-- respect complet des règles Rust/workspace.
+- `ksp_core_lib::ErrorCode`, `ErrorContext`, `Error` et `Result<T>` comme contrat d'erreur ouvert aux domaines supérieurs ;
+- `ksp_core_lib::Pubkey` comme primitive Solana réexportée par Core ;
+- 18 Program IDs fondamentaux possédés par KSP avec paires `PRGID_*` / `PRGIDPK_*` ;
+- `declare_program_id!` pour construire la représentation texte et `Pubkey` depuis une déclaration canonique unique ;
+- `ProgramIdEntry`, `ProgramIdFilter`, `ProgramIdKind` et le registre enumerable/recherchable ;
+- des vues par domaine/famille/protocole et `native_program_ids()` sans registres secondaires ;
+- une taxonomie extensible séparant notamment `subfamily` et `program_version` ;
+- les réexports crate-root, rustdocs et tests publics correspondants.
 
 ### Dépendances
 
 Core ne dépend pas de `ksp-logging-lib`, Config, Wallet, Store, Transport, Program ou Materializer.
 
-Une primitive Solana/Anza officiellement stable peut être ajoutée seulement lorsqu'un item Core concret en a besoin.
-
-`solana-pubkey` est un candidat naturel pour les Program IDs ; les autres primitives autorisées ne sont pas ajoutées par anticipation.
+La seule dépendance externe directe de `ksp-core-lib` à la clôture est `solana-pubkey`, déclarée au workspace avec la génération `^4.3`, `default-features = false`, puis héritée par la crate avec `.workspace = true`. Aucune feature optionnelle supplémentaire n'est activée dans `0.1.1`.
 
 ### Hors scope
 
@@ -87,20 +84,20 @@ Une primitive Solana/Anza officiellement stable peut être ajoutée seulement lo
 
 ### Lifecycle de la release
 
-Le nombre de prereleases n'est pas figé avant `pre.001`.
-
-Trajectoire candidate :
+Trajectoire réellement suivie :
 
 ```text
-pre.001  brainstorming + audit + plan détaillé
-pre.002  Error/Result + fondation API
-pre.003  primitives/Program IDs réellement retenus
-pre.004  compléments/tests/audits
-pre.005  validation finale/docs/cleanup/prompt 0.1.2
+pre.001              brainstorming + audit + plan détaillé
+pre.001-fix.001/.002 corrections de cadrage Program IDs/taxonomie
+pre.002              Error/Result + fondation API
+pre.002-fix.001      corrections de tests/lints
+pre.003              Pubkey + Program IDs
+pre.003-fix.001      politique Cargo workspace + corrections Clippy
+pre.004              intégration Core + audits
+pre.005              validation finale/docs/cleanup/prompt 0.1.2
+rel.001               publication stable après validation de pre.005
 ```
 
-Cette séquence est indicative. `pre.001` peut la modifier.
-
 ## `0.1.2` — Logging foundation
 
 ### Dépendances
@@ -325,7 +322,7 @@ Les directions restent celles du roadmap :
 
 Ces séries sont des objectifs fonctionnels, pas un calendrier contractuel.
 
-# Sélection de la première release
+# Progression de la série `0.1.x`
 
 La première release fonctionnelle est :
 
@@ -333,10 +330,15 @@ La première release fonctionnelle est :
 0.1.1 — Core foundation
 ```
 
-Le prompt de démarrage associé est :
+Son prompt historique d'ouverture reste :
 
 ```text
 prompts/001-V0_1_1_START_PROMPT.md
 ```
 
-`0.0.3` est désormais la base fondatrice stable. La prochaine phase ouvre `0.1.1-pre.001` à partir du prompt final `prompts/001-V0_1_1_START_PROMPT.md`.
+À la clôture de `0.1.1-pre.005`, la surface Core est prête pour validation puis publication stable via `0.1.1-rel.001`. Après le tag `v0.1.1`, la release suivante s'ouvre avec :
+
+```text
+0.1.2 — Logging foundation
+prompts/002-V0_1_2_START_PROMPT.md
+```