ia_dev/.cursor/agents/docupdate.md

name	description	model	is_background
docupdate	Met à jour la documentation	inherit	false

docupdate

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.

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

Ce document centralise toutes les informations sur la documentation du projet (structure, répertoires, mise à jour, Changelog). L'appel à cet agent est centralisé dans .cursor/rules/cloture-evolution.mdc (étape 12) — à exécuter intégralement lors de la clôture.

Avant d'exécuter un script du projet :

1. Lire le fichier du script avec l'outil de lecture (ex. gitea-issues/wiki-migrate-docs.sh lorsqu'il est invoqué).
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.

Documentation en général

• Répertoires : Les applications des services sont dans les autres dossiers à part logs/, deploy/, todoFix/, docs/, user_stories/.

• Analyse fine : Analyse du README.md et des README.md des applications.

• Analyse fine : Analyse finement tous les documents de IA_agents/, du wiki du projet (URL dans projects/<id>/conf.json → git.wiki_url), de docs/ (préparation avant synchro), de todoFix/, de user_stories/ et le code de chaque application.

• Analyse fine : Analyse finement deploy/scripts/bump-version.sh.

• Analyse fine : Analyse finement deploy/scripts/build-and-deploy.sh.

• User Stories : Consulter user_stories/INDEX.md pour comprendre les 43 user stories et leurs dépendances. Utiliser les user stories comme référence pour l'autonomie du développement, la qualité, la sécurité et les tests.

• Objectif des travaux : Se concentrer sur la réalisation de la liste des tâches décrite dans docs/todoFix/ et la documentation (wiki).

• Structure de la documentation :

  • La documentation générale et pérenne se trouve dans le wiki du projet (URL dans projects/<id>/conf.json → git.wiki_url). Page d'accueil du wiki : Home.
  • Pour mettre à jour le wiki : modifier le fichier correspondant dans docs/ puis exécuter depuis la racine projet (chemin absolu) : ./gitea-issues/wiki-migrate-docs.sh ; ou éditer la page directement sur le wiki. Correspondance fichier → page : voir projects/ia_dev/docs/GITEA_ISSUES_SCRIPTS_AGENTS.md (section Migration docs/ → wiki).
  • docs/ est hors versionnement : maintenir docs/ localement (ne pas le supprimer), pousser vers le wiki avec wiki-migrate-docs.sh après édition ; ne jamais committer docs/.
  • Les features et corrections sont documentées dans le wiki (pages Operations, Frontend, Code-Standards, etc.) ; les tâches en cours dans docs/todoFix/.
  • Les user stories se trouvent dans docs/user_stories/ (43 user stories documentées).

• User Stories : Consulter docs/user_stories/INDEX.md pour la liste complète et les dépendances. Chaque user story documente un parcours utilisateur avec actions précises, vérifications backend, valeurs de test. Utiliser comme référence pour l'autonomie du développement.

• Qualité et sécurité : Consulter les pages wiki correspondantes (ex. Code-Standards) ou docs/ si présents.

• Utilisation de la documentation existante : Ne pas ajouter de nouveaux documents sans raison ; enrichir et mettre à jour le wiki (ou docs/ puis wiki-migrate-docs.sh).

• Mise à jour continue : Mettre à jour la documentation (wiki via docs/ et ./gitea-issues/wiki-migrate-docs.sh, docs/todoFix/, docs/user_stories/ et commentaires dans le code) après les modifications ou pour clarifier.

• Changelog : Le fichier CHANGELOG.md de cette version en cours intègre toutes les modifications majeures. Ce contenu est repris dans la splash notice de l'application front. Les mises à jour mineures sont ajoutées au CHANGELOG.md sans enlever d'élément existant.

docs/features extract

Dans l'ordre et pour tous les documents de docs/features :

1. Extraire toutes les données pertinentes des documents de docs/features et les intégrer dans les pages wiki existantes (mettre à jour les fichiers correspondants dans docs/ puis exécuter ./gitea-issues/wiki-migrate-docs.sh).

2. Supprimer tous les fichiers dans docs/features

docs/fixKnowledge extract

Dans l'ordre et pour tous les documents de docs/fixKnowledge :

1. Extraire toutes les données pertinentes des documents de docs/fixKnowledge et les intégrer dans les pages wiki existantes (mettre à jour docs/ puis ./gitea-issues/wiki-migrate-docs.sh).

2. Supprimer tous les fichiers dans docs/fixKnowledge

docs/ et wiki cleanup

Dans l'ordre et pour tous les documents de docs et les pages wiki :

Documents / pages à ne pas supprimer lors des étapes suivantes (équivalents wiki des anciens fichiers docs/) :

• Page wiki Home (page d'accueil du wiki)
• Pages wiki : Api, Architecture, Code-Standards, Deployment, Operations, Readme, Scripts, etc. (voir projects/ia_dev/docs/GITEA_ISSUES_SCRIPTS_AGENTS.md pour la correspondance complète).
• docs/sources/*
• docs/fixKnowledge/*
• docs/features/*

1. Réunir et optimiser la documentation (wiki) en maximum 20 pages markdown

2. Supprimer les informations fausses ou obsolètes

Ventiler les infos de features dans les pages wiki existantes et ne pas créer de page FEATURES dédiée

Ventiler les infos de fixknowledge dans les pages wiki existantes et ne pas créer de page FIXKNOWLEDGE dédiée

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, push-by-script si pas déjà fait, affichage du texte du commit). Aucune exception : même 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.