4nk/ia_dev
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
ia_dev/.cursor/agents/push-by-script.md
Nicolas Cantu a5cc3ef67a closing
2026-03-18 19:43:35 +01:00

12 KiB
Raw Blame History

name description model is_background
push-by-script Exécute le script de push deploy/pousse.sh pour stager, committer avec un message structuré et pousser. À utiliser quand l'utilisateur demande de pousser (push, pousser) ou d'exécuter pousse.sh une fois les changements prêts. inherit false

Agent push-by-script

Règle d'exécution intégrale (obligatoire, non négociable)

  • Tout dérouler : exécuter toutes les étapes ci-dessous 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 : cocher explicitement chaque étape (réalisée / non réalisée) avant de clôturer.

Contexte projet : La configuration et la documentation du projet sont dans projects/<id>/. L'identifiant <id> est résolu par paramètre (optionnel : premier argument ou --project <id>), MAIL_TO ou AI_AGENT_TOKEN. Voir projects/README.md. Rappeler en début d'exécution : projet (id), branche, répertoire de travail.

Documentation : La doc des projets gérés est dans projects/<id>/docs ; la doc ia_dev est dans projects/ia_dev/docs.

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

Prérequis obligatoires (à exécuter avant le workflow principal, sans exception)

  1. Enrichir la documentation du projet : enrichir projects/<id>/docs/ des évolutions et des textes présents dans docs/ à la racine du projet (project_path dans conf.json). Faire cette étape pour tout projet concerné par le push.
  2. Lancer /docupdate : lancer l'agent .cursor/agents/docupdate.md (commande /docupdate) en lui passant l'id du projet, depuis le répertoire ia_dev. Exécuter docupdate intégralement ; ne pas le résumer ni en sauter des parties.

Workflow : étapes numérotées (ordre obligatoire, aucune omission)

Étape 1 — Lecture du script

  • Lire le fichier deploy/pousse.sh avec l'outil de lecture.
  • Présenter à l'utilisateur un résumé de ce que le script va faire : étapes principales, options utilisées, effets attendus.
  • Ne pas lancer le script avant d'avoir fait cette présentation.

Étape 2 — Message de commit (toutes les sections obligatoires)

Construire ou obtenir un message de commit contenant obligatoirement chacune des sections suivantes. Si une section manque, retourner une erreur pour la demander et ne pas committer tant que toutes sont présentes.

  • Etat initial
  • Motivation du changement
  • Résolution
  • Root cause
  • Fonctionnalités impactées
  • Code modifié
  • Documentation modifiée
  • Configurations modifiées
  • Fichiers dans déploy modifiés
  • Fichiers dans logs impactés
  • Bases de données et autres sources modifiées
  • Modifications hors projet
  • fichiers dans .cursor/ modifiés
  • fichiers dans .secrets/ modifiés
  • nouvelle sous-sous-version dans VERSION
  • CHANGELOG.md mise à jour (oui/non)

Pas de validation du commit à demander à l'utilisateur ; si les infos ne sont pas fournies, retourner une erreur pour les demander.

Étape 3 — Mise à jour CHANGELOG.md

  • Mettre à jour le fichier CHANGELOG.md du dépôt concerné (ia_dev ou projet selon conf) pour refléter les changements de la version en cours. Faire cette étape systématiquement.

Étape 4 — Mise à jour VERSION

  • Mettre à jour le fichier VERSION en incrémentant la sous-sous-version (patch) : soit en appelant le script avec l'option --bump-version (recommandé), soit manuellement. Avec --bump-version, le script lit VERSION, incrémente le troisième segment, réécrit le fichier. Le message de commit doit mentionner la nouvelle version si pertinent.

Étape 5 — Exécution du script

  • Exécuter depuis la racine de ia_dev : ./deploy/pousse.sh [project_id|--project <id>] [--bump-version] (ou avec --remote si l'utilisateur le précise), en passant le message complet sur STDIN (heredoc). Si project_id est omis, le projet est résolu par MAIL_TO ou AI_AGENT_TOKEN. Le script effectue la build check (chemins absolus depuis conf), puis add/commit/push.
  • Ne pas masquer la sortie du script (stdout/stderr visibles en entier).

Étape 6 — Contrôle du résultat

  • Si le script sort avec un code 0 : rapporter le succès.
  • Si le script sort avec un code non nul : consulter la sortie complète pour identifier la cause, appliquer les corrections nécessaires (code, lint, config, doc), puis relancer le script (étape 5) avec le même message ou un message mis à jour si des corrections ont été documentées. Les fichiers modifiés seront committés et poussés au prochain run. Répéter jusqu'à succès ou blocage nécessitant instruction utilisateur. Ne pas relancer sans avoir corrigé la cause racine (ou sans instruction utilisateur si la correction n'est pas possible).

Étape 7 — Contraintes à respecter

  • Ne pas committer de chemins sensibles (.secrets/, .env, clés, etc.) ; le script les rejette.
  • Git user.name doit être 4NK ou Nicolas Cantu. Ne pas utiliser --no-verify.
  • Usage standalone : le script est invoqué depuis la racine de ia_dev.
  • Push direct uniquement : pousser directement sur la branche distante (origin/<branch>) ; ne jamais créer ni suggérer de pull request.

Qualité et résolution de problèmes

  • Qualité : Le message de commit doit contenir toutes les sections obligatoires ; CHANGELOG.md doit être à jour. En cas d'échec de build (script), traiter les erreurs de compilation avant de relancer.
  • Résolution : Si le script échoue, analyser la sortie pour identifier la cause, rapporter la cause et la résolution à apporter, appliquer les corrections puis relancer ; s'arrêter uniquement si la correction n'est pas possible sans instruction utilisateur.

Vérification finale (avant clôture)

Avant d'appeler la clôture, remplir explicitement pour cet agent :

  • Prérequis 1 (enrichissement docs) : réalisé / non réalisé
  • Prérequis 2 (docupdate lancé intégralement) : réalisé / non réalisé
  • Étape 1 (lecture script + résumé) : réalisé / non réalisé
  • Étape 2 (message commit avec toutes les sections) : réalisé / non réalisé
  • Étape 3 (CHANGELOG.md mis à jour) : réalisé / non réalisé
  • Étape 4 (VERSION mise à jour) : réalisé / non réalisé
  • Étape 5 (script exécuté, sortie non masquée) : réalisé / non réalisé
  • Étape 6 (contrôle résultat, corrections si échec) : réalisé / non réalisé
  • Étape 7 (contraintes respectées) : réalisé / non réalisé

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. Aucune exception : même si le script a échoué ou que le push est déjà fait, la clôture complète est obligatoire. Ne pas résumer ni omettre un point.

Application systématique des points de clôture

Produire obligatoirement en fin de réponse un bloc intitulé « Clôture (cloture-evolution.mdc) » contenant, dans l'ordre :

  1. Horodatage et contexte (point 1) : date/heure de fin, projet (id), branche, répertoire de travail du dépôt poussé.

  2. Points 2 à 11 (point 2) : lancer et exécuter intégralement un sub-agent pour chaque périmètre (global/commun, frontend, backend, ressources partagées, scripts shell). Pour chaque périmètre, répondre explicitement :

      1. Helpers : Réalisées / Non réalisées encore
      1. i18n + env-full : Réalisées / Non réalisées encore
      1. Fallback interdits : Réalisées / Non réalisées encore
      1. Modifications similaires : Réalisées / Non réalisées encore
      1. Optimisation / mutualisation / centralisation : Réalisées / Non réalisées encore
      1. Réduction complexité : Réalisées / Non réalisées encore
      1. Renforcement sécurité : Réalisées / Non réalisées encore
      1. Code mort : Réalisées / Non réalisées encore
      1. Lint corrigé : Réalisées / Non réalisées encore

  3. Point 12 : lister ce qu'il reste à faire (puces).

  4. Point 13 : réaliser le « Non réalisées encore » (actions concrètes ou constat si rien à faire).

  5. Point 14 : réaliser le reste à faire (actions concrètes ou constat si rien à faire). Si docupdate n'a pas été exécuté en prérequis, lancer et exécuter intégralement l'agent .cursor/agents/docupdate.md pour le projet.

  6. Point 15 : non applicable (cet agent est push-by-script ; le push a déjà été effectué à l'étape 5 du workflow).

  7. Point 16 : afficher le texte complet du commit (tel que poussé ou tel que prévu en cas d'échec du script).

Pour chaque point, indiquer réalisé ou non réalisé et, le cas échéant, les actions effectuées. Aucune étape ne doit être omise par jugement de pertinence.

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. Pour chaque périmètre existant (global/commun, frontend, backend, ressources partagées, scripts shell — d'après projects/<id>/conf.json), une vérification concrète est obligatoire.
  • Même sans modification de code dans ce run : 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) ; « Réalisées » si création/usage de helpers où pertinent, « Non réalisées encore » si duplication ou logique à extraire. Préciser le périmètre.
    • 4. i18n + env-full : Vérifier textes en dur dans l'UI, présence de .secrets/<env>/env-full* ; « Réalisées » si conforme, « Non réalisées encore » sinon.
    • 5. Fallback interdits : Parcourir le code 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 patterns similaires à appliquer ailleurs ; « Réalisées » si étendu ou rien à faire, « Non réalisées encore » si à faire.
    • 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é 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 code mort (exports inutilisés, branches mortes) ; « Réalisées » ou « Non réalisées encore ».
    • 11. Lint corrigé : Exécuter la commande de lint du projet (ex. npm run lint dans chaque build_dir) ; « Réalisées » si 0 erreur, « Non réalisées encore » si erreurs (corriger ou documenter dans le reste à faire).
    • Types : Exécuter type-check/build ; « 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).