l'exécution, en détail

Un déroulé complet

La composition de référence, étape par étape. Chaque étape nomme le module qui la porte.

Sa forme

Human     │ demande, défi, brainstorm
          ▼
discovery │ cadrage → issues + branche portant les specs
          ▼
tracker   │ affinement → Ready for dev, ou sous-issues par contexte
   ↕      │   ↳ mobilise les rôles quand leur réponse change le ticket
team      │
          ▼
Human     │ valide les designs qui sont douteux, critiques ou risqués
          ▼
team      │ manager construit le sprint avec l'équipe → To dev
          ▼
team      │ workflows dynamiques : implémentation, revue, QA
   ↕      │   ↳ l'implémentation suit le module d'implémentation de l'app
impl      │     et les modules intégrés dans l'app
          ▼
Human     │ revue PR, test → Done

Étape par étape

Un humain apporte une demande humain

Une idée, un problème, une intuition. Le cadrage met en question : le problème existe-t-il ? cela le résout-il ? qu'est-ce qui devient impossible ? où sont les cas limites ? qu'est-ce qui est supposé mais non dit ?

Le point unique où l'attention humaine soutenue paie — et où elle coûte le moins.

/scrumia-discovery:scrumia-brainstorm

Le cadrage produit des issues et une branche de specs agent

Les features business d'abord, puis les features app — une par app, jamais deux. Puis les issues.

Les specs sont expédiées sur une branche specs/<slug> dans une PR ouverte : le design est examiné dans le même outil que le code, et l'affinement commence à partir de quelque chose de fixe plutôt qu'une conversation mémorisée.

/scrumia-discovery:scrumia-split

L'affinement rend le ticket exécutable agent

Quatre conditions, toutes vérifiables :

Une feature de rattachement existe et est à jour
Les critères d'acceptation sont écrits, identifiés AC-n, et peuvent échouer
Le périmètre d'impact est connu : quelles apps, quels fichiers
Aucune question ouverte ne bloque le début

Les rôles avec la vue plus large sont mobilisés quand leur réponse change le ticket — pas pour le valider simplement. Le ticket peut se diviser en sous-issues par contexte : un par app, puisque le contexte d'implémentation diffère.

/scrumia-github-project:scrumia-refine 42

Un humain valide où cela compte humain

Escaladé : une règle métier a dû être inventée, le découpage a changé la demande, le ticket a une large portée, ou un rôle a soulevé une réserve. Tout le reste passe à Ready for dev.

Le manager construit le sprint agent

Un lot de tickets qui ne se heurtent pas — deux tickets sur les mêmes fichiers soit se sérialisent soit fusionnent. L'humain approuve le lot explicitement.

Les workflows dynamiques consomment le sprint agent

Un workflow par ticket, en parallèle, chacun dans son propre worktree. Chacun obtient un numéro de ticket et rien d'autre — il charge son propre contexte.

Charger le contexte par le module de specs
Mettre à jour la spec avant le code, si le comportement change
Implémenter en suivant le module d'implémentation de l'app et les modules branchés à côté — spécifique bat générique
Couvrir chaque AC-n avec un test qui peut échouer
Autorevue, puis revue par les rôles selon le périmètre d'impact
Ouvrir la PR

/scrumia-teams:scrumia-sprint

L'humain revoit et fusionne humain

La PR porte la correspondance critère par critère, les specs qu'elle a changées, les verdicts de revue, et les réserves ouvertes avec leurs issues. Les agents ne fusionnent pas, sauf pour les catégories explicitement listées dans config.

Pourquoi la spec en premier

Écrire la spec d'abord fait remonter les contradictions avant qu'elles ne soient codées — où les corriger coûte le moins. Si une surgit contre une autre feature, l'exécution s'arrête et demande au rôle métier. Elle ne résout jamais une règle d'elle-même : une règle inventée en vol devient la référence de tout le monde sans que personne ne l'ait décidée.

Trois portes

Le coût de validation suit le risque, plutôt que d'être uniforme.

Porte	Qui	Quand
1 — Automatique	CI, linter, tests	Toujours. Bloquant, aucun humain.
2 — Agent	Les rôles	Acheminé par le diff réel, pas le label déclaré.
3 — Humain	Vous	La fusion, sauf délégation explicite.

Quand deux rôles ne sont pas d'accord

Le désaccord est transmis tel quel, non mélangé dans une moyenne. C'est précisément le cas qui a besoin d'un appel humain — le lisser détruit le signal.

Composer l'autonomie

Un réglage explicite dans .scrumia/config.yaml, pas une propriété implicite.

Niveau	L'humain approuve	Quand l'utiliser
`guided`	Le cadrage de chaque ticket et chaque PR	Au démarrage, pendant l'étalonnage
`assisted`	Les PRs seulement	Le mode de croisière prévu
`autonomous`	Les PRs hors de ce que couvre `auto_merge`	Une fois la confiance établie

autonomy:
  level: autonomous
  auto_merge: docs-only   # une PR qui touche seulement de la documentation

Un scalaire, pas une liste blanche

auto_merge est un réglage unique pour tout le projet, pas une liste par catégorie : none (rien ne fusionne sans surveillance, par défaut), docs-only (une PR qui touche seulement de la documentation), ou all.

Ce que fait l'humain

1 — Cadrer et arbitrer

L'IA conteste et propose ; l'humain résout les points bloquants.

2 — Valider les designs risqués

Où le doute, la criticalité ou le risque le justifient.

3 — Approuver le lot du sprint

Lancer un sprint est une décision, pas une conséquence.

4 — Revue et fusion

L'appel final, sauf si une catégorie est explicitement déléguée.

Partout ailleurs, les agents progressent d'eux-mêmes. Si vous vous trouvez à faire autre chose, c'est un signal sur la composition — pas sur votre discipline.

Sur « préparer le prochain sprint tandis que celui-ci s'exécute »

Non automatisable en une session : un subagent ne peut pas faire naître des subagents, et les équipes d'agents sont expérimentales avec une équipe par session. Deux sessions Claude Code sur le même dépôt vous y arrivent — l'une consomme le sprint actuel, l'autre affine le prochain. Puisque l'état réside dans le suivi plutôt que dans la mémoire de session, ils restent cohérents sans coordonner.

Référence Installer