4NK/cursor
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial: desk + ncantu placeholder + per-project cursor configs

Browse Source 
**Motivations:**
- Centraliser les fichiers Cursor (rules, skills, agents, commands, hooks) par user et par projet

**Root causes:**
- N/A

**Correctifs:**
- N/A

**Evolutions:**
- desk: rules, skills-cursor, agents, commands, hooks, argv/hooks/mcp.json
- ncantu: README placeholder
- 4NK_node, algo, builazoo, ia_local, lecoffre_ng, lecoffre_ng_pprod, lecoffre_ng_test: .cursor contents

**Pages affectées:**
- cursor/desk/, cursor/ncantu/, cursor/<project>/
This commit is contained in:
Nicolas Cantu
2026-03-03 23:29:29 +01:00
commit 785868b53b
114 changed files with 6455 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

116
lecoffre_ng/rules/cloture-evolution.mdc Normal file
View File

@@ -0,0 +1,116 @@
---
description: Workflow de clôture à exécuter à la fin de chaque évolution ou correction
alwaysApply: true
model: inherit
---
# Clôture évolution / correction
À la fin de toute évolution ou correction, exécuter ce workflow dans l'ordre. Boucler chaque bloc jusqu'à stabilisation (rien à optimiser). **Ne jamais produire une réponse partielle** : répondre à toutes les questions de clôture et lancer les subagents/plans concernés.
## Clôture obligatoire après évolution/correction
Après chaque évolution ou correction, la réponse doit inclure **obligatoirement** :
1. **Helpers :** des helpers sont-ils à utiliser ailleurs dans le code ? Des helpers existants auraient-ils pu être utilisés ? Y a-t-il des doublons de helpers ?
- Si oui : factoriser, réutiliser les helpers existants et supprimer/absorber les doublons immédiatement.
2. **Texte i18n :** les textes sont ils centralisés ? `.secrets/<env>/env-full-<env>-for-bdd-injection.txt` est il à jour ? et test, pprod, prod ?
- Si non : fait le
3. **Fallback :** As tu ajouté des fallbacks ?
- Si oui : supprime les fallback, si il y en avait avant et que tu peux les enlever sans regression, fait le.
4. **Modifications similaires :** y a-t-il des modifications similaires à produire ailleurs dans le code ?
- Si oui : les implémenter immédiatement.
5. **Optimisation / mutualisation / centralisation :** y a-t-il des optimisations possibles ?
- Si oui : les implémenter immédiatement.
6. **Sécurité :** Des failles des sécurité sont elles posibles ?
- Si oui : corrige les
7. **Code mort :** le code mort est-il nettoyé ?
- Si non : le nettoyer immédiatement.
8. **Lint :** les fichiers corrigés sont-ils exempts d’erreurs de lint ?
- Réponse attendue : constat uniquement, **ne pas corriger** ici.
9. **Types :** les vérifications de types du projet sont-elles OK ?
- Si non : corriger, même si l’erreur ne vient pas des modifications en cours.
10. **Compilation :** le projet compile-t-il ?
- Si non : corriger, même si l’erreur ne vient pas des modifications en cours.
11. **Documentation :** Rationaliser la documentation
Si la réponse déclenche de nouvelles actions, cette checklist doit être rejouée en boucle jusqu’à stabilisation (code propre), avec lancement des subagents nécessaires pour exécuter les tâches.
## Orchestration des subagents et plans
Après une correction ou évolution, lancer en boucle jusqu'à succès :
- **Lint** : Si erreurs détectées → `mcp_task` generalPurpose avec prompt fix-lint (ou exécution manuelle) ; boucler jusqu'à 0 erreur.
- **Déploiement** : Si déploiement requis et validé → `mcp_task` subagent_type="deploy" avec env ; en cas d'échec, orchestrer la correction (investigation, correctif, relance) sans s'arrêter.
- **Tests** : Compléter et lancer les tests concernés.
Ne pas s'arrêter au rapport d'échec d'un subagent : prendre le relais, corriger, relancer.
## 1. Tests
- Compléter les tests manquants (user stories)
- Lancer les tests, corriger les échecs, boucler
- Rationaliser les tests (supprimer doublons, mutualiser)
## 2. Types
- Chercher si les types sont à optimiser (`npm run typecheck`, `npx tsc --noEmit`)
- Si oui, implémenter et boucler jusqu'à rien à optimiser
## 3. Reproductions
- Chercher si des changements similaires doivent être reproduits ailleurs
- Si oui, implémenter et boucler jusqu'à rien à reproduire
## 4. Factorisation / optimisation
- Chercher factorisation, mutualisation, centralisation possibles
- Si oui, implémenter et boucler jusqu'à rien à optimiser
## 5. Lint
- Chercher erreurs de lint (`npm run lint`, `ReadLints`)
- Si oui, corriger et boucler jusqu'à rien à corriger
- Sinon, vérifier si on peut être plus exigeant sur la qualité
## 6. Sécurité
- Chercher améliorations de sécurité possibles (`docs/CODE_SECURITY.md`)
- Si oui, implémenter et boucler jusqu'à rien à améliorer
## 7. Documentation
- Mettre à jour la doc : REX + descriptions (OPERATIONS.md, FRONTEND.md, CODE_STANDARDS.md selon périmètre)
- Rationaliser la doc (supprimer doublons, fusionner)
## 8. Déploiement (après validation utilisateur)
- Le script deploy.sh exécute un hook pre-deploy qui arrête (SIGTERM) les processus concurrents dont le cwd est dans le projet, puis suggère de relancer /fix-lint après le déploiement.
- Demander validation avant déploiement
- Déployer sur l'environnement de la branche locale (`deploy/scripts/build-and-deploy.sh`)
- Analyser les logs du déploiement
- Si corrections nécessaires, implémenter et boucler
- Si optimisations déploiement possibles, implémenter et boucler
- Si améliorations sécurité déploiement possibles, implémenter et boucler
- Mettre à jour la doc déploiement : REX + descriptions puis rationaliser
## Plan et commande
- **Plan** : `~/.cursor/plans/workflow-cloture-evolution.plan.md` (niveau utilisateur)
- **Commande** : `/cloture-evolution` (déclenche l'exécution du plan)
## Outils
- Lint : `mcp_task` generalPurpose avec prompt détaillé (fix-lint via mcp_task non fonctionnel)
- Déploiement : `mcp_task` subagent_type="deploy" ou exécution manuelle du script
- Tests : MCP browser, `user_stories/`

38
lecoffre_ng/rules/development-autonomy.mdc Normal file
View File

@@ -0,0 +1,38 @@
---
description: Règles pour l'autonomie du développement avec user stories, patterns, qualité, sécurité et tests
alwaysApply: true
model: inherit
---
# Règles pour l'Autonomie du Développement
## 📚 Références Documentation
### User Stories
* **Index :** Consulter `user_stories/INDEX.md` pour la liste complète des 43 user stories et leurs dépendances
* **Structure :** Chaque user story (`US*.md`) documente un parcours utilisateur avec actions précises, vérifications backend, valeurs de test
* **Autonomie :** Utiliser les user stories comme référence pour comprendre les parcours, créer les tests, implémenter les fonctionnalités
* **Comptes de test :** Consulter `user_stories/TEST_ACCOUNTS.md`
* **Scripts :** Utiliser `user_stories/scripts/prepare-test-data.sh`
### Patterns et Architecture
* **Backend Patterns :** Consulter `docs/CODE_STANDARDS.md` (section Patterns) pour les helpers centralisés (errorHandlers, errorLoggers, userHelpers)
* **Frontend Patterns :** Utiliser les hooks existants (useApiClient) et suivre le pattern Controller/Vue
* **Architecture :** Découper les features complexes en hooks contrôleurs + sous-composants présentateurs
### Qualité et Sécurité
* **Qualité :** Consulter `docs/CODE_STANDARDS.md` - Respecter les limites (250 lignes/fichier, 40 lignes/fonction)
* **Sécurité :** Consulter `docs/CODE_SECURITY.md` - Validation, secrets en base, pas de logging sensible
### Tests
* **Tests Browser :** Utiliser les outils MCP browser pour les tests E2E
* **Navigation :** TOUJOURS utiliser la navigation du site, JAMAIS construire d'URLs manuellement
* **User Stories :** Référencer les user stories pour comprendre les parcours à tester
### Documentation Fonctionnelle
* **Référence :** Consulter `docs/CODE_STANDARDS.md` et `docs/FRONTEND.md` pour la structure et les fichiers du projet

6
lecoffre_ng/rules/error-fixing.mdc Normal file
View File

@@ -0,0 +1,6 @@
---
alwaysApply: true
model: inherit
---
corriger l'erreur et jamais contourner

13
lecoffre_ng/rules/investigation-analysis.mdc Normal file
View File

@@ -0,0 +1,13 @@
---
description: Règles d'investigation et d'analyse des problèmes (logs, données)
alwaysApply: true
model: inherit
---
# Investigation et analyse des problèmes
## Logs et données
* Analyser les problèmes avec les logs des backends (journalctl, fichiers de logs dans `logs/`)
* Analyser les données en base pour les investigations
* Les services sont host-native (pas de Docker) ; les logs sont accessibles via journalctl ou les fichiers dans `logs/`

230
lecoffre_ng/rules/rules.mdc Normal file
View File

@@ -0,0 +1,230 @@
---
description: Règles pour tous aussi pour l'IA et pour Cursor
alwaysApply: true
model: inherit
---
# 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é
* **Clôture corrections/évolutions :** À la fin de toute correction ou évolution, répondre systématiquement aux questions suivantes et implémenter les améliorations identifiées :
* Modifications similaires à produire ailleurs dans le code ?
* Optimisations, mutualisations ou centralisations possibles ?
* Fichiers corrigés exempts d'erreurs de lint ?
* Vérification des types du projet OK ?
* Projet compile ?
* Si ces réponses ne sont pas fournies : les produire si pertinent et implémenter les améliorations identifiées (mutualisation, parties impactées).
* 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.
### 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 utiliser 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 dédiée) et commentaire // TODO(MAX_LINES) dans le code (voir docs/CODE_STANDARDS.md).
* **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 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.