@neikyun/ciel 6.14.0 → 6.14.2

package/assets/.claude/skills/logging/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: logging
+description: "Logging — structured JSON, correlation ID, PII scrubbing, centralized aggregation, log levels as signal. À charger quand on configure les logs."
+---
+
+# Logging
+
+**Principe premier :** Les logs ne sont pas pour toi — ils sont pour le "toi du futur" qui debug une erreur à 3h du matin sans contexte. Un log qui dit "Error occurred" est pire que pas de log — il donne l'illusion d'information. Chaque log doit répondre à : quoi, quand, où, qui, et pourquoi c'est arrivé. Le format est JSON structuré, pas du texte libre — parce que les logs seront parsés par des machines (Loki, ELK, Datadog) bien avant d'être lus par des humains.
+
+## Checklist
+- [ ] Logs structurés JSON — pas de `console.log("texte libre " + variable)`
+- [ ] Correlation ID (trace ID) injecté et transmis à travers tous les services
+- [ ] Niveaux de log respectés : ERROR (action requise), WARN (attention), INFO (normal), DEBUG (détail)
+- [ ] Stack trace + contexte (userId, orderId, params) dans chaque ERROR
+- [ ] PII/secret scrubbing : jamais de password, token, carte bancaire, email dans les logs
+- [ ] Centralisation : tous les logs vers un endpoint unique (Loki/ELK/CloudWatch)
+- [ ] Rétention configurée : hot 7j, warm 30j, cold 1 an
+
+## Anti-patterns
+### Log texte libre
+**Ce qu'on voit :** `console.log("User " + userId + " logged in at " + Date.now())`. Concaténation de strings.
+**Pourquoi c'est dangereux :** impossible à parser automatiquement. Pas de champ structuré. Recherche et filtrage impossibles sans regex fragiles. Si le format change légèrement, tous les dashboards cassent.
+**Faire plutôt :** `logger.info({ event: "user_login", userId, timestamp }, "User logged in")`. JSON structuré. Champs typés. Requêtable.
+
+### Pas de correlation ID
+**Ce qu'on voit :** chaque service logue avec son propre ID. Impossible de suivre une requête à travers 3 microservices.
+**Pourquoi c'est dangereux :** debug en microservices = ouvrir 3 terminaux, chercher manuellement des timestamps qui coïncident. Une requête lente = mystère complet.
+**Faire plutôt :** correlation ID généré à l'entrée (API Gateway). Transmis dans chaque header HTTP. Logué dans chaque service. Une recherche = une requête = tous les logs.
+
+### Données sensibles dans les logs
+**Ce qu'on voit :** `logger.error("Payment failed", { cardNumber, cvv, userId })`.
+**Pourquoi c'est dangereux :** PCI-DSS violé. Données bancaires dans les logs. En cas de fuite des logs, toutes les cartes compromises. Les logs sont souvent moins protégés que la DB.
+**Faire plutôt :** `logger.error("Payment failed", { paymentId, errorCode, userId })`. Jamais de PII ou secret. Scrub automatisé en cas de doute.
+
+## Patterns
+### Structured JSON logging
+**Quand :** toute application.
+**Comment :** chaque log = `{timestamp, level, message, service, correlationId, ...context}`. Parse, filtre, indexe par Loki/ELK. Requêtable : `{.level = "ERROR"} | json | ...`
+
+### Centralized aggregation
+**Quand :** plus d'un service.
+**Comment :** tous les logs → stdout (K8s/Docker) → Promtail (parse, label) → Loki (stocke) → Grafana (requete LogQL). Un seul endroit pour chercher. LogQL : `{service="api", level="error"} |= "payment" | json`. Depuis Grafana, lien direct : log → trace ID → Tempo → span exact.
+
+### Debug flow Grafana (metrics → logs → traces)
+**Quand :** incident en production.
+**Comment :** (1) Grafana dashboard : métrique RED rouge → clic sur le point → (2) "Explore logs" → LogQL filtré par temps + service → (3) extraire le trace ID du log → (4) Tempo : trace complète avec tous les spans. Sans intégration, ces 3 outils sont séparés. Avec Grafana, ils sont liés.

package/assets/.claude/skills/ml-engineering/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: ml-engineering
+description: "ML Engineering — pipelines ML, feature stores, model serving, drift detection, MLOps, experiment tracking. A charger quand on met en production des modeles ML."
+---
+
+# ML Engineering
+
+**Principe premier :** Le ML engineering n'est pas "entrainer un modele avec le meilleur score" — c'est mettre un modele en production et garantir qu'il reste performant dans le temps. La metrique qui compte n'est pas l'accuracy sur le dataset de test (qui est un instantane du passe) — c'est la performance en production sur les donnees de demain. Un modele est un programme qui se degrade passivement : le monde change, les distributions derivent, et un modele a 98% de precision aujourd'hui peut tomber a 72% dans 6 mois sans que personne ne le sache. La difference entre un notebook Jupyter et un systeme ML de production, c'est le monitoring, le versioning, et la capacite a re-entrainer.
+
+## Checklist
+- [ ] Les donnees sont versionnees (DVC, LakeFS, Delta Lake) — pas de `dataset_v3_final_FINAL.csv`
+- [ ] Les experiences sont trackees (MLflow, W&B, ClearML) avec hyperparametres, code version, dataset version
+- [ ] Le feature store est la source unique de verite pour les features — pas de features calculees differemment en train et en inference
+- [ ] Le serving est monitorise : latence P95, taux d'erreur, distribution des predictions
+- [ ] Le data drift ET le concept drift sont monitorises — alerter quand la distribution change
+- [ ] Le pipeline d'entrainement est reproductible (DAG, conteneurise, versionne)
+- [ ] Le rollback de modele est aussi simple que le rollback de code (model registry avec versioning)
+
+## Anti-patterns
+### Notebook → production
+**Ce qu'on voit :** le data scientist donne son notebook "il marche sur mon laptop". L'ingenieur le copie-colle dans un endpoint. 2000 lignes de code non structure.
+**Pourquoi c'est dangereux :** un notebook n'est pas un programme — c'est un journal d'exploration. Pas de gestion d'erreur, pas de typage, pas de tests, pas de reproductibilite (execution ordonnee non garantie). Les imports sont eparpilles, les variables persistent entre cellules, le code est impossible a maintenir.
+**Faire plutot :** le notebook est un outil d'exploration. Le code de production est dans des modules Python standards, versionnes, testes. Le data scientist et le ML engineer travaillent ensemble sur la transition notebook → module. Le notebook documente l'intention, le module implemente la production.
+
+### Features train/serve inconsistantes
+**Ce qu'on voit :** les features sont calculees en Python (pandas) pour l'entrainement, et en Go/Java dans le serving. Implementation differente → comportement different → modele qui performe mal en production sans raison apparente.
+**Pourquoi c'est dangereux :** c'est le bug le plus pernicieux en ML. Les metriques d'entrainement sont bonnes, les tests passent, mais le modele est mauvais en production. La cause est quasi impossible a debugger sans comparer les implementations feature par feature.
+**Faire plutot :** feature store central. Les memes features, calculees par le meme code, servent l'entrainement ET l'inference. Si le calcul change, le feature store versionne. Zero implementation divergente.
+
+### Drift = surprise
+**Ce qu'on voit :** pas de monitoring du drift. Le modele se degrade lentement. 6 mois plus tard, un utilisateur remarque que les predictions sont mauvaises.
+**Pourquoi c'est dangereux :** la degradation est silencieuse et graduelle. Le modele ne crash pas — il devient juste de plus en plus mauvais. Les decisions basees sur ces predictions deviennent de plus en plus mauvaises. Le MTTD (mean time to detect) est de 6 mois.
+**Faire plutot :** monitoring continu de la distribution des features en production vs distribution d'entrainement (data drift). Monitoring des predictions (concept drift : relation feature → cible qui change). Alerter quand la divergence depasse un seuil. Re-entrainement automatise ou manuel selon la criticite.
+
+## Patterns
+### Model registry
+**Quand :** plusieurs modeles en production ou re-entrainements frequents.
+**Comment :** MLflow Model Registry, Seldon, ou Sagemaker Model Registry. Chaque modele a : version, metriques, dataset d'origine, artefact, statut (staging/production/archived). Promotion staging → production via CI/CD. Rollback = pointer vers la version precedente en un clic.
+
+### Feature store
+**Quand :** features reutilisees entre plusieurs modeles ou entre train/serving.
+**Comment :** Feast, Tecton, ou solution interne. Les features sont definies une fois, calculees offline (batch) et servies online (low latency). Le feature store garantit la consistance entre train et serve. Chaque feature est versionnee et documentee.

package/assets/.claude/skills/mobile/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: mobile
+description: "Mobile — iOS/Android/React Native/Flutter, offline-first, batterie, store review, push notifications. A charger quand on developpe une application mobile."
+---
+
+# Mobile
+
+**Principe premier :** Le mobile n'est pas "un petit ecran" — c'est un environnement hostile. Reseau instable (tunnel → metro → edge → 3G), batterie limitee, stockage restreint, OS qui peut killer l'app a tout moment. Si ton app ne fonctionne pas dans un tunnel avec 1 barre de 3G et 10% de batterie, elle ne fonctionne pas. Le store (App Store, Play Store) est ton canal de distribution mais aussi ton gatekeeper — chaque release est une revue humaine qui peut etre rejetee. Le mobile recompense l'optimisme offline et le pessimisme reseau : suppose toujours que le reseau est lent, cher, et hostile.
+
+## Checklist
+- [ ] Offline-first : l'app fonctionne sans reseau — donnees en cache local, actions en file d'attente
+- [ ] Les images sont lazy-loadees et resizees (pas de 4K telecharge sur un ecran 400px de large)
+- [ ] La batterie est respectee : pas de polling every 5s, pas de wake lock permanent, pas de GPS continu
+- [ ] Le state est preserve a travers les kills d'OS (serialisation automatique du state critique)
+- [ ] Les crashs sont reportes (Crashlytics, Sentry) — pas de "ca crash sur le telephone de Julie"
+- [ ] Les updates sont gerees : forced update si API incompatible, optional update sinon
+- [ ] Le stockage local a un TTL et une limite de taille — pas de cache infini qui remplit le telephone
+
+## Anti-patterns
+### Mobile = site web en webview
+**Ce qu'on voit :** une webview qui charge le site responsive. Publie sur les stores. "Ca marche sur mobile."
+**Pourquoi c'est dangereux :** zero integration native. Pas de push notifications, pas de stockage offline, pas de gestures natives, pas de transition fluide. Les utilisateurs le sentent immediatement et desinstallent. Les stores peuvent rejeter si l'app n'apporte rien par rapport au site.
+**Faire plutot :** si le contenu est statique → PWA (plus leger, pas besoin de store). Si besoin natif (push, camera, offline) → app native ou React Native/Flutter avec vrais composants natifs.
+
+### Optimiste sur le reseau
+**Ce qu'on voit :** l'app suppose que le reseau est disponible et rapide. Pas de cache, pas de queue offline, pas de gestion d'erreur reseau. L'app affiche un spinner blanc des que le reseau est lent.
+**Pourquoi c'est dangereux :** le reseau mobile est le pire reseau de tous les clients. L'utilisateur est dans un ascenseur, un metro, une cave, une campagne. Si l'app ne fonctionne pas offline, elle est inutilisable 30% du temps. L'utilisateur ouvre l'app concurrente.
+**Faire plutot :** cache local (SQLite, Realm, WatermelonDB). Sync en arriere-plan quand le reseau est disponible. UI qui montre les donnees en cache immediatement, puis rafraichit. Indicateur "donnees de X minutes" plutot qu'un spinner.
+
+### Release = pari
+**Ce qu'on voit :** soumission sur le store sans test de recette. Rejet pour violation de guideline. 3 jours de delai. Corrections en catastrophe.
+**Pourquoi c'est dangereux :** le store review est un processus humain, lent, et imprevisible. Un rejet decale la release de 3-7 jours. Les utilisateurs attendent, les bugs critiques restent en production.
+**Faire plutot :** pre-release checklist (guidelines store, screenshots, permissions documentees). TestFlight/Internal Testing pour valider le binaire avant soumission. Soumission en debut de semaine pour maximiser les chances de review rapide.
+
+## Patterns
+### Offline-first avec sync queue
+**Quand :** app qui modifie des donnees (notes, taches, commandes).
+**Comment :** ecriture locale immediate → queue de synchronisation → synchro background quand online. Resolution de conflits : last-write-wins pour donnees simples, merge pour donnees complexes. UI qui montre l'etat de synchro (sync, synced, error).
+
+### Gradual rollout sur stores
+**Quand :** release avec risque (refonte, nouvelle fonctionnalite).
+**Comment :** Play Store : staged rollout (10% → 50% → 100% avec possibilite de halt). App Store : phased release sur 7 jours. Monitoring des crashs et des ratings par version. Rollback en arretant le rollout (pas besoin de nouvelle soumission).

package/assets/.claude/skills/monitoring/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: monitoring
+description: "Monitoring — RED/USE metrics, SLI/SLO/SLA comme contrats, dashboards comme outils de debugging, alerting fatigue. À charger quand on met en place du monitoring."
+---
+
+# Monitoring
+
+**Principe premier :** Le monitoring n'est pas "avoir des dashboards" — c'est pouvoir répondre à deux questions en < 30 secondes : "est-ce que le système fonctionne ?" et "si non, qu'est-ce qui a changé ?". Si tes dashboards ne répondent pas à ça, ils sont du bruit visuel. La métrique fondamentale n'est pas le nombre de graphiques — c'est le Mean Time To Detect (MTTD). Combien de temps entre le début de l'incident et la première alerte ? Si la réponse est "quand un client ouvre un ticket", ton monitoring a échoué.
+
+## Checklist
+- [ ] RED metrics par service : Rate, Errors, Duration (P50/P95/P99) — collectées via Prometheus, exposées sur `/metrics`
+- [ ] USE metrics par ressource : Utilization, Saturation, Errors — node_exporter/cAdvisor → Prometheus → Grafana
+- [ ] Dashboards, règles Prometheus, et config AlertManager sont dans le repo (monitoring as code) — pas créés à la main dans l'UI Grafana
+- [ ] Dashboards Grafana avec seuils visuels (vert/jaune/rouge) — pas juste des lignes sur un graphique
+- [ ] SLI définis (ce qu'on mesure), SLO documentés (l'objectif), SLA communiqués (la promesse)
+- [ ] Alertes sur les signaux critiques uniquement — pas d'alerte sur "CPU > 70% pendant 30s à 3h du matin"
+- [ ] Runbook associé à chaque alerte — "si cette alerte sonne, voici quoi faire"
+
+## Anti-patterns
+### Dashboard = décoration
+**Ce qu'on voit :** un écran mural avec 50 graphiques, pas de titre, pas d'échelle, pas de seuil. Personne ne le regarde. Les incidents sont découverts par les utilisateurs.
+**Pourquoi c'est dangereux :** un dashboard sans contexte n'est pas un outil — c'est du bruit. Les anomalies sont noyées dans la masse de données non interprétables. Le MTTD est infini.
+**Faire plutôt :** un dashboard par service. Titre explicite. Description : "Ce dashboard montre la santé du service X. Si ce graphique est rouge, regarder Y." Seuils visuels. Maximum 10 métriques par dashboard. Le dashboard doit permettre de répondre "est-ce que c'est normal ?" en un coup d'œil.
+
+### Alerte sur tout
+**Ce qu'on voit :** 200 alertes configurées. "CPU > 50%", "mémoire > 60%", "disque > 70%". 15 alertes par nuit. L'équipe a muté le canal. Les vraies urgences sont ignorées.
+**Pourquoi c'est dangereux :** l'alert fatigue est réelle. Chaque fausse alerte entraîne la suivante vers l'ignorance. Quand une vraie alerte critique arrive, personne ne la voit parce que tout le monde a appris que "les alertes = du bruit".
+**Faire plutôt :** alerter sur les SYMPTÔMES, pas sur les causes potentielles. "P95 latency > 1s pendant 5 min" (symptôme utilisateur), pas "CPU > 70%" (cause possible). Chaque alerte doit être actionable — si tu ne peux pas écrire le runbook en 3 étapes, ne crée pas l'alerte.
+
+### Monitoring = dashboards Grafana
+**Ce qu'on voit :** tout est dans Grafana. Pas de logs structurés, pas de tracing, pas d'alerting. "On regardera le dashboard si quelqu'un se plaint."
+**Pourquoi c'est dangereux :** le monitoring sans observabilité, c'est regarder le tableau de bord de ta voiture. Tu vois que la vitesse est à 0, mais tu ne sais pas POURQUOI. Les dashboards montrent les symptômes, les logs et traces montrent les causes. L'un sans l'autre = tu sais que c'est cassé, pas pourquoi.
+**Faire plutôt :** monitoring (métriques + dashboards + alertes) + logging (logs structurés JSON + correlation ID) + tracing (OpenTelemetry, traces distribuées). Les trois piliers de l'observabilité.
+
+## Patterns
+### Prometheus + Grafana (stack standard)
+**Quand :** toute application en production.
+**Comment :** Prometheus scrape les métriques exposées par l'app (`/metrics`). Grafana interroge Prometheus (PromQL) et affiche les dashboards. Pas de solution propriétaire — cette stack est le standard ouvert, toutes les bibliothèques l'implémentent. Chaque service expose ses propres métriques RED, l'infrastructure expose les USE via node_exporter / cAdvisor.
+
+### RED method (services)
+**Quand :** monitoring de tout service (API, worker, etc.).
+**Comment :** Rate (requêtes/s), Errors (taux d'erreur), Duration (P50/P95/P99) via histogram Prometheus. 3 métriques par endpoint. Couvre l'expérience utilisateur. PromQL : `rate(http_requests_total[5m])`, `rate(http_errors_total[5m])`, `histogram_quantile(0.95, rate(http_duration_bucket[5m]))`.
+
+### USE method (ressources)
+**Quand :** monitoring de toute ressource (CPU, RAM, disque, réseau, DB pool).
+**Comment :** Utilization (% utilisé), Saturation (file d'attente), Errors (compteur d'erreurs) via node_exporter. 3 métriques par ressource. Dashboard Grafana avec seuils vert/jaune/rouge. Si Utilization > 80%, si Saturation > 0, si Errors > 0 — investiguer.
+
+### SLO-based alerting
+**Quand :** définir les alertes sans tomber dans l'alert fatigue.
+**Comment :** définir un SLO (ex: "99.9% des requêtes < 500ms sur 30 jours"). L'alerte se déclenche quand le error budget est consommé trop vite (ex: 5% du budget mensuel en 1h). Configurer dans AlertManager via Prometheus rules : `alert: HighErrorBurnRate`, `expr: rate(http_errors_total[1h]) / rate(http_requests_total[1h]) > 0.05`.
+
+### Monitoring as Code (dashboards + rules dans le repo)
+**Quand :** toute équipe de plus d'une personne.
+**Comment :** dashboards Grafana en JSON (Grafonnet pour les générer), règles Prometheus en YAML, config AlertManager en YAML — tout dans `monitoring/` du repo. Déploiement via CI/CD (Terraform, Grafana provisioning API). PR pour chaque changement de dashboard ou alerte. Le monitoring est de l'infrastructure — le même niveau de rigueur que le Terraform de prod.

package/assets/.claude/skills/networking/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: networking
+description: "Networking — le reseau comme fondation invisible. DNS, TLS, HTTP/2/3, VPC, firewall, load balancing. A charger quand on configure des connexions ou debug la connectivite."
+---
+
+# Networking
+
+**Principe premier :** Le reseau n'est pas "ce qui connecte les machines" — c'est la couche de securite zero. Avant que ton application ne recoive un octet, le reseau a deja pris 100 decisions : routage, filtrage, terminaison TLS, rate limiting. Un reseau bien configure rend 80% des attaques impossibles avant meme qu'elles n'atteignent l'application. Le probleme inverse : un reseau mal configure est invisible jusqu'a l'incident — "pourquoi le service B ne peut pas parler au service C en prod ?" La connectivite n'est jamais acquise — elle est configuree, testee, monitorisee.
+
+## Checklist
+- [ ] DNS est configure avec TTL raisonnable (300s pour APEX, 60s pour failover) — pas de TTL de 86400s
+- [ ] TLS >= 1.2 partout, TLS 1.3 pour les services internes — pas de TLS 1.0/1.1, pas de SSL
+- [ ] Les certificats sont auto-renouveles (LetsEncrypt, cert-manager, ACM) — pas d'expiration surprise
+- [ ] Firewall : seuls les ports necessaires sont ouverts. SSH (22) restreint par IP source
+- [ ] Les VPC/VNET sont isoles par environnement (dev/staging/prod) avec peering explicite
+- [ ] HTTP/2 ou HTTP/3 active — multiplexing, header compression, 0-RTT
+- [ ] Le load balancer a un health check actif (pas juste TCP connect — verifier le endpoint)
+
+## Anti-patterns
+### "C'est un probleme reseau"
+**Ce qu'on voit :** chaque bug de connexion est blame sur "le reseau". Personne ne debug. Le probleme persiste 3 semaines.
+**Pourquoi c'est dangereux :** le reseau est un bouc emissaire facile parce qu'il est invisible. En realite, la plupart des problemes "reseau" sont des problemes d'application : timeout trop court, DNS cache, certificat expire, mauvais endpoint. Dire "c'est le reseau" sans preuve = arreter de chercher.
+**Faire plutot :** debug methodique : `dig` (DNS), `curl -v` (TLS + HTTP), `traceroute` (routage), `telnet host port` (connectivite brute). Chaque couche se teste independamment. Le probleme est toujours sur UNE couche specifique.
+
+### Firewall = apres coup
+**Ce qu'on voit :** le firewall est configure "quand tout marche" (jamais). Tous les ports sont ouverts "pour pas etre bloque".
+**Pourquoi c'est dangereux :** le firewall est la premiere ligne de defense. Sans regles strictes, une application vulnerable sur un port oublie = acces non autorise. Le firewall interne (entre services) est aussi important que l'externe.
+**Faire plutot :** deny-all par defaut. Ouvrir uniquement les flux documentes. Chaque regle a un commentaire (pourquoi ce port, pour quel service). Revue trimestrielle des regles.
+
+### DNS comme apres-pensee
+**Ce qu'on voit :** TTL = 86400 (24h). Changement de serveur → 24h de propagation. Les utilisateurs voient l'ancienne IP. Ou pire : `CNAME` court-circuite avec un `A` record parce que "c'est plus simple".
+**Pourquoi c'est dangereux :** DNS est le premier maillon de toute connexion. Un TTL trop long empeche le failover rapide. Un mauvais enregistrement = outage total. Le DNS est la fondation — tout repose dessus.
+**Faire plutot :** TTL courts pour les endpoints critiques (60-300s). Records A/AAAA pour la racine, CNAME pour les sous-domaines. Monitoring de resolution DNS depuis plusieurs points geographiques.
+
+## Patterns
+### Defense en profondeur reseau
+**Quand :** architecture multi-services.
+**Comment :** WAF/CDN (couche 1) → Load Balancer + TLS termination (couche 2) → Network ACL/VPC firewall (couche 3) → Security Group par service (couche 4). Chaque couche suppose que la precedente a echoue. Aucune couche ne fait confiance a la precedente.
+
+### Zero Trust networking
+**Quand :** services distribues, multi-cloud, ou travailleurs distants.
+**Comment :** pas de "reseau interne de confiance". Chaque appel est authentifie (mTLS, JWT, SPIFFE). Le reseau est hostile par defaut — les services ne se font pas plus confiance entre eux qu'a Internet. C'est le principe inverse du "perimetre de securite".

package/assets/.claude/skills/nosql/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: nosql
+description: "NoSQL — MongoDB/DynamoDB/Redis, modeling around access patterns, single-table design, hot partition avoidance. À charger quand on choisit ou utilise du NoSQL."
+---
+
+# NoSQL
+
+**Principe premier :** NoSQL n'est pas "SQL sans schéma" — c'est un trade-off fondamental : tu échanges la flexibilité des requêtes (tu ne peux pas tout JOINer) contre la scalabilité horizontale (tu peux sharder). Ce trade-off est le SEUL critère valide pour choisir NoSQL. Si tu n'as pas de problème de scale horizontal que SQL ne résout pas, NoSQL est un downgrade, pas une modernisation. Le modeling NoSQL se fait à l'envers du relationnel : tu pars des requêtes (qu'est-ce que je dois lire en une opération ?) et tu construis le modèle autour.
+
+## Checklist
+- [ ] Le choix NoSQL est justifié par le scale horizontal, pas par "c'est plus simple"
+- [ ] Le modèle de données est conçu autour des access patterns (et pas l'inverse)
+- [ ] La partition key a une haute cardinalité et une distribution uniforme
+- [ ] Les index secondaires (GSI) sont justifiés — chaque GSI coûte de l'argent et de la latence
+- [ ] La stratégie de dénormalisation est documentée : quelle donnée est dupliquée, où, pourquoi
+- [ ] Les TTL sont configurés pour les données temporaires — pas de job de nettoyage manuel
+
+## Anti-patterns
+### Modélisation relationnelle dans NoSQL
+**Ce qu'on voit :** 12 `$lookup` (MongoDB) pour reproduire un JOIN. 50 `GetItem` séquentiels (DynamoDB) parce que les données sont dans des items séparés.
+**Pourquoi c'est dangereux :** NoSQL n'est pas optimisé pour les JOINs. Chaque `$lookup` est un scan coûteux. Chaque `GetItem` est une requête réseau. 50 requêtes séquentielles DynamoDB = 500ms de latence minimum contre 10ms pour un JOIN SQL. Tu paies le prix du NoSQL sans le bénéfice.
+**Faire plutôt :** pre-joindre. Si les données sont lues ensemble, elles sont stockées ensemble (single document/item). Le modèle reflète les patterns d'accès — une requête = un read.
+
+### Hot partition / hot key
+**Ce qu'on voit :** partition key = `status` avec 90% des items à `status = "active"`. Ou pire, partition key = `tenant_id` et un tenant fait 80% du trafic.
+**Pourquoi c'est dangereux :** en NoSQL, les partitions sont l'unité de scale. Une partition chaude = tout le trafic sur un seul shard = throttling (DynamoDB) ou performance dégradée (MongoDB). Le scale horizontal est neutralisé par une mauvaise clé.
+**Faire plutôt :** partition key à haute cardinalité et distribution uniforme. `user_id`, `order_id`, pas de `status` ou `type`. Si un tenant est plus gros, sharder par `tenant_id#entity_id` (composite key).
+
+### Redis comme source de vérité
+**Ce qu'on voit :** toutes les données métier dans Redis. `FLUSHALL` ou reboot = toutes les données perdues. "Mais j'ai configuré la persistence" — qui n'a jamais été testée.
+**Pourquoi c'est dangereux :** Redis est conçu comme un cache/queue/session store en mémoire. La persistence Redis (RDB/AOF) est asynchrone et non garantie. Même avec AOF everysec, tu peux perdre les 2 dernières secondes d'écritures.
+**Faire plutôt :** PostgreSQL/MySQL/DynamoDB pour la source de vérité. Redis pour cache, sessions, rate limiting, queues temporaires. Si Redis est flush, l'app dégrade mais ne perd pas de données métier.
+
+## Patterns
+### Single-table design (DynamoDB)
+**Quand :** plusieurs types d'entités avec des access patterns différents.
+**Comment :** une table. PK = `TYPE#id`, SK = `RELATION#id`. Les GSI inversent PK/SK pour les autres patterns. Un user et ses orders sont dans la même table, lus en une query. Pas de JOIN.
+
+### TTL index
+**Quand :** données temporaires (sessions, cache, logs éphémères).
+**Comment :** champ `expires_at` en epoch seconds + TTL index. La DB supprime automatiquement. Pas de cron job. Pas de nettoyage manuel. Gratuit (DynamoDB) ou quasi-gratuit.

package/assets/.claude/skills/oop-solid/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: oop-solid
+description: "OOP & SOLID — classes, objets, heritage, composition, encapsulation, principes SOLID comme garde-fous. A charger quand on travaille avec des classes."
+---
+
+# OOP & SOLID
+
+**Principe premier :** SOLID n'est pas un dogme — c'est un systeme d'alerte precoce. Chaque principe ne te dit pas quoi faire, il te dit QUAND le design est en train de pourrir. Single Responsibility = ta classe a plus d'une raison de changer. Open/Closed = tu modifies du code existant au lieu d'etendre. Liskov = ta sous-classe ne peut pas remplacer la classe mere. Interface Segregation = tes clients dependent d'interfaces qu'ils n'utilisent pas. Dependency Inversion = tes modules de haut niveau dependent des bas niveau. Le but n'est pas un score SOLID parfait — c'est un code qui accepte le changement sans se briser. La composition est par defaut, l'heritage est l'exception.
+
+## Checklist
+- [ ] Chaque classe a une responsabilite unique (SRP) — decrire son job en une phrase sans "et"
+- [ ] Les classes sont ouvertes a l'extension, fermees a la modification (OCP) — nouveau comportement = nouveau code, pas modification
+- [ ] Les sous-classes sont substituables a leur classe mere (LSP) — pas de `if (obj instanceof SpecialCase)`
+- [ ] Les interfaces sont minimales (ISP) — pas d'interface de 15 methodes dont 10 jettent `NotImplementedException`
+- [ ] Les modules haut niveau ne dependent pas des bas niveau (DIP) — les deux dependent d'abstractions
+- [ ] L'heritage est utilise pour "est-un", pas pour reutiliser du code — composition > heritage
+- [ ] Le couplage est reduit : un changement dans une classe ne force pas une cascade de changements
+
+## Anti-patterns
+### SOLID comme religion
+**Ce qu'on voit :** chaque classe est precedee de `interface IFoo`. Chaque `new` est remplace par une factory + DI container. 50 classes pour afficher "Hello World".
+**Pourquoi c'est dangereux :** SOLID utilise en dogme produit l'inverse de son intention : code rigide, difficile a changer, difficile a comprendre. Une interface pour chaque classe = explosion du nombre de fichiers. DI partout = perdu dans les couches d'indirection.
+**Faire plutot :** appliquer SOLID la ou le changement est PROBABLE. Un composant stable peut violer SOLID — c'est acceptable. Introduire une abstraction quand un deuxieme cas concret apparait (pas avant). SOLID est un outil de diagnostic, pas un objectif de design.
+
+### Heritage deep chain
+**Ce qu'on voit :** `Animal → Mammal → Canine → Dog → Labrador → GoldenLabrador`. Chaque classe ajoute un comportement. Pour comprendre `GoldenLabrador`, il faut lire 6 classes.
+**Pourquoi c'est dangereux :** l'heritage profond cree un couplage vertical. Changer `Animal` affecte toutes les 200 sous-classes. Impossible de comprendre une classe isolement. Le YAGNI frappe fort : la plupart des classes intermediaires ne sont jamais utilisees directement.
+**Faire plutot :** limiter a 1-2 niveaux d'heritage maximum. Composer les comportements (Strategy, Decorator) plutot qu'heriter. Si une classe a plus de 2 ancetres concrets, repenser le design.
+
+### Classe "Manager" / "Utils" / "Helper"
+**Ce qu'on voit :** `UserManager` (3000 lignes), `DateUtils` (150 fonctions statiques), `StringHelper` (tout le monde ajoute des trucs).
+**Pourquoi c'est dangereux :** les noms en -Manager, -Utils, -Helper sont des aveux d'echec de design. Ils ne disent rien sur ce que fait la classe. Ils attirent le code non relie comme un aimant. Une classe qui s'appelle `Manager` n'a pas de responsabilite — elle en a 50.
+**Faire plutot :** nommer les classes par leur responsabilite reelle. `UserRepository`, `UserAuthenticator`, `UserNotificationSender`. Si une classe a plus de 10 methodes publiques, la splitter par responsabilite. Les "utils" sont un signe qu'un concept manque dans le domaine.
+
+## Patterns
+### Composition over inheritance
+**Quand :** quasi tout le temps.
+**Comment :** au lieu de `class Duck extends Bird extends Animal`, injecter les comportements : `class Duck { constructor(flyBehavior, quackBehavior, swimBehavior) }`. Chaque comportement est interchangeable. Testable independamment. Le duck peut changer de FlyBehavior au runtime.
+
+### Dependency injection par constructeur
+**Quand :** toute classe qui depend d'un service externe (DB, API, file system).
+**Comment :** `constructor(db: Database, logger: Logger)` — les dependances sont explicites. Pas de `new Database()` dans la classe. Pas de singleton global (`Database.getInstance()`). Le test peut injecter un mock/adaptateur. La classe ne sait pas CREER ses dependances, elle les RECOIT.

package/assets/.claude/skills/performance/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: performance
+description: "Performance — mesurer avant d'optimiser, P95 > moyenne, performance budgets, profiling, N+1, slow queries. À charger quand on parle d'optimisation."
+---
+
+# Performance
+
+**Principe premier :** "Make it work, make it right, make it fast" — dans cet ordre. La performance est une feature, pas une propriété magique. Comme toute feature, elle a un coût et doit être mesurée. Le piège classique est l'optimisation prématurée : du code complexe et illisible pour gagner 5ms sur un endpoint appelé 10×/jour. La règle d'or : ne jamais optimiser sans avoir mesuré. Le bottleneck réel n'est presque jamais là où on pense. Et la métrique qui compte n'est pas la moyenne — c'est le P95 (ou P99). La moyenne ment parce qu'elle cache les outliers, et ce sont les outliers qui pourrissent l'expérience utilisateur.
+
+## Checklist
+- [ ] Profiling AVANT optimisation — jamais d'optimisation sur une intuition
+- [ ] Métriques RED par endpoint : Rate, Errors, Duration (P50, P95, P99)
+- [ ] Les requêtes N+1 sont identifiées et résolues (eager loading, batch, JOIN)
+- [ ] Performance budget dans la CI : JS < 200KB, LCP < 2.5s, P95 < 500ms
+- [ ] Les requêtes lentes sont loguées (> 100ms) avec EXPLAIN automatique
+- [ ] Cache en place avec TTL explicite — pas de calcul redondant sur la hot path
+
+## Anti-patterns
+### Optimisation prématurée
+**Ce qu'on voit :** micro-optimisations de boucles, bit-shifting, allocation pooling — sur un endpoint appelé 100×/jour. Le code est devenu illisible pour gagner 2ms.
+**Pourquoi c'est dangereux :** l'optimisation prématurée a un double coût : le code devient plus dur à maintenir, et le temps passé à optimiser n'est pas passé sur des vrais problèmes. Pire : l'optimisation cible souvent le mauvais endroit parce qu'elle est basée sur l'intuition, pas sur la mesure.
+**Faire plutôt :** "Make it work, make it right, make it fast." Mesurer. Profiler. Identifier le vrai bottleneck (souvent une requête DB, pas une boucle). Optimiser là où le profiling montre un gain. Si le gain est < 10%, se demander si la complexité ajoutée le justifie.
+
+### Optimiser la moyenne
+**Ce qu'on voit :** "la latence moyenne est de 200ms, c'est bon." Le P95 est à 8 secondes — 5% des utilisateurs attendent 8 secondes. Mais la moyenne est belle.
+**Pourquoi c'est dangereux :** la moyenne est insensible aux outliers. 95% des requêtes à 50ms + 5% à 10s = moyenne de ~550ms. Tu regardes 550ms et tu penses "acceptable". Mais 5% de tes utilisateurs ont une expérience exécrable. Les percentiles existent pour cette raison précise.
+**Faire plutôt :** P50 (médiane), P95, P99. Le P95 est l'expérience "normale dans le pire cas". Le P99 est l'expérience "vraiment mauvaise". Alerter et optimiser sur les percentiles, pas sur la moyenne.
+
+### Cache sans stratégie
+**Ce qu'on voit :** `cache.set(key, data)` sans TTL. Le cache garde des données stales indéfiniment. Ou pire : le cache est invalidé à chaque écriture mais jamais rechargé (cache toujours vide).
+**Pourquoi c'est dangereux :** un cache mal conçu est pire que pas de cache — il ajoute de la latence (aller-retour Redis) pour servir des données périmées ou pour ne jamais avoir de hit. Le hit rate est la métrique qui dit si ton cache sert à quelque chose.
+**Faire plutôt :** TTL explicite basé sur la fraîcheur acceptable. Surveiller le hit rate — si < 50%, le cache est probablement mal configuré. Cache-aside pour les lectures, write-through pour les lectures après écriture.
+
+## Patterns
+### Performance budget
+**Quand :** application web ou mobile.
+**Comment :** définir des seuils dans la CI. JS bundle < 200KB, page weight < 1MB, LCP < 2.5s, TTI < 3s, P95 API < 500ms. Si la PR dépasse, bloquer. Le budget force la discipline — comme un budget financier, tu ne peux pas ajouter sans enlever ailleurs.
+
+### Slow query monitoring
+**Quand :** toute application avec une base de données.
+**Comment :** loguer toute requête > 100ms avec son EXPLAIN ANALYZE. Dashboard des slow queries. Alerte si une nouvelle slow query apparaît (requête qui était rapide avant, lente maintenant = probablement un index ou un volume de données). Chaque slow query est un ticket.

package/assets/.claude/skills/reactive/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: reactive
+description: "Programmation Reactive — observables, streams, RxJS, backpressure, event sourcing, flux de donnees. A charger quand on utilise un paradigme reactif ou des streams."
+---
+
+# Programmation Reactive
+
+**Principe premier :** La programmation reactive n'est pas "utiliser RxJS" — c'est traiter les donnees comme un flux continu plutot que comme des valeurs ponctuelles. Dans un modele imperatif, tu demandes la valeur (`let x = getValue()`). Dans un modele reactif, tu t'abonnes au changement (`stream.subscribe(x => ...)`). La difference fondamentale : le code reactif se declare une fois et reagit a N evenements, le code imperatif repond a chaque evenement individuellement. Le piege : la complexite explose avec le nombre de streams. Sans gestion de la backpressure (producteur plus rapide que le consommateur) et du cycle de vie (unsubscribe), les streams deviennent une source de fuites memoire et de bugs subtils.
+
+## Checklist
+- [ ] Les streams sont unsubscribed proprement (`takeUntil`, `async pipe`, `DisposeBag`) — zero fuite memoire
+- [ ] La backpressure est geree : le consommateur controle le debit (`buffer`, `throttle`, `sample`, `request(n)`)
+- [ ] Les operateurs sont composees en pipeline lisible — pas de callback hell reactive
+- [ ] Les erreurs sont propagees dans le stream — pas de `try/catch` autour de `.subscribe()`
+- [ ] Les streams partages sont multicastes (`share`, `shareReplay`) — pas de side effect par souscripteur
+- [ ] Les valeurs initiales sont definies (`BehaviorSubject`, `startsWith`) — pas de "le stream emet dans 5 secondes"
+- [ ] Le debounce/throttle est utilise pour les evenements frequents (input utilisateur, scroll) — pas de traitement par frappe
+
+## Anti-patterns
+### Nested subscribes
+**Ce qu'on voit :** `stream1.subscribe(x => { stream2.subscribe(y => { stream3.subscribe(z => { doSomething(x,y,z) }) }) })`. Trois niveaux de souscriptions imbriquees.
+**Pourquoi c'est dangereux :** c'est le callback hell version reactive. Chaque subscribe est un effet de bord. Impossible de unsubcribe proprement. La gestion d'erreur est cassee. Si `stream1` emet pendant que `stream2` n'a pas fini → race condition. Le code est illisible et indetachable.
+**Faire plutot :** `combineLatest([stream1, stream2, stream3]).pipe(takeUntil(destroy$)).subscribe(([x,y,z]) => doSomething(x,y,z))`. Un seul subscribe. Flat/compose, never nest.
+
+### Pas de gestion de backpressure
+**Ce qu'on voit :** un stream de clics souris a 1000 events/s. Le consommateur traite chaque event (appel API). La file d'attente memoire explose.
+**Pourquoi c'est dangereux :** le producteur et le consommateur ont des vitesses differentes. Sans backpressure, le consommateur est inonde. Memoire → ∞. L'app freeze. Le comportement est non deterministe (depend de la charge).
+**Faire plutot :** `sampleTime(200)` (prendre un event toutes les 200ms), `debounceTime(300)` (attendre 300ms de silence), `throttleTime(500)` (max 1 emission toutes les 500ms). Le consommateur controle le debit, pas le producteur.
+
+### RxJS partout
+**Ce qu'on voit :** tout est un observable. `Observable.of(42)`, `Observable.from([1,2,3])`. Même les valeurs synchrones passent par des streams.
+**Pourquoi c'est dangereux :** la programmation reactive ajoute de la complexite cognitive et un surcout de performance. Pour des donnees synchrones (un tableau, une variable), un observable est un marteau-piqueur pour ouvrir une noix. Le code devient plus dur a lire sans benefice.
+**Faire plutot :** utiliser les observables la ou l'asynchronisme et le temps sont intrinseques : evenements utilisateur, websockets, reponses serveur, timers. Pour le synchrone, les structures de donnees normales suffisent.
+
+## Patterns
+### takeUntil pour le cleanup
+**Quand :** tout abonnement qui a une duree de vie < l'application (composant Angular, ecran React).
+**Comment :** `destroy$ = new Subject<void>()`. Tous les pipelines se terminent par `.pipe(takeUntil(this.destroy$))`. Dans `ngOnDestroy` / `useEffect` cleanup : `this.destroy$.next(); this.destroy$.complete()`. Tous les abonnements sont nettoyes en une ligne.
+
+### Event bus central
+**Quand :** communication entre composants non relies (pas de parent-enfant).
+**Comment :** un `Subject` ou `EventEmitter` partage. Les producteurs emettent, les consommateurs souscrivent. Chaque message est un type specifique (pas de `any`). Le bus est mockable en test. Alternative a Redux pour les cas simples ou la communication est le seul besoin.

package/assets/.claude/skills/release-management/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: release-management
+description: "Release Management — releases as contracts, semver as communication, pre-release channels (alpha/beta/rc), signed provenance, changelog as consumer signal. À charger quand on prépare une release."
+---
+
+# Release Management
+
+**Principe premier :** Une release est un contrat avec les consommateurs. Le numéro de version n'est pas un compteur — c'est un signal. MAJOR veut dire "tu dois migrer, voici comment". MINOR veut dire "nouveau, sans risque, upgrade". PATCH veut dire "sécurité ou bug, fais-le maintenant". Si tes numéros de version ne communiquent pas ça, ils ne servent à rien. Le changelog est la partie visible de ce contrat — sans lui, les consommateurs ne savent pas ce qui a changé et n'upgraderont pas.
+
+## Checklist
+- [ ] La version suit semver strict : MAJOR (breaking API), MINOR (nouveau compatible), PATCH (bug/security)
+- [ ] Chaque breaking change a un guide de migration (pas juste "changed X" — quoi changer, ligne par ligne)
+- [ ] Des pre-release channels existent : alpha (instable, dev), beta (feature-complete, testable), rc (release candidate, plus de bugs connus)
+- [ ] Le changelog est lisible par un humain — pas un dump de commits, pas de jargon interne
+- [ ] Les artefacts sont signés ET vérifiables (Cosign/Sigstore, checksums SHA256, SBOM)
+- [ ] Le tag Git est signé ET correspond exactement au commit du build (pas de tag après coup)
+- [ ] Les releases sont immutables — jamais de repush d'un tag, jamais de republish d'un package
+
+## Anti-patterns
+### Version bloquée
+**Ce qu'on voit :** `"version": "1.0.0"` dans package.json depuis 2 ans. 47 commits, des breaking changes, des nouvelles features — la version n'a jamais bougé.
+**Pourquoi c'est dangereux :** la version ne communique plus rien. Les consommateurs ne savent pas s'ils peuvent upgrade. Certains pinent au commit, d'autres prennent `latest` et cassent. Le projet perd la confiance de son écosystème.
+**Faire plutôt :** version bump à chaque release. Automatiser via conventional commits + semantic-release. Chaque merge sur main → version calculée → changelog mis à jour → release. Zéro intervention humaine.
+
+### Changelog = dump de commits
+**Ce qu'on voit :** CHANGELOG.md copié-collé depuis `git log --oneline`. "fix: bug", "wip", "cleanup", "fix test" — l'utilisateur ne comprend rien.
+**Pourquoi c'est dangereux :** un changelog illisible est pire qu'inexistant. Il donne l'illusion d'information. Le consommateur doit lire le diff pour comprendre ce qui a changé — exactement ce que le changelog devait éviter.
+**Faire plutôt :** changelog structuré : Added, Changed, Deprecated, Removed, Fixed, Security. Chaque entrée est une phrase compréhensible par un utilisateur du projet. Le changelog répond à : "Qu'est-ce que je dois faire pour upgrade ?"
+
+### Pre-release sauté
+**Ce qu'on voit :** `1.0.0-alpha.1` existe, puis directement `1.0.0`. Pas de beta, pas de RC. 6 mois entre alpha et stable.
+**Pourquoi c'est dangereux :** les early adopters sont punis. Ils testent l'alpha, trouvent des bugs, mais n'ont jamais de version stable de leurs retours. Ils arrêtent de tester les pre-releases. La release stable sort sans validation réelle.
+**Faire plutôt :** pipeline de maturité : alpha (semaine 1, cassant) → beta (semaine 2-3, testable, feedback) → rc (semaine 4, gel, uniquement bugfixes) → stable. Chaque étape a des consommateurs différents : devs internes → early adopters → tout le monde.
+
+### Artefact mutable
+**Ce qu'on voit :** `npm publish` puis `npm publish` à nouveau sur la même version parce que "j'ai oublié un fichier". Ou `git tag -d v1.2.3 && git tag v1.2.3`.
+**Pourquoi c'est dangereux :** un artefact mutable détruit la reproductibilité. Le hash que tu as vérifié hier n'est plus valide aujourd'hui. Impossible de faire un audit. Les mirrors de registre ont des versions différentes. C'est un cauchemar de debugging.
+**Faire plutôt :** une version = un artefact = un hash, pour toujours. Si bug → nouvelle version (1.2.4, pas 1.2.3 repush). La plupart des registres permettent de "deprecate" sans "unpublish".
+
+## Patterns
+### Conventional Commits → release automatisée
+**Quand :** tout projet avec plus d'un mainteneur.
+**Comment :** `feat:` → MINOR bump, `fix:` → PATCH bump, `feat!:` ou `BREAKING CHANGE:` → MAJOR bump. `semantic-release` lit l'historique de commits depuis la dernière release, calcule la version, génère le changelog, publie. Configuré une fois, oublié.
+
+### Pre-release channels
+**Quand :** projet avec breaking changes fréquents ou base d'utilisateurs qui teste les versions beta.
+**Comment :** `1.0.0-alpha.1` → tags `alpha` instables. `1.0.0-beta.1` → tag `beta`, feature-complete. `1.0.0-rc.1` → tag `rc`, plus de bugs connus. `1.0.0` → tag `latest`. Les consommateurs choisissent leur niveau de risque : `npm install pkg@beta` ou `npm install pkg@latest`.
+
+### Migration guide
+**Quand :** tout MAJOR bump.
+**Comment :** un fichier `MIGRATION.md` ou section dans le changelog. Format : "Avant → Après" pour chaque breaking change. Exemple de code avant, exemple après. Pourquoi le changement a été fait (pas juste "changed"). Liste des choses à vérifier après migration.

package/assets/.claude/skills/research/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: research
+description: "Recherche web — stratégies de recherche, évaluation des sources, documentation officielle, issues GitHub, pertinence et fraîcheur de l'information. À charger avant toute recherche d'information externe."
+---
+
+# Recherche Web
+
+**Principe premier :** La qualité du code dépend de la qualité de l'information qui l'a inspiré. Une recherche bâclée produit du code basé sur des articles de blog obsolètes, des réponses StackOverflow sans contexte, ou pire — des hallucinations confondues avec des faits. La recherche est une compétence technique : savoir quoi chercher, où chercher, comment évaluer, et quand s'arrêter. Le but n'est pas de tout lire — c'est de trouver l'information la plus fiable et pertinente en un minimum de temps.
+
+## Hiérarchie des sources (par ordre de confiance)
+1. **Documentation officielle** — docs du framework/langage, spécifications, RFCs
+2. **Code source** — le code est la documentation ultime, il ne ment jamais
+3. **Changelogs / release notes** — pour les changements de comportement entre versions
+4. **Issues GitHub officielles** — bugs connus, discussions de design, workarounds
+5. **StackOverflow / forums** — uniquement si la réponse a > 10 votes et date de < 2 ans
+6. **Articles de blog / Medium** — uniquement de la part de mainteneurs officiels ou experts reconnus
+7. **LLM / connaissances internes** — dernier recours, toujours vérifier avec une source primaire
+
+## Checklist
+- [ ] La recherche part d'une source officielle (pas d'un blog ou d'une réponse StackOverflow)
+- [ ] La version de la doc correspond à la version utilisée dans le projet (pas de doc v2 pour un projet en v1)
+- [ ] Au moins deux sources indépendantes confirment une information critique (pas de single-source confirmation)
+- [ ] Les issues GitHub sont vérifiées : open vs closed, date de dernière activité, lien à un PR de fix
+- [ ] Pour un bug : l'issue a été reproduite par quelqu'un d'autre, pas juste signalée
+- [ ] Pour une solution : le PR qui la contient est mergé et released, pas juste proposé
+- [ ] La fraîcheur est évaluée : < 6 mois (excellent), < 2 ans (bon), > 2 ans (vérifier si toujours valide)
+
+## Anti-patterns
+### Première page Google = vérité
+**Ce qu'on voit :** recherche Google, premier lien (souvent un blog), copie de la solution sans vérifier qui l'a écrite ni quand.
+**Pourquoi c'est dangereux :** le SEO n'est pas un indicateur de qualité. Les articles de blog optimisés SEO sont souvent écrits par des juniors qui reproduisent ce qu'ils ont vu ailleurs (cargo cult). La solution peut être obsolète, incorrecte, ou dangereuse. Le pire : elle peut marcher dans le cas simple mais échouer silencieusement en production.
+**Faire plutôt :** commencer par la documentation officielle. Le site de doc du framework a un search — l'utiliser. Si Google est nécessaire, ajouter `site:docs.official.com` ou `site:github.com/org/repo/issues`. Filtrer par date (< 1 an). Croiser avec une deuxième source avant d'adopter.
+
+### Solution StackOverflow sans contexte
+**Ce qu'on voit :** copier-coller une réponse StackOverflow acceptée sans lire la question complète, les commentaires, ou les autres réponses.
+**Pourquoi c'est dangereux :** la réponse acceptée n'est pas toujours la meilleure — c'est celle qui a résolu le problème de l'OP. Le contexte peut être différent (version différente, contrainte différente). Les commentaires contiennent souvent des corrections critiques ("this breaks in v3", "deprecated since...").
+**Faire plutôt :** lire la question complète (même contexte ?), les 2-3 réponses les plus votées (pas juste l'acceptée), les commentaires sous chaque réponse (corrections, mises en garde), et vérifier la date. Une réponse de 2015 peut être dangereuse en 2026.
+
+### Hallucination de documentation
+**Ce qu'on voit :** le LLM affirme qu'une API existe avec certaines options. Pas de vérification. Le code est écrit avec une API inexistante.
+**Pourquoi c'est dangereux :** les LLMs mélangent les versions, inventent des paramètres plausibles, et confondent les frameworks similaires (React 17 vs 19, Python 2 vs 3, Express vs Fastify). L'information inventée est souvent syntaxiquement correcte mais sémantiquement fausse — le compilateur ne la détecte pas.
+**Faire plutôt :** toute API utilisée pour la première fois doit être vérifiée dans la doc officielle. Si le LLM dit `fetch(url, { retries: 3 })` — vérifier que `retries` existe vraiment dans l'API fetch. Ne jamais faire confiance à un nom de paramètre ou une signature de fonction sans vérification.
+
+### Ignorer les issues fermées
+**Ce qu'on voit :** on cherche un bug, on trouve une issue ouverte qui décrit le même problème. On s'arrête là. Mais l'issue fermée #1452 contenait la vraie solution, mergée il y a 3 semaines.
+**Pourquoi c'est dangereux :** les issues fermées contiennent les solutions. Les issues ouvertes contiennent les problèmes. Chercher seulement les ouvertes = ignorer tout ce qui a déjà été résolu. Le bug que tu rencontres a peut-être déjà un fix dans la dernière release.
+**Faire plutôt :** toujours chercher les issues fermées ET ouvertes. Une issue fermée avec un PR lié → lire le PR, vérifier dans quelle release il est inclus. Une issue fermée sans PR → lire pourquoi (wontfix ? duplicate ?). Les issues fermées récemment (< 1 mois) sont des mines d'or.
+
+### Single-source confirmation
+**Ce qu'on voit :** une information critique (auth, sécurité, migration) est confirmée par UNE seule source. Pas de vérification croisée.
+**Pourquoi c'est dangereux :** une source peut se tromper. Si la seule source qui dit "cette migration est safe" est un commentaire GitHub de 2019 avec 2 pouces, c'est un pari, pas une vérification.
+**Faire plutôt :** règle des deux sources pour toute information critique. La doc officielle + une issue GitHub. Ou le code source + les tests. Si les sources se contredisent → la doc officielle et le code source priment. Toujours documenter quelle source a confirmé quoi.
+
+## Patterns
+### Stratégie de recherche par couches
+**Quand :** toute tâche qui demande des connaissances externes.
+**Comment :** Couche 1 : doc officielle (site:docs.X.com). Couche 2 : issues GitHub (site:github.com/org/repo/issues). Couche 3 : StackOverflow si et seulement si les deux premières n'ont pas donné de réponse. Chaque couche plus large = confiance plus faible. Arrêter dès qu'une source fiable confirme.
+
+### Vérification de version
+**Quand :** toute lecture de documentation.
+**Comment :** vérifier la version affichée en haut de la page de doc (souvent un dropdown). Comparer avec la version installée (`package.json`, `go.mod`, `Cargo.toml`). Si la doc est en v3 et le projet en v1 → chercher la doc v1 (URL avec `/v1/` ou switcher dans l'UI). Les breaking changes entre versions sont la cause #1 de "pourtant la doc dit que ça marche".
+
+### Évaluation d'issue GitHub
+**Quand :** on lit une issue GitHub pour décider d'une action.
+**Comment :** Checker : (1) statut (open/closed), (2) date de dernière activité (récent = actif), (3) nombre de participants (plusieurs personnes = problème réel), (4) PRs liés (un PR merged = solution disponible), (5) milestones (incluse dans une release ?). Une issue avec 50 commentaires, fermée, avec un PR merged dans la release v2.3 → solution confirmée. Une issue avec 2 commentaires, ouverte depuis 2 ans → probablement pas prioritaire.
+
+### Croisement de sources
+**Quand :** information critique (sécurité, breaking change, deprecation).
+**Comment :** trouver au moins deux sources indépendantes. Exemples de paires valides : doc officielle + changelog, code source + test, issue GitHub + PR mergé. Une paire invalide : deux articles de blog qui citent la même source. Noter les sources dans un commentaire du code ou du PR pour que le prochain développeur sache pourquoi cette décision a été prise.

package/assets/.claude/skills/resilience/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: resilience
+description: "Resilience — circuit breakers, retry with backoff, timeouts, bulkheads, graceful degradation. À charger quand on rend un système tolérant aux pannes."
+---
+
+# Resilience
+
+**Principe premier :** La résilience n'est pas "gérer les erreurs" — c'est concevoir le système pour qu'il continue à fonctionner (même en mode dégradé) quand ses dépendances tombent. Chaque dépendance externe va tomber un jour. La question n'est pas "est-ce que Redis est fiable ?" mais "que fait mon application quand Redis est down ?". Le circuit breaker n'est pas un pattern — c'est un réflexe : ne pas continuer à appeler un service qui ne répond pas.
+
+## Checklist
+- [ ] Timeouts explicites sur tout appel externe : connect < 2s, read < 5s, request < 10s
+- [ ] Circuit breaker sur chaque dépendance : échecs > N → circuit OPEN → fast fail
+- [ ] Retry avec backoff exponentiel + jitter — pas de retry immédiat, max 3-5 tentatives
+- [ ] Bulkhead : pools de connexions séparés par client/type de requête
+- [ ] Fallback défini pour chaque point de défaillance : cache, defaults, degraded mode
+- [ ] Chaos engineering : tester la résilience en production, pas en théorie
+
+## Anti-patterns
+### Retry sans backoff
+**Ce qu'on voit :** `while (!ok) { try { call(); ok = true; } catch {} }` — retry immédiat en boucle.
+**Pourquoi c'est dangereux :** thundering herd. Le service en difficulté reçoit 1000× plus de requêtes à cause des retries. L'incident s'aggrave. Un retry immédiat est une attaque DDoS contre soi-même.
+**Faire plutôt :** backoff exponentiel avec jitter. 1s → 2s → 4s → 8s, max 5 tentatives. Le jitter (aléatoire ±25%) empêche la synchronisation des retries de tous les clients.
+
+### Pas de fallback
+**Ce qu'on voit :** si Redis est down → 500 Internal Server Error. Le cache est devenu un point de défaillance unique.
+**Pourquoi c'est dangereux :** une dépendance non-critique (cache, analytics, recommandations) fait tomber tout le service. Le client voit une erreur pour une fonctionnalité qui aurait pu fonctionner sans cette dépendance.
+**Faire plutôt :** si cache down → servir depuis la DB (plus lent mais fonctionnel). Si analytics down → logger localement et réessayer plus tard. Chaque dépendance a un fallback explicite.
+
+### Timeout = 60 secondes
+**Ce qu'on voit :** `http.get(url, { timeout: 60000 })`. L'utilisateur attend 60s.
+**Pourquoi c'est dangereux :** les threads/workers sont bloqués. Le pool s'épuise. L'app devient non-réactive. Un timeout trop long transforme une défaillance partielle en outage total.
+**Faire plutôt :** timeouts agressifs. Connect < 2s, read < 5s. L'utilisateur préfère un échec rapide qu'une attente infinie. Fast fail > slow timeout.
+
+## Patterns
+### Circuit Breaker
+**Quand :** toute communication avec une dépendance externe.
+**Comment :** CLOSED (normal) → OPEN après N échecs consécutifs → HALF_OPEN après timeout → CLOSED si succes. En OPEN, les appels sont rejetés immédiatement (pas de tentative inutile).
+
+### Bulkhead
+**Quand :** ressources partagées entre différents appels/clients.
+**Comment :** pool de connexions séparé par client. Si un client sature son pool, les autres ne sont pas affectés. Comme les cloisons étanches d'un navire — une voie d'eau ne coule pas le bateau.