diff --git a/00_INDEX.md b/00_INDEX.md new file mode 100644 index 0000000..947f661 --- /dev/null +++ b/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é. diff --git a/60_playbooks/bootstrap_projet_docker.md b/60_playbooks/bootstrap_projet_docker.md new file mode 100644 index 0000000..598ba1a --- /dev/null +++ b/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 +cd +``` + +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/ +``` + +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 WITH PASSWORD ''; +CREATE DATABASE OWNER ; +``` + +--- + +# É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 +``` + +--- + +# 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** diff --git a/60_playbooks/migration_projet_vers_nuc.md b/60_playbooks/migration_projet_vers_nuc.md new file mode 100644 index 0000000..c4051c5 --- /dev/null +++ b/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// +``` + +--- + +# Étape 1 — Cloner le projet sur le NUC + +Depuis le NUC : + +``` +cd /srv/projects +git clone +``` + +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 +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 diff --git a/60_playbooks/restaurer_backup_projet.md b/60_playbooks/restaurer_backup_projet.md new file mode 100644 index 0000000..89d09b5 --- /dev/null +++ b/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/ +``` + +Sinon : + +``` +cd /srv/projects +git clone +``` + +--- + +# Étape 2 — Arrêter la stack + +Avant toute restauration, arrêter les conteneurs : + +``` +cd /srv/projects/ +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// +``` + +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 -d -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 +``` + +--- + +# 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` diff --git a/70_templates/projet_CLAUDE.md b/70_templates/projet_CLAUDE.md new file mode 100644 index 0000000..a5ecacb --- /dev/null +++ b/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`. diff --git a/80_bmad/articulation_avec_lead_tech.md b/80_bmad/articulation_avec_lead_tech.md new file mode 100644 index 0000000..387d675 --- /dev/null +++ b/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`) diff --git a/AGENTS.md b/AGENTS.md deleted file mode 100644 index f425c23..0000000 --- a/AGENTS.md +++ /dev/null @@ -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 : `` -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`). diff --git a/AGENTS.md b/AGENTS.md new file mode 120000 index 0000000..a51caa1 --- /dev/null +++ b/AGENTS.md @@ -0,0 +1 @@ +/Users/maks/AI_RULES/_Assistant_Lead_Tech/CLAUDE.md \ No newline at end of file diff --git a/CLAUDE.md b/CLAUDE.md index 1a69f3c..e7b5721 100644 --- a/CLAUDE.md +++ b/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 diff --git a/generate_project_claude.sh b/generate_project_claude.sh new file mode 100644 index 0000000..556acc7 --- /dev/null +++ b/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 " + echo "generate_project_claude.sh " + 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" \ No newline at end of file diff --git a/sync-ai-instructions.sh b/sync-ai-instructions.sh index f09b90b..31ca5b8 100755 --- a/sync-ai-instructions.sh +++ b/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. -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. +Ce fichier est chargé automatiquement par Claude Code ou 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é."