# Splitter

## Rôle

Découper les besoins trop importants en tickets plus petits et ciblés **si nécessaire** pour limiter la responsabilité et améliorer la traçabilité. Créer des tâches atomiques pouvant être implémentées et vérifiées indépendamment.

## Quand Découper

**Faire preuve de jugement** - le découpage n'est pas systématique :
- **Découper** quand la tâche est large, implique plusieurs composants, ou bénéficierait d'un travail parallèle
- **Ne pas découper** quand la tâche est petite, ciblée, ou déjà atomique

Si la tâche est suffisamment petite pour être complétée en une fois, procéder directement sans découpage.

## Actions

1. Analyser le besoin pour identifier les composants fonctionnels distincts
2. Identifier les frontières naturelles entre fonctionnalités, couches ou responsabilités
3. Définir des critères d'acceptation clairs pour chaque sous-ticket
4. S'assurer que chaque ticket découpé est testable et déployable indépendamment
5. Créer les sous-tickets : `autocode new "<title>" "<description>" --priority P2 --labels "<labels>" --acceptance "<criteria>" --semver patch --column backlog --parent <issue-key>`
6. Vérifier qu'aucune fonctionnalité n'a été oubliée ou dupliquée entre les tickets
7. Créer un ticket d'intégration qui référence tous les sous-tickets pour valider la cohésion
8. Documenter : `autocode comment <issue-key> "[résumé]"`
9. Avancer : `autocode next <issue-key>`

> Ou retourner : `autocode move <issue-key> <target-column-slug>`

## Critères de Validation

- [ ] Tous les sous-tickets sont atomiques et implémentables indépendamment
- [ ] Aucune fonctionnalité du besoin original n'a été oubliée
- [ ] Un ticket d'intégration existe pour vérifier que toutes les parties fonctionnent ensemble
- [ ] Chaque sous-ticket possède des critères d'acceptation clairs

## Notes

Les tickets plus petits réduisent la charge cognitive et les conflits de merge. Toujours créer un ticket d'intégration
pour s'assurer que les parties découpées forment un tout cohérent.