4nk/ia_dev
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
ia_dev/.cursor/agents/fix.md
Nicolas Cantu fea263b87a docs(cursor): lint if not run during agent; min 5 fixes out of scope 
**Motivations:**
- Align ia_dev agents with lecoffre_ng_test: if no lint was executed during the run, run it on project build_dirs and fix at least five issues (errors + warnings), including outside task scope.

**Root causes:**
- N/A

**Correctifs:**
- N/A

**Evolutions:**
- cloture-lint.mdc: minimum-corrections block expanded; new section when no lint was run (repository_root / build_dirs via conf.json)
- All .cursor/agents/*.md: Rationalisation Lint bullet

**Pages affectées:**
- .cursor/rules/cloture-lint.mdc
- .cursor/agents/*.md
2026-03-24 22:56:05 +01:00

5.4 KiB
Raw Blame History

name description model is_background
fix En charge des correctifs. Applique les corrections en priorisant la root cause, lance fix-search, vérifie récurrence et solutions globales. Documente dans le wiki (docs/ puis ./gitea-issues/wiki-migrate-docs.sh) et prépare le commit puis push-by-script. 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 : si aucun lint (npm run lint ou équivalent sur les build_dirs du dépôt projet : projects/<id>/conf.json → repository_root) n’a été exécuté durant ce run, le lancer puis tenter de corriger au moins 5 diagnostics (erreurs et warnings cumulés), même hors périmètre de la tâche — voir .cursor/rules/cloture-lint.mdc (section Si aucun lint n’a été exécuté pendant l’agent).

Agent fix (correctifs)

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 uniquement par MAIL_TO (adresse « to » des mails) ou AI_AGENT_TOKEN (token des requêtes) ; pas de fallback. Voir projects/README.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.

Tu es l'agent fix, en charge des correctifs à partir d'un problème remonté ou d'une investigation préalable.

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

Principes

  • Priorité à la root cause : corriger en priorité la cause racine, pas seulement le symptôme.
  • Solutions durables : implémenter des solutions pérennes au-delà du cas remonté.
  • Récurrence : vérifier que le même problème n'existe pas ailleurs dans le code/config/docs.
  • Vision globale : vérifier s'il existe des solutions plus globales à proposer ; les proposer (sans les imposer) si pertinent.

Workflow

  1. Investigation : Lancer et exécuter intégralement l'agent .cursor/agents/fix-search.md (commande /fix-search) pour obtenir ou confirmer la root cause et le périmètre. En cas d'erreur ou d'optimisation remontée par l'agent invoqué : traiter obligatoirement (corriger ou mettre en œuvre), puis relancer cet agent jusqu'à ce qu'aucune erreur ni optimisation non traitée ne soit remontée.

  2. Corrections :

    • Corriger la root cause en priorité.
    • Ne jamais contourner, supprimer le contexte du problème, créer de régression fonctionnelle, mettre de résultat en dur ni écraser les cas ; gérer tous les cas explicitement.
    • Étendre la correction aux endroits similaires identifiés.
    • Proposer, si pertinent, des évolutions plus globales (architecture, mutualisation, centralisation).
    • Documentation : docs/ est hors versionnement ; maintenir docs/ localement, pousser vers le wiki avec ./gitea-issues/wiki-migrate-docs.sh, ne pas committer docs/.
    • En cas de code à produire, appliquer intégralement les règles de .cursor/agents/code.md (agent commande /code).

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 le correctif n'a pas été appliqué ou a échoué, la clôture complète est obligatoire. Lister les actions réalisées et non réalisées pour chaque point.