Initial commit

This commit is contained in:
Zhongwei Li
2025-11-30 08:26:40 +08:00
commit df656f9818
13 changed files with 1070 additions and 0 deletions

View File

@@ -0,0 +1,214 @@
---
name: auditing-security
description: Audits application security (XSS, CSP, vulnerable dependencies, CORS). Use before releases, after adding dependencies, or modifying security-utils.js
allowed-tools: Read, Grep, Glob, Bash, WebSearch
---
# Security Audit
Audite la sécurité de l'application web selon standards OWASP et best practices.
## Table des matières
- [Quand utiliser](#quand-utiliser)
- [Domaines de sécurité](#domaines-de-sécurité)
- [Checklist sécurité](#checklist-sécurité)
- [Outils d'audit](#outils-daudit)
- [En cas de doute](#en-cas-de-doute)
## Quand utiliser
- Avant chaque release en production
- Après ajout/mise à jour dépendances npm
- Modifications de `security-utils.js`
- Warnings eslint-plugin-security
- Avant commit manipulant HTML dynamique
- Ajout de scripts externes (CDN, analytics)
## Domaines de sécurité
### 1. XSS (Cross-Site Scripting) Prevention
**Règle absolue : Utiliser security-utils.js**
Trouve security-utils.js pour voir fonctions disponibles :
- `appendSanitizedHTML()` - Insérer HTML dynamique
- `createSafeElement()` - Créer élément avec contenu sécurisé
- `setSafeMessage()` - Définir texte (pas HTML)
**Dangers :**
- `innerHTML` avec user input → XSS
- Fonctions d'exécution dynamique avec données externes
- Event handlers depuis user input
**Exceptions sécurisées :**
- `innerHTML = ''` (nettoyage)
- `getTranslation()` output (contenu interne)
### 2. Content Security Policy (CSP)
**Principe : Meta tag CSP dans index.html**
Examine index.html pour voir configuration CSP actuelle.
**Baseline restrictive :**
- `default-src 'self'`
- Pas de `'unsafe-eval'` dans script-src
- `'unsafe-inline'` limité au strict nécessaire
- `frame-ancestors 'none'` pour prévenir clickjacking
**Scripts externes :**
- Toujours `crossorigin="anonymous"`
- Integrity hashes pour bibliothèques statiques
- PAS d'integrity pour analytics (auto-update)
- Documenter exceptions avec commentaires
### 3. Dependency Vulnerabilities
**Commandes audit :**
```bash
npm audit # Scan vulnérabilités
npm audit --json # Rapport détaillé
npm audit fix # Fix auto (patch/minor)
npm audit fix --force # Fix breaking (attention!)
```
**Niveaux de sévérité :**
- **Critical/High** : Fix immédiatement avant release
- **Moderate** : Fix dans sprint suivant
- **Low** : Monitorer, fix si possible
**Vérifier :**
- Pas de dépendances deprecated
- Versions à jour (pas trop anciennes)
- Licences compatibles
### 4. HTTPS et Mixed Content
**Vérifier :**
- HTTPS obligatoire en production
- Pas de resources HTTP (mixed content)
- Redirection HTTP → HTTPS
- HSTS header
Examine configuration serveur ou CDN.
### 5. Secrets et Credentials
**Règles :**
- **JAMAIS** committer secrets (API keys, tokens, passwords)
- **JAMAIS** stocker passwords en LocalStorage
- Utiliser variables d'environnement
- .gitignore pour fichiers sensibles (.env, credentials.json)
**Vérifier :**
- Pas de secrets hardcodés dans code
- .env dans .gitignore
- Terraform state pas committé
### 6. LocalStorage Security
**Données sensibles :**
- **JAMAIS** tokens d'authentification
- **JAMAIS** passwords ou PII
- OK pour préférences utilisateur non sensibles
**Vérifier :**
- storage.js utilise localStorage correctement
- Pas de données sensibles stockées
- Données validées avant lecture
## Checklist sécurité
- [ ] Tous `innerHTML` utilisent `appendSanitizedHTML()` ou justifiés
- [ ] Pas de fonctions d'exécution dynamique avec données externes
- [ ] Meta tag CSP présent dans index.html
- [ ] `crossorigin="anonymous"` sur scripts externes
- [ ] `npm audit` sans Critical/High
- [ ] Pas de secrets hardcodés
- [ ] Pas de données sensibles en LocalStorage
- [ ] HTTPS en production
- [ ] Pas de mixed content
- [ ] Tests sécurité passent
## Outils d'audit
**ESLint Security :**
```bash
npm run lint # Inclut eslint-plugin-security
```
**Dependency Scan :**
```bash
npm audit
```
**Lighthouse Security Audit :**
- Lance Chrome DevTools → Lighthouse
- Vérifie section Security
- Score doit être 100
**OWASP ZAP (optionnel) :**
- Scan automatisé pour vulnérabilités web
- Tests de pénétration
## En cas de doute
**Source :** security-utils.js + CLAUDE.md
**Fichiers clés :**
1. `js/security-utils.js` - Fonctions sécurité du projet
2. `eslint.config.js` - Règles security ESLint
3. `index.html` - Configuration CSP
4. `CLAUDE.md` - Guidelines sécurité
**Règles absolues :**
1. TOUJOURS utiliser security-utils.js pour manipulation DOM
2. TOUJOURS audit avant release (`npm audit`)
3. JAMAIS `innerHTML` avec user input direct
4. JAMAIS stocker données sensibles en LocalStorage
5. JAMAIS scripts externes sans `crossorigin="anonymous"`
**Workflow minimal avant commit :**
```bash
npm run lint # ESLint security rules
npm audit # Dependency check
npm test # Security tests
```
**Workflow complet avant release :**
```bash
npm run verify # Full quality gate
npm audit --audit-level=moderate # Dependency audit
# Lighthouse security audit
# Review index.html CSP config
```
**Red flags (arrêter immédiatement) :**
- Fonctions d'exécution dynamique avec données externes
- `innerHTML = userInput`
- Tokens/passwords en LocalStorage
- npm audit Critical/High
- Scripts CDN sans crossorigin

View File

@@ -0,0 +1,159 @@
---
name: managing-dependencies
description: Manages npm dependencies (audit, updates, breaking changes, lockfile). Use before releases, after adding packages, or monthly for maintenance
allowed-tools: Read, Grep, Glob, Bash
---
# Gestion des Dépendances
Gère dépendances npm de manière sécurisée (audit, mises à jour, lockfile).
## Table des matières
- [Quand utiliser](#quand-utiliser)
- [Scripts npm](#scripts-npm)
- [Workflows essentiels](#workflows-essentiels)
- [Gestion vulnérabilités](#gestion-vulnérabilités)
- [Migrations majeures](#migrations-majeures)
- [Bonnes pratiques](#bonnes-pratiques)
- [Checklist](#checklist)
- [En cas de doute](#en-cas-de-doute)
## Quand utiliser
- Avant chaque release production
- Après ajout nouvelles dépendances
- Mensuellement maintenance proactive
- Quand vulnérabilités signalées
- Migrations versions majeures
## Scripts npm
- `npm audit` - Vue d'ensemble sécurité
- `npm audit --json` - Rapport détaillé
- `npm audit fix` - Fix auto (patch/minor)
- `npm outdated` - Packages à mettre à jour
- `npm update` - Update patches/minors
- `npm ls` / `npm ls --depth=0` - Arbre dépendances
## Workflows essentiels
**Audit sécurité :**
- CRITICAL/HIGH → Corriger immédiatement
- MODERATE → Corriger avant release
- LOW → Corriger quand possible
**Types mises à jour (SemVer) :**
- Patch (1.0.x) → Bugs, sécurisé
- Minor (1.x.0) → Features, rétrocompatible
- Major (x.0.0) → Breaking, nécessite tests
**Stratégie :**
- Patches → Auto si tests passent
- Minors → Manuel vérification
- Majors → Manuel migration plan
**Lockfile :**
- Garantit versions exactes
- Commit toujours avec package.json
- Désynchronisé → `npm install`
- Conflit merge → Résoudre + `npm install`
## Gestion vulnérabilités
**Critiques/Hautes :** Fix immédiat, tester, déployer rapidement
**Sans fix :** Package alternatif, fork + patch, monitorer, désactiver si possible
**Packages deprecated :** Chercher alternatives maintenues, planifier migration
## Migrations majeures
**Préparation :**
1. Lire CHANGELOG (breaking changes)
2. Estimer impact code
3. Créer branche dédiée
**Exécution :**
1. Update package.json
2. Adapter code aux breaking changes
3. Corriger erreurs TS/ESLint
4. Tests exhaustifs
**Validation :**
- Tests passent
- Lighthouse score OK
- Performance stable
- Pas régressions visuelles
## Bonnes pratiques
**Do's :**
- Commit lockfile toujours
- Audit hebdomadaire minimum
- Tests après update
- Un update à la fois
- Lire CHANGELOG majors
- Respecter SemVer
**Don'ts :**
- Pas `npm install --force` (sauf urgence)
- Pas updates aveugles
- Pas lockfile .gitignore
- Pas updates avant release
- Pas dépendances non maintenues
## Checklist
- [ ] `npm audit` sans CRITICAL/HIGH
- [ ] `npm outdated` vérifié
- [ ] Lockfile synchronisé
- [ ] Tests passent après update
- [ ] Build OK
- [ ] Performance stable
- [ ] Pas deprecated packages
- [ ] CHANGELOG lu (majors)
- [ ] Lockfile committé
## En cas de doute
**Règles absolues :**
1. `npm audit` AVANT release obligatoire
2. Tester APRÈS mise à jour
3. Jamais ignorer lockfile
4. CHANGELOG pour majors
5. CRITICAL/HIGH fix immédiat
**Workflow mensuel :**
```bash
npm outdated
npm audit
npm update
npm test
```
**Workflow avant release :**
```bash
npm audit --audit-level=moderate
npm outdated
npm test
npm run build
```
**Références :**
- package.json - Versions actuelles
- package-lock.json - Lockfile
- npm docs - Documentation

169
skills/i18n-sync/SKILL.md Normal file
View File

@@ -0,0 +1,169 @@
---
name: synchronizing-i18n-translations
description: Verifies translation files synchronization (fr.json, en.json, es.json) and detects missing keys, empty values, and type inconsistencies
allowed-tools: Read, Grep, Glob, Bash
---
# I18n Translation Synchronization
Maintient la synchronisation des fichiers de traduction pour toutes les langues supportées.
## Table des matières
- [Quand utiliser](#quand-utiliser)
- [Langues supportées](#langues-supportées)
- [Scripts disponibles](#scripts-disponibles)
- [Workflow principal](#workflow-principal)
- [Détection automatique](#détection-automatique)
- [Corriger les erreurs](#corriger-les-erreurs)
- [Structure des fichiers](#structure-des-fichiers)
- [Checklist i18n](#checklist-i18n)
- [En cas de doute](#en-cas-de-doute)
## Quand utiliser
- Ajout de nouveaux textes UI
- Modification de traductions existantes
- Avant de committer changements i18n
- Quand `npm run i18n:compare` signale erreurs
## Langues supportées
- **fr.json** (référence) - Toujours modifier en premier
- **en.json** (anglais)
- **es.json** (espagnol)
## Scripts disponibles
```bash
npm run i18n:compare # Compare tous les fichiers (PRINCIPAL)
npm run i18n:verify # Vérifie cohérence
npm run i18n:unused # Détecte clés inutilisées
```
## Workflow principal
### 1. Vérifier l'état actuel
```bash
npm run i18n:compare
```
Si erreurs, lire le rapport détaillé.
### 2. Modifier les traductions
**Règle d'or :** Toujours commencer par `fr.json`
1. Modifie `fr.json` d'abord
2. Copie la STRUCTURE (pas les valeurs) dans en.json et es.json
3. Traduis les valeurs
### 3. Vérifier synchronisation
```bash
npm run i18n:compare
```
Doit afficher : "Tous les fichiers de traduction sont parfaitement synchronisés !"
### 4. Tester dans l'UI
Lance l'application et teste le sélecteur de langue.
## Détection automatique
Le script `npm run i18n:compare` détecte :
**Clés manquantes :**
- Clés présentes dans fr.json mais absentes dans en.json/es.json
**Clés supplémentaires :**
- Clés présentes dans en.json/es.json mais absentes dans fr.json
**Valeurs vides :**
- `""`, `null`, `undefined`, `[]`
**Incohérences de types :**
- String vs Array (ex: fr.json = "text", en.json = ["array"])
**Format du rapport :**
- Console détaillée
- JSON exporté dans `docs/translations-comparison-report.json`
## Corriger les erreurs
### Clés manquantes
Ajoute les clés manquantes dans en.json/es.json avec traductions appropriées.
### Clés supplémentaires
Supprime les clés supplémentaires OU ajoute-les dans fr.json si nécessaires.
### Valeurs vides
Remplace les valeurs vides par traductions appropriées.
### Types incohérents
Uniformise le type (soit String partout, soit Array partout).
## Structure des fichiers
**Format JSON :**
```json
{
"key": "value",
"nested": {
"key": "value"
},
"array": ["item1", "item2"]
}
```
**Dot notation :**
- `key` → "key"
- `nested.key` → "nested.key"
- `array` → "array"
Le script aplatit la structure en dot notation pour comparaison.
## Checklist i18n
- [ ] fr.json modifié en premier
- [ ] Structure copiée dans en.json et es.json
- [ ] Valeurs traduites correctement
- [ ] `npm run i18n:compare` passe (100% synchronisé)
- [ ] Testé dans UI avec sélecteur de langue
- [ ] Pas de valeurs vides
- [ ] Types cohérents (String ou Array)
## En cas de doute
**Source :** fr.json + npm scripts
**Règles absolues :**
1. Toujours vérifier avec `npm run i18n:compare`
2. fr.json est la référence (pas en.json, pas es.json)
3. Ne jamais committer avec erreurs i18n
4. Tester dans UI avant commit
5. Scripts npm détectent TOUS les problèmes
**Workflow minimal :**
```bash
# Modifier fr.json
npm run i18n:compare # Vérifier
# Copier structure dans en.json, es.json
# Traduire valeurs
npm run i18n:compare # DOIT être OK
```

View File

@@ -0,0 +1,94 @@
---
name: managing-pwa-service-worker
description: Manages Service Worker updates securely with cache versioning and offline tests. Use when modifying SW, adding resources, or changing cache strategy
allowed-tools: Read, Write, Grep, Glob, Bash
---
# PWA Service Worker Manager
Gère Service Worker pour offline play et cache versioning sécurisé.
## Quand utiliser
- Modification Service Worker
- Ajout ressources à cacher
- Changement stratégie cache
- Tests offline
- Correction bugs SW
## Scripts essentiels
```bash
npm run test:pwa-offline # Tester offline (PRINCIPAL)
npm run sw:disable # Désactiver SW
npm run sw:fix # Réparer SW
```
## Versioning et workflow
**SemVer (voir sw.js) :**
- Major : Changements cassants
- Minor : Ressources ajoutées
- Patch : Corrections
**Workflow :**
1. **Modifier :** sw.js (version, ressources, handlers)
2. **Incrémenter :** Version (SemVer)
3. **Tester :** `npm run test:pwa-offline`
4. **Vérifier :** DevTools App tab (Offline mode)
5. **Quality :** format:check, lint, test
## Stratégies de cache
- **Cache First :** Assets (HTML, CSS, JS, images)
- **Network First :** APIs (données fraîches)
- **Cache Only :** Assets immuables
- **Network Only :** Analytics, auth
Trouve stratégie dans sw.js existant.
## Événements SW clés
- **Install :** Créer cache, skipWaiting()
- **Activate :** Nettoyer anciens caches, clients.claim()
- **Fetch :** Appliquer stratégie, gérer erreurs
## Debugging
**Chrome DevTools (F12) → Application → Service Workers :**
- Offline mode → Tester navigation
- caches.keys() en console → Vérifier caches
**Problèmes courants :**
- SW ne s'update → Incrémenter version, skipWaiting() présent
- Ressources manquantes → Ajouter à liste cache
- Cache volumineux → Cacher uniquement ressources critiques
## Checklist
- [ ] Version incrémentée (SemVer)
- [ ] skipWaiting() + clients.claim() présents
- [ ] Nettoyage anciens caches
- [ ] Offline test OK (`npm run test:pwa-offline`)
- [ ] DevTools Offline mode OK
- [ ] format:check, lint, test passent
## En cas de doute
**Règles absolues :**
1. Incrémenter version TOUJOURS
2. Tester offline AVANT commit
3. DevTools Application tab verification
4. `npm run test:pwa-offline` doit passer
5. skipWaiting() + clients.claim() essentiels
**Références :**
- `sw.js` - Service Worker principal
- `manifest.json` - PWA manifest
- Chrome DevTools Application tab

View File

@@ -0,0 +1,167 @@
---
name: validating-accessibility
description: Validates web accessibility according to WCAG 2.1 AA standards for users with disabilities. Use when modifying UI, adding components, or performing accessibility audits
allowed-tools: Read, Grep, Glob, Bash, WebSearch
---
# Validateur d'Accessibilité
Guide la validation et l'amélioration de l'accessibilité web selon WCAG 2.1 niveau AA.
## Table des matières
- [Quand utiliser](#quand-utiliser)
- [Standards WCAG 2.1 AA](#standards-wcag-21-aa)
- [Scripts npm disponibles](#scripts-npm-disponibles)
- [Checklist essentielle](#checklist-essentielle)
- [Workflow d'audit](#workflow-daudit)
- [Checklist avant release](#checklist-avant-release)
- [En cas de doute](#en-cas-de-doute)
## Quand utiliser
- Ajout de composants UI
- Modification d'interfaces
- Avant chaque release majeure
- Audit d'accessibilité complet
## Standards WCAG 2.1 AA
**Quatre principes POUR :**
1. **Perceptible** - Information présentable
2. **Opérable** - Composants opérables
3. **Compréhensible** - Info et UI compréhensibles
4. **Robuste** - Contenu robuste
## Scripts npm disponibles
Trouve et utilise :
- Audit accessibilité complet
- Audit mobile responsive
- Vérification contraste
- Tests automatisés
## Checklist essentielle
### 1. Structure sémantique HTML
- Balises appropriées (`<header>`, `<nav>`, `<main>`, `<footer>`)
- Hiérarchie titres logique (h1 → h2 → h3)
- `<button>` pour actions, `<a>` pour navigation
### 2. Navigation clavier
- Éléments interactifs focusables
- Ordre tabulation logique
- Focus visible (outline ou custom)
- Raccourcis clavier sans conflit
### 3. ARIA (Accessible Rich Internet Applications)
**Utiliser quand sémantique HTML insuffisante**
Règles :
- Pas d'ARIA mieux que mauvais ARIA
- Vérifier support lecteurs d'écran
- Tester avec vraies technologies assistives
Attributs courants :
- `aria-label`, `aria-labelledby`
- `aria-describedby`
- `aria-hidden`
- `role` (button, dialog, alert, etc.)
### 4. Contraste couleurs
**WCAG 2.1 AA minimum :**
- Texte normal : 4.5:1
- Texte large (≥18pt ou ≥14pt gras) : 3:1
- Composants UI : 3:1
Outils : navigateur DevTools, Contrast Checker
### 5. Alternatives textuelles
- Toutes images avec `alt`
- Images décoratives : `alt=""`
- Images complexes : description détaillée
- Vidéos : sous-titres/transcription
### 6. Formulaires
- Labels explicites associés
- Messages d'erreur clairs
- Instructions visibles
- Validation côté client + serveur
### 7. Responsive et zoom
- Support zoom 200% sans perte fonctionnalité
- Contenu responsive (mobile, tablette, desktop)
- Touch targets ≥ 44×44 px mobile
## Workflow d'audit
### 1. Tests automatisés
Utilise scripts npm disponibles ou Lighthouse (Chrome DevTools).
### 2. Tests manuels
**Navigation clavier :**
- Tab à travers tous éléments interactifs
- Enter/Space pour activer
- Échap pour fermer modales/menus
**Lecteur d'écran :**
- VoiceOver (macOS/iOS)
- NVDA (Windows)
- JAWS (Windows)
**Contraste :**
- Vérifie tous textes et icônes
- Teste modes sombre/clair
### 3. Tests utilisateurs réels
- Personnes avec handicaps
- Différentes technologies assistives
- Feedback sur expérience réelle
## Checklist avant release
- [ ] Hiérarchie titres correcte
- [ ] Navigation clavier complète
- [ ] Contraste WCAG AA respecté
- [ ] Alt text sur toutes images
- [ ] Labels formulaires associés
- [ ] Focus visible partout
- [ ] Tests lecteur d'écran passés
- [ ] Zoom 200% fonctionnel
- [ ] Touch targets ≥ 44px mobile
## En cas de doute
**Source :** Standards WCAG 2.1 AA officiels
**Règles absolues :**
1. Toujours tester clavier uniquement
2. Toujours vérifier contraste
3. Toujours tester lecteur d'écran
4. Jamais cacher contenu sans `aria-hidden`
5. Jamais empêcher zoom mobile
**Workflow minimal :**
- Lighthouse audit
- Navigation clavier complète
- Test 1 lecteur d'écran minimum