From d8a17283711fdd008cbb6dd69b7516645e931853 Mon Sep 17 00:00:00 2001
From: r-zakarya <82443831+r-zakarya@users.noreply.github.com>
Date: Sat, 1 Aug 2026 16:45:48 +0100
Subject: [PATCH] docs(tests): mark A13b validated

---
 TEST_SCENARIOS.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/TEST_SCENARIOS.md b/TEST_SCENARIOS.md
index cf78076..8c54695 100644
--- a/TEST_SCENARIOS.md
+++ b/TEST_SCENARIOS.md
@@ -91,7 +91,7 @@ Aucun de ces enchaînements ne doit afficher « Entry changed elsewhere » :
 - **Bug trouvé par ce test** : le serveur répondait **200 « Updated »** pour un `UPDATE` n'ayant touché **aucune** ligne — le client affichait « Saved » alors que rien n'était écrit. Perte de données silencieuse. `HandleUpdateEntry` teste maintenant `RowsAffected` et renvoie 404.
 - **Même classe, non corrigé** : delete / restore / favorite / pin / set-icon répondent aussi OK sur un id inexistant. Assumé — aucun ne prétend avoir enregistré un travail de l'utilisateur, et le client recharge la liste juste après.
 
-### A13b · récupérer la saisie quand l'entrée a disparu
+### A13b · récupérer la saisie quand l'entrée a disparu ✅
 - **ACTION** : même mise en place qu'A13 → au Save, répondre **« Save as new entry »**.
 - **ATTENDU** : une nouvelle entrée est créée avec le contenu de l'éditeur, le panneau se rouvre dessus et la carte clignote. *Cancel* → rien n'est écrit, l'éditeur reste ouvert avec la saisie.
 - **Nouvel uuid, pas une résurrection** : le POST en génère un neuf, donc l'entrée recréée n'entre pas en conflit avec le tombstone laissé par la suppression — aucun risque de la voir re-supprimée au sync suivant, ni de ressusciter en boucle ce qu'un autre appareil a effacé volontairement.