docs: initialize CLAUDE.md for AuditShield
Some checks failed
Deploy / deploy (push) Failing after 9s

This commit is contained in:
2026-03-21 17:06:45 +01:00
parent 080952129b
commit 1ff3c15ea9

View File

@@ -1,60 +1,84 @@
# [NOM DU PROJET]
# AuditShield
## Projet
[Une phrase : ce que fait l'app, pour qui, pourquoi.]
Outil d'audit infrastructure et sécurité pour clients MSP. Permet de lancer des scans réseau, vulnérabilités et pentest automatisés, avec suivi des actions et génération de rapports exportables (PDF + dashboard web) compréhensibles pour des clients non-techniques.
## Stack
- Runtime : Node 20 / Python 3.11 / ...
- Framework : ...
- Base de données : MariaDB / PostgreSQL / SQLite
- Déploiement : Docker → Synology NAS (rigolet.tech)
- Frontend : Next.js 14 + Tailwind + shadcn/ui
- Backend : FastAPI (Python 3.11)
- Base de données : PostgreSQL
- ORM : SQLAlchemy + Alembic (migrations)
- Auth : JWT + bcrypt
- PDF : WeasyPrint
- Déploiement : Docker → Synology NAS ou VPS (rigolet.tech)
## Structure
```
src/
components/ # Exemple de composant : src/components/UserCard.tsx
api/ # Exemple de route : src/api/users/route.ts
stores/ # State management
frontend/
app/ # Next.js App Router
components/ # Composants réutilisables
lib/ # Utilitaires, API client
backend/
api/ # Routes FastAPI
scanners/ # Orchestration Nmap, OpenVAS, Metasploit, AD
models/ # Modèles SQLAlchemy
reports/ # Génération PDF
docker/
docker-compose.yml
.gitea/
workflows/
deploy.yml
docker-compose.prod.yml
```
## Commandes
```bash
npm install # Installer les dépendances
npm run dev # Lancer en développement
npm run build # Build production
npm test # Lancer UN test ciblé, pas toute la suite
npm run typecheck # IMPORTANT : lancer après chaque série de modifications
# Frontend
cd frontend && npm install && npm run dev
# Backend
cd backend && pip install -r requirements.txt && uvicorn main:app --reload
# Docker complet
docker compose -f docker/docker-compose.yml up -d
# Migrations BDD
cd backend && alembic upgrade head
# Tests
pytest backend/tests/
```
## Modèle de données
- Client : id, nom, contact, créé_le
- Audit : id, client_id, statut, date_début, date_fin, score_global
- Cible : id, audit_id, type (IP/domaine/subnet), valeur
- Vulnérabilité : id, audit_id, criticité (critique/important/modéré/faible), titre, description, recommandation
- Action : id, vulnérabilité_id, statut (ouvert/en_cours/résolu), assigné_à, note
## Sécurité IMPORTANT
- Jamais de credentials dans le code, toujours via .env
- Les scans ne se lancent QUE sur des cibles validées par l'utilisateur
- Logs de toutes les actions de scan en BDD
- Rate limiting sur toutes les routes API
## Code style
- ES modules (import/export), jamais CommonJS (require)
- Functional components + hooks uniquement, jamais de class components
- TypeScript strict activé
- Destructure les imports quand possible
- IMPORTANT : ne jamais considérer une tâche terminée sans typecheck qui passe
- ES modules (import/export), jamais CommonJS
- Functional components + hooks uniquement
- TypeScript strict sur le frontend
- Type hints Python obligatoires sur le backend
- IMPORTANT : typecheck après chaque série de modifications
## Git
- Branches : main (prod) → dev (dev)
- Branches : main (prod) → dev → feature/xxx
- Commits : feat: / fix: / docs: / refactor: / chore:
- IMPORTANT : toujours créer une nouvelle branche pour chaque tâche
- IMPORTANT : toujours créer une branche pour chaque tâche
- IMPORTANT : ne jamais pusher directement sur main
## Déploiement
Pipeline automatique via Gitea Actions.
Chaque push sur develop déclenche un déploiement sur le NAS.
Voir @.gitea/workflows/deploy.yml pour le détail du pipeline.
## Références
- Vue d'ensemble du projet : @README.md
- Variables d'environnement : @.env.example
Gitea Actions → Docker → NAS ou VPS selon le client
Voir @docker/docker-compose.yml et @.gitea/workflows/deploy.yml
## Ce que Claude doit savoir sur CE projet
- [Ajoute ici les erreurs que Claude répète spécifiquement sur ce projet]
- [Ex : "ne pas utiliser axios, on utilise fetch natif"]
- [Ex : "la BDD utilise snake_case, le code TypeScript utilise camelCase"]
- [Ex : "les tests sont dans __tests__/, pas dans src/"]
- Les scans sont des opérations longues → utiliser des jobs asynchrones (Celery ou BackgroundTasks FastAPI)
- Le rapport PDF doit être compréhensible par un dirigeant non-technique
- Toujours traduire les CVE en langage clair dans les rapports
- La BDD utilise snake_case, le frontend TypeScript utilise camelCase
- Les criticités : critique (CVSS 9-10), important (7-8.9), modéré (4-6.9), faible (0-3.9)