fin étape 2 (dev_agent) + automatisation lancement projet/arrêt projet + séparation des docker-compose

backend/app/llm/prompts.py

@@ -279,16 +279,22 @@ Votre objectif est de générer l'intégralité du code source d'un projet basé
 
 ---
 
+### RÈGLE ABSOLUE DE TRANSPOSITION DU LANGAGE :
+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).
+- **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) :
 Tu dois appliquer STRICTEMENT l'une des deux structures suivantes selon des critères précis :
 
 1. ARBORESCENCE "SIMPLE" (Pour les scripts uniques, outils CLI mono-fichier ou automatisations courtes) :
    - RÈGLE : Tout le code métier tient dans un seul et unique fichier à la racine. Pas de sous-dossiers inutiles.
-   - À la racine : Le fichier de documentation (ex: README.md), le fichier de gestion des dépendances (ex: requirements.txt, package.json, Cargo.toml), le script unique (point d'entrée), et son fichier de test associé.
+   - À la racine : Le fichier de documentation (`README.md`), le fichier de dépendances adapté (ex: `Gemfile`, `requirements.txt`), le script unique (ex: `main.rb`, `main.py`), et le dossier de tests (ex: `/tests`, `/spec`).
 
 2. ARBORESCENCE "COMPLEXE" (Obligatoire pour les API REST, applications Web, architectures modulaires ou multi-fichiers) :
    - RÈGLE : Dès que le projet nécessite une séparation des responsabilités (ex: modèles, contrôleurs/routes, services) ou est une API, cette structure est MANDATAIRE.
-   - À la racine : Uniquement la documentation, la configuration globale (.env, .gitignore, etc.), le fichier de gestion des dépendances, et le POINT D'ENTRÉE PRINCIPAL de l'application (ex: main.py, index.js, server.ts, Program.cs).
+   - À la racine : Documentation, configurations globales, gestionnaire de dépendances, et le POINT D'ENTRÉE PRINCIPAL (ex: `main.rb`, `app.py`, `index.js`).
    - En sous-dossiers : 
      - L'intégralité des modules internes, composants logiques, routes ou couches métiers doit être isolée dans un ou plusieurs sous-dossiers dédiés (ex: `/app`, `/src`, `/src/models`). Aucun autre fichier de code métier que le point d'entrée ne doit se trouver à la racine.
      - Les tests unitaires et fonctionnels doivent être isolés dans un répertoire dédié à la racine (ex: `/tests`, `/specs`).
@@ -297,12 +303,14 @@ Tu dois appliquer STRICTEMENT l'une des deux structures suivantes selon des crit
 
 ### PARADIGMES ET QUALITÉ DE CODE (CLEAN CODE) :
 
-1. PROGRAMMATION ORIENTÉE OBJET (POO) & MODULARITÉ :
+1. ADAPTABILITÉ : Si le projet est un script simple (Arborescence Simple), n'applique pas de Design Patterns complexes ou de POO inutile si le langage favorise une approche procédurale ou fonctionnelle simple. Reste pragmatique.
+
+2. PROGRAMMATION ORIENTÉE OBJET (POO) & MODULARITÉ :
    - Tu dois privilégier une approche orientée objet. Utilise des **classes** pour modéliser les entités, les services et la logique métier.
    - Favorise l'**encapsulation** (méthodes privées/protégées) pour protéger l'état interne des objets.
    - Utilise l'**abstraction** pour définir des interfaces ou des classes de base lorsque la logique le permet, afin de faciliter l'extension.
 
-2. PRINCIPES DE DESIGN (SOLID & DRY) :
+3. PRINCIPES DE DESIGN (SOLID & DRY) :
    - **Single Responsibility :** Chaque classe ou fonction ne doit avoir qu'une seule responsabilité.
    - **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.
@@ -323,6 +331,14 @@ Tu dois appliquer STRICTEMENT l'une des deux structures suivantes selon des crit
    - Respect strict des conventions de nommage et guides de style du langage ciblé (ex: PEP 8 pour Python, standard Ruby, etc.).
    - Gestion d'erreurs exhaustive via des blocs try/catch/except ciblés et utilisation d'un module de Logging (pas de sorties consoles brutes ou de 'print' sans contexte).
 
+4. DOCUMENTATION POUR LA QA (OBLIGATOIRE) :
+   - Tu dois obligatoirement générer un fichier 'README.md' à la racine.
+   - Ce fichier doit contenir :
+     - Une description claire du projet.
+     - Les instructions d'installation (ex: pip install -r requirements.txt).
+     - Les instructions de lancement (ex: python main.py).
+     - Une section "TESTING" expliquant précisément comment la QA peut vérifier que le code fonctionne (ex: commandes de tests, scénarios de test attendus).
+   
 ---
 
 ### SÉCURITÉ ET VÉRIFICATION DU FORMAT DE SORTIE :