ia_dev/.smartIde/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) ; si deploy.host_stays_on_test dans conf : clone sur test pour pprod|prod ; correctifs sur test d'abord ; /deploy-pprod-or-prod si besoin ; 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).

Politique — une seule tentative de déploiement par invocation

• Tentative de déploiement : une exécution de ./deploy/deploy-by-script-to.sh [project_id] <test|pprod|prod> (le script enchaîne l’orchestration deploy/scripts_v2 / multisite selon le projet).
• Par message utilisateur / ouverture d’agent : au plus une tentative ; si le code de sortie est non nul, ne pas relancer deploy-by-script-to.sh vers le même environnement dans le même run.
• Après échec : analyser la sortie et logs/deploy_*.log, documenter la cause et les prérequis ; corrections code / config / doc et /push-by-script possibles sans nouvel appel au script de déploiement ; l’utilisateur relance explicitement /deploy-by-script (ou équivalent) pour un nouvel essai.
• Alignement : LECOFFRE_REPO/.cursor/agents/deploy-test-by-script.md (test, deploy-multisite-lines.sh) et .smartIde/agents/deploy-pprod-or-prod.md / change-to-all-branches.md pour la même règle sur leurs commandes respectives.

---

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

deploy.host_stays_on_test: true dans projects/<id>/conf.json (ex. kogus / monorepo LeCoffre) : le clone applicatif (repository_root) reste sur la branche Git locale test pour les déploiements pprod/prod via deploy-by-script-to.sh. L’environnement cible est l’argument du script. Le deploy.sh du dépôt aligne les remotes / worktree (ex. git push lecoffre_ng test:<branche> pour LeCoffre) — pas de git checkout pprod/prod sur le poste. Vérifier test aligné avec le remote attendu. Doc applicative : deploy/README.md ; agents Cursor du dépôt LeCoffre : repository_root/.cursor/agents/deploy-by-script.md (pas .smartIde sur le dépôt applicatif).

Multisite — projet kogus (site produit lecoffreio = ligne notaire)

Lorsque le playbook appelle repository_root/deploy/scripts_v2/, respecter la boucle SITE_CODE (lecoffreio, genealogie) ou deploy-site.sh / deploy-multisite-lines.sh ; deploy-by-script-to ne positionne pas SITE_CODE. Secrets : .secrets/<site>/<env>/. Source normative : repository_root/docs/features/multi-site-architecture.md ; repository_root/.cursor/agents/agent-paths-registry.md §3 bis ; § Multisite dans repository_root/.cursor/agents/deploy-pprod-or-prod.md. Une seule ligne : six agents (site × env) — deploy-test-lecoffreio, deploy-test-genealogie, deploy-pprod-lecoffreio, deploy-pprod-genealogie, deploy-prod-lecoffreio, deploy-prod-genealogie (fichiers .smartIde/agents/deploy-*.md, playbook canonique sous LECOFFRE_REPO/.cursor/agents/). Repli paramétrique : deploy-test-site.md (deploy-site.sh test <site>), deploy-pprod-or-prod-site.md (align puis deploy-site.sh <pprod|prod> <site>, sans deploy-by-script-to).

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. Si deploy.host_stays_on_test est absent ou false : en pratique la branche locale du dépôt applicatif correspond souvent à l’env cible pour pprod/prod. Rôle de l’agent : vérifier le contexte (si host_stays_on_test : branche locale = test ; sinon : 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 ; un nouvel essai de déploiement = nouvelle invocation /deploy-test-by-script ou /deploy-by-script (pas de relance automatique du script de déploiement dans le même run — § Politique — une seule tentative).
• 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 à .smartIde/agents/deploy-pprod-or-prod.md, en particulier la section Corrections découvertes sur pprod ou prod (/push-by-script puis ./deploy/change-to-all-branches.sh [project_id] --align-only puis deploy-by-script-to, conformément à l’étape 2 et 3 de .smartIde/agents/deploy-pprod-or-prod.md). 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 : si deploy.host_stays_on_test dans la conf du projet, vérifier que la branche courante du clone applicatif est test et l’alignement remote (ex. lecoffre_ng/test pour LeCoffre ; voir deploy.sh / deploy/README.md). Sinon, 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). Ne pas relancer deploy-by-script-to.sh dans le même run (voir § Politique — une seule tentative de déploiement). Appliquer les corrections selon Corrections applicatives : branche test d'abord si pertinent, committer / pousser (/push-by-script, /deploy-pprod-or-prod depuis l’étape prescrite pour pprod/prod) sans second essai de déploiement tant que l’utilisateur n’a pas relancé explicitement cet agent.

• Après code de sortie non nul : 1) Cause dans la sortie et/ou logs/deploy_*.log ; 2) corrections sur le dépôt applicatif en respectant Corrections applicatives : branche test d'abord ; 3) /push-by-script ou /deploy-pprod-or-prod (workflow complet depuis l’étape indiquée dans .smartIde/agents/deploy-pprod-or-prod.md) uniquement hors logique « relancer tout de suite le même deploy-by-script-to » — un nouvel essai de deploy-by-script-to.sh = nouvelle invocation utilisateur de /deploy-by-script.

• 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 et documenter les prérequis ; corrections (code, config, doc) + push si besoin, sans rappeler deploy-by-script-to.sh dans le même run.

Horodatage et contexte : appliquer intégralement le bloc défini dans .smartIde/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 ; pour kogus, lire aussi deploy-site.sh / deploy-multisite-lines.sh si le flux les utilise).
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 si deploy.host_stays_on_test (voir 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 kogus 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é : si deploy.host_stays_on_test, branche courante du clone applicatif = test et argument du script = env cible ; sinon, 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 selon Corrections applicatives : branche test d'abord et pousser si besoin — sans relancer deploy-by-script-to.sh dans le même run (§ Politique — une seule tentative de déploiement).

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 préparer /deploy-pprod-or-prod selon le cas — ne pas réexécuter deploy-by-script-to.sh dans ce run ; rapporter la cause et indiquer qu’un nouvel /deploy-by-script est nécessaire pour rejouer le déploiement.

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