create-gef 1.0.0

package/hooks/commit-msg

@@ -0,0 +1,27 @@
+#!/bin/bash
+# Hook: commit-msg
+# Réf: ENGINEERING_PLAYBOOK.md §1
+
+COMMIT_MSG_FILE=$1
+COMMIT_MSG=$(cat $1)
+
+# Regex pour Conventional Commits + Issue Number (Kanban)
+PATTERN="^(feat|fix|docs|chore|refactor|style|perf|test|release)(\([a-zA-Z0-9_.-]+\))?: (.*) \(#[0-9]+\)$"
+
+if [[ ! $COMMIT_MSG =~ $PATTERN ]]; then
+  echo -e "\033[31mErreur: Message de commit non conforme au Playbook §1.\033[0m"
+  echo "Le message doit suivre le format Conventional Commits ET inclure le numéro de ticket Kanban à la fin."
+  echo "Exemple: 'feat: ajout du bouton login (#42)'"
+  exit 1
+fi
+
+# Récupération de la description (après le préfixe)
+DESCRIPTION="${BASH_REMATCH[3]}"
+
+if [ ${#DESCRIPTION} -lt 10 ]; then
+  echo -e "\033[33mAvertissement: La description du commit est très courte (moins de 10 caractères).\033[0m"
+  echo "Playbook §1 recommande des messages détaillés pour faciliter la traçabilité."
+  # Non bloquant
+fi
+
+exit 0

package/hooks/pre-commit

@@ -0,0 +1,46 @@
+#!/bin/bash
+# Hook: pre-commit
+# Réf: ENGINEERING_PLAYBOOK.md §1, §6, §12
+
+# 1. Vérification des secrets en clair
+# Recherche naïve de patterns de type api_key="qqchose" ou secret = "qqchose" dans le code mis en stage
+SECRETS=$(git diff --cached -G"(api_key|secret|token|password)[ ]*=[ ]*['\"][a-zA-Z0-9_\-]+['\"]" --name-only)
+if [ -n "$SECRETS" ]; then
+  echo -e "\033[31mErreur: Potentiel secret en clair détecté dans les fichiers suivants :\033[0m"
+  echo "$SECRETS"
+  echo "Bloqué selon le Playbook. Utilisez des variables d'environnement."
+  exit 1
+fi
+
+# 2. Vérification des fichiers de debug non voulus
+DEBUG_FILES=$(git diff --cached --name-only | grep -E "(^|/)(debug_|test_)" | grep -v "^tests/")
+if [ -n "$DEBUG_FILES" ]; then
+  echo -e "\033[31mErreur: Fichier de debug ou de test hors du dossier officiel 'tests/' détecté :\033[0m"
+  echo "$DEBUG_FILES"
+  echo "Bloqué selon le Playbook §12."
+  exit 1
+fi
+
+# 3. Lint / Format (Dégradation progressive acceptable)
+# On tente de trouver une commande de lint dans les scripts standards, sinon on avertit.
+if [ -f "package.json" ] && grep -q '"lint"' package.json; then
+  echo "Exécution du linter npm..."
+  npm run lint || { echo -e "\033[31mErreur Lint\033[0m"; exit 1; }
+elif [ -f "Makefile" ] && grep -q "^lint:" Makefile; then
+  echo "Exécution du linter Make..."
+  make lint || { echo -e "\033[31mErreur Lint\033[0m"; exit 1; }
+else
+  echo -e "\033[33mAvertissement: Aucun linter standard détecté (npm run lint, make lint). Configurez-en un dans PROJECT_CONFIG.md.\033[0m"
+fi
+
+# 4. Taille des fichiers modifiés
+for file in $(git diff --cached --name-only); do
+  if [ -f "$file" ]; then
+    LINES=$(wc -l < "$file")
+    if [ "$LINES" -gt 500 ]; then
+      echo -e "\033[33mAvertissement: Le fichier $file dépasse 500 lignes ($LINES lignes). Envisagez de le découper (Playbook §4).\033[0m"
+    fi
+  fi
+done
+
+exit 0

package/hooks/pre-push

@@ -0,0 +1,25 @@
+#!/bin/bash
+# Hook: pre-push
+# Réf: ENGINEERING_PLAYBOOK.md §13
+
+CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD)
+
+# 1. Rejet si la branche cible est main (push direct)
+if [ "$CURRENT_BRANCH" = "main" ] || [ "$CURRENT_BRANCH" = "master" ]; then
+  echo -e "\033[31mErreur: Push direct sur '$CURRENT_BRANCH' interdit.\033[0m"
+  echo "Le Playbook §13 impose de passer par des branches de feature (ex: feat/...) et des Pull Requests."
+  exit 1
+fi
+
+# 2. Exécution optionnelle des tests locaux
+if [ -f "package.json" ] && grep -q '"test"' package.json; then
+  echo "Exécution des tests locaux (npm test)..."
+  npm test || { echo -e "\033[31mErreur: Tests en échec. Push annulé.\033[0m"; exit 1; }
+elif [ -f "Makefile" ] && grep -q "^test:" Makefile; then
+  echo "Exécution des tests locaux (make test)..."
+  make test || { echo -e "\033[31mErreur: Tests en échec. Push annulé.\033[0m"; exit 1; }
+else
+  echo -e "\033[34mInfo: Aucun runner de tests standard détecté. Push autorisé.\033[0m"
+fi
+
+exit 0

package/package.json

@@ -0,0 +1,18 @@
+{
+  "name": "create-gef",
+  "version": "1.0.0",
+  "description": "Générateur interactif de projets respectant le framework GEF",
+  "type": "module",
+  "bin": {
+    "create-gef": "./generator/index.js"
+  },
+  "scripts": {
+    "start": "node generator/index.js"
+  },
+  "dependencies": {
+    "chalk": "^5.3.0",
+    "inquirer": "^9.2.12"
+  },
+  "author": "Gildas",
+  "license": "ISC"
+}

package/prompts/adr_writing.md

@@ -0,0 +1,14 @@
+# Prompt Rédaction ADR — GEF
+
+> Ce prompt est à utiliser lorsqu'une décision architecturale majeure doit être prise (changement de base de données, framework, cloud, etc.).
+
+Tu dois rédiger un document d'Architecture Decision Record (ADR) en respectant le `ENGINEERING_PLAYBOOK.md` (§6) :
+
+1. Crée un nouveau fichier dans `docs/adr/` nommé `ADR-XXX-titre_descriptif.md`.
+2. Utilise le format strict suivant :
+   - **Contexte** : Quel est le problème ou la situation actuelle ?
+   - **Options considérées** : Quelles sont les alternatives techniques évaluées ?
+   - **Décision** : Quelle option est retenue et pourquoi ?
+   - **Conséquences** : Quels sont les impacts positifs, négatifs et les compromis acceptés suite à cette décision ?
+
+Ne consigne pas ces décisions architecturales dans le RESEARCH_LOG. Fais-en un commit dédié (`docs: création ADR pour ...`).

package/prompts/bugfix.md

@@ -0,0 +1,15 @@
+# Prompt Résolution de Bug — GEF
+
+> Ce prompt est à utiliser pour diagnostiquer et corriger un bug.
+
+Tu as pour mission de corriger un bug en respectant strictement le `ENGINEERING_PLAYBOOK.md` :
+
+1. **Diagnostic et Fix**
+   - Identifie la cause racine, propose une correction et effectue un commit `fix:` approprié (Réf. Playbook §1).
+
+2. **Règle Fondamentale : RESEARCH_LOG (Réf. Playbook §6)**
+   - Ne considère **jamais** un bug critique ou une erreur bloquante comme résolue sans ajouter une nouvelle entrée numérotée dans `docs/research/RESEARCH_LOG.md`.
+   - Explique brièvement la cause de l'erreur et la façon dont elle a été résolue pour garder une trace scientifique.
+
+3. **Validation**
+   - Assure-toi d'ajouter ou de mettre à jour un test pour éviter la régression avant de clore la tâche.

package/prompts/code_review.md

@@ -0,0 +1,14 @@
+# Prompt Revue de Code — GEF
+
+> Ce prompt est à utiliser pour simuler ou assister une revue de code avant un merge.
+
+Tu agis en tant que relecteur technique strict, garant de l'application du `ENGINEERING_PLAYBOOK.md` (§7).
+Analyse les modifications proposées selon cette checklist obligatoire :
+
+1. **Lint et Build** : Le code passe-t-il les règles de formatage et compile-t-il sans erreur apparente ?
+2. **Tests** : La logique nouvelle ou modifiée est-elle couverte par des tests adaptés ?
+3. **Revue** : L'architecture est-elle propre, modulaire et auditable scientifiquement ? N'y a-t-il aucune donnée hardcodée ?
+4. **Documentation** : Les docstrings sont-elles présentes et à jour ? L'intention du code est-elle claire ?
+5. **Changelog / README** : Si des changements majeurs sont introduits, le README ou le CHANGELOG ont-ils été mis à jour ?
+
+Si l'un des points échoue, demande les corrections associées et suggère le code pour les appliquer.

package/prompts/feature_development.md

@@ -0,0 +1,29 @@
+# Prompt Développement de Fonctionnalité — GEF
+
+> Ce prompt est à utiliser lors de la demande de développement d'une nouvelle fonctionnalité.
+
+Tu dois implémenter la fonctionnalité demandée en respectant le `ENGINEERING_PLAYBOOK.md` :
+
+1. **Branche et workflow (Réf. Playbook §13)**
+   - Ne travaille jamais directement sur `main`. Nous devons être sur une branche `feat/<nom-fonctionnalite>`. 
+
+2. **Traçabilité (Réf. Playbook §1)**
+   - Implémente la fonctionnalité par petits incréments logiques.
+   - Effectue des micro-commits fréquents avec des messages au format *Conventional Commits* (ex: `feat: ajout du bouton`, `test: tests unitaires bouton`).
+   - Aucune modification massive non-commitée.
+
+3. **Documentation continue (Réf. Playbook §2)**
+   - Mets à jour le `README.md` **uniquement** si cette fonctionnalité change l'installation, les API publiques, les prérequis, l'architecture ou les fonctionnalités visibles.
+
+4. **Pilotage Kanban et TDD (Réf. Playbook §14 et §16)**
+   - Utilise `gh issue create` pour créer un ticket correspondant à la fonctionnalité.
+   - Tous tes commits doivent inclure la référence du ticket (ex: `feat: ... (#12)`).
+   - Avant d'écrire le code, écris le test E2E/Playwright décrivant le comportement (TDD).
+
+5. **Auto-Documentation (Réf. Playbook §15)**
+   - Si tu introduis une nouveauté architecturale, écris un ADR dans `docs/adr/`.
+
+6. **Validation et Pull Request (Réf. Playbook §14)**
+   - Une fois terminé et testé, n'essaie jamais de merger sur `main`.
+   - Utilise `gh pr create` pour ouvrir la Pull Request (avec "Closes #XYZ").
+   - Demande explicitement à l'utilisateur : "J'ai créé la PR, peux-tu la vérifier et la merger ?"

package/prompts/new_project_kickoff.md

@@ -0,0 +1,14 @@
+# Prompt Kickoff Projet — GEF
+
+> Ce prompt est à utiliser tout au début d'un nouveau projet, avant même d'écrire la première ligne de code métier.
+
+Tu aides à démarrer un nouveau projet de manière robuste. Suis les instructions du `ENGINEERING_PLAYBOOK.md` (§10) :
+
+Pose-moi explicitement la question suivante : 
+**"Ce projet est-il une expérimentation R&D (jetable) ou un projet contractuel/production destiné à être maintenu ?"**
+
+En fonction de ma réponse :
+- Si R&D : rappelle-moi que nous pouvons être souples sur la CI/CD et que le code pourra rester dans le dépôt `prototype`.
+- Si Contractuel/Production : rappelle-moi qu'il faut séparer strictement ce code de tout dépôt exploratoire existant, et que les règles de tests, d'auditabilité et de CI/CD sont non-négociables dès le premier jour. 
+
+Aide-moi ensuite à remplir le `PROJECT_CONFIG.md` initial en posant des questions sur les technologies, le cloud provider et les jalons.

package/prompts/system_prompt.md

@@ -0,0 +1,24 @@
+# System Prompt — GEF
+
+> Ce prompt est à fournir à l'IA en début de toute session de travail sur ce projet.
+
+Tu es une IA d'assistance au développement travaillant sur ce projet. Tu dois impérativement respecter le `ENGINEERING_PLAYBOOK.md` du projet.
+
+## 1. Cycle de Vie du Projet & Clause d'Antériorité
+- Avant de commencer toute tâche, identifie dans quelle phase du projet nous nous trouvons (Idée, Cadrage, Architecture, R&D, Développement contractuel, Tests, Release, Maintenance) et adapte ton approche en conséquence.
+- **Clause d'Antériorité :** Applique les règles de ce framework sur le **nouveau** code. Ne refactore jamais proactivement l'ancien code existant pour le rendre conforme aux nouvelles règles, sauf si je te le demande explicitement (règle du *Fix Forward*).
+
+## 2. Traçabilité Git Extrême
+- **Une action = Un commit.** Ne groupe jamais la création d'un fichier et sa modification.
+- Utilise la convention **Conventional Commits** (`feat:`, `fix:`, `docs:`, `chore:`, `refactor:`, `style:`, `perf:`, `test:`, `release:`).
+- Aucun changement sans l'associer immédiatement à un commit précis.
+
+## 3. Documentation
+- Assure-toi de commenter ton code pour expliquer l'*intention* et ajoute des docstrings.
+- **RESEARCH_LOG.md** : Si tu résous un bug ou une erreur bloquante, documente-le immédiatement dans ce fichier avant de poursuivre.
+- Ne mets pas à jour le README pour de simples refactorisations internes.
+
+## 4. Méthodologie Pas-à-Pas
+- Ne code jamais de larges blocs d'un seul coup.
+- Propose, explique, implémente, et valide (via un commit) étape par étape.
+- Si une erreur survient, diagnostique et documente-la avant de continuer.