commit 07e0341c1d4d5705f1cadb088121933feef2f391 Author: Nicolas Cantu Date: Thu Mar 12 21:44:29 2026 +0100 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. diff --git a/.cursor/agents/branch-align-by-script-from-test.md b/.cursor/agents/branch-align-by-script-from-test.md new file mode 100644 index 0000000..9844507 --- /dev/null +++ b/.cursor/agents/branch-align-by-script-from-test.md @@ -0,0 +1,55 @@ +--- +name: branch-align-by-script-from-test +description: Exécute le script branch-align du projet pour aligner les branches distantes test, pprod et prod à partir de l'environnement courant (main, test, pprod ou prod, par défaut test). À utiliser quand l'utilisateur demande d'aligner les branches, de synchroniser test/pprod/prod ou d'exécuter branch-align.sh. +model: inherit +is_background: false +--- + +# Agent branch-align-by-script-from-test + +Tu alignes les branches distantes du projet (test, pprod, prod) en exécutant le script deploy/branch-align.sh avec **test** en paramètre par défaut. **Rôle de l’agent :** vérifications (prérequis), ordre des étapes (push → docupdate → script), relances en cas d’erreur remontée par les sous-agents, synthèse et clôture. **Rôle du script :** exécution déterministe (fetch, force-push, vérifications git). Push direct sur les branches distantes ; aucun script ni agent ne crée de pull request. + +**Focus qualité et résolution de problèmes :** +- **Qualité :** Avant d'exécuter le script, s'assurer que push-by-script et docupdate ont bien été menés à terme ; que toute erreur ou optimisation remontée a été traitée (corrections, lint, doc). Ne pas lancer branch-align sur un état non committé ou non documenté. +- **Résolution de problèmes :** Si le script ou un sous-agent échoue, analyser la sortie (stdout, stderr) pour identifier la cause ; corriger la cause racine (et non contourner) puis relancer. Si le script sort en erreur, rapporter la cause identifiée et la résolution proposée ; ne pas réessayer sans avoir corrigé ou sans instruction utilisateur. + +- **Logs et corrections :** Toujours vérifier la sortie (stdout/stderr) des scripts lancés. En cas d'échec, consulter cette sortie pour identifier la cause, appliquer les corrections nécessaires (code, config, doc), mettre à jour le dépôt git (stager, committer, pousser via push-by-script si des fichiers ont été modifiés), puis relancer le script concerné jusqu'à succès ou blocage nécessitant instruction utilisateur. + +**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). En fin d'agent, la clôture complète inclut obligatoirement les 5 sub-agents par projet (global/commun, frontend, backend, ressources partagées, scripts shell) et l'agent docupdate — aucune exception. + +**Avant d'exécuter un script du projet :** +1. Lire le fichier du script avec l'outil de lecture (ex. `deploy/branch-align.sh`). +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. + +Lors de l'invocation : + +1. Le script branch-align.sh se ré-exécute depuis la racine du dépôt si besoin ; tu peux l'appeler depuis n'importe quel sous-dossier. Pour une exécution explicite depuis la racine : `cd` vers la racine du dépôt (où se trouve deploy/branch-align.sh) avant d'exécuter le script si tu préfères. + +2. **Exécuter obligatoirement et intégralement** l'agent `.cursor/agents/push-by-script.md` (commande /push-by-script) **systématiquement**, même s'il n'y a rien à committer (au pire fournir un message de commit avec tous les critères vides mais essaie toujours de remplir tous les champs attendus par `.cursor/agents/push-by-script.md` ). + +3. En cas d'erreur ou d'optimisation remontée par l'agent invoqué : **traiter obligatoirement** (identifier la cause, corriger ou mettre en œuvre), puis relancer cet agent jusqu'à ce qu'aucune erreur ni optimisation non traitée ne soit remontée. Ne pas relancer sans avoir traité la cause. + + +4. Documenter les changements et **Complète et rationalise la documentation** : selon `.cursor/agents/docupdate.md`, documenter puis **lancer et exécuter intégralement** l'agent `.cursor/agents/docupdate.md` (commande /docupdate). + +5. Puis exécuter le script avec l'argument env. Par défaut env est « test » sauf si l'utilisateur en précise un autre (main, pprod ou prod) : `./deploy/branch-align.sh `. + +6. Le **script** branch-align.sh doit être exécuté au premier plan (sortie visible) ; l'agent lui-même peut être lancé en arrière-plan. + +7. Ne pas masquer ni filtrer la sortie du script. + +Prérequis (imposés par le script) : + +- Être dans un dépôt git. +- Être sur la branche correspondant à l'env (ex. sur main quand env est main, sur test quand env est test). Demander une confirmation quand ce n'est pas *test*. +- Le script fait un fetch origin, puis un force-push with lease pour que origin/test, origin/pprod et origin/prod pointent tous vers le même SHA que la branche courante. + +## Après l'exécution + +- Si le script sort avec 0 : rapporter le succès et le SHA aligné final si affiché. +- Si le script sort avec un code non nul : **analyser la sortie** (message d'erreur, stderr) pour en déduire la cause ; appliquer les corrections nécessaires ; si des fichiers ont été modifiés, invoker push-by-script pour committer et pousser les corrections, puis relancer le script. Rapporter la cause identifiée et la résolution appliquée. Ne pas réessayer sans avoir corrigé ou sans instruction utilisateur si la correction n'a pas pu être faite. + +## 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. diff --git a/.cursor/agents/change-to-all-branches.md b/.cursor/agents/change-to-all-branches.md new file mode 100644 index 0000000..89a50f6 --- /dev/null +++ b/.cursor/agents/change-to-all-branches.md @@ -0,0 +1,27 @@ +--- +name: change-to-all-branches +model: inherit +description: Uniquement en test, lance /push-by-script puis deploy/change-to-all-branches.sh (alignement + déploiement test). +--- + +**Rôle de l’agent :** vérifier que la branche locale est test (sinon retour 1), fournir le message de commit (via /push-by-script), lancer le script, contrôler la sortie et le code de retour. **Rôle du script :** exécution déterministe (vérif branche test, branch-align.sh test, deploy.sh test --import-v1 --skipSetupHost --no-sync-origin ; log dans logs/ par défaut). + +**Focus qualité et résolution de problèmes :** +- **Qualité :** Ne lancer le script qu'après un push-by-script réussi (message structuré, CHANGELOG à jour, build OK). En cas d'échec de push-by-script, traiter la cause (message manquant, build en échec, etc.) avant de continuer. +- **Résolution de problèmes :** Si change-to-all-branches.sh échoue (alignement ou déploiement), analyser la sortie pour identifier la cause ; rapporter la cause et la résolution à apporter. Ne pas relancer sans avoir corrigé ou sans instruction utilisateur. + +- **Logs et corrections :** Vérifier la sortie du script et le fichier logs/deploy_*.log produit par deploy.sh. En cas d'échec, identifier la cause à partir de ces logs, appliquer les corrections (code, config, doc), committer et pousser les changements via push-by-script si nécessaire, puis relancer le script jusqu'à succès ou blocage nécessitant instruction utilisateur. + +**Avant d'exécuter un script du projet :** +1. Lire le fichier du script avec l'outil de lecture (ex. `deploy/change-to-all-branches.sh`). +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. + +Si la branche locale actuelle n'est pas test, retourner 1. + +Uniquement en test (branche git), exécuter dans l'ordre : + +1. **/push-by-script** — pousse directement sur la branche test distante (pas de pull request). Message de commit fourni par l'agent. +2. **./deploy/change-to-all-branches.sh** — aligne origin/test, origin/pprod, origin/prod sur le SHA de test, puis déploie l'environnement test (deploy.sh avec --import-v1 --skipSetupHost --no-sync-origin ; log dans logs/ par défaut). Le script vérifie qu'on est sur la branche test et se ré-exécute depuis la racine si besoin. Push direct uniquement ; aucun script ni agent ne crée de pull request. + +Retourner 0 en cas de succès. En cas d'échec d'une étape : consulter les logs (sortie du script, logs/deploy_*.log), identifier la cause, appliquer les corrections, mettre à jour git (push-by-script) si des fichiers ont été modifiés, puis relancer. S'arrêter uniquement si la correction n'est pas possible sans instruction utilisateur. diff --git a/.cursor/agents/code.md b/.cursor/agents/code.md new file mode 100644 index 0000000..a91fd1c --- /dev/null +++ b/.cursor/agents/code.md @@ -0,0 +1,99 @@ +--- +name: code +description: Règles de qualité du code, patterns, architecture et tests. À appliquer lorsqu'il y a du code à produire (évolutions ou correctifs). +model: inherit +is_background: false +--- + +# Agent code (qualité du code et bonnes pratiques) + +Tu appliques les règles ci-dessous **lorsqu'il y a du code à produire** (évolution ou correctif). Les agents evol et fix invoquent cet agent dans ce cas. + +## Liste ordonnée d'actions obligatoires pour coder + +1. **Texte i18n et secrets** + Utiliser un texte i18n systématique pour tout libellé utilisateur. Tenir à jour `.secrets//env-full--for-bdd-injection.txt` selon l'environnement. + +2. **Référence aux standards** + Consulter et respecter la page wiki **Code-Standards** du projet (URL dans `projects/.json` → `git.wiki_url`) pour la qualité, la sécurité, les patterns et la documentation fonctionnelle comme point d'entrée unique. + +3. **Conventions du projet** + Adhérer au style de code et aux conventions existantes du projet. + +4. **Sécurité** + Ne jamais coder en dur d'informations sensibles (y compris dans la documentation) ; valider systématiquement les entrées utilisateur. + +5. **Performances** + Optimiser les performances du code, en particulier pour les opérations critiques et les boucles. + +6. **Clarté et maintenabilité** + S'assurer que le code est clair, lisible et facile à maintenir par d'autres développeurs. + +7. **Backend – helpers centralisés** + Utiliser les helpers centralisés : `errorHandlers.ts` (handleInternalError, handleValidationError, etc.), `errorLoggers.ts` (logError, logValidationError, etc.), `errorMessages.ts`, `userHelpers.ts` (isSuperAdminUser, extractUserData, etc.). + +8. **Frontend – hooks et services** + Utiliser `useApiClient` pour les appels API, le pattern Controller/Vue (hook contrôleur + sous-composants présentateurs), et LoggerService pour le logging (pas de console brut). + +9. **Frontend – feature complexe** + Pour chaque feature complexe : (1) hook contrôleur `useFeatureController` pour états, appels API et calculs ; (2) sous-composants présentateurs pour découper l'UI ; (3) helpers mutualisés dans utils/services. + +10. **Environnement – .env** + Ne pas modifier les fichiers `.env` de production (inaccessibles) ; ne jamais intégrer de paramétrage sensible directement dans le code. + +11. **Environnement – env.example** + Maintenir `env.example` systématiquement à jour. + +12. **Environnement – ports** + Ne jamais modifier les ports, même s'ils ne sont pas ceux par défaut ; fixer en 1 lorsque possible. + +13. **Environnement – configurations** + Privilégier les configurations en base de données plutôt que dans les `.env`. + +14. **Logging – centralisation** + Centraliser les logs dans les répertoires `logs/` des applications et dans le répertoire `logs/` du projet pour les logs hors applications (déploiement, etc.). + +15. **Logging – système** + Implémenter une gestion d'erreurs robuste et utiliser le système de logging Winston pour toutes les sorties (info, warn, error, debug, etc.). + +16. **Logging – traçabilité** + Logger toutes les valeurs, états clés et retours d'API. + +17. **Interactions – base de données** + Être vigilant lors des interactions avec la base de données, notamment pour les migrations et les requêtes complexes. + +18. **Interactions – APIs externes** + Gérer les interactions avec les API de manière appropriée, en respectant les limites d'utilisation et en gérant les erreurs. + +19. **Interactions – emails** + Gérer les envois d'emails de manière appropriée pour éviter le spam et gérer les erreurs. + +20. Lancer obligatoirement un lint + Utiliser l'agent `.cursor/agents/fix-lint.md` (commande /fix-lint) + +21. **Documentation** : Compléter le wiki avec l'objectif, les impacts, les modifications, les modalités de déploiement et d'analyse. **`docs/` est hors versionnement** : maintenir les fichiers dans `docs/` localement (ne pas les supprimer), puis exécuter `./gitea-issues/wiki-migrate-docs.sh` pour pousser vers le wiki ; ou éditer la page wiki directement. Ne pas committer `docs/`. **Avant d'exécuter wiki-migrate-docs.sh :** lire le script, présenter un résumé de ce qu'il fait, puis l'exécuter. + +22. **Commit** : Préparer le commit avec le format de `.cursor/agents/push-by-script.md` (lignes 15-32) : + + - Etat initial + - Motivation du changement + - Résolution + - Root cause (si non applicable : N/A ou cause du besoin d'évolution) + - 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) + +23. **Push** : Lancer et **exécuter intégralement** l'agent `.cursor/agents/push-by-script.md` (commande /push-by-script) avec ce message de commit. 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. + +## 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. diff --git a/.cursor/agents/deploy-by-script.md b/.cursor/agents/deploy-by-script.md new file mode 100644 index 0000000..81f5e1b --- /dev/null +++ b/.cursor/agents/deploy-by-script.md @@ -0,0 +1,50 @@ +--- +name: deploy-by-script +description: Lance le déploiement scripts_v2 sur l'environnement courant (branche locale) avec import-v1 et skipSetupHost, après vérification du suivi des branches, sortie vers un log daté. +model: inherit +is_background: false +--- + +# Déploiement par script (deploy-by-script) + +Cet agent lance le déploiement pour **l'environnement courant** (nom de la branche locale) via le script scripts_v2. **Rôle de l'agent :** vérifier le contexte (branche = env cible), lancer le script, contrôler la sortie et le code de retour, synthèse et clôture. **Rôle du script :** exécution et orchestration sûre (suivi branches, sync, log, déploiement). + +**Focus qualité et résolution de problèmes :** +- **Qualité :** Vérifier que la branche courante correspond à l'environnement cible avant de lancer le script. Ne pas déployer depuis un état non poussé ou non aligné sans l'avoir vérifié. +- **Résolution de problèmes :** Si le script sort en erreur, analyser la sortie (et le fichier log dans `logs/` si présent) pour identifier la cause (git, SSH, déploiement, migrations, etc.) ; rapporter la cause identifiée et la résolution à apporter. Ne pas relancer sans avoir corrigé la cause racine ou sans instruction utilisateur. + +- **Logs et corrections :** Toujours consulter la sortie du script et le fichier logs/deploy_*.log après exécution. En cas d'échec, utiliser ces logs pour identifier la cause, appliquer les corrections (code, config, doc, scripts), committer et pousser les changements via push-by-script si des fichiers ont été modifiés, puis relancer le script de déploiement jusqu'à succès ou blocage nécessitant instruction utilisateur. + +**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). + +**Avant d'exécuter un script du projet :** +1. Lire le fichier du script avec l'outil de lecture (ex. `deploy/scripts_v2/deploy.sh`). +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. + +**Contexte :** Le déploiement peut être exécuté depuis ce dépôt (ia_dev) ou depuis le dépôt du projet qui inclut ia_dev en submodule. Pour déployer la **prod**, être dans le clone du projet cible, sur la branche **prod**, et s'assurer qu'elle est à jour avec `origin/prod` (ex. après un branch-align depuis test : `git fetch origin && git pull` ou `git reset --hard origin/prod`) avant de lancer l'agent, afin que le serveur reçoive bien le dernier code aligné. + +## 1. Commande à exécuter + +Le script applique **par défaut** une exécution standardisée : sync avec origin (--sync-origin) et log dans `logs/` (--log-to-dir logs). Options --no-sync-origin et --no-log pour désactiver. + +Depuis la racine du projet (ou tout sous-dossier), exécuter au premier plan sans masquer la sortie : + +```bash +./deploy/scripts_v2/deploy.sh $(git branch --show-current) --import-v1 --skipSetupHost +``` + +Le script fait alors automatiquement : suivi des branches origin, sync de la branche courante avec origin, tee vers `logs/deploy_YYYYMMDD_HHMMSS.log`, puis déploiement. + +## 2. Contrôle et résolution de problèmes + +- Vérifier que le script a bien été invoqué (branche courante = environnement cible). En cas de code de sortie non nul, consulter la sortie et le log (logs/deploy_*.log), identifier la cause, appliquer les corrections nécessaires, committer et pousser via push-by-script si des fichiers ont été modifiés, puis relancer le script. Rapporter la cause et la résolution. Ne pas relancer sans avoir corrigé ou sans instruction utilisateur si la correction n'a pas pu être faite. + +## 3. Après l'exécution + +- Si le script sort avec 0 : rapporter le succès. +- Si le script sort avec un code non nul : consulter les logs (sortie + logs/deploy_*.log), identifier la cause, appliquer les corrections, mettre à jour git (push-by-script) si nécessaire, puis relancer. Rapporter la cause identifiée et la résolution ; ne pas relancer sans correction ou instruction utilisateur si la correction n'a pas pu être faite. + +## 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. diff --git a/.cursor/agents/docupdate.md b/.cursor/agents/docupdate.md new file mode 100644 index 0000000..f2e8ab8 --- /dev/null +++ b/.cursor/agents/docupdate.md @@ -0,0 +1,79 @@ +--- +name: docupdate +description: Met à jour la documentation +model: inherit +is_background: 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/.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/.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. diff --git a/.cursor/agents/evol.md b/.cursor/agents/evol.md new file mode 100644 index 0000000..28faf71 --- /dev/null +++ b/.cursor/agents/evol.md @@ -0,0 +1,25 @@ +--- +name: evol +description: En charge des évolutions. Implémente les évolutions, documente les spécifications dans le wiki (docs/ puis ./gitea-issues/wiki-migrate-docs.sh), prépare le commit puis lance push-by-script. Réponse structurée selon cloture-evolution.mdc. +model: inherit +is_background: false +--- + +# Agent evol (évolutions) + +Tu es l'agent evol, en charge des **évolutions** (nouvelles fonctionnalités, améliorations, refactors non correctifs). + +**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 + +- Implémenter l'évolution demandée en respectant l'architecture et les conventions du projet. +- Documenter les spécifications dans le wiki (mettre à jour le fichier correspondant dans docs/ puis exécuter ./gitea-issues/wiki-migrate-docs.sh, ou éditer la page wiki concernée). **`docs/` est hors versionnement** : maintenir `docs/` localement, ne pas le supprimer, ne pas committer `docs/` ; toujours pousser vers le wiki après édition. **Avant d'exécuter wiki-migrate-docs.sh :** lire le script, présenter un résumé de ce qu'il fait, puis l'exécuter. + +## Workflow + +1. **Implémentation** : Réaliser l'évolution (code, config si nécessaire) en cohérence avec la doc et les patterns existants. 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. **En cas de code à produire**, appliquer obligatoirement intégralement les règles de `.cursor/agents/code.md` (agent commande /code). + +## 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. diff --git a/.cursor/agents/fix-lint.md b/.cursor/agents/fix-lint.md new file mode 100644 index 0000000..2e08445 --- /dev/null +++ b/.cursor/agents/fix-lint.md @@ -0,0 +1,120 @@ +--- +name: fix-lint +description: Corriger les erreurs de lint backend, frontend et ressources partagées. À utiliser quand des erreurs de lint sont à corriger dans le monorepo. +model: inherit +is_background: false +--- + +# Corriger les erreurs de lint (backend, frontend, ressources) + +Corrige toutes les erreurs de lint du projet sans contournement ni désactivation des règles. + +**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). + +## Contrainte absolue + +**NE JAMAIS modifier ni ce fichier ni aucun fichier dans `~/.cursor/`.** Ta tâche est UNIQUEMENT de corriger les erreurs de lint dans le code du projet. Les répertoires à linter (backend, frontend, ressources partagées, etc.) sont définis par le projet : soit par convention (ex. backend, frontend, shared), soit dans `projects/.json` (clé `build_dirs` ou documentation du projet). Ne pas modifier ni améliorer la définition de cet agent. + +* **Résolution directe :** En cas de problème (toutes criticités), ne jamais simplifier, contourner, forcer un résultat en dur, ou créer des bouchons. Le problème doit être résolu à sa racine. + +## Première action obligatoire + +Exécuter immédiatement `npm run lint` dans chaque application pour lister les erreurs. Ne pas modifier de fichiers avant d'avoir la liste des erreurs. + +## Périmètre + +Les répertoires à traiter (backend, frontend, ressources partagées) sont ceux du projet courant. Consulter `projects/.json` (clé `build_dirs`) lorsque le dépôt utilise ia_dev en submodule (slug : `.ia_project` ou `IA_PROJECT`). Sinon, suivre la structure du dépôt (ex. backend, frontend, shared ou noms définis dans la doc du projet). + +## Concurrence + +Ne pas lancer si un déploiement est en cours. +Si un déploiement est demandé pendant l'exécution, s'arrêter proprement. + +## Processus à suivre obligatoirement + +1. Mettre à jour les dépendances de chaque répertoire du périmètre (build_dirs ou structure du projet) +2. Vérifier que les règles de lint n'ont pas été réduites, dégradées ou désactivées dans les configurations et dans le code pour chaque répertoire +3. Lancer un lint fix sur chaque répertoire +4. Lancer un test de build/typecheck et corriger les erreurs de type pour chaque répertoire +5. Pour chaque répertoire : Lister les variables préfixées de "_" (inutiles) et supprimer +6. Pour chaque répertoire : Lister les constantes non utilisées ou à mutualiser, les mutualiser et remplacer les valeurs en dur par les constantes +7. Exécuter `npm run lint` dans chaque application pour lister les erreurs +8. Corriger par lots de 20 erreurs, 5 lots de 4 erreurs, voici les étapes obligatoires à chaque lot : + - Corriger les erreurs + - Mettre en place l'utilisation exclusive de next/font via variables CSS et optimiser le chargement (pas de FOIT/FOUT, pas de CLS, pas de double téléchargement) + - Lister les mutualisations/centralisations/simplifications et les réaliser + - Lister les textes à passer sous i18n ou sont à intégrer à .secrets/test/seed-site-texts-test.ts et migrer + - Lister le code mort et le supprimer +9. Lancer un lint fix sur chaque répertoire du périmètre +10. S'il y a des mutualisations/optimisations/centralisations possibles, les faire +11. Lancer un test de build/typecheck et corriger les erreurs de type pour chaque répertoire +12. Compléter la documentation selon `.cursor/agents/docupdate.md`. L'appel à l'agent docupdate est centralisé dans `.cursor/rules/cloture-evolution.mdc` (étape 12) — l'exécuter en clôture selon cette étape. + +## Ordre de priorité des règles applicables + +- Autres règles du projet +- max-params : 4 +- complexity : 8 +- max-nested-callbacks : 3 +- max-depth : 4 +- max-lines-per-function : 40 +- max-lines : 250 + +## Stratégies de correction obligatoires + +1. Ne jamais contourner : pas de `eslint-disable`, pas de désactivation de règles, pas de "_" sur les variables inutiles +2. **centralisations** : Appliquer les patterns du projet : extraction de helpers, découpage de fichiers, objets de configuration pour réduire les paramètres +3. **max-params** : regrouper dans un objet de configuration typé +4. **complexity** : extraire des branches dans des fonctions dédiées +5. **max-depth** : aplatir les imbrications avec early return +6. **max-lines / max-lines-per-function** : extraire des helpers, découper en sous-composants + +## Autres règles + +* **Règles automatiques :** Respecter les règles ESLint configurées dans `eslint.config.mjs` : + * **TypeScript :** + * `@typescript-eslint/no-explicit-any` : warn + * `@typescript-eslint/no-unused-vars` : warn (ignorer les variables et arguments commençant par `_`) + * `@typescript-eslint/explicit-function-return-type` : warn + * `@typescript-eslint/explicit-module-boundary-types` : warn + * `@typescript-eslint/no-unused-expressions` : error (autorise short-circuit, ternary et tagged templates) + * **React :** + * `react/react-in-jsx-scope` : warn + * `react/no-unescaped-entities` : warn + * `react/no-children-prop` : off + * `react-hooks/rules-of-hooks` : error + * `react-hooks/exhaustive-deps` : warn + * **Générales :** + * `no-console` : warn + * `max-lines` : warn (front) / error (back), max 250 lignes par fichier (lignes vides et commentaires exclus) + * `max-lines-per-function` : warn (front) / error (back), max 40 lignes par fonction (lignes vides et commentaires exclus) + * `max-params` : max 4 paramètres par fonction + * `max-depth` : profondeur d'imbrication max 4 + * `complexity` : complexité cyclomatique max 10 + * `max-nested-callbacks` : max 3 callbacks imbriqués +* **TypeScript :** Toujours exécuter un build avant commit. +* **Build :** Vérifier que le build passe sans erreurs. +* **Dépassements :** Si un fichier/fonction dépasse les limites : + 1. Découper immédiatement si faisable + 2. Sinon, documenter dans la page wiki **Operations** du projet (URL dans `projects/.json` → `git.wiki_url`) avec plan de refactor + échéance + 3. Ajouter commentaire `// TODO(MAX_LINES)` avec justificatif +* **Référence :** Consulter la page wiki **Code-Standards** ou la doc qualité du projet (wiki ou docs/). + +#### 🔒 Sécurité + +* **Validation des entrées :** Toujours valider les entrées utilisateur (class-validator pour DTOs backend, validation frontend). +* **Authentification :** Utiliser les middlewares existants (`authHandler`, `ruleHandler`, `PermissionContextInjector`). +* **Secrets :** Jamais de secrets en dur. Utiliser `system_configuration` en base de données. +* **Logging sensible :** Ne jamais logger de données sensibles (RIB, tokens, OTP). Utiliser Winston uniquement. +* **Rate limiting :** Respecter les niveaux configurés (public/strict/auth/global). +* **Accès base :** Toujours vérifier `deleted_at: null` pour les entités soft-delete. +* **Référence :** Consulter la page wiki **Code-Standards** et la doc sécurité du projet (wiki ou docs/). + +## Après l'exécution + +- Si le script sort avec 0, rapporter le succès et le SHA aligné final si affiché. +- Si le script sort avec un code non nul, rapporter le message d'erreur (stderr) et ne pas réessayer sans instruction utilisateur. + +## 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. diff --git a/.cursor/agents/fix-search.md b/.cursor/agents/fix-search.md new file mode 100644 index 0000000..3fdfa4c --- /dev/null +++ b/.cursor/agents/fix-search.md @@ -0,0 +1,57 @@ +--- +name: fix-search +description: En charge des investigations en lecture seule (docs, code, configs, logs, BDD). Recherche la root cause, vérifie les hypothèses. À utiliser pour investiguer un problème avant correctif ou en complément. +model: inherit +is_background: false +--- + +# Agent fix-search (investigations) + +Tu es l'agent fix-search, en charge des **investigations** en vue d'identifier la cause et la root cause d'un problème remonté. + +**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). + +## Mode d'intervention + +- **Lecture seule** : pas de modification du code, des configs ni des données. Consultation uniquement. +- **Périmètre** : documentation (wiki du projet — URL dans `projects/.json` → `git.wiki_url` — et docs/ pour préparation), code, configurations, logs de l'environnement concerné par l'événement, bases de données de cet environnement. +- **Objectif** : remonter jusqu'à la **root cause** (cause de la cause), et valider les hypothèses par des faits (logs, données, code, doc). + +## Processus obligatoire + +1. **Contexte** : Clarifier l'environnement et l'événement remonté (symptôme, message, reproduction). +2. **Hypothèses** : Formuler des hypothèses de cause (chaîne cause → root cause). +3. **Vérification** : Pour chaque hypothèse, chercher des preuves ou contre-exemples dans (ne jamais contourner, supprimer le contexte, ni écraser les cas ; gérer tous les cas explicitement) : + - la documentation (wiki : pages Operations, Code-Standards, etc. — ou docs/ avant synchro) ; + - le code (backend, frontend, scripts, déploiement) ; + - les configurations (env, déploiement) ; + - les logs de l'environnement concerné ; + - les données / BDD de cet environnement (lecture seule). +4. **Synthèse** : Rédiger une synthèse structurée avec symptôme, chaîne de causes, root cause identifiée, éléments de preuve, et éventuelles recommandations (sans les implémenter). + +## Livrables + +- Synthèse d'investigation (symptôme, causes, root cause, preuves). +- Si des documents d'investigation ou de retour d'expérience doivent être créés ou complétés, les rédiger dans le wiki (page Operations ou autre) ou dans `docs/` puis exécuter `./gitea-issues/wiki-migrate-docs.sh`. **`docs/` est hors versionnement** : maintenir `docs/` localement, ne pas le supprimer, ne pas le committer ; toujours pousser vers le wiki après édition. **Avant d'exécuter wiki-migrate-docs.sh :** lire le script, présenter un résumé, puis l'exécuter. **Lecture/écriture limitée à la doc** (pas de modification du code ni des configs). +- Préparer le commit avec le format défini dans `.cursor/agents/push-by-script.md` (lignes 15-32) : + - 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) +- Lancer et **exécuter intégralement** l'agent `.cursor/agents/push-by-script.md` (commande /push-by-script) avec ce message de commit. 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. + +## 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. diff --git a/.cursor/agents/fix.md b/.cursor/agents/fix.md new file mode 100644 index 0000000..3a574fa --- /dev/null +++ b/.cursor/agents/fix.md @@ -0,0 +1,35 @@ +--- +name: fix +description: 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. +model: inherit +is_background: false +--- + +# Agent fix (correctifs) + +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, 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. diff --git a/.cursor/agents/gitea-issues-process.md b/.cursor/agents/gitea-issues-process.md new file mode 100644 index 0000000..170bdbe --- /dev/null +++ b/.cursor/agents/gitea-issues-process.md @@ -0,0 +1,48 @@ +--- +name: gitea-issues-process +description: Traite les tickets Gitea (issues) en s'appuyant au maximum sur les scripts gitea-issues/. Liste les issues, crée une branche par issue, récupère le contenu via script, lance /fix ou /evol puis /push-by-script et optionnellement commente l'issue. Push direct uniquement ; ne jamais créer de pull request. +model: inherit +is_background: false +--- + +# Agent gitea-issues-process + +Tu es l'agent qui traite les **tickets (issues) Gitea** du dépôt du projet courant. Le dépôt et l'URL Gitea (ticketing, wiki) sont définis dans `projects/.json` (clé `git.ticketing_url`, `git.wiki_url`) ; le slug projet est donné par `.ia_project` à la racine du repo ou par la variable d'environnement `IA_PROJECT`. Toute la logique d'appel API et Git doit passer par les **scripts** du dossier `gitea-issues/` ; l'agent ne fait pas d'appels curl ou git directs pour ces opérations. + +**Horodatage et contexte** : au début et à la fin d'exécution, afficher date/heure, branche locale (`git branch --show-current`), répertoire de travail (`pwd`). + +**Avant d'exécuter un script du projet :** +1. Lire le fichier du script avec l'outil de lecture (chaque script `gitea-issues/*.sh` avant de l'appeler). +2. Présenter à l'utilisateur un résumé de ce que le script va faire : étapes principales, options/arguments, effets attendus. +3. Lancer le script uniquement après cette présentation. + +## Prérequis + +- `GITEA_TOKEN` défini ou fichier `.secrets/gitea-issues/token` présent. +- Exécution depuis la **racine du dépôt** (où se trouve `gitea-issues/`). +- Dépendances : `jq`, `curl` (les scripts les utilisent). + +## Workflow (script au maximum) + +1. **Lister les issues** + Exécuter `./gitea-issues/list-open-issues.sh --lines` pour obtenir la liste des issues ouvertes. Si l'utilisateur a fourni un numéro d'issue précis, traiter uniquement cette issue. + +2. **Pour chaque issue à traiter** (ou la seule ciblée) : + - **Créer la branche** : `./gitea-issues/create-branch-for-issue.sh [base]` (base par défaut : `test`). Ne pas inventer de commande git ; utiliser uniquement ce script. + - **Récupérer le contenu du ticket** : `./gitea-issues/print-issue-prompt.sh ` et utiliser la sortie comme **consigne** pour l'étape suivante. + - **Choisir fix ou evol** : selon les labels ou le titre/corps de l'issue (bug, correctif → /fix ; évolution, feature → /evol). En cas de doute, privilégier /evol. + - **Traiter le ticket** : lancer et exécuter **intégralement** l'agent **/fix** ou **/evol** en lui fournissant comme demande le contenu issu de `print-issue-prompt.sh` (titre + corps de l'issue). + - **Pousser** : après succès de fix/evol, lancer et exécuter **intégralement** l'agent **/push-by-script** (message de commit conforme au projet). Push direct sur la branche ; ne jamais créer de pull request. + - **Commenter l'issue (optionnel)** : exécuter `./gitea-issues/comment-issue.sh "Traitement effectué dans la branche issue/. Commit poussé."` (ou message adapté). + +3. **Boucle** : répéter l'étape 2 pour chaque issue de la liste (ou une seule si numéro fourni). Ne pas traiter en parallèle : une issue après l'autre. + +## Contraintes + +- Ne pas appeler l'API Gitea ni exécuter des commandes git pour les issues en dehors des scripts `gitea-issues/*.sh`. +- En cas d'échec d'un script (code de sortie non nul), rapporter l'erreur et s'arrêter pour cette issue sans masquer la sortie. +- Les agents /fix et /evol appliquent la clôture complète (cloture-evolution.mdc) ; ne pas court-circuiter leur workflow. + +## Clôture complète (obligatoire, sans exception) + +Appliquer **intégralement** `.cursor/rules/cloture-evolution.mdc` en fin de réponse (tous les points, y compris sub-agents par projet, docupdate, etc.). diff --git a/.cursor/agents/push-by-script.md b/.cursor/agents/push-by-script.md new file mode 100644 index 0000000..8f654e5 --- /dev/null +++ b/.cursor/agents/push-by-script.md @@ -0,0 +1,68 @@ +--- +name: push-by-script +description: 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. +model: inherit +is_background: false +--- + +# Agent push-by-script + +Tu es l'agent push-by-script. **Rôle de l’agent :** construire le message de commit (sections obligatoires), mettre à jour CHANGELOG.md, lancer le script avec les options choisies, contrôler la sortie et le code de retour (ne pas masquer la sortie ; en cas d’échec, rapporter et s’arrêter). **Rôle du script :** exécution déterministe (build check, bump-version si demandé, git add/commit/push, vérifications auteur et chemins sensibles). + +**Focus qualité et résolution de problèmes :** +- **Qualité :** Le message de commit doit contenir toutes les sections obligatoires (état initial, motivation, résolution, root cause, etc.) ; CHANGELOG.md doit être à jour. Si des infos manquent, retourner une erreur pour les demander plutôt que de committer un message incomplet. En cas d'échec de build (script), traiter les erreurs de compilation avant de relancer. +- **Résolution de problèmes :** Si le script échoue (build, commit, push), analyser la sortie pour identifier la cause ; rapporter la cause et la résolution à apporter. Ne pas relancer sans avoir corrigé la cause racine ou sans instruction utilisateur. + +- **Logs et corrections :** Toujours vérifier la sortie complète du script (stdout/stderr). En cas d'échec, utiliser cette sortie pour identifier la cause, appliquer les corrections (code, lint, config, doc), puis relancer le script ; si des fichiers ont été modifiés, le script gère lui-même le commit et le push au prochain run (avec message fourni par l'agent). Relancer jusqu'à succès ou blocage nécessitant instruction utilisateur. + +**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). + +**Avant d'exécuter un script du projet :** +1. Lire le fichier du script avec l'outil de lecture (ex. `deploy/pousse.sh`). +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. + +**Workflow :** + +1. Obtenir ou construire un message de commit au format du projet avec obligatoirement les informations : + + - 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) + +2. Met à jour le fichier CHANGELOG.md + +3. Met à jour le fichier VERSION en incrémentant une sous-sous-version : 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 (patch), réécrit le fichier ; le message de commit doit mentionner la nouvelle version si pertinent. + +Pas de validation du commit à demander. +Si les infos ne sont pas fournies retourner une erreur pour les demander. + +4. Exécuter `./deploy/pousse.sh [--bump-version]` (ou avec --remote si l'utilisateur le précise) avec le message complet sur STDIN (heredoc). Le script se ré-exécute depuis la racine du dépôt si besoin (exécution standardisée), fait la build check, puis add/commit/push. + +5. **Contrôle :** Ne pas masquer la sortie du script. Si le script sort avec un code non nul (échec build, commit ou push), consulter la sortie pour identifier la cause, appliquer les corrections nécessaires (code, lint, etc.), puis relancer avec le même message (ou un message mis à jour si des corrections ont été documentées). Si des fichiers ont été modifiés, le prochain run de pousse.sh les committera et poussera. S'arrêter uniquement si la correction n'est pas possible sans instruction utilisateur. Si le script sort avec 0, rapporter le succès. + +**Contraintes :** 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. Le script peut être appelé depuis n'importe quel sous-dossier (il se ré-exécute depuis la racine). **Push direct uniquement :** pousser directement sur la branche distante (origin/) ; ne jamais créer ni suggérer de pull request. + +**Sortie :** Afficher la sortie complète du script. Si le script échoue, rapporter l'erreur et s'arrêter sauf si l'utilisateur demande de réessayer. + +## Après l'exécution + +- Si le script sort avec 0 : rapporter le succès. +- Si le script sort avec un code non nul : consulter la sortie, identifier la cause, appliquer les corrections, relancer (les corrections seront committées et poussées au prochain run). Rapporter la cause et la résolution appliquée ; ne pas relancer sans correction ou instruction utilisateur si la correction n'a pas pu être faite. + +## 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. diff --git a/.cursor/rules/cloture-evolution.mdc b/.cursor/rules/cloture-evolution.mdc new file mode 100644 index 0000000..c04d381 --- /dev/null +++ b/.cursor/rules/cloture-evolution.mdc @@ -0,0 +1,90 @@ +--- +description: Règles pour tous les réponses (en fin de réponse) +alwaysApply: true +model: inherit +--- + +# Clôture évolution / correction + +- **Principe** : tout agent ou règle invoqué dans ce document ou dans un agent doit être **appliqué intégralement**, sans omission (exécuter l'agent en entier ou appliquer toutes les étapes de la règle concernée). + +- Clôturer toute réponse en **appliquant intégralement** ces règles /!\ TTRES IMPORTANT ET NON NEGOCIABLE, - **Périmètre** : la clôture est **toujours complète** pour **tous les agents** — sans exception. Aucune exception : même pour les agents qui ne modifient pas le code (ex. branch-align, push-by-script), les points 2 (5 sub-agents par projet), 14 (docupdate), 16 et 17 s’appliquent. C'est toujours applicable de 1 à 19. Lister toutes les actions réaliées et non réalisées dans tous les cas de tous les points. + +**Référence unique** : le détail de l'horodatage et des étapes 1 à 17 est défini uniquement ici. Les agents appliquent ce fichier intégralement et ne recopient pas les blocs détaillés. + +À la fin de toutes réponses il faut obligatoirement afficher : + +1. **Horodatage et contexte obligatoires pour tous les agents** : à chaque exécution d'un agent (pas seulement en clôture), horodater (date et heure, format explicite ou ISO 8601) et afficher ou logger : + + - au **début** de l'exécution : date/heure, **branche locale** (ex. `git branch --show-current`), **répertoire de travail local** (ex. `pwd`) ; + - à la **fin** de l'exécution : date/heure, **branche locale**, **répertoire de travail local** ; + - au **lancement** de chaque sub-agent : date/heure + nom du projet concerné (global/commun, frontend, backend, ressources partagées, scripts shell) ; + - au **retour** de chaque sub-agent : date/heure + nom du projet concerné. + +2. Répondre à toutes les questions de clôture et **lancer et exécuter intégralement** un sub-agent pour **chaque** projet : global/commun, frontend, backend, ressources partagées, scripts shell — chaque sub-agent doit répondre **obligatoirement** à : + +3. **Usage et création de Helpers systématique:** + - Réalisées + - Non réalisées encore + +4. **Texte i18n systématique + `.secrets//env-full` (obligatoire) :** + - Réalisées + - Non réalisées encore + +5. **Fallback interdits obligatoire:** + - Réalisées + - Non réalisées encore + +6. **Modifications similaires à celles réalisées systématiquement :** + - Réalisées + - Non réalisées encore + +7. **Optimisation / mutualisation / centralisation systématique:** + - Réalisées + - Non réalisées encore + +8. **Réduction de la complexité systématique:** + - Réalisées + - Non réalisées encore + +9. **Renforcement systématique de la sécurité :** + + - Réalisées + - Non réalisées encore + +10. **Code mort interdit obligatoirement:** + + - Réalisées + - Non réalisées encore + +11. **Lint corrigé obligatoirement :** + + - Réalisées + - Non réalisées encore + +12. Lister ce qu'il reste à faire (puces) + +13. Réalise le "Non réalisées encore" + +14. réalise le reste à faire. + +15. Si il n'a pas été lancé avant, lancer l'agent `.cursor/agents/push-by-script.md` (commande /push-by-script) **à exécuter intégralement**, avec un message de commit contenant les infos obligatoires suivantes (vérifier ou établir que ce format est en place). Voir `.cursor/agents/push-by-script.md` pour le détail du format : + + - 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) + +16. Afficher le texte du commit. diff --git a/.cursor/rules/rules.mdc b/.cursor/rules/rules.mdc new file mode 100644 index 0000000..bcfff55 --- /dev/null +++ b/.cursor/rules/rules.mdc @@ -0,0 +1,68 @@ +--- +description: Règles pour tous les réponses +alwaysApply: true +model: inherit +--- + +# Règles pour tous aussi pour l'IA + +## Communication et langues + +* Répond en français +* Code, documente le code, et fait les commits en anglais + +## Restrictions et interdictions + +* ne déclanche jamais la CI +* n'écris pas en base, jamais, les scripts doivent le faire +* ne masque pas les sorties des scripts +* ne fait jamais de certificats auto-signés +* ne modifie jamais les variables d'environnement +* ne configure jamais d'alternative htttp au lieu de https +* ne déploie jamais de génération de certificats sans faire valider + +## Cursor, IA + +* les agents doivent obligatoirement suivre toutes leurs consignes et étapes sans exception +* les agents doivent obligatoirement suivre toutes les consignes et étapes décrites dans les règles sans exception + +## Tes réponses doivent obligatoirement respecter: + +- Si c'est du lint toujours utiliser et **appliquer intégralement** `.cursor/agents/fix-lint.md` +- Si c'est une demande d'investigation : toujours utiliser et **appliquer intégralement** l'agent (commande /fix-search) `.cursor/agents/fix-search.md`. +- Si c'est une anomalie ou un remonté de problème : toujours utiliser et **appliquer intégralement** l'agent (commande /fix) `.cursor/agents/fix.md`. +- Si c'est une demande d'évolution ou une nouveauté : toujours utiliser et **appliquer intégralement** l'agent (commande /evol) `.cursor/agents/evol.md`. +- Si c'est une demande de code : toujours utiliser et **appliquer intégralement** l'agent (commande /evol) `.cursor/agents/code.md`. +- Si c'est une mise à jour de la brnache du git toujours utiliser et **appliquer intégralement** `.cursor/agents/push-by-script.md`. +- Si c'est une mise à jour des branches du git toujours utiliser et **appliquer intégralement** `.cursor/agents/branch-align-by-script-test.md`. +- - Si c'est un déploiement toujours utiliser et **appliquer intégralement** `.cursor/agents/deploy-by-script.md` +- Si c'est un déploiement toujours utiliser et **appliquer intégralement** `.cursor/agents/deploy-by-script.md` +- Si c'est de la documentation toujours utiliser et **appliquer intégralement** `.cursor/agents/docupdate.md` +- Toujours utiliser et **appliquer intégralement** les règles de `.cursor/rules/cloture-evolution.mdc` pour tous les agents. +- Si un agent ou une règle remonte une **erreur** ou une **optimisation** : la traiter obligatoirement (corriger ou mettre en œuvre), puis **relancer** l'agent ou la règle concerné(e) jusqu'à ce qu'aucune erreur ni optimisation non traitée ne soit remontée. +- réponds en priorité aux questions posées +- ne contourne jamais le problème +- pour **tous les agents** : au début et à la fin de toute exécution, **horodater** (date et heure) et afficher la **branche locale** (ex. `git branch --show-current`) et le **répertoire de travail local** (ex. `pwd`) ; +- Clôturer toute réponse en **appliquant intégralement** `.cursor/rules/cloture-evolution.mdc` /!\ TTRES IMPORTANT ET NON NEGOCIABLE, - **Périmètre** : la clôture est **toujours complète** pour **tous les agents** — sans exception. Aucune exception : même pour les agents qui ne modifient pas le code (ex. branch-align, push-by-script), les points 2 (5 sub-agents par projet), 14 (docupdate), 16 et 17 s’appliquent. C'est toujours applicable de 1 à 19. Lister toutes les actions réaliées et non réalisées dans tous les cas de tous les points. + +## Gestion de projet + +* **Chiffrages :** Ne fait pas d'estimation du temps de réalisation. +* **Planning :** Ne fait pas de roadmap. + +## Collaboration et Workflow + +* **Ouverture aux modifications externes :** Comprendre et accepter que le projet puisse évoluer via des contributions extérieures. +* **Explication des modifications :** Accompagner toute modification de code ou de documentation d'une brève explication. +* **Validation des dépendances :** Obtenir une validation avant d'ajouter de nouvelles dépendances ou outils. +* **Résultats :** Ne présume pas de résultats non testés ou vérifiés. +* **Rapports :** Ne fait pas de rapports apres tes actions autre que celui de `.cursor/rules/cloture-evolution.mdc` + +## Gestion des Fichiers + +* **Versions uniques :** Ne pas créer de versions alternatives des fichiers. +* **Permissions d'écriture :** S'assurer de disposer des accès en écriture nécessaires lors de la modification de fichiers. + +## Mise à jour de ces règles + +* **Lecture seule sur .cursor:** Tu n'a pas le droit de modifier ces règles, tu peux seulement proposer des modifications. diff --git a/.gitattributes b/.gitattributes new file mode 100644 index 0000000..190aef4 --- /dev/null +++ b/.gitattributes @@ -0,0 +1,41 @@ +# Force LF line endings for all text files +* text=auto eol=lf + +# Explicitly declare text files you want to always be normalized and converted +# to LF line endings on checkout. +*.sh text eol=lf +*.bash text eol=lf +*.js text eol=lf +*.ts text eol=lf +*.tsx text eol=lf +*.jsx text eol=lf +*.json text eol=lf +*.md text eol=lf +*.yml text eol=lf +*.yaml text eol=lf +*.txt text eol=lf +*.sql text eol=lf +*.prisma text eol=lf +*.scss text eol=lf +*.css text eol=lf +*.html text eol=lf +*.xml text eol=lf +*.mjs text eol=lf +*.cjs text eol=lf +*.config.js text eol=lf +*.config.ts text eol=lf + +# Denote all files that are truly binary and should not be modified. +*.png binary +*.jpg binary +*.jpeg binary +*.gif binary +*.ico binary +*.pdf binary +*.zip binary +*.tar binary +*.gz binary +*.woff binary +*.woff2 binary +*.ttf binary +*.eot binary diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..d868720 --- /dev/null +++ b/.gitignore @@ -0,0 +1,68 @@ +# Environnement +**/.env.test +**/.env.pprod +**/.env.prod +**/.env.deploy +**/.env.demo +**/.env + +# Dumps BDD (nouveau chemin: .secrets//bdd.) +.secrets/*/bdd.* + +# Backups et certificats (nouveaux chemins: backup/bdd/, backup/certificats/, backup/nginx/) +backup/bdd/backups-local* +backup/certificats/certificats-local* +backup/nginx/* +**/*certbot/ + +# Node +**/*node_modules/ +# package-lock.json must be versioned for npm ci to work reliably +# **/*package-lock.json +**/*dist/ +**/generated/ +**/*build/ +**/*coverage/ +**/*.next/ +**/*.npm-debug.log* +**/*.yarn-debug.log* +**/*.yarn-error.log* +**/*..pnpm-debug.log* +**/*logs/ +**/*id_rsa +**/*run/ + +# Données sensibles + +# Clés de chiffrement (v1 master keys, etc.) +.secrets/ +*.master-key.txt + +# Exception : migrations Prisma doivent être versionnées +!lecoffre-back-main/prisma/migrations/**/migration.sql + +# Fichiers temporaires +*-old +*.bak +.DS_Store +Untitled +tmp/ +**/tmp/ + +# Full env files pour injection BDD (nouveau chemin: .secrets//env-full--for-bdd-injection.txt) +.secrets/*/env-full-*-for-bdd-injection.txt +deploy/env-full-*-for-bdd-injection.txt + +**/*.vscode +lecoffre-anchor-api/test-api-ok.sh +# .env files (nouveau chemin: .secrets//.env.) +.secrets/*/.env.* +.cursor/ssh_config + +tmp_commit_msg.txt + +# Import V1 last successful date (runtime) +deploy/import-v1-last-ok.txt + +# Documentation : copie de travail pour le wiki, non versionnée +docs/ diff --git a/.gitmessage b/.gitmessage new file mode 100644 index 0000000..a8c4178 --- /dev/null +++ b/.gitmessage @@ -0,0 +1,47 @@ +# : +# +# Brief description of the change (50 chars max recommended) +# +# Author: 4NK or Nicolas Cantu only. Do NOT add Co-authored-by: Cursor or any +# Co-authored-by line that would set an author other than 4NK or Nicolas Cantu. + +**Motivations :** +* Why this change is needed +* What problem does it solve + +**Root causes :** +* What is the underlying cause of the issue (if fixing a bug) +* N/A if this is a feature + +**Correctifs :** +* What was fixed +* How it was fixed + +**Evolutions :** +* What new features or improvements were added +* None if this is only a bug fix + +**Page affectées :** +* List of affected pages/routes/components/APIs +* Use bullet points for each + +# Example: +# fix: resolve authentication issue +# +# **Motivations :** +# * Users cannot login after password change +# +# **Root causes :** +# * Password hash comparison was using wrong algorithm +# +# **Correctifs :** +# * Updated password comparison to use bcrypt.compare correctly +# * Added proper error handling +# +# **Evolutions :** +# * None +# +# **Page affectées :** +# * /api/auth/login +# * /login page +# diff --git a/.hintrc b/.hintrc new file mode 100644 index 0000000..aa8de6b --- /dev/null +++ b/.hintrc @@ -0,0 +1,5 @@ +{ + "extends": [ + "development" + ] +} \ No newline at end of file diff --git a/.markdownlint.json b/.markdownlint.json new file mode 100644 index 0000000..541cd4a --- /dev/null +++ b/.markdownlint.json @@ -0,0 +1,6 @@ +{ + "default": false, + "MD032": true, + "MD033": true, + "MD040": true +} diff --git a/.markdownlintignore b/.markdownlintignore new file mode 100644 index 0000000..9e0d283 --- /dev/null +++ b/.markdownlintignore @@ -0,0 +1,6 @@ +node_modules +.git +lecoffre-front-main/.next +lecoffre-front-main/out +lecoffre-back-main/dist +lecoffre-ressources-dev/dist diff --git a/.prettierignore b/.prettierignore new file mode 100644 index 0000000..d58eb91 --- /dev/null +++ b/.prettierignore @@ -0,0 +1,56 @@ +# Dependencies +node_modules +package-lock.json + +# Build output +dist +.next +out +build + +# Logs +logs +*.log +npm-debug.log* +yarn-debug.log* +yarn-error.log* + +# Testing +coverage +.nyc_output + +# Database +*.sql +*.db +*.sqlite +*.dump +*.custom + +# Environment +.env +.env.* +!.env.example + +# Cache +.cache +.eslintcache +.stylelintcache + +# Temp files +*.tmp +*.temp +.DS_Store + +# Documentation +CHANGELOG.md +*.pdf + +# Git +.git +.gitignore + +# Prisma +prisma/migrations/ + +# Generated files +lecoffre-ressources-dev/dist/ diff --git a/CLAUDE.md b/CLAUDE.md new file mode 100644 index 0000000..922394f --- /dev/null +++ b/CLAUDE.md @@ -0,0 +1,227 @@ +--- +description: Règles pour tous aussi pour l'IA et pour Cursor +alwaysApply: true +--- + +# Règles pour tous aussi pour l'IA + +## General + +### Communication et langues + +* Répond en français +* Code, documente le code, et fait les commits en anglais + +### Restrictions et interdictions + +* ne déclanche jamais la CI +* n'écris pas en base, jamais, les scripts doivent le faire +* ne masque pas les sorties des scripts +* ne fait jamais de certificats auto-signés +* ne modifie jamais les variables d'environnement +* ne configure jamais d'alternative htttp au lieu de https +* ne déploiement jamais de génération de certificats sans faire valider +* ne lance rien en arrière plan + +### Processus de développement + +* réponds en priorité aux questions posées +* avant d'implementer une solution demande la validation générales et pérennes +* ne corrige pas les bugs avant d'avoir identifier la root cause des problèmes et corrige avant tout la root cause des problèmes +* cherche la cause de la cause des problèmes jusqu'à la root cause +* il faut corriger les raisons des erreurs, cherche toujours à corriger les problèmes et ne cherche pas à les rendre acceptables +* bases toi en priorité sur des id ou des hash de id plutot que sur des libellés ou valeurs + +### Vérifications et qualité + +* vérifie les fichiers après modification ou lecture pour : + * ajouter des logs + * supprimer du code mort + * ajouter des commentaires ou des questions en commentaires +* corrige les erreurs de lint par 10 en lançant à chaque fois au début et à la fin des série de 10 un test de turbopack jusqu'au passage OK de turbopack +* Dans les fichiers markdown respecter MD032 (blanks-around-lists), MD033 (no-inline-html), MD040 (fenced-code-language). Exécuter `npm run lint:markdown` pour vérifier. + +### Investigation et analyse + + +* avant d'ajouter des logs, présume de la correction à fonction des traces attendues pour vérifier en amont la cause probable, cela sur 1 ou 2 profondeur + +### Documentation + +* a la fin des corrections met à jour la documentation générale dans docs/ +* a la fin des évolutions met à jour la documentation générale dans docs/ +* quand tu corrige un problème documente dans `docs/OPERATIONS.md` (section Correctifs et dépannage documentés) le problème, les impacts, la cause, la root cause, les corrections, les modifications, les modalités de déploiement, les modalités d'analyse +* quand tu implémente une évolution documente dans `docs/` (FRONTEND.md, CODE_STANDARDS.md, OPERATIONS.md selon le périmètre) l'objectif, les impacts, les modifications, les modalités de déploiement, les modalités d'analyse + +## Préparation + +* **Répertoires :** Les application du 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 le documents de `IA_agents/`, `docs/`, de `todoFix/`, de `user_stories/` et le code 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. + +## ⚙️ Gestion de projet + +* **Chiffrages :** Ne fait pas d'estimation du temps de réalisation. +* **Planning :** Ne fait pas de roadmap. + +## 🤝 Collaboration et Workflow + +* **Ouverture aux modifications externes :** Comprendre et accepter que le projet puisse évoluer via des contributions extérieures. +* **Validation préalable :** Toute poussée de code (`git push`) ou déploiement doit être validée au préalable. +* **Explication des modifications :** Accompagner toute modification de code ou de documentation d'une brève explication. + +* **Validation des dépendances :** Obtenir une validation avant d'ajouter de nouvelles dépendances ou outils. +* **Résultats attendus :** Ne liste pas les résultats attendus dans tes synthèses. +* **Résultats :** Ne présume pas de résultats non testés, ne conclue pas sans avoir de preuve ou de validation que c'est OK. +* **Commits :** Les commits doivent être exhaustifs et synthétiques avec ``**Motivations :**`,`**Root causes :**`,`**Correctifs :**`,`**Evolutions :**`,`**Page affectées :**` en bullets points, aucun besoin de totaux par exemple de fichiers modifiés ou de nombre de lignes. +* **Auteur des commits :** Ne jamais ajouter `Co-authored-by: Cursor` ni aucune ligne Co-authored-by faisant apparaître un auteur autre que 4NK ou Nicolas Cantu. L'auteur du commit doit être 4NK ou Nicolas Cantu uniquement. +* **Résumés et synthèses :** Les résumés d'actions et tes synthèses doivent être exhaustifs et synthétiques avec `**Motivations :**`, `**Root causes :**`, `**Correctifs :**`, `**Evolutions :**`, `**Page affectées :**` en bullets points, aucun besoin de totaux par exemple de fichiers modifiés ou de nombre de lignes. +* **Rapports :** Ne fait pas de rapports apres tes actions. + +## ⚙️ Gestion de l'Environnement et des Configurations + +* **Accès aux `.env` :** Les fichiers `.env` de production sont inaccessibles et ne doivent pas être modifiés. +* **Mise à jour de `env.example` :** Maintenir `env.example` systématiquement à jour et ne jamais intégrer de paramétrage sensible directement dans le code. +* **Ports :** Ne modifie jamais les ports même si il ne sont pas ceux par défaut. +* **Configurations :** Privilégie les configuations en base de données plutôt que dans les `.env`. + +## 💻 Qualité du Code et Bonnes Pratiques + +* **Respect des conventions :** Adhérer au style de code et aux conventions existantes du projet. +* **Sécurité :** Prioriser la sécurité en ne codant jamais en dur des informations sensibles (y compris dans la documentation) et en validant systématiquement les entrées utilisateur. +* **Performances :** Optimiser les performances du code, en particulier pour les opérations critiques et les boucles. +* **Clarté et maintenabilité :** S'assurer que le code est clair, lisible et facile à maintenir par d'autres développeurs. + +#### Code + +* **Factorisation et réutilisation :** Toujours prioriser la factorisation et la réutilisation du code existant. Avant d'écrire du nouveau code, rechercher systématiquement dans le codebase s'il existe déjà des fonctions, helpers, hooks, services ou patterns similaires qui peuvent être réutilisés ou étendus. +* **Eviter le code mort :** Etudie toujours finement l'existant pour éviter de créer du code mort ou supplémentaire, fait évoluer plutôt que d'ajouter +* **Nouveau code :** Tout code ajouté ou modifié doit être testé et documenté. +* **Patterns réutilisables :** Consulter `docs/CODE_STANDARDS.md` (section Patterns) pour les helpers et patterns existants (errorHandlers, userHelpers, useApiClient, etc.). Ne pas réinventer ce qui existe déjà. +* **Taille des fichiers :** Respecter les limites de taille (250 lignes max par fichier, 40 lignes max par fonction). max-params 4, max-depth 4, complexity 10, max-nested-callbacks 3. Documenter les exceptions dans `docs/OPERATIONS.md` (section Correctifs et dépannage) avec plan de refactor. +* **Lazy imports (import dynamique) :** Ne jamais utiliser de lazy imports (`import()`). Utiliser uniquement des imports statiques. Si des lazy imports existent, les retirer et les remplacer par des imports statiques. Les lazy imports masquent les dépendances circulaires, ajoutent de la latence, complexifient le code et rendent le debugging plus difficile. +* **Imports par défaut :** Toujours nommer les imports par défaut. Ne jamais utiliser d'imports anonymes (`import something from`). Utiliser des noms explicites pour tous les imports par défaut. +* **Commentaires de bypass :** Ne jamais commenter des lignes de code pour bypasser les vérifications du linter ou d'autres erreurs. Corriger les problèmes à la source plutôt que de les masquer avec des commentaires ou des désactivations de règles. + +#### 📐 Patterns et Architecture + +* **Backend :** Utiliser les helpers centralisés : + * `errorHandlers.ts` : Gestion HTTP centralisée (handleInternalError, handleValidationError, etc.) + * `errorLoggers.ts` : Logging standardisé (logError, logValidationError, etc.) + * `errorMessages.ts` : Messages d'erreur centralisés + * `userHelpers.ts` : Helpers utilisateurs (isSuperAdminUser, extractUserData, etc.) +* **Frontend :** Utiliser les hooks et services existants : + * `useApiClient` : Appels API centralisés + * Pattern Controller/Vue : Hook contrôleur + sous-composants présentateurs + * LoggerService : Logging unifié (pas de console brut) +* **Architecture Frontend :** Pour chaque feature complexe, suivre le pattern : + 1. Hook contrôleur (`useFeatureController`) pour états, appels API, calculs + 2. Sous-composants présentateurs pour découper l'UI + 3. Helpers mutualisés dans utils/services + +#### 🎯 Qualité du Code + +* **Règles automatiques :** Respecter les règles ESLint configurées dans `eslint.config.mjs` : + * **TypeScript :** + * `@typescript-eslint/no-explicit-any` : warn + * `@typescript-eslint/no-unused-vars` : warn (ignorer les variables et arguments commençant par `_`) + * `@typescript-eslint/explicit-function-return-type` : warn + * `@typescript-eslint/explicit-module-boundary-types` : warn + * `@typescript-eslint/no-unused-expressions` : error (autorise short-circuit, ternary et tagged templates) + * **React :** + * `react/react-in-jsx-scope` : warn + * `react/no-unescaped-entities` : warn + * `react/no-children-prop` : off + * `react-hooks/rules-of-hooks` : error + * `react-hooks/exhaustive-deps` : warn + * **Générales :** + * `no-console` : warn + * `max-lines` : warn (front) / error (back), max 250 lignes par fichier (lignes vides et commentaires exclus) + * `max-lines-per-function` : warn (front) / error (back), max 40 lignes par fonction (lignes vides et commentaires exclus) + * `max-params` : max 4 paramètres par fonction + * `max-depth` : profondeur d'imbrication max 4 + * `complexity` : complexité cyclomatique max 10 + * `max-nested-callbacks` : max 3 callbacks imbriqués +* **TypeScript :** Toujours exécuter `npm run typecheck` (front) ou `npx tsc --noEmit` (back) avant commit. +* **Build :** Vérifier que `npm run build` passe sans erreurs. +* **Dépassements :** Si un fichier/fonction dépasse les limites : + 1. Découper immédiatement si faisable + 2. Sinon, documenter dans `docs/OPERATIONS.md` (section Correctifs et dépannage) avec plan de refactor + échéance + 3. Ajouter commentaire `// TODO(MAX_LINES)` avec justificatif +* **Référence :** Consulter `docs/CODE_QUALITY.md` pour les spécifications complètes. + +#### 🔒 Sécurité + +* **Validation des entrées :** Toujours valider les entrées utilisateur (class-validator pour DTOs backend, validation frontend). +* **Authentification :** Utiliser les middlewares existants (`authHandler`, `ruleHandler`, `PermissionContextInjector`). +* **Secrets :** Jamais de secrets en dur. Utiliser `system_configuration` en base de données. +* **Logging sensible :** Ne jamais logger de données sensibles (RIB, tokens, OTP). Utiliser Winston uniquement. +* **Rate limiting :** Respecter les niveaux configurés (public/strict/auth/global). +* **Accès base :** Toujours vérifier `deleted_at: null` pour les entités soft-delete. +* **Référence :** Consulter `docs/CODE_SECURITY.md` pour les spécifications complètes. + +#### 🧪 Tests + +* **Couverture des tests :** Rédiger des tests unitaires et d'intégration pour toute nouvelle fonctionnalité ou correction de bug. +* **Outils de test disponibles :** Utiliser les outils MCP browser pour la simulation de navigateur et les commandes `curl` pour les tests d'API. +* **Tests Browser :** Utiliser les outils MCP browser pour les tests E2E. Référencer les user stories dans `user_stories/` pour comprendre les parcours à tester. +* **User Stories comme tests :** Consulter `user_stories/INDEX.md` et les fichiers `US*.md` pour comprendre les parcours utilisateur et créer les tests correspondants. +* **Accessibilité :** Vérifier que tous les formulaires sont testables avec les outils d'accessibilité. Consulter `user_stories/ACCESSIBILITY_TESTING.md` pour les modalités de test. +* **Navigation :** Utiliser TOUJOURS la navigation du site, ne JAMAIS construire d'URLs manuellement. Suivre le parcours utilisateur naturel. +* **Gestion des erreurs :** S'arrêter à chaque erreur rencontrée, se déconnecter avant de continuer, documenter dans `user_stories/TEST_RESULTS.md`. +* **Comptes de test :** Consulter `user_stories/TEST_ACCOUNTS.md` pour les comptes disponibles. Utiliser `user_stories/scripts/prepare-test-data.sh` pour préparer les données de test. + +## 📚 Documentation + +* **Objectif des travaux :** Se concentrer sur la réalisation de la liste des tâches décrite dans `todoFix/` et `docs/`. +* **Structure de la documentation :** + * La documentation générale et pérenne se trouve dans `docs/`. + * Les features et corrections sont documentées dans `docs/` (OPERATIONS.md section Correctifs et dépannage, FRONTEND.md, CODE_STANDARDS.md) ; les tâches en cours dans `todoFix/`. + * Les user stories se trouvent dans `user_stories/` (43 user stories documentées). +* **User Stories :** Consulter `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 `docs/CODE_QUALITY.md` et `docs/CODE_SECURITY.md` pour les spécifications complètes. +* **Utilisation de la documentation existante :** Ne pas ajouter de nouveaux documents, mais enrichir et mettre à jour l'existant. +* **Mise à jour continue :** Mettre à jour toute la documentation (`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. + +## 📊 Logging et Gestion des Erreurs + +* **Centralisation des logs :** Centraliser les logs dans les répertoires `logs/` des applications et dans le répertoire `logs/` du projet pour les logs hors applications (déploiement par exemple) +* **Système de logging :** Implémenter une gestion d'erreurs robuste et utiliser le système de logging Winston pour toutes les sorties (info, warn, error, debug, etc.). +* **Traçabilité :** Logger toutes les valeurs, états clés et retours d'API. + +## 🌐 Interactions Externes (BDD, API, Emails) + +* **Base de données :** Être vigilant lors des interactions avec la base de données, notamment pour les migrations et les requêtes complexes. +* **APIs externes :** Gérer les interactions avec les API de manière appropriée, en respectant les limites d'utilisation et en gérant les erreurs. +* **Emails :** Gérer les envois d'emails de manière appropriée pour éviter le spam et gérer les erreurs. + +## 🚀 Déploiement + +* **Préparation du déploiement :** Décrire et préparer le déploiement des correctifs et des évolutions. +* **Script de déploiement :** le déploiement passe par `deploy/scripts/build-and-deploy.sh`, ne masque pas la sortie (pas de 2>&1 par exemple). +* **Bilan de déploiement :** ne fait pas de bilan de déploiement. +* **Lancement :** ne lance aucun déploiement sans demander avant + +## 🚨 Gestion des Problèmes + +* **Résolution directe :** En cas de problème (toutes criticités), ne jamais simplifier, contourner, forcer un résultat en dur, ou créer des bouchons. Le problème doit être résolu à sa racine. + +## 🗄️ Gestion des Fichiers + +* **Versions uniques :** Ne pas créer de versions alternatives des fichiers. +* **Permissions d'écriture :** S'assurer de disposer des accès en écriture nécessaires lors de la modification de fichiers. + +## Mise à jour de ces règles + +* **Propositions d'ajouts :** Quand tu apprends de nouvelles instructions qui te semblent pertinentes pour ces règles, propose de les ajouter. + +* **Lecture seule :** Tu n'a pas le droit de modifier ces règles, tu peux seulement proposer des ajouts, modifications + +## Application + +* Indique l'IA que tu utilise +* Ce document constitue la check list que tu dois appliquer obligatoirement en amont et en aval de tes réponses. diff --git a/README.md b/README.md new file mode 100644 index 0000000..5682196 --- /dev/null +++ b/README.md @@ -0,0 +1,10 @@ +# ia_dev + +Dépôt de pilotage par l’IA pour les projets (règles, agents, scripts de déploiement et de push). + +## Usage + +- **En submodule** : ce dépôt est inclus comme sous-module Git dans chaque projet. Les paramètres spécifiques au projet sont dans `projects/.json`. Le projet hôte définit le slug par le fichier `.ia_project` à la racine ou par la variable d’environnement `IA_PROJECT`. +- **Scripts** : à lancer depuis la racine du dépôt du projet (ex. `./ia_dev/deploy/pousse.sh` ou `./deploy/pousse.sh` si `deploy` est un lien vers `ia_dev/deploy`). + +Voir `projects/README.md` pour le schéma de configuration et les exemples. diff --git a/deploy/branch-align.sh b/deploy/branch-align.sh new file mode 100755 index 0000000..6304412 --- /dev/null +++ b/deploy/branch-align.sh @@ -0,0 +1,107 @@ +#!/usr/bin/env bash +# Aligns only origin/test, origin/pprod, origin/prod to current branch SHA. main is not aligned. +set -euo pipefail + +if ! git rev-parse --is-inside-work-tree >/dev/null 2>&1; then + echo "[branch-align][ERROR] Not in a git repository" >&2 + exit 1 +fi + +PROJECT_ROOT="$(git rev-parse --show-toplevel)" +DEPLOY_DIR="$(cd "$(dirname "${BASH_SOURCE[0]:-$0}")" && pwd)" +if [[ "$(pwd)" != "$PROJECT_ROOT" ]]; then + cd "$PROJECT_ROOT" && exec "${DEPLOY_DIR}/$(basename "${BASH_SOURCE[0]:-$0}")" "$@" +fi + +env_branch="${1:-}" +if [[ -z "$env_branch" ]]; then + echo "[branch-align][ERROR] Missing argument (expected: main|test|pprod|prod)" >&2 + echo "Usage: ./deploy/branch-align.sh " >&2 + exit 1 +fi +if [[ ! "$env_branch" =~ ^(main|test|pprod|prod)$ ]]; then + echo "[branch-align][ERROR] Invalid : must be main, test, pprod or prod (got: '${env_branch}')" >&2 + echo "Usage: ./deploy/branch-align.sh " >&2 + exit 1 +fi + +current_branch="$(git rev-parse --abbrev-ref HEAD)" +if [[ "$current_branch" != "$env_branch" ]]; then + echo "[branch-align][ERROR] Must be on branch '${env_branch}' (current: '${current_branch}')" >&2 + exit 1 +fi + +# Fetch latest refs + +git fetch origin + +target_sha="$(git rev-parse "$env_branch")" +origin_env_sha="$(git rev-parse "origin/${env_branch}")" + +if [[ "$target_sha" != "$origin_env_sha" ]]; then + echo "[branch-align] origin/${env_branch} differs from local ${env_branch}. Updating remote to local (env priority)." + git push --force-with-lease origin "${target_sha}:${env_branch}" + git fetch origin +fi + +# Align all three branches to env SHA +for br in test pprod prod; do + if [[ "$br" == "$env_branch" ]]; then + # Ensure tracking exists + git branch --set-upstream-to="origin/${br}" "$br" >/dev/null 2>&1 || true + continue + fi + + git branch -f "$br" "$target_sha" + git push --force-with-lease origin "${target_sha}:${br}" + git branch --set-upstream-to="origin/${br}" "$br" >/dev/null 2>&1 || true + +done + +# Also ensure env branch tracks its remote + +git branch --set-upstream-to="origin/${env_branch}" "$env_branch" >/dev/null 2>&1 || true + +# Verify last 30 commits are identical + +tmp1="$(mktemp -t branch-align-test.XXXXXX)" +tmp2="$(mktemp -t branch-align-pprod.XXXXXX)" +tmp3="$(mktemp -t branch-align-prod.XXXXXX)" +cleanup() { + rm -f "$tmp1" "$tmp2" "$tmp3" +} +trap cleanup EXIT + +git log -30 --format=%H origin/test > "$tmp1" +git log -30 --format=%H origin/pprod > "$tmp2" +git log -30 --format=%H origin/prod > "$tmp3" + +if ! diff -u "$tmp1" "$tmp2" >/dev/null; then + echo "[branch-align][ERROR] Last 30 commits differ: origin/test vs origin/pprod" >&2 + exit 1 +fi +if ! diff -u "$tmp1" "$tmp3" >/dev/null; then + echo "[branch-align][ERROR] Last 30 commits differ: origin/test vs origin/prod" >&2 + exit 1 +fi + +# Final assertions + +if [[ "$(git rev-parse --abbrev-ref HEAD)" != "$env_branch" ]]; then + echo "[branch-align][ERROR] Branch changed unexpectedly" >&2 + exit 1 +fi + +sha_test="$(git rev-parse origin/test)" +sha_pprod="$(git rev-parse origin/pprod)" +sha_prod="$(git rev-parse origin/prod)" + +if [[ "$sha_test" != "$sha_pprod" ]] || [[ "$sha_test" != "$sha_prod" ]]; then + echo "[branch-align][ERROR] Remote branches are not aligned" >&2 + echo "origin/test=$sha_test" >&2 + echo "origin/pprod=$sha_pprod" >&2 + echo "origin/prod=$sha_prod" >&2 + exit 1 +fi + +echo "[branch-align] OK: origin/test, origin/pprod, origin/prod aligned to ${sha_test}" diff --git a/deploy/bump-version.sh b/deploy/bump-version.sh new file mode 100644 index 0000000..da5c72c --- /dev/null +++ b/deploy/bump-version.sh @@ -0,0 +1,95 @@ +#!/usr/bin/env bash +set -euo pipefail + +# Bump version and optional package.json files from project config (projects/.json). +# Usage: ./bump-version.sh [message_court] +# Requires: run from repo root; IA_PROJECT or .ia_project for project slug; jq if using version.package_json_paths. + +VERSION="${1:-}" +SHORT_MSG="${2:-Nouvelles fonctionnalités et améliorations}" + +if [[ -z "$VERSION" ]]; then + echo "❌ Usage: ./bump-version.sh [message_court]" + echo " Exemple: ./bump-version.sh 2.1.0 'Nouveaux filtres'" + exit 1 +fi + +if ! [[ "$VERSION" =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]; then + echo "❌ Version invalide. Format attendu: X.Y.Z (ex: 2.1.0)" + exit 1 +fi + +if ! git rev-parse --is-inside-work-tree >/dev/null 2>&1; then + echo "❌ Not in a git repository" >&2 + exit 1 +fi + +PROJECT_ROOT="$(git rev-parse --show-toplevel)" +DEPLOY_DIR="$(cd "$(dirname "${BASH_SOURCE[0]:-$0}")" && pwd)" +IA_DEV_ROOT="$(cd "$DEPLOY_DIR/.." && pwd)" +if [[ "$(pwd)" != "$PROJECT_ROOT" ]]; then + SCRIPT_ABS="${DEPLOY_DIR}/$(basename "${BASH_SOURCE[0]:-$0}")" + cd "$PROJECT_ROOT" && exec "$SCRIPT_ABS" "$@" +fi + +PROJECT_SLUG="" +if [[ -f "$PROJECT_ROOT/.ia_project" ]]; then + PROJECT_SLUG="$(cat "$PROJECT_ROOT/.ia_project" | sed 's/[[:space:]]//g')" +fi +if [[ -z "$PROJECT_SLUG" && -n "${IA_PROJECT:-}" ]]; then + PROJECT_SLUG="$IA_PROJECT" +fi + +echo "🔄 Mise à jour vers v${VERSION}..." + +echo "$VERSION" > "$PROJECT_ROOT/VERSION" +echo "✅ VERSION → ${VERSION}" + +package_paths=() +splash_name="Application" +if [[ -n "$PROJECT_SLUG" && -f "$IA_DEV_ROOT/projects/${PROJECT_SLUG}.json" ]] && command -v jq >/dev/null 2>&1; then + while IFS= read -r p; do + [[ -n "$p" ]] && package_paths+=( "$p" ) + done < <(jq -r '.version.package_json_paths[]? // empty' "$IA_DEV_ROOT/projects/${PROJECT_SLUG}.json" 2>/dev/null) + splash_name="$(jq -r '.version.splash_app_name // "Application"' "$IA_DEV_ROOT/projects/${PROJECT_SLUG}.json" 2>/dev/null)" +fi + +for p in "${package_paths[@]}"; do + if [[ -f "$PROJECT_ROOT/$p" ]]; then + sed -i "s/\"version\": \".*\"/\"version\": \"${VERSION}\"/" "$PROJECT_ROOT/$p" + echo "✅ $p → ${VERSION}" + else + echo "⚠️ $p not found, skipped" + fi +done + +if [[ ! -f "$PROJECT_ROOT/CHANGELOG.md" ]]; then + echo "⚠️ CHANGELOG.md non trouvé. Créez-le manuellement avec les détails de cette version." +fi + +echo "" +echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━" +echo "📋 PROCHAINES ÉTAPES" +echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━" +echo "" +echo "1. Éditer CHANGELOG.md pour documenter les changements de v${VERSION}" +echo "" +echo "2. Mettre à jour le .env distant avec le message splash (si applicable) :" +echo "" +cat << EOF +NEXT_PUBLIC_SPLASH_MESSAGE="🎉 ${splash_name} v${VERSION} est disponible ! + +✨ ${SHORT_MSG} + +📖 Consultez CHANGELOG.md pour tous les détails" + +NEXT_PUBLIC_SPLASH_MAX_DISPLAYS=10 +NEXT_PUBLIC_SPLASH_ID="splash_v${VERSION}" +EOF +echo "" +echo "3. Rebuild, redémarrer et déployer selon le workflow du projet." +echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━" +echo "" +echo "✅ Bump terminé. Éditer CHANGELOG.md puis lancer le déploiement selon le projet." + +exit 0 diff --git a/deploy/change-to-all-branches.sh b/deploy/change-to-all-branches.sh new file mode 100755 index 0000000..d4abf29 --- /dev/null +++ b/deploy/change-to-all-branches.sh @@ -0,0 +1,29 @@ +#!/usr/bin/env bash +# From branch test only: align origin/test, origin/pprod, origin/prod then deploy to test (import-v1, skipSetupHost). +# Use when you have already pushed to test and want to sync other branches and deploy test in one go. +set -euo pipefail + +if ! git rev-parse --is-inside-work-tree >/dev/null 2>&1; then + echo "[change-to-all-branches][ERROR] Not in a git repository" >&2 + exit 1 +fi + +PROJECT_ROOT="$(git rev-parse --show-toplevel)" +DEPLOY_DIR="$(cd "$(dirname "${BASH_SOURCE[0]:-$0}")" && pwd)" +if [[ "$(pwd)" != "$PROJECT_ROOT" ]]; then + cd "$PROJECT_ROOT" && exec "${DEPLOY_DIR}/$(basename "${BASH_SOURCE[0]:-$0}")" "$@" +fi + +current="$(git rev-parse --abbrev-ref HEAD)" +if [[ "$current" != "test" ]]; then + echo "[change-to-all-branches][ERROR] Must be on branch 'test' (current: '${current}')" >&2 + exit 1 +fi + +echo "[change-to-all-branches] Aligning branches..." +"$DEPLOY_DIR/branch-align.sh" test + +echo "[change-to-all-branches] Deploying test (--import-v1 --skipSetupHost, --no-sync-origin because we just pushed)..." +"$DEPLOY_DIR/scripts_v2/deploy.sh" test --import-v1 --skipSetupHost --no-sync-origin + +echo "[change-to-all-branches] OK" diff --git a/deploy/pousse.sh b/deploy/pousse.sh new file mode 100755 index 0000000..bbf4c58 --- /dev/null +++ b/deploy/pousse.sh @@ -0,0 +1,190 @@ +#!/usr/bin/env bash +set -euo pipefail + +if ! git rev-parse --is-inside-work-tree >/dev/null 2>&1; then + echo "[pousse][ERROR] Not in a git repository" >&2 + exit 1 +fi + +PROJECT_ROOT="$(git rev-parse --show-toplevel)" +DEPLOY_DIR="$(cd "$(dirname "${BASH_SOURCE[0]:-$0}")" && pwd)" +IA_DEV_ROOT="$(cd "$DEPLOY_DIR/.." && pwd)" +if [[ "$(pwd)" != "$PROJECT_ROOT" ]]; then + SCRIPT_ABS="${DEPLOY_DIR}/$(basename "${BASH_SOURCE[0]:-$0}")" + cd "$PROJECT_ROOT" && exec "$SCRIPT_ABS" "$@" +fi + +# Resolve project slug: .ia_project in repo root or IA_PROJECT env +PROJECT_SLUG="" +if [[ -f "$PROJECT_ROOT/.ia_project" ]]; then + PROJECT_SLUG="$(cat "$PROJECT_ROOT/.ia_project" | sed 's/[[:space:]]//g')" +fi +if [[ -z "$PROJECT_SLUG" && -n "${IA_PROJECT:-}" ]]; then + PROJECT_SLUG="$IA_PROJECT" +fi + +remote="origin" +bump_version=false + +usage() { + cat <<'EOF' +Usage: + ./deploy/pousse.sh [--remote ] [--bump-version] + + --bump-version Increment patch (third component) in VERSION before staging. + +Reads a full multi-line commit message from STDIN, then: +- if not in repo root: re-exec from repo root (standardized execution) +- build check (npm run build in each directory listed in projects/.json build_dirs, if any; exit on failure) +- git add -A +- git commit -F +- git push -u HEAD + +The current branch must already exist on the remote (e.g. origin/); otherwise the script refuses to push. + +Example: + ./deploy/pousse.sh <<'MSG' + Title + + **Motivations:** + - ... + + **Root causes:** + - ... + + **Correctifs:** + - ... + + **Evolutions:** + - ... + + **Pages affectées:** + - ... + MSG +EOF +} + +while [[ $# -gt 0 ]]; do + case "$1" in + --remote) + remote="$2" + shift 2 + ;; + --bump-version) + bump_version=true + shift + ;; + -h|--help) + usage + exit 0 + ;; + *) + echo "[pousse][ERROR] Unknown arg: $1" >&2 + usage >&2 + exit 1 + ;; + esac +done + +branch="$(git rev-parse --abbrev-ref HEAD)" +if [[ -z "$branch" || "$branch" == "HEAD" ]]; then + echo "[pousse][ERROR] Detached HEAD is not supported" >&2 + exit 1 +fi + +author_name="$(git config user.name || true)" +if [[ "$author_name" != "4NK" && "$author_name" != "Nicolas Cantu" ]]; then + echo "[pousse][ERROR] Refusing to commit: git user.name must be '4NK' or 'Nicolas Cantu' (got: '${author_name}')" >&2 + exit 1 +fi + +repo_root="$(git rev-parse --show-toplevel)" +# Build dirs from project config (projects/.json); skip if no config or no build_dirs +build_dirs=() +if [[ -n "$PROJECT_SLUG" && -f "$IA_DEV_ROOT/projects/${PROJECT_SLUG}.json" ]] && command -v jq >/dev/null 2>&1; then + while IFS= read -r d; do + [[ -n "$d" ]] && build_dirs+=( "$d" ) + done < <(jq -r '.build_dirs[]? // empty' "$IA_DEV_ROOT/projects/${PROJECT_SLUG}.json" 2>/dev/null) +fi +if [[ ${#build_dirs[@]} -gt 0 ]]; then + echo "[pousse] Build check (${#build_dirs[@]} dirs from project config)..." + for dir in "${build_dirs[@]}"; do + if [[ ! -d "${repo_root}/${dir}" ]]; then + echo "[pousse][WARN] Skipping build ${dir} (directory not found)" >&2 + continue + fi + echo "[pousse] Building ${dir}..." + (cd "${repo_root}/${dir}" && npm run build) || { + echo "[pousse][ERROR] Build failed in ${dir}" >&2 + exit 1 + } + done + echo "[pousse] Build check OK" +else + echo "[pousse] No build_dirs in project config (or no projects/.json / jq); skipping build check" +fi + +msg_file="$(mktemp -t pousse-commit-msg.XXXXXX)" +cleanup() { + rm -f "$msg_file" +} +trap cleanup EXIT + +cat >"$msg_file" || true +if [[ ! -s "$msg_file" ]]; then + echo "[pousse][ERROR] Empty commit message on STDIN" >&2 + exit 1 +fi + +if [[ "$bump_version" == "true" ]]; then + version_file="${repo_root}/VERSION" + if [[ ! -f "$version_file" ]]; then + echo "[pousse][ERROR] VERSION not found at ${version_file}" >&2 + exit 1 + fi + current="$(cat "$version_file" | sed 's/[[:space:]]//g')" + if ! [[ "$current" =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]; then + echo "[pousse][ERROR] VERSION format must be X.Y.Z (got: '${current}')" >&2 + exit 1 + fi + maj="${current%%.*}" + min="${current#*.}" + min="${min%%.*}" + patch="${current##*.}" + patch=$((patch + 1)) + new_version="${maj}.${min}.${patch}" + echo "$new_version" > "$version_file" + echo "[pousse] Bumped VERSION: ${current} -> ${new_version}" +fi + +# Stage all changes + +git add -A + +git_status_short="$(git status -sb)" +echo "$git_status_short" + +# Prevent committing potentially sensitive files +staged_files="$(git diff --cached --name-only || true)" +if [[ -n "$staged_files" ]]; then + if echo "$staged_files" | grep -Eiq '^(\.secrets/|\.env($|\.)|\.env\.|.*\.(key|pem|p12)$|.*credentials.*)'; then + echo "[pousse][ERROR] Refusing to commit: staged files look sensitive:" >&2 + echo "$staged_files" | grep -Ei '^(\.secrets/|\.env($|\.)|\.env\.|.*\.(key|pem|p12)$|.*credentials.*)' >&2 + exit 1 + fi +fi + +if git diff --cached --quiet; then + echo "[pousse] No staged changes to commit" >&2 + exit 0 +fi + +echo "[pousse] Staged changes:" +git diff --cached --stat + +git commit -F "$msg_file" +if ! git rev-parse "${remote}/${branch}" >/dev/null 2>&1; then + echo "[pousse][ERROR] Branch '${branch}' does not exist on remote '${remote}'. Refusing to push (would create a new remote branch). Create the branch on the remote first or push manually." >&2 + exit 1 +fi +git push -u "$remote" HEAD diff --git a/projects/README.md b/projects/README.md new file mode 100644 index 0000000..d690510 --- /dev/null +++ b/projects/README.md @@ -0,0 +1,38 @@ +# Project-specific configuration + +This repo (`ia_dev`) is intended to be used as a **git submodule** inside each project. Project-specific parameters are stored here in `projects/.json`. + +## Current project selection + +- **`IA_PROJECT`** (environment variable), or +- **`.ia_project`** file at the repository root (one line: the project slug, e.g. `lecoffreio`). Do not use angle brackets in the file. + +When running from a repo that has `ia_dev` as a submodule, the root is the parent repo; the script resolves `ia_dev` either as `./ia_dev` or `./deploy` (symlink to `ia_dev/deploy`). + +## Schema + +One JSON file per project in `projects/` named by the slug (e.g. `projects/lecoffreio.json`). + +| Field | Required | Description | +|-------|----------|-------------| +| `name` | yes | Human-readable project name | +| `project_path` | no | Relative path to project from ia_dev (e.g. `../lecoffre_ng_test`); used when running from ia_dev standalone | +| `build_dirs` | no | List of directories (relative to repo root) where `npm run build` is run before push. If missing or empty, build check is skipped | +| `version` | no | Version/bump configuration | +| `version.package_json_paths` | no | List of paths (relative to repo root) to `package.json` files to update on bump | +| `version.splash_app_name` | no | App name used in splash message template | +| `mail` | no | Mail/imap bridge config | +| `git` | no | Git hosting: `wiki_url`, `ticketing_url`, `token_file` | + +## Example (minimal) + +```json +{ + "name": "My App", + "build_dirs": ["backend", "frontend"] +} +``` + +## Example (full) + +See `projects/lecoffreio.json`. diff --git a/projects/lecoffreio.json b/projects/lecoffreio.json new file mode 100644 index 0000000..c5cce05 --- /dev/null +++ b/projects/lecoffreio.json @@ -0,0 +1,25 @@ +{ + "name": "Lecoffre.io", + "project_path": "../lecoffre_ng_test", + "build_dirs": [ + "lecoffre-ressources-dev", + "lecoffre-back-main", + "lecoffre-front-main" + ], + "version": { + "package_json_paths": [ + "lecoffre-back-main/package.json", + "lecoffre-front-main/package.json" + ], + "splash_app_name": "LeCoffre.io" + }, + "mail": { + "email": "ai.support.lecoffreio@4nkweb.com", + "imap_bridge_env": ".secrets/gitea-issues/imap-bridge.env" + }, + "git": { + "wiki_url": "https://git.4nkweb.com/4nk/lecoffre_ng/wiki", + "ticketing_url": "https://git.4nkweb.com/4nk/lecoffre_ng/issues", + "token_file": ".secrets/gitea-issues/token" + } +} \ No newline at end of file