DOC
Accueil/ Projets/ Gestion RH/ CLAUDE.md - Règles de travail de Claude sur ce dépôt (gestion-rh)

CLAUDE.md - Règles de travail de Claude sur ce dépôt (gestion-rh)

Ce fichier est chargé automatiquement à chaque session. Il définit comment Claude doit se comporter sur ce repo. Il complète la mémoire projet dans ~/.claude/projects/.../memory/. À lire et appliquer sans exception.

0. Rituel d'ouverture de session (OBLIGATOIRE)

À chaque nouvelle session, avant toute action d'écriture, Claude doit :

  1. Rappeler les consignes ci-dessous en une phrase courte.
  2. Demander explicitement à l'utilisateur ce qu'il autorise pour cette session :
    • ✅ Écriture sur le dépôt Git (commits / push / création de branches) - OUI / NON
    • ✅ Écriture dans la base de données Supabase (INSERT / UPDATE / DELETE / migrations) - OUI / NON
  3. Attendre la réponse avant toute opération d'écriture Git ou base.

Tant que l'utilisateur n'a pas répondu, considérer que Git = lecture seule et Base = lecture seule.

1. Autorisations par défaut

Action Par défaut Remarque
Lecture de fichiers, du code, de l'historique Git (git log, git diff, git status, git show) ✅ Autorisé Toujours, sans demander
Lecture de la base (SELECT) ✅ Autorisé Si des identifiants/outils sont fournis
Build & tests en local (npm install, npm run build, npm run dev, lint, tests) ✅ Carte blanche Aucune confirmation nécessaire
Écriture de fichiers dans le repo (édition de code, docs) ✅ Autorisé Mais voir §2 (commits)
Commit / push Git ⛔ Interdit sans accord Demandé en début de session (§0)
Écriture base / migrations appliquées ⛔ Interdit sans accord Demandé en début de session (§0)

2. Règle des commits - « prépare, ne commit pas »

Claude ne commit jamais de lui-même. À la place :

  1. Après avoir modifié des fichiers, regrouper les changements par bloc logique (par module / dossier / thème : planning, paie, docs/audits, auth, …).
  2. Rédiger, pour chaque bloc, un message de commit prêt à l'emploi (format Conventional Commits : type(scope): résumé), et le présenter à l'utilisateur.
  3. Laisser l'utilisateur décider de committer ou non. Ne lancer git commit / git push que si l'utilisateur l'a explicitement autorisé pour la session (§0) et demandé pour ce lot précis.

Exemple de rendu attendu en fin de tâche :

Bloc 1 - docs/audits/audit_10_07_26_Seer/
  docs(audit): ajoute l'audit complet de l'application (README, ADR, features, backlog)

Bloc 2 - CLAUDE.md + memory
  chore(governance): met en place les règles de travail et la mémoire projet

Fin de commit : ajouter la ligne Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> uniquement au moment où un commit est réellement effectué (donc pas dans les messages « préparés »).

3. Toujours travailler sur une branche - jamais sur main

  • La branche par défaut est main. Ne jamais committer directement sur main.
  • Avant toute modification destinée à être committée, créer une branche dédiée : git switch -c type/sujet-court (ex. feat/export-comptable, docs/audit-seer).
  • Rappeler ce point à l'utilisateur s'il demande un commit alors que la branche courante est main.

⚠️ Historique actuel : tous les commits sont sur main (« Update App.jsx », « Add files via upload ») - édition via l'interface web GitHub. Un des objectifs de gouvernance est de passer à un flux branche → PR → merge.

4. Contexte projet (rappel court)

  • Stack : React 18 + Vite 5 + Tailwind 3 (front) · Supabase (Postgres + Auth + Storage) · déploiement Netlify. Pas de backend Java ni de serveur applicatif.
  • Tout le code applicatif est dans un seul fichier : gestionrh-github/src/App.jsx (~2800 lignes). Voir l'audit docs/audits/audit_10_07_26_Seer/ pour le détail.
  • Point de vigilance sécurité majeur : les policies RLS Supabase sont totalement permissives (tout utilisateur authentifié peut lire/écrire toutes les tables). Le contrôle des rôles/périmètres est uniquement côté client. Ne pas aggraver ce point ; le documenter/corriger si on y touche.

5. Bonnes pratiques attendues quand on modifie le code

  • Respecter le style existant (composants inline, Tailwind, français dans l'UI).
  • Ne pas introduire de secret en clair ; les clés passent par les variables VITE_SUPABASE_URL / VITE_SUPABASE_ANON_KEY.
  • Toute nouvelle table ou colonne doit être ajoutée dans un fichier SQL de migration (gestionrh-github/supabase-*.sql) - voir la dette « schéma non documenté » dans l'audit.
  • Après une modification de code : npm run build (dans gestionrh-github/) doit passer avant de proposer un commit.

Dernière mise à jour : 2026-07-10 - voir docs/audits/audit_10_07_26_Seer/.