Référence

Les modules

scrumia-core — le noyau

Ne remplit aucun slot et ne fait rien par lui-même. Il décrit la composition et la rend lisible pour les agents. Le seul module obligatoire.

scrumia-rules — no slot

Situé aux côtés de scrumia-core : le format de hiérarchie des règles lui-même — index, guides, décisions — qui permet à une compétence de connaissance d'un module, ou aux conventions propres d'un projet, de ne charger que le guide vers lequel une tâche est routée plutôt qu'un seul fichier qui grossit. Ne remplit aucun slot. Ne suppose rien au-delà de scrumia-core. Coûte une couche de plus à bien concevoir — une section est un surcoût en dessous de trois préoccupations distinctes.

scrumia-specs — slot specs

Specs par feature, orientées TDD. Un catalogue de fichiers contextuel plutôt qu'un document unique. Présume que les spécifications vivent dans le dépôt à côté du code. Coûte plus de jugement lors de la rédaction qu'un modèle fixe.

scrumia-github-project — slot tracker

Issues, sous-issues, colonnes de GitHub Projects, branches et PRs. Un hook PreToolUse bloque les fichiers d'état dans le dépôt. Présume un gh authentifié. Coûte une dépendance GitHub stricte et rien en mode hors ligne.

scrumia-teams — slot team

Chaque limite est une ligne de refus — sans elle, les trois s'effondrent en un généraliste et la division cesse de s'auto-financer. Trois n'est pas un nombre magique : les rôles sont activés, désactivés et ajoutés par configuration. Éteindre l'un d'eux est un compromis documenté, pas une régression.

scrumia-discovery — slot discovery

scrumia-impl-rust — slot implementation

États invalides rendus impossibles, Result aux limites, erreurs typées par couche. Refuse unwrap() en production, les clones qui calment l'analyseur d'emprunt, les traits à implémenteur unique.

scrumia-impl-solidjs — slot implementation

Réactivité à grain fin sans réflexes React, tests de composants comportement-d'abord, structure par feature. Refuse les props destructurées, les effets utilisés comme dérivations, les composants qui récupèrent les données.

scrumia-impl-reactjs — slot implementation

Server Components par défaut, Actions pour les mutations, état dérivé au rendu, tests de composants comportement-d'abord. Refuse useEffect pour l'état dérivé, le DOM impératif, les effets là où un gestionnaire d'événement suffit, "use client" non nécessaire.

scrumia-tdd — no slot

Affine un point du contrat d'implémentation : comment nous testons. Le cycle opérationnalisé pour un agent, la limite des mocks, la cartographie AC-to-test.

scrumia-solid-principles — no slot

Affine un point du contrat d'implémentation : quels principes de conception. Les cinq principes, chacun avec sa limite d'application — la sur-application est auditée au même niveau que les violations.

scrumia-tanstack-query — no slot

Affine un point du contrat d'implémentation : comment l'app communique avec le serveur et cache ce qu'elle récupère — query keys, invalidation, optimistic updates, la limite qui sépare l'état serveur de l'état purement client. Porté d'une utilisation réelle monorepo : 9 guides, 13 décisions. Présume une stack que TanStack Query livre (React, Solid, Vue, Svelte). Coûte un modèle de caching à apprendre — les compétences d'audit et de refactorisation qui mesureraient et fermeraient l'écart ne sont pas encore construites.

scrumia-rhf — no slot

Gestion déclarative des formulaires pour les apps React utilisant React Hook Form. Refuse un formulaire sans resolver, useState + onChange là où register() couvre déjà, et la lecture d'état via le DOM. Scopé à scrumia-impl-reactjs ; une app SolidJS ne paie rien.

scrumia-compound-design — no slot

Le motif de composants composés, indépendant du framework. Un parent expose ses parties par une seule API, les enfants atteignent le parent par contexte (ou son équivalent — provide/inject, signals, un service), et les sous-composants voyagent avec le parent plutôt que d'être éparpillés sur des chemins de modules. Documenté côte à côte pour React, Vue, Solid et Angular, dans l'idiome de chaque framework.

scrumia-design — slot design

Identité, tokens et composants vivent dans le dépôt ; un projet Claude Design est la surface de revue, pas la source de vérité. Une règle en dessous : une valeur que les tokens ne portent pas est un constat, jamais une exception écrite en dur. Fournit le rôle permanent designer — le seul module à le faire depuis l'extérieur du slot team, parce qu'un rôle sans design system à garder jugerait au goût.

scrumia-zod — no slot

La validation à l'exécution, à la frontière de confiance. Le type est dérivé du schéma plutôt qu'écrit à la main à côté, le parsing se fait là où des données non fiables entrent plutôt qu'à chaque appel interne, et un schéma dont un utilisateur lit l'échec porte un message ciblé sur le champ. Cité contre Zod épinglé à la v4.

scrumia-html-css — no slot

La capacité HTML, CSS et accessibilité pour une application couverte. Trois règles de refus et une compétence d'audit : un élément sémantique quand les deux expriment la même intention, un widget interactif qui utilise l'élément dont le contrat correspond à l'action, et un test qui interroge ce que rencontre une technologie d'assistance. Ciblée sur React et SolidJS par défaut ; un projet qui ne tourne sur aucun des deux n'en supporte pas le coût.

scrumia-gradle — no slot

Gradle l'outil de build, énoncé dans ses termes. Huit refus ou normes : DSL Kotlin plutôt que Groovy, catalogue de versions comme l'unique endroit où vivent les versions, forme d'un plugin de convention (plugin script précompilé dans un composite build-logic), configuration paresseuse des tâches, caches de build et de configuration, builds composites pour les siblings locaux, pluginManagement, et tâches de documentation branchées sur le cycle de vie. L'application spécifique à Kotlin Multiplatform de ces règles appartient à scrumia-kotlin-multiplatform-mobile, cité ici seulement comme l'endroit où la forme s'applique.

scrumia-material3 — no slot

Material 3 le système d'UI, énoncé dans ses termes. Huit refus ou normes : Compose comme boîte à outils par défaut et Views comme choix explicite avec une justification énoncée ; tokens depuis MaterialTheme.colorScheme, Typography, Shapes, elevation, et le système de couches d'état — jamais depuis des littéraux hexadécimaux ; composants depuis androidx.compose.material3.* — jamais construits depuis des primitives ; couleur dynamique comme option par défaut sur Android 12+ ; cibles tactiles de 48dp × 48dp ; ratios de contraste de 4.5:1 pour le texte courant et 3:1 pour le grand texte ; et contentDescription sur chaque contrôle icon-only.

scrumia-kotlin-multiplatform-mobile — slot implementation

Le preset de composition Kotlin Multiplatform Mobile. Six refus : expect/actual reste dans commonMain pour le contrat et dans le source set plateforme pour l'implémentation ; la disposition des source sets garde le code plateforme dans son propre source set ; les tests plateforme et les dépendances partagées vivent là où ils compilent pour chaque target ; un pod Cocoapods est déclaré une seule fois entre le module KMP et le projet iOS ; la liste des targets est celle du DSL Gradle, pas celle qu'un IDE invente ; le câblage Gradle passe par le DSL source-set du plugin Kotlin Multiplatform.

scrumia-ktor — no slot

Les règles de serveur et client HTTP pour un code base Ktor. Neuf refus ou normes : la surface de l'application est un seul bloc routing {} découpé en fonctions d'extension de route imbriquées ; ContentNegotiation est installé une fois par application et par client ; un HttpClient par dépendance distante, construit une fois et fermé une fois ; l'authentification est install(Authentication) { name -> ... } avec des fournisseurs nommés ; les tests de route tournent sur testApplication {} ; ports, hôtes, secrets et URLs viennent de environment.config ; une route streaming énonce si elle est WebSocket ou SSE ; le logging de requêtes est install(CallLogging) avec un filtre ; et un HTTP non-2xx est converti en erreur de domaine à un endroit nommé.

scrumia-kotlin — slot implementation

Les règles de langage Kotlin idiomatique. Six refus ou normes : var seulement quand val ne peut pas porter l'invariant ; !! seulement avec une preuve locale énoncée et jamais sur un platform type (T!) lu comme Kotlin ; concurrence structurée avec scopes explicites, pas de GlobalScope.launch hors du bootstrap, pas de CancellationException avalé ; data class pour les valeurs, sealed interface pour les taxonomies fermées, value class pour les wrappers type-safe ; fonctions top-level pour les utilitaires stateless, expressions object seulement pour les vrais singletons ; internal comme frontière de module (pas package-private), public seulement sur une surface destinée à traverser une frontière publiée.

scrumia-effect — no slot

Les effets comme valeurs, pas comme exceptions — la discipline des effets typés. Six refus : chaque règle nomme l'approche qu'elle informe (Result, Either, IO/suspend, effect.website, ou niveau discipline) ; les quatre approches sont empilées, jamais substituées ; effect.website est cité par URL et jamais encapsulé ; les échecs récupérables empruntent le chemin de valeur, pas le throw ; le retry est une donnée sur l'échec composée comme fonction sur l'effet, pas une boucle try/catch ; les environnements et layers (là où ils s'appliquent) remplacent les dépendances style service-locator à la frontière d'effet.

scrumia-functional-programming — no slot

Le paradigme de programmation fonctionnelle, neutre en langage. Six refus : une impureté glissée au-delà d'une frontière non nommée ; une fonction partielle dont la signature accepte une entrée pour laquelle elle ne peut pas produire de sortie ; une expression dont la valeur dépend de quelque chose que sa forme syntaxique ne nomme pas (une violation de transparence référentielle) ; la mutation par défaut là où une valeur immuable aurait lu pareil et écrit moins ; l'héritage comme mécanisme principal de réutilisation là où la composition aurait été le choix plus petit et plus local ; des effets décrits au moment où ils s'exécutent plutôt que comme valeurs que le programme compose avant l'exécution.

Configuration

.scrumia/config.yaml décrit le projet et ses outils — jamais son état.

project:
  name: "my-project"
  repo: "tibs245/my-project"

modules:
  "tibs245/scrumia:scrumia-specs": {}
  "tibs245/scrumia:scrumia-github-project": {}
  "tibs245/scrumia:scrumia-teams": {}
  "tibs245/scrumia:scrumia-discovery": {}
  "tibs245/scrumia:scrumia-design": {}

apps:
  - name: web
    path: apps/web
    type: frontend
    modules:
      "tibs245/scrumia:scrumia-impl-solidjs": {}
      "tibs245/scrumia:scrumia-tdd": {}
  - name: api
    path: apps/api
    type: backend
    modules:
      "tibs245/scrumia:scrumia-impl-rust": {}
      "tibs245/scrumia:scrumia-tdd": {}
      "tibs245/scrumia:scrumia-solid-principles": {}

settings:
  autonomy:
    level: guided
    auto_merge: none
  specs:
    root: "features"
  tracker:
    columns: [Backlog, Ready for dev, To dev, In progress, In review, Done]
  team:
    roles: [manager, business, tech]
    sprint:
      max_tickets: 5

Deux conventions qui comptent : la table nomme ce qui est présent, donc une capacité dont vous vous passez ne porte aucune clé — et là où la différence entre « pas encore choisi » et « délibérément sans » compte, elle se dit en commentaire, à la place de la clé. Et chaque module documente les clés qu'il lit sous settings : un paramètre implicite est celui que vous ne pouvez pas changer.

Modules d'implémentation et modules qui les affinent

Le choix le plus personnel. Une app liste les modules sur lesquels elle s'appuie — son module d'implémentation, et autant d'autres qui affinent un point de ce que celui-ci dit. Deux développeurs compétents peuvent avoir des points de vue opposés ici et aucun n'a tort, c'est exactement pourquoi ce sont des modules remplaçables plutôt que des règles du noyau.

Le contrat

Une compétence que l'agent charge avant d'écrire du code dans cette application, couvrant quatre choses :

1. Comment vous testez — quel niveau pour quel changement, ce qui est stubé et ce qui ne l'est pas, comment un AC-n devient un test
2. Quels principes de conception — nommés et situés. « Nous appliquons SOLID » ne guide personne ; un principe sans limite devient un réflexe, et les réflexes produisent une abstraction inutile
3. Comment le code est organisé — suffisamment précis pour qu'un agent place un nouveau fichier sans hésiter
4. Ce qui est refusé — la partie la plus utile, et la plus souvent ignorée. Un agent qui sait ce qui est rejeté se corrige lui-même

Comment ils se composent

Un module peut affiner un point nommé de ce contrat — scrumia-tdd affine « comment vous testez », scrumia-solid-principles affine « quels principes de conception » — et livrer les compétences de référence, d'audit et de refactorisation qui vont avec. Le module d'implémentation situe chacun pour sa pile. Une règle de précédence : spécifique bat générique — le module d'implémentation plutôt que celui qui l'affine, le remplacement de projet plutôt que les deux.

Surcharger sans forker

Chaque module documente ce qu'il lit sous ses propres params:, plus un fichier de remplacement de projet optionnel (.scrumia/modules/<module>.md) dont il honore le contenu plutôt que ses propres règles. Un module n'offrant ni l'un ni l'autre est forké au premier désaccord — et ce fork ne voit jamais de mise à jour.

Hiérarchie des règles

Chaque compétence de connaissance devient un index de routage plutôt qu'un seul fichier lourd : 00-index.md chargé en premier et toujours, guides/NN-topic.md chargé seulement à la demande, decisions/D-NN-slug.md ouvert seulement quand une règle est contestée. Un section.json déclare les globs qu'une section gouverne. Dans un monorepo, le path d'une app dans apps[] ancre quelles sections s'appliquent où — la même précédence spécifique bat générique, un niveau plus bas. Voir scrumia-rules plus haut et ADR-0011.

Écrire un module

Trois règles, pas plus :

1. Remplir un slot — un existant, ou un nouveau que vous définissez et documentez
2. Documenter vos paramètres sous settings.<slot>
3. Fournir votre ligne CLAUDE.md — la phrase qui dit à un agent ce dont il a besoin sans vous lire

Et une interdiction : ne jamais supposer qu'un autre module est présent. Si une capacité manque, dites-le et proposez l'étape suivante plutôt que d'échouer.

# valider avant de publier
claude plugin validate ./plugins/scrumia-core
claude plugin validate .

# essayer sans installer
claude --plugin-dir ./plugins/scrumia-core

Un nouveau slot est justifié quand un vrai projet le remplirait différemment. Sinon, c'est une compétence de plus dans un module existant.