---
description: Workflow de clôture à exécuter à la fin de chaque évolution ou correction
alwaysApply: true
model: inherit
---

# Clôture évolution / correction

À la fin de toute évolution ou correction, exécuter ce workflow dans l'ordre. Boucler chaque bloc jusqu'à stabilisation (rien à optimiser). **Ne jamais produire une réponse partielle** : répondre à toutes les questions de clôture et lancer les subagents/plans concernés.

## Clôture obligatoire après évolution/correction

Après chaque évolution ou correction, la réponse doit inclure **obligatoirement** :

1. **Helpers :** des helpers sont-ils à utiliser ailleurs dans le code ? Des helpers existants auraient-ils pu être utilisés ? Y a-t-il des doublons de helpers ?
   - Si oui : factoriser, réutiliser les helpers existants et supprimer/absorber les doublons immédiatement.

2. **Texte i18n :** les textes sont ils centralisés ? `.secrets/<env>/env-full-<env>-for-bdd-injection.txt` est il à jour ? et test, pprod, prod ?
   -  Si non : fait le

3. **Fallback :** As tu ajouté des fallbacks ?
   -  Si oui : supprime les fallback, si il y en avait avant et que tu peux les enlever sans regression, fait le.

4. **Modifications similaires :** y a-t-il des modifications similaires à produire ailleurs dans le code ?
   - Si oui : les implémenter immédiatement.

5. **Optimisation / mutualisation / centralisation :** y a-t-il des optimisations possibles ?
   - Si oui : les implémenter immédiatement.

6. **Sécurité :** Des failles des sécurité sont elles posibles ?
   - Si oui : corrige les

7. **Code mort :** le code mort est-il nettoyé ?
   - Si non : le nettoyer immédiatement.

8. **Lint :** les fichiers corrigés sont-ils exempts d’erreurs de lint ?
   - Réponse attendue : constat uniquement, **ne pas corriger** ici.

9.  **Types :** les vérifications de types du projet sont-elles OK ?
    - Si non : corriger, même si l’erreur ne vient pas des modifications en cours.

10. **Compilation :** le projet compile-t-il ?
    - Si non : corriger, même si l’erreur ne vient pas des modifications en cours.

11. **Documentation :** Rationaliser la documentation

Si la réponse déclenche de nouvelles actions, cette checklist doit être rejouée en boucle jusqu’à stabilisation (code propre), avec lancement des subagents nécessaires pour exécuter les tâches.

## Orchestration des subagents et plans

Après une correction ou évolution, lancer en boucle jusqu'à succès :

- **Lint** : Si erreurs détectées → `mcp_task` generalPurpose avec prompt fix-lint (ou exécution manuelle) ; boucler jusqu'à 0 erreur.
- **Déploiement** : Si déploiement requis et validé → `mcp_task` subagent_type="deploy" avec env ; en cas d'échec, orchestrer la correction (investigation, correctif, relance) sans s'arrêter.
- **Tests** : Compléter et lancer les tests concernés.

Ne pas s'arrêter au rapport d'échec d'un subagent : prendre le relais, corriger, relancer.

## 1. Tests

- Compléter les tests manquants (user stories)
- Lancer les tests, corriger les échecs, boucler
- Rationaliser les tests (supprimer doublons, mutualiser)

## 2. Types

- Chercher si les types sont à optimiser (`npm run typecheck`, `npx tsc --noEmit`)
- Si oui, implémenter et boucler jusqu'à rien à optimiser

## 3. Reproductions

- Chercher si des changements similaires doivent être reproduits ailleurs
- Si oui, implémenter et boucler jusqu'à rien à reproduire

## 4. Factorisation / optimisation

- Chercher factorisation, mutualisation, centralisation possibles
- Si oui, implémenter et boucler jusqu'à rien à optimiser

## 5. Lint

- Chercher erreurs de lint (`npm run lint`, `ReadLints`)
- Si oui, corriger et boucler jusqu'à rien à corriger
- Sinon, vérifier si on peut être plus exigeant sur la qualité

## 6. Sécurité

- Chercher améliorations de sécurité possibles (`docs/CODE_SECURITY.md`)
- Si oui, implémenter et boucler jusqu'à rien à améliorer

## 7. Documentation

- Mettre à jour la doc : REX + descriptions (OPERATIONS.md, FRONTEND.md, CODE_STANDARDS.md selon périmètre)
- Rationaliser la doc (supprimer doublons, fusionner)

## 8. Déploiement (après validation utilisateur)

- Le script deploy.sh exécute un hook pre-deploy qui arrête (SIGTERM) les processus concurrents dont le cwd est dans le projet, puis suggère de relancer /fix-lint après le déploiement.
- Demander validation avant déploiement
- Déployer sur l'environnement de la branche locale (`deploy/scripts/build-and-deploy.sh`)
- Analyser les logs du déploiement
- Si corrections nécessaires, implémenter et boucler
- Si optimisations déploiement possibles, implémenter et boucler
- Si améliorations sécurité déploiement possibles, implémenter et boucler
- Mettre à jour la doc déploiement : REX + descriptions puis rationaliser

## Plan et commande

- **Plan** : `~/.cursor/plans/workflow-cloture-evolution.plan.md` (niveau utilisateur)
- **Commande** : `/cloture-evolution` (déclenche l'exécution du plan)

## Outils

- Lint : `mcp_task` generalPurpose avec prompt détaillé (fix-lint via mcp_task non fonctionnel)
- Déploiement : `mcp_task` subagent_type="deploy" ou exécution manuelle du script
- Tests : MCP browser, `user_stories/`