create-gef 1.0.0 → 1.1.1

package/generator/templates/adr-template.md

@@ -0,0 +1,22 @@
+# ADR-000 — [Titre de la décision]
+
+**Statut :** [Proposé | Accepté | Déprécié | Remplacé par ADR-YYY]
+**Date :** YYYY-MM-DD
+
+## Contexte
+Quel est le problème, le besoin ou la situation qui nécessite une décision ?
+Inclure le maximum de contexte : contraintes, enjeux métier, contraintes techniques.
+
+## Options Considérées
+| Option | Avantages | Inconvénients |
+|--------|-----------|---------------|
+| Option A | ... | ... |
+| Option B | ... | ... |
+
+## Décision
+Quelle option est retenue et **pourquoi** ? Être précis et factuel.
+
+## Conséquences
+- **Positives :** Quels bénéfices concrets cette décision apporte-t-elle ?
+- **Négatives / Compromis :** Quelles dettes techniques ou limitations sont acceptées ?
+- **Actions requises :** Quelles tâches découlent de cette décision (mise à jour du CI/CD, formation, migration) ?

package/hooks/commit-msg

@@ -1,6 +1,7 @@
 #!/bin/bash
 # Hook: commit-msg
-# Réf: ENGINEERING_PLAYBOOK.md §1
+# Hook: commit-msg
+# Réf: ENGINEERING_PLAYBOOK.md §5
 
 COMMIT_MSG_FILE=$1
 COMMIT_MSG=$(cat $1)
@@ -9,7 +10,7 @@ COMMIT_MSG=$(cat $1)
 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 -e "\033[31mErreur: Message de commit non conforme au Playbook §5.\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
@@ -20,7 +21,7 @@ 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é."
+  echo "Playbook §5 recommande des messages détaillés pour faciliter la traçabilité."
   # Non bloquant
 fi
 

package/hooks/pre-commit

@@ -37,8 +37,8 @@ fi
 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"
+    if [ "$LINES" -gt 400 ]; then
+      echo -e "\033[33mAvertissement: Le fichier $file dépasse 400 lignes ($LINES lignes). Envisagez de le découper (Playbook §1).\033[0m"
     fi
   fi
 done

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-gef",
-  "version": "1.0.0",
+  "version": "1.1.1",
   "description": "Générateur interactif de projets respectant le framework GEF",
   "type": "module",
   "bin": {

package/prompts/adr_writing.md

@@ -1,14 +1,50 @@
 # 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.).
+> Ce prompt est à utiliser lorsqu'une décision architecturale majeure doit être prise (changement de base de données, framework, cloud, authentification, etc.).
 
-Tu dois rédiger un document d'Architecture Decision Record (ADR) en respectant le `ENGINEERING_PLAYBOOK.md` (§6) :
+Tu dois rédiger un document **Architecture Decision Record (ADR)** en respectant le `ENGINEERING_PLAYBOOK.md` (§6 — Diátaxis & Docs-as-Code).
 
-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 ?
+## Processus de Rédaction d'un ADR
 
-Ne consigne pas ces décisions architecturales dans le RESEARCH_LOG. Fais-en un commit dédié (`docs: création ADR pour ...`).
+### Étape 1 — Création du Fichier
+- Crée un nouveau fichier dans `docs/explanation/adr/` nommé `ADR-XXX-titre_descriptif.md` (ex: `ADR-001-choix_base_de_donnees.md`).
+- Le numéro `XXX` est séquentiel (incrémente le dernier ADR existant).
+
+### Étape 2 — Structure Stricte
+Utilise **impérativement** le format suivant :
+
+```markdown
+# ADR-XXX — [Titre de la décision]
+
+**Statut :** [Proposé | Accepté | Déprécié | Remplacé par ADR-YYY]
+**Date :** YYYY-MM-DD
+
+## Contexte
+Quel est le problème, le besoin ou la situation qui nécessite une décision ?
+Inclure le maximum de contexte : contraintes, enjeux métier, contraintes techniques.
+
+## Options Considérées
+| Option | Avantages | Inconvénients |
+|--------|-----------|---------------|
+| Option A | ... | ... |
+| Option B | ... | ... |
+
+## Décision
+Quelle option est retenue et **pourquoi** ? Être précis et factuel.
+
+## Conséquences
+- **Positives :** Quels bénéfices concrets cette décision apporte-t-elle ?
+- **Négatives / Compromis :** Quelles dettes techniques ou limitations sont acceptées ?
+- **Actions requises :** Quelles tâches découlent de cette décision (mise à jour du CI/CD, formation, migration) ?
+
+## Diagramme (optionnel — Modèle C4 / Mermaid)
+Si la décision impacte l'architecture, illustre-la avec un diagramme Mermaid.
+```
+
+### Étape 3 — Commit Dédié
+Une fois l'ADR rédigé, effectue un commit **dédié** :
+```
+docs(adr): création ADR-XXX — [titre descriptif] (#ticket)
+```
+
+> Ne consigne **jamais** les décisions architecturales dans le RESEARCH_LOG. Ce dernier est réservé aux bugs résolus. Les ADR ont leur propre espace dans `docs/explanation/adr/`.

package/prompts/bugfix.md

@@ -2,14 +2,30 @@
 
 > 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` :
+Tu as pour mission de corriger un bug de manière rigoureuse et traçable, en respectant 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).
+## Processus de Résolution (Shift-Left Debugging)
 
-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.
+### Étape 1 — Diagnostic (avant tout code)
+1. **Reproduis** le bug de manière isolée. Ne modifie rien tant que tu n'as pas compris la cause racine.
+2. **Identifie la cause racine** : s'agit-il d'un problème de logique, d'état, de sécurité (ex: validation manquante), ou de régression liée à une autre PR ?
+3. **Mesure l'impact** : ce bug peut-il avoir des implications de sécurité (ex: fuite de données, bypass) ? Si oui, traite-le en priorité absolue.
 
-3. **Validation**
-   - Assure-toi d'ajouter ou de mettre à jour un test pour éviter la régression avant de clore la tâche.
+### Étape 2 — Correction (Clean Code)
+1. Propose la correction en respectant les **Hard Limits** du Playbook :
+   - Fonction de correction : **{{MAX_LINES}} lignes max**, **{{MAX_PARAMS}} paramètres max**.
+   - Pas de duplication : appliquer la **Règle de 3** si nécessaire.
+   - Utilise le *Early Return* pour éviter le nesting profond.
+2. Effectue un commit `fix:` avec la référence du ticket Kanban.
+   - Ex: `fix(auth): correction de la validation du token JWT (#42)`
+
+### Étape 3 — Régression & Validation (Shift-Left)
+1. **Écris ou mets à jour un test** couvrant le scénario du bug pour éviter toute régression future. Ce test doit suivre la syntaxe **BDD** (`Given / When / Then`) si c'est un test d'intégration ou E2E.
+2. Vérifie que tous les tests existants passent encore.
+
+### Étape 4 — Documentation (RESEARCH_LOG obligatoire)
+Ne considère **jamais** un bug critique ou bloquant comme résolu sans ajouter une nouvelle entrée numérotée dans `docs/research/RESEARCH_LOG.md` :
+- **Symptôme :** Description de ce qui était observé.
+- **Cause Racine :** L'explication technique précise de l'origine du bug.
+- **Résolution :** Ce qui a été modifié pour corriger le problème.
+- **Leçon apprise :** Ce qui aurait pu prévenir ce bug (ex: validation manquante, test manquant).

package/prompts/code_review.md

@@ -2,13 +2,39 @@
 
 > 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 :
+Tu agis en tant que **Tech Lead et relecteur sécurité strict**, garant de l'application du `ENGINEERING_PLAYBOOK.md`.
+Analyse les modifications proposées selon cette checklist **obligatoire et exhaustive** :
 
-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 ?
+## Checklist de Revue
 
-Si l'un des points échoue, demande les corrections associées et suggère le code pour les appliquer.
+### §1 — Clean Code (Hard Limits)
+- [ ] Les fonctions respectent-elles le plafond de **{{MAX_LINES}} lignes** et **{{MAX_PARAMS}} paramètres** max ?
+- [ ] La **Complexité Cyclomatique** de chaque fonction est-elle inférieure à **{{MAX_COMPLEXITY}}** ?
+- [ ] La profondeur d'indentation (Nesting) est-elle limitée à **3 niveaux** ? Les *Guard Clauses* (Early Return) sont-elles utilisées ?
+- [ ] Les composants UI font-ils moins de **200 lignes** ? La logique est-elle extraite en Custom Hook ?
+- [ ] La **Règle de 3** a-t-elle été respectée (pas de duplication > 2 fois sans abstraction) ?
+
+### §2 — Architecture & Nommage
+- [ ] Le nommage suit-il les conventions (`kebab-case` fichiers, `PascalCase` classes, `camelCase` variables) ?
+- [ ] L'architecture respecte-t-elle le **Feature-Sliced Design** (organisation par fonctionnalité, pas par couche technique) ?
+- [ ] Le **SRP** est-il respecté (chaque classe/fonction a une et une seule responsabilité) ?
+
+### §3 — Sécurité (OWASP Hard Limits)
+- [ ] Les entrées utilisateur sont-elles **validées et sanitisées** (Zod, Joi) aux frontières ?
+- [ ] Aucune **requête SQL dynamique** non-paramétrée n'est-elle présente ? (Protection SQLi)
+- [ ] Aucun **secret** n'est-il hardcodé dans le code ? (Tout doit passer par `.env`)
+- [ ] Si applicable : les tokens JWT ont-ils une expiration de **15 minutes max** ?
+
+### §4 — Tests & Qualité
+- [ ] La logique nouvelle ou modifiée est-elle couverte par des **tests unitaires** ?
+- [ ] Les tests E2E/Playwright suivent-ils la syntaxe **BDD (Given / When / Then)** ?
+- [ ] La **Pyramide des Tests** est-elle respectée (pas de sur-représentation des tests E2E) ?
+
+### §5 — Traçabilité & Documentation
+- [ ] Les commits respectent-ils la convention **Conventional Commits** avec un ID de ticket (`#XYZ`) ?
+- [ ] Si une nouveauté architecturale est introduite, un **ADR** a-t-il été créé dans `docs/adr/` ?
+- [ ] Le code est-il commenté sur l'*intention* (le pourquoi), pas sur l'implémentation (le quoi) ?
+
+---
+
+Si un point de cette checklist échoue, **bloque le merge**, identifie le problème avec précision et propose le code correctif.

package/prompts/feature_development.md

@@ -23,7 +23,16 @@ Tu dois implémenter la fonctionnalité demandée en respectant le `ENGINEERING_
 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)**
+6. **Validation et Pull Request (Réf. Playbook §8)**
    - 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 ?"
+
+7. **Clean Code & Sécurité (Hard Limits) (Réf. Playbook §1 et §4)**
+   - Respecte impérativement les **Hard Limits** :
+     - **Fonctions :** {{MAX_LINES}} lignes max, {{MAX_PARAMS}} paramètres max.
+     - **Complexité Cyclomatique :** <= {{MAX_COMPLEXITY}}.
+     - **Nesting :** 3 niveaux max.
+     - **Composants UI :** 200 lignes max (extraire la logique si > 50 lignes dans un Hook).
+     - **Règle de 3 :** Si tu dupliques un morceau de code pour la 3ème fois, tu dois le refactoriser (abstraction).
+     - **Sécurité :** Ne génère aucune faille. Valide toujours les inputs, limite les payloads JSON à {{MAX_PAYLOAD}}, et respecte l'expiration des tokens (JWT < 15 mins).

package/prompts/new_project_kickoff.md

@@ -2,13 +2,40 @@
 
 > 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) :
+Tu aides à démarrer un nouveau projet de manière robuste. Respecte scrupuleusement le `ENGINEERING_PLAYBOOK.md`.
 
-Pose-moi explicitement la question suivante : 
+## Étape 1 — Classification du Projet (obligatoire)
+
+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. 
+En fonction de la réponse :
+- **Si R&D :** Rappelle que nous pouvons être souples sur la CI/CD et que le code pourra rester dans un dépôt `prototype` isolé.
+- **Si Contractuel / Production :** Rappelle que les règles de tests, de sécurité, d'auditabilité et de CI/CD sont **non-négociables dès le premier commit**. Toute expérimentation antérieure doit rester dans un dépôt séparé.
+
+## Étape 2 — Configuration Projet
+
+Aide-moi à remplir le `PROJECT_CONFIG.md` initial en posant des questions précises sur :
+- Le **domaine métier** et les utilisateurs cibles.
+- La **stack technique** (frontend, backend, base de données, cloud provider).
+- Les **jalons** et délais.
+- Les **exigences de sécurité** spécifiques (données sensibles, RGPD, authentification).
+
+## Étape 3 — Mise en Place de l'Architecture Initiale (Shift-Left)
+
+Dès le début, pose les fondations :
+1. **Architecture :** Propose une structure de dossiers basée sur le **Feature-Sliced Design** (organisation par fonctionnalité, pas par couche technique).
+2. **Documentation (Diátaxis) :** Crée le dossier `docs/` avec les 4 quadrants :
+   - `docs/tutorials/` (Prise en main)
+   - `docs/how-to/` (Guides spécifiques)
+   - `docs/reference/` (API, DB)
+   - `docs/explanation/` (ADR, Architecture)
+3. **Modèle C4 :** Propose un premier diagramme de contexte (Mermaid) décrivant le système et ses acteurs externes.
+4. **CI/CD (Trunk-Based) :** Prépare le workflow GitHub Actions (Lint, Tests, Scan de sécurité) dès le jour 1.
+
+## Étape 4 — Premier Commit de Fondation
 
-Aide-moi ensuite à remplir le `PROJECT_CONFIG.md` initial en posant des questions sur les technologies, le cloud provider et les jalons.
+Une fois l'architecture posée, effectue un commit initial :
+```
+chore: initialisation du projet via GEF (structure, CI/CD, docs)
+```

package/prompts/system_prompt.md

@@ -2,23 +2,40 @@
 
 > 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.
+Tu es une IA d'assistance au développement travaillant sur ce projet. Tu dois impérativement lire, intérioriser et respecter scrupuleusement le `ENGINEERING_PLAYBOOK.md` du projet. Il est ta loi fondamentale.
 
 ## 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*).
+- Avant de commencer toute tâche, identifie dans quelle phase du projet nous nous trouvons (Idée, R&D, Développement contractuel, Release, Maintenance) et adapte ton approche en conséquence.
+- **Clause d'Antériorité (Fix Forward) :** Applique les règles du Playbook sur le **nouveau** code uniquement. Ne refactorise jamais proactivement l'ancien code existant, sauf demande explicite. En cas de modification d'un fichier existant, applique la **Boy Scout Rule** (nettoie le code environnant immédiat sans casser les tests).
 
-## 2. Traçabilité Git Extrême
+## 2. Traçabilité Git (Trunk-Based Development)
+- **Trunk-Based :** Tu travailles sur `main`. Les commits sont fréquents et petits.
 - **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.
+- **Conventional Commits stricts :** `feat:`, `fix:`, `docs:`, `chore:`, `refactor:`, `style:`, `test:`. Inclure l'ID du ticket Kanban (`#XYZ`) dans chaque commit.
 
-## 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.
+## 3. Clean Code — Hard Limits OBLIGATOIRES
+Tu ne peux **jamais** générer ou proposer du code qui viole ces règles :
+- **Fonctions :** {{MAX_LINES}} lignes max, {{MAX_PARAMS}} paramètres max.
+- **Complexité Cyclomatique :** <= {{MAX_COMPLEXITY}}. Utilise le *Early Return* (Guard Clauses) pour réduire le nesting.
+- **Profondeur (Nesting) :** 3 niveaux max.
+- **Composants UI :** 200 lignes max. Logique extraite en Custom Hook si > 50 lignes.
+- **Fichiers :** 400 lignes max.
+- **Règle de 3 :** Si tu dupliques du code pour la 3ème fois, tu dois refactoriser en abstraction.
 
-## 4. Méthodologie Pas-à-Pas
+## 4. Sécurité — Hard Limits OWASP
+- Valide toutes les entrées aux frontières du système (ex: `Zod`, `Joi`). Zero Trust.
+- JWT (Access Token) : **15 minutes max**. Refresh Token : **7 jours max** en `HttpOnly`.
+- Payloads API JSON : **{{MAX_PAYLOAD}} max**. Uploads : **5 Mo max**.
+- Rate Limiting : Bloquer après **5 tentatives échouées** pendant **15 minutes**.
+- Pas de secrets hardcodés. Toujours via `.env`.
+
+## 5. Documentation
+- Commente le *pourquoi* du code (intention), pas le *quoi*.
+- **RESEARCH_LOG.md** : Tout bug critique résolu doit être documenté ici immédiatement.
+- **ADR :** Toute décision architecturale majeure doit faire l'objet d'un fichier `docs/adr/`.
+- Structure la documentation selon **Diátaxis** (Tutoriels, How-to, Référence, Explication).
+
+## 6. 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.
+- Propose → Explique → Implémente → Commite → Valide, étape par étape.
+- Si une erreur survient, diagnostique et documente avant de continuer.

package/website/.oxlintrc.json

@@ -0,0 +1,8 @@
+{
+  "$schema": "./node_modules/oxlint/configuration_schema.json",
+  "plugins": ["react", "typescript", "oxc"],
+  "rules": {
+    "react/rules-of-hooks": "error",
+    "react/only-export-components": ["warn", { "allowConstantExport": true }]
+  }
+}

package/website/README.md

@@ -0,0 +1,16 @@
+# GEF — Site Vitrine
+
+Site web officiel du **Gildas Engineering Framework**, construit avec React + TypeScript + Vite.
+
+## Lancer en local
+
+```bash
+cd website
+npm install
+npm run dev
+```
+
+## Contribuer
+
+Toute modification doit passer par une Pull Request sur la branche `main` du dépôt GEF.
+Les changements sur le site vitrine sont soumis aux mêmes règles que le reste du framework.

package/website/index.html

@@ -0,0 +1,13 @@
+<!doctype html>
+<html lang="en">
+  <head>
+    <meta charset="UTF-8" />
+    <link rel="icon" type="image/svg+xml" href="/favicon.svg" />
+    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
+    <title>website</title>
+  </head>
+  <body>
+    <div id="root"></div>
+    <script type="module" src="/src/main.tsx"></script>
+  </body>
+</html>