# Covalba Refonte - Regles d'equipe ## Stack - Vite + React 18 + TypeScript - Tailwind CSS + shadcn/ui - GSAP pour les animations - React Router DOM ## Workflow equipe (3 devs) ### Branches - `main` : branche de production, jamais de push direct - Chaque dev travaille sur sa propre branche (`feat/xxx`, `fix/xxx`) - Merge uniquement via Pull Request sur GitHub ### Anti-conflits - **1 composant = 1 personne** : ne jamais modifier un fichier qu'un autre dev a en cours (PR ouverte) - **Avant de commencer** : lancer `/check-conflicts` pour voir les fichiers "pris" par les autres - **Fichiers partages** (a ne toucher qu'apres coordination) : - `src/pages/Index.tsx` (assemblage de la home) - `src/components/Navbar.tsx`, `Footer.tsx` - `src/index.css`, `tailwind.config.ts` - `package.json` ### Conventions - Composants en PascalCase, un composant par fichier - Styles via Tailwind (pas de CSS custom sauf exception) - Commits en francais ou anglais, messages descriptifs ## Contexte projet (à lire en début de session) Le dossier `docs/contexte/` contient le contexte métier, stratégique et client de la refonte : activité Covalba, produits (Cool Roof), cibles, objectifs, stratégie, transcripts des échanges client. **À faire à chaque nouvelle session** : parcourir `docs/contexte/README.md` puis les fichiers thématiques pertinents pour la tâche en cours. Mettre à jour ces docs quand le client donne de nouvelles infos. ## Environnement Paf-Studio Code Tu tournes dans **Paf-Studio Code**, un environnement de développement partagé sur VPS (Hostinger, France). 4 développeurs partagent ce VPS : **Tom Assous**, **Pierre Bost**, **Nicolas Pommereuil**, **Clara Girard** (surnommée *Graziella* pour son bagout et l'ambiance qu'elle met). Chaque branche a son propre worktree isolé — pas de conflit entre développeurs. Les credentials Claude Code sont partagés entre les membres de l'équipe. - **Développeur actuel** : Tom Assous (tom) - **Projet** : covalba-wp - **Branche** : `tom/passage-wp` - **Preview** : https://covalba-wp-tom-passage-wp.paf-studio.dev - **Port dev server** : 3083 ### Règles Git & PR - Tu travailles sur la branche `tom/passage-wp`. Ne touche **jamais** à `main` directement. - Commits en anglais, format conventionnel : `feat:`, `fix:`, `chore:`, `docs:` - Quand le travail est prêt : `git push` puis crée une PR vers `main`. - Ne force push pas (`--force`) sauf si explicitement demandé. - Le **plugin GitHub Claude Code** est installé : les PR sont automatiquement reviewées par Claude. - Toujours inclure une description claire dans la PR (résumé + test plan). ### Preview L'URL de preview pour cette branche est : **https://covalba-wp-tom-passage-wp.paf-studio.dev** Lance le dev server sur le port **3083** et le host **0.0.0.0** pour que la preview fonctionne. Exemple : `next dev -p 3083 -H 0.0.0.0` ou `vite --port 3083 --host` Le launcher écrit aussi un bloc géré dans `.env.local` avec `PAF_STUDIO_PREVIEW_URL`, `PAF_STUDIO_PREVIEW_HOST`, `PAF_STUDIO_PREVIEW_PORT`, et, si absents, `HOST`/`PORT`/`VITE_HOST`/`VITE_PORT`. Le nettoyage mémoire peut arrêter un dev server inactif sans supprimer la preview. Si l'URL ne répond plus, relance depuis le worktree avec `preview restart`, ou lance manuellement le dev server sur le port indiqué dans `.env.local`. **IMPORTANT** : le hostname `covalba-wp-tom-passage-wp.paf-studio.dev` doit être autorisé, mais ne hard-code jamais ce host ou ce port dans une config versionnée. Si la config du framework doit changer, fais une modification générique qui lit les variables de `.env.local` et reste valable pour toutes les branches. Le point commun : **host 0.0.0.0** (pas localhost/127.0.0.1) + **port depuis `.env.local`** + **hostname depuis `PAF_STUDIO_PREVIEW_HOST`**. ### Images partagees Quand l'utilisateur colle un chemin qui commence par `~/images/` (ex: `~/images/tom/clipboard-20260414-143022.png`), c'est une image qu'il vient de partager avec toi via son clipboard ou drag & drop. **Analyse-la automatiquement** en utilisant Read — pas besoin de demander confirmation. Ces images sont des screenshots, mockups, photos de bugs, references visuelles. ### Passation entre agents Pour passer le relais a la prochaine personne (humaine ou IA) qui va bosser sur cette branche, tape `/handoff`. Claude va creer ou completer `HANDOFF.md` a la racine du projet en mode append-in-place (pas d'archivage) et commit le fichier. **Trigger sans slash** : si l'utilisateur ecrit juste le mot `handoff` (seul, sans autre contexte), invoque la slash command `/handoff` — c'est le comportement attendu, pas besoin de demander confirmation. Quand un nouvel agent prend le relais sur une branche, il doit d'abord lire `HANDOFF.md` s'il existe (apres `git pull`). ### Permissions & sécurité Tu tournes avec `--dangerously-skip-permissions`. Le VPS est isolé et jetable. Git est la source de vérité. Tu peux exécuter des commandes librement. Ne stocke aucun secret en dur dans le code. Utilise des variables d'environnement.