v0.1.2-pre.002-fix

docs/plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # Plan KSP 0.1.2 — Logging foundation
 
@@ -223,7 +223,7 @@ La façade ne doit pas obliger les consumers à importer `tracing::Span` ou `tra
 
 Pour le code synchrone, la surface doit permettre d'associer un scope d'exécution au span sans déplacer le callsite.
 
-Pour le code async, la surface doit instrumenter la `Future` elle-même. Un guard issu de `Span::enter()` ne doit pas être maintenu à travers un `.await`, car cela produit des traces incorrectes lorsque l'exécution change de tâche/thread ou que la future yield.
+Pour le code async, la surface doit instrumenter la `Future` elle-même. Un guard issu de `Span::enter()` ne doit pas être maintenu à travers un `.await`, car cela produit des traces incorrectes lorsque l'exécution change de tâche/thread ou que la future yield. La primitive `tracing::Instrument` entre dans le span à chaque `poll` **et lors du `Drop`** de la future instrumentée ; les tests KSP doivent donc distinguer explicitement ces deux opérations au lieu de supposer une seule paire `enter`/`exit` sur toute la durée de vie de la future.
 
 ### Mesure de durée
 
@@ -791,6 +791,7 @@ Cette arborescence reste ajustable si une séparation plus petite suffit. Aucun
 - target explicite conservé ;
 - scope synchrone correctement associé au span ;
 - future async instrumentée par la façade KSP ;
+- entrée/sortie du span vérifiée pendant chaque `poll` pertinent et lors du `Drop` de la future instrumentée ;
 - aucun enter guard conservé à travers `.await` dans l'API recommandée ;
 - `SpanEvents::NewAndClose` produit les événements lifecycle attendus ;
 - `CLOSE` contient les temps `busy`/`idle` lorsque les timestamps sont actifs ;