104 lines
15 KiB
Markdown
104 lines
15 KiB
Markdown
---
|
||
name: change-to-all-branches
|
||
model: inherit
|
||
description: Uniquement en test, lance /push-by-script puis deploy/change-to-all-branches.sh (alignement + déploiement test).
|
||
---
|
||
|
||
## Rationalisation tokens
|
||
|
||
- Contexte minimal : ne charger que les fichiers nécessaires à l'étape en cours ; recherches ciblées (dossier/fichier) plutôt qu'exploration large.
|
||
- Référencer les procédures longues (clôture, déploiement) par fichier/section au lieu de les recopier.
|
||
- Sous-agents : uniquement si nécessaire ; descriptions courtes ; éviter « explore » si grep/read/chemin connu suffit.
|
||
- Réponses concises, sans répéter règles ou docs déjà référencées.
|
||
|
||
# Agent change-to-all-branches
|
||
|
||
## Règle d'exécution intégrale (obligatoire, non négociable)
|
||
|
||
- **Tout dérouler** : exécuter **toutes** les étapes décrites dans cet agent dans l'ordre, sans en omettre aucune. Tout doit se dérouler effectivement.
|
||
- **Sans priorisation** : aucune étape n'est optionnelle ou "secondaire" ; chacune est obligatoire.
|
||
- **Sans jugement d'intérêt** : ne jamais juger de la pertinence d'une étape pour la sauter ; tout appliquer tel que décrit, sans exception.
|
||
- **Vérification en fin d'agent** : avant clôture, cocher explicitement chaque étape (réalisée / non réalisée).
|
||
|
||
**Checklist à cocher (dans l'ordre) :**
|
||
1. Contexte : rappeler projet (id) et `projects/<id>/`.
|
||
2. Lire `deploy/change-to-all-branches.sh`.
|
||
3. Présenter résumé (étapes, options, effets).
|
||
4. Vérifier branche du dépôt projet = **test** (sinon retour 1).
|
||
5. Exécuter **/push-by-script** (message fourni par l'agent).
|
||
6. Exécuter `./deploy/change-to-all-branches.sh [project_id]` (timeout long).
|
||
7. **En échec du script** : identifier la cause (sortie + logs/deploy_*.log). Si typecheck / lint / build : lancer **intégralement** l'agent **/fix-lint** pour le projet, puis **/push-by-script**, puis relancer `./deploy/change-to-all-branches.sh [project_id]`. Répéter jusqu'à succès ou **maximum 5 tentatives** ; au-delà, documenter les erreurs et s'arrêter.
|
||
8. Clôture : points 1 à 16 de cloture-evolution.mdc (horodatage, 5 périmètres 3-11, 12-14, 15, 16).
|
||
|
||
---
|
||
|
||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'identifiant `<id>` est résolu par **paramètre** (optionnel : `./deploy/change-to-all-branches.sh [project_id]`), **MAIL_TO** ou **AI_AGENT_TOKEN**. Voir `projects/README.md`. Rappeler ce chemin en début d'exécution.
|
||
|
||
**Documentation** : La doc des projets gérés est dans **`projects/<id>/docs`** ; la doc ia_dev est dans **`projects/ia_dev/docs`**.
|
||
|
||
**Rôle de l’agent :** vérifier que la branche locale est test (sinon retour 1), fournir le message de commit (via /push-by-script), lancer le script, contrôler la sortie et le code de retour. **Rôle du script :** exécution déterministe (vérif branche test, branch-align.sh test, deploy.sh test --import-v1 --skipSetupHost --no-sync-origin ; log dans logs/ par défaut).
|
||
|
||
**Focus qualité et résolution de problèmes :**
|
||
|
||
- **Qualité :** Ne lancer le script qu'après un push-by-script réussi (message structuré, CHANGELOG à jour, build OK). En cas d'échec de push-by-script, traiter la cause (message manquant, build en échec, etc.) avant de continuer.
|
||
|
||
- **Résolution de problèmes :** Si change-to-all-branches.sh échoue (alignement ou déploiement), analyser la sortie pour identifier la cause ; appliquer la correction puis relancer sans demander validation (boucle corriger → pousser → relancer). Ne s'arrêter que si la correction n'est pas possible sans instruction utilisateur.
|
||
|
||
- **Boucle corriger-et-retenter (obligatoire) :** En cas d'échec du script (code de sortie non nul), 1) identifier la cause dans la sortie et/ou logs/deploy_*.log (ex. erreur TypeScript, lint, migration, SSH) ; 2) appliquer la correction dans le code du projet cible (dépôt indiqué par projects/`<id>`/conf.json) ; 3) committer et pousser via /push-by-script (ou ./deploy/pousse.sh [project_id]) avec un message décrivant le correctif ; 4) relancer ./deploy/change-to-all-branches.sh [project_id]. Répéter jusqu'à succès ou jusqu'à un blocage nécessitant instruction utilisateur (ex. erreur infra non corrigeable par l'agent). Ne pas se contenter de rapporter l'échec sans corriger et retenter.
|
||
|
||
- **Échec npm sur le serveur (ENOENT, ENOTEMPTY, node_modules) :** Si la sortie ou les logs (logs/deploy_*.log) contiennent une erreur npm liée à node_modules (ex. ENOENT, ENOTEMPTY, mkdir node_modules/…, npm error enoent). Il s'agit d'un problème d'environnement sur le serveur de déploiement, pas du code. **Correction automatique** : ne pas modifier le code ; relancer **une fois** ./deploy/change-to-all-branches.sh [project_id] (sans refaire /push-by-script : les branches sont déjà alignées). Le script distant deploy/scripts_v2/remote/deploy-app.sh effectue désormais un retry après `rm -rf node_modules` lors de chaque npm ci ; la relance lance un nouveau déploiement qui bénéficie de cette logique. Si l'échec persiste après cette unique relance, documenter la sortie et les logs (fichier deploy_*.log, extraits d'erreur npm) et s'arrêter — intervention manuelle ou infra requise (espace disque, droits, npm cache).
|
||
|
||
- **Échec du build (TypeScript, lint, frontend/backend) — boucle autonome obligatoire :** Si le déploiement échoue au build (code de sortie non nul, erreurs TypeScript, typecheck, lint, module introuvable, etc. dans la sortie ou dans logs/deploy_*.log), l'agent doit **obligatoirement** et **sans demander validation** : 1) Extraire de la sortie/log la liste des fichiers et erreurs (ex. fichiers .ts/.tsx listés par tsc ou eslint). 2) **Lancer et exécuter intégralement** l'agent **/fix-lint** (ou `.cursor/agents/fix-lint.md`) pour le projet cible, en lui passant en contexte les fichiers/erreurs identifiés si possible ; fix-lint corrige types, lint et compilation. 3) Exécuter **/push-by-script** (ou `./deploy/pousse.sh [project_id]`) pour committer et pousser les corrections. 4) **Relancer immédiatement** `./deploy/change-to-all-branches.sh [project_id]`. Répéter cette séquence (fix-lint → push-by-script → change-to-all-branches.sh) jusqu'à **succès** ou jusqu'à **5 tentatives** ; après 5 échecs consécutifs, documenter la sortie et les logs (extraits d'erreurs, fichiers concernés) et s'arrêter — intervention utilisateur requise. Aucune demande de validation entre correction et relance.
|
||
|
||
- **Logs et corrections :** Vérifier la sortie du script et le fichier logs/deploy_*.log produit par deploy.sh. En cas d'échec, identifier la cause à partir de ces logs, appliquer les corrections (code, config, doc), committer et pousser les changements via push-by-script si nécessaire, puis relancer le script jusqu'à succès ou blocage nécessitant instruction utilisateur.
|
||
|
||
**Avant d'exécuter un script du projet :**
|
||
|
||
1. Lire le fichier du script avec l'outil de lecture (ex. `deploy/change-to-all-branches.sh`).
|
||
2. Présenter à l'utilisateur un résumé de ce que le script va faire : étapes principales, options utilisées, effets attendus.
|
||
3. Lancer le script uniquement après cette présentation.
|
||
|
||
Si la branche locale actuelle n'est pas test, retourner 1.
|
||
|
||
Uniquement en test (branche git), exécuter dans l'ordre :
|
||
|
||
1. **/push-by-script** — pousse directement sur la branche test distante (pas de pull request). Message de commit fourni par l'agent.
|
||
2. **Exécuter depuis la racine de ia_dev** : `./deploy/change-to-all-branches.sh [project_id]` — aligne origin/test, origin/pprod, origin/prod sur le SHA de test, puis déploie l'environnement test (deploy.sh avec --import-v1 --skipSetupHost --no-sync-origin ; log dans logs/ par défaut). project_id optionnel pour cibler le projet. Push direct uniquement ; aucun script ni agent ne crée de pull request.
|
||
- **Paramètres :** Le script n'accepte qu'un seul argument optionnel : le **project_id** (ex. lecoffreio). La branche est toujours **test** (imposée par le script, pas un paramètre). Si l'utilisateur fournit deux tokens (ex. « test lecoffreio » ou « lecoffreio test »), extraire celui qui correspond à un projet (existence de `projects/<id>/conf.json`) et appeler le script avec uniquement ce project_id : `./deploy/change-to-all-branches.sh lecoffreio`.
|
||
- **Pas de timeout :** Ne pas lancer la commande avec un timeout court (ex. 5 min). Le déploiement (build, migrations, import-v1, redémarrage services, vérifications) peut durer 10 à 30 min ; utiliser un timeout long ou aucun timeout pour laisser le script aller au bout.
|
||
|
||
Retourner 0 en cas de succès. En cas d'échec d'une étape : consulter les logs (sortie du script, logs/deploy_*.log), identifier la cause. **Si la cause est typecheck / lint / build** : lancer **intégralement** l'agent **/fix-lint** pour le projet, puis /push-by-script, puis **relancer immédiatement** change-to-all-branches.sh (sans demander à l'utilisateur). Répéter jusqu'à succès ou **5 tentatives** ; au-delà, documenter et s'arrêter. Pour les autres causes (erreur serveur, secret manquant, infra) : s'arrêter si la correction n'est pas possible sans instruction utilisateur.
|
||
|
||
## Clôture complète obligatoire (tous les cas, sans exception)
|
||
|
||
En fin d'exécution de cet agent, **toujours** appliquer intégralement `.cursor/rules/cloture-evolution.mdc` : points 1 à 19. Pour le point 7 (Optimisation / mutualisation / centralisation), si « Non réalisées encore » : justifier par composant (voir `.cursor/agents/closure-point-7-justification.md`). Toutes les étapes (agent + clôture) doivent être **réellement passées**, sans jugement de pertinence ; tout doit se dérouler. (horodatage, 5 sub-agents par projet, questions 3-13, docupdate, reste à faire, push-by-script si pas déjà fait, affichage du texte du commit). **Aucune exception** : même si le script a échoué ou si l'agent n'a pas modifié de code, la clôture complète est obligatoire. Lister les actions réalisées et non réalisées pour chaque point.
|
||
|
||
**Exhaustivité obligatoire de la clôture :**
|
||
|
||
- Traiter **tous** les points 1 à 16 (ou 19 selon la référence en vigueur) sans en omettre aucun.
|
||
- **Point 1** : Horodatage au début et à la fin ; projet (id), branche, répertoire de travail ; au lancement et au retour de chaque sub-agent.
|
||
- **Point 2** : Lancer ou exécuter intégralement un sub-agent (ou une passée de checklist) pour **chaque** périmètre du projet cible : global/commun, frontend, backend, ressources partagées, scripts shell — et pour **chaque** périmètre répondre aux points 3 à 11 (Réalisées / Non réalisées encore).
|
||
- **Points 3 à 11** : Pour chaque point, indiquer explicitement « Réalisées » et « Non réalisées encore » (éventuellement par périmètre si pertinent).
|
||
- **Points 12 à 14** : Lister le reste à faire (12), réaliser le « Non réalisées encore » (13), réaliser le reste à faire (14).
|
||
- **Point 15** : Lancer /push-by-script si pas déjà fait (message structuré selon le format obligatoire).
|
||
- **Point 16** : Afficher le texte du commit.
|
||
Si un point est non applicable (ex. périmètre absent du projet, avec justification), le mentionner explicitement plutôt que de l’omettre.
|
||
|
||
### Règles d'exécution des points 3 à 11 (obligatoires, pas de N/A de convenance)
|
||
|
||
- **Interdiction** : Ne jamais répondre « Réalisées : N/A » ou « Non réalisées encore : N/A » pour les points 3 à 11 sauf si le **périmètre n'existe pas** dans le projet (ex. projet sans frontend). Pour chaque périmètre existant (défini dans `projects/<id>/conf.json` : build_dirs, project_path), une **vérification concrète** est obligatoire.
|
||
- **Même sans modification de code** (ex. run limité à push + change-to-all-branches) : exécuter les vérifications ci-dessous sur le dépôt du projet et indiquer le résultat par périmètre (Réalisées avec précision, ou Non réalisées encore avec précision).
|
||
- **Vérifications concrètes obligatoires** :
|
||
- **3. Helpers** : Parcourir les zones concernées (fichiers modifiés ou build_dirs) ; indiquer « Réalisées » si création/usage de helpers où pertinent, « Non réalisées encore » si duplication ou logique à extraire en helper. Préciser le périmètre concerné.
|
||
- **4. i18n + env-full** : Vérifier textes en dur dans l'UI, présence de `.secrets/<env>/env-full*` ; « Réalisées » si conforme, « Non réalisées encore » sinon. Préciser.
|
||
- **5. Fallback interdits** : Parcourir le code (modifié ou périmètre) pour fallback, valeurs par défaut masquant des erreurs ; « Réalisées » si aucun, « Non réalisées encore » si présents.
|
||
- **6. Modifications similaires** : Vérifier s'il existe ailleurs dans le dépôt des patterns similaires à appliquer ; « Réalisées » si étendu ou rien à faire, « Non réalisées encore » si à faire. Préciser.
|
||
- **7. Optimisation / mutualisation / centralisation** : Vérifier duplication ou centralisation possible ; « Réalisées » ou « Non réalisées encore » avec précision.
|
||
- **8. Réduction complexité** : Vérifier complexité (longueur fichiers, imbrication) dans les zones concernées ; « Réalisées » ou « Non réalisées encore ».
|
||
- **9. Renforcement sécurité** : Vérifier exposition de données sensibles, validation des entrées ; « Réalisées » ou « Non réalisées encore ».
|
||
- **10. Code mort** : Vérifier présence de code mort (exports inutilisés, branches mortes) dans les zones concernées ; « Réalisées » ou « Non réalisées encore ».
|
||
- **11. Lint corrigé** : **Exécuter** `npm run lint` (ou la commande de lint du projet) dans **chaque** répertoire du périmètre (chaque build_dir : backend, frontend, ressources partagées — pas seulement un sous-ensemble). Comptabiliser **erreurs et warnings** dans la sortie. « Réalisées » **uniquement** si **0 erreur et 0 warning** pour ce périmètre. S'il reste des erreurs ou des warnings : « Non réalisées encore » en précisant le nombre d'erreurs et le nombre de warnings par répertoire (ex. « frontend : 0 erreur, 1004 warnings »). Ne jamais considérer le lint OK pour un projet si des warnings restent ; les traiter ou les documenter dans le reste à faire. Même règle pour tous les projets (backend, frontend, ressources).
|
||
- **Types** : **Exécuter** type-check/build du projet ; « Réalisées » si OK, « Non réalisées encore » sinon.
|
||
- **Compilation** : **Exécuter** le build ; « Réalisées » si succès, « Non réalisées encore » sinon.
|
||
- **Format de réponse** : Pour chaque point, écrire soit « Réalisées : [précision courte] », soit « Non réalisées encore : [précision courte] ». Interdit de laisser un point sans réponse ou avec uniquement « N/A » sans justification (périmètre inexistant).
|