Etape 4 finie, TODO : correction QA, gestion retour au PM après refus utilisateur

backend/app/llm/prompts.py

@@ -243,6 +243,35 @@ Si tu ne comprends pas un champ, tu le remplis avec une valeur par défaut INTEL
 ```
 ---
 
+=== VALIDATION DE COMPLÉTUDE DE LA SPÉCIFICATION (OBLIGATOIRE) ===
+
+Avant de considérer la ProjectSpec comme complète, tu dois te demander :
+
+"Un développeur senior peut-il implémenter l'intégralité du projet sans devoir faire la moindre hypothèse importante ?"
+
+Tu dois vérifier notamment que les éléments suivants sont suffisamment définis lorsqu'ils sont pertinents :
+
+- le comportement attendu de l'application ;
+- les données d'entrée (type, format, provenance) ;
+- les données de sortie (type, format, emplacement) ;
+- les règles métier ;
+- les traitements à effectuer ;
+- les services, API ou bases de données concernés ;
+- les méthodes d'authentification ;
+- les paramètres configurables ;
+- les cas limites importants ;
+- les contraintes fonctionnelles ou techniques.
+
+Si une ou plusieurs informations indispensables sont absentes ou ambiguës, tu dois :
+
+- définir `"is_complete": false`
+- remplir `"clarifying_question"` avec UNE question claire, précise et ciblée permettant d'obtenir uniquement les informations manquantes.
+- ne jamais inventer une règle métier ou un comportement qui n'a pas été demandé.
+
+Tu peux compléter automatiquement uniquement les conventions techniques raisonnables (OS, stratégie de logs, dépendances, versions, structure du projet, etc.), mais jamais les besoins fonctionnels.
+
+---
+
 === DERNIER CHECKPOINT ===
 
 Avant de retourner le JSON :
@@ -283,6 +312,7 @@ Votre objectif est de générer l'intégralité du code source d'un projet basé
 Tu dois impérativement identifier le langage cible défini dans la `ProjectSpec` (champ `"language"`). Tu as l'interdiction stricte d'utiliser un autre langage.
 - **Extensions :** Adapte l'extension du point d'entrée et des tests (.rb pour Ruby, .py pour Python, .js pour JS, .go pour Go, etc.).
 - **Gestionnaire de dépendances :** Utilise le fichier standard du langage (ex: `Gemfile` pour Ruby, `requirements.txt` ou `pyproject.toml` pour Python, `package.json` pour Node.js).
+- **Dépendances :** N'ajoute dans le gestionnaire de dépendances (ex: `requirements.txt`, `Gemfile`, `package.json`, etc.) que les bibliothèques externes réellement nécessaires. Il est strictement interdit d'ajouter des modules ou bibliothèques faisant déjà partie de la bibliothèque standard (standard library) du langage ciblé (ex: `logging`, `json`, `os`, `pathlib`, `datetime`, `typing` en Python, etc.).
 - **Commandes du README :** Les instructions d'installation et d'exécution doivent correspondre EXACTEMENT au langage (ex: `bundle install` et `ruby main.rb` pour Ruby).
 
 ### DIRECTIVES D'ARCHITECTURE (ADAPTATIVE) :
@@ -315,6 +345,16 @@ Tu dois appliquer STRICTEMENT l'une des deux structures suivantes selon des crit
    - **DRY (Don't Repeat Yourself) :** Extrais la logique répétitive dans des fonctions ou des classes utilitaires.
    - **Découplage :** Évite les dépendances trop fortes entre les modules pour permettre une évolution facile du code.
    - Utilise des **Design Patterns** reconnus (Factory, Singleton, Strategy, etc.) si la complexité du projet le justifie.
+
+4. DOCUMENTATION DU CODE (OBLIGATOIRE) :
+   - Chaque fichier source doit commencer par un commentaire décrivant clairement son rôle.
+   - Chaque classe doit posséder un commentaire ou une documentation expliquant sa responsabilité.
+   - Chaque fonction ou méthode doit être documentée avec un commentaire ou une documentation décrivant :
+     - son objectif ;
+     - les paramètres attendus ;
+     - la valeur de retour (si applicable) ;
+     - les éventuelles exceptions levées lorsque le langage le permet.
+   - Les commentaires doivent utiliser le format idiomatique du langage ciblé (ex: docstrings Python, JSDoc pour JavaScript/TypeScript, YARD pour Ruby, GoDoc pour Go, JavaDoc pour Java, XML Documentation pour C#, etc.).
      
 ---
 
@@ -341,7 +381,7 @@ Tu dois appliquer STRICTEMENT l'une des deux structures suivantes selon des crit
 
 ---
 
-## CONTRÂINTE DE MODERNITÉ ET SÉCURITÉ DU CODE (UNIVERSEL)
+## CONTRAINTE DE MODERNITÉ ET SÉCURITÉ DU CODE (UNIVERSEL)
 
 Peu importe le langage de programmation choisi pour répondre à la spécification, tu dois appliquer les règles strictes suivantes :