@the-bearded-bear/claude-craft 8.23.3 → 8.26.0-next.2a54921

package/Dev/i18n/fr/Workflow/commands/auto-sprint.md

@@ -1,6 +1,6 @@
 ---
 description: Orchestrateur de sprint de bout en bout (démarrage -> décomposition -> validation -> implémentation -> PR -> CI -> revue -> rétro -> merge)
-argument-hint: "<N> [--auto-merge] [--max-fix-attempts=2] [--max-workers=3] [--base=main] [--dry-run] [--overnight]"
+argument-hint: "<N> [--from-prd] [--auto-merge] [--max-fix-attempts=2] [--max-workers=3] [--base=main] [--dry-run] [--overnight]"
 ---
 
 # Auto Sprint — Orchestrateur de Sprint de Bout en Bout
@@ -14,8 +14,8 @@ que `/team:sprint`) afin d'éviter l'imbrication d'Agent Teams.
 Cette commande automatise ce qui nécessitait auparavant six commandes manuelles avec un `/clear` entre chaque :
 
 ```
-/workflow:start N -> /project:decompose-tasks 00N -> /gate:validate-sprint 00N
--> /team:sprint "sprint-00N" -> /workflow:review N -> /workflow:retro N
+/workflow:start N -> /workflow:start N --tasks-only -> /gate:check sprint 00N
+-> /workflow:implement N -> /workflow:review N -> /workflow:retro N
 ```
 
 …et ajoute : branche, commit, Pull Request, surveillance CI et merge.
@@ -25,6 +25,7 @@ Cette commande automatise ce qui nécessitait auparavant six commandes manuelles
 $ARGUMENTS
 
 - `<N>` : Numéro du sprint (ex. `5`). **Obligatoire.**
+- `--from-prd` : Avant la Phase 1, exécute `/workflow:plan --only=backlog` (sous-agent) pour générer le backlog depuis `project-management/prd.md`, puis poursuit le pipeline normal.
 - `--auto-merge` : Merge automatiquement dès que la CI est verte et que la DoD est validée. **Défaut : DÉSACTIVÉ** — la
   commande se met en pause et attend un GO humain explicite avant de merger (respecte la règle de « revue obligatoire »,
   règle 09, et le principe Karpathy « pas d'auto-merge sans revue humaine »).
@@ -52,7 +53,7 @@ la bonne forme à chaque phase :
 | Phase | Forme attendue |
 |-------|----------------|
 | `start`, `review`, `retro` | `N` brut (ex. `5`) |
-| `decompose-tasks` | `00N` avec zéros (ex. `005`) |
+| `start --tasks-only` | `N` nu (ex. `5`) |
 | `team:sprint` (implémentation) | nom libre du sprint résolu depuis le dossier / fichier de statut |
 
 Résoudre le dossier du sprint via glob `project-management/sprints/sprint-{N}-*/` et lire
@@ -64,12 +65,16 @@ Résoudre le dossier du sprint via glob `project-management/sprints/sprint-{N}-*
 
 1. Parser `<N>` et les drapeaux. Dériver `N`, `00N`, le slug et le nom du sprint.
 2. Résoudre `project-management/sprints/sprint-{N}-*/` et `.bmad/sprint-status.yaml`.
-   **Abandonner** si aucun des deux n'existe (rien à orchestrer).
+   Si aucun des deux n'existe, le sprint est nouveau : la Phase 1 crée les deux (pas d'abandon).
 3. Vérifier que l'arbre de travail est propre et que `--base` est à jour. **Abandonner** si sale.
 4. Créer / basculer sur la branche feature `feature/sprint-{N}-<slug>` depuis `--base`
    (règle 09 : `main` toujours déployable — ne jamais travailler directement sur la branche de base).
 5. Si `--dry-run` : afficher le contexte résolu + les 9 phases planifiées et **s'arrêter ici**.
 
+### Phase 0b — Backlog depuis le PRD (sous-agent, uniquement avec `--from-prd`)
+
+> « Lis `.claude/commands/workflow/plan.md` et exécute `/workflow:plan --only=backlog` (entrée : `project-management/prd.md`). Retourne un résumé concis et les fichiers créés. »
+
 ### Phase 1 — Démarrage (sous-agent)
 
 Instancier un sous-agent isolé :
@@ -80,13 +85,13 @@ Instancier un sous-agent isolé :
 
 ### Phase 2 — Décomposition (sous-agent)
 
-> « Lis `.claude/commands/project/decompose-tasks.md` et exécute-le pour le sprint **00N**.
-> Génère les fichiers de tâches par US, `task-board.md`, et le graphe de dépendances.
+> « Lis `.claude/commands/workflow/start.md` (`/workflow:start {N} --tasks-only`) et exécute-le pour le sprint **N**.
+> Génère les fichiers `tasks/TASK-*.md`, `board.md`, et le graphe de dépendances.
 > Retourne un résumé concis et les fichiers créés. »
 
 ### Phase 3 — Validation du gate (sous-agent + boucle de correction automatique)
 
-> « Lis `.claude/commands/gate/validate-sprint.md` et exécute-le pour le sprint **00N**.
+> « Lis `.claude/commands/gate/check.md` (gate `sprint`) et exécute-le pour le sprint **00N**.
 > Retourne PASS/FAIL, le score et la liste des critères échoués. »
 
 **En cas d'ÉCHEC → boucle de correction automatique** (jusqu'à `--max-fix-attempts`) :
@@ -97,6 +102,8 @@ Instancier un sous-agent isolé :
 
 ### Phase 4 — Implémentation (tu = chef d'orchestre)
 
+> Équivalent à `/workflow:implement --parallel N` (qui délègue à `/team:sprint`).
+
 Prendre **directement le rôle de conducteur `/team:sprint`** (ne **pas** instancier un Agent Team imbriqué) :
 
 1. Lire `.bmad/sprint-status.yaml` ; filtrer les stories à `ready-for-dev`.
@@ -195,3 +202,4 @@ Phase              | Statut | Notes
 - **L'auto-merge est opt-in** et intentionnellement conditionné à un drapeau.
 - **Docker est obligatoire** pour les tests (CLAUDE.md du projet).
 - L'isolation des sous-agents remplace `/clear` — garder chaque rapport de sous-agent concis.
+- Pour la variante parallèle Agent Teams qui rédige aussi les stories avec revue croisée, utiliser `/team:delivery`.

package/Dev/i18n/fr/Workflow/commands/design.md

@@ -1,7 +1,11 @@
 ---
 name: workflow-design
-description: "Exécuter la phase de Conception (Solutioning) - spécification technique et architecture"
+description: "Exécuter la phase de Conception (Solutioning) - générer la spécification technique (défaut) ou la constitution du projet (--constitution)"
+argument-hint: "[--constitution] [--continue]"
 arguments:
+  - name: constitution
+    description: Générer la constitution du projet (project-management/constitution.md) au lieu de la spec technique
+    required: false
   - name: continue
     description: Reprendre là où on s'est arrêté
     required: false
@@ -11,273 +15,208 @@ arguments:
 
 ## Mission
 
-Exécuter la phase de Conception (Solutioning) du workflow de développement. Cette phase se concentre sur la création de la Spécification Technique, la conception de l'architecture et la documentation des décisions techniques clés.
+Exécuter la phase de Conception (Solutioning) : transformer le PRD en spécification technique, diagrammes d'architecture, modèle de données, conception d'API et ADR. Avec `--constitution`, consigner à la place les décisions immuables du projet dans une Constitution de projet.
+
+## Usage
+
+| Invocation | Action | Remplace |
+|------------|--------|----------|
+| `/workflow:design` | Lit `project-management/prd.md`, écrit `project-management/tech-spec.md` + fichiers d'architecture + ADR | `/workflow:design` |
+| `/workflow:design --constitution` | Écrit `project-management/constitution.md` (décisions immuables, utilisée par `/gate:check alignment`) | `/workflow:design --constitution` |
+| `/workflow:design --continue` | Reprend une session de conception interrompue | - |
+
+Ordre canonique des documents : PRD → spec technique → backlog → sprint.
 
 ## Quand utiliser
 
 - Tracks **Standard** et **Enterprise**
-- Après la complétion de `/workflow:plan`
-- Quand le PRD et le backlog sont prêts
+- Après `/workflow:plan --only=prd`
+- `--constitution` : au démarrage du projet (ou dès que des décisions doivent être verrouillées)
 
 ## Prérequis
 
-- Le PRD existe dans `project-management/prd.md`
-- Le backlog existe dans `project-management/backlog/`
-
-## Mode Plan
+- Le PRD existe dans `project-management/prd.md` (`--constitution` : uniquement des sources optionnelles, voir ci-dessous)
+- Stack technique identifiée (demandée de façon interactive pour un nouveau projet)
 
-> **Le mode plan est recommandé.** Claude active le mode plan pour structurer l'approche, identifier les dépendances et présenter une stratégie de génération avant de créer les artefacts.
+## Plan Mode
 
-## Workflow
+> **Le plan mode est obligatoire.** Claude active le plan mode pour analyser le code impacté, proposer une stratégie de génération et attendre votre validation avant de créer des artefacts.
 
-### Étape 1 : Mise en place de la conception
-
-```
-╔══════════════════════════════════════════════════════════╗
-║              PHASE DE CONCEPTION - DÉMARRAGE              ║
-╠══════════════════════════════════════════════════════════╣
-║ Track: Standard                                           ║
-║ Phase: 3 sur 4 - Conception (Solutioning)                 ║
-║                                                           ║
-║ Objectifs :                                               ║
-║ • Créer la Spécification Technique à partir du PRD        ║
-║ • Concevoir l'architecture système (diagrammes C4)        ║
-║ • Définir le modèle de données et la conception API       ║
-║ • Documenter les Architecture Decision Records (ADR)      ║
-║ • Planifier la stratégie de test                          ║
-╚══════════════════════════════════════════════════════════╝
-```
+## Workflow : Spec technique (défaut)
 
-### Étape 2 : Chargement des artefacts de planification
+### Étape 1 : Analyse du PRD
 
 ```
 ╔══════════════════════════════════════════════════════════╗
-║              CHARGEMENT DES ARTEFACTS DE PLANIFICATION    ║
-╠══════════════════════════════════════════════════════════╣
-║                                                           ║
-║ Analyse du PRD :                                         ║
-║ ├── ✅ prd.md chargé                                     ║
+║           PHASE DE CONCEPTION - DÉMARRAGE                 ║
+║ Track : Standard | Phase : 3 sur 4 - Design (Solutioning) ║
+║ Chargement de project-management/prd.md ...               ║
 ║ ├── Exigences fonctionnelles : 12                         ║
 ║ ├── Exigences non fonctionnelles : 8                      ║
 ║ └── Intégrations requises : 2                             ║
-║                                                           ║
-║ Résumé du backlog :                                      ║
-║ ├── ✅ backlog/ chargé                                   ║
-║ ├── EPICs : 4                                            ║
-║ ├── User Stories : 18                                     ║
-║ └── Story Points totaux : 89                              ║
-║                                                           ║
-║ Contraintes (si Enterprise) :                             ║
-║ └── ✅ analysis/constraints.md chargé                    ║
-║                                                           ║
 ╚══════════════════════════════════════════════════════════╝
 ```
 
-### Étape 3 : Tâches de conception
+Extraire du PRD : exigences fonctionnelles (`FR-xxx`), exigences non fonctionnelles (performance, sécurité, scalabilité), personas et parcours, contraintes et hypothèses, intégrations. Si `project-management/analysis/constraints.md` existe (Enterprise), le charger aussi.
+
+### Étape 2 : Analyse de la codebase
 
-Exécuter les tâches de conception dans l'ordre :
+Codebase existante : détecter la stack (backend, frontend, base de données, cache, infrastructure) et les patterns existants (architecture, style d'API, auth, tests) et rester cohérent avec eux.
+
+Nouveau projet : poser les questions technologiques.
 
 ```
-╔══════════════════════════════════════════════════════════╗
-║                 TÂCHES DE CONCEPTION                      ║
-╠══════════════════════════════════════════════════════════╣
-║                                                           ║
-║ □ Tâche 1 : Générer la Spécification Technique           ║
-║   Commande : /project:generate-tech-spec                  ║
-║   Résultat : project-management/tech-spec.md              ║
-║                                                           ║
-║ □ Tâche 2 : Conception de l'architecture                  ║
-║   Créer les diagrammes C4 (contexte, conteneur, composant)║
-║   Résultat : project-management/architecture/             ║
-║                                                           ║
-║ □ Tâche 3 : Conception du modèle de données               ║
-║   ERD et schéma de base de données                        ║
-║   Résultat : project-management/architecture/erd.md       ║
-║                                                           ║
-║ □ Tâche 4 : Conception de l'API                           ║
-║   Endpoints, payloads, authentification                    ║
-║   Résultat : project-management/architecture/api.md       ║
-║                                                           ║
-║ □ Tâche 5 : Créer les ADR                                 ║
-║   Documenter les décisions techniques clés                ║
-║   Résultat : docs/adr/                                    ║
-║                                                           ║
-║ □ Tâche 6 : Revue de sécurité                             ║
-║   Checklist OWASP, stratégie d'authentification           ║
-║   Résultat : project-management/architecture/security.md  ║
-║                                                           ║
-╚══════════════════════════════════════════════════════════╝
+┌─────────────────────────────────────────────────────────┐
+│ QUESTIONS - Stack technique                              │
+├─────────────────────────────────────────────────────────┤
+│ 1. Framework backend préféré ? (Symfony/Laravel/Node)    │
+│ 2. Framework frontend ? (React/Vue/Angular/Aucun)        │
+│ 3. Base de données préférée ? (PostgreSQL/MySQL/MongoDB) │
+│ 4. Cible de déploiement ? (Docker/K8s/Serverless/VPS)    │
+│ 5. Des intégrations existantes à prendre en compte ?     │
+└─────────────────────────────────────────────────────────┘
 ```
 
-### Étape 4 : Exécution de la génération de la Spécification Technique
+### Étape 3 : Questions d'architecture
 
 ```
-Démarrage de /project:generate-tech-spec...
-
-Analyse des exigences du PRD...
-Détection des patterns du codebase existant...
+┌─────────────────────────────────────────────────────────┐
+│ QUESTIONS - Décisions d'architecture                     │
+├─────────────────────────────────────────────────────────┤
+│ 1. Monolithe ou microservices ?                          │
+│ 2. Style d'API préféré ? (REST/GraphQL/gRPC)             │
+│ 3. Échelle attendue ? (utilisateurs, requêtes/s)         │
+│ 4. Fonctionnalités temps réel ? (WebSockets/SSE)         │
+│ 5. Besoins de stockage de fichiers ? (S3/local/CDN)      │
+│ 6. Besoins de traitement de jobs en arrière-plan ?       │
+│ 7. Intégrations tierces ? (paiement, e-mail, etc.)       │
+└─────────────────────────────────────────────────────────┘
+```
 
-[Le workflow de génération de la Spécification Technique s'exécute avec Q&R interactif]
+### Étape 4 : Tâches de conception
 
-✅ Spécification Technique créée : project-management/tech-spec.md
-```
+Exécuter dans l'ordre :
 
-### Étape 5 : Diagrammes d'architecture
+| # | Tâche | Sortie |
+|---|-------|--------|
+| 1 | Spec technique (template `.claude/templates/project/tech-spec.md`) | `project-management/tech-spec.md` |
+| 2 | Diagrammes C4 (contexte, conteneur, composant) | `project-management/architecture/c4-*.md` |
+| 3 | Modèle de données : ERD (Mermaid `erDiagram`) + schémas ; valider les relations, les entités manquantes, l'indexation | `project-management/architecture/erd.md` |
+| 4 | Conception d'API : endpoints dérivés des FR-xxx et des personas, payloads, erreurs, auth | `project-management/architecture/api.md` |
+| 5 | Sécurité et performance : mitigations OWASP, authN/authZ, chiffrement, rate limiting, écarts RGPD | `project-management/architecture/security.md` |
+| 6 | ADR pour les décisions clés (base de données, style d'API, authentification) | `docs/adr/ADR-00x-*.md` |
+| 7 | Stratégie de tests (cible de couverture 80 %), CI/CD et déploiement, monitoring | dans `tech-spec.md` |
 
-Générer les diagrammes d'architecture C4 :
+Exemple de checklist sécurité :
 
 ```
-╔══════════════════════════════════════════════════════════╗
-║             DIAGRAMMES D'ARCHITECTURE                     ║
-╠══════════════════════════════════════════════════════════╣
-║                                                           ║
-║ C4 Niveau 1 - Contexte système :                         ║
-║ ┌─────────────────────────────────────────────────────┐  ║
-║ │                                                     │  ║
-║ │     [Utilisateur] ──► [Notre Système] ──► [Stripe]  │  ║
-║ │                            │                        │  ║
-║ │                            ▼                        │  ║
-║ │                       [SendGrid]                    │  ║
-║ │                                                     │  ║
-║ └─────────────────────────────────────────────────────┘  ║
-║                                                           ║
-║ C4 Niveau 2 - Conteneur :                                ║
-║ ┌─────────────────────────────────────────────────────┐  ║
-║ │                                                     │  ║
-║ │  [React SPA] ──► [Symfony API] ──► [PostgreSQL]    │  ║
-║ │                       │                             │  ║
-║ │                       ▼                             │  ║
-║ │                    [Redis]                          │  ║
-║ │                                                     │  ║
-║ └─────────────────────────────────────────────────────┘  ║
-║                                                           ║
-║ Fichiers créés :                                         ║
-║ ├── architecture/c4-context.md                            ║
-║ ├── architecture/c4-container.md                          ║
-║ └── architecture/c4-component.md                          ║
-║                                                           ║
-╚══════════════════════════════════════════════════════════╝
+✅ Authentification : JWT avec cookies HttpOnly
+✅ Autorisation : RBAC avec policies
+✅ Chiffrement des données : AES-256 au repos, TLS 1.3 en transit
+✅ Validation des entrées : validation DTO + sanitisation
+✅ Rate limiting : 100 req/min par utilisateur
+⚠️  Conformité RGPD : politique de rétention des données à définir
 ```
 
-### Étape 6 : Création des ADR
+### Étape 5 : Gate de revue de conception
 
-Documenter les décisions architecturales clés :
+- La spec technique couvre toutes les exigences du PRD (chaque `FR-xxx` est traçable)
+- L'architecture supporte les NFR (performance, sécurité)
+- Le modèle de données gère toutes les entités ; la conception d'API couvre toutes les user stories
+- Sécurité, stratégie de tests et approche de déploiement documentées
+- ADR complets et justifiés
 
-```
-╔══════════════════════════════════════════════════════════╗
-║        ARCHITECTURE DECISION RECORDS (ADR)                ║
-╠══════════════════════════════════════════════════════════╣
-║                                                           ║
-║ ADR créés :                                              ║
-║                                                           ║
-║ ┌─────────────────────────────────────────────────────┐  ║
-║ │ ADR-001 : Choix de la base de données               │  ║
-║ │ Décision : PostgreSQL                               │  ║
-║ │ Justification : Conformité ACID, support JSON,      │  ║
-║ │ existant                                            │  ║
-║ └─────────────────────────────────────────────────────┘  ║
-║                                                           ║
-║ ┌─────────────────────────────────────────────────────┐  ║
-║ │ ADR-002 : Style d'API                               │  ║
-║ │ Décision : REST avec JSON:API                       │  ║
-║ │ Justification : Expertise de l'équipe, cache,       │  ║
-║ │ simplicité                                          │  ║
-║ └─────────────────────────────────────────────────────┘  ║
-║                                                           ║
-║ ┌─────────────────────────────────────────────────────┐  ║
-║ │ ADR-003 : Authentification                          │  ║
-║ │ Décision : JWT avec refresh tokens                  │  ║
-║ │ Justification : Stateless, adapté au mobile,        │  ║
-║ │ standard                                            │  ║
-║ └─────────────────────────────────────────────────────┘  ║
-║                                                           ║
-║ Fichiers : docs/adr/ADR-001.md, ADR-002.md, ADR-003.md  ║
-║                                                           ║
-╚══════════════════════════════════════════════════════════╝
-```
+Proposer des itérations : stratégie de cache, documentation d'API détaillée, pipeline de déploiement.
 
-### Étape 7 : Porte de revue de conception
+### Étape 6 : Finalisation
 
 ```
 ╔══════════════════════════════════════════════════════════╗
-║              PORTE DE REVUE DE CONCEPTION                 ║
-╠══════════════════════════════════════════════════════════╣
-║                                                           ║
-║ Checklist :                                              ║
-║ ✅ La Spécification Technique couvre toutes les exigences ║
-║    du PRD                                                ║
-║ ✅ L'architecture supporte les NFR (performance, sécurité)║
-║ ✅ Le modèle de données gère toutes les entités          ║
-║ ✅ La conception API couvre toutes les user stories       ║
-║ ✅ Les considérations de sécurité sont documentées       ║
-║ ✅ La stratégie de test est définie                       ║
-║ ✅ L'approche de déploiement est documentée              ║
-║                                                           ║
-║ Questions de revue :                                     ║
-║ 1. L'architecture est-elle appropriée pour l'échelle ?   ║
-║ 2. Y a-t-il des intégrations manquantes ?                ║
-║ 3. L'approche sécurité est-elle suffisante ?             ║
-║ 4. Les ADR sont-ils complets et justifiés ?              ║
-║                                                           ║
+║           PHASE DE CONCEPTION TERMINÉE                    ║
+║ ✅ project-management/tech-spec.md                        ║
+║ ✅ project-management/architecture/ (c4, erd, api, sec.)  ║
+║ ✅ docs/adr/ (3 ADR)                                      ║
+║ • 24 endpoints d'API • 8 entités • 3 intégrations         ║
+║                                                           ║
+║ SUIVANT : /workflow:plan --only=backlog                   ║
+║ PUIS : /workflow:start 1                                  ║
 ╚══════════════════════════════════════════════════════════╝
 ```
 
-### Étape 8 : Fin de phase
+Le backlog lit `project-management/prd.md` et, une fois créée, `project-management/tech-spec.md`. Après la conception, recommander `/workflow:plan --only=backlog` puis `/workflow:start 1`.
 
-```
-╔══════════════════════════════════════════════════════════╗
-║              PHASE DE CONCEPTION TERMINÉE                 ║
-╠══════════════════════════════════════════════════════════╣
-║                                                           ║
-║ Artefacts créés :                                        ║
-║ ✅ tech-spec.md            Spécification Technique        ║
-║ ✅ architecture/                                          ║
-║    ├── c4-context.md       Diagramme de contexte système  ║
-║    ├── c4-container.md     Diagramme de conteneurs        ║
-║    ├── c4-component.md     Diagramme de composants        ║
-║    ├── erd.md              Diagramme Entité-Relation      ║
-║    ├── api.md              Conception API                  ║
-║    └── security.md         Considérations de sécurité     ║
-║ ✅ docs/adr/               3 Architecture Decision Records║
-║                                                           ║
-║ Résumé :                                                 ║
-║ • 24 endpoints API conçus                                ║
-║ • 8 entités de base de données définies                  ║
-║ • 3 intégrations externes spécifiées                     ║
-║ • Objectif de couverture de tests à 80%                  ║
-║                                                           ║
-║ ─────────────────────────────────────────────────────────║
-║ PHASE SUIVANTE : Implémentation                          ║
-║ Commande : /workflow:implement                           ║
-║ ─────────────────────────────────────────────────────────║
-║                                                           ║
-║ Prêt à démarrer le développement du Sprint 1 !           ║
-╚══════════════════════════════════════════════════════════╝
-```
+## Workflow : Constitution (`--constitution`)
+
+### Phase 1 : Découverte du contexte
+
+Analyse automatique de : `README.md`, `project-management/prd.md`, `project-management/tech-spec.md`, structure de la codebase (patterns, conventions) et configuration `.claude/`. Lister les sources trouvées.
+
+### Phase 2 : Clarification interactive
+
+Interroger l'utilisateur, par thème, pour combler les lacunes :
+
+| Thème | Questions |
+|-------|-----------|
+| Vision & Mission | Vision en une phrase ; quoi, pour qui, pourquoi ; objectifs non négociables ; ce qui ferait échouer le projet |
+| Contraintes techniques | Technologies verrouillées ; pattern d'architecture obligatoire ; contraintes d'infrastructure ; intégrations tierces obligatoires |
+| Principes de conception | Patterns obligatoires ; patterns/pratiques interdits ; standards de code ; stratégie de tests requise |
+| Exigences non fonctionnelles | Objectifs de performance (latence, charge) ; sécurité ; conformité (RGPD, SOC2) ; disponibilité/uptime |
+| Périmètre | Hors périmètre ; systèmes externes ; frontières d'équipe et responsabilités ; qui peut amender la constitution |
+
+### Phase 3 : Génération
+
+1. Charger le template `.claude/templates/project/constitution.md`
+2. Renseigner la vision, la mission et les objectifs non négociables
+3. Verrouiller la stack technique (technologies et versions)
+4. Consigner les patterns obligatoires et interdits
+5. Enregistrer les objectifs de performance, de sécurité et de conformité
+6. Documenter les exclusions, les frontières d'intégration et le processus d'amendement
+
+### Phase 4 : Revue et ratification
+
+Sortie : `project-management/constitution.md` avec les sections Vision & Mission, Contraintes techniques, Principes de conception, Exigences non fonctionnelles, Périmètre, Processus d'amendement. Proposer d'ajuster les décisions verrouillées, d'ajouter des contraintes ou d'affiner le périmètre. Les notes de découverte optionnelles vont dans `project-management/analysis/discovery-notes.md`.
+
+La constitution est la référence utilisée par `/gate:check alignment`. Étapes suivantes : `/workflow:plan --only=prd` s'il n'y a pas encore de PRD, sinon lancer le `/workflow:design` par défaut.
 
 ## Agents impliqués
 
-- **tech-lead** : Conception technique globale et création des ADR
-- **api-designer** : Conception d'API REST/GraphQL
-- **database-architect** : Modèle de données et conception du schéma
-- **ui-designer** : Architecture frontend (si applicable)
-- **devops-engineer** : Conception du déploiement et de l'infrastructure
+- **tech-lead** : conception technique globale et création des ADR
+- **api-designer** : conception d'API REST/GraphQL
+- **database-architect** : modèle de données et conception du schéma
+- **ui-designer** : architecture frontend (le cas échéant)
+- **devops-engineer** : conception du déploiement et de l'infrastructure
 
 ## Fichiers de sortie
 
-| Fichier | Objectif |
-|---------|----------|
-| `tech-spec.md` | Spécification Technique complète |
-| `architecture/c4-*.md` | Diagrammes d'architecture C4 |
-| `architecture/erd.md` | Diagramme Entité-Relation |
-| `architecture/api.md` | Documentation des endpoints API |
-| `architecture/security.md` | Conception de la sécurité |
+| Fichier | Rôle |
+|---------|------|
+| `project-management/tech-spec.md` | Spécification technique complète |
+| `project-management/constitution.md` | Constitution du projet (`--constitution`) |
+| `project-management/architecture/c4-*.md` | Diagrammes d'architecture C4 |
+| `project-management/architecture/erd.md` | Diagramme entité-relation |
+| `project-management/architecture/api.md` | Documentation des endpoints d'API |
+| `project-management/architecture/security.md` | Conception de la sécurité |
 | `docs/adr/*.md` | Architecture Decision Records |
 
+## Exemple de session
+
+```
+User: /workflow:design
+
+Claude: Chargement de project-management/prd.md : 12 FR, 8 NFR.
+Détecté : Symfony + React + PostgreSQL.
+❓ L'API actuelle est REST. Garder REST ou migrer vers GraphQL ?
+> Garder REST
+[... Q&R interactives ...]
+✅ Spec technique générée : project-management/tech-spec.md
+Suivant : /workflow:plan --only=backlog, puis /workflow:start 1
+```
+
 ## Commandes associées
 
-- `/workflow:plan` - Phase précédente
-- `/workflow:implement` - Phase suivante
+- `/workflow:plan` - Phase précédente (`--only=prd`, `--only=backlog`)
+- `/workflow:start` - Démarrer le premier sprint
+- `/workflow:implement` - Phase d'implémentation
 - `/workflow:status` - Vérifier la progression
-- `/project:generate-tech-spec` - Génération directe de la spécification technique
+- `/gate:check` - Quality gates (`alignment` utilise la constitution)
 - `/common:architecture-decision` - Créer des ADR individuels