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

name	description	model	is_background
deploy-pprod-or-prod	Déploie vers pprod ou prod en suivant le workflow change-to-all-branches, deploy-by-script-to, puis push-by-script. Toute correction issue d’une phase pprod/prod se fait sur test puis le workflow est rejoué depuis change-to-all-branches. Paramètre obligatoire pprod ou prod.	inherit	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 build_dir de la conf — tout le périmètre à chaque fois, pas seulement le sous-projet modifié dans la session (ex. tâche front : lancer aussi le lint sur les autres build_dirs). 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é dans pousse/build sans changements ESLint 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 .cursor/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).

---

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 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 d'une étape, corriger (analyse des logs, corrections code/config/doc), relancer jusqu'à succès ou blocage nécessitant instruction utilisateur.

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

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 ; le premier push du cycle est en principe celui de l’étape 2 via /change-to-all-branches).
  2. Rejouer intégralement le workflow depuis l’étape 2 : /change-to-all-branches (push-by-script + change-to-all-branches.sh), puis étape 3 deploy-by-script-to vers la cible pprod ou prod, puis étapes 4 à 6 comme décrit ci-dessous.
• Si plusieurs cycles correction → alignement → déploiement sont nécessaires, chaque correction part toujours de test puis enchaîne étape 2 → 6 jusqu’à succès ou blocage utilisateur.

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 (tant que l’étape 2 ci-dessous existe dans ce fichier)
/push-by-script (branche test)	Lancer avant ce workflow seulement si /change-to-all-branches ne le lance pas aussi.	L’agent /change-to-all-branches exécute /push-by-script avant ./deploy/change-to-all-branches.sh (voir .cursor/agents/change-to-all-branches.md, checklist étape 5). Comme /deploy-pprod-or-prod appelle /change-to-all-branches à l’étape 2, interdit de lancer /push-by-script sur test séparément avant l’étape 2 de ce workflow.
/change-to-all-branches	Lancer avant ce workflow seulement si /deploy-pprod-or-prod (cible pprod ou prod) ne le lance pas aussi.	Ce fichier impose l’étape 2 « Lancer /change-to-all-branches ». Interdit de lancer /change-to-all-branches séparément avant de commencer ce workflow (sauf évolution documentée de ce fichier sans étape 2 ; dans ce cas seulement, enchaîner manuellement dans l’ordre push → change-to-all-branches → suite).

Si une future version de ce fichier supprime l’étape 2 : réévaluer le tableau (alors /change-to-all-branches peut être requis en amont, et /push-by-script reste couvert si /change-to-all-branches est inchangé côté ia_dev).

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 change-to-all-branches : je n’ai pas exécuté /change-to-all-branches complet en dehors de ce run immédiatement avant l’étape 2 (conforme : une seule exécution, celle de l’étape 2).
2. Anti-duplication push-by-script : je n’ai pas exécuté /push-by-script sur test uniquement pour préparer ce déploiement avant l’étape 2 (le premier push est celui inclus dans /change-to-all-branches à l’étape 2).

Si l’utilisateur ou un autre processus a déjà aligné / poussé : le signaler ; ne pas refaire /push-by-script ni /change-to-all-branches en amont par habitude — suivre quand même l’étape 2 (idempotence gérée par les scripts / l’agent change-to-all-branches).

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

Cocher explicitement : « Ordre anti-duplication : respecté (pas de /push-by-script ni /change-to-all-branches standalone avant l’étape 2 hors ce workflow) » — ou documenter l’exception si évolution du fichier sans étape 2. 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 ».

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. Lancer /change-to-all-branches (sur test) :

   • Exécuter intégralement l'agent change-to-all-branches (commande /change-to-all-branches) : push-by-script puis ./deploy/change-to-all-branches.sh.
   • Si KO : Analyser la sortie et les logs (logs/deploy_*.log), identifier la cause. Toute correction sur le dépôt applicatif : test d’abord (voir section Corrections découvertes sur pprod ou prod), puis relancer /change-to-all-branches jusqu'à succès.
   • Si OK : Passer à l'étape 3.

3. Lancer le script deploy-by-script-to avec la branche 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>.
   • Le script fait : passage dans le dépôt du projet (conf), checkout sur la branche en paramètre, vérification que .secrets/<env> existe, mise à jour forcée de la branche locale sur la branche distante, déploiement (orchestrateur ou deploy.sh ; flags métier via deploy.conf uniquement), 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, puis rejouer depuis l’étape 2 (/change-to-all-branches puis deploy-by-script-to) jusqu'à succès (section Corrections découvertes sur pprod ou prod).
   • Si OK : Passer à l'étape 4.

4. Checkout test : Le script remet déjà sur test. Vérifier que la branche courante est test après le script.

5. Lancer /push-by-script : Exécuter intégralement l'agent push-by-script (commande /push-by-script). Message de commit fourni par l'agent selon les règles du projet.

6. 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 : enchaîner /push-by-script (commit des corrections lint) 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 .cursor/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 .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 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.