v0.3.3-pre.003-fix.001

docs/plans/024-V0_3_3_STORE_POSTGRES_RAW_TRANSACTION_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/024-V0_3_3_STORE_POSTGRES_RAW_TRANSACTION_PLAN.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # Plan `0.3.3` — Store/PostgreSQL RawTransaction vertical slice
 
@@ -159,15 +159,17 @@ SHA-256 = d29068b8c13b9dc0cc9ef6aaadd0fa12d41e0fe4c56541a1118c4bfc846a1450
 
 Le SQL crée uniquement `ksp_store_schema_migrations`. Le moteur stable considère toute migration appliquée `> 0` comme `SchemaNewer`; il doit donc être généralisé avant V001.
 
-Convention figée pour la nouvelle ressource :
+Convention initialement retenue en `pre.001`, puis corrigée par `pre.003-fix.001` avant toute tranche repository : V001 reste une migration logique unique (`version = 1`, `name = raw_transaction`) mais ses ressources physiques sont séparées et ordonnées sous :
 
 ```text
-crates/ksp-store-postgres-lib/migrations/V001__raw_transaction.sql
-version = 1
-name    = raw_transaction
-checksum SHA-256 calculé sur les bytes embedded exacts
+crates/ksp-store-postgres-lib/migrations/v001_raw_transaction/
+  tables/
+  constraints/
+  indexes/
 ```
 
+Le checksum logique V001 est calculé de manière déterministe sur l'identifiant relatif et les bytes exacts de chaque ressource embedded dans l'ordre du registre. Cette correction ne transforme pas chaque table/contrainte/index en version de migration autonome.
+
 ### 5.3 Config `std.store` final
 
 `config/std.store.json` est `format_version = 1`, profil par défaut `devnet` et contient exactement :
@@ -1040,17 +1042,36 @@ Statut matérialisé en `pre.002` :
 - tests de checksum/inventory/bounds ;
 - matérialiser `store.postgres_retention_compaction_unsupported`, sans modifier les contrats stables sauf preuve nouvelle d'un blocage réel.
 
-Statut matérialisé en `pre.003` :
+Statut du commit `pre.003` avant correctif :
 
 - registre réel `[V000, V001]`, version courante `1` ;
-- V000 reste byte-identique avec son checksum historique ;
-- V001 est embarquée sous `migrations/V001__raw_transaction.sql` avec checksum SHA-256 `6fe57ed0313d2ed295280dd6e49f6d86695d4e4effee2724a25e36db1ea17761` ;
-- V001 crée exactement `ksp_store_identity`, `ksp_raw_transactions`, `ksp_raw_transaction_observations`, `ksp_raw_transaction_archive_payloads` et l'index partiel `(slot, signature)` hors `purged` ;
-- `slot` reste `NUMERIC(20,0)` et toutes les bornes physiques suivent les invariants `ksp-store-api` sans narrowing ;
-- le hook V001 crée puis valide l'identité en `AppliedNow`, et valide seulement en `Existing` ; absence, forme invalide ou réseau différent deviennent un `MigrationMismatch` sûr sans rendre la valeur persistée ;
-- `store.postgres_retention_compaction_unsupported` est réservé par valeur dans le backend et la façade, sans reverse dependency ;
+- V000 byte-identique avec son checksum historique ;
+- V001 monolithique possédait le checksum `6fe57ed0313d2ed295280dd6e49f6d86695d4e4effee2724a25e36db1ea17761` ;
+- les quatre tables, contraintes et l'index partiel étaient créés, mais l'historique de migration ne prouvait pas à lui seul la compatibilité physique des objets réellement présents ;
+- le hook V001 créait/validait déjà l'identité réseau sans rebind silencieuse ;
+- aucune capability/repository `RawTransaction*` n'était encore implémentée.
+
+### `0.3.3-pre.003-fix.001` — correction du contrat physique
+
+Le correctif s'applique au commit `pre.003` et remplace la matérialisation SQL sans changer le numéro logique V001 :
+
+- V000 est déplacée sous `migrations/v000_bootstrap/tables/001_ksp_store_schema_migrations.sql` **byte-identique** ; son checksum historique reste `d29068b8c13b9dc0cc9ef6aaadd0fa12d41e0fe4c56541a1118c4bfc846a1450` ;
+- V001 est éclatée en 40 ressources embedded : 4 tables, 35 contraintes, 1 index ;
+- le checksum logique V001 devient `31488cda2f08f3f46c4cdbdbb6c18c243662fada02eac4487040c8735d72cc51`, calculé sur les identifiants relatifs et bytes ordonnés des ressources ;
+- chaque ressource sait comment être créée de façon additive, mais `IF NOT EXISTS` n'est jamais considéré comme preuve de compatibilité ;
+- le backend introspecte les catalogues PostgreSQL et classe chaque ressource `Compatible`, `Missing` ou `Incompatible` ;
+- tables, colonnes obligatoires, nullabilité/types, précision `NUMERIC(20,0)`, PK/FK/CHECK, index partiel, RLS, triggers, rules et contraintes externes susceptibles de modifier les writes sont vérifiés ;
+- les CHECK sont comparés à la définition canonique dérivée de leur propre ressource SQL, et non à une liste permissive de fragments ;
+- une colonne externe est acceptée uniquement lorsque sa présence est prouvée non bloquante pour les writes KSP ; les indexes externes non uniques sont tolérés ; les extensions ambiguës ou write-constraining bloquent `Ready` ;
+- `schema_autocreate` contrôle l'initialisation/adoption d'une base sans metadata KSP ; `schema_autoupdate` contrôle les migrations pending et les réparations additives sûres d'un schéma KSP existant ;
+- aucune réparation destructive ou ambiguë n'est exécutée automatiquement : le backend bloque avec une erreur/log sûrs pour intervention manuelle ;
+- une identité V001 absente sur une migration déjà appliquée n'est jamais recréée automatiquement ;
+- Config `std.store` passe au format V2 pour séparer les deux politiques, tout en conservant la lecture V1 où `auto_migrate` mappe les deux valeurs ;
+- les fichiers monolithiques `migrations/V000__bootstrap.sql` et `migrations/V001__raw_transaction.sql` sont supprimés explicitement par le delta ;
 - aucune capability/repository `RawTransaction*` n'est encore implémentée.
 
+Une base PostgreSQL sur laquelle le commit `pre.003` aurait déjà enregistré l'ancien checksum V001 n'est **pas** réécrite silencieusement : elle doit être réinitialisée si elle est jetable, ou réconciliée manuellement. Le correctif préserve ainsi la règle d'immutabilité de l'historique au lieu de masquer une divergence de prerelease.
+
 ### `0.3.3-pre.004` — mapping et lectures
 
 - codecs SQL privés ;