Initial commit

This commit is contained in:
Zhongwei Li
2025-11-30 08:26:45 +08:00
commit f79d7f0f9e
16 changed files with 1710 additions and 0 deletions

View File

@@ -0,0 +1,100 @@
---
name: optimizing-bundle-size
description: Analyzes and reduces JavaScript bundle size for fast loading. Use when adding dependencies, before releases, or if bundle exceeds 200KB
allowed-tools: Read, Grep, Glob, Bash
---
# Optimiseur de Taille de Bundle
Optimise taille des bundles JavaScript pour chargement rapide et performance mobile.
## Quand utiliser
- Ajout de nouvelles dépendances
- Bundle > 200 KB (gzipped)
- Avant chaque release
- Optimisation mobile (3G/4G)
- Audit de performance
## Cibles de taille
- Bundle initial : < 100 KB (gzipped)
- Bundle total : < 500 KB
- Modules individuels : < 50 KB
## Stratégies essentielles
### Tree Shaking
- Imports nommés (pas `import *`)
- Imports spécifiques de modules externes
- Named exports (pas d'export default d'objets)
### Code Splitting
- Import dynamique avec `import()`
- Lazy loading de composants lourds
- Vérifier lazy loading des modes de jeu
### Minification & Compression
- Minifier actif en production
- Gzip/Brotli sur serveur (-70% taille)
- Source maps pour debug
### Éliminer duplications
- Détecter code similaire entre modules
- Extraire logique partagée
- Cherche jeux arcade avec patterns similaires
## Outils d'analyse
**Scripts npm :**
- `npm run analyze:dependencies` - Dépendances non utilisées
- `npm run dead-code` - Exports/fonctions jamais appelés
- `npm run analyze:globals` - Variables globales
- `npm run analyze:assets` - Assets volumineux
**Mesurer impact :**
- Taille gzippée avant/après
- Lighthouse CI (Performance > 90)
- Tests mobile 3G/4G
## Workflow
1. **Analyser :** Lancer scripts npm d'analyse
2. **Identifier :** Code mort, modules lourds, imports sous-optimaux
3. **Optimiser :** Une stratégie à la fois (lazy loading > tree shaking > minification)
4. **Mesurer :** Taille gzippée, temps chargement, Lighthouse
5. **Valider :** Tests passent, mobile performant
## Checklist
- [ ] Scripts d'analyse exécutés
- [ ] Imports optimisés (spécifiques, pas wildcard)
- [ ] Code mort retiré
- [ ] Lazy loading vérifié
- [ ] Minification/Gzip activés
- [ ] Lighthouse > 90 (Performance)
- [ ] Bundle < 100 KB (gzipped)
## En cas de doute
**Règles absolues :**
1. Toujours mesurer avant/après
2. Une optimisation à la fois
3. Priorité : lazy loading > tree shaking > minification
4. Mobile 3G/4G = référence
5. Tests passent après chaque changement
**Workflow minimal :**
```bash
npm run analyze:dependencies # Identifier code mort
npm run dead-code # Vérifier exports non utilisés
npm run analyze:assets # Vérifier assets volumineux
```

View File

@@ -0,0 +1,117 @@
---
name: generating-jsdoc
description: Automatically generates JSDoc documentation for ES6 modules with @param, @returns, @throws and examples. Use when adding functions, refactoring, or improving documentation
allowed-tools: Read, Write, Grep, Glob, Bash
---
# Générateur JSDoc
Génère documentation JSDoc pour modules ES6 (functions, classes, exports).
## Table des matières
- [Quand utiliser](#quand-utiliser)
- [Scripts npm](#scripts-npm)
- [Format JSDoc essentiel](#format-jsdoc-essentiel)
- [Patterns projet](#patterns-projet)
- [Workflow](#workflow)
- [Checklist](#checklist)
- [En cas de doute](#en-cas-de-doute)
## Quand utiliser
- Ajout fonctions ou classes
- Refactoring code
- Amélioration documentation
- Avant release
- Onboarding développeurs
## Scripts npm
- `npm run analyze:jsdoc` - Couverture JSDoc
- `npm run improve:jsdoc` - Améliorer documentation
- JSDoc HTML generation (si configuré)
## Format JSDoc essentiel
**Fonction :**
```javascript
/**
* Description brève (impératif : "Calcule", pas "Cette fonction")
*
* @param {Type} paramName - Description
* @param {Type} paramName2 - Description
* @returns {Type} Description retour
* @throws {ErrorType} Conditions erreur
* @example
* functionName(value1, value2); // → result
*/
```
**Classe :**
```javascript
/**
* Description classe
* @class
* @extends ParentClass
*/
export class ClassName {}
```
**Types :** `string`, `number`, `boolean`, `Array<Type>`, `{key: Type}`, `Promise<Type>`, `Type1|Type2`
## Patterns projet
**Priorités :**
- Haute : API publiques, fonctions complexes, classes
- Moyenne : Méthodes, callbacks, utilitaires
- Basse : Fonctions privées simples, getters évidents
**Tags spéciaux :**
- `@typedef` - Définir types complexes
- `@fires` - Événements émis
- `@deprecated` - Code obsolète
- `@see {@link Name}` - Références croisées
Examine code existant (modes, utils, core) pour patterns.
## Workflow
1. **Analyser :** `npm run analyze:jsdoc` → Identifier gaps
2. **Documenter :** Description + @param + @returns + @example
3. **Enrichir :** Cas limites, erreurs (@throws)
4. **Vérifier :** Code cohérent, types précis, exemples du domaine
## Checklist
- [ ] Description brève et impérative
- [ ] @param pour chaque paramètre avec type précis
- [ ] @returns avec type et description
- [ ] @throws si erreurs possibles
- [ ] @example (au moins 1 cas réaliste)
- [ ] @typedef pour types complexes
- [ ] Types précis (pas {Object} générique)
- [ ] Exemples avec valeurs du domaine
- [ ] Cas limites documentés (null, undefined)
- [ ] Cohérent avec reste projet
## En cas de doute
**Règles absolues :**
1. Description impérative (imperative mood)
2. Types explicites (jamais {\*} sauf dernier recours)
3. Exemples du domaine (réalistes)
4. @example obligatoire pour API publiques
5. Maintenir à jour avec refactoring
**Références :**
- Code existant patterns (modes, utils)
- `npm run analyze:jsdoc` - Vérifier couverture
- JSDoc.app - Syntaxe spécifique
- Examiner fichiers bien documentés du projet

View File

@@ -0,0 +1,118 @@
---
name: managing-animations
description: Creates and manages CSS and JavaScript animations (keyframes, transitions, sprite animations, canvas animations). Use when adding visual animations or user feedback
allowed-tools: Read, Write, Grep, Glob, Bash
---
# Système d'Animation
Crée animations fluides (CSS, JS, sprites, particules) pour feedback utilisateur et jeux.
## Table des matières
- [Quand utiliser](#quand-utiliser)
- [Types d'animations](#types-danimations)
- [Patterns essentiels](#patterns-essentiels)
- [Optimisations](#optimisations)
- [Workflow](#workflow)
- [Checklist](#checklist)
- [En cas de doute](#en-cas-de-doute)
## Quand utiliser
- Feedback visuel (boutons, transitions)
- Animations sprites (jeux arcade)
- Transitions slides
- Effets visuels (particules, explosions)
- Micro-interactions UI
- Animations canvas jeux
## Types d'animations
**CSS Transitions :**
- Hover, focus, state changes
- Propriétés : transform, opacity (GPU), color, box-shadow
- Easing : ease-out (UI), ease-in-out (transitions), linear (rotations)
**CSS Keyframes :**
- Pulse, shake, bounce, rotate, fade
- Animations répétables sans événement
- Trouve keyframes existantes dans CSS
**JavaScript (requestAnimationFrame) :**
- Animations complexes programmées
- `performance.now()` → progress (0-1) → easing → interpolate
- Batch multiple animations dans un RAF
**Sprite Animations (Canvas) :**
- Frame-based (FPS adaptatif)
- Sprite sheets, frame index qui boucle
- Directional sprites, callbacks (onLoop, onComplete)
**Particle Systems :**
- Effets visuels (explosions, étincelles)
- Particle class (position, velocity, life, color)
- Max 100 simultanées, object pooling, cleanup
Examine animationen existantes dans le code.
## Patterns essentiels
- **Feedback :** Correct (vert, pulse), Wrong (rouge, shake), Coins (trajectoires)
- **Transitions slides :** TranslateX, fade, cleanup, historique
- **Accessibility :** Respecter `prefers-reduced-motion`, fallback simple
- **Easing :** Linear, Quad, Cubic, Elastic, Bounce (trouve dans utils)
## Optimisations
**GPU Acceleration :**
- Utiliser transform + opacity (pas left/top)
- will-change: transform, opacity (retirer après)
**Performance :**
- Batch RAF multiple animations
- Particules < 100 simultanées, cleanup chaque frame
- 60 FPS obligatoire (profile DevTools)
## Workflow
1. **Choisir type :** CSS transition (simple), CSS keyframes (feedback), RAF (complexe), Sprite (jeu), Particles (effets)
2. **Examiner existant :** Patterns, conventions, optimisations
3. **Implémenter :** Suivre mêmes patterns, cleanup, 60 FPS
4. **Tester :** Fluide, prefers-reduced-motion OK, mobile OK
## Checklist
- [ ] CSS pour animations simples
- [ ] RAF pour animations complexes
- [ ] transform + opacity (GPU)
- [ ] prefers-reduced-motion respecté
- [ ] Particules < 100, cleanup
- [ ] Easing appropriée
- [ ] 60 FPS maintenu
- [ ] Testé mobile
## En cas de doute
**Règles absolues :**
1. Examiner animations similaires dans code
2. Prioriser CSS (simplicité + perf)
3. JavaScript uniquement si nécessaire
4. Profile DevTools (60 FPS OBLIGATOIRE)
5. Toujours respecter prefers-reduced-motion
**Références :**
- CSS keyframes/transitions existantes
- Feedback animations (coins, scores)
- Slides transitions
- Jeux arcade (sprites, particules)
- Easing functions utils

View File

@@ -0,0 +1,121 @@
---
name: optimizing-assets
description: Optimizes images, sprites, sounds and media to reduce bandwidth and improve loading. Use before adding large assets or during mobile optimization
allowed-tools: Read, Grep, Glob, Bash
---
# Asset Optimizer
Optimise images, sprites, sons, vidéos pour chargement rapide et performance mobile.
## Table des matières
- [Quand utiliser](#quand-utiliser)
- [Objectifs de taille](#objectifs-de-taille)
- [Principes essentiels](#principes-essentiels)
- [Workflow](#workflow)
- [Checklist](#checklist)
- [En cas de doute](#en-cas-de-doute)
## Quand utiliser
- Avant ajouter images/sprites
- Assets > 100 KB
- Optimisation mobile (3G/4G)
- Audit Lighthouse Performance
- PWA bande passante
- Images non responsive
## Objectifs de taille
- Images PNG: < 50 KB, JPG: < 30 KB
- Audio: < 50 KB (96-128 kbps)
- Sprites: < 100 KB total
- Total first load: < 2 MB
- Lighthouse Performance: > 90
## Principes essentiels
**Images :**
- Compresse (TinyPNG, Squoosh): -30-50% PNG, -20-40% JPG
- WebP + fallback PNG/JPG (-25% vs JPG)
- Responsive (1x, 2x, 3x via srcset)
- Lazy loading (loading="lazy" ou Intersection Observer)
**Audio :**
- Bitrate: 96 kbps effets, 128 kbps musique
- Formats: MP3 + OGG/WebM (compatibilité)
- Preload sons critiques
**Sprites :**
- Combiner en sheets (moins requêtes HTTP)
- SVG icônes (scalable, modifiable CSS)
- Optimize avec SVGO
**Cache :**
- cache-updater.js (versioning auto)
- responsive-image-loader.js (chargement adapté densité)
## Workflow
1. **Analyser :** `npm run assets:analyze`
2. **Compresser :** Images TinyPNG/Squoosh, audio bitrate
3. **Intégrer :** Respecter patterns existants (loaders, versioning)
4. **Vérifier :** `npm run assets:diff`, Lighthouse > 90
## Checklist
**Images :**
- [ ] Compressées (TinyPNG/Squoosh)
- [ ] WebP + fallback PNG/JPG
- [ ] Responsive si > 50 KB (srcset)
- [ ] Lazy loading si hors-viewport
- [ ] Alt text présent
- [ ] Versioning cache-updater.js
**Audio :**
- [ ] Bitrate optimisé (96-128 kbps)
- [ ] Formats multiples (MP3 + OGG)
- [ ] < 50 KB par fichier
- [ ] Preload si critique
**Général :**
- [ ] assets:analyze exécuté
- [ ] assets:diff vérifié
- [ ] Lighthouse > 90
- [ ] First load < 2 MB
## En cas de doute
**Règles absolues :**
1. Compresse TOUJOURS (TinyPNG/Squoosh)
2. WebP + fallback PNG/JPG
3. Versioning via cache-updater.js
4. Lighthouse > 90 OBLIGATOIRE
**Outils :**
- TinyPNG/Squoosh - Compression (web)
- ffmpeg - Audio/vidéo (CLI)
- Lighthouse - Vérification
**Modules clés :**
- responsive-image-loader.js (9 KB)
- cache-updater.js (10 KB)
- npm run assets:\*
**Où chercher :**
- responsive-image-loader.js - Chargement images
- cache-updater.js - Versioning
- assets/ - Organisation actuelle
- npm run assets:analyze - État

View File

@@ -0,0 +1,124 @@
---
name: profiling-performance
description: Analyzes and optimizes application performance (loading time, FPS, memory, bottlenecks). Use when experiencing slowdowns, before releases, or optimizing arcade games
allowed-tools: Read, Grep, Glob, Bash, WebSearch
---
# Profileur de Performance
Analyse et optimise performances pour expérience utilisateur fluide (chargement, FPS, mémoire).
## Table des matières
- [Quand utiliser](#quand-utiliser)
- [Métriques cibles](#métriques-cibles)
- [Outils d'analyse](#outils-danalyse)
- [Zones de profiling](#zones-de-profiling)
- [Patterns essentiels](#patterns-essentiels)
- [Workflow](#workflow)
- [Checklist](#checklist)
- [En cas de doute](#en-cas-de-doute)
## Quand utiliser
- Ralentissements dans les jeux
- Avant chaque release majeure
- Ajout de features lourdes
- Optimisation FPS arcade
- Investigation memory leaks
- Mobile performance
## Métriques cibles
**Chargement :** FCP < 1.5s, TTI < 3s, TBT < 200ms
**Runtime :** FPS ≥ 60 (arcade), Memory < 50 MB (stable)
**Bundle :** Initial < 200 KB (gzipped), Total < 2 MB
## Outils d'analyse
**Chrome DevTools Performance :**
- Profile JS (Scripting), Rendering, Painting
- Identifie Long Tasks (> 50ms = problème)
- Mesure FPS en temps réel
**Lighthouse :**
- Performance > 90, Accessibility > 95, PWA > 90
- Identifie bottlenecks chargement
**Performance API :**
- `performance.mark()` / `performance.measure()`
- `performance.getEntriesByName()` pour résultats
## Zones de profiling
### 1. Chargement initial
- Lighthouse audit → FCP, TTI
- Lazy loading modules lourds (trouvé dans lazy-loader.js)
- Imports dynamiques existants
### 2. FPS arcade (< 60 FPS = problème)
- Trop de calculs dans game loop → cacher résultats
- Re-render inutiles → cherche dirty rectangles/layers
- DOM excessif → batch avec requestAnimationFrame
### 3. Memory leaks
- DevTools Memory → Heap snapshots
- Event listeners non nettoyés dans cleanup()
- Timers non clearés (setInterval/clearInterval)
### 4. Bundle size
- Scripts npm : analyze:dependencies, dead-code
- Lazy-loader configuration
- Code splitting opportunities
## Patterns essentiels
- **Debounce/Throttle :** Événements fréquents
- **Memoization :** Cache résultats coûteux
- **requestAnimationFrame :** Batch DOM updates
- **Lazy loading :** Modules > 50 KB
- **Cleanup :** Listeners/Timers en destroy
## Workflow
1. **Identifier :** Profile DevTools ou Lighthouse
2. **Mesurer :** Taille, FPS, TTI avant optimisation
3. **Optimiser :** Une stratégie à la fois
4. **Valider :** Re-mesure, seuils atteints, mobile OK
## Checklist
- [ ] Lighthouse Performance > 90
- [ ] FPS ≥ 60 (arcade)
- [ ] Lazy loading implémenté
- [ ] Cleanup() nettoyage complet
- [ ] Memory leak-free (heap snapshot stable)
- [ ] Bundle < 200 KB initial
- [ ] Debounce/throttle sur événements
- [ ] Assets optimisés
## En cas de doute
**Workflow minimal :**
```bash
# Profile avec DevTools ou Lighthouse
# Identifier bottleneck (chargement, FPS, mémoire)
# Appliquer pattern (lazy loading > debounce > cache)
# Mesurer avant/après
# Valider sur mobile (bas de gamme)
```
**Règles absolues :**
1. Profile d'abord, optimiser après
2. Mesure avant/après
3. Une optimisation à la fois
4. Tests passent

View File

@@ -0,0 +1,167 @@
---
name: practicing-tdd-with-jest
description: Implements features following Test-Driven Development RED/GREEN/REFACTOR cycle with Jest. Use when adding new features, fixing bugs, or refactoring existing code
allowed-tools: Read, Write, Grep, Glob, Bash
---
# Test-Driven Development avec Jest
Implémente code en suivant cycle TDD RED/GREEN/REFACTOR avec Jest.
## Table des matières
- [Quand utiliser](#quand-utiliser)
- [Cycle TDD : RED → GREEN → REFACTOR](#cycle-tdd--red--green--refactor)
- [Scripts npm](#scripts-npm)
- [Structure tests (Arrange-Act-Assert)](#structure-tests-arrange-act-assert)
- [Assertions Jest essentielles](#assertions-jest-essentielles)
- [Mocking](#mocking)
- [Tests spécialisés](#tests-spécialisés)
- [Couverture](#couverture)
- [Bonnes pratiques](#bonnes-pratiques)
- [Workflow](#workflow)
- [Checklist](#checklist)
- [En cas de doute](#en-cas-de-doute)
## Quand utiliser
- Implémentation nouvelles features
- Correction bugs avec reproduction
- Refactoring code existant
- Ajout comportements modules
- Validation logique complexe
## Cycle TDD : RED → GREEN → REFACTOR
**RED (Test échoue) :**
1. Identifier comportement
2. Écrire test AVANT code
3. Test DOIT échouer ❌
**GREEN (Test passe) :**
1. Code minimum possible
2. Pas d'optimisation/généralisation
3. Faire passer test uniquement ✅
**REFACTOR (Améliorer) :**
1. Nettoyer code (noms, structure)
2. Éliminer duplications
3. Vérifier tests passent toujours ✅
## Scripts npm
- `npm test` - Tous tests
- `npm run test:watch` - Mode watch
- `npm run test:coverage` - Avec couverture
## Structure tests (Arrange-Act-Assert)
**AAA Pattern :**
- **Arrange :** Préparer données
- **Act :** Exécuter action
- **Assert :** Vérifier résultat
**Grouping :**
- `describe()` - Grouper tests liés
- `test()` / `it()` - Tests individuels
- `beforeEach()` / `afterEach()` - Setup/cleanup
**Nommage :** Descriptif ("should do X when Y", "handles edge case Z")
## Assertions Jest essentielles
- Égalité: `toBe()` (strict), `toEqual()` (profonde)
- Booléens: `toBeTruthy()`, `toBeFalsy()`, `toBeNull()`, `toBeUndefined()`
- Nombres: `toBeGreaterThan()`, `toBeLessThan()`, `toBeCloseTo()`
- Arrays: `toContain()`, `toHaveLength()`
- Exceptions: `toThrow()`, `toThrow(ErrorClass)`
Voir documentation Jest pour liste complète.
## Mocking
**Fonctions :**
- `jest.fn()` - Mock simple
- `mockReturnValue()` - Valeur
- `mockResolvedValue()` / `mockRejectedValue()` - Promesses
- `toHaveBeenCalled()`, `toHaveBeenCalledWith(args)`, `toHaveBeenCalledTimes(n)`
**Modules :** Isoler code testé, éviter dépendances externes (API, localStorage)
## Tests spécialisés
**Async :** `async/await` recommandé, ou `expect().resolves/rejects`
**DOM/UI :** jsdom simule DOM - créer, attacher, exécuter, vérifier, cleanup
**Canvas (jeux arcade) :** Mock context, mock performance.now(), tester logique séparément rendu, tests d'état
## Couverture
**Cibles :** Branches > 80%, Functions > 80%, Lines > 80%, Statements > 80%
Lance `npm run test:coverage`, examine rapport.
## Bonnes pratiques
**Do's :**
- Test AVANT code TOUJOURS
- Un test à la fois (RED → GREEN → REFACTOR)
- Tests descriptifs (noms clairs)
- Isolés, indépendants
- Edge cases (null, undefined, limites)
- Rapides (< 100ms idéal)
**Don'ts :**
- Pas de code avant test
- Pas de tests trop larges
- Pas de tests fragiles (timing, random)
- Pas de RED ignoré (test inutile)
- Pas de .skip tests
## Workflow
1. **Requirement :** Cas normaux + edge cases
2. **Test RED :** Doit échouer
3. **Code GREEN :** Minimum pour passer
4. **REFACTOR :** Améliorer, tests verts
5. **Répéter :** Couverture > 80%
## Checklist
- [ ] Test écrit AVANT code
- [ ] Test échoue (RED)
- [ ] Code minimum
- [ ] Test passe (GREEN)
- [ ] Refactorisé si besoin
- [ ] Noms descriptifs
- [ ] AAA pattern
- [ ] Mocks isolent
- [ ] Edge cases
- [ ] Couverture > 80%
- [ ] Tests rapides
## En cas de doute
**Règles absolues :**
1. Cycle RED → GREEN → REFACTOR OBLIGATOIRE
2. Test doit échouer d'abord (sinon inutile)
3. Code minimum (pas sur-engineering)
4. Refactor après GREEN seulement
5. Tests restent verts après refactor
6. Couverture > 80%
**Références :**
- Tests existants patterns
- jest.config.cjs - Configuration
- npm run test:coverage - État actual

View File

@@ -0,0 +1,215 @@
---
name: testing-mobile-responsive
description: Tests mobile compatibility and responsive design (touch, viewports, mobile performance). Use after responsive CSS modifications, touch controls, or before releases
allowed-tools: Read, Grep, Glob, Bash, WebSearch
---
# Tests Responsive Mobile
Guide les tests de responsive design et compatibilité mobile pour garantir une expérience optimale sur tous les appareils.
## Table des matières
- [Quand utiliser](#quand-utiliser)
- [Viewports essentiels](#viewports-essentiels)
- [Outils de test](#outils-de-test)
- [Checklist responsive](#checklist-responsive)
- [Workflow de test](#workflow-de-test)
- [Checklist finale](#checklist-finale)
- [En cas de doute](#en-cas-de-doute)
## Quand utiliser
- Modifications CSS responsive
- Ajout de touch controls
- Avant chaque release
- Bugs reportés sur mobile
- Tests performance mobile
## Viewports essentiels
**Desktop:** 1920×1080, 1366×768
**Tablet:** 768×1024, 1024×768
**Mobile:** 375×667, 390×844, 412×915
Trouve les breakpoints CSS utilisés dans le projet.
## Outils de test
### Chrome DevTools Device Mode
Émule différents appareils :
- Viewports prédéfinis
- Touch simulation
- Network/CPU throttling
### Chrome DevTools MCP
- Capture screenshots multi-device
- Tests automatisés layout
- Performance profiling
### Tests sur vrais appareils
**Essentiels :**
- iPhone (iOS récent)
- Android (version récente)
**Pourquoi :**
- Touch réel ≠ simulation
- Performance réelle
- Bugs spécifiques device
## Checklist responsive
### 1. Layout
- Layout fluide (pas de horizontal scroll)
- Contenu lisible sans zoom
- Images redimensionnées
- Colonnes en stack mobile
### 2. Touch targets
**Taille minimum :**
- 44×44 px (iOS)
- 48×48 px (Android)
- 8px espacement minimum
Trouve les tailles de touch targets dans le CSS.
### 3. Navigation mobile
- Menu burger accessible
- Animation fluide
- Fermeture backdrop ou X
- Pas de piège clavier
### 4. Touch interactions
**Supportés :**
- Tap (pas de hover requis)
- Swipe si applicable
- Pinch-zoom si pertinent
**Éviter :**
- Hover-only interactions
- Gestures complexes
Trouve les touch handlers dans le JavaScript.
### 5. Formulaires mobiles
**Optimisations :**
- Input type approprié (`email`, `tel`, `number`)
- `autocomplete` actif
- Labels visibles
- Clavier adapté au type
Examine les formulaires et leur configuration.
### 6. Images responsive
**Techniques :**
- `srcset` pour résolutions multiples
- `<picture>` pour art direction
- Lazy loading
- WebP avec fallback
Trouve la stratégie d'images responsive.
### 7. Typography
**Tailles :**
- 16px minimum corps de texte
- Line-height ≥ 1.5
- rem/em pour scalabilité
Examine les tailles de police CSS.
### 8. Performance mobile
**Métriques cibles :**
- First Contentful Paint < 2s (3G)
- Time to Interactive < 5s (3G)
- Lighthouse Performance > 80
Lance Lighthouse en mode mobile.
## Workflow de test
### 1. Tests DevTools
Pour chaque viewport clé :
- Layout adaptatif
- Touch targets simulation
- Performance
- Screenshot
### 2. Tests vrais devices
iPhone et Android :
- Navigation complète
- Touch interactions réelles
- Formulaires
- Jeux arcade si applicable
### 3. Tests throttling
Avec 3G + 4x CPU :
- Temps de chargement
- Fluidité interactions
- FPS jeux arcade
### 4. Corrections
Priorise :
1. Bloquants (layout cassé)
2. UX dégradée (touch targets petits)
3. Performance (chargement lent)
## Checklist finale
- [ ] Tous viewports testés (mobile, tablet, desktop)
- [ ] Touch targets ≥ 44×44 px
- [ ] Pas de horizontal scroll
- [ ] Menu mobile fonctionnel
- [ ] Formulaires optimisés (input types)
- [ ] Images responsive (srcset/picture)
- [ ] Typography lisible (16px min)
- [ ] Performance 3G acceptable (< 5s TTI)
- [ ] Testé sur vrais appareils (iOS + Android)
- [ ] Lighthouse Mobile > 80
- [ ] Pas de hover-only interactions
## En cas de doute
**Source :** Vrais appareils + Lighthouse Mobile
**Règles absolues :**
1. Toujours tester sur vrais appareils (iOS + Android)
2. Toujours tester avec 3G throttling
3. Touch targets minimum 44×44 px
4. Jamais hover-only interactions
5. Lighthouse Mobile > 80 obligatoire
**Workflow minimal :**
- DevTools pour iterations rapides
- Vrais appareils pour validation finale
- Lighthouse mobile pour métriques

View File

@@ -0,0 +1,149 @@
---
name: testing-visual-regression
description: Visual regression tests for canvas games and responsive UI. Use after canvas modifications, CSS changes, or adding new arcade games
allowed-tools: Read, Grep, Glob, Bash, WebSearch
---
# Tests de Régression Visuelle
Détecte régressions visuelles dans jeux canvas et UI responsive via captures automatiques.
## Table des matières
- [Quand utiliser](#quand-utiliser)
- [Ce que les tests visuels détectent](#ce-que-les-tests-visuels-détectent)
- [Architecture](#architecture)
- [Outils et Configuration](#outils-et-configuration)
- [Tests essentiels](#tests-essentiels)
- [Gestion des faux positifs](#gestion-des-faux-positifs)
- [Debugging](#debugging)
- [Workflow](#workflow)
- [Checklist](#checklist)
- [En cas de doute](#en-cas-de-doute)
## Quand utiliser
- Modifications code canvas (jeux arcade)
- Changements CSS ou styles
- Ajout nouveau jeu arcade
- Avant release majeure
- Bugs visuels reportés
- Modifications thèmes
## Ce que les tests visuels détectent
**Tests unitaires NE détectent PAS:**
- Sprites mal positionnés/manquants
- Couleurs incorrectes
- Animations cassées
- Éléments mal alignés
- Responsive breakpoints cassés
- Thèmes mal appliqués
## Architecture
**Structure :**
- `baselines/` - Images de référence
- `current/` - Captures actuelles
- `diffs/` - Différences visuelles
**Viewports :**
- Desktop: 1920×1080
- Tablet: 768×1024
- Mobile: 375×667
Trouve structure tests visuels dans projet.
## Outils et Configuration
**Outils :** Playwright (visual testing intégré)
**Configuration clés :**
- Répertoire tests visuels
- Timeout canvas
- Retry sur timing
- Base URL serveur local
- Viewports configurés
Trouve ou crée configuration Playwright.
## Tests essentiels
**Jeux arcade (par jeu):**
- Écran démarrage
- Gameplay + action
- Game over
- États spécifiques
**UI responsive (par composant):**
- Dashboard, TopBar, Customization
- Chaque viewport (desktop, tablet, mobile)
- États interactifs (menus, toggles)
**Tolérance :**
- UI statique: maxDiffPixels 50-100
- Canvas animé: maxDiffPixels 200-300
- Responsive: maxDiffPixels 100
## Gestion des faux positifs
- **Animations :** Pause avant capture
- **Contenu dynamique :** Masquer avec option mask
- **Fonts :** Font smoothing cohérent
## Debugging
**Outils :**
- Rapport HTML (diffs visuels)
- Mode UI interactif (meilleur debug)
- Inspection manuelle diffs
**Images générées :**
- baseline (référence)
- actual (capture)
- diff (différences en rouge)
## Workflow
1. **Setup :** Installe Playwright, crée structure dossiers
2. **Tests arcade :** Start, gameplay, gameover
3. **Tests UI :** Tous viewports, états interactifs
4. **CI/CD :** Ajoute stage, bloque merge si régressions
5. **Review :** Examine diffs manuellement
## Checklist
- [ ] Desktop tests passent (1920×1080)
- [ ] Tablet tests passent (768×1024)
- [ ] Mobile tests passent (375×667)
- [ ] Baselines mises à jour (si intentionnel)
- [ ] Baselines commitées descriptif
- [ ] Pas de faux positifs
- [ ] Tolérance appropriée
- [ ] Diffs reviewed manuellement
## En cas de doute
**Règles absolues :**
1. Tests visuels OBLIGATOIRES après mods visuelles
2. Review manuellement TOUS diffs
3. Update baselines uniquement si intentionnel
4. Tolérance adaptée : statique strict, animé plus souple
5. Debug avec UI interactif
6. Baselines avec messages descriptifs
**Référence :**
- Structure baselines/ existante
- Scripts npm visual-testing
- Diffs générés (baseline/actual/diff)