v0.5.3-pre.004

docs/plans/V0_5_3_KS_STORE_NORMALIZATION_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/V0_5_3_KS_STORE_NORMALIZATION_PLAN.md -->
-<!-- version: 8 -->
+<!-- version: 9 -->
 
 # Plan `0.5.3` — audit et normalisation de `ks-store`
 
@@ -1609,3 +1609,73 @@ Les autres metadata transactionnelles auditées (`fee`, rewards, compute units,
 - les projections N4 metadata/trading.
 
 Ces points restent dans les tranches suivantes et peuvent décaler le premier candidat de clôture au-delà de `pre.007`.
+
+## 34. État réalisé de `0.5.3-pre.004`
+
+`pre.004` ferme la tranche repositories/replay sans ajouter de table et sans déclarer encore le gel formel N1/N2/N3.
+
+### 34.1 Replay top-level + CPI
+
+Les instructions top-level et CPI restent dans leurs deux tables physiques. Les repositories construisent désormais une lecture logique commune avec `CoreInstructionScope::{TopLevel, Inner}`. Le replay contextuel N2 -> N3 fonctionne sur les deux scopes ; le lifecycle est mis à jour dans la table physique correspondant au chemin d’instruction.
+
+L’ordre de page durable est :
+
+```text
+(slot, signature, scope_rank, instruction_path)
+```
+
+`PageRequest` abandonne `offset` et utilise un curseur borné. Les lectures interactives sont plafonnées à 500 lignes.
+
+### 34.2 Batches de processing
+
+Les campagnes Core extraction, decode et account-state utilisent des limites propres, plafonnées à 1 000 entrées par batch. Elles ne réutilisent pas la limite interactive de 500 et aucune surface publique ne conserve l’ancien plafond 100 000.
+
+### 34.3 Invalidation descendante
+
+Le remplacement d’un graphe Core invalide, dans la même transaction, les descendants decode/coverage/materialization et les ledgers de la signature avant reconstruction N2.
+
+Le remplacement d’un résultat decode invalide les matérialisations appartenant à l’identité exacte `(decoder_name, decoder_version, decode_input_key)`. Les clés de ledger sont comparées par préfixe littéral avec `LEFT(...)=prefix`, jamais avec `LIKE`.
+
+Après persistence, le lifecycle instructionnel est recalculé depuis les descendants courants. Une sortie produite par une ancienne version du decoder ne peut donc pas faire apparaître la nouvelle version comme matérialisée.
+
+### 34.4 Account observation -> account state
+
+Le couple réservé en `pre.003` devient opérationnel :
+
+```text
+k_sol_obs_account_observations
+        -> account_state_normalization ledger
+        -> k_sol_core_account_states
+```
+
+La sélection transporte le nom/version du normalizer ; une nouvelle version peut rejouer les observations même si un Core state d’une version précédente existe. Le hash d’input assure l’idempotence de la version courante. Les valeurs `lamports`/`rent_epoch` conservent le domaine `u64` complet via `NUMERIC(20,0)`.
+
+### 34.5 Index et ressources SQL
+
+Aucune table ni contrainte logique n’est ajoutée. Quatre index non uniques sont ajoutés pour les nouveaux chemins :
+
+- ordre de replay des CPI par slot/signature/path ;
+- lookup coverage par signature/path ;
+- descendants materialized outputs par decode input ;
+- descendants materialized outputs par signature/input.
+
+Le corpus passe de 236 à **240 ressources SQL**, avec **63 index explicites / 79 index attendus** en comptant les 16 clés primaires. Les index restent ajustables avant gel sur la base des plans `EXPLAIN`.
+
+### 34.6 Instrumentation PostgreSQL
+
+Les opérations de repository réécrites émettent des événements `TRACE` sous le target canonique `ks-store` avec :
+
+```text
+backend="postgres"
+domain="ks-store.pg"
+action
+elapsed_ms
+rows
+outcome
+```
+
+Le statement logging automatique SQLx reste désactivé. Les traces normales ne publient ni SQL brut, ni valeurs bindées, ni secret de connexion.
+
+### 34.7 Reste avant gel
+
+La validation PostgreSQL réelle des nouveaux chemins, les plans `EXPLAIN`, la présentation desktop finale et le snapshot machine-readable restent dans les tranches suivantes. `pre.004` stabilise les repositories candidats ; il ne déclare pas encore N1/N2/N3 frozen.