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-lecoffre-all-sites.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`**, **`enso`**, **`genealogie`**) ou **`deploy-site.sh`** / **`deploy-lecoffre-all-sites.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 (test)** : agent **`.smartIde/agents/deploy-test-site.md`** ( **`deploy-site.sh test <site>`** ). **Une seule ligne (pprod/prod)** : **`.smartIde/agents/deploy-pprod-or-prod-site.md`** (align **`change-to-all-branches.sh --align-only`** puis **`deploy-site.sh <env> <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-lecoffre-all-sites.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.