veza/prompts/01-login.md

ok maintenant il faut dresser une liste exhaustive de toutes les erreurs qui existent dans la page "Connexion" (/login). Il faut tester chaque fonctionnalité une par une avec le MCP Playwright pour simuler un utilisateur réel.

Comptes de test :

┌───────────┬───────────────────┬──────────────┐ │ Rôle │ Email │ Mot de passe │ ├───────────┼───────────────────┼──────────────┤ │ admin │ admin@veza.music │ Admin123! │ ├───────────┼───────────────────┼──────────────┤ │ creator │ artist@veza.music │ Artist123! │ ├───────────┼───────────────────┼──────────────┤ │ user │ user@veza.music │ User123! │ ├───────────┼───────────────────┼──────────────┤ │ moderator │ mod@veza.music │ Mod123! │ ├───────────┼───────────────────┼──────────────┤ │ user_new │ new@veza.music │ New123! │ └───────────┴───────────────────┴──────────────┘ Domaine : veza.fr

Comptes à utiliser pour cette page : (pas de connexion), user

─── INSTRUCTIONS ───

1. AUDIT EXHAUSTIF avec Playwright MCP :

   Pour la page /login ("Connexion"), teste systématiquement :

   a) CHARGEMENT & RENDU

   • La page se charge sans erreur (pas de crash, pas de blank screen)
   • Pas d'erreurs dans la console navigateur (JS errors, failed network requests)
   • Tous les éléments visuels attendus sont présents et visibles
   • Le layout est correct (pas d'overflow, pas d'éléments qui se chevauchent)

   b) FONCTIONNALITÉS SPÉCIFIQUES À CETTE PAGE

• Formulaire email + password fonctionnel
• Validation des champs (email invalide, champs vides)
• Messages d'erreur (mauvais credentials)
• Lien 'Mot de passe oublié' fonctionnel
• Lien 'Inscription' fonctionnel
• Redirection après login réussi
• Protection contre brute-force (rate limiting visible)
• Autocomplete attributes sur les inputs
• Accessibilité: labels, focus order, aria

c) RÉSEAU & API - Tous les appels API réussissent (pas de 4xx/5xx inattendus) - Les données affichées correspondent aux réponses API - Gestion correcte du loading state - Gestion correcte des erreurs réseau

d) SÉCURITÉ - Pas de fuite d'informations sensibles (tokens, emails dans l'URL, clés API) - Les données d'un autre utilisateur ne sont pas accessibles - Les actions protégées nécessitent bien l'authentification - CSRF / XSS : vérifier les inputs utilisateur

e) ACCESSIBILITÉ (a11y) - Tous les éléments interactifs ont un accessible name descriptif (pas juste "Checkbox" ou "Button") - Les labels sont associés aux inputs - Le focus order est logique (Tab navigation) - Les aria-labels/aria-describedby sont présents et pertinents - Contraste suffisant sur les textes

f) INTERNATIONALISATION (i18n) - Pas de mélange de langues (tout FR ou tout EN, pas les deux) - Les traductions sont complètes (pas de clés i18n brutes affichées)

g) RESPONSIVE - Tester en viewport mobile (375px), tablet (768px), desktop (1280px) - Pas d'éléments qui débordent - Navigation mobile fonctionnelle

2. FORMAT DU RAPPORT :

   Produis un rapport structuré exactement comme suit :

   Rapport exhaustif des erreurs — Page Connexion (/login)
   Testé avec le(s) compte(s) : (pas de connexion), user
   Date : [date du test]
   
   ───
   ERREURS CRITIQUES (bloquantes)
   
   BUG #1 — [Titre court]
   - Sévérité: CRITIQUE
   - Section: [section de la page]
   - Repro: [étapes de reproduction]
   - Erreur: [description technique]
   - Source: [fichier:ligne si identifiable]
   - Impact: [impact utilisateur]
   
   ───
   ERREURS HAUTES
   
   ...
   
   ───
   ERREURS MOYENNES
   
   ...
   
   ───
   ERREURS FAIBLES
   
   ...
   
   ───
   RÉSUMÉ
   
   ┌────────────────────────────┬─────────┬──────────────┐
   │         Catégorie          │ Nombre  │ Sévérité max │
   ├────────────────────────────┼─────────┼──────────────┤
   │ ...                        │ ...     │ ...          │
   └────────────────────────────┴─────────┴──────────────┘
   

3. CORRECTION DES BUGS :

   Après avoir dressé la liste, corrige TOUS les problèmes trouvés pour que la page soit entièrement fonctionnelle. Pour chaque fix :

   • Identifie le fichier source exact
   • Applique le correctif
   • Vérifie avec Playwright que le bug est résolu

4. TRANSFORMATION EN TESTS E2E :

   Transforme toute la suite de vérification que tu viens de faire pour la page /login en suite de tests Playwright que tu peux ajouter directement à ceux existants dans veza-e2e/.

   Spécifications des tests :

   • Fichier : veza-e2e/tests/login.spec.ts
   • Framework : Playwright Test (@playwright/test)
   • Pattern : Page Object Model si la page est complexe
   • Chaque bug trouvé ET corrigé = au moins 1 test de non-régression
   • Chaque fonctionnalité testée manuellement = 1 test automatisé
   • Tests organisés par describe() : "Chargement", "Fonctionnalités", "Sécurité", "a11y", "i18n"
   • Les tests doivent être indépendants (setup/teardown propre)
   • Utiliser les test accounts définis ci-dessus pour l'auth dans les fixtures

   Structure attendue :

   import { test, expect } from '@playwright/test';
   
   test.describe('Connexion (/login)', () => {
     test.describe('Chargement & Rendu', () => {
       test('la page se charge sans erreur', async ({ page }) => {
         // ...
       });
     });
   
     test.describe('Fonctionnalités', () => {
       // Un test par fonctionnalité
     });
   
     test.describe('Sécurité', () => {
       // Tests de sécurité
     });
   
     test.describe('Accessibilité', () => {
       // Tests a11y
     });
   
     test.describe('Régression', () => {
       // Un test par bug corrigé
     });
   });
   

   Assure-toi que les nouveaux tests s'intègrent avec la config Playwright existante et ne dupliquent pas des tests déjà présents.