chore: readme reset

This commit is contained in:
Julien Froidefond
2025-08-25 08:40:04 +02:00
parent a5e5a75561
commit e02af4f992
5 changed files with 0 additions and 498 deletions

View File

@@ -1,111 +0,0 @@
# Migration vers UUIDs pour la sécurité
## 🎯 Objectif
Remplacer les user IDs séquentiels (1, 2, 3...) par des UUIDs pour éviter les attaques d'énumération.
## ⚠️ Important
Cette migration doit être effectuée quand l'application n'est pas en production ou pendant une maintenance.
## 📋 Étapes à suivre
### Scenario A : Nouvelle installation (recommandé)
```bash
# 1. Supprimer l'ancienne DB si elle existe
dropdb peakskills
# 2. Créer une nouvelle DB avec le nouveau schema UUID
createdb peakskills
psql -h localhost -U peakskills_user -d peakskills -f scripts/init.sql
# 3. Synchroniser les données skills et teams
pnpm run sync-skills
pnpm run sync-teams
# 4. Démarrer l'app
npm run dev
```
### Scenario B : Migration base existante
**⚠️ Script de migration supprimé**
Le script `migrate-to-uuid.sql` a été supprimé. Pour migrer une base existante :
1. **Sauvegarde** tes données importantes
2. **Supprime** l'ancienne base : `dropdb peakskills`
3. **Recrée** avec le nouveau schéma : `createdb peakskills`
4. **Utilise** le Scenario A ci-dessus
### 4. Nettoyer les anciennes sessions
- Tous les utilisateurs devront se reconnecter (car les cookies utilisent maintenant des UUIDs)
- C'est normal et nécessaire pour la sécurité
## 🔒 Sécurité apportée
**Avant :**
- Cookie: `peakSkills_userId=2`
- Facilement hackable: essayer 1, 3, 4, 5...
**Après :**
- Cookie: `peakSkills_userId=a1b2c3d4-e5f6-7890-abcd-ef1234567890`
- Impossible à deviner: UUID v4 avec 2^122 possibilités
## 🚀 Tests à effectuer
1. **Login nouveau utilisateur**
- Créer un compte → doit générer un UUID
- Vérifier le cookie dans le navigateur
2. **Utilisateur existant**
- Se reconnecter → doit utiliser l'UUID existant
- Vérifier que les données sont préservées
3. **Actions d'évaluation**
- Modifier une skill → doit fonctionner avec UUID
- Vérifier que les données sont sauvées
## 📊 Migration status
-**Code application complètement adapté aux UUIDs**
- ✅ Nouvelles méthodes `*Uuid()` dans EvaluationService
- ✅ Toutes les APIs modifiées (`/api/auth`, `/api/evaluations`, `/api/evaluations/skills`)
- ✅ Functions SSR adaptées (server-auth.ts)
- ✅ Middleware mis à jour
- ✅ Types AuthService corrigés
-**À faire : Exécuter la migration DB**
-**À faire : Tester en développement**
-**À faire : Nettoyer le code legacy une fois validé**
## 🔧 Fichiers modifiés
### Services
- `services/evaluation-service.ts` → Méthodes `*Uuid()` ajoutées
- `lib/server-auth.ts``getUserUuidFromCookie()` et adaptations
- `lib/auth-utils.ts` → Types de retour UUID
### APIs
- `app/api/auth/route.ts` → Cookies UUID
- `app/api/evaluations/route.ts``getUserByUuid()`
- `app/api/evaluations/skills/route.ts` → Toutes méthodes `*Uuid()`
### Infrastructure
- `middleware.ts` → Variables UUID
- `scripts/init.sql` → Schema DB initial avec UUIDs
## 🧹 Nettoyage futur
Une fois la migration validée, supprimer :
- Méthodes `upsertUser()` et `getUserById()` legacy
- Colonnes `id` et `user_id` dans les tables (garder seulement UUIDs)

105
README.md
View File

@@ -1,105 +0,0 @@
# Design System Template
Template Next.js avec un design system complet basé sur shadcn/ui, Tailwind CSS et Radix UI.
## 🚀 Usage rapide
1. **Copier le template**
```bash
cp -r design-system-template my-new-app
cd my-new-app
```
2. **Installer les dépendances**
```bash
pnpm install
# ou npm install / yarn install
```
3. **Lancer le dev server**
```bash
pnpm dev
```
4. **Personnaliser**
- Changer le nom dans `package.json`
- Modifier `app/layout.tsx` (title, description)
- Customiser `app/page.tsx`
## 📦 Inclus
### Composants UI (shadcn/ui)
- **Tous les composants** : Button, Card, Dialog, Form, Input, Select, etc.
- **Layout** : ThemeProvider, ThemeToggle
- **Hooks** : use-mobile, use-toast
- **Utils** : clsx, tailwind-merge
### Styling
- **Tailwind CSS v4** avec PostCSS
- **Variables CSS** pour theming
- **Dark/Light mode** automatique
- **Animations custom** (glitch, holo, matrix)
- **Scrollbar custom**
### Config
- **TypeScript** setup complet
- **Path aliases** (@/components, @/lib, etc.)
- **ESLint/Prettier** ready
- **Next.js 15** avec App Router
## 🎨 Customisation
### Couleurs
Modifier les variables CSS dans `app/globals.css`:
```css
:root {
--primary: oklch(0.205 0 0);
--background: oklch(0.98 0.005 240);
/* ... */
}
```
### Composants
Tous les composants sont dans `/components/ui/` et modifiables.
### Ajout de nouveaux composants
```bash
npx shadcn@latest add [component-name]
```
## 🛠 Structure
```
├── app/
│ ├── globals.css # Styles + variables CSS
│ ├── layout.tsx # Layout racine
│ └── page.tsx # Page d'accueil
├── components/
│ ├── ui/ # Tous les composants shadcn
│ └── layout/ # ThemeProvider, etc.
├── lib/
│ └── utils.ts # Utilities (cn, etc.)
├── hooks/ # Hooks réutilisables
└── package.json # Dépendances complètes
```
## 📚 Documentation
- [shadcn/ui](https://ui.shadcn.com/)
- [Tailwind CSS](https://tailwindcss.com/)
- [Radix UI](https://www.radix-ui.com/)
- [Next.js](https://nextjs.org/)
---
**Prêt à développer !** 🎉

54
TODO.md
View File

@@ -1,54 +0,0 @@
# TODO List
## Completed ✅
### 1. Analyse de la structure existante
- [x] Analyser la structure existante des pages admin et des APIs
- [x] Identifier les composants existants et leurs responsabilités
### 2. Création de la page de gestion
- [x] Créer une nouvelle page admin avec onglets pour Skills et Teams
- [x] Implémenter les composants de gestion des Skills (CRUD)
- [x] Implémenter les composants de gestion des Teams (CRUD)
- [x] Créer/adapter les APIs nécessaires pour les opérations CRUD
### 3. Vue arborescente des Skills
- [x] Refactorer Skills Management avec une vue arborescente par catégorie
- [x] Implémenter le système expand/collapse pour les catégories
- [x] Adapter la recherche pour fonctionner avec la vue arborescente
- [x] Ajouter l'icône du skill au début de chaque ligne
### 4. Factorisation des composants
- [x] Créer des composants réutilisables pour la vue arborescente dans Skills et Teams Management
- [x] Factoriser le code entre les deux pages de gestion
- [x] Créer des composants génériques : TreeViewContainer, TreeCategoryHeader, TreeItemRow, TreeSearchControls, TeamMetrics
### 5. Suppression de direction
- [x] Ajouter la possibilité de supprimer une direction entière avec toutes ses équipes
- [x] Implémenter la vérification de sécurité (impossible si des équipes ont des membres)
- [x] Ajouter le bouton de suppression dans TreeCategoryHeader pour les directions
### 6. Réorganisation de la structure
- [x] Réorganiser tous les composants admin dans des dossiers logiques
- [x] Créer une structure claire : overview/, layout/, management/, team-detail/, utils/
- [x] Mettre à jour tous les imports et exports
- [x] Créer des fichiers d'index pour chaque dossier
- [x] Documenter la nouvelle structure avec un README
## Pending 🔄
### Aucune tâche en attente
## Next Steps 🚀
La structure des composants admin est maintenant parfaitement organisée et documentée. Tous les composants sont factorisés et réutilisables. La fonctionnalité de suppression de direction est implémentée et sécurisée.
---
**Note** : Cette TODO list a été complètement réalisée ! 🎉

View File

@@ -1,115 +0,0 @@
# API Clients Architecture
Cette architecture respecte les principes SOLID en séparant les responsabilités par domaine métier et en évitant le code mort.
## Structure
```
clients/
├── base/
│ └── http-client.ts # Classe de base avec logique HTTP commune
├── domains/
│ ├── evaluation-client.ts # Client pour les évaluations (lecture + modification)
│ ├── teams-client.ts # Client pour la gestion des équipes (lecture + CRUD)
│ ├── skills-client.ts # Client pour les compétences (lecture + création)
│ ├── auth-client.ts # Client pour l'authentification (login, logout, getCurrentUser)
│ └── admin-client.ts # Client pour la gestion admin (skills, teams, users)
├── index.ts # Exports publics de tous les clients
├── client.ts # Wrapper client-side sécurisé
└── README.md # Ce fichier
```
## Services associés
- **`services/auth-service.ts`** - Service d'authentification côté client (renommé depuis auth-utils)
- **`services/evaluation-service.ts`** - Service d'évaluation côté serveur
- **`services/teams-service.ts`** - Service des équipes côté serveur
- **`services/skills-service.ts`** - Service des compétences côté serveur
## Principes
- **Single Responsibility** : Chaque client gère un seul domaine métier
- **Open/Closed** : Facile d'étendre sans modifier le code existant
- **Liskov Substitution** : Tous les clients héritent de BaseHttpClient
- **Interface Segregation** : Chaque client expose uniquement ses méthodes
- **Dependency Inversion** : Dépend de l'abstraction BaseHttpClient
## Clients par responsabilité
### EvaluationClient
- **`loadUserEvaluation()`** - Chargement d'une évaluation utilisateur
- **`saveUserEvaluation()`** - Sauvegarde d'une évaluation
- **`updateSkillLevel()`** - Mise à jour du niveau d'une skill
- **`updateSkillMentorStatus()`** - Mise à jour du statut mentor
- **`updateSkillLearningStatus()`** - Mise à jour du statut d'apprentissage
- **`addSkillToEvaluation()`** - Ajout d'une skill à l'évaluation
- **`removeSkillFromEvaluation()`** - Suppression d'une skill
### SkillsClient
- **`loadSkillCategories()`** - Chargement des catégories de skills
- **`createSkill()`** - Création d'une nouvelle skill
### TeamsClient
- **`loadTeams()`** - Chargement des équipes
- **`createTeam()`** - Création d'une équipe
- **`updateTeam()`** - Mise à jour d'une équipe
- **`deleteTeam()`** - Suppression d'une équipe
### AuthClient
- **`login()`** - Authentification d'un utilisateur
- **`getCurrentUser()`** - Récupération de l'utilisateur actuel
- **`logout()`** - Déconnexion d'un utilisateur
### AdminClient
- **`getSkills()`** - Récupération de toutes les skills
- **`createSkill()`** - Création d'une nouvelle skill
- **`updateSkill()`** - Mise à jour d'une skill
- **`deleteSkill()`** - Suppression d'une skill
- **`getTeams()`** - Récupération de toutes les équipes
- **`createTeam()`** - Création d'une nouvelle équipe
- **`updateTeam()`** - Mise à jour d'une équipe
- **`deleteTeam()`** - Suppression d'une équipe
- **`deleteDirection()`** - Suppression d'une direction
- **`getTeamMembers()`** - Récupération des membres d'une équipe
- **`removeTeamMember()`** - Suppression d'un membre d'équipe
- **`deleteUser()`** - Suppression d'un utilisateur
## Utilisation
### Import direct
```typescript
import {
evaluationClient,
teamsClient,
skillsClient,
authClient,
adminClient,
} from "@/clients";
```
### Import client-side sécurisé
```typescript
import {
evaluationClient,
teamsClient,
skillsClient,
authClient,
adminClient,
} from "@/services/client";
```
## Avantages
- **Code mort supprimé** : Plus de méthodes dupliquées
- **Architecture simple** : Chaque client gère son domaine complet
- **Performance** : Seules les méthodes nécessaires sont importées
- **Maintenabilité** : Architecture claire et logique
- **Testabilité** : Chaque client peut être testé indépendamment
- **Séparation claire** : Client HTTP vs services métier

View File

@@ -1,113 +0,0 @@
# Server-Side Utilities Architecture
Cette architecture respecte les principes SOLID en séparant clairement les responsabilités côté serveur et en évitant le code mort.
## Structure
```
lib/
├── evaluation-utils.ts # Utilitaires pour les évaluations
├── evaluation-actions.ts # Actions d'évaluation
├── score-utils.ts # Utilitaires pour les scores
├── skill-file-loader.ts # Chargement des fichiers de skills
├── types.ts # Types TypeScript généraux
├── admin-types.ts # Types pour l'administration
├── utils.ts # Utilitaires généraux
├── category-icons.ts # Icônes des catégories
├── tech-colors.ts # Couleurs des technologies
├── pattern-colors.ts # Couleurs des patterns
└── README.md # Ce fichier
```
## Responsabilités
### evaluation-utils.ts
- **Utilitaires** pour les évaluations côté client
- **Génération de données** pour les graphiques radar
### evaluation-actions.ts
- **Actions d'évaluation** côté serveur
- **Gestion des profils** utilisateur
### score-utils.ts
- **Calcul des scores** et niveaux de compétences
- **Logique métier** pour les évaluations
### skill-file-loader.ts
- **Chargement des fichiers** de compétences depuis le système de fichiers
- **Parsing des données** JSON
### types.ts
- **Types TypeScript** généraux de l'application
- **Interfaces** pour les entités principales
### admin-types.ts
- **Types pour l'administration** et les statistiques
- **Interfaces** pour TeamMember, TeamStats, DirectionStats
## Services d'authentification
### AuthClient (client-side uniquement)
- **`login()`** - Authentification côté client
- **`getCurrentUser()`** - Récupération utilisateur côté client
- **`logout()`** - Déconnexion côté client
### AuthService (server-side uniquement)
- **`getUserUuidFromCookie()`** - Récupère l'UUID depuis le cookie côté serveur
- **`isUserAuthenticated()`** - Vérifie l'authentification côté serveur
## Séparation client/serveur
- **`clients/domains/auth-client.ts`** - Côté client uniquement (React components, hooks)
- **`services/auth-service.ts`** - Côté serveur uniquement (API routes, pages)
- **Pas de duplication** entre les deux services
## Utilisation
### Import direct des services
```typescript
import { AuthService } from "@/services";
import { SkillsService, TeamsService } from "@/services";
import { evaluationService } from "@/services/evaluation-service";
```
### Utilisation dans les pages
```typescript
export default async function HomePage() {
const userUuid = await AuthService.getUserUuidFromCookie();
if (!userUuid) {
redirect("/login");
}
const [userEvaluation, skillCategories, teams] = await Promise.all([
evaluationService.getServerUserEvaluation(userUuid!),
SkillsService.getSkillCategories(),
TeamsService.getTeams(),
]);
}
```
## Avantages
- **Séparation claire** : Chaque fichier a une seule responsabilité
- **Pas de code mort** : Utilisation directe des services existants
- **Maintenabilité** : Code organisé et facile à comprendre
- **Réutilisabilité** : Fonctions modulaires et indépendantes
- **Testabilité** : Chaque module peut être testé séparément
- **Évolutivité** : Facile d'ajouter de nouvelles fonctionnalités
- **Architecture logique** : L'authentification est dans les services d'auth
- **Séparation client/serveur** : Pas de confusion entre les deux environnements
- **Noms cohérents** : AuthService pour le serveur, AuthClient pour le client
- **Imports directs** : Plus de wrapper inutile, appel direct des services
- **Simplicité** : Architecture claire et directe