Ajoute le skill raggaroth-senior-dev

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

raggaroth-senior-dev/references/backend-languages.md

@@ -0,0 +1,29 @@
+# Backend : Java, Python, Bash
+
+Points à vérifier en priorité selon le langage. Utiliser la grille de sévérité de SKILL.md.
+
+## Java (8 → 25)
+
+- **Version cible** : vérifier que les features utilisées (records, pattern matching, sealed classes, virtual threads...) correspondent bien à la version de langage réellement ciblée par le module — un usage de feature récente dans un module encore en Java 8/11 est 🔴.
+- Gestion d'exceptions : ne jamais avaler silencieusement (`catch (Exception e) {}`) → 🔴 si ça masque une erreur réelle, 🟠 sinon.
+- Null-safety : préférer `Optional` en retour de méthode plutôt que retourner `null` sans le documenter.
+- Ressources : `try-with-resources` systématique pour tout ce qui implémente `Closeable`/`AutoCloseable` (fichiers, connexions DB, sockets).
+- Concurrence : attention aux collections non thread-safe partagées entre threads ; si virtual threads (Java 21+), vérifier l'absence de `synchronized` bloquant qui annule le bénéfice (pinning).
+- Build : cohérence Maven/Gradle avec le reste du studio, pas de dépendance ajoutée sans justification.
+
+## Python 3
+
+- Typing : encourager les type hints sur les fonctions publiques/API, surtout dans du code partagé entre modules — absence de typing sur une fonction publique = 🟡.
+- Gestion d'erreurs : `except Exception:` nu ou `except:` bare = 🔴 (masque tout, y compris `KeyboardInterrupt`/bugs).
+- Mutable default arguments (`def f(x=[])`) = 🔴, piège classique.
+- Environnements : vérifier la présence d'un fichier de dépendances explicite (requirements.txt / pyproject.toml) et l'absence d'installs globales non versionnées.
+- Context managers (`with`) pour tout ce qui ouvre une ressource (fichiers, connexions DB/PostgreSQL, subprocess).
+- f-strings plutôt que `%` ou `.format()` pour la lisibilité (🔵 suggestion seulement, pas bloquant).
+
+## Bash
+
+- `set -euo pipefail` en tête de script sauf raison explicite de ne pas l'avoir → absence = 🟠 (échecs silencieux en cascade).
+- Toujours quoter les variables (`"$var"`) sauf besoin explicite de split — variable non quotée dans un chemin de fichier = 🔴 potentiel (injection/špace bugs).
+- Éviter de parser `ls` ; préférer les globs ou `find -print0` / `while read -r`.
+- Vérifier les codes de sortie des commandes critiques plutôt que de supposer le succès.
+- Scripts destinés à tourner en CI Gitea ou en conteneur : vérifier l'idempotence (peut être relancé sans effet de bord destructeur).

raggaroth-senior-dev/references/frontend.md

@@ -0,0 +1,19 @@
+# Frontend : React, VueJS
+
+Probablement utilisés côté outillage/tooling interne du studio (dashboards, outils de prod) plutôt que le jeu lui-même — garder ce contexte en tête pour calibrer le niveau d'exigence (outil interne ≠ produit public).
+
+## React
+
+- État : logique métier qui devrait être dans un state manager/hook custom mais traînée dans le JSX du composant = 🟡, 🟠 si ça duplique un état déjà géré ailleurs.
+- `useEffect` : dépendances manquantes ou over-larges dans le tableau de dépendances = 🟠 (bugs de sync ou re-renders inutiles).
+- Clés de liste (`key`) : usage de l'index de tableau comme `key` sur une liste qui peut être réordonnée/filtrée = 🟠 (bugs de rendu subtils).
+- Props drilling excessif (>2-3 niveaux) : suggérer contexte ou composition plutôt que de continuer à faire passer les props = 🔵/🟡 selon la profondeur.
+- Accessibilité de base (labels, alt text) sur les outils internes : 🔵 sauf si l'outil est utilisé par plusieurs personnes régulièrement, alors 🟡.
+
+## VueJS
+
+- Réactivité : mutation directe d'un objet/array réactif sans passer par les méthodes réactives appropriées (selon Options API vs Composition API) → bug silencieux de non-mise à jour = 🟠.
+- Composition API vs Options API : vérifier la cohérence avec le reste du projet plutôt que de mélanger les deux styles dans la même base sans raison = 🟡.
+- Props : toujours typées et validées (`props: { x: { type: String, required: true } }`) plutôt que des props non déclarées = 🟡.
+- Watchers : `watch` profond (`deep: true`) sur un gros objet sans nécessité = 🟡 (coût perf).
+- Cohérence de state management (Pinia/Vuex si utilisé) : pas de state dupliqué entre un store global et un state local qui devrait être dérivé.

raggaroth-senior-dev/references/game-scripting.md

@@ -0,0 +1,25 @@
+# Scripting jeu : C# (Godot/Mono), GDScript, Lua
+
+## C# (Godot/Mono)
+
+- Signaux vs appels directs : préférer les signaux Godot pour le découplage entre nœuds, plutôt que des références directes croisées entre scènes — couplage fort non justifié = 🟠.
+- Cycle de vie des nœuds : vérifier l'usage correct de `_Ready()`, `_Process()` vs `_PhysicsProcess()` (logique physique/mouvement doit être dans `_PhysicsProcess`, pas `_Process` = 🔴 si ça casse le déterminisme physique).
+- `GetNode()` avec chemin en dur fragile aux réorganisations de scène → préférer `[Export]` ou constantes de chemin centralisées (🟡).
+- Allocations dans `_Process`/`_PhysicsProcess` (boucle par frame) : allocation d'objets/listes à chaque frame = 🟠 (pression GC, risque de stutter, critique en pixel-art temps réel).
+- `async`/`await` avec Godot : attention aux tâches qui survivent à la destruction du nœud (`QueueFree`) sans annulation → fuite/crash potentiel = 🔴.
+- Cohérence avec la structure de scènes du projet (ElironWorldDungeons ou autre) : vérifier que le script respecte l'organisation de dossiers déjà en place plutôt que d'en introduire une nouvelle sans discussion.
+
+## GDScript
+
+- Typage statique disponible (`var x: int`, `-> void`) : l'utiliser sur les fonctions publiques/API de nœud, surtout dans du code partagé — absence = 🟡 (perte de perf + autocomplete + détection d'erreurs à l'édition).
+- `@onready var` pour les références de nœuds internes plutôt que `get_node()` répété dans plusieurs fonctions.
+- Éviter la logique lourde dans `_process()` par frame sans nécessité — même remarque que C# sur les allocations en boucle.
+- Signaux : connecter/déconnecter proprement (`connect`/`disconnect`) pour éviter les callbacks fantômes sur des nœuds libérés = 🔴 si ça crash en prod.
+- Cohérence de nommage : `snake_case` pour variables/fonctions, `PascalCase` pour classes/nœuds (convention GDScript standard) — à vérifier si le studio n'a pas dévié explicitement.
+
+## Lua
+
+- Scope des variables : `local` par défaut, variable globale non déclarée volontairement = 🟠 (pollution du scope global, bugs difficiles à tracer, surtout si Lua est embarqué comme langage de modding/scripting).
+- Gestion d'erreurs : `pcall`/`xpcall` autour de tout code exécuté dynamiquement ou venant de scripts externes/mods (si Lua sert à du modding, un script tiers qui plante ne doit pas crasher le jeu) → absence = 🔴 dans ce contexte précis.
+- Tables : attention à la confusion array-like vs map-like dans une même table, source de bugs subtils avec `#`/`ipairs`/`pairs`.
+- Si Lua est utilisé pour du contenu moddable : vérifier qu'aucune fonction dangereuse (accès fichier système, `os.execute`, etc.) n'est exposée au sandbox de script sans contrôle explicite = 🔴 (risque sécurité si mods tiers).

raggaroth-senior-dev/references/infra-devops.md

@@ -0,0 +1,25 @@
+# Infra & DevOps : Docker, Podman, PostgreSQL, Gitea
+
+## Docker / Podman
+
+- Image de base : vérifier une version explicite et pinnée (pas de `latest` en prod/CI) → `latest` non pinné = 🟠.
+- Utilisateur non-root dans le conteneur pour tout ce qui tourne en prod/CI — root par défaut sans justification = 🟠 (surface d'attaque).
+- Multi-stage build pour limiter la taille de l'image finale (surtout pour du Java/Node buildé) — absence sur un build lourd = 🟡.
+- `.dockerignore` présent et cohérent pour éviter d'embarquer des secrets/fichiers inutiles = vérifier systématiquement.
+- Podman vs Docker : si rootless Podman est utilisé (cohérent avec le choix du studio d'éviter le daemon root), vérifier que les volumes/permissions UID/GID sont gérés correctement (mapping utilisateur) plutôt que de forcer du root.
+- Secrets : jamais de secret en clair dans un `Dockerfile`/`docker-compose.yml`/`ENV` versionné = 🔴 systématique.
+
+## PostgreSQL
+
+- Migrations : toute modification de schéma doit passer par un outil de migration versionné (pas d'ALTER manuel non tracé) = 🟠 minimum, 🔴 si ça touche une table en prod sans rollback prévu.
+- Index : vérifier la présence d'index sur les colonnes utilisées en `WHERE`/`JOIN` fréquents avant de valider une requête qui semble lente.
+- Transactions : opérations multi-tables qui doivent être atomiques mais ne sont pas dans une transaction explicite = 🔴 potentiel (incohérence de données).
+- Connexions : pooling de connexions plutôt que d'ouvrir une connexion par requête dans du code applicatif à fort volume.
+- Types : privilégier les types PostgreSQL adaptés (`timestamptz` plutôt que `timestamp` sans fuseau, `numeric` pour les montants plutôt que `float`).
+
+## Gitea (workflow & CI)
+
+- Branch protection sur `main` : vérifier que le workflow proposé respecte la protection de branche déjà en place (cf. préférences de Benjamin sur la hygiène de clés/rotation et les accès agents IA).
+- PR/Issue : cohérence avec la structure EPIC=Milestone / FEATURE=Issue / STORY=checklist item définie dans la skill `agile-master` — ne pas réinventer une autre convention de nommage dans une review.
+- CI (Gitea Actions ou runner équivalent) : tout script de CI doit être idempotent et échouer explicitement (exit code non nul) en cas de problème plutôt que de continuer silencieusement.
+- Clés/déploiement : pour tout ce qui touche l'accès Git d'un agent (SSH, PAT), rappeler la préférence du studio pour des deploy keys ou PAT fine-grained scopés (`Contents: write` + `Pull requests: write`) plutôt qu'un accès large — accès trop large proposé = 🟠.