_Assistant_Lead_Tech/70_templates/projet_CLAUDE.md

CLAUDE.md — Contexte et mémoire du projet {{PROJECT_NAME}}

Ce fichier sert de mémoire active du projet.

Ce projet hérite des règles globales définies dans Lead_tech.

Dans l’environnement de travail, Lead_tech est généralement accessible via un symlink local pointant vers le repository contenant les règles globales.

Pour les agents, la porte d’entrée de ces règles est :

• ~/CLAUDE.md : symlink vers ~/Lead_tech/CLAUDE.md
• ~/AGENTS.md : symlink vers ~/Lead_tech/CLAUDE.md

Ce fichier sert de point d’entrée vers la base de connaissance globale (patterns, anti-patterns, décisions d’architecture, debug).

Les règles définies dans ce fichier complètent ces règles globales.

Ce mécanisme permet au projet de rester portable entre environnements (Mac, NUC, serveur, etc.) tout en conservant un socle de règles global partagé.

Hiérarchie des règles :

1. contraintes réelles du code et de l’infrastructure
2. règles définies dans ce fichier (projet)
3. règles globales Lead_tech

Ce fichier doit permettre à un agent (Claude, Codex, etc.) de comprendre rapidement :

• la stack
• les conventions importantes
• les patterns appliqués
• l’état actuel du projet
• les pièges connus

---

Contexte du projet

Nom :
Objectif :
Statut : (exploration / MVP / production / maintenance)

Description rapide du produit ou du service.

---

Stack technique

• backend :
• frontend :
• base de données :
• cache :
• infra :
• tests :

Préciser les frameworks et versions importantes.

Exemple :

• NestJS strict
• Next.js / Expo
• PostgreSQL
• Prisma

---

Architecture du projet

Structure principale du repo.

Exemple :

apps/
  api/
  web/
packages/
  contracts/
infra/

Règles importantes :

• responsabilités de chaque dossier
• ce qui doit rester partagé
• ce qui doit rester local à une app

---

Cartographie rapide du code

Objectif : permettre à un agent de comprendre où se trouvent les responsabilités principales du projet sans scanner tout le repository.

Exemple :

Backend principal → apps/api

Frontend web → apps/web

Contrats partagés (types / schémas / validation) → packages/contracts

Infrastructure / Docker / déploiement → infra

Tests → apps/api/tests

Principes :

• la logique métier doit rester côté backend
• les contrats doivent être centralisés
• éviter la duplication de logique entre apps

Adapter cette cartographie à la structure réelle du projet.

---

Commandes du projet

Lister ici les commandes principales permettant de travailler sur le projet.

Objectif : permettre à un agent ou à un développeur de comprendre rapidement comment installer, lancer et tester l’application.

Exemple :

Installation :

npm install

Lancer le backend :

npm run dev:api

Lancer le frontend :

npm run dev:web

Tests :

npm run test

Build :

npm run build

Ajouter également si nécessaire :

• commandes de migration de base de données
• commandes de seed
• commandes Docker
• commandes d’environnement local

---

Patterns critiques du projet

Lister ici les patterns spécifiques à ce projet.

Ils complètent les patterns globaux définis dans Lead_tech.

Exemples :

• contracts-first
• architecture hexagonale
• structure des modules
• conventions d’erreurs API

Chaque pattern doit expliquer pourquoi il existe.

---

Conventions spécifiques

Conventions propres au projet.

Exemples :

• gestion des erreurs
• nommage des modules
• structure des services
• conventions Prisma / ORM

---

Statut du projet

Décrire l’état actuel du développement.

Exemple :

Epic / milestone en cours :

• Epic 1 : done
• Epic 2 : in-progress

Ou bien :

• MVP en production
• refactor backend en cours

---

Leçons apprises

Capitaliser ici les apprentissages importants du projet.

Exemples :

• décisions d’architecture validées
• erreurs rencontrées
• améliorations à appliquer sur les prochaines features

---

Dette technique

Lister la dette technique identifiée.

Format conseillé :

• description
• niveau (LOW / MEDIUM / HIGH)

Exemple :

• tests E2E incomplets (MEDIUM)
• refactor service auth nécessaire (LOW)

---

Points sensibles

Parties du projet nécessitant une vigilance particulière.

Exemples :

• sécurité
• authentification
• logique financière
• migrations de base de données

---

Références

Voir également :

• règles globales : Lead_tech/CLAUDE.md
• patterns backend
• patterns frontend
• debug et post-mortems

---

Mise à jour

Ce fichier doit être mis à jour lorsque :

• une décision d’architecture importante est prise
• un pattern spécifique apparaît
• une dette technique significative est identifiée

Si une information devient utile à plusieurs projets, la remonter dans Lead_tech via la procédure de capitalisation décrite ci-dessous.

---

Capitalisation vers Lead_tech

Zone de dépôt

Toute proposition doit être écrite dans :

$LEADTECH/95_a_capitaliser.md

$LEADTECH est résolu automatiquement par le shell sur Mac et sur le NUC.

En pratique :

• Mac : ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md
• NUC : /srv/projects/_Assistant_Lead_Tech/95_a_capitaliser.md

Quand capitaliser

• résolution d'un bug difficile
• pattern réutilisable identifié
• anti-pattern rencontré
• décision d'architecture structurante

Format

DATE — PROJET

FILE_UPDATE_PROPOSAL
Fichier cible : <10_backend_patterns_valides.md | 10_frontend_patterns_valides.md | 10_ux_patterns_valides.md | 10_product_patterns_valides.md | 10_n8n_patterns_valides.md | 10_backend_risques_et_vigilance.md | 10_frontend_risques_et_vigilance.md | 10_ux_risques_et_vigilance.md | 10_n8n_nodes_a_risques.md | 10_conventions_redaction.md | 40_decisions_et_archi.md | 90_debug_et_postmortem.md>

Pourquoi :
<raison en 1-2 phrases>

Proposition :
<contenu suggéré>

Règle

Les agents écrivent dans 95_a_capitaliser.md uniquement. Jamais directement dans les fichiers de connaissance validée. La validation et l'intégration sont faites par le développeur.