ia_dev/.smartIde/agents/change-to-all-branches.md
Nicolas Cantu 49de4eea20 docs(multisite): remove enso line references and tighten SSH/read-only guidance
Update ia_dev agent playbooks and kogus docs to reflect two-line multisite (lecoffreio/genealogie), enforce SSH execution requirements in analyse mode, and refresh deployment/multisite documentation links.
2026-05-13 22:59:34 +02:00

120 lines
18 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
name: change-to-all-branches
model: inherit
description: Uniquement en test, lance /push-by-script puis deploy/change-to-all-branches.sh (alignement + déploiement test). Correctifs applicatifs sur test ; si contexte pprod/prod, voir deploy-pprod-or-prod (section corrections).
---
## 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.
# Agent change-to-all-branches
## 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 test par invocation
- **Tentative** : une exécution de **`./deploy/change-to-all-branches.sh [project_id]`** **sans** **`--align-only`** (le script enchaîne alignement + déploiement **test** multisite).
- **Par message utilisateur / ouverture dagent** : **au plus une** telle exécution ; si code de sortie **non nul**, **ne pas** relancer ce script dans le **même** run.
- **Après échec** : analyser sortie + **`logs/deploy_*.log`** ; **`/fix-lint`** puis **`/push-by-script`** autorisés pour corriger le dépôt — **sans** nouvelle exécution de **`change-to-all-branches.sh`** tant que lutilisateur na pas relancé explicitement **`/change-to-all-branches`**.
- **Alignement** : **`deploy-test-by-script.md`**, **`.smartIde/agents/deploy-by-script.md`**, **`.smartIde/agents/deploy-pprod-or-prod.md`** (même principe sur leurs commandes de déploiement).
**Checklist à cocher (dans l'ordre) :**
1. Contexte : rappeler projet (id) et `projects/<id>/`.
2. Lire `deploy/change-to-all-branches.sh`.
3. Présenter résumé (étapes, options, effets).
4. Vérifier branche du dépôt projet = **test** (sinon retour 1).
5. Exécuter **/push-by-script** (message fourni par l'agent).
6. Exécuter `./deploy/change-to-all-branches.sh [project_id]` (timeout long). **Sans** loption **`--align-only`** : le script enchaîne alignement **et** déploiement **test**. Loption **`--align-only`** (alignement uniquement) est réservée au workflow **`/deploy-pprod-or-prod`** — ne pas lutiliser pour clôturer **cet** agent si un déploiement **test** est attendu.
7. **En échec du script** : identifier la cause (sortie + **`logs/deploy_*.log`**). Si typecheck / lint / build : lancer **intégralement** l'agent **/fix-lint** pour le projet, puis **/push-by-script** — **ne pas** relancer **`./deploy/change-to-all-branches.sh [project_id]`** dans le même run (**§ Politique — une seule tentative de déploiement test**). Pour les autres causes (SSH, secrets, infra) : documenter et sarrêter sans nouvelle exécution du script dans ce run.
8. **Lint min. 5 avant clôture** : sur `repository_root`, lint **chaque** `build_dir` (tout le périmètre déclaré, pas seulement le sous-projet modifié dans la session) ; si **N ≥ 1**, corriger **au moins min(5, N)** dans **ce** run ; décompte avant/après. **Interdit** de clôturer en reportant seul sur un **`/fix-lint` ultérieur** sans ces corrections. **Interdit** dignorer des warnings/erreurs parce quils sont « préexistants » ou hors fichiers modifiés ce run : voir `.smartIde/rules/cloture-lint.mdc` — section **Diagnostics préexistants / hors périmètre de la session**. Si fichiers modifiés : **/push-by-script** avant clôture si le dépôt nest pas clean.
9. Clôture : points 1 à 16 de cloture-evolution.mdc (horodatage, 5 périmètres 3-11, 12-14, 15, 16).
---
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'identifiant `<id>` est résolu par **paramètre** (optionnel : `./deploy/change-to-all-branches.sh [project_id]`), **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`**.
**Rôle de lagent :** vérifier que la branche locale est test (sinon retour 1), fournir le message de commit (via /push-by-script), lancer le script, contrôler la sortie et le code de retour. **Rôle du script :** exécution déterministe (vérif branche test, `branch-align.sh test`, puis sauf **`--align-only`** : **`orchestrator.sh test --no-sync-origin`** ou, à défaut, **`bash deploy/scripts_v2/deploy-multisite-lines.sh test --no-sync-origin`** — **toujours les deux lignes** lecoffreio / genealogie lorsque le dépôt expose **`deploy-multisite-lines.sh`** ; repli historique **`deploy.sh test`** uniquement si ce script est absent). Flags métier via **`$SECRETS_BASE/<site>/test/deploy.conf`** (par ligne) ; journalisation **`./logs/deploy_*.log`**. Préparation OS : **`/setup-host`** + **`run-setup-host.sh`**, pas confondre avec le déploiement applicatif.
**Projet kogus (monorepo LeCoffre) :** si le script enchaîne **`deploy/scripts_v2`**, appliquer le contrat multisite (**`SITE_CODE`** / **`deploy-site.sh`** / **`deploy-multisite-lines.sh`**, secrets **`.secrets/<site>/<env>/`**) décrit dans **`repository_root/docs/features/multi-site-architecture.md`** et **`repository_root/.cursor/agents/agent-paths-registry.md`** §3 bis (les agents Cursor du dépôt applicatif sont sous **`.cursor/agents/`**, pas **`.smartIde`**).
**Branche applicative test-first (obligatoire) :** Toute correction de code, configuration ou documentation dans le **dépôt applicatif** (`repository_root` dans `projects/<id>/conf.json`) pendant lexécution de cet agent doit être réalisée sur la branche locale **test**. Avant toute modification : si le dépôt applicatif nest pas sur **test**, exécuter **`git checkout test`** (ou équivalent validé projet). **Interdit** : committer un correctif **uniquement** sur **pprod** ou **prod** depuis cet agent. Si léchec ou le contexte provient dune phase **pprod**/**prod** (correctifs identifiés après déploiement ou analyse sur ces branches), appliquer la procédure **Corrections découvertes sur pprod ou prod** dans `.smartIde/agents/deploy-pprod-or-prod.md` : correctifs sur **test**, pousser **hors** **`/deploy-pprod-or-prod`** si besoin, puis **nouvelle** invocation utilisateur de **`/deploy-pprod-or-prod`** (workflow depuis l**étape 2** ; **une** tentative de **`deploy-by-script-to`** par ouverture dagent — **§ Politique** dans le même fichier). **Ne pas** confondre avec lagent **`/change-to-all-branches`** (déploiement **test** multisite).
**Focus qualité et résolution de problèmes :**
- **Qualité :** Ne lancer le script qu'après un push-by-script réussi (message structuré, CHANGELOG à jour). **`/push-by-script`** ne compile pas : labsence de build dans ce flux nest pas un échec de push-by-script. En cas d'échec de push-by-script, traiter la cause (message manquant, script en erreur, etc.) avant de continuer.
- **Résolution de problèmes :** Si **`change-to-all-branches.sh`** échoue, analyser la sortie pour identifier la cause ; appliquer les corrections (**`/fix-lint`**, **`/push-by-script`**) **sans** relancer le script de déploiement test dans le même run (**§ Politique**).
- **Après échec du script (code de sortie non nul) :** 1) Cause dans la sortie et/ou **`logs/deploy_*.log`** ; 2) corrections sur le dépôt applicatif (**`repository_root`**, branche **test**, voir **Branche applicative test-first**) ; 3) **`/fix-lint`** puis **`/push-by-script`** si des fichiers ont été modifiés — **interdit** : relancer **`./deploy/change-to-all-branches.sh [project_id]`** dans la **même** ouverture dagent ; lutilisateur relance **`/change-to-all-branches`** pour un nouvel essai.
- **Échec npm sur le serveur (ENOENT, ENOTEMPTY, node_modules) :** Problème denvironnement cible. Documenter la sortie et **`logs/deploy_*.log`** ; **ne pas** relancer **`change-to-all-branches.sh`** dans ce run ; intervention manuelle ou nouvelle invocation utilisateur après correction infra.
- **Échec du build (TypeScript, lint, frontend/backend) :** 1) Extraire fichiers / erreurs depuis la sortie ou les logs. 2) **`/fix-lint`** intégralement pour le projet cible. 3) **`/push-by-script`** (ou **`./deploy/pousse.sh [project_id]`**) si des corrections ont été enregistrées. **Ne pas** enchaîner une seconde exécution de **`./deploy/change-to-all-branches.sh [project_id]`** dans le même run ; indiquer quun **nouvel** **`/change-to-all-branches`** est requis pour redéployer.
- **Logs et corrections :** Consulter la sortie du script et **`logs/deploy_*.log`**. Après échec : corrections + push possibles ; pas de nouvelle tentative de déploiement test sans nouvelle demande utilisateur.
**Avant d'exécuter un script du projet :**
1. Lire le fichier du script avec l'outil de lecture (ex. `deploy/change-to-all-branches.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.
Si la branche locale actuelle n'est pas test, retourner 1.
Uniquement en test (branche git), exécuter dans l'ordre :
1. **/push-by-script** — pousse directement sur la branche test distante (pas de pull request). Message de commit fourni par l'agent.
2. **Exécuter depuis la racine de ia_dev** : `./deploy/change-to-all-branches.sh [project_id]` — aligne origin/test, origin/pprod, origin/prod sur le SHA de test, puis déploie **test** en **multisite** (`orchestrator.sh` ou **`deploy-multisite-lines.sh test --no-sync-origin`** ; métier via **`deploy.conf`** par site ; logs **`./logs/`**). project_id optionnel. Push direct uniquement ; aucun PR. **Ne pas** passer **`--align-only`** pour cet agent (cette option saute le déploiement **test** ; elle est utilisée par **`/deploy-pprod-or-prod`** étape 2 uniquement).
- **Paramètres :** Arguments : **project_id** optionnel (ex. kogus), puis optionnellement **`--align-only`** (hors périmètre de **cet** agent). La branche git est toujours **test**. Si l'utilisateur fournit des tokens ambigus (ex. « test kogus »), extraire le **project_id** quand `projects/<id>/conf.json` existe : `./deploy/change-to-all-branches.sh kogus`.
- **Pas de timeout :** Ne pas lancer la commande avec un timeout court (ex. 5 min). Le déploiement (build, migrations, import-v1, redémarrage services, vérifications) peut durer 10 à 30 min ; utiliser un timeout long ou aucun timeout pour laisser le script aller au bout.
Retourner 0 en cas de succès. En cas d'échec d'une étape : consulter les logs (sortie du script, **`logs/deploy_*.log`**), identifier la cause. **Si la cause est typecheck / lint / build** : **`/fix-lint`** puis **`/push-by-script`** — **sans** relancer **`change-to-all-branches.sh`** dans le même run (**§ Politique — une seule tentative de déploiement test**). Pour les autres causes : documenter et s'arrêter ; nouvel essai de déploiement = **nouvelle** invocation **`/change-to-all-branches`**.
## 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 selon la référence en vigueur) sans en omettre aucun.
- **Point 1** : Horodatage au début et à la fin ; projet (id), branche, répertoire de travail ; au lancement et au retour de chaque sub-agent.
- **Point 2** : Lancer ou exécuter intégralement un sub-agent (ou une passée de checklist) pour **chaque** périmètre du projet cible : global/commun, frontend, backend, ressources partagées, scripts shell — et pour **chaque** périmètre répondre aux points 3 à 11 (Réalisées / Non réalisées encore).
- **Points 3 à 11** : Pour chaque point, indiquer explicitement « Réalisées » et « Non réalisées encore » (éventuellement par périmètre si pertinent).
- **Points 12 à 14** : Lister le reste à faire (12), réaliser le « Non réalisées encore » (13), réaliser le reste à faire (14).
- **Point 15** : Lancer /push-by-script si pas déjà fait (message structuré selon le format obligatoire).
- **Point 16** : Afficher le texte du commit.
Si un point est non applicable (ex. périmètre absent du projet, avec justification), le mentionner explicitement plutôt que de lomettre.
### Règles d'exécution des points 3 à 11 (obligatoires, pas de N/A de convenance)
- **Interdiction** : Ne jamais répondre « Réalisées : N/A » ou « Non réalisées encore : N/A » pour les points 3 à 11 sauf si le **périmètre n'existe pas** dans le projet (ex. projet sans frontend). Pour chaque périmètre existant (défini dans `projects/<id>/conf.json` : build_dirs, project_path), une **vérification concrète** est obligatoire.
- **Même sans modification de code** (ex. run limité à push + change-to-all-branches) : exécuter les vérifications ci-dessous sur le dépôt du projet et indiquer le résultat par périmètre (Réalisées avec précision, ou Non réalisées encore avec précision).
- **Vérifications concrètes obligatoires** :
- **3. Helpers** : Parcourir les zones concernées (fichiers modifiés ou build_dirs) ; indiquer « Réalisées » si création/usage de helpers où pertinent, « Non réalisées encore » si duplication ou logique à extraire en helper. Préciser le périmètre concerné.
- **4. i18n + env-full** : Vérifier textes en dur dans l'UI, présence des **`env-full-*`** sous **`.secrets/<site>/<env>/`** sur `LECOFFRE_REPO` ; « Réalisées » si conforme, « Non réalisées encore » sinon. Préciser.
- **5. Fallback interdits** : Parcourir le code (modifié ou périmètre) pour fallback, valeurs par défaut masquant des erreurs ; « Réalisées » si aucun, « Non réalisées encore » si présents.
- **6. Modifications similaires** : Vérifier s'il existe ailleurs dans le dépôt des patterns similaires à appliquer ; « Réalisées » si étendu ou rien à faire, « Non réalisées encore » si à faire. Préciser.
- **7. Optimisation / mutualisation / centralisation** : Vérifier duplication ou centralisation possible ; « Réalisées » ou « Non réalisées encore » avec précision.
- **8. Réduction complexité** : Vérifier complexité (longueur fichiers, imbrication) dans les zones concernées ; « Réalisées » ou « Non réalisées encore ».
- **9. Renforcement sécurité** : Vérifier exposition de données sensibles, validation des entrées ; « Réalisées » ou « Non réalisées encore ».
- **10. Code mort** : Vérifier présence de code mort (exports inutilisés, branches mortes) dans les zones concernées ; « Réalisées » ou « Non réalisées encore ».
- **11. Lint corrigé** : **Exécuter** `npm run lint` (ou la commande de lint du projet) dans **chaque** répertoire du périmètre (chaque build_dir : backend, frontend, ressources partagées — pas seulement un sous-ensemble). Comptabiliser **erreurs et warnings** dans la sortie. « Réalisées » **uniquement** si **0 erreur et 0 warning** pour ce périmètre. S'il reste des erreurs ou des warnings : « Non réalisées encore » en précisant le nombre d'erreurs et le nombre de warnings par répertoire (ex. « frontend : 0 erreur, 1004 warnings »). Ne jamais considérer le lint OK pour un projet si des warnings restent ; les traiter ou les documenter dans le reste à faire. Même règle pour tous les projets (backend, frontend, ressources).
- **Types** : **Exécuter** type-check/build du projet ; « Réalisées » si OK, « Non réalisées encore » sinon.
- **Compilation** : **Exécuter** le build ; « Réalisées » si succès, « Non réalisées encore » sinon.
- **Format de réponse** : Pour chaque point, écrire soit « Réalisées : [précision courte] », soit « Non réalisées encore : [précision courte] ». Interdit de laisser un point sans réponse ou avec uniquement « N/A » sans justification (périmètre inexistant).