v0.2.13-pre.005

docs/plans/020-V0_2_13_INTERFACE_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/020-V0_2_13_INTERFACE_PLAN.md -->
-<!-- version: 4 -->
+<!-- version: 5 -->
 
 # Plan `0.2.13` — Interface / wire foundation
 
@@ -395,13 +395,13 @@ Matérialiser la primitive de compte ordonné, la borne accounts, le modèle d'e
 
 ### pre.004 — `ProgramInstruction` passif borné
 
-**Statut : réalisé ; gate opérateur à confirmer.**
+**Statut : réalisé ; gate opérateur intégralement PASS.**
 
 Ajouter l'instruction `{ program_id, accounts, data }`, constructeur validé, accessors, Debug résumé et canaris d'ordre/doublons/limites. Aucun serde/codec ou comportement Program.
 
 ### pre.005 — adversarial + consumer externe + API/dependency hardening
 
-**Statut : prévu**
+**Statut : réalisé ; gate opérateur à confirmer.**
 
 Fermer les cas limites, surface crate-root, consumer externe, firewall source/manifest et graphes Cargo. Ne pas ajouter un second domaine wire opportuniste.
 
@@ -534,4 +534,43 @@ Les deux limites utilisent le code commun `interface.program_instruction_limit_e
 
 Le `Debug` manuel n'imprime ni la collection accounts ni les octets `data`. Il expose uniquement l'identité publique du programme et les deux longueurs structurelles utiles au diagnostic.
 
-Le passage à `pre.005` doit désormais se concentrer sur les canaris adversariaux/consumer externe/API/dependency hardening, sans ajouter un second domaine wire.
+Le gate opérateur `pre.004` confirme désormais fmt, audits Rust/Markdown, `cargo check --workspace`, Clippy, tests ciblés Interface, `cargo test --workspace` et les deux graphes Cargo. Le passage à `pre.005` se concentre donc exclusivement sur les canaris adversariaux/consumer externe/API/dependency hardening, sans ajouter un second domaine wire.
+
+## 19. État préparé `pre.005`
+
+`pre.005` n'ajoute aucun code de production et ferme uniquement les preuves de consommation, complétude et résistance adversariale autour de la surface déjà matérialisée :
+
+```text
+production src modifié                              non
+nouveau domaine wire                               non
+external consumer integration crate                présent
+release completeness inventory                     présent
+façade crate-root exacte                           6 exports contrôlés
+modules de production                              4 fichiers exacts
+Vec accounts/data                                  transfert sans réallocation interne testé
+payload hostile dans erreur                        absent attendu
+account material hostile dans erreur               absent attendu
+narrowing casts                                    absents par source canary
+codec encode/decode générique                      absent par source canary
+manifest dependency                                ksp-core-lib uniquement
+source dependency firewall                         renforcé sur tous les modules production
+```
+
+Le canari `tests/external_consumer.rs` est volontairement un test d'intégration Rust séparé : Cargo le compile comme un crate consommateur externe de la bibliothèque. Il n'utilise que la façade `ksp_interface_lib::*` accessible depuis le crate-root et n'exige donc ni fixture workspace artificielle ni invocation Cargo imbriquée.
+
+`tests/release_completeness.rs` verrouille l'inventaire exact de la foundation `0.2.13` :
+
+```text
+ERROR_CODE_PROGRAM_INSTRUCTION_LIMIT_EXCEEDED
+MAX_PROGRAM_INSTRUCTION_ACCOUNTS
+ProgramAccountMeta
+MAX_PROGRAM_INSTRUCTION_DATA_LEN
+ProgramInstruction
+Pubkey
+```
+
+Il verrouille également l'absence de `pub mod` et l'inventaire exact des quatre fichiers Rust de production. Ajouter une seconde famille wire dans `0.2.13` ferait ainsi échouer explicitement le canari de complétude au lieu d'élargir silencieusement la release.
+
+Le hardening unitaire vérifie enfin que les allocations des `Vec` admis sont transférées telles quelles dans `ProgramInstruction` et que les erreurs de dépassement n'échoient ni marqueur hostile de payload ni représentation arbitraire d'account meta. Ces tests renforcent le contrat de construction sans changer l'API publique.
+
+Après validation opérateur de `pre.005`, `pre.006` doit rester un gate technique pur sans nouveau développement fonctionnel.