smart_ide/services/ia_dev/.smartIde/agents/change-to-all-branches.md

name	model	description
change-to-all-branches	inherit	Uniquement en test, lance /push-by-script puis deploy/change-to-all-branches.sh (alignement + déploiement test). Correctifs applicatifs sur test ; si contexte pprod/prod, voir deploy-pprod-or-prod (section corrections).

Preparer au maximum à l'aide d'outils et de scripts

En tant qu'agent, avant de solliciter l'ia, regarde ce que tu peux scripter (importe/install les outils nécessaires si besoin) l'ia est la derniere priorité par rapport à l'outillage, les outils sont lancés dans des scripts dans /home/desk/code/ia_dev/tools et rendus le plus générique possible afin de les réutilisé plus tard dans d'autres contextes, par contre l'ia peut serveur à développer ces scripts.

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. Lint min. 5 avant clôture : sur repository_root, lint chaque build_dir (tout le périmètre déclaré, pas seulement le sous-projet modifié dans la session) ; si N ≥ 1, corriger au moins min(5, N) dans ce run ; décompte avant/après. Interdit de clôturer en reportant seul sur un /fix-lint ultérieur sans ces corrections. Interdit d’ignorer des warnings/erreurs parce qu’ils sont « préexistants » ou hors fichiers modifiés ce run : voir .smartIde/rules/cloture-lint.mdc — section Diagnostics préexistants / hors périmètre de la session. Si fichiers modifiés : /push-by-script avant clôture si le dépôt n’est pas clean.
9. 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 docs/repo/ia-dev-project-conf-schema.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, orchestrateur ou deploy.sh test --no-sync-origin ; flags métier uniquement via $SECRETS_BASE/test/deploy.conf ; journalisation toujours ./logs/deploy_*.log). Préparation OS cible : agent /setup-host + deploy/scripts_v2/run-setup-host.sh, pas deploy.sh.

Branche applicative test-first (obligatoire) : Toute correction de code, configuration ou documentation dans le dépôt applicatif (repository_root dans projects/<id>/conf.json) pendant l’exécution de cet agent doit être réalisée sur la branche locale test. Avant toute modification : si le dépôt applicatif n’est pas sur test, exécuter git checkout test (ou équivalent validé projet). Interdit : committer un correctif uniquement sur pprod ou prod depuis cet agent. Si l’échec ou le contexte provient d’une phase pprod/prod (correctifs identifiés après déploiement ou analyse sur ces branches), appliquer la procédure Corrections découvertes sur pprod ou prod dans .smartIde/agents/deploy-pprod-or-prod.md : correctifs sur test, puis rejouer le workflow complet depuis l’étape 2 de cet agent dans ce flux (/change-to-all-branches inclus dans /deploy-pprod-or-prod), sans court-circuiter l’alignement test → pprod → prod.

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) sur la branche test du dépôt applicatif (voir Branche applicative test-first ci-dessus) ; 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 .smartIde/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 (orchestrator.sh ou deploy.sh test --no-sync-origin ; métier via deploy.conf ; logs ./logs/). 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 .smartIde/rules/cloture-evolution.mdc : points 1 à 19. Pour le point 7 (Optimisation / mutualisation / centralisation), si « Non réalisées encore » : justifier par composant (voir .smartIde/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).