Outils Conception & Planification (Flux D)

Le flux D contient 7 outils pour transformer les specs en artefacts d'implémentation concrets — schémas, contrats UI, décisions architecturales, plans d'exécution et contrats d'événements.

generate_adr

Générer des Architecture Decision Records pour une spec.

Ce qu'il produit : Des documents ADR structurés couvrant le contexte de la décision, les options envisagées, la décision prise et les conséquences. Le format suit MADR (Markdown Architectural Decision Records).

Quand l'utiliser : Lorsqu'une spec implique un choix technologique significatif, un pattern architectural ou un compromis que les futurs développeurs doivent comprendre.

Prompt : "Génère des ADR pour la spec SPEC-004 dans le projet proj_abc123"

Exemple de sortie :

# ADR-001: Utiliser Redis pour le stockage de session

## Statut : Accepté

## Contexte
La spec d'authentification nécessite la persistance de session sur plusieurs instances de serveur...

## Décision
Utiliser Redis comme store de session...

## Conséquences
- Positif : Mise à l'échelle horizontale sans sessions collantes
- Négatif : Ajoute Redis comme dépendance d'infrastructure obligatoire

---

design_schema

Concevoir le schéma de base de données à partir des exigences de la spec.

Ce qu'il produit :

• Définitions de tables avec colonnes, types et contraintes
• Relations de clés primaires et étrangères
• Suggestions d'index pour les performances de requêtes
• Indications de migration
• Schéma dans plusieurs dialectes (SQL, Prisma, SQLAlchemy, GORM, etc.)

Quand l'utiliser : Lorsqu'une spec implique de la persistance de données et que vous avez besoin d'un point de départ concret pour la couche base de données.

Prompt : "Conçois le schéma de base de données pour la spec SPEC-002 dans le projet proj_abc123"

---

define_ui_contract

Définir les contrats de composants UI, le flux de données et la gestion d'état.

Ce qu'il produit :

• Définitions d'interface de composants (props, événements, slots)
• Diagramme de flux de données (quels composants possèdent quel état)
• Approche de gestion d'état (locale, contexte, store)
• Contrat API entre frontend et backend
• Exigences d'accessibilité

Quand l'utiliser : Pour toute spec incluant un composant frontend, un formulaire ou une interaction utilisateur.

Prompt : "Définis le contrat UI pour le flux de connexion dans la spec SPEC-001 pour le projet proj_abc123"

---

challenge_spec

Tester une spec sous pression pour les défaillances, la concurrence, la montée en charge et les cas limites.

Ce qu'il vérifie :

• Problèmes de concurrence (race conditions, deadlocks)
• Points de rupture à l'échelle (que se passe-t-il à 10x, 100x de charge ?)
• Modes de défaillance (que se passe-t-il si la base de données est indisponible ?)
• Cas limites non couverts par les critères d'acceptation
• Surface d'attaque sécurité

Quand l'utiliser : Pour toute spec qui s'exécutera en production avec de vrais utilisateurs. Particulièrement précieux pour les specs touchant les paiements, l'authentification ou les fonctionnalités temps réel.

Prompt : "Challenge la spec SPEC-003 pour le projet proj_abc123"

---

generate_execution_plan

Générer un PLAN.md étape par étape pour implémenter une spec — cycle RED/GREEN/VERIFY avec étapes parallélisables.

Ce qu'il produit :

## Phase 1 : Fondation (parallèle)
- [ ] Étape 1a : Créer la migration de base de données
- [ ] Étape 1b : Définir les interfaces TypeScript
- [ ] Étape 1c : Écrire les tests échouants (RED)

## Phase 2 : Implémentation (séquentielle)
- [ ] Étape 2a : Implémenter la couche repository (GREEN)
- [ ] Étape 2b : Implémenter la couche service

## Phase 3 : Vérification
- [ ] Étape 3a : Exécuter la suite de tests complète (VERIFY)
- [ ] Étape 3b : Mettre à jour le statut de la spec à review

Quand l'utiliser : Avant que l'implémentation commence. Le PLAN.md devient le contrat d'implémentation pour l'agent IA ou le développeur.

Prompt : "Génère un plan d'exécution pour la spec SPEC-005 dans le projet proj_abc123"

---

generate_orchestration_script

Générer un script d'automatisation parallèle à 3 couches (worktrees + claude -p) pour exécuter plusieurs specs simultanément.

Ce qu'il produit : Un script shell qui :

• Crée des worktrees git isolés par spec
• Lance des workers claude -p en parallèle
• Gère l'allocation des ressources en fonction du CPU et de la RAM disponibles
• Surveille la santé des workers et gère les défaillances

Quand l'utiliser : Lorsque vous devez implémenter plusieurs specs indépendantes simultanément et souhaitez un maximum de parallélisme.

Prompt : "Génère un script d'orchestration pour les specs SPEC-010, SPEC-011, SPEC-012 dans le projet proj_abc123"

---

event_contracts

Gérer les contrats d'architecture événementielle — générer des contrats d'événements JSON Schema pour la validation producteur/consommateur.

Ce qu'il produit :

• Définitions JSON Schema pour chaque type d'événement
• Contrat producteur (ce que l'émetteur garantit)
• Contrat consommateur (ce que l'abonné attend)
• Stratégie de versionnage
• Notes de compatibilité ascendante

Quand l'utiliser : Pour toute spec impliquant des files de messages, des bus d'événements (Kafka, RabbitMQ, AWS SQS/SNS, NATS) ou des intégrations webhook.

Prompt : "Définis les contrats d'événements pour le flux de traitement des commandes dans la spec SPEC-008 pour le projet proj_abc123"

Exemple de sortie :

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "OrderPlaced",
  "version": "1.0.0",
  "type": "object",
  "required": ["orderId", "customerId", "items", "total", "placedAt"],
  "properties": {
    "orderId": { "type": "string", "format": "uuid" },
    "customerId": { "type": "string", "format": "uuid" },
    "items": { "type": "array", "items": { "$ref": "#/definitions/OrderItem" } },
    "total": { "type": "number", "minimum": 0 },
    "placedAt": { "type": "string", "format": "date-time" }
  }
}