@neikyun/ciel 6.14.0 → 6.14.2

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

@@ -0,0 +1,42 @@
+---
+name: agile
+description: "Agile — Scrum, Kanban, Shape Up, sprints, estimation, retros, amelioration continue. A charger quand on travaille en mode agile."
+---
+
+# Agile
+
+**Principe premier :** L'agilite n'est pas un framework (Scrum n'est pas l'agilite) — c'est un principe : livrer de la valeur en petits increments, inspecter le resultat, et adapter le plan. Le manifeste agile a 4 valeurs, et la premiere est "les individus et leurs interactions plus que les processus et les outils". Si ton processus agile est plus important que les personnes qui l'utilisent, tu as echoue l'agilite. Le but du process n'est pas d'etre suivi — c'est de rendre l'equipe plus efficace. Un processus qui ralentit l'equipe n'est pas agile, meme s'il suit Scrum a la lettre. Le meilleur indicateur d'agilite : combien de temps entre "j'ai une idee" et "c'est en production" ?
+
+## Checklist
+- [ ] Les ceremonies sont cadrees : standup 15min, retro 1h, planning 1-2h — si plus long, le processus est casse
+- [ ] Les tickets sont INVEST : Independent, Negotiable, Valuable, Estimable, Small, Testable
+- [ ] Le WIP est limite (Kanban/Scrum avec capacite explicite) — pas plus de travail en cours que de capacite
+- [ ] Les retros produisent des actions concretes (pas "on communiquera mieux") — max 2-3 actions par retro
+- [ ] La velocite est utilisee pour le planning, pas pour le jugement de performance
+- [ ] Le backlog est priorise par valeur business, pas par "c'est facile" ou "c'est urgent depuis 6 mois"
+- [ ] Le cycle time (temps ticket ouvert → ferme) est mesure et s'ameliore — c'est le vrai KPI agile
+
+## Anti-patterns
+### Agile = Scrum = standups + sprints
+**Ce qu'on voit :** l'equipe fait des standups, des sprints de 2 semaines, et un retro. "On est agile." Les stories sont estimees en story points. Les sprints sont bookes a 110%. Rien n'est livre en production a la fin du sprint.
+**Pourquoi c'est dangereux :** c'est du theatre agile. Les ceremonies sont suivies mais l'objectif (livrer de la valeur rapidement) est manque. Le processus devient le produit. L'equipe est frustree ("l'agile c'est des reunions qui servent a rien") sans comprendre que le probleme n'est pas l'agilite, c'est l'imitation vide de l'agilite.
+**Faire plutot :** se demander POURQUOI on fait chaque ceremonie. Si le standup est un compte-rendu au manager, c'est foutu — le standup est pour que l'equipe se synchronise. Si la retro ne produit jamais d'actions, l'arreter. Moins de processus, plus de livraison. Commencer par Kanban (pas de sprint, flux continu) et ajouter des ceremonies seulement si le besoin emerge.
+
+### Story points = mesure de performance
+**Ce qu'on voit :** "tu as fait 8 points ce sprint, l'objectif est 13." Les story points deviennent un KPI individuel.
+**Pourquoi c'est dangereux :** les story points mesurent la complexite relative, pas la productivite. Les utiliser comme KPI = l'equipe gonfle les estimations. 1 point devient 3. La velocite augmente mais rien n'est livre plus vite. Culture de la peur et du gaming du systeme.
+**Faire plutot :** les story points servent UNIQUEMENT a la planification de sprint (combien de travail l'equipe peut absorber). La vraie metrique est le cycle time (combien de temps pour livrer) et le throughput (combien de tickets livres par semaine). Ces metriques ne sont pas gameables.
+
+### Retro = rituel vide
+**Ce qu'on voit :** "Qu'est-ce qui s'est bien passe ? Qu'est-ce qui s'est mal passe ?" Memes reponses depuis 6 mois : "la communication" et "les specs pas claires". Zero action concrete.
+**Pourquoi c'est dangereux :** une retro sans action est un signal que l'equipe est apprise a l'impuissance. Les problemes sont identifies mais jamais resolus. La retro devient une soupape ou on se plaint sans consequence — c'est pire que pas de retro car ca cree du cynisme.
+**Faire plutot :** chaque retro produit 1-2 actions concretes, assignees, avec deadline. La retro suivante commence par "est-ce que les actions de la derniere retro sont faites ?" Si non, pourquoi ? Si une action n'est jamais faite, le probleme n'est pas l'equipe — c'est que le systeme empeche l'amelioration.
+
+## Patterns
+### Kanban pour commencer
+**Quand :** equipe qui decouvre l'agilite ou qui a ete brulee par Scrum.
+**Comment :** visualiser le flux (colonnes To Do / In Progress / Done), limiter le WIP (max 2 taches par personne en In Progress), mesurer le cycle time. Pas de sprint, pas d'estimation obligatoire, pas de ceremonies forcees. Ajouter un standup uniquement si la synchro est necessaire. Iterer sur le processus a partir de la.
+
+### Cycle time comme North Star
+**Quand :** mesurer l'amelioration continue.
+**Comment :** cycle time = temps entre "le ticket est pret a developper" et "en production". Mesurer le P50 et P85 (pas la moyenne — les outliers faussent). Objectif : reduire le cycle time sans sacrifier la qualite. Un cycle time qui diminue = l'equipe s'ameliore VRAIMENT.

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

@@ -0,0 +1,55 @@
+---
+name: alerting
+description: "Alerting — SLO-based alerting, alert fatigue prevention, on-call, post-mortems, runbooks. A charger quand on configure des alertes."
+---
+
+# Alerting
+
+**Principe premier :** Une alerte qui ne declenche pas d'action n'est pas une alerte — c'est du bruit qui tue les vraies alertes. Chaque alerte doit etre : actionable (tu sais quoi faire), symptom-based (pas cause-based), et avoir un runbook. Si tu ne peux pas ecrire le runbook en < 5 etapes, ne cree pas l'alerte. Le but n'est pas d'etre notifie de tout — c'est d'etre notifie assez tot pour agir avant que les utilisateurs ne remarquent.
+
+## Checklist
+- [ ] Les alertes sont sur les symptomes (P95 > 1s, error rate > 1%), pas sur les causes (CPU > 70%)
+- [ ] Chaque alerte a un runbook — pas "on verra quand ca sonnera"
+- [ ] Les regles d'alerte et la config AlertManager sont dans le repo (alerting as code) — pas creees a la main
+- [ ] SLA de reponse defini : critical (page, < 5 min), high (page jour, < 30 min), medium (ticket, < 4h)
+- [ ] Alertes groupees et de-dupliquees — pas 50 pages pour la meme cause racine
+- [ ] On-call rotation documentee avec escalation — personne n'est on-call seul sans backup
+- [ ] Post-mortem blameless apres chaque incident majeur + 5 Whys jusqu'a la cause racine
+
+## Anti-patterns
+### Alerter sur tout
+**Ce qu'on voit :** "CPU > 70%", "memoire > 60%", "disque > 70%" — 200 alertes configurees. 15 pages par nuit. L'equipe a mute le canal.
+**Pourquoi c'est dangereux :** alert fatigue. Chaque fausse alerte entraine la suivante vers l'ignore. Quand la vraie alerte critique arrive, personne ne la voit. Le canal d'alerte est devenu un flux de bruit ignore.
+**Faire plutot :** alerter sur les symptomes utilisateur. "P95 latency > 1s pendant 5 min" (l'utilisateur ressent la lenteur). "Error rate > 1% pendant 5 min" (l'utilisateur voit des erreurs). Le CPU est une cause possible parmi 10, pas un symptome.
+
+### Alerte sans runbook
+**Ce qu'on voit :** alerte "PaymentService is down". Pas de runbook. L'on-call Googlise "comment restart payment service" a 3h du matin.
+**Pourquoi c'est dangereux :** MTTR explose. L'on-call stresse fait des erreurs. Le runbook est la difference entre "redemarrer en 2 minutes" et "aggraver l'incident en 30 minutes de debugging panique".
+**Faire plutot :** runbook attache a chaque alerte. Etapes concretes. "1. Verifier les logs dans Loki avec {service=payment, level=error}. 2. Si OOM -> restart le pod. 3. Si DB timeout -> verifier les connexions pool. 4. Si rien -> escalader a l'equipe backend. 5. Post-mortem avec 5 Whys dans les 48h."
+
+### Aucun post-mortem
+**Ce qu'on voit :** incident resolu -> "ouf, on passe a autre chose". Pas d'analyse. Le meme incident se reproduit 3 mois plus tard.
+**Pourquoi c'est dangereux :** sans post-mortem, l'organisation n'apprend pas. Les memes erreurs se repetent. Le but du post-mortem n'est pas de trouver un coupable — c'est d'identifier les failles du SYSTEME qui ont permis l'incident.
+**Faire plutot :** post-mortem blameless dans les 48h. Format : timeline, impact, 5 Whys jusqu'a la cause racine, what went well, what went wrong, action items. Les action items ont des owners et des deadlines.
+
+### Corriger le symptome, pas la cause racine
+**Ce qu'on voit :** le disque est plein -> on supprime des logs. Le disque se remplit 3 jours plus tard. Meme incident, meme reponse. 5 iterations avant de se demander POURQUOI.
+**Pourquoi c'est dangereux :** corriger le symptome sans trouver la cause racine garantit la recidive. Chaque recurrence erode la confiance. Le MTTR apparent est bas, le MTTR reel est infini (l'incident n'est jamais vraiment resolu).
+**Faire plutot :** methode des 5 Whys. "Le disque est plein" -> Pourquoi ? "Les logs font 50 Go/jour" -> Pourquoi ? "Level DEBUG active en prod" -> Pourquoi ? "Le deploiement a ecrase la config" -> Pourquoi ? "La config n'est pas versionnee" -> Action racine : versionner la config + alerter si disque > 80%. Le bug est le niveau DEBUG. La cause racine est l'absence d'IaC pour la config. On corrige la cause, pas le symptome.
+
+## Patterns
+### AlertManager (routing + dedup + silence)
+**Quand :** toute stack Prometheus en production.
+**Comment :** Prometheus evalue les rules -> alertes -> AlertManager. AlertManager groupe les alertes (`group_by: [service, severity]`), deduplique (meme alerte = une notification), silencie la maintenance (`matchers: [env=staging]`). Routes par severite : critical -> PagerDuty/Opsgenie, warning -> Slack. Config dans `monitoring/alertmanager.yml`, versionne dans le repo.
+
+### Alerting as Code (regles dans le repo)
+**Quand :** toute equipe de plus d'une personne.
+**Comment :** regles Prometheus (`monitoring/rules.yml`), config AlertManager (`monitoring/alertmanager.yml`), dashboards Grafana (`monitoring/dashboards/`) — tout dans le repo, versionne, deploye via CI/CD. Pas de regle creee a la main dans l'UI Grafana. Une PR pour chaque changement d'alerte — le seuil, le runbook_url, la severite sont revus comme du code.
+
+### Runbook integre a l'alerte
+**Quand :** chaque alerte creee.
+**Comment :** `annotations: { runbook_url: "https://wiki.corp/runbooks/payment-latency" }`. Le runbook contient : (1) ce que signifie l'alerte, (2) comment verifier dans Grafana/Loki/Tempo, (3) actions de mitigation, (4) qui escalader, (5) comment faire un 5 Whys si la mitigation ne suffit pas.
+
+### Post-mortem blameless + 5 Whys
+**Quand :** tout incident qui a declenche une alerte on-call.
+**Comment :** document blameless dans les 48h. Sections : timeline, impact, 5 Whys jusqu'a la cause racine systemique, what went well, what went wrong, action items avec owners et deadlines. L'objectif est d'ameliorer le SYSTEME — pas de trouver un responsable. Action items prioritaires sur le prochain sprint.

package/assets/.claude/skills/api-design/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: api-design
+description: "API Design — l'API comme contrat, REST/GraphQL/gRPC, pagination cursor-based, idempotency, structured errors, rate limiting. À charger quand on crée ou modifie des endpoints."
+---
+
+# API Design
+
+**Principe premier :** Une API est un contrat entre un client et un serveur qui évoluent à des rythmes différents. Le client peut être une app mobile qui se met à jour une fois par mois, le serveur peut être déployé 10× par jour. Le design d'API est l'art de faire évoluer le contrat sans le casser. Chaque champ que tu ajoutes est un engagement, chaque champ que tu changes est une rupture. La question n'est pas "est-ce que c'est RESTful ?" mais "est-ce que le client peut survivre à 6 mois de changements serveur sans mise à jour ?"
+
+## Checklist
+- [ ] L'API est versionnée — dans l'URL (/v1/) ou le header (Accept-Version)
+- [ ] Pagination cursor-based — stable, index-friendly, pas de doublon entre pages
+- [ ] Les erreurs sont structurées : `{error: {code, message, details}}` — pas de `200 OK {success: false}`
+- [ ] Les mutations POST/PUT/DELETE supportent l'idempotency key
+- [ ] Rate limiting en place avec headers standards : `Retry-After`, `X-RateLimit-*`
+- [ ] Le schéma est documenté (OpenAPI/GraphQL schema/gRPC proto) et la doc est le contrat, pas une suggestion
+- [ ] Pas de breaking change sans nouvelle version ou deprecation window explicite
+
+## Anti-patterns
+### Breaking change silencieux
+**Ce qu'on voit :** `{price: 10}` devient `{price: {amount: 10, currency: "EUR"}}` sur la même version d'API. Les clients mobiles qui n'ont pas été mis à jour crashent.
+**Pourquoi c'est dangereux :** le client n'a aucun moyen de savoir que le contrat a changé. Il parse ce qu'il reçoit, ça casse. Le pire : ça peut arriver à 20% des utilisateurs seulement (ceux qui n'ont pas la dernière version de l'app). Le bug est invisible côté serveur.
+**Faire plutôt :** nouvelle version (/v2/) avec le nouveau format. L'ancienne version (/v1/) est maintenue pendant une deprecation window (6-12 mois) avec un header `Deprecation: true` et `Sunset: <date>`. Les clients ont le temps de migrer.
+
+### `200 OK` avec erreur dedans
+**Ce qu'on voit :** toutes les réponses sont HTTP 200. Le corps contient `{success: false, error: "quelque chose"}`. Même pour une erreur 500.
+**Pourquoi c'est dangereux :** HTTP a un système de codes d'erreur pour une raison. Les CDN cachent les 200. Les load balancers comptent les 5xx. Les outils de monitoring alertent sur les taux d'erreur HTTP. En faisant tout en 200, tu rends ton API invisible à toute la chaîne d'infrastructure.
+**Faire plutôt :** utiliser les codes HTTP comme prévu. 201 Created, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 422 Unprocessable, 429 Too Many Requests, 500 Internal. Le code HTTP est un signal machine-readable.
+
+### Offset pagination
+**Ce qu'on voit :** `GET /orders?page=3&limit=50` → `LIMIT 50 OFFSET 100`. À la page 100, la DB scanne 5000 rows pour en retourner 50.
+**Pourquoi c'est dangereux :** deux problèmes. Performance : OFFSET N oblige la DB à scanner N rows. Cohérence : si une row est insérée entre deux pages, toutes les rows suivantes sont décalées et l'utilisateur voit des doublons ou manque des entrées.
+**Faire plutôt :** cursor-based : `GET /orders?cursor=xyz&limit=50` → `WHERE id > 'xyz' ORDER BY id LIMIT 50`. Index-friendly. Stable. Pas de doublon. Le cursor est opaque pour le client.
+
+## Patterns
+### Structured errors
+**Quand :** toute API.
+**Comment :** `{error: {code: "INSUFFICIENT_FUNDS", message: "Solde insuffisant", details: [{field: "amount", reason: "minimum 10 EUR"}]}}`. `code` : machine-readable (switch côté client). `message` : human-readable (debug). `details` : actionable (form validation).
+
+### Idempotency key
+**Quand :** toute mutation où le double-submit est dangereux (paiements, créations).
+**Comment :** header `Idempotency-Key: <uuid>`. Le serveur stocke la clé + le résultat. Même clé = même réponse, l'opération n'est exécutée qu'une fois. Stripe utilise ce pattern pour 100% de leurs mutations.
+
+### Rate limiting avec headers
+**Quand :** tout endpoint public.
+**Comment :** `429 Too Many Requests` + `Retry-After: 30` + `X-RateLimit-Limit: 100` + `X-RateLimit-Remaining: 0` + `X-RateLimit-Reset: 1716000000`. Le client sait exactement quand réessayer. Pas de backoff deviné.

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

@@ -0,0 +1,43 @@
+---
+name: appsec
+description: "Application Security — OWASP Top 10, defense in depth, auth (OAuth2/OIDC), input validation, session security. À charger quand on sécurise une application."
+---
+
+# Application Security
+
+**Principe premier :** La sécurité applicative n'est pas une feature — c'est une propriété émergente d'un système où chaque couche suppose que celle d'avant a échoué. Si ton input validation compte sur le WAF, et que ton WAF compte sur le framework, personne ne valide vraiment. La défense en profondeur n'est pas "plusieurs couches" — c'est "chaque couche traite l'input comme hostile, même si une autre couche est censée l'avoir déjà nettoyé". Assume breach à chaque étage.
+
+## Checklist
+- [ ] Toutes les entrées utilisateur sont validées à la frontière — type, longueur, charset, range
+- [ ] Requêtes SQL/NoSQL paramétrées — jamais de concaténation (injection)
+- [ ] Authentification via OAuth2/OIDC avec providers éprouvés — pas d'auth maison
+- [ ] Sessions : HttpOnly, Secure, SameSite=Lax, rotation d'ID après login
+- [ ] CSRF protégé sur toutes les mutations (SameSite + token si nécessaire)
+- [ ] Rate limiting sur TOUS les endpoints sensibles (login, API, upload, reset password)
+- [ ] Headers de sécurité : CSP, HSTS, X-Frame-Options, X-Content-Type-Options
+- [ ] Mots de passe hashés avec argon2id (pas de SHA, pas de MD5)
+
+## Anti-patterns
+### Auth maison
+**Ce qu'on voit :** `const token = jwt.sign({userId}, SECRET)` — JWT sans expiration, sans refresh, sans blacklist. Le token volé = accès permanent.
+**Pourquoi c'est dangereux :** l'authentification est le problème de sécurité le plus résolu — et le plus mal implémenté. Un JWT mal configuré n'a pas de révocation possible. Si l'attaquant vole un token, il a un accès permanent. Construire son propre système d'auth est la cause #1 des failles critiques.
+**Faire plutôt :** OAuth2/OIDC via un provider éprouvé (Auth0, Clerk, NextAuth, Keycloak). Access token courte durée (15 min), refresh token longue durée (7j) avec rotation. Blacklist côté serveur pour les tokens révoqués.
+
+### Validation "plus tard"
+**Ce qu'on voit :** les données arrivent dans le controller, passent dans le service, arrivent dans la DB sans validation. "Le frontend valide". "L'ORM échappe".
+**Pourquoi c'est dangereux :** le frontend est sous le contrôle de l'attaquant. Un simple `curl` contourne toute validation frontend. L'ORM échappe le SQL mais ne valide pas le type, la longueur, le charset, le business logic. Sans validation à la frontière, la DB reçoit n'importe quoi.
+**Faire plutôt :** validation à l'entrée de l'API (middleware/guard). Schéma (Zod, JSON Schema, Pydantic). Rejeter tout ce qui ne matche PAS le schéma — ne pas essayer de "corriger". Whitelist, pas blacklist.
+
+### Rate limiting absent
+**Ce qu'on voit :** `POST /login` sans rate limiting. Un attaquant brute-force 10 000 mots de passe par seconde.
+**Pourquoi c'est dangereux :** le brute-force est l'attaque la plus simple et la plus efficace. Sans rate limiting, un mot de passe faible tombe en minutes. Le rate limiting n'est pas une feature — c'est la seule défense contre l'énumération.
+**Faire plutôt :** rate limiting sur /login (5 tentatives/min/IP + compte), /api (100 req/s par clé), /reset-password (1 tentative/min/email). Retourner 429 avec `Retry-After`. Bloquer (pas juste ralentir) après N échecs.
+
+## Patterns
+### Defense in depth
+**Quand :** toute application manipulant des données sensibles.
+**Comment :** WAF → Input validation → Auth → Authorization → SQL paramétré → Output encoding → CSP → Encryption at rest. Chaque couche suppose que les précédentes ont failli. Exemple : même avec du SQL paramétré, valider le type de l'input avant. Même avec HTTPS, marquer les cookies Secure.
+
+### Structured security review (OWASP Top 10)
+**Quand :** à chaque release ou changement majeur.
+**Comment :** passer en revue le Top 10 OWASP pour CHAQUE endpoint critique. Injection, Broken Auth, Sensitive Data Exposure, XXE, Broken Access Control, Security Misconfiguration, XSS, Insecure Deserialization, Vulnerable Components, Insufficient Logging. Pas un audit annuel — une habitude de release.

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

@@ -0,0 +1,74 @@
+---
+name: architecture
+description: "Architecture Logicielle — monolithe modulaire, microservices, ports/adapters, ADR, Strangler Fig, trade-offs. A charger quand on definit la structure d'un projet."
+---
+
+# Architecture Logicielle
+
+**Principe premier :** L'architecture n'est pas une collection de patterns — c'est la gestion explicite des dependances. La qualite d'une architecture se mesure a une chose : combien de modules dois-je toucher pour faire un changement metier ? Si la reponse est > 3, l'architecture est cassee, peu importe le pattern utilise. Le bon pattern depend du contexte (taille d'equipe, frequence de changement, exigences de scale), pas de la mode.
+
+## Checklist
+- [ ] Le choix d'architecture est justifie par le contexte et documente (ADR)
+- [ ] Les dependances pointent vers le domaine — jamais l'inverse (Domain <> Infrastructure)
+- [ ] Les modules sont nommes par capacite metier (billing, shipping), pas par couche technique (controllers, services, utils)
+- [ ] Chaque module a une interface explicite (contrat) — pas de couplage par import direct interne
+- [ ] Demarrer simple (monolithe modulaire) — extraire en service UNIQUEMENT quand le besoin est prouve
+- [ ] Le diagramme de contexte (C4 niveau 1-2) existe et est visible des nouveaux
+
+## Trade-offs : les 3 architectures
+
+### Monolithe simple vs Monolithe modulaire vs Microservices
+
+| | Monolithe simple | Monolithe modulaire | Microservices |
+|--|-----------------|-------------------|--------------|
+| **Structure** | 1 codebase, pas de frontieres internes | 1 codebase, modules separes par domaine (billing/, orders/) | N codebases independantes |
+| **Deploiement** | 1 artefact | 1 artefact | N artefacts |
+| **Avantages** | Simple, rapide a demarrer | Deploiement simple, frontieres claires, peut extraire en service plus tard | Scale independant, equipes autonomes, isolation de pannes |
+| **Desavantages** | Devient vite un "big ball of mud" | Modules peuvent se coupler par import direct si pas discipline | Cout reseau, latence, serialisation, deploiements coordonnes |
+| **Quand choisir** | POC, equipe 1-3, court-terme | Equipe 4-20, projet long-terme | > 5 equipes, besoin de scale independant |
+| **Piege** | "On modularisera plus tard" → jamais fait | Modules deviennent des services deguises (imports croises) | Microservices sans equipes autonomes = pire que monolithe |
+
+**Regle :** commencer monolithe modulaire. Extraire en microservice quand : (1) l'equipe est trop grande pour une codebase (> 20), OU (2) un module a besoin de scale independant, OU (3) un module a un cycle de release different.
+
+## Anti-patterns
+### Microservices comme defaut
+**Ce qu'on voit :** 12 services, 12 repos, 12 pipelines — pour 3 devs et 100 utilisateurs. Un changement simple touche 4 repos.
+**Pourquoi c'est dangereux :** les microservices deplacent la complexite du code vers le reseau. Chaque service ajoute latence, serialisation, gestion d'erreur reseau. Le seuil n'est pas technologique, il est organisationnel : une equipe par service.
+**Faire plutot :** monolithe modulaire. Domaines separes en modules, interfaces explicites, meme codebase. Un commit = un changement. Extraire un service quand l'equipe grandit (> 20) ou qu'un module a besoin de scale independant.
+
+### Architecture en couches videe
+**Ce qu'on voit :** Controller → Service → Repository. Le Service fait 3 lignes : `return this.repository.findById(id)`. Le domaine n'existe pas — c'est un tuyau HTTP→DB.
+**Pourquoi c'est dangereux :** les regles metier sont eparpillees dans les controllers, validateurs, middlewares. Changer une regle oblige a traquer la logique dans 6 fichiers.
+**Faire plutot :** le domaine contient les regles. `order.approve()` verifie le statut, le credit, la dispo. Le service orchestre, le repository persiste, le controller traduit HTTP. Chaque couche a une VRAIE responsabilite.
+
+### Architecture decidee puis figee
+**Ce qu'on voit :** un diagramme dessine il y a 3 ans. L'archi reelle a diverge. Personne ne l'a documente.
+**Pourquoi c'est dangereux :** l'architecture documentee est un mensonge. Les nouveaux devs prennent des decisions sur une base fausse. La derive architecturale s'accelere.
+**Faire plutot :** ADR (Architecture Decision Records) pour les decisions importantes. Diagrammes regeneres (C4 via structurizr ou PlantUML). L'architecture est vivante.
+
+## Patterns
+### Monolithe modulaire
+**Quand :** debut de projet, equipe < 20, pas de besoin de scale independant.
+**Comment :** modules par domaine (billing/, shipping/, auth/). Chaque module a son propre schema DB logique. Communication inter-module par interfaces explicites.
+- **Avantages :** deploy simple, refactoring facile (un commit), pas de latence reseau
+- **Desavantages :** scale tout-ou-rien, un module peut bloquer le deploiement
+- **Mise en place :** (1) Creer un dossier par domaine (`src/billing/`, `src/shipping/`). (2) Chaque module expose une interface publique (`index.ts` avec exports explicites). (3) Les imports entre modules passent UNIQUEMENT par l'interface publique. (4) Chaque module a ses propres migrations DB. (5) Tester les modules isolement. (6) Si un module devient trop gros → Strangler Fig pour l'extraire.
+
+### Ports & Adapters (Hexagonale)
+**Quand :** le domaine metier doit survivre aux changements d'infrastructure.
+**Comment :** le domaine definit des interfaces (ports : `OrderRepository`, `PaymentGateway`). Les adapters implementent ces interfaces (PostgresAdapter, StripeAdapter). Le domaine ne depend de rien d'externe.
+- **Avantages :** changer de DB ou de payment provider sans toucher le domaine. Testable sans infra.
+- **Desavantages :** couche d'abstraction supplementaire. Plus de fichiers.
+- **Mise en place :** (1) Definir les ports dans le domaine. (2) Implementer les adapters dans un dossier `infrastructure/`. (3) Injecter les adapters au runtime (constructor injection). (4) Tester le domaine avec des adapters in-memory. (5) Tester les vrais adapters en integration.
+
+### Strangler Fig (migration progressive)
+**Quand :** migration d'un legacy vers une nouvelle architecture sans big bang.
+**Comment :** router le trafic progressivement. Nouvelle fonctionnalite → nouveau systeme. Ancienne migree → proxy vers nouveau, puis suppression.
+- **Avantages :** chaque etape est deployable et rollbackable. Zero downtime.
+- **Desavantages :** plus lent qu'un big bang. Cout de maintenance du proxy et des deux systemes en parallele.
+- **Mise en place :** (1) Placer un proxy/API Gateway devant le legacy. (2) Creer le nouveau service avec un sous-ensemble de fonctionnalites. (3) Router par endpoint : `GET /orders` → nouveau, le reste → legacy. (4) Migrer les endpoints un par un, valider chaque migration. (5) Migrer les donnees progressivement (dual-write puis backfill). (6) Quand tout le trafic est sur le nouveau → supprimer le legacy. (7) Supprimer le proxy. Chaque etape = une PR deployable.
+
+### ADR (Architecture Decision Record)
+**Quand :** toute decision architecturale non triviale.
+**Comment :** document leger (1-2 pages) dans `docs/adrs/NNNN-title.md`. Format : Titre, Statut (proposed/accepted/deprecated), Contexte, Decision, Alternatives, Consequences.
+- **Mise en place :** (1) Creer `docs/adrs/`. (2) Template ADR. (3) Chaque decision significative → un ADR. (4) Les ADR sont revus en PR comme du code. (5) Les ADR obsoletes sont marques `deprecated` (pas supprimes — l'historique a de la valeur). Un nouveau membre lit les ADR dans l'ordre pour comprendre l'histoire de l'architecture.

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

@@ -0,0 +1,41 @@
+---
+name: backend
+description: "Backend — graceful degradation, connection pooling, idempotency, error handling as contract, health checks. À charger quand on crée ou modifie des services backend."
+---
+
+# Backend
+
+**Principe premier :** Le backend n'est pas "la partie qui parle à la base de données" — c'est un composant dans un système distribué qui doit survivre à la défaillance de tout ce qui l'entoure. La DB tombe, le réseau coupe, le client timeout. Un backend bien conçu ne crash pas — il dégrade, il retry, il informe. La métrique n'est pas "uptime" mais "MTTR" — chaque seconde entre la panne et la récupération est du temps utilisateur perdu.
+
+## Checklist
+- [ ] Chaque endpoint a un timeout explicite — pas de requête pendante infinie
+- [ ] Graceful shutdown : SIGTERM → stop accepter → drainer les requêtes (max 30s) → close connexions → exit
+- [ ] Health check exposé : liveness (suis-je vivant ?) ≠ readiness (puis-je servir ?)
+- [ ] Connection pooling sur DB, Redis, et clients HTTP — pas de connexion unique
+- [ ] Les erreurs sont structurées : `{code, message, details}` — jamais de stack trace en prod
+- [ ] Rate limiting en place sur les endpoints publics — pas de "on verra plus tard"
+
+## Anti-patterns
+### Avaler les erreurs
+**Ce qu'on voit :** `try { await db.query() } catch (e) { console.log(e) }`. Pas de rethrow, pas de fallback. L'erreur est loguée et oubliée.
+**Pourquoi c'est dangereux :** l'appelant reçoit "success" mais rien n'a été fait. Le système continue dans un état incohérent. Les erreurs avalées sont impossibles à debugger — tu ne sais jamais quelles opérations ont réellement échoué.
+**Faire plutôt :** soit gérer l'erreur (retry, fallback, compensation), soit la laisser remonter à un error handler global qui la transforme en réponse structurée. Ne jamais avaler silencieusement.
+
+### Graceful shutdown = process.exit(0)
+**Ce qu'on voit :** `process.on('SIGTERM', () => process.exit(0))` — les 50 requêtes en cours sont coupées net. Le load balancer envoie encore du trafic vers une instance zombie.
+**Pourquoi c'est dangereux :** perte de données, transactions incomplètes, expérience utilisateur dégradée. Le load balancer détecte la panne 30 secondes plus tard — pendant ce temps, toutes les requêtes échouent.
+**Faire plutôt :** SIGTERM → le load balancer retire l'instance (health check fail) → l'instance arrête d'accepter les nouvelles requêtes → attend la fin des requêtes en cours (timeout 30s max) → close les connexions DB/Redis → exit. Kubernetes donne 30s par défaut (terminationGracePeriodSeconds).
+
+### Une connexion DB pour tout le monde
+**Ce qu'on voit :** `const db = new Database(DATABASE_URL)` — un singleton connexion pour toute l'application. 100 requêtes simultanées = 99 en file d'attente.
+**Pourquoi c'est dangereux :** la connexion unique est le bottleneck. Les requêtes s'empilent, la latence explose. Sous charge, l'app devient non-réactive. Une seule requête lente bloque tout le monde.
+**Faire plutôt :** connection pool. min/max configurés selon la charge attendue (min: 2, max: 20). Monitorer les métriques du pool : waiting, idle, active. Si `waiting > 0` régulièrement, augmenter le max ou optimiser les requêtes.
+
+## Patterns
+### Middleware chain
+**Quand :** logique transversale (auth, logging, rate limiting, CORS).
+**Comment :** chaque middleware fait UNE chose. Ordre canonique : CORS → rate limit → auth → validation → handler → error handler. La requête traverse la chaîne dans l'ordre, l'erreur remonte dans l'ordre inverse.
+
+### Idempotency token
+**Quand :** opérations mutantes (paiement, création de ressource) où le double-submit est dangereux.
+**Comment :** le client génère un `Idempotency-Key: uuid`. Le serveur stocke la clé + le résultat de l'opération dans une transaction. Si la clé est déjà vue → retourner le résultat stocké sans ré-exécuter.

package/assets/.claude/skills/backup-recovery/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: backup-recovery
+description: "Backup & Recovery — RPO/RTO, PITR, disaster recovery, multi-region, test de restore. A charger quand on configure les sauvegardes."
+---
+
+# Backup & Recovery
+
+**Principe premier :** Une sauvegarde n'est pas une copie de donnees — c'est une police d'assurance, et comme toute assurance, tu ne sais pas si elle marche tant que tu n'as pas fait de sinistre. La question n'est pas "est-ce qu'on a des backups ?" (oui, tout le monde en a) — c'est "a quelle date etait le dernier test de restore ?" Un backup jamais teste n'est pas un backup, c'est un vœu pieux. Les deux metriques qui definissent ta strategie sont le RPO (Recovery Point Objective : combien de donnees tu acceptes de perdre, en temps) et le RTO (Recovery Time Objective : combien de temps pour restaurer le service). Tout le reste — outils, frequence, retention — decoule de ces deux nombres.
+
+## Checklist
+- [ ] RPO (perte de donnees max acceptable) et RTO (temps de restore max acceptable) sont definis et documentes
+- [ ] Les backups sont automatises — pas de "je fais un pg_dump le vendredi soir"
+- [ ] Le restore est teste regulierement (minimum trimestriel) — sans test, pas de backup
+- [ ] Les backups sont stockes dans une region/separee differente de la production (pas dans le meme datacenter)
+- [ ] La retention est definie : journaux 30j, mensuels 12 mois, annuels 7 ans (selon conformite)
+- [ ] Les backups sont chiffres au repos et en transit — une fuite de backup = fuite de toutes les donnees
+- [ ] Le processus de restore est documente et testable par n'importe quel membre de l'equipe
+
+## Anti-patterns
+### Backup = dump periodique
+**Ce qu'on voit :** `pg_dump` tous les jours a 3h du matin. "On a une sauvegarde." RPO = 24h. Restore = manuel, non teste.
+**Pourquoi c'est dangereux :** un pg_dump quotidien = tu perds jusqu'a 24h de donnees. Le restore prend des heures (charger un dump complet). Pas de PITR (point-in-time recovery) — si la corruption est arrivee a 14h, tu ne peux pas restaurer a 13h59, seulement a 3h du matin.
+**Faire plutot :** WAL archiving continu (PostgreSQL) ou binlog (MySQL) → PITR possible a la seconde pres. Backups complets hebdomadaires + incrementaux quotidiens ou continus. Restore PITR teste automatiquement.
+
+### Backup dans la meme region
+**Ce qu'on voit :** backups dans le meme S3 bucket, meme region, meme compte. "C'est plus simple a gerer."
+**Pourquoi c'est dangereux :** la region tombe (panne AWS, coupure electrique, catastrophe naturelle) → tous les backups sont inaccessibles. Un attaquant compromet le compte → il supprime tout, backups inclus. Le backup co-localise n'est pas un backup — c'est une copie.
+**Faire plutot :** backups cross-region minimum. Idealement cross-cloud pour les donnees critiques. Les backups sont dans un compte separe avec acces minimal. Immutable backups (Object Lock, WORM) : meme l'admin ne peut pas supprimer avant la retention.
+
+### "Le restore a marche en staging il y a 6 mois"
+**Ce qu'on voit :** le test de restore a ete fait une fois, lors de la mise en place. Depuis, le schema a change, les volumes ont triple, l'equipe a tourne.
+**Pourquoi c'est dangereux :** un restore est un processus complexe : restaurer la DB, verifier l'integrite, re-configurer les connexions, re-chauffer les caches, valider les donnees. Chaque changement dans le schema, les dependances, ou l'infrastructure peut casser le restore. Un restore qui echoue le jour du sinistre = pas de restore du tout.
+**Faire plutot :** restore automatise hebdomadaire dans un environnement isole. Tests d'integrite automatiques apres restore. L'alerte part si le restore echoue. Le test de restore fait partie de la sante operationnelle, comme un health check.
+
+## Patterns
+### Strategie 3-2-1
+**Quand :** toute strategie de backup.
+**Comment :** 3 copies des donnees, sur 2 types de media differents, dont 1 copie hors site (offsite). Exemple : backup local (rapide a restaurer) + backup cloud (region A) + backup cloud (region B, immuable). Une panne ou corruption sur un seul media ne detruit pas tout.
+
+### Point-in-time recovery (PITR)
+**Quand :** base de donnees relationnelle (PostgreSQL, MySQL, SQL Server).
+**Comment :** WAL archiving continu vers un stockage objet. Backup complet hebdomadaire. Restore : charger le dernier backup complet → appliquer les WAL jusqu'au timestamp desire. RPO effectif = secondes (le delai de replication du WAL), pas heures.

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

@@ -0,0 +1,44 @@
+---
+name: caching
+description: "Caching — cache-aside/write-through, cache stampede protection, TTL strategy, invalidation as the hard problem. À charger quand on parle de performance ou de mise en cache."
+---
+
+# Caching
+
+**Principe premier :** Il y a deux problèmes difficiles en informatique : nommer les choses, l'invalidation de cache, et les off-by-one. Le cache est un mensonge délibéré — tu sers une version potentiellement périmée de la donnée en échange de latence réduite. La seule question qui compte est : "quelle est la péremption acceptable pour CE cas d'usage ?" Si la réponse est 0ms, pas de cache. Si la réponse est "5 minutes, c'est acceptable", tu as un budget d'incohérence. Nommer ce budget explicitement est le design du cache.
+
+## Checklist
+- [ ] La stratégie est choisie selon le pattern d'accès : cache-aside (read-heavy), write-through (read-after-write), write-behind (write-heavy)
+- [ ] Chaque entrée de cache a un TTL explicite et justifié — jamais de cache infini
+- [ ] La protection anti-stampede est en place — 1000 miss simultanés ne déclenchent pas 1000 requêtes DB
+- [ ] Le cache est monitoré : hit rate, miss rate, eviction rate, mémoire utilisée
+- [ ] L'invalidation est événementielle ou par TTL — jamais "pense à vider le cache" en commentaire
+
+## Anti-patterns
+### Cache infini
+**Ce qu'on voit :** `cache.set('user:' + id, userData)` sans TTL. Le cache ne sera vidé que quand Redis sera plein et fera une éviction arbitraire.
+**Pourquoi c'est dangereux :** l'incohérence grandit avec le temps. L'utilisateur change son email dans la DB, le cache sert l'ancien pendant des jours. Le bug est intermittent (parfois cache hit, parfois miss) — le pire type de bug à debugger.
+**Faire plutôt :** toujours un TTL. Court pour les données dynamiques (1-5 min). Long pour le statique (1-24h). Le TTL est un compromis entre fraîcheur et performance — le choisir consciemment.
+
+### Cache stampede
+**Ce qu'on voit :** une clé chaude expire. 1000 requêtes simultanées arrivent. Toutes font un cache miss → toutes interrogent la DB. La DB reçoit 1000× la même requête.
+**Pourquoi c'est dangereux :** le stampede transforme un cache miss en attaque DDoS auto-infligée. La DB qui allait bien voit soudainement 1000× la charge normale. Pire : elle génère 1000× la même réponse, et 999 réponses sont jetées.
+**Faire plutôt :** probabilistic early recomputation (recalculer avec une probabilité croissante quand le TTL approche). Ou lock distribué temporaire — un seul worker recalcule, les autres attendent le résultat (SETNX).
+
+### Invalidation commentée
+**Ce qu'on voit :** `// PENSE À VIDER LE CACHE QUAND TU MODIFIES CETTE TABLE` — dans un commentaire. Qui n'est pas lu. Par un dev qui ne savait pas. Le cache et la DB divergent silencieusement.
+**Pourquoi c'est dangereux :** l'invalidation manuelle est une machine à bugs intermittents. Chaque écriture est une opportunité d'oubli. Le bug n'apparaît que dans le cas "cache hit après écriture" — difficile à reproduire.
+**Faire plutôt :** invalidation automatique. Événement DB → event bus → cache invalidation. Ou TTL assez court pour que l'incohérence maximale soit acceptable. Jamais de "penser à" dans la conception d'un système.
+
+## Patterns
+### Cache-aside
+**Quand :** lecture dominante, tolérance à la stale data.
+**Comment :** (1) lire le cache, (2) si hit → retourner, (3) si miss → lire la DB, (4) écrire dans le cache, (5) retourner. L'application est responsable de la cohérence. Simple, mais attention au stampede.
+
+### Write-through
+**Quand :** les données écrites sont presque toujours relues immédiatement.
+**Comment :** écrire dans le cache ET dans la DB dans la même opération. Le cache est toujours chaud pour les lectures récentes. Coût : chaque écriture touche le cache, même si personne ne relit.
+
+### Probabilistic early recomputation
+**Quand :** protéger une clé chaude du stampede.
+**Comment :** avant que le TTL n'expire, le worker vérifie si `random() < 1 / (TTL_remaining_seconds * request_rate)`. Si oui, il recalcule de manière anticipée et met à jour le cache. Statistiquement, un seul worker le fait.

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

@@ -0,0 +1,42 @@
+---
+name: cdn
+description: "CDN & Edge — cache geographique, TTL strategies, origin shield, edge computing, cache invalidation. A charger quand on configure un CDN ou optimise la livraison de contenu."
+---
+
+# CDN & Edge
+
+**Principe premier :** Un CDN n'est pas un "cache rapide" — c'est un reseau de distribution qui rapproche les donnees de l'utilisateur. La latence n'est pas une question de bande passante, c'est une question de distance (lumiere dans la fibre = ~5ms pour 1000km). Un CDN reduit la distance en placant les donnees dans 200+ points de presence. Mais un CDN est aussi un cache — et tout cache peut servir des donnees stale. La question centrale n'est pas "est-ce que le CDN est rapide ?" mais "quelle fraicheur est acceptable pour quel contenu ?"
+
+## Checklist
+- [ ] Les assets statiques sont servis via CDN (pas depuis le serveur d'origine) avec Cache-Control explicite
+- [ ] Les headers de cache sont differencies par type de contenu : immutable pour versionne, revalidation pour dynamique
+- [ ] L'origin shield est configure — pas de 50 POPs qui frappent l'origine simultanement
+- [ ] L'invalidation est ciblee (chemins specifiques, pas `/*`) et monitorisee
+- [ ] Le TTL est defini selon la fraicheur acceptable : html 5min, assets versionnes 1 an
+- [ ] Les tokens/query strings prives ne cassent pas le cache (strip, normalize, ou ignore)
+- [ ] Le CDN est devant l'application entiere, pas juste les assets (DDoS protection, SSL termination)
+
+## Anti-patterns
+### Tout en `max-age=0, no-cache`
+**Ce qu'on voit :** l'equipe a ete brulee par du contenu stale. Solution : tout revalider a chaque requete.
+**Pourquoi c'est dangereux :** chaque requete frappe l'origine. Le CDN devient un proxy transparent inutile (cout + latence sans benefice). Le serveur d'origine encaisse 100% du trafic. Le CDN coute de l'argent pour rien.
+**Faire plutot :** differencier par type de contenu. Assets versionnes → `max-age=31536000, immutable`. Pages HTML → `max-age=300, stale-while-revalidate=600`. API responses → `max-age=0, private` (pas de cache CDN pour les donnees privees).
+
+### Cache invalidation = `/*`
+**Ce qu'on voit :** un deployement → invalidation de tout le cache (`/*`). 50000 requetes simultanees vers l'origine.
+**Pourquoi c'est dangereux :** l'invalidation complete cree un "cache stampede" sur l'origine. Le serveur d'origine n'est pas dimensionne pour le trafic total. Chaque deployement = risque d'outage.
+**Faire plutot :** invalider uniquement les chemins modifies. Utiliser des noms de fichiers versionnes (`main.a3f2b1c.js`) → jamais besoin d'invalider. Pour les SPA : invalider `index.html` seulement, le reste est immutable.
+
+### CDN = juste pour les images
+**Ce qu'on voit :** seuls les assets statiques sont sur le CDN. L'API et les pages HTML passent directement au serveur.
+**Pourquoi c'est dangereux :** le CDN offre la terminaison SSL, la protection DDoS, le WAF, l'optimisation d'images, le edge computing. Le mettre uniquement devant `/static/` gaspille sa capacite principale : absorber le trafic malveillant avant qu'il n'atteigne l'origine.
+**Faire plutot :** CDN devant tout le domaine. L'origine est cachee derriere le CDN, pas exposee publiquement. Les regles de cache decident ce qui est servi depuis le edge vs l'origine.
+
+## Patterns
+### Cache hierarchies (origin shield)
+**Quand :** trafic global avec beaucoup de POPs (200+).
+**Comment :** un POP regional intermediaire (origin shield) consolide les requetes vers l'origine. Au lieu de 200 POPs qui frappent l'origine sur un cache miss, seul l'origin shield la contacte. Reduction de la charge origine de 100-200x.
+
+### Stale-while-revalidate
+**Quand :** contenu qui peut etre legerement stales (pages HTML, reponses API publiques).
+**Comment :** `Cache-Control: max-age=300, stale-while-revalidate=600`. Le CDN sert le contenu stales jusqu'a 15 minutes pendant qu'il revalide en arriere-plan. L'utilisateur ne voit jamais la latence de revalidation. Ideal pour les pages qui changent peu.

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

@@ -0,0 +1,41 @@
+---
+name: chaos
+description: "Chaos Engineering — injection de pannes, Game Day, Chaos Monkey, experimentation, hypotheses de resilience. A charger quand on teste la resilience d'un systeme."
+---
+
+# Chaos Engineering
+
+**Principe premier :** Le chaos engineering n'est pas "casser des choses en production pour voir ce qui se passe" — c'est une discipline scientifique appliquee aux systemes distribues. Tu formules une hypothese de resilience ("si le service B tombe, le fallback degrade le mode"), tu injectes la panne de maniere controlee, et tu compares le comportement observe a l'hypothese. La valeur n'est pas dans le chaos — elle est dans la decouverte des comportements emergents que personne n'avait prevus. Un systeme sans chaos engineering n'est pas stable — il est non teste. La stabilite reelle se mesure en production, pas en staging.
+
+## Checklist
+- [ ] Une hypothese de resilience est formulee avant chaque experience (pas "on va eteindre cette DB et voir")
+- [ ] Le blast radius est controle : un petit pourcentage de trafic, un seul AZ/service
+- [ ] L'experience a un arret d'urgence (kill switch) actionnable en < 10 secondes
+- [ ] Les metriques sont en place AVANT l'experience (baseline + deviation en temps reel)
+- [ ] Le Game Day est planifie avec un scenario et un runbook
+- [ ] Les decouvertes sont documentees et transforment le systeme (pas "c'etait interessant, on fera mieux")
+
+## Anti-patterns
+### Chaos en production sans filet
+**Ce qu'on voit :** "on va tester en production vendredi soir." Pas d'hypothese, pas de kill switch, pas de monitoring.
+**Pourquoi c'est dangereux :** le chaos sans controle n'est pas une experience — c'est un incident provoque. Sans hypothese, tu ne sais pas si le comportement est normal ou anormal. Sans kill switch, tu ne peux pas arreter l'hemorragie.
+**Faire plutot :** commencer en staging avec des pannes simples (kill un process, saturer un disque). Monter en puissance progressivement. En production : commencer par 1% de trafic, puis 5%, puis 10%. Toujours avec un kill switch.
+
+### Chaos = Chaos Monkey uniquement
+**Ce qu'on voit :** l'equipe installe Chaos Monkey, kill des instances au hasard, et considere que le chaos engineering est fait.
+**Pourquoi c'est dangereux :** Chaos Monkey teste UNE chose : que ton application survit a la mort d'une instance. Ca ne teste pas la latence reseau, la corruption de donnees, la saturation disque, les pannes DNS, les timeouts de circuit breaker. Le chaos engineering est une discipline large — Chaos Monkey en est un tout petit sous-ensemble.
+**Faire plutot :** varier les injections : latence reseau, perte de paquets, defaillance DNS, saturation CPU/disque, coupure de dependance, corruption de reponse, expiration de certificat. Chaque type de panne revele une classe de vulnerabilites differente.
+
+### Pas de suivi des decouvertes
+**Ce qu'on voit :** le Game Day est fun. Les decouvertes sont notees sur un post-it. Rien n'est corrige.
+**Pourquoi c'est dangereux :** le chaos engineering sans correction est du theatre. Les memes vulnerabilites survivent au Game Day suivant. L'equipe apprend mais le systeme n'apprend pas.
+**Faire plutot :** chaque decouverte = un ticket. Prioriser les corrections avant le prochain Game Day. Re-tester les memes pannes pour verifier que la correction fonctionne. Le chaos engineering est une boucle : injecter → mesurer → corriger → re-tester.
+
+## Patterns
+### Game Day
+**Quand :** equipe qui n'a jamais teste son systeme en conditions de panne.
+**Comment :** 2h-4h planifiees. 1 scenario defini a l'avance ("la DB primaire est inaccessible"). Roles : un orchestrateur, un observateur, un intervenant. Monitoring temps reel. Debrief immediat apres : qu'est-ce qui a casse ? qu'est-ce qui a tenu ? qu'est-ce qu'on corrige ?
+
+### Steady-state hypothesis
+**Quand :** toute experience de chaos.
+**Comment :** definir l'etat normal AVANT l'injection ("P95 latence < 500ms, taux d'erreur < 1%, pas d'alerte critique"). Injecter la panne. Comparer a l'etat normal. Si l'ecart est inattendu → vulnerabilite. Cette methode donne une definition objective de "le systeme a tenu".

package/assets/.claude/skills/cicd-pipeline/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: cicd-pipeline
+description: "CI/CD — feedback loops, DORA metrics, trunk-based dev, pipeline as constraint theory, matrix builds, OIDC, ephemeral runners. À charger quand on conçoit ou optimise un pipeline CI/CD."
+---
+
+# CI/CD Pipeline
+
+**Principe premier :** La CI/CD n'est pas "automatiser les builds". C'est réduire le temps entre un commit et le feedback de production. Chaque minute perdue entre "j'écris" et "je sais si ça marche" est du gaspillage. Les 4 métriques DORA (Lead Time, Deploy Frequency, MTTR, Change Failure Rate) mesurent cette performance. Tout le reste — caching, parallel builds, OIDC — est un moyen, pas une fin.
+
+## Checklist
+- [ ] La pipeline donne du feedback en < 5 min (sinon les devs arrêtent de l'attendre)
+- [ ] Le trunk-based development est la norme — branches ≤ 1 jour, pas de long-lived branches
+- [ ] Les 4 DORA metrics sont mesurées et visibles (dashboard, pas dans un coin)
+- [ ] Les secrets utilisent OIDC — zéro credential long-lived
+- [ ] Les runners sont éphémères — rien ne survit entre deux builds
+- [ ] Concurrency groups — pas deux pipelines en parallèle sur la même branche
+- [ ] Le pipeline bloque sur flaky test detection (> 2% de flaky rate = quarantaine automatique)
+- [ ] L'artefact de build est immutable et signé (hash + signature vérifiés au déploiement)
+
+## Anti-patterns
+### Branches longue durée
+**Ce qu'on voit :** un dev travaille 2 semaines sur `feature/big-refactor`. Merge conflict de 200 fichiers. Tests jamais lancés ensemble.
+**Pourquoi c'est dangereux :** le "I" de CI, c'est l'intégration. Si le code n'est pas intégré au trunk au moins 1×/jour, ce n'est pas de la CI. Le merge final est un événement traumatique — les bugs apparaissent tous en même temps, impossible de bisecter proprement.
+**Faire plutôt :** trunk-based development. Branches ≤ 1 jour. Feature flags pour cacher le code incomplet. Petits commits fréquents — le diff est la meilleure défense contre les bugs.
+
+### Pipeline vu comme un checklist et non une contrainte
+**Ce qu'on voit :** lint → test → build → deploy, séquentiel. Le pipeline met 20 min et personne ne se demande pourquoi c'est lent.
+**Pourquoi c'est dangereux :** un pipeline lent n'est pas juste chiant — il tue la boucle de feedback. Les devs ne poussent plus, ils accumulent, les PRs grossissent, la CI devient un bottleneck systémique. C'est la théorie des contraintes : le pipeline EST la contrainte.
+**Faire plutôt :** traiter le pipeline comme un système à optimiser. Paralléliser tout ce qui peut l'être. Investir dans le cache. Splitter les tests lents. CI < 5 min — si c'est pas possible, c'est que l'architecture de test a un problème.
+
+### Pipeline non versionné
+**Ce qu'on voit :** le pipeline est configuré dans l'UI GitHub Actions, pas dans `.github/workflows/`. Ou pire : un Jenkins configuré à la main.
+**Pourquoi c'est dangereux :** le pipeline n'est pas reproductible. Si le runner crashe, personne ne sait le reconstruire. Pas de code review sur les changements de pipeline. Le pipeline devient un snowflake.
+**Faire plutôt :** pipeline as code — dans le repo, revu comme du code. Tout changement de pipeline passe par une PR. Le pipeline se teste lui-même (les changements de CI s'exécutent sur la PR qui les propose).
+
+### Flaky tests ignorés
+**Ce qu'on voit :** "ah ce test faille parfois, relance le job". Le pipeline a un taux de succès de 70% et tout le monde rerun jusqu'à ce que ça passe.
+**Pourquoi c'est dangereux :** un test flaky tue la confiance dans le pipeline. Quand le rouge ne veut plus dire "bug", les vrais bugs passent au travers. Les devs développent une tolérance à l'échec — c'est la mort lente de la CI.
+**Faire plutôt :** quarantaine automatique. Un test qui faille > 2% du temps est isolé dans une suite "quarantaine". Le pipeline principal bloque sur vrai rouge. La quarantaine est traitée comme dette technique prioritaire.
+
+## Patterns
+### OIDC
+**Quand :** tout pipeline qui parle à un cloud provider.
+**Comment :** GitHub Actions → OIDC token → AWS IAM / GCP WIF → credentials temporaires (< 1h). Zéro secret stocké. Rotation automatique. Si le token fuit, il expire avant d'être utilisable.
+
+### Matrix build
+**Quand :** bibliothèque ou outil utilisé sur plusieurs versions/OS.
+**Comment :** `matrix: { node: [18, 20, 22], os: [ubuntu, macos] }`. Chaque combinaison est un job indépendant. Pas de "ça marche sur ma machine" quand la CI couvre 3 OS.
+
+### Concurrency groups
+**Quand :** éviter les interférences entre runs.
+**Comment :** `concurrency: { group: deploy-${{ github.ref }}, cancel-in-progress: true }`. Un seul déploiement à la fois par branche. Le nouveau run annule le précédent. Évite les race conditions de déploiement.
+
+### Flaky test quarantine
+**Quand :** suite de tests avec > 100 tests.
+**Comment :** chaque test a un compteur de flaky (fail suivi de pass sans changement de code). Si > 2% sur 100 runs → déplacé en `quarantine/`. Le pipeline principal ignore cette suite. La quarantaine est revue chaque sprint — chaque test est soit fixé, soit réécrit, soit supprimé.

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

@@ -0,0 +1,14 @@
+---
+name: ciel
+description: Ciel v9 — thin shell. Understand before generating. Verify before claiming done.
+---
+
+# Ciel v9
+
+**Suis les instructions dans CLAUDE.md.** Ce skill ne duplique pas ce qui y est deja.
+
+## Specifique a l'invocation /ciel
+- **Skills domaine** — evalue le contexte, invoque tous les skills pertinents avec `Skill()`. C'est la meme instruction que CLAUDE.md, rappelee ici.
+- **VISIBILITE** — le pipeline est ta checklist mentale, pas un journal public. Pas de tableaux d'etapes, pas de "[CIEL]", pas de "DOCS termine". Sortie visible = resultats, pas la machinerie.
+- **META** — a la fin de la tache, les 3 questions META (stop hook). Si la reponse a "qu'ai-je manque" est une vraie question pour l'utilisateur → pose-la. Si c'est une action logique → fais-la sans demander.
+- **Memoire** — si une decouverte merite d'etre sauvegardee, ecris dans `.ciel/memory/` et rebuild l'index. Ne pas juste dire "je devrais sauvegarder" — sauvegarde.