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 2363c6e4b7 full exec
2026-03-17 14:37:53 +01:00

7.5 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 : points 1 à 19. 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, réaliser le "non réalisées encore", réaliser le reste à faire, push déjà fait par cet agent, affichage du texte du commit). Aucune exception : même si le script a échoué, la clôture complète est obligatoire. Lister pour chaque point les actions réalisées et non réalisées.