@neikyun/ciel 6.11.2 → 6.13.0

package/assets/skills/research/validate-source-credibility/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: validate-source-credibility
+description: Scores information sources on credibility and freshness — official docs > maintainer blog > GitHub issue > StackOverflow > community forum > random blog. Flags stale content (> 12 months for fast-moving libs). Invoked during research synthesis to rank findings before trusting.
+allowed-tools: WebFetch
+context: fork
+agent: researcher
+---
+
+# validate-source-credibility — Rank sources by trust
+
+## What this covers
+Meta-research skill #4 of 6. Not all sources are equal. Wrong information confidently presented causes downstream failures. This skill scores every finding before it influences code decisions.
+
+## Core principle
+**Credibility is tiered, not binary.** A Tier-1 source (official docs) needs no validation. A Tier-4 source (random blog) is a hypothesis until cross-referenced.
+
+## Inputs
+
+```
+SOURCE_URL: [URL of information source]
+CLAIM: [what the source says]
+TECHNOLOGY: [lib name]
+VERSION: [version the claim is about]
+```
+
+## Credibility tiers
+
+| Tier | Source | Trust |
+|------|--------|-------|
+| **1** | Official docs, GitHub release notes, source code | High — always prefer |
+| **2** | Maintainer blog, maintainer GitHub discussion, conference talk | High for scope; possible bias |
+| **3** | SO accepted (50+ upvotes), GitHub issue with maintainer comment, Reddit consensus | Medium — cross-reference |
+| **4** | Random blog, low-upvoted SO, Medium article without credentials | Low — verify against Tier 1/2 |
+| **5** | AI-generated content, old tutorials without authorship | Zero — flag, do not follow |
+
+## Freshness thresholds
+
+| Library pace | Max age |
+|-------------|---------|
+| Fast (React, Next.js, Ktor, Tailwind) | 12 months |
+| Medium (Rails, Django, Spring) | 18 months |
+| Slow (C, SQL, git) | 36 months |
+| Stable fundamentals | 5+ years |
+
+## Process
+
+### 1. Identify tier from URL + content
+
+### 2. Extract publication date
+
+### 3. Compute freshness (fresh / aging / stale)
+
+### 4. Score: Tier + Freshness → FULL / VERIFY / REJECT
+
+## Common patterns
+
+### Good credibility assessment
+
+```
+## SOURCE CREDIBILITY — https://blog.example.com/react-19-patterns
+
+Tier: 4 (personal blog, no maintainer credential)
+Freshness: aging — published 2025-11-08, 5 months old
+Library pace: fast (React)
+
+Credibility signals:
+- Author unknown in React contributor list
+- No upvote/engagement data available
+
+Trust assessment: VERIFY — cross-reference with official docs before using
+
+Recommendation: Do not trust alone. Verify claim "use() replaces useEffect" against react.dev.
+```
+
+### Bad credibility assessment
+
+```
+Source looks reliable. Use it.
+```
+
+Problems: no tier, no freshness check, no trust assessment.
+
+## Anti-patterns
+
+- **Tier 4/5 trusted alone** — always cross-reference against Tier 1/2
+- **Tier 1 overrides common sense** — if docs contradict source code for installed version, flag conflict
+- **Age penalized unfairly** — stable fundamentals don't age. A 2017 article on TCP sockets is still correct.
+- **Freshness = correctness** — a brand-new blog post can be wrong; an old maintainer article on stable API can be right
+- **AI-generated content not detected** — boilerplate patterns, generic structure, no author credentials → suspect
+
+## How to verify
+
+- [ ] Tier assigned (1-5)?
+- [ ] Publication date extracted?
+- [ ] Freshness assessed against library pace?
+- [ ] Trust assessment given (FULL / VERIFY / REJECT)?
+- [ ] Recommendation states how main session should treat this source?
+
+## When triggered
+
+- By `synthesize-findings` when merging multi-source research
+- On any finding from Tier 3/4/5 before it influences code decisions
+- User request: "how reliable is this source?"

package/assets/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.

package/assets/skills/serverless/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: serverless
+description: "Serverless — fonctions comme unites de deploiement, cold starts, concurrency, API Gateway, Step Functions, cout a la requete. A charger quand on utilise des fonctions serverless."
+---
+
+# Serverless
+
+**Principe premier :** Le serverless n'est pas "pas de serveur" — c'est "le serveur n'est pas ton probleme". Tu echange le controle contre la simplicite operationnelle. Le piege : tu ne controles plus le runtime, la memoire, le reseau, le systeme de fichiers. Chaque hypothese que tu fais sur l'execution ("le /tmp existe", "l'IP est stable", "le process survit entre deux requetes") est une source de bug. Le serverless recompense l'architecture stateless et punit le stateful. Le cout est a la requete — une fonction inefficace coute de l'argent a chaque appel, pas juste du CPU.
+
+## Checklist
+- [ ] Les fonctions sont stateless — pas de donnees persistees dans le filesystem local (/tmp est ephemere)
+- [ ] Les connexions DB/Redis sont hors du handler (global scope, reutilisees entre invocations)
+- [ ] Le timeout est configure explicitement (3s pour API, 30s max pour async) — pas de timeout infini
+- [ ] La memoire est dimensionnee correctement (plus de RAM = plus de CPU, mais plus de cout)
+- [ ] Les cold starts sont mesures (P50/P95) et optimises (bundling, provisioned concurrency si necessaire)
+- [ ] API Gateway / load balancer a un health check independant de la fonction
+- [ ] Les fonctions ont un dead letter queue pour les evenements non traites
+
+## Anti-patterns
+### Fonction monolithe
+**Ce qu'on voit :** une seule Lambda/Cloud Function qui gere toutes les routes. 500MB de code, 3s de cold start. "C'est un microservice."
+**Pourquoi c'est dangereux :** le cold start est proportionnel a la taille du code. Le deploiement est tout-ou-rien. Le debugging est un cauchemar. C'est un monolithe avec les inconvenients du serverless (cold starts, timeouts) sans les benefices (isolation, deploiement independant).
+**Faire plutot :** une fonction par endpoint/operation. Chaque fonction est independante : son propre code, son propre deploiement, son propre timeout. Si une fonction est lente, les autres ne sont pas affectees.
+
+### State cache dans le handler
+**Ce qu'on voit :** `let connection; export const handler = async (event) => { if (!connection) connection = await createDbConnection(); ... }` — le test unitaire passe, la prod echoue aleatoirement.
+**Pourquoi c'est dangereux :** la connection est reutilisee entre invocations mais pas entre cold starts. Le comportement depend de l'etat du container (warm/cold), ce qui est non deterministe. Pire : si la connection est stales (timeout serveur), elle echoue silencieusement.
+**Faire plutot :** initialiser dans le global scope, AVANT le handler. Verifier la sante de la connexion a chaque invocation. Accepter que les cold starts arrivent et les monitoriser.
+
+### Serverless pour tout
+**Ce qu'on voit :** toute l'architecture est en serverless. Y compris un job qui tourne 24/7, un websocket qui reste ouvert 2h, une DB de 10 To.
+**Pourquoi c'est dangereux :** le serverless est optimal pour les charges sporadiques et les pics. Pour une charge constante, le cout par requete est superieur a un serveur. Les timeouts (15 min Lambda, 60 min Cloud Functions) rendent certains workloads impossibles. Les websockets sur serverless = cout eleve et latence variable.
+**Faire plutot :** serverless pour les API, les traitements asynchrones, les cron jobs. Serveur/container pour les charges constantes, les connexions longues, les traitements lourds. Hybride : ce n'est pas l'un ou l'autre.
+
+## Patterns
+### Global scope initialization
+**Quand :** toute fonction qui utilise une connexion externe (DB, Redis, API client).
+**Comment :** initialiser les clients hors du handler. Le runtime reutilise le container pour plusieurs invocations — le code hors handler n'est execute qu'au cold start. SDK clients, connexions, configuration : tout dans le global scope. Le handler ne fait que le metier.
+
+### Step Functions pour l'orchestration
+**Quand :** workflow multi-etapes (paiement → stock → email → facture).
+**Comment :** chaque etape est une fonction separee. Step Functions gere les transitions, les retries, les timeouts, la compensation (Saga pattern). Le workflow est visible dans la console, chaque etape est monitorisee independamment.

package/assets/skills/servers/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: servers
+description: "Servers — reverse proxy comme défense périmétrique, TLS termination, process management, OS hardening. À charger quand on configure des serveurs."
+---
+
+# Servers
+
+**Principe premier :** Un serveur n'est pas la machine où tourne l'app — c'est la première ligne de défense. Ne jamais exposer une application directement. Toujours un reverse proxy devant qui gère TLS, rate limiting, buffering. L'application ne doit voir que du trafic propre et autorisé. Le serveur doit survivre à un reboot, un crash applicatif, et un pic de trafic sans intervention humaine.
+
+## Checklist
+- [ ] Reverse proxy devant l'application (Nginx/Caddy/Traefik) — jamais d'exposition directe
+- [ ] TLS 1.3 avec certificats auto-renouvelés (LetsEncrypt/cert-manager)
+- [ ] Process manager avec restart automatique (systemd) — pas de `node server.js &`
+- [ ] Health check endpoint utilisé par le load balancer (liveness ≠ readiness)
+- [ ] Firewall : seuls les ports 443 et 80 (redirect) sont ouverts, SSH restreint
+- [ ] Log rotation configurée avec retention max — pas de disque plein par les logs
+
+## Anti-patterns
+### Application directement exposée
+**Ce qu'on voit :** `app.listen(443)` — l'app écoute directement sur le port public. Pas de proxy.
+**Pourquoi c'est dangereux :** pas de buffering → un client lent bloque un worker. Pas de rate limiting → pas de protection DDoS basique. Pas de cache statique → chaque requête touche l'app. Le reverse proxy est une couche de défense gratuite.
+**Faire plutôt :** Nginx/Caddy en frontal. Il gère TLS, compression, cache statique, rate limiting. L'app écoute sur localhost:3000 et ne voit que du trafic filtré.
+
+### Redémarrage manuel
+**Ce qu'on voit :** `node server.js` lancé dans un screen/tmux. Crash → app down jusqu'à intervention humaine.
+**Pourquoi c'est dangereux :** tout process crashe un jour. OOM, segfault, exception non catchée. Sans restart automatique, chaque crash = outage non borné. À 3h du matin, personne ne relance.
+**Faire plutôt :** systemd avec `Restart=always` et `RestartSec=5`. Le process manager relance en secondes.
+
+### Logs sans rotation
+**Ce qu'on voit :** `app.log` qui grossit depuis 6 mois. 50 Go. Le disque se remplit.
+**Pourquoi c'est dangereux :** disque plein = tout tombe. L'app ne peut plus écrire, la DB s'arrête. L'outage par manque d'espace disque est le plus évitable de tous.
+**Faire plutôt :** logrotate avec retention 30 jours. Alerte si espace disque < 20%. Les logs sont streamés vers un système centralisé, pas stockés localement.
+
+## Patterns
+### Reverse proxy
+**Quand :** toute application web en production.
+**Comment :** Nginx/Caddy en frontal. TLS termination, compression, cache statique, rate limiting. L'applicatif derrière sur localhost uniquement.
+
+### Health check
+**Quand :** load balancer ou orchestrateur devant l'app.
+**Comment :** `GET /health` → `{"status":"ok","uptime":3600,"db":"connected"}`. Vérifié toutes les 10s. 3 échecs → retirer l'instance du pool.

package/assets/skills/sql/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: sql
+description: "SQL — EXPLAIN ANALYZE comme discipline, CTE & window functions, requêtes N+1, transactions courtes, connection pooling. À charger quand on écrit ou optimise des requêtes SQL."
+---
+
+# SQL
+
+**Principe premier :** Le SQL n'est pas un langage de requête — c'est un langage déclaratif qui décrit CE QUE tu veux, pas COMMENT l'obtenir. Le planificateur de la DB décide du comment. Ton job n'est pas d'écrire "la bonne requête" — c'est d'écrire une requête que le planificateur peut optimiser. La discipline fondamentale est donc : toujours vérifier ce que le planificateur a fait (EXPLAIN ANALYZE). Sans ça, tu codes à l'aveugle. Un index n'existe que si le planificateur l'utilise.
+
+## Checklist
+- [ ] EXPLAIN ANALYZE dans la PR pour toute requête non-triviale — pas après la mise en prod
+- [ ] Pas de `SELECT *` sauf si tu as VRAIMENT besoin de toutes les colonnes
+- [ ] Les JOINs sont vérifiés : chaque condition de JOIN a un index des deux côtés
+- [ ] Pas de N+1 — les données liées sont fetchées en une requête (JOIN, IN, ou LATERAL)
+- [ ] Les transactions sont aussi courtes que possible — tout le calcul est fait avant le BEGIN
+- [ ] Connection pooling : PgBouncer (transaction mode) ou équivalent entre l'app et PostgreSQL
+
+## Anti-patterns
+### N+1 queries
+**Ce qu'on voit :** `for (const user of users) { orders = await db.query('SELECT * FROM orders WHERE user_id = $1', [user.id]) }`. 100 users = 101 requêtes.
+**Pourquoi c'est dangereux :** le N+1 est le tueur silencieux de performance. Chaque requête a une latence réseau (0.5ms en local, 5ms en cloud). 1000 users = 5 secondes juste en overhead réseau. Et le pire : la DB pourrait répondre en 50ms avec un JOIN.
+**Faire plutôt :** `SELECT * FROM orders WHERE user_id = ANY($1)` avec un tableau d'IDs. Ou JOIN. Toujours regarder les boucles qui contiennent des requêtes DB — c'est le pattern N+1.
+
+### EXPLAIN jamais fait
+**Ce qu'on voit :** la requête est lente en production. On ajoute un index "au pif" sur une colonne qui semblait importante. La requête est toujours lente — l'index n'est pas utilisé.
+**Pourquoi c'est dangereux :** sans EXPLAIN ANALYZE, tu ne sais pas ce que la DB fait vraiment. Seq Scan ? Index Scan ? Nested Loop ? Hash Join ? Chaque choix du planificateur a un impact 100-1000× sur la performance. Deviner l'index est du gaspillage.
+**Faire plutôt :** `EXPLAIN (ANALYZE, BUFFERS) SELECT ...` → regarder le plan. Seq Scan sur grosse table → index. Nested Loop sur 100K×100K → Hash Join. L'index se met là où le plan montre un goulot, pas là où "ça semble logique".
+
+### Transaction longue
+**Ce qu'on voit :** `BEGIN; calculApplicatif(); query1(); appelAPIExterne(); query2(); COMMIT;` L'appel API prend 2 secondes.
+**Pourquoi c'est dangereux :** la transaction garde des locks (RowExclusive, ShareLock) pendant toute sa durée. Toutes les modifications concurrentes sur les mêmes rows sont bloquées. 2 secondes de blocage → file d'attente → timeout → erreurs en cascade.
+**Faire plutôt :** tout le calcul, les appels API, la validation métier sont faits AVANT le BEGIN. La transaction ne contient QUE les requêtes DB. Durée < 100ms. Si un appel externe est nécessaire au milieu → reconsidérer le design.
+
+## Patterns
+### CTE (Common Table Expression)
+**Quand :** requête complexe avec des étapes intermédiaires.
+**Comment :** `WITH active_users AS (SELECT id FROM users WHERE last_login > now() - interval '30 days'), user_orders AS (SELECT ...) SELECT ... FROM active_users JOIN user_orders ...`. Le CTE nomme chaque étape — bien plus lisible qu'une soupe de sous-requêtes. `MATERIALIZED` ou non selon que le CTE est réutilisé.
+
+### Window functions
+**Quand :** classement, cumuls, ou comparaison entre rows sans perdre la granularité.
+**Comment :** `ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at)` pour le premier/dernier par groupe. `LAG(price) OVER (PARTITION BY product ORDER BY date)` pour la variation. Pas de self-JOIN coûteux.
+
+### Connection pooling
+**Quand :** toute application en production avec PostgreSQL.
+**Comment :** PgBouncer en transaction mode. L'app se connecte à PgBouncer (local), PgBouncer multiplexe sur PostgreSQL (peu de connexions). 1000 clients → 20 connexions DB. Évite le fork() par connexion de PostgreSQL.

package/assets/skills/supply-chain/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: supply-chain
+description: "Supply Chain Security — dépendances comme surface d'attaque, lockfile integrity, SBOM, SLSA provenance, signed commits. À charger quand on sécurise la chaîne d'approvisionnement."
+---
+
+# Supply Chain Security
+
+**Principe premier :** Chaque dépendance est une backdoor potentielle. La sécurité de la supply chain ne consiste pas à auditer chaque package — c'est impossible. Elle consiste à réduire la surface d'attaque (moins de dépendances), garantir la reproductibilité (lockfiles, pinning), et créer de la traçabilité (SBOM, provenance). Le jour où une CVE sort (et elle sortira), tu dois pouvoir répondre en < 1h à la question : "quels services utilisent ce package ?"
+
+## Checklist
+- [ ] Les dépendances sont épinglées (version exacte ou lockfile commité) — build reproductible
+- [ ] Le nombre de dépendances est surveillé comme une métrique de risque — chaque ajout est justifié
+- [ ] SBOM généré à chaque build (SPDX ou CycloneDX) et requêtable en cas d'incident
+- [ ] SLSA niveau 2 minimum : build isolé, provenance attestée, artefacts signés
+- [ ] Les dépendances non maintenues sont identifiées et remplacées proactivement
+- [ ] Les signatures de commits et tags sont vérifiées — pas de "verified" sur un seul commit sur 100
+
+## Anti-patterns
+### Dépendance non épinglée
+**Ce qu'on voit :** `"express": "^4.18.0"` dans package.json, pas de lockfile dans le repo. Chaque `npm install` peut installer une version différente.
+**Pourquoi c'est dangereux :** un build non reproductible est un build non auditable. Si un attaquant compromet une version mineure de express, ton build l'installe silencieusement. Le hash de ton artefact change sans que tu saches pourquoi.
+**Faire plutôt :** lockfile commité dans le repo. `npm ci` (pas `npm install`) dans la CI. Version exacte pinnée pour les dépendances critiques. Le lockfile est ta déclaration de ce qui tourne en production — traite-le comme tel.
+
+### Dépendance comme choix gratuit
+**Ce qu'on voit :** `npm install left-pad` pour une fonction de 11 lignes. `npm install is-odd` pour `n % 2 === 1`. 1500 dépendances au total.
+**Pourquoi c'est dangereux :** chaque dépendance est un vecteur d'attaque et une dette de maintenance. `event-stream` (2018) a été compromis pour voler des bitcoins. `ua-parser-js` (2021) a été infecté par un malware. Plus tu as de dépendances, plus ta surface d'attaque est grande.
+**Faire plutôt :** évaluer chaque dépendance avant de l'ajouter : est-ce que ça fait plus de 50 lignes de logique non-triviale ? Est-ce maintenu (dernier commit < 6 mois) ? Combien de maintainers ? Préférer la stdlib ou copier 10 lignes (attribuées) plutôt qu'une dépendance pour une fonction triviale.
+
+### SBOM inutilisable en incident
+**Ce qu'on voit :** un SBOM est généré, stocké dans un artefact de build que personne ne sait requêter. Le jour J, retrouver les services affectés prend 4h.
+**Pourquoi c'est dangereux :** un SBOM qui n'est pas utilisable en incident est du théâtre de sécurité. Log4Shell a montré que les équipes qui avaient un SBOM requêtable ont patché en heures. Les autres en semaines.
+**Faire plutôt :** SBOM versionné, stocké dans un registre central requêtable. Test d'audit trimestriel : "Simule une CVE sur le package X. Chronomètre le temps pour lister tous les services affectés." Si > 10 min, le processus est cassé.
+
+## Patterns
+### SBOM comme produit
+**Quand :** toute application en production.
+**Comment :** génération automatisée via Syft/Trivy dans la CI. Format SPDX ou CycloneDX. Stockage dans un registre (Dependency-Track, OWASP). API pour requêter "quels services utilisent log4j ?" en une requête. Le SBOM est un livrable, pas un sous-produit.
+
+### SLSA provenance
+**Quand :** consommateurs qui ont besoin de vérifier l'origine de l'artefact.
+**Comment :** SLSA niveau 2 : build isolé (pas d'accès au réseau arbitraire), provenance signée (attestation du build system). Le consommateur vérifie la signature avant d'utiliser l'artefact. Le but : empêcher qu'un build compromis produise un artefact qui a l'air légitime.

package/assets/skills/system-design/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: system-design
+description: "System Design — estimation back-of-envelope, CAP theorem, trade-offs, scalability patterns, load balancing, caching layers. A charger quand on concoit un nouveau service."
+---
+
+# System Design
+
+**Principe premier :** Le system design n'est pas "choisir les bonnes technologies" — c'est identifier les contraintes et les accepter. Chaque decision d'architecture est un trade-off : consistency vs availability, latence vs throughput, simplicite vs flexibilite. Si tu ne peux pas nommer ce que tu sacrifies, tu n'as pas vraiment designe. La competence cle n'est pas de connaitre les patterns — c'est de savoir estimer (back-of-envelope) pour ne pas resoudre un probleme qui n'existe pas.
+
+## Checklist
+- [ ] Estimation back-of-envelope faite avant tout choix d'architecture (req/s, stockage, bande passante)
+- [ ] Le CAP theorem est arbitre : ce systeme doit-il etre CP ou AP ? Pourquoi ?
+- [ ] Chaque couche a une strategie de scale (vertical, horizontal, ou sharding)
+- [ ] Les single points of failure sont identifies et elimines (ou assumes avec un plan de recovery)
+- [ ] Le caching est place la ou il reduit la latence, pas la ou il est facile a implementer
+- [ ] Les operations lourdes sont async (file d'attente, workers) — l'utilisateur ne bloque pas
+- [ ] Le plan de capacity planning existe : a quel seuil on passe au niveau superieur ?
+
+## Trade-offs : les 3 choix structurants
+
+### SQL vs NoSQL
+
+| | SQL (PostgreSQL, MySQL) | NoSQL (DynamoDB, MongoDB) |
+|--|-------------------------|---------------------------|
+| **Modele** | Schema fixe, relations, JOINs | Schema flexible, pas de JOINs |
+| **Scale** | Vertical puis read replicas | Horizontal natif (sharding) |
+| **Quand choisir** | Relations complexes, transactions ACID, reporting | Acces par cle connu, schema variable, scale horizontal obligatoire |
+| **Piege** | Les migrations deviennent le bottleneck | Tu decouvres que t'as besoin de JOINs → impossible |
+| **Ne JAMAIS faire** | `SELECT * FROM orders JOIN ... JOIN ... JOIN ...` sur 10M rows | Utiliser NoSQL "au cas ou" sans avoir mesure le besoin de scale |
+
+### Sync vs Async
+
+| | Sync (HTTP/gRPC) | Async (queues/events) |
+|--|------------------|----------------------|
+| **Consistance** | Immediate (le client sait tout de suite) | Eventuelle (le client sait plus tard) |
+| **Couplage** | Le caller attend le callee | Decouple temporellement |
+| **Quand choisir** | L'utilisateur attend la reponse | Operation lourde, notification, propagation |
+| **Piege** | Le timeout tue tout (si B est lent, A est lent) | Debugging : ou est l'event ? Qui l'a traite ? |
+
+### Monolithe vs Microservices
+
+| | Monolithe | Microservices |
+|--|----------|--------------|
+| **Deploy** | 1 artefact | N artefacts independants |
+| **Scale** | Tout ou rien | Par service (le checkout scale, pas l'auth) |
+| **Complexite** | Dans le code (couplage) | Dans le reseau (latence, serialisation, erreurs) |
+| **Quand choisir** | Equipe < 20, domaine stable, pas de besoin de scale independant | Equipes autonomes (> 5 equipes), modules qui scalent differemment |
+| **Piege** | Le monolithe devient un "big ball of mud" (pas de frontieres internes) | 12 services pour 3 devs : le cout de coordination > benefices |
+| **Regle** | Commencer monolithe modulaire. Extraire en service UNIQUEMENT quand la douleur est prouvee. |
+
+## Anti-patterns
+### Designer pour Google
+**Ce qu'on voit :** sharding, event sourcing, CQRS, 12 microservices — pour 100 utilisateurs.
+**Pourquoi c'est dangereux :** la complexite que tu construis aujourd'hui est la dette que tu paieras demain. Chaque couche ajoute des points de defaillance.
+**Faire plutot :** estimation back-of-envelope. "100 req/s x 50ms = 5 workers suffisent. Une DB avec read replicas tient 10 000 req/s. Pas besoin de sharding avant 100k req/s." Le design evolue avec la charge.
+
+### Single point of failure ignore
+**Ce qu'on voit :** un load balancer, une DB, une region. "On verra quand ca tombera."
+**Pourquoi c'est dangereux :** tout tombe. Un SPOF qui tombe = 100% du service down.
+**Faire plutot :** redondance sur chaque couche. Multi-AZ, replicas, failover automatique. Si un composant ne peut pas etre redondant, documenter explicitement pourquoi.
+
+### Pas d'estimation avant de coder
+**Ce qu'on voit :** un endpoint cree sans savoir combien de req/s il va prendre. En production, ca s'effondre.
+**Pourquoi c'est dangereux :** sans estimation, le choix d'architecture est arbitraire. SQL vs NoSQL, sync vs async — ces decisions dependent des ordres de grandeur.
+**Faire plutot :** estimation en 5 min : req/s x pics, taille payload x volume, latence acceptable. Des ordres de grandeur. Si les ordres changent d'un facteur 10, le design change.
+
+## Patterns
+### Back-of-envelope estimation
+**Quand :** avant tout choix d'architecture.
+**Comment :** 3 calculs. (1) Throughput : req/s / temps de traitement = workers necessaires. (2) Storage : req/s x taille par req x retention = volume disque. (3) Network : req/s x taille de reponse = bande passante. Toujours x10 pour la marge. Si les chiffres sont petits, rester simple.
+
+**Mise en place :** (1) Lister les endpoints/operations. (2) Estimer les req/s en pic. (3) Multiplier par la taille de payload. (4) Verifier que chaque couche (LB, app, DB, cache) tient ces chiffres. (5) Documenter les seuils de passage a l'echelle superieure (ex: a 1000 req/s → add read replica).
+
+### Consistent hashing
+**Quand :** sharding avec redistribution minimale quand on ajoute/supprime un nœud.
+**Comment :** ring de hash. Chaque cle → premier nœud dans le sens horaire. Ajout d'un nœud ne redistribue que les cles voisines (pas tout le keyspace).
+
+**Mise en place :** (1) Choisir une fonction de hash (SHA-256, MD5 tronque). (2) Placer les nœuds sur le ring. (3) Pour chaque cle, hash → premier nœud dans le sens horaire. (4) Pour la redondance, chaque cle va sur N nœuds consecutifs (replication). (5) Ajouter/supprimer un nœud ne deplace que ~K/N cles. Utilise par CDN, caches distribues, partitions DB.
+
+### Backpressure
+**Quand :** un producteur est plus rapide que le consommateur.
+**Comment :** refuser explicitement (429/503) plutot qu'accepter et timeout. Rate limiting a l'entree. Queue avec capacite max.
+
+**Mise en place :** (1) Definir la capacite max (ex: 1000 requetes concurrentes). (2) Rate limiter a l'entree (token bucket, sliding window). (3) Queue bornee (taille max, pas infinie). (4) Si file pleine → 429. (5) Le client retry avec exponential backoff + jitter. La backpressure se propage — si le worker est plein, l'API refuse, le client ralentit.
+
+### Cache layers (ou placer le cache)
+**Quand :** latence a reduire sur un chemin critique.
+**Comment :** cache navigateur (Cache-Control headers) → CDN (edge cache) → cache applicatif (Redis) → DB. Chaque couche reduit la latence et la charge sur la couche suivante.
+- **Avantages :** reduction drastique de la latence (DB: 10ms, Redis: 1ms, CDN: 0ms pour le client)
+- **Desavantages :** stale data, invalidation complexe, memoire = cout
+- **Mise en place :** (1) Identifier la hot path. (2) Mesurer la latence actuelle par couche. (3) Ajouter le cache le plus proche du client d'abord (CDN > Redis > local). (4) Definir TTL = fraicheur acceptable. (5) Monitorer hit rate > 80%.

package/assets/skills/tech-leadership/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: tech-leadership
+description: "Tech Leadership — ADR, RFC, architecture reviews, dette technique, mentoring, estimation, roadmap technique. A charger quand on fait du leadership technique."
+---
+
+# Tech Leadership
+
+**Principe premier :** Le leadership technique n'est pas "le dev le plus senior decide" — c'est creer un environnement ou les bonnes decisions emergent de l'equipe. Le tech lead n'est pas un architecte omniscient qui dicte les solutions — c'est un jardinier qui cree les conditions pour que les bonnes pratiques poussent. Les deux livrables principaux sont les ADR (Architecture Decision Records) qui capturent le contexte et le pourquoi des decisions, et la strategie de dette technique (toute equipe a de la dette — la question est de savoir laquelle et a quel prix). Le technicien resout les problemes ; le tech lead rend l'equipe capable de resoudre les problemes sans lui.
+
+## Checklist
+- [ ] Les decisions techniques sont documentees en ADR (contexte, alternatives considerees, decision, consequences)
+- [ ] La dette technique est suivie, budgetee (ex: 20% du sprint), et communiquee aux stakeholders
+- [ ] Les RFC sont le processus standard pour les changements majeurs (> 2 semaines d'effort)
+- [ ] L'estimation est basee sur l'historique (cycle time, throughput) — pas sur des jours/homme devines
+- [ ] Les revues d'architecture sont regulieres (mensuelles) avec des criteres objectifs
+- [ ] Le mentoring est structure : chaque dev junior a un plan de progression avec objectifs mesurables
+- [ ] La roadmap technique est alignee avec la roadmap produit — pas deux planifications paralleles
+
+## Anti-patterns
+### Tech lead = seul decideur
+**Ce qu'on voit :** le tech lead prend toutes les decisions seul. "Je connais le systeme, faites ce que je dis." L'equipe execute sans comprendre.
+**Pourquoi c'est dangereux :** goulot d'etranglement decisionnel. L'equipe devient passive — "je fais ce que le lead dit". Le lead devient le bus factor = 1. Quand il part, la connaissance part avec lui. Les decisions ne sont pas contraintes parce que personne ne les conteste.
+**Faire plutot :** decisions via RFC. L'auteur propose, l'equipe review, le lead approuve ou demande des changements. Le lead est un editeur, pas un auteur. Les decisions sont documentees (ADR) pour que le contexte survive au lead.
+
+### Dette technique = tabou
+**Ce qu'on voit :** l'equipe sait qu'il y a de la dette. Personne n'en parle aux stakeholders. Un jour, tout explose et le sprint "refactoring urgent" dure 3 mois.
+**Pourquoi c'est dangereux :** la dette technique non communiquee est une bombe a retardement. Les stakeholders ne comprennent pas pourquoi "une feature simple prend 3 semaines". La confiance s'erode. L'equipe est en mode pompier permanent.
+**Faire plutot :** la dette technique est un choix economique, pas une honte. La quantifier ("ce module coute 2x plus cher a modifier que la moyenne"). La presenter aux stakeholders comme un risque avec un cout. Budgeter 20% du sprint pour la reduction de dette. Montrer le ROI : "apres ce refactoring, les features sur ce module seront 2x plus rapides".
+
+### Estimation = souhait
+**Ce qu'on voit :** "c'est 3 jours" — base sur rien. Les estimations sont systematiquement x2-x3. Les deadlines sont basees sur les estimations et deviennent des engagements.
+**Pourquoi c'est dangereux :** l'estimation n'est pas un engagement, mais les stakeholders l'entendent comme tel. Le cycle se repete : estimation optimiste → sous-performance percue → pression → estimation encore plus optimiste pour compenser → burn-out.
+**Faire plutot :** estimer en probabilites : "50% de chances en 3 jours, 90% en 7 jours." Utiliser l'historique (cycle time reel, pas estime). Separer estimation (combien de temps) et engagement (quand c'est livre). L'engagement vient apres l'exploration, pas avant.
+
+## Patterns
+### ADR (Architecture Decision Record)
+**Quand :** toute decision architecturale non triviale.
+**Comment :** format standard : Titre, Contexte (pourquoi maintenant), Decision (ce qu'on a decide), Alternatives considerees, Consequences (positives et negatives). Fichier `docs/adrs/NNNN-title.md`. Les ADR documentent le POURQUOI, pas juste le QUOI. Un nouveau membre peut lire les ADR et comprendre l'histoire de l'architecture.
+
+### RFC (Request for Comments)
+**Quand :** changement qui affecte > 1 equipe ou > 2 semaines d'effort.
+**Comment :** document de 2-4 pages. Sections : Motivation, Design propose, Alternatives, Impact (migration, cout, risques). Review period : 3-5 jours. L'auteur n'est pas le decideur — l'equipe (ou les equipes) commentent, le lead tranche. La decision est capturee en ADR.
+
+### Probabilistic estimation
+**Quand :** estimation d'une tache de > 1 jour.
+**Comment :** "J'ai 50% de confiance que ca prendra X jours, 90% que ca prendra Y jours." Le ratio Y/X mesure l'incertitude. Si Y > 3X → l'incertitude est trop grande, faire un spike pour reduire. L'estimation est basee sur des taches similaires passees (historique), pas sur l'intuition.

package/assets/skills/testing/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: testing
+description: "Testing — RED-GREEN-REFACTOR, test pyramid, testing behavior not implementation, FIRST principles, flaky test quarantine. À charger quand on écrit ou planifie des tests."
+---
+
+# Testing
+
+**Principe premier :** Les tests ne sont pas là pour prouver que le code marche — ils sont là pour te permettre de changer le code sans peur. Un test qui ne survit pas à un refactoring n'est pas un test, c'est un otage. Le but ultime n'est pas 100% de couverture — c'est la confiance : si les tests passent, je peux déployer. Si tu ne peux pas déployer après un test vert, les tests ont échoué, pas le code.
+
+## Checklist
+- [ ] RED (test échoue) → GREEN (passe) → REFACTOR — dans cet ordre, toujours
+- [ ] Les tests testent le comportement observable, pas l'implémentation interne
+- [ ] Test pyramid : 70% unitaires, 20% intégration, 10% E2E — pas de pyramide inversée
+- [ ] Chaque test est isolé — pas d'ordre d'exécution, pas de state partagé, pas de dépendance
+- [ ] Les tests sont FIRST : Fast, Isolated, Repeatable, Self-validating, Timely
+- [ ] Flaky test detection : > 2% de flaky → quarantaine automatique → fix ou delete dans le sprint
+
+## Anti-patterns
+### Tester l'implémentation
+**Ce qu'on voit :** test qui mock `repository.findById()` et vérifie qu'il est appelé avec les bons arguments. Le test sait QUELLES méthodes le code appelle, pas ce que le code produit.
+**Pourquoi c'est dangereux :** le test est couplé à l'implémentation. Tu refactores en inline le `findById()` → le test casse alors que le comportement est identique. Ces tests ne donnent PAS la confiance pour refactorer — ils empêchent le refactoring.
+**Faire plutôt :** tester le comportement observable. Input → output. "Given un utilisateur avec id 123, when GET /users/123, then retourne {name, email}". Peu importe si le handler appelle un service ou un repository.
+
+### Mock absolument tout
+**Ce qu'on voit :** DB mockée, Redis mocké, filesystem mocké, horloge mockée. Le test unitaire passe, le test d'intégration n'existe pas. Premier déploiement → explosion.
+**Pourquoi c'est dangereux :** les mocks mentent. Un mock Redis ne vérifie pas le format de la clé. Un mock DB ne vérifie pas la contrainte UNIQUE. Le test passe mais le code est cassé en condition réelle. C'est la fausse confiance — pire que pas de confiance.
+**Faire plutôt :** mocker les frontières lentes/non-déterministes (appels HTTP externes, emails). Tester avec une vraie DB en intégration (testcontainers, pg_tmp). La DB est le composant le plus important à tester réellement.
+
+### Test flaky toléré
+**Ce qu'on voit :** "ce test faille parfois, relance le job". Le pipeline passe au 3ème rerun. Le flaky rate est de 5% mais personne ne le mesure.
+**Pourquoi c'est dangereux :** chaque test flaky érode la confiance dans le pipeline. Quand le rouge ne veut plus dire "bug", les vrais bugs passent. L'équipe développe un réflexe "rerun" au lieu de "investigate". C'est la mort lente de la CI.
+**Faire plutôt :** quarantaine automatique. Flaky > 2% → test déplacé dans une suite séparée. Le pipeline principal reste strict (vert = ok, rouge = bug). La quarantaine est prioritaire — chaque test est fixé, réécrit, ou supprimé.
+
+## Patterns
+### Test pyramid
+**Quand :** toute suite de tests.
+**Comment :** base large de tests unitaires (rapides, isolés, nombreux). Milieu de tests d'intégration (DB réelle, API réelle). Sommet étroit de tests E2E (parcours critiques). Si la pyramide s'inverse (beaucoup d'E2E, peu d'unitaires), le feedback est lent et le debugging est coûteux.
+
+### FIRST principles
+**Quand :** écrire chaque test.
+**Comment :** Fast (< 5ms unitaire, < 100ms intégration), Isolated (pas d'ordre), Repeatable (même résultat à chaque run), Self-validating (assertion, pas de log à vérifier manuellement), Timely (écrit AVANT le code — RED first).

package/assets/skills/tracing/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: tracing
+description: "Tracing — OpenTelemetry, distributed traces, spans, sampling, context propagation. À charger quand on met en place du tracing distribué."
+---
+
+# Tracing
+
+**Principe premier :** Le tracing n'est pas "du monitoring avec plus de détails" — c'est le seul outil qui te permet de voir une requête traverser 5 services et identifier lequel a pris 90% du temps. Sans tracing, chaque service est une boîte noire. Avec tracing, tu as un diagramme de séquence généré automatiquement. OpenTelemetry est le standard — ne pas utiliser de solution propriétaire.
+
+## Checklist
+- [ ] OpenTelemetry SDK configuré dans chaque service — pas de vendor lock-in
+- [ ] Chaque requête entrante génère un span racine avec trace ID unique
+- [ ] Les appels sortants (HTTP, DB, Redis, queue) créent des spans enfants
+- [ ] Le contexte de trace est propagé automatiquement (W3C Trace Context headers)
+- [ ] Sampling configuré : 100% en dev/staging, sampling adaptatif en prod
+- [ ] Les spans contiennent les attributs clés : service, endpoint, userId, status code
+
+## Anti-patterns
+### Tracing = logs améliorés
+**Ce qu'on voit :** des spans manuelles `span.setAttribute("message", "processing order")` — comme des logs déguisés.
+**Pourquoi c'est dangereux :** le tracing n'est pas du logging. Son pouvoir vient de l'automatisme : les spans sont créées automatiquement par l'instrumentation, pas manuellement par le dev. Des spans manuelles = du bruit.
+**Faire plutôt :** laisser l'auto-instrumentation créer les spans (HTTP, DB, gRPC). Ajouter manuellement UNIQUEMENT les spans qui représentent des étapes métier importantes (OrderProcessing, PaymentValidation).
+
+### Pas de sampling
+**Ce qu'on voit :** 100% des traces en production. 10 millions de spans/heure. Coût du stockage x10.
+**Pourquoi c'est dangereux :** coût et volume. La plupart des traces normales n'apportent rien. Seules les traces lentes et les traces avec erreurs sont utiles en prod.
+**Faire plutôt :** sampling adaptatif : 100% des traces avec erreur ou > P95. 10% des traces normales. Assez pour voir les patterns, pas assez pour exploser le budget.
+
+## Patterns
+### OpenTelemetry auto-instrumentation
+**Quand :** tout service en production.
+**Comment :** importer le SDK OTel. Auto-instrumentation pour HTTP, DB, gRPC, queues. Zéro code pour les spans de base. Export vers Jaeger/Tempo/Honeycomb. Standard ouvert — change de backend sans changer le code.
+
+### Span attributes
+**Quand :** chaque span.
+**Comment :** `service.name`, `http.method`, `http.status_code`, `db.system`, `user.id` (pas de PII). Assez pour filtrer et grouper, pas assez pour identifier une personne.