generated from vincent/template-projet
docs: initialize CLAUDE.md for AuditShield
Some checks failed
Deploy / deploy (push) Failing after 9s
Some checks failed
Deploy / deploy (push) Failing after 9s
This commit is contained in:
96
CLAUDE.md
96
CLAUDE.md
@@ -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)
|
||||
Reference in New Issue
Block a user