4nk/ia_dev
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
ia_dev/.cursor/agents/docupdate.md
Nicolas Cantu 07e0341c1d Initial commit: ia_dev pilot repo, agents and deploy scripts 
**Motivations:**
- Provide a single repo for IA-driven piloting of all projects (agents, rules, deploy scripts).
- Reusable as git submodule; project-specific config in projects/ (no slug from submodule path).

**Evolutions:**
- Cursor agents: deploy-by-script, push-by-script, branch-align, fix, evol, fix-lint, fix-search, code, docupdate, gitea-issues-process, change-to-all-branches.
- Deploy scripts: pousse.sh (build_dirs from project config), bump-version.sh (version from project config), branch-align.sh, change-to-all-branches.sh.
- Project config schema in projects/README.md; lecoffreio.json as example.

**Pages affectées:**
- .cursor/agents/*.md, .cursor/rules/*.mdc, deploy/*.sh, projects/README.md, projects/lecoffreio.json, README.md, CLAUDE.md, config files.
2026-03-12 21:44:29 +01:00

5.6 KiB
Raw Blame History

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

docupdate

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/<slug>.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/<slug>.json → git.wiki_url). Page d'accueil du wiki : Home.
    • Pour mettre à jour le wiki : modifier le fichier correspondant dans docs/ puis exécuter ./gitea-issues/wiki-migrate-docs.sh ; ou éditer la page directement sur le wiki. Correspondance fichier → page : voir gitea-issues/README.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 gitea-issues/README.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, sans exception)

Appliquer intégralement .cursor/rules/cloture-evolution.mdc. Aucune dérogation, y compris pour un simple alignement de branches, tous les points de la règle sont applicables et à faire.