v0.0.3-pre.005

docs/IDEAS.md

@@ -1,5 +1,5 @@
 <!-- file: docs/IDEAS.md -->
-<!-- version: 8 -->
+<!-- version: 9 -->
 
 # Idées à explorer
 
@@ -40,7 +40,7 @@ L'UI sélectionne/injecte une implémentation réutilisable ; elle ne doit pas d
 
 `ksp-execution-lib` est retenu comme orchestration spécialisée entre programme, policy, wallet et transport. Il dépend de `ksp-program-api`, pas de l'implémentation `ksp-program-lib`.
 
-Les types exacts d'opération préparée et de policy restent à définir en `0.0.3-pre.004`.
+La frontière d'orchestration et les checkpoints de policy sont définis dans `007-EXECUTION_AND_POLICY.md`; les types Rust exacts restent à définir avec l'implémentation.
 
 ### Scenarios : norme avant API
 
@@ -192,3 +192,20 @@ Définir la politique lorsqu'un registry reçoit plusieurs implémentations capa
 **Status :** À explorer avec les premiers modules
 
 Le principe `domain/program/capability` est retenu. Les noms exacts des dossiers courts (`dec`, `exec_prep`) seront validés avec la première vraie arborescence.
+
+
+## Execution — idées d'implémentation
+
+### Composition de policies
+
+**Status :** À explorer
+
+Évaluer, lorsque plusieurs policies réelles existent, s'il est utile de composer des policies spécialisées (réseau, montants, risque, lifecycle/deprecated, approval utilisateur, etc.) derrière un contrat commun.
+
+Ne pas imposer cette composition dans `ksp-execution-policy-api` avant qu'un cas concret ne démontre les règles de priorité, union des requirements et traitement des conflits.
+
+### Reprise après approbation externe
+
+**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.