v0.1.0-pre.064-065

olddocs/archivekbot2/docs/V0_4_6_VALIDATION.md

@@ -0,0 +1,66 @@
+<!-- file: docs/V0_4_6_VALIDATION.md -->
+<!-- version: 1 -->
+
+# Validation finale `0.4.6`
+
+## Périmètre
+
+Le jalon couvre Token-2022 et le registre ElGamal comme programmes distincts, ainsi que la régression des décodeurs Solana Core/SPL livrés auparavant. Il ne transforme pas Anchor, Metaplex ou les futurs DEX en surfaces implicitement couvertes.
+
+## Résultats de tests
+
+| Suite                              | Résultat |
+|------------------------------------|---------:|
+| `kb_store_core`                    |    41/41 |
+| `kb_store_pg` avec PostgreSQL réel |    46/46 |
+| `kb_pipeline`                      |  124/124 |
+| `kb_app_demo`                      |  118/118 |
+| `cargo clippy --all-targets`       |   propre |
+
+Les contrôles SQL sur `kb_sol_decode_events` et `kb_sol_mat_events` ne révèlent aucun doublon d’identité.
+
+## Token-2022 et ElGamal Registry
+
+- 55 instructions Token-2022 Mainnet ont été décodées sans échec persistant.
+- Huit opérations publiques Token-2022 ont été confirmées sur Devnet : `MintToChecked`, `TransferChecked`, `ApproveChecked`, `Revoke`, `BurnChecked`, `FreezeAccount`, `ThawAccount` et `CloseAccount`.
+- Chaque parcours Devnet a été simulé, confirmé, hydraté, extrait, décodé, matérialisé puis rejoué idempotemment.
+- ElGamal Registry est validé synthétiquement/offline pour le wire, le PDA, l’état, les lectures RPC, les préflights et les preuves.
+- La validation publique ElGamal Registry reste indisponible sur Devnet/Mainnet au 20 juillet 2026 ; aucune preuve réseau n’est revendiquée.
+
+## Loader immuable et Loader v4
+
+Le parser `Write` du loader immuable lit désormais la longueur vectorielle en `u32` et les données à l’offset 12. Le replay Mainnet a supprimé 68 diagnostics `loader_vector_length_mismatch`.
+
+Les rejets persistants restants sont tous issus de transactions Solana échouées :
+
+| Diagnostic                       | Nombre |
+|----------------------------------|-------:|
+| `immutable_loader_tag_truncated` |     31 |
+| `loader_v4_tag_truncated`        |     44 |
+| `loader_accounts_invalid`        |      1 |
+
+Quatre variantes Loader v4 inconnues sont persistées comme traitement réussi avec résultat métier `Unsupported`. Elles ne sont pas assimilées à des décodages complets.
+
+## Replay des signatures incomplètes
+
+Le mode `incomplete_signatures` sélectionne les signatures contenant au moins une instruction `pending`, `failed`, `replay_requested` ou `unsupported`. La limite est appliquée au nombre de signatures avant expansion vers les instructions compatibles. Ce mode ne nécessite pas de force replay global.
+
+Deux campagnes PostgreSQL réelles successives ont produit exactement :
+
+```text
+selected=81
+started=81
+completed=81
+unmatched=0
+notStarted=0
+failedInputs=76
+decoded=1
+unsupported=4
+failed=76
+```
+
+L’instruction décodée appartient à une signature incomplète contenant également une instruction valide. La répétition identique du second passage confirme la sélection stable ; les événements et matérialisations restent idempotents.
+
+## Conclusion
+
+Tous les décodeurs livrés jusqu’à `0.4.6` respectent leur contrat sur les tests synthétiques, les scénarios stateful et les données réseau observées. Les payloads malformés sont rejetés fail-closed et les variantes inconnues sont classées explicitement `Unsupported`. Cette conclusion ne prétend pas que chaque variante rare possible a été observée sur un cluster public.