ia_dev/.smartIde/agents/deploy-pprod-or-prod.md

---
name: deploy-pprod-or-prod
description: Déploie vers pprod ou prod : alignement branches (change-to-all-branches.sh --align-only, sans déploiement test), deploy-by-script-to. Prérequis : **origin/test** à jour (push hors cet agent : **pousse.sh** ou **/push-by-script**). Toute correction issue d’une phase pprod/prod se fait sur test puis le workflow est rejoué depuis l’étape 2. Paramètre obligatoire pprod ou prod.
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.

- **Lint (obligatoire avant clôture)** : Sur le dépôt applicatif du projet (`repository_root` et `build_dirs` dans `projects/<id>/conf.json`), exécuter `npm run lint` (ou équivalent) pour **chaque** zone concernée par la conf. Compter **erreurs + warnings**. Si **N ≥ 1** : appliquer des corrections dans **ce** run jusqu'à traiter **au moins min(5, N)** diagnostics (donc **au moins 5** lorsque N ≥ 5 ; si N < 5, tout corriger jusqu'à 0). **Interdit** de s'exonérer par un lint déjà passé **sans** changements ESLint enregistrés dans le workspace, ou en reportant sur un **`/fix-lint` ultérieur** : les corrections (min. 5 quand N ≥ 5) font partie **du même run** que la clôture. Clôture : commandes, périmètres, **décompte avant/après**. Voir `.smartIde/rules/cloture-lint.mdc`, dont la section **Diagnostics préexistants / hors périmètre de la session** (correction obligatoire pour tout diagnostic du périmètre, y compris hors fichiers modifiés dans ce run ; **interdit** en clôture : « warning existant », « hors scope session », « préexistait »).

# Agent deploy-pprod-or-prod

## 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] <pprod|prod>`** (étape **3** du workflow ci-dessous), qui enchaîne le déploiement multisite sur la cible.
- **Par message utilisateur / ouverture d’agent** : **au plus une** tentative pour l’étape **3** ; si le code de sortie est **non nul**, **ne pas** relancer **`deploy-by-script-to.sh`** vers **pprod** ou **prod** dans le **même** run.
- **Après échec de l’étape 3** : analyser les logs, appliquer **Corrections découvertes sur pprod ou prod** si besoin (correctifs sur **test**, push hors agent) ; **ne pas** enchaîner une seconde exécution de l’étape **3** sans **nouvelle** demande utilisateur (**`/deploy-pprod-or-prod`** ou équivalent).
- **Étape 2** (**`change-to-all-branches.sh --align-only`**) : alignement Git **sans** déploiement applicatif **test** ; une nouvelle exécution de l’étape **2** après correction reste possible dans le même run si le playbook l’exige pour des raisons d’alignement, **sans** compenser une nouvelle tentative d’**étape 3** sans nouvelle demande.
- **Alignement** : **`LECOFFRE_REPO/.cursor/agents/deploy-test-by-script.md`**, **`.smartIde/agents/deploy-by-script.md`**, **`.smartIde/agents/change-to-all-branches.md`**.

---

**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 et en fin 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 :** Exécuter le déploiement vers **pprod** ou **prod** en suivant strictement le workflow ci-dessous. Paramètre obligatoire : `pprod` ou `prod`. En cas d’échec de l’**étape 3** (**`deploy-by-script-to`**), **s’arrêter** après analyse et corrections documentées — **pas** de second lancement de l’**étape 3** dans le même run (**§ Politique — une seule tentative de déploiement**). Pour l’**étape 2** uniquement (alignement), en cas d’échec : corriger puis **une** nouvelle exécution de l’**étape 2** autorisée si nécessaire avant toute **nouvelle** invocation utilisateur pour l’**étape 3**.

**Répertoire d'exécution (standalone) :** Racine de ia_dev. Tous les scripts sont invoqués depuis la racine de ia_dev.

**`repository_root` (LeCoffre) / branche `test` — pas de `git stash` :** ne pas utiliser **`git stash`** sur le clone applicatif pour « préparer » **`pousse.sh`** ou un déploiement — commit WIP + **`./deploy/pousse.sh`** (message sur stdin ; builds explicites avant push ou **`--build`** si compilation requise dans le même appel). Le stash crée des conflits (**`VERSION`**, fichiers non suivis) et duplique souvent un état déjà sur **`origin/test`**.

## Corrections découvertes sur pprod ou prod (obligatoire)

- **Contexte** : analyse des logs, échec de **`deploy-by-script-to`**, constat sur le dépôt applicatif alors que la branche locale est **pprod** ou **prod**, ou toute autre intervention qui amène à modifier code, configuration ou documentation du projet cible.
- **Interdit** : appliquer la correction **uniquement** sur la branche **pprod** ou **prod** du dépôt applicatif (`repository_root` dans `projects/<id>/conf.json`) et poursuivre sans repasser par **test** (pas de « correctif local pprod/prod puis push ciblé » en dehors du flux test-first).
- **Obligation** :
  1. **`git checkout test`** (ou équivalent validé projet) sur le **dépôt applicatif** ; y **réaliser** les corrections (commits selon règles du projet) ; **pousser** **`test`** → **`origin/test`** **hors** cet agent (**`/push-by-script`** ou **`./deploy/pousse.sh kogus`**, etc.) tant que le tip local n’est pas sur le remote.
  2. **`./deploy/change-to-all-branches.sh [project_id] --align-only`** (alignement uniquement). **Étape 3** (**`deploy-by-script-to`**) et **étapes 4 à 5** : **nouvelle** invocation utilisateur de **`/deploy-pprod-or-prod`** — **pas** de second **`deploy-by-script-to`** dans le run déjà en échec sur l’étape 3 (**§ Politique — une seule tentative de déploiement**). Pour un **déploiement test** complet après correctif, enchaîner l’agent **`/change-to-all-branches`** en flux **séparé**.
- Si plusieurs cycles correction → alignement sont nécessaires, **chaque** correction part de **test** puis enchaîne **étape 2** si besoin ; **chaque** nouvel essai de **déploiement** (**étape 3**) suppose une **nouvelle** demande utilisateur (**`/deploy-pprod-or-prod`**) après alignement et push, conformément à **§ Politique — une seule tentative de déploiement**.

## Ordre des agents et anti-duplication (obligatoire)

Règles **décisionnelles** (ne pas lancer en double ce qu’un agent en aval exécute déjà) :

| Action en amont | Condition | Application |
| --- | --- | --- |
| **Push `test` → `origin/test`** | Ce workflow **n’exécute pas** **`/push-by-script`** ni **`pousse.sh`**. | Avant l’**étape 2**, le tip à déployer doit être sur **`origin/test`** (push **hors** cet agent si besoin). L’**étape 2** exécute uniquement **`./deploy/change-to-all-branches.sh [project_id] --align-only`**. |
| **Agent `/change-to-all-branches`** (déploiement **test** inclus) | Lancer **avant** ce workflow **seulement** pour un besoin explicite de **déploiement test** (flux séparé). | Ce fichier **n’invoque pas** l’agent **`/change-to-all-branches`** : l’étape 2 aligne les branches via **`change-to-all-branches.sh --align-only`** **sans** **`deploy.sh` test**. **Interdit** de lancer l’agent **`/change-to-all-branches`** juste avant ce workflow pour « pré-déployer test » dans le même objectif pprod/prod — utiliser **`/change-to-all-branches`** en session **dédiée** si le déploiement test est requis. |

**Si** une future version de ce fichier **supprime** l’étape 2 : réévaluer le tableau (alignement branches ; push **test** manuel si besoin).

### Vérification obligatoire — début d’exécution

Avant l’**étape 1** du workflow, **afficher et cocher** (dans la sortie de l’agent) :

1. **Anti-duplication agent `change-to-all-branches`** : je **n’ai pas** enchaîné l’agent **`/change-to-all-branches`** (déploiement **test**) dans le même run **pour le même objectif** pprod/prod **avant** l’étape 2, sauf exigence utilisateur documentée (flux test dédié).
2. **Prérequis `origin/test`** : le tip local **test** est déjà sur **`origin/test`**, ou j’indique qu’un push **hors** cet agent (**`/push-by-script`**, **`pousse.sh`**, etc.) est nécessaire avant de poursuivre.

Si l’utilisateur ou un autre processus **a** déjà aligné les branches distantes : **le signaler** ; l’**étape 2** (`--align-only`) reste à exécuter selon le playbook (idempotence gérée par les scripts).

### Vérification obligatoire — fin d’agent (avant clôture)

Cocher explicitement : **« Ordre anti-duplication : respecté (pas d’agent `/change-to-all-branches` complet en doublon pour le même objectif pprod/prod ; push **test** géré hors cet agent si requis) »** — ou documenter l’exception. Cocher : **« Corrections pprod/prod : si applicable, faites sur test puis workflow rejoué depuis étape 2 (aucun correctif applicatif « seulement pprod/prod ») »**. Cocher aussi : **« Lint min. 5 : exécuté sur repository_root + décompte avant/après (ou 0 diagnostic) ; pas de report seul sur /fix-lint »**.

## Multisite — projet **kogus** (monorepo LeCoffre ; code produit site `lecoffreio` inchangé)

Quand **`repository_root`** est le monorepo LeCoffre et **`deploy-by-script-to`** enchaîne **`deploy/scripts_v2/`**, l’orchestration doit couvrir **`notary`**, **`enso`**, **`genealogie`** (**`SITE_CODE`** ou **`deploy-site.sh`** / **`deploy-multisite-lines.sh`**) ; **`deploy-by-script-to`** ne définit pas **`SITE_CODE`**. Secrets : **`.secrets/<site>/<env>/`**. Doc : **`repository_root/docs/features/multi-site-architecture.md`** ; **`repository_root/.cursor/agents/agent-paths-registry.md`** §3 bis ; **`repository_root/.cursor/agents/deploy-pprod-or-prod.md`** § Multisite.

## Workflow obligatoire

1. **Vérifier la branche** : La machine doit être sur la branche **test** au démarrage. Si ce n'est pas le cas, indiquer à l'utilisateur de passer sur test (ou exécuter `git checkout test` depuis la racine projet) avant de continuer.

2. **Alignement branches (sans déploiement test)** :
   - **Prérequis** : **`origin/test`** porte le commit à déployer (commits locaux poussés **hors** cet agent : **`/push-by-script`**, **`./deploy/pousse.sh kogus`**, etc.). Si le clone **test** est en avance sur **`origin/test`**, **arrêter** et indiquer de pousser d’abord.
   - Depuis la racine ia_dev : **`./deploy/change-to-all-branches.sh [project_id] --align-only`** (**pas** d’appel **`deploy-multisite-lines.sh test`** / **`orchestrator.sh test`** dans cette étape).
   - **Ne pas** invoquer l’agent **`/change-to-all-branches`** ici : cet agent enchaîne le déploiement **test** ; pour un déploiement test complet, flux séparé **`/change-to-all-branches`**.
   - **Si KO :** Analyser la sortie (et **`logs/deploy_*.log`** si un outil amont les a alimentés). Toute correction sur le dépôt applicatif : **test** d’abord (voir section **Corrections découvertes sur pprod ou prod**), puis **au plus une** nouvelle exécution de l’**étape 2** dans le même run si l’échec est purement d’alignement Git ; sinon documenter et s’arrêter.
   - **Si OK :** Passer à l'étape 3.

3. **Lancer le script deploy-by-script-to** avec l’environnement en paramètre (`pprod` ou `prod`) :
   - Le script est lancé depuis la racine de ia_dev. Avec project_id (optionnel), MAIL_TO ou AI_AGENT_TOKEN le dépôt cible est celui de la conf (deploy.secrets_path). Lancer : `./deploy/deploy-by-script-to.sh [project_id] <pprod|prod>`.
   - **`deploy.host_stays_on_test: true`** dans `projects/<id>/conf.json` (LeCoffre : **true** dans `projects/kogus/conf.json`) : le clone applicatif reste sur **`test`** ; `deploy-by-script-to.sh` ne fait **pas** de `checkout` **pprod**/**prod** ni `reset --hard` sur ces branches ; le playbook **`deploy/scripts_v2`** aligne les remotes / **worktree** et enchaîne **les trois lignes** (**`orchestrator.sh`** ou **`deploy-multisite-lines.sh`**) — voir **`deploy/README.md`** du dépôt applicatif.
   - **Sinon :** le script fait en général : passage dans le dépôt du projet, `checkout` sur la branche paramètre, vérification que la base secrets attendue par le projet existe (**kogus** / monorepo LeCoffre : imbriquée **`.secrets/<site>/<env>/`**, voir **`repository_root/docs/features/multi-site-architecture.md`** — le seul plat **`.secrets/<env>/`** n’est pas le contrat nominal multisite), `reset --hard` sur **`origin/<branche>`**, déploiement (**orchestrateur** ou **`deploy-multisite-lines.sh`** / repli **`deploy.sh`**), puis **`checkout test`**.
   - **Si KO :** Analyser la sortie et les logs, identifier la cause. **Ne pas** se limiter à corriger sur la branche **pprod**/**prod** : retour **test**, corrections, push **hors** cet agent si besoin, puis **rejouer depuis l’étape 2** (**`change-to-all-branches.sh --align-only`**) **sans** relancer l’**étape 3** (**`deploy-by-script-to`**) dans le même run — section **Corrections découvertes sur pprod ou prod** et **§ Politique — une seule tentative de déploiement**. Un nouvel essai de **`deploy-by-script-to`** = **nouvelle** invocation **`/deploy-pprod-or-prod`**.
   - **Si OK :** Passer à l'étape 4.

4. **Branche test après l’étape 3 :** si **`deploy.host_stays_on_test`**, le clone est déjà sur **`test`**. Sinon, le script a remis **`test`** : vérifier que la branche courante est **`test`**.

5. **Lint min. 5 sur le dépôt applicatif** : Avant la clôture, se placer dans `repository_root` (`projects/<id>/conf.json`). Exécuter le lint dans **chaque** entrée de `build_dirs`. Si **N ≥ 1** diagnostics (erreurs+warnings) : corriger **au moins min(5, N)** dans **ce** run. **Interdit** de clôturer le point lint en renvoyant uniquement à un **`/fix-lint` ultérieur**. Documenter décompte avant/après. Si des fichiers sont modifiés : committer et pousser **hors** les étapes numérées de cet agent (**`./deploy/pousse.sh`**, **`/push-by-script`**, ou équivalent) avant de finaliser la clôture lorsque le dépôt n’est pas clean.

## 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). Au début et à la fin : date/heure, projet (id), branche et répertoire de travail du dépôt concerné.

## 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, affichage du texte du commit ou constat « rien à committer »). **Aucune exception** : même si une étape a échoué, la clôture complète est obligatoire. Lister les actions réalisées et non réalisées pour chaque point.