11 lines
1.6 KiB
Markdown
11 lines
1.6 KiB
Markdown
---
|
|
issueRef: "#37"
|
|
version: 6
|
|
updatedBy: {"kind":"agent","agent_id":"57695b92-24d0-4876-837c-76116e70a6ae"}
|
|
updatedAt: 1784363570119
|
|
---
|
|
Découpage proposé :
|
|
1. [DevBackend] Use cases de suppression avec cascade : deleteExercise (retire l'exercice de tous les programmes qui le référencent, soft delete via metadata.deletedAt déjà existant sur EntityMetadata — pas de nouveau champ nécessaire), deleteProgram (retire le programme de toutes les séances-modèles qui le référencent), deleteWorkoutTemplate (soft delete simple, pas de cascade car rien ne référence une séance-modèle sauf l'historique qui garde son propre snapshot autonome déjà indépendant). S'assurer que listActive()/repositories filtrent bien deletedAt != null partout où c'est déjà censé être le cas.
|
|
2. [DevFrontend] Boutons de suppression + confirmations sur les 3 écrans (bibliothèque d'exercices, liste de programmes, liste de séances-modèles), avec les messages de confirmation adaptés (cf. description utilisateur du ticket : cascade expliquée si pertinent). Vérifier que la relance d'une séance dont la séance-modèle source a été supprimée affiche bien le message déjà prévu par la conception initiale ("La séance originale n'existe plus. Une copie va être utilisée.") — c'est déjà censé être géré par le pattern historique existant (ticket #10/#28), à vérifier/compléter si besoin plutôt qu'à recréer.
|
|
|
|
Important : l'historique doit rester lisible même après suppression (déjà garanti par le pattern snapshot autonome existant sur WorkoutHistory) — ne pas casser ça. |