feats : automatisation des process

00_INDEX.md

@@ -0,0 +1,151 @@
+# Lead_tech — Index de la base de connaissance
+
+Ce repository constitue la **mémoire inter‑projets** et la **doctrine technique** utilisée par les agents et les projets.
+
+Il centralise :
+
+- les conventions globales
+- les patterns validés
+- les décisions d’architecture
+- les post‑mortems
+- les playbooks réutilisables
+
+---
+
+# Structure de la base de connaissance
+
+## Contexte global
+
+- `CLAUDE.md`  
+  Instructions globales chargées automatiquement par les agents.
+
+- `AGENTS.md`  
+  Alias vers `CLAUDE.md` pour compatibilité avec certains outils.
+
+---
+
+## Patterns validés
+
+Patterns éprouvés en production ou en projets réels.
+
+- `10_backend_patterns_valides.md`
+- `10_frontend_patterns_valides.md`
+
+---
+
+## Risques et anti‑patterns
+
+Situations connues pouvant entraîner :
+
+- bugs difficiles
+- dette technique
+- complexité inutile
+
+- `10_backend_risques_et_vigilance.md`
+- `10_frontend_risques_et_vigilance.md`
+
+---
+
+## Workflows et intégrations
+
+Procédures de travail et intégrations techniques.
+
+- `20_workflows_README.md`
+- `30_integrations_README.md`
+
+---
+
+## Décisions d’architecture
+
+Mini‑ADR documentant les choix techniques structurants.
+
+- `40_decisions_et_archi.md`
+
+---
+
+## Idées et explorations
+
+Zone de réflexion pour des idées non encore validées.
+
+- `50_idees_en_vrac.md`
+
+---
+
+## Playbooks
+
+Procédures opérationnelles réutilisables.
+
+Exemples :
+
+- migration d’un projet vers le NUC
+- configuration d’un service partagé
+- bootstrap d’un projet
+
+Dossier :
+
+```
+60_playbooks/
+```
+
+---
+
+## Templates
+
+Modèles de fichiers et structures de projet.
+
+Exemples :
+
+- template `CLAUDE.md` pour projet
+- exemples de configuration Docker
+
+Dossier :
+
+```
+70_templates/
+```
+
+---
+
+## BMAD
+
+Documentation sur l’articulation entre la méthode BMAD et cette base de connaissance.
+
+Dossier :
+
+```
+80_bmad/
+```
+
+---
+
+## Debug et post‑mortems
+
+Historique de problèmes rencontrés et des solutions appliquées.
+
+- `90_debug_et_postmortem.md`
+
+---
+
+# Principe fondamental
+
+Toute information ajoutée ici doit être :
+
+- **réutilisable sur plusieurs projets**
+- **validée par l’expérience**
+- **utile pour réduire le temps de debug**
+
+Sinon elle doit rester dans le projet concerné.
+
+---
+
+# Capitalisation
+
+Lorsqu’un nouveau pattern ou apprentissage apparaît :
+
+```
+FILE_UPDATE_PROPOSAL
+Fichier : ...
+Pourquoi : ...
+```
+
+Puis proposer le contenu à ajouter dans le fichier approprié.

60_playbooks/bootstrap_projet_docker.md

@@ -0,0 +1,184 @@
+# Playbook — Bootstrap d’un projet Docker sur le NUC
+
+Ce document décrit la procédure standard pour **initialiser un nouveau projet Docker** sur l’environnement NUC (`docker-dev`).
+
+Objectifs :
+
+- garantir une structure cohérente entre les projets
+- centraliser les volumes persistants
+- préparer le projet pour le développement via VSCode Remote / SSH
+
+---
+
+# Architecture standard du NUC
+
+Tous les projets suivent la structure suivante :
+
+```
+/srv/
+  projects/        # code source des projets
+  docker-data/     # volumes persistants Docker
+  backups/         # sauvegardes
+```
+
+Exemple pour un projet `portfolio` :
+
+```
+/srv/projects/portfolio
+/srv/docker-data/portfolio/
+```
+
+---
+
+# Étape 1 — Cloner le projet
+
+Depuis la VM `docker-dev` :
+
+```
+cd /srv/projects
+git clone <repo>
+cd <repo>
+```
+
+Exemple :
+
+```
+git clone git@github.com:xxx/portfolio.git
+```
+
+---
+
+# Étape 2 — Préparer les volumes persistants
+
+Créer le dossier dédié au projet :
+
+```
+mkdir -p /srv/docker-data/<nom-projet>
+```
+
+Exemples :
+
+```
+/srv/docker-data/portfolio/postgres
+/srv/docker-data/portfolio/uploads
+```
+
+Principe :
+
+- **aucune donnée persistante ne doit vivre dans le repo Git**
+- tous les volumes doivent être externalisés dans `/srv/docker-data`
+
+---
+
+# Étape 3 — Adapter le docker-compose
+
+Les services doivent utiliser les volumes du NUC.
+
+Exemple :
+
+```yaml
+services:
+  postgres:
+    image: postgres:17
+    volumes:
+      - /srv/docker-data/portfolio/postgres:/var/lib/postgresql/data
+```
+
+Bonnes pratiques :
+
+- éviter les volumes anonymes
+- préférer les chemins absolus
+
+---
+
+# Étape 4 — Préparer la base de données (si nécessaire)
+
+Si le projet utilise la base partagée :
+
+```
+psql -U postgres_su
+```
+
+Créer :
+
+```
+CREATE USER <user> WITH PASSWORD '<password>';
+CREATE DATABASE <db> OWNER <user>;
+```
+
+---
+
+# Étape 5 — Initialiser la mémoire projet
+
+Dans le repo :
+
+1. copier le template :
+
+```
+70_templates/projet_CLAUDE.md
+```
+
+2. créer le fichier :
+
+```
+CLAUDE.md
+```
+
+3. créer le symlink pour Codex :
+
+```
+ln -s CLAUDE.md AGENTS.md
+```
+
+Ce fichier servira de **mémoire active du projet**.
+
+---
+
+# Étape 6 — Lancer l’environnement
+
+Depuis le dossier du projet :
+
+```
+docker compose up -d
+```
+
+Vérifier :
+
+```
+docker ps
+```
+
+---
+
+# Étape 7 — Vérification
+
+Contrôler :
+
+- que les conteneurs démarrent correctement
+- que les volumes sont bien montés
+- que la base de données est accessible
+
+Commandes utiles :
+
+```
+docker compose logs -f
+docker logs <container>
+```
+
+---
+
+# Bonnes pratiques
+
+- garder les volumes hors du repo
+- documenter la stack dans `CLAUDE.md`
+- vérifier les ports exposés
+
+---
+
+# Quand utiliser ce playbook
+
+Ce playbook doit être utilisé lorsque :
+
+- un **nouveau projet Docker** est créé
+- un projet est **installé pour la première fois sur le NUC**
+- un environnement doit être **reproduit sur une nouvelle machine**

60_playbooks/migration_projet_vers_nuc.md

@@ -0,0 +1,159 @@
+# Playbook — Migration d’un projet vers le NUC
+
+Ce document décrit la procédure standard pour migrer un projet local (Mac / Docker Desktop) vers l’environnement **NUC Docker Dev**.
+
+Objectifs :
+
+- centraliser l’exécution des conteneurs sur le NUC
+- garder le code sur le NUC pour le développement via SSH / VSCode
+- uniformiser la structure des projets
+
+---
+
+# Architecture cible
+
+Sur le NUC :
+
+```
+/srv/
+  projects/        # code des projets
+  docker-data/     # volumes persistants
+  backups/         # sauvegardes
+```
+
+Exemple pour un projet :
+
+```
+/srv/projects/portfolio
+```
+
+Les volumes Docker doivent vivre dans :
+
+```
+/srv/docker-data/<nom-projet>/
+```
+
+---
+
+# Étape 1 — Cloner le projet sur le NUC
+
+Depuis le NUC :
+
+```
+cd /srv/projects
+git clone <repo>
+```
+
+Exemple :
+
+```
+git clone git@github.com:xxx/portfolio.git
+```
+
+---
+
+# Étape 2 — Adapter docker-compose
+
+Les projets ne doivent pas dépendre de Docker Desktop.
+
+Principes :
+
+- utiliser des **chemins absolus côté NUC** pour les volumes
+- éviter les volumes implicites Docker
+
+Exemple :
+
+```yaml
+volumes:
+  - /srv/docker-data/portfolio/postgres:/var/lib/postgresql/data
+```
+
+---
+
+# Étape 3 — Vérifier les dépendances système
+
+Sur la VM `docker-dev` :
+
+- Docker installé
+- Docker Compose disponible
+- Node / npm si nécessaire
+
+Vérifier :
+
+```
+docker --version
+docker compose version
+node -v
+```
+
+---
+
+# Étape 4 — Lancer les conteneurs
+
+Depuis le dossier du projet :
+
+```
+docker compose up -d
+```
+
+Vérifier :
+
+```
+docker ps
+```
+
+---
+
+# Étape 5 — Migration éventuelle des données
+
+Si le projet utilisait Docker Desktop :
+
+1. exporter la base
+
+```
+pg_dump -U user dbname > dump.sql
+```
+
+2. copier le dump sur le NUC
+
+3. restaurer :
+
+```
+psql -U user dbname < dump.sql
+```
+
+---
+
+# Étape 6 — Vérification
+
+Vérifier :
+
+- l’application démarre
+- la base de données est accessible
+- les migrations fonctionnent
+- les logs ne contiennent pas d’erreurs
+
+Commandes utiles :
+
+```
+docker logs <container>
+docker compose logs -f
+```
+
+---
+
+# Bonnes pratiques
+
+- ne jamais stocker de données persistantes dans `/srv/projects`
+- tous les volumes doivent vivre dans `/srv/docker-data`
+- documenter les migrations importantes
+
+---
+
+# Quand utiliser ce playbook
+
+Ce playbook doit être utilisé lorsque :
+
+- un projet Docker Desktop est migré vers le NUC
+- un nouveau projet est installé sur le NUC
+- un projet doit être reproduit sur un nouvel environnement

60_playbooks/restaurer_backup_projet.md

@@ -0,0 +1,201 @@
+# Playbook — Restaurer un projet depuis un backup
+
+Ce playbook décrit la procédure standard pour **restaurer un projet Docker sur le NUC** à partir d’une sauvegarde.
+
+Il couvre principalement :
+
+- restauration de base de données
+- restauration de volumes persistants
+- redémarrage de la stack Docker
+
+Ce playbook est utilisé après :
+
+- une migration
+- une perte de données
+- la recréation d’un environnement
+
+---
+
+# Architecture de référence
+
+Sur le NUC, les données vivent dans :
+
+```
+/srv/
+  projects/        # code source
+  docker-data/     # volumes persistants
+  backups/         # sauvegardes
+```
+
+Les backups sont stockés dans :
+
+```
+/srv/backups/
+```
+
+Exemple :
+
+```
+/srv/backups/portfolio/
+```
+
+---
+
+# Étape 1 — Vérifier que le projet existe
+
+Le projet doit être présent dans :
+
+```
+/srv/projects/<nom-projet>
+```
+
+Sinon :
+
+```
+cd /srv/projects
+git clone <repo>
+```
+
+---
+
+# Étape 2 — Arrêter la stack
+
+Avant toute restauration, arrêter les conteneurs :
+
+```
+cd /srv/projects/<nom-projet>
+docker compose down
+```
+
+Cela évite les corruptions de données.
+
+---
+
+# Étape 3 — Restaurer les volumes persistants
+
+Si le backup contient des volumes :
+
+Exemple :
+
+```
+/srv/backups/portfolio/uploads
+/srv/backups/portfolio/postgres
+```
+
+Restaurer dans :
+
+```
+/srv/docker-data/<nom-projet>/
+```
+
+Exemple :
+
+```
+cp -r /srv/backups/portfolio/uploads /srv/docker-data/portfolio/
+```
+
+Important :
+
+- vérifier les permissions
+- vérifier que les dossiers existent
+
+---
+
+# Étape 4 — Restaurer la base de données
+
+Si un dump SQL est disponible :
+
+Exemple :
+
+```
+/srv/backups/portfolio/db.sql
+```
+
+Importer :
+
+```
+psql -U <user> -d <database> -f db.sql
+```
+
+Exemple concret :
+
+```
+psql -U portfolio_user -d portfolio -f /srv/backups/portfolio/db.sql
+```
+
+---
+
+# Étape 5 — Vérifier la configuration Docker
+
+Contrôler :
+
+- chemins des volumes
+- variables d’environnement
+- ports
+
+Fichier principal :
+
+```
+docker-compose.yml
+```
+
+---
+
+# Étape 6 — Redémarrer le projet
+
+Depuis le dossier projet :
+
+```
+docker compose up -d
+```
+
+Vérifier :
+
+```
+docker ps
+```
+
+---
+
+# Étape 7 — Vérifications post-restauration
+
+Contrôler :
+
+- que l’application démarre
+- que la base contient bien les données
+- que les volumes sont montés
+
+Commandes utiles :
+
+```
+docker compose logs -f
+```
+
+ou
+
+```
+docker logs <container>
+```
+
+---
+
+# Bonnes pratiques
+
+- toujours arrêter la stack avant restauration
+- restaurer les volumes **avant** de relancer Docker
+- vérifier les permissions des dossiers
+
+---
+
+# Quand utiliser ce playbook
+
+Utiliser ce playbook lorsque :
+
+- un projet doit être restauré après incident
+- un environnement doit être reconstruit
+- une sauvegarde doit être testée
+
+Ce playbook complète :
+
+- `bootstrap_projet_docker.md`
+- `migration_projet_vers_nuc.md`

70_templates/projet_CLAUDE.md

@@ -0,0 +1,284 @@
+# CLAUDE.md — Contexte et mémoire du projet {{PROJECT_NAME}}
+
+Ce fichier sert de **mémoire active du projet**.
+
+Ce projet hérite des règles globales définies dans **Lead_tech**.
+
+Dans l’environnement de travail, `Lead_tech` est généralement accessible via
+**un symlink local** pointant vers le repository contenant les règles globales.
+
+Pour les agents, la porte d’entrée de ces règles est :
+
+- `~/CLAUDE.md` : symlink vers `~/Lead_tech/CLAUDE.md`
+- `~/AGENTS.md` : symlink vers `~/Lead_tech/CLAUDE.md`
+
+Ce fichier sert de **point d’entrée vers la base de connaissance globale** (patterns,
+anti-patterns, décisions d’architecture, debug).
+
+Les règles définies dans ce fichier **complètent** ces règles globales.
+
+Ce mécanisme permet au projet de rester portable entre environnements (Mac, NUC, serveur, etc.) tout en conservant un socle de règles global partagé.
+
+Hiérarchie des règles :
+
+1. contraintes réelles du code et de l’infrastructure
+2. règles définies dans ce fichier (projet)
+3. règles globales `Lead_tech`
+
+Ce fichier doit permettre à un agent (Claude, Codex, etc.) de comprendre rapidement :
+
+- la stack
+- les conventions importantes
+- les patterns appliqués
+- l’état actuel du projet
+- les pièges connus
+
+---
+
+# Contexte du projet
+
+Nom :  
+Objectif :  
+Statut : (exploration / MVP / production / maintenance)
+
+Description rapide du produit ou du service.
+
+---
+
+# Stack technique
+
+- backend :
+- frontend :
+- base de données :
+- cache :
+- infra :
+- tests :
+
+Préciser les frameworks et versions importantes.
+
+Exemple :
+
+- NestJS strict
+- Next.js / Expo
+- PostgreSQL
+- Prisma
+
+---
+
+# Architecture du projet
+
+Structure principale du repo.
+
+Exemple :
+
+```
+apps/
+  api/
+  web/
+packages/
+  contracts/
+infra/
+```
+
+Règles importantes :
+
+- responsabilités de chaque dossier
+- ce qui doit rester partagé
+- ce qui doit rester local à une app
+
+---
+
+# Cartographie rapide du code
+
+Objectif : permettre à un agent de comprendre **où se trouvent les responsabilités principales du projet** sans scanner tout le repository.
+
+Exemple :
+
+Backend principal
+→ `apps/api`
+
+Frontend web
+→ `apps/web`
+
+Contrats partagés (types / schémas / validation)
+→ `packages/contracts`
+
+Infrastructure / Docker / déploiement
+→ `infra`
+
+Tests
+→ `apps/api/tests`
+
+Principes :
+
+- la logique métier doit rester côté backend
+- les contrats doivent être centralisés
+- éviter la duplication de logique entre apps
+
+Adapter cette cartographie à la structure réelle du projet.
+
+---
+
+# Commandes du projet
+
+Lister ici les commandes principales permettant de travailler sur le projet.
+
+Objectif : permettre à un agent ou à un développeur de comprendre rapidement
+comment installer, lancer et tester l’application.
+
+Exemple :
+
+Installation :
+
+```
+npm install
+```
+
+Lancer le backend :
+
+```
+npm run dev:api
+```
+
+Lancer le frontend :
+
+```
+npm run dev:web
+```
+
+Tests :
+
+```
+npm run test
+```
+
+Build :
+
+```
+npm run build
+```
+
+Ajouter également si nécessaire :
+
+- commandes de migration de base de données
+- commandes de seed
+- commandes Docker
+- commandes d’environnement local
+
+---
+
+# Patterns critiques du projet
+
+Lister ici les patterns **spécifiques à ce projet**.
+
+Ils complètent les patterns globaux définis dans `Lead_tech`.
+
+Exemples :
+
+- contracts-first
+- architecture hexagonale
+- structure des modules
+- conventions d’erreurs API
+
+Chaque pattern doit expliquer **pourquoi il existe**.
+
+---
+
+# Conventions spécifiques
+
+Conventions propres au projet.
+
+Exemples :
+
+- gestion des erreurs
+- nommage des modules
+- structure des services
+- conventions Prisma / ORM
+
+---
+
+# Statut du projet
+
+Décrire l’état actuel du développement.
+
+Exemple :
+
+Epic / milestone en cours :
+
+- Epic 1 : done
+- Epic 2 : in-progress
+
+Ou bien :
+
+- MVP en production
+- refactor backend en cours
+
+---
+
+# Leçons apprises
+
+Capitaliser ici les apprentissages importants du projet.
+
+Exemples :
+
+- décisions d’architecture validées
+- erreurs rencontrées
+- améliorations à appliquer sur les prochaines features
+
+---
+
+# Dette technique
+
+Lister la dette technique identifiée.
+
+Format conseillé :
+
+- description
+- niveau (LOW / MEDIUM / HIGH)
+
+Exemple :
+
+- tests E2E incomplets (MEDIUM)
+- refactor service auth nécessaire (LOW)
+
+---
+
+# Points sensibles
+
+Parties du projet nécessitant une vigilance particulière.
+
+Exemples :
+
+- sécurité
+- authentification
+- logique financière
+- migrations de base de données
+
+---
+
+# Références
+
+Voir également :
+
+- règles globales : `Lead_tech/CLAUDE.md`
+- patterns backend
+- patterns frontend
+- debug et post-mortems
+
+---
+
+# Mise à jour
+
+Ce fichier doit être mis à jour lorsque :
+
+- une décision d’architecture importante est prise
+- un pattern spécifique apparaît
+- une dette technique significative est identifiée
+
+Si une information devient **utile à plusieurs projets**, proposer :
+
+```
+FILE_UPDATE_PROPOSAL
+```
+
+pour la remonter dans la base `Lead_tech`.

80_bmad/articulation_avec_lead_tech.md

@@ -0,0 +1,84 @@
+# BMAD — articulation avec Lead_tech
+
+BMAD fournit une méthode de travail basée sur des agents spécialisés.
+
+Le repository `Lead_tech` fournit :
+
+- la mémoire inter-projets
+- les conventions globales
+- les patterns validés
+- les décisions d'architecture
+
+---
+
+# Principe
+
+BMAD ne remplace pas `Lead_tech`.
+
+BMAD s'appuie dessus.
+
+---
+
+# Répartition des responsabilités
+
+## Lead_tech
+
+Contient :
+
+- patterns validés
+- décisions d'architecture
+- conventions globales
+- playbooks
+- post-mortems
+
+## Projet
+
+Contient :
+
+- le code
+- les règles spécifiques
+- l'architecture locale
+- les conventions propres au projet
+
+## Agents BMAD
+
+Responsables de :
+
+- cadrer
+- implémenter
+- reviewer
+- améliorer le code
+
+---
+
+# Règle importante
+
+Avant d'introduire :
+
+- un nouveau pattern
+- une nouvelle convention
+- une nouvelle architecture
+
+les agents doivent vérifier la base `Lead_tech`.
+
+---
+
+# Capitalisation
+
+Si un pattern devient réutilisable :
+
+Proposer une mise à jour :
+
+```
+FILE_UPDATE_PROPOSAL
+Fichier : …
+Pourquoi : …
+```
+
+---
+
+# Hiérarchie de contexte
+
+1. contraintes techniques réelles
+2. règles du projet
+3. règles globales (`Lead_tech`)

AGENTS.md

@@ -1,61 +0,0 @@
-# Instructions globales — Lead Tech Copilote
-
-Ce fichier est chargé automatiquement par Codex à chaque session.
-Il pointe vers la base de connaissance commune à tous les projets.
-
-## Rôle et posture
-
-Tu es mon copilote principal : technicien, lead tech, coach et challenger.
-Priorité absolue : justesse, robustesse, réduction du temps de debug.
-Jamais de sur-ingénierie. Jamais d'invention de comportements incertains.
-
-Langue de travail : **français**.
-
-## Base de connaissance à consulter en priorité
-
-Ces fichiers sont la mémoire durable inter-projets. Consulte-les avant de proposer
-une solution dans leur domaine respectif.
-
-| Fichier | Contenu |
-|---|---|
-| `10_backend_patterns_valides.md` | Patterns backend validés en conditions réelles |
-| `10_frontend_patterns_valides.md` | Patterns frontend/mobile validés |
-| `10_backend_risques_et_vigilance.md` | Risques et anti-patterns backend |
-| `10_frontend_risques_et_vigilance.md` | Risques et anti-patterns frontend |
-| `40_decisions_et_archi.md` | Décisions techniques (mini-ADR) |
-| `90_debug_et_postmortem.md` | Post-mortems et bugs capitalisés |
-
-## Règles de mise à jour
-
-Quand tu repères qu'un pattern mérite d'être capitalisé :
-
-```
-FILE_UPDATE_PROPOSAL
-Fichier : `<nom_du_fichier>`
-Pourquoi : <1-2 phrases>
-```
-
-Puis propose le contenu à ajouter dans le format du fichier cible.
-
-## Projets actifs
-
-| Projet | Stack | Localisation | État |
-|---|---|---|---|
-| app-alexandrie | NestJS + Expo (React Native) + Prisma + pnpm monorepo | `/srv/projects/app-alexandrie` | Epic 2 en préparation |
-
-## Patterns clés à appliquer systématiquement
-
-- **Contracts-First / Zod-Infer / No-DTO** : voir `10_backend_patterns_valides.md`
-- **Navigation réactive useEffect** : voir `10_frontend_patterns_valides.md`
-- **Guard NestJS — ordre d'enregistrement** : voir `10_backend_patterns_valides.md`
-- **Format d'erreur API standardisé** : `{ error: { code, message, requestId } }`
-- **Sessions avec TTL** : toujours un champ `expiresAt`, filtrer dans les queries
-
-## Infrastructure NUC
-
-Convention de structure Docker sur le NUC (Proxmox) :
-- `/srv/projects` — code applicatif
-- `/srv/docker-data` — données persistantes (bind mounts explicites)
-- `/srv/backups` — dumps et archives
-
-Éviter SQL Server en LXC Proxmox → préférer PostgreSQL/MariaDB (voir `90_debug_et_postmortem.md`).

AGENTS.md

@@ -0,0 +1 @@
+/Users/maks/AI_RULES/_Assistant_Lead_Tech/CLAUDE.md

CLAUDE.md

@@ -1,6 +1,6 @@
 # Instructions globales — Lead Tech Copilote
 
-Ce fichier est chargé automatiquement par Claude Code à chaque session.
+Ce fichier est chargé automatiquement par Claude Code ou Codex à chaque session.
 Il pointe vers la base de connaissance commune à tous les projets.
 
 ## Rôle et posture
@@ -41,7 +41,7 @@ Puis propose le contenu à ajouter dans le format du fichier cible.
 
 | Projet | Stack | Localisation | État |
 |---|---|---|---|
-| app-alexandrie | NestJS + Expo (React Native) + Prisma + pnpm monorepo | `/srv/projects/app-alexandrie` | Epic 2 en préparation |
+| app-alexandrie | NestJS + Expo (React Native) + Prisma + pnpm monorepo | `/Volumes/TeraSSD/Projets_Dev/__Mindleaf/app-alexandrie` | Epic 2 en préparation |
 
 ## Patterns clés à appliquer systématiquement
 

generate_project_claude.sh

@@ -0,0 +1,46 @@
+#!/usr/bin/env bash
+
+set -euo pipefail
+
+# If no arguments are provided, infer project name and path from current directory
+if [ $# -eq 0 ]; then
+  PROJECT_PATH="$(pwd)"
+  PROJECT_NAME="$(basename "$PROJECT_PATH")"
+
+# If one argument is provided, treat it as the project name and use current directory
+elif [ $# -eq 1 ]; then
+  PROJECT_NAME="$1"
+  PROJECT_PATH="$(pwd)"
+
+# If two arguments are provided, keep explicit behaviour
+elif [ $# -eq 2 ]; then
+  PROJECT_NAME="$1"
+  PROJECT_PATH="$2"
+
+else
+  echo "Usage:"
+  echo "generate_project_claude.sh"
+  echo "generate_project_claude.sh <project_name>"
+  echo "generate_project_claude.sh <project_name> <project_path>"
+  exit 1
+fi
+
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+TEMPLATE="$SCRIPT_DIR/70_templates/projet_CLAUDE.md"
+
+OUTPUT="$PROJECT_PATH/CLAUDE.md"
+
+if [ ! -f "$TEMPLATE" ]; then
+  echo "Template introuvable : $TEMPLATE"
+  exit 1
+fi
+
+mkdir -p "$PROJECT_PATH"
+
+sed "s/{{PROJECT_NAME}}/${PROJECT_NAME}/g" "$TEMPLATE" > "$OUTPUT"
+
+rm -f "$PROJECT_PATH/AGENTS.md"
+ln -s CLAUDE.md "$PROJECT_PATH/AGENTS.md"
+
+echo "✔ CLAUDE.md créé : $OUTPUT"
+echo "✔ AGENTS.md -> CLAUDE.md"

sync-ai-instructions.sh

@@ -1,6 +1,7 @@
 #!/usr/bin/env bash
 # sync-ai-instructions.sh
-# Génère CLAUDE.md et AGENTS.md depuis _AI_INSTRUCTIONS.md + _projects.conf
+# Génère CLAUDE.md depuis _AI_INSTRUCTIONS.md + _projects.conf
+# puis recrée AGENTS.md comme symlink vers CLAUDE.md
 # selon la machine courante (Darwin = Mac, Linux = NUC)
 
 set -euo pipefail
@@ -55,21 +56,25 @@ generate() {
   echo "  -> $dest"
 }
 
+ensure_symlink() {
+  local target="$1"
+  local link_path="$2"
+  rm -f "$link_path"
+  ln -s "$target" "$link_path"
+  echo "  -> $link_path -> $target"
+}
+
 echo "Sync AI instructions (OS: $OS)"
 
 CLAUDE_HEADER="# Instructions globales — Lead Tech Copilote
 
-Ce fichier est chargé automatiquement par Claude Code à chaque session.
+Ce fichier est chargé automatiquement par Claude Code ou Codex à chaque session.
-Il pointe vers la base de connaissance commune à tous les projets."
-
-CODEX_HEADER="# Instructions globales — Lead Tech Copilote
-
-Ce fichier est chargé automatiquement par Codex à chaque session.
 Il pointe vers la base de connaissance commune à tous les projets."
 
 generate "$CLAUDE_HEADER" "$HOME/.claude/CLAUDE.md"
 generate "$CLAUDE_HEADER" "$SCRIPT_DIR/CLAUDE.md"
-generate "$CODEX_HEADER"  "$HOME/.codex/AGENTS.md"
+
-generate "$CODEX_HEADER"  "$SCRIPT_DIR/AGENTS.md"
+ensure_symlink "$HOME/.claude/CLAUDE.md" "$HOME/.codex/AGENTS.md"
+ensure_symlink "$SCRIPT_DIR/CLAUDE.md" "$SCRIPT_DIR/AGENTS.md"
 
 echo "Sync terminé."