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).

Politique — une seule tentative de déploiement test par invocation

• Tentative : une exécution de ./deploy/change-to-all-branches.sh [project_id] sans --align-only (le script enchaîne alignement + déploiement test multisite).
• Par message utilisateur / ouverture d’agent : au plus une telle exécution ; si code de sortie non nul, ne pas relancer ce script dans le même run.
• Après échec : analyser sortie + logs/deploy_*.log ; /fix-lint puis /push-by-script autorisés pour corriger le dépôt — sans nouvelle exécution de change-to-all-branches.sh tant que l’utilisateur n’a pas relancé explicitement /change-to-all-branches.
• Alignement : deploy-test-by-script.md, .smartIde/agents/deploy-by-script.md, .smartIde/agents/deploy-pprod-or-prod.md (même principe sur leurs commandes de déploiement).

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). Sans l’option --align-only : le script enchaîne alignement et déploiement test. L’option --align-only (alignement uniquement) est réservée au workflow /deploy-pprod-or-prod — ne pas l’utiliser pour clôturer cet agent si un déploiement test est attendu.
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 — ne pas relancer ./deploy/change-to-all-branches.sh [project_id] dans le même run (§ Politique — une seule tentative de déploiement test). Pour les autres causes (SSH, secrets, infra) : documenter et s’arrêter sans nouvelle exécution du script dans ce run.
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, puis sauf --align-only : orchestrator.sh test --no-sync-origin ou, à défaut, bash deploy/scripts_v2/deploy-multisite-lines.sh test --no-sync-origin — toujours les deux lignes lecoffreio / genealogie lorsque le dépôt expose deploy-multisite-lines.sh ; repli historique deploy.sh test uniquement si ce script est absent). Flags métier via $SECRETS_BASE/<site>/test/deploy.conf (par ligne) ; journalisation ./logs/deploy_*.log. Préparation OS : /setup-host + run-setup-host.sh, pas confondre avec le déploiement applicatif.

Projet kogus (monorepo LeCoffre) : si le script enchaîne deploy/scripts_v2, appliquer le contrat multisite (SITE_CODE / deploy-site.sh / deploy-multisite-lines.sh, secrets .secrets/<site>/<env>/) décrit dans repository_root/docs/features/multi-site-architecture.md et repository_root/.cursor/agents/agent-paths-registry.md §3 bis (les agents Cursor du dépôt applicatif sont sous .cursor/agents/, pas .smartIde).

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, pousser hors /deploy-pprod-or-prod si besoin, puis nouvelle invocation utilisateur de /deploy-pprod-or-prod (workflow depuis l’étape 2 ; une tentative de deploy-by-script-to par ouverture d’agent — § Politique dans le même fichier). Ne pas confondre avec l’agent /change-to-all-branches (déploiement test multisite).

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). /push-by-script ne compile pas : l’absence de build dans ce flux n’est pas un échec de push-by-script. En cas d'échec de push-by-script, traiter la cause (message manquant, script en erreur, etc.) avant de continuer.

• Résolution de problèmes : Si change-to-all-branches.sh échoue, analyser la sortie pour identifier la cause ; appliquer les corrections (/fix-lint, /push-by-script) sans relancer le script de déploiement test dans le même run (§ Politique).

• Après échec du script (code de sortie non nul) : 1) Cause dans la sortie et/ou logs/deploy_*.log ; 2) corrections sur le dépôt applicatif (repository_root, branche test, voir Branche applicative test-first) ; 3) /fix-lint puis /push-by-script si des fichiers ont été modifiés — interdit : relancer ./deploy/change-to-all-branches.sh [project_id] dans la même ouverture d’agent ; l’utilisateur relance /change-to-all-branches pour un nouvel essai.

• Échec npm sur le serveur (ENOENT, ENOTEMPTY, node_modules) : Problème d’environnement cible. Documenter la sortie et logs/deploy_*.log ; ne pas relancer change-to-all-branches.sh dans ce run ; intervention manuelle ou nouvelle invocation utilisateur après correction infra.

• Échec du build (TypeScript, lint, frontend/backend) : 1) Extraire fichiers / erreurs depuis la sortie ou les logs. 2) /fix-lint intégralement pour le projet cible. 3) /push-by-script (ou ./deploy/pousse.sh [project_id]) si des corrections ont été enregistrées. Ne pas enchaîner une seconde exécution de ./deploy/change-to-all-branches.sh [project_id] dans le même run ; indiquer qu’un nouvel /change-to-all-branches est requis pour redéployer.

• Logs et corrections : Consulter la sortie du script et logs/deploy_*.log. Après échec : corrections + push possibles ; pas de nouvelle tentative de déploiement test sans nouvelle demande 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 test en multisite (orchestrator.sh ou deploy-multisite-lines.sh test --no-sync-origin ; métier via deploy.conf par site ; logs ./logs/). project_id optionnel. Push direct uniquement ; aucun PR. Ne pas passer --align-only pour cet agent (cette option saute le déploiement test ; elle est utilisée par /deploy-pprod-or-prod étape 2 uniquement).
   • Paramètres : Arguments : project_id optionnel (ex. kogus), puis optionnellement --align-only (hors périmètre de cet agent). La branche git est toujours test. Si l'utilisateur fournit des tokens ambigus (ex. « test kogus »), extraire le project_id quand projects/<id>/conf.json existe : ./deploy/change-to-all-branches.sh kogus.
   • 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 : /fix-lint puis /push-by-script — sans relancer change-to-all-branches.sh dans le même run (§ Politique — une seule tentative de déploiement test). Pour les autres causes : documenter et s'arrêter ; nouvel essai de déploiement = nouvelle invocation /change-to-all-branches.

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 des env-full-* sous .secrets/<site>/<env>/ sur LECOFFRE_REPO ; « 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).