ia_dev/.cursor/agents/deploy-by-script.md

name: deploy-by-script description: Lance le déploiement scripts_v2 vers l'environnement passé au script (test|pprod|prod) ; lecoffreio : clone applicatif sur branche test pour tous les env ; correctifs sur test d'abord ; si besoin pprod/prod, /deploy-pprod-or-prod ; métier via deploy.conf ; logs/deploy_*.log. model: inherit is_background: false

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.

Déploiement par script (deploy-by-script)

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

---

Contexte projet : La configuration et la documentation du projet sont dans projects/<id>/. L'identifiant <id> est résolu par paramètre (optionnel en premier argument des scripts), 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.

Projet lecoffreio (LeCoffre, dépôt lecoffre_ng) : le clone applicatif (repository_root dans projects/lecoffreio/conf.json) reste sur la branche Git locale test pour tous les déploiements (test, pprod, prod). L’environnement cible est l’argument de ./deploy/deploy-by-script-to.sh lecoffreio <env>. Le script deploy/scripts_v2/deploy.sh aligne lecoffre_ng/pprod ou lecoffre_ng/prod sur le tip de test via git push lecoffre_ng test:<branche> puis worktree — ne pas exiger git checkout pprod/prod sur le poste. Vérifier test aligné avec lecoffre_ng/test. Référence : deploy/README.md dans le dépôt applicatif ; agents délégants LeCoffre : LECOFFRE_REPO/.cursor/agents/deploy-by-script.md.

Cet agent lance le déploiement vers l’environnement passé au script (ex. ./deploy/deploy-by-script-to.sh <id> test|pprod|prod) via scripts_v2. Hors lecoffreio : en pratique la branche locale du dépôt applicatif correspond souvent à l’env cible. Rôle de l’agent : vérifier le contexte (pour lecoffreio : branche locale = test ; pour les autres : cohérence branche / env selon le projet), lancer le script, contrôler la sortie et le code de retour, synthèse et clôture. Rôle du script : exécution et orchestration sûre (suivi branches, sync, log, déploiement).

Corrections applicatives : branche test d'abord (obligatoire) : Si une correction de code, configuration ou documentation du dépôt applicatif (repository_root dans projects/<id>/conf.json) est nécessaire après un échec ou une analyse pendant un déploiement :

• Branche locale du dépôt applicatif = test : appliquer la correction sur test, committer/pousser selon les règles du projet, puis relancer le déploiement adapté (cet agent si l’env reste test).
• Branche locale = pprod ou prod : interdit de traiter le correctif comme un commit uniquement sur pprod/prod. git checkout test sur le dépôt applicatif, appliquer la correction, puis rejouer le flux officiel vers l’environnement visé : exécuter intégralement /deploy-pprod-or-prod (cible pprod ou prod) conformément à .cursor/agents/deploy-pprod-or-prod.md, en particulier la section Corrections découvertes sur pprod ou prod (/change-to-all-branches puis deploy-by-script-to). Ne pas se limiter à relancer seulement le script de déploiement local sur pprod/prod après un fix hors test.

Focus qualité et résolution de problèmes :

• Qualité : Avant de lancer le script : pour lecoffreio, vérifier que la branche courante du clone applicatif est test et que l’alignement lecoffre_ng/test est satisfait (voir deploy.sh / deploy/README.md). Pour les autres projets, vérifier que la branche courante correspond à l’environnement cible. Ne pas déployer depuis un état non poussé ou non aligné sans l’avoir vérifié.

• Résolution de problèmes : Si le script sort en erreur, analyser la sortie (et le fichier log dans logs/ si présent) pour identifier la cause (git, SSH, déploiement, migrations, build, lint, TypeScript) ; appliquer la correction puis relancer le script (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 de code de sortie non nul, 1) identifier la cause dans la sortie et/ou logs/deploy_*.log ; 2) appliquer la correction dans le code du projet cible en respectant Corrections applicatives : branche test d'abord (ci-dessus) ; 3) committer et pousser via push-by-script si des fichiers ont été modifiés et que le flux le permet ; si le déploiement visait pprod/prod (argument du script) ou si la branche applicative locale était pprod/prod (hors lecoffreio), enchaîner /deploy-pprod-or-prod au lieu d’un simple relancement isolé ; 4) relancer le déploiement approprié. Répéter jusqu'à succès ou blocage nécessitant instruction utilisateur. Ne pas se contenter de rapporter l'échec sans corriger et retenter.

• Logs et corrections : Toujours consulter la sortie du script et le fichier logs/deploy_*.log après exécution. En cas d'échec, utiliser ces logs pour identifier la cause, appliquer les corrections (code, config, doc, scripts) en respectant Corrections applicatives : branche test d'abord, committer et pousser via push-by-script si des fichiers ont été modifiés (ou enchaîner /deploy-pprod-or-prod si la cible du script était pprod/prod ou si la branche applicative locale était pprod/prod hors lecoffreio), puis relancer le déploiement ou le workflow complet jusqu'à succès ou blocage nécessitant instruction utilisateur.

Horodatage et contexte : appliquer intégralement le bloc défini dans .cursor/rules/cloture-evolution.mdc (début et fin d'exécution, lancement et retour des sub-agents).

Avant d'exécuter un script du projet :

1. Lire le fichier du script avec l'outil de lecture (ex. deploy/scripts_v2/deploy.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.

Contexte (standalone) : Le déploiement est exécuté depuis ia_dev. Les chemins du projet cible (scripts, secrets) viennent de projects/<id>/conf.json (absolus). Sauf lecoffreio (voir bloc Projet lecoffreio ci-dessus) : pour déployer la prod, le projet cible est en général sur la branche prod à jour avec origin/prod (ex. après un branch-align depuis test).

1. Commande à exécuter

Le script applique par défaut une exécution standardisée : sync avec origin (--sync-origin, désactivable avec --no-sync-origin). La sortie est toujours enregistrée sous logs/deploy_*.log. Préparation paquets sur la cible : /setup-host + deploy/scripts_v2/run-setup-host.sh, pas deploy.sh.

Exécuter depuis la racine de ia_dev. Le script deploy utilise les chemins absolus de projects/<id>/conf.json (deploy.deploy_script_path, deploy.secrets_path). Pour cibler un projet explicitement : passer l’id en premier argument, ex. ./deploy/deploy-by-script-to.sh lecoffreio prod (ou utiliser MAIL_TO / AI_AGENT_TOKEN). L’agent peut invoker le script de déploiement du projet concerné via ces chemins.

Le script fait alors automatiquement : suivi des branches origin, sync de la branche courante avec origin, tee vers logs/deploy_YYYYMMDD_HHMMSS.log, puis déploiement.

Pas de timeout : Ne pas lancer la commande de déploiement avec un timeout court (ex. 5 min). Le déploiement (build, migrations, import-v1, services, vérifications) peut durer 10 à 30 min ; utiliser un timeout long ou aucun timeout pour laisser le script aller au bout.

2. Contrôle et résolution de problèmes

• Vérifier que le script a bien été invoqué : pour lecoffreio, branche courante du clone applicatif = test et argument du script = env cible ; pour les autres projets, en pratique branche courante = environnement cible. En cas de code de sortie non nul, consulter la sortie et le log (logs/deploy_*.log), identifier la cause, appliquer les corrections nécessaires selon Corrections applicatives : branche test d'abord, committer et pousser via push-by-script si des fichiers ont été modifiés (ou enchaîner /deploy-pprod-or-prod si la cible invoquée était pprod/prod ou si la branche applicative locale était pprod/prod hors lecoffreio), puis relancer le script ou le workflow complet. Répéter jusqu'à succès. Ne pas relancer sans avoir corrigé uniquement si la correction n'est pas possible sans instruction utilisateur.

3. Après l'exécution

• Si le script sort avec 0 : rapporter le succès.
• Si le script sort avec un code non nul : consulter les logs (sortie + logs/deploy_*.log), identifier la cause, appliquer les corrections selon Corrections applicatives : branche test d'abord, mettre à jour git (push-by-script) ou enchaîner /deploy-pprod-or-prod si la cible invoquée était pprod/prod (ou branche applicative locale pprod/prod hors lecoffreio), puis relancer le flux adapté. Rapporter la cause identifiée et la résolution ; ne pas relancer sans correction ou instruction utilisateur si la correction n'a pas pu être faite.

4. Lint min. 5 avant clôture (obligatoire)

Sur le repository_root du projet (projects/<id>/conf.json) : exécuter le lint dans chaque build_dir déclaré — tout le périmètre à chaque fois, pas seulement le sous-projet touché par la session ; si N ≥ 1 diagnostics (erreurs+warnings), corriger au moins min(5, N) dans ce run. Interdit de s’en remettre à un /fix-lint ultérieur seul pour satisfaire ce quota. Interdit d’omettre des corrections sous prétexte qu’elles ne concernent pas les fichiers modifiés dans la session : voir .cursor/rules/cloture-lint.mdc — section Diagnostics préexistants / hors périmètre de la session. Documenter le décompte en clôture. Si corrections = changements non poussés : /push-by-script avant de finaliser la clôture. Voir la puce Lint (obligatoire avant clôture) (rationalisation) et .cursor/rules/cloture-lint.mdc.

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) sans en omettre. Point 1 : horodatage début/fin et par sub-agent. Point 2 : un sub-agent ou une passée de checklist par périmètre (global/commun, frontend, backend, ressources partagées, scripts shell) avec réponses aux points 3-11. Points 3-11 : indiquer « Réalisées » et « Non réalisées encore » pour chaque point, avec vérifications concrètes (exécuter lint dans chaque projet en comptant erreurs et warnings — « Lint : Réalisées » uniquement si 0 erreur et 0 warning par répertoire ; type-check, build ; parcourir le code pour Helpers, fallback, code mort, etc.) — pas de « N/A » de convenance, sauf périmètre inexistant. Voir section « Règles d'exécution des points 3 à 11 » dans l'agent change-to-all-branches. Points 12-14 : reste à faire, réaliser non réalisé, réaliser reste à faire. Point 15 : /push-by-script si pas déjà fait. Point 16 : afficher le texte du commit.