v0.0.3-pre.006

docs/IDEAS.md

@@ -1,5 +1,5 @@
 <!-- file: docs/IDEAS.md -->
-<!-- version: 9 -->
+<!-- version: 10 -->
 
 # Idées à explorer
 
@@ -209,3 +209,39 @@ Ne pas imposer cette composition dans `ksp-execution-policy-api` avant qu'un cas
 **Status :** À explorer avec la première UI concernée
 
 Définir un mécanisme sûr de suspension/reprise d'une exécution lorsque la policy demande une approbation externe, sans faire dépendre la couche execution d'une UI ou de Tauri.
+
+## Data / Store — questions d'implémentation
+
+### Schémas SQL D1/D2/D3/D4
+
+**Status :** À explorer avec la première release Store
+
+La structure durable D1–D4 est retenue, mais les noms de tables, colonnes, contraintes, index et repositories doivent être conçus avec les premiers workloads réels.
+
+### Format générique D3
+
+**Status :** À explorer
+
+Le journal D3 doit accepter les outputs de materializers officiels ou externes sans nécessiter une nouvelle table par materializer.
+
+À définir : identité/type/domain, payload, hash, provenance, version processor, état current/superseded/failed/replay et stratégie de sérialisation.
+
+### Backlog et checkpoints
+
+**Status :** À explorer en `pre.007`
+
+Les notifications restent des wake-ups. Définir comment chaque worker/job interroge le Store pour retrouver les inputs non traités par une version donnée, avec pagination, batching, reprise et concurrence.
+
+### Jobs de replay
+
+**Status :** À explorer en `pre.007`
+
+Prévoir des jobs séparés pour D1 -> D2, D2 -> D3 et D3 -> D4 plutôt qu'un replay monolithique obligatoire.
+
+Les noms définitifs ne sont pas encore retenus.
+
+### Notification backend de référence
+
+**Status :** À explorer en `pre.007`
+
+PostgreSQL LISTEN/NOTIFY est un candidat naturel pour la première implémentation de signal de réveil, mais le contrat doit rester indépendant du mécanisme et le Store reste la source de vérité.