159 lines
7.9 KiB
Markdown
159 lines
7.9 KiB
Markdown
---
|
||
title: "Contexte du Projet"
|
||
description: Comment project-context.md guide les agents IA avec les règles et préférences de votre projet
|
||
sidebar:
|
||
order: 12
|
||
---
|
||
|
||
Le fichier `project-context.md` est le guide d’implémentation de votre projet pour les agents IA. Similaire à une « constitution » dans d’autres systèmes de développement, il capture les règles, les patterns et les préférences qui garantissent une génération de code cohérente à travers tous les workflows.
|
||
|
||
## Ce Qu’il Fait
|
||
|
||
Les agents IA prennent constamment des décisions d’implémentation — quels patterns suivre, comment structurer le code, quelles conventions utiliser. Sans guidance claire, ils peuvent :
|
||
- Suivre des bonnes pratiques génériques qui ne correspondent pas à votre codebase
|
||
- Prendre des décisions incohérentes selon les différentes stories
|
||
- Passer à côté d’exigences ou de contraintes spécifiques au projet
|
||
|
||
Le fichier `project-context.md` résout ce problème en documentant ce que les agents doivent savoir dans un format concis et optimisé pour les LLM.
|
||
|
||
## Comment Ça Fonctionne
|
||
|
||
Chaque workflow d’implémentation charge automatiquement `project-context.md` s’il existe. Le workflow architecte le charge également pour respecter vos préférences techniques lors de la conception de l’architecture.
|
||
|
||
**Chargé par ces workflows :**
|
||
- `bmad-create-architecture` — respecte les préférences techniques pendant la phase de solutioning
|
||
- `bmad-create-story` — informe la création de stories avec les patterns du projet
|
||
- `bmad-dev-story` — guide les décisions d’implémentation
|
||
- `bmad-code-review` — valide par rapport aux standards du projet
|
||
- `bmad-quick-dev` — applique les patterns lors de l’implémentation des spécifications techniques
|
||
- `bmad-sprint-planning`, `bmad-retrospective`, `bmad-correct-course` — fournit le contexte global du projet
|
||
|
||
## Quand Le Créer
|
||
|
||
Le fichier `project-context.md` est utile à n’importe quel stade d’un projet :
|
||
|
||
| Scénario | Quand Créer | Objectif |
|
||
|------------------------------------------|-----------------------------------------------------|---------------------------------------------------------------------------------------|
|
||
| **Nouveau projet, avant l’architecture** | Manuellement, avant `bmad-create-architecture` | Documenter vos préférences techniques pour que l’architecte les respecte |
|
||
| **Nouveau projet, après l’architecture** | Via `bmad-generate-project-context` ou manuellement | Capturer les décisions d’architecture pour les agents d’implémentation |
|
||
| **Projet existant** | Via `bmad-generate-project-context` | Découvrir les patterns existants pour que les agents suivent les conventions établies |
|
||
| **Projet Quick Dev** | Avant ou pendant `bmad-quick-dev` | Garantir que l’implémentation rapide respecte vos patterns |
|
||
|
||
:::tip[Recommandé]
|
||
Pour les nouveaux projets, créez-le manuellement avant l’architecture si vous avez de fortes préférences techniques. Sinon, générez-le après l’architecture pour capturer ces décisions.
|
||
:::
|
||
|
||
## Ce Qu’il Contient
|
||
|
||
Le fichier a deux sections principales :
|
||
|
||
### Pile Technologique & Versions
|
||
|
||
Documente les frameworks, langages et outils utilisés par votre projet avec leurs versions spécifiques :
|
||
|
||
```markdown
|
||
## Pile Technologique & Versions
|
||
|
||
- Node.js 20.x, TypeScript 5.3, React 18.2
|
||
- State: Zustand (pas Redux)
|
||
- Testing: Vitest, Playwright, MSW
|
||
- Styling: Tailwind CSS avec design tokens personnalisés
|
||
```
|
||
|
||
### Règles Critiques d’Implémentation
|
||
|
||
Documente les patterns et conventions que les agents pourraient autrement manquer :
|
||
|
||
```markdown
|
||
|
||
## Règles Critiques d’Implémentation
|
||
|
||
**Configuration TypeScript :**
|
||
- Mode strict activé — pas de types `any` sans approbation explicite
|
||
- Utiliser `interface` pour les APIs publiques, `type` pour les unions/intersections
|
||
|
||
**Organisation du Code :**
|
||
- Composants dans `/src/components/` avec fichiers `.test.tsx` co-localisés
|
||
- Utilitaires dans `/src/lib/` pour les fonctions pures réutilisables
|
||
- Les appels API utilisent le singleton `apiClient` — jamais de fetch direct
|
||
|
||
**Patterns de Tests :**
|
||
- Les tests unitaires se concentrent sur la logique métier, pas sur les détails d’implémentation
|
||
- Les tests d’intégration utilisent MSW pour simuler les réponses API
|
||
- Les tests E2E couvrent uniquement les parcours utilisateurs critiques
|
||
|
||
**Spécifique au Framework :**
|
||
- Toutes les opérations async utilisent le wrapper `handleError` pour une gestion cohérente des erreurs
|
||
- Les feature flags sont accessibles via `featureFlag()` de `@/lib/flags`
|
||
- Les nouvelles routes suivent le modèle de routage basé sur les fichiers dans `/src/app/`
|
||
```
|
||
|
||
Concentrez-vous sur ce qui est **non évident** — des choses que les agents pourraient ne pas déduire en lisant des extraits de code. Ne documentez pas les pratiques standard qui s’appliquent universellement.
|
||
|
||
## Création du Fichier
|
||
|
||
Vous avez trois options :
|
||
|
||
### Création Manuelle
|
||
|
||
Créez le fichier `_bmad-output/project-context.md` et ajoutez vos règles :
|
||
|
||
```bash
|
||
# Depuis la racine du projet
|
||
mkdir -p _bmad-output
|
||
touch _bmad-output/project-context.md
|
||
```
|
||
|
||
Éditez-le avec votre pile technologique et vos règles d’implémentation. Les workflows architecture et implémentation le trouveront et le chargeront automatiquement.
|
||
|
||
### Générer Après L’Architecture
|
||
|
||
Exécutez le workflow `bmad-generate-project-context` après avoir terminé votre architecture :
|
||
|
||
```bash
|
||
bmad-generate-project-context
|
||
```
|
||
|
||
Cela analyse votre document d’architecture et vos fichiers projet pour générer un fichier de contexte capturant les décisions prises.
|
||
|
||
### Générer Pour Les Projets Existants
|
||
|
||
Pour les projets existants, exécutez `bmad-generate-project-context` pour découvrir les patterns existants :
|
||
|
||
```bash
|
||
bmad-generate-project-context
|
||
```
|
||
|
||
Le workflow analyse votre codebase pour identifier les conventions, puis génère un fichier de contexte que vous pouvez examiner et affiner.
|
||
|
||
## Pourquoi C’est Important
|
||
|
||
Sans `project-context.md`, les agents font des suppositions qui peuvent ne pas correspondre à votre projet :
|
||
|
||
| Sans Contexte | Avec Contexte |
|
||
|----------------------------------------------------|-------------------------------------------------|
|
||
| Utilise des patterns génériques | Suit vos conventions établies |
|
||
| Style incohérent selon les stories | Implémentation cohérente |
|
||
| Peut manquer les contraintes spécifiques au projet | Respecte toutes les exigences techniques |
|
||
| Chaque agent décide indépendamment | Tous les agents s’alignent sur les mêmes règles |
|
||
|
||
C’est particulièrement important pour :
|
||
- **Quick Dev** — saute le PRD et l’architecture, le fichier de contexte comble le vide
|
||
- **Projets d’équipe** — garantit que tous les agents suivent les mêmes standards
|
||
- **Projets existants** — empêche de casser les patterns établis
|
||
|
||
## Édition et Mise à Jour
|
||
|
||
Le fichier `project-context.md` est un document vivant. Mettez-le à jour quand :
|
||
|
||
- Les décisions d’architecture changent
|
||
- De nouvelles conventions sont établies
|
||
- Les patterns évoluent pendant l’implémentation
|
||
- Vous identifiez des lacunes dans le comportement des agents
|
||
|
||
Vous pouvez l’éditer manuellement à tout moment, ou réexécuter `bmad-generate-project-context` pour le mettre à jour après des changements significatifs.
|
||
|
||
:::note[Emplacement du Fichier]
|
||
L’emplacement par défaut est `_bmad-output/project-context.md`. Les workflows le recherchent là, et vérifient également `**/project-context.md` n’importe où dans votre projet.
|
||
:::
|