Feature #23
Updated by Redmine Admin about 2 months ago
### Problème Actuellement, les développeurs et les product owners doivent manuellement décider si un ticket Redmine doit être découpé en sous-tâches et spécifier ces sous-tâches. Ce processus est chronophage et sujet à des oublis, surtout pour les tickets complexes (ex. : applications mobiles). ### Contexte Dans le cadre du projet **pipeliner**, nous souhaitons automatiser cette décision en créant un **agent Scrum Master / Dev Spec** invocable par d'autres agents. Cet agent analysera les tickets soumis (`status = "Submitted"`) "submitted"`) pour : - Déterminer si un découpage est nécessaire. - Proposer une décomposition détaillée en sous-tâches si applicable. - Faire avancer Changer le statut du ticket dans le pipeline (`Submitted Redmine (`"submitted" → Spec "spec" → In development`). "ready_for_dev"`). - Mettre à jour le tableau de bord **Pipeliner** et l'**Aggregator** l’**Aggregator** pour refléter ces changements. > **⚠️ MISE À JOUR (gouvernance des statuts, 2026-06-11)** — le statut `ready_for_dev` initialement demandé est **abandonné** : c'est une *frontière* entre `Spec` et `In development`, pas une étape où le travail se trouve. On réutilise le workflow canonique existant (8 statuts, ids 7–14) — voir `docs/superpowers/specs/2026-06-11-redmine-status-governance.md` §5.2. **Aucun nouveau statut.** Les transitions sont pilotées par `allowed_statuses` (jamais d'ids ni de noms codés en dur). ### Comportement proposé 1. **Déclenchement** : l'agent L’agent reçoit un ticket Redmine avec `status = "Submitted"`. "submitted"`. 2. **Passage en Spec** **Changement de statut** : le Le ticket passe en `status = "Spec"` (via la transition autorisée) "spec"` pour indiquer qu'il qu’il est en cours de spécification. 3. **Analyse** : l'agent L’agent applique les règles de découpage (ne (ex. : ne pas découper les bugfix / ou petites améliorations ; améliorations, mais découper les applications mobiles / ou tâches complexes). 4. **Proposition** : si Si un découpage est nécessaire, l'agent l’agent génère une proposition de sous-tâches (JSON) ajoutée et l’ajoute en commentaire Redmine, et crée les sous-tâches (issues enfants, `parent_issue_id`). Redmine. 5. **Spec terminée** **Validation** : Le PO valide/modifie la complétude de la spec est signalée **sans nouveau statut** — `spec_ref` renseigné + `done_ratio` à 100 % sur proposition. Une fois validée, le statut `Spec`. La colonne « Prêt pour le développement » du board ticket passe en `status = la colonne **Spec** à ce moment-là. "ready_for_dev"`. 6. **Démarrage **Mise à jour du dev** tableau de bord** : au moment où Le ticket apparaît dans la colonne **"Prêt pour le développement est pris en charge, l'agent (ou le Senior Dev) fait la transition `Spec → In development`. développement"** de Pipeliner. ### Contraintes - **Aucun nouveau statut Redmine** : on n'utilise que les statuts canoniques `Submitted` / `Spec` / `In development`. - Les sous-tâches conservent L’agent doit conserver la **langue originale** du ticket. ticket pour les sous-tâches. - Les statuts Redmine (`"spec"` et `"ready_for_dev"`) doivent être pris en compte par l’Aggregator et Pipeliner. - Les mutations respectent sur les tickets doivent respecter les règles de verrouillage (ex. : un ticket est éditable uniquement en `Submitted` / `Spec` ; une fois en `In development` il est verrouillé (`TicketLocked` → 403). - Toute transition pas de statut est décidée à partir de `allowed_statuses` retourné par Redmine. modification après `"spec"`). ## Acceptance criteria - [ ] **Passage en Spec** **Changement de statut** : l'agent L’agent passe systématiquement le ticket de `Submitted` `"submitted"` à `Spec` (transition issue `"spec"` avant de `allowed_statuses`) avant l'analyse. commencer l’analyse. - [ ] **Règles de découpage** : l'agent L’agent ne découpe pas `bugfix` / `content_update` / petite amélioration, les tickets de type `bugfix`, `content_update`, ou `petite amélioration`, mais découpe les tickets pour les applications mobiles / ou les tâches complexes. - [ ] **Proposition de sous-tâches** : si Si `should_split = true`, l’agent génère un JSON structuré avec les sous-tâches (titres, descriptions, critères d'acceptation, d’acceptation, dépendances, et estimation répartie) répartie). Ce JSON est ajouté en commentaire Redmine et les sous-tâches sont créées comme issues enfants. Redmine. - [ ] **Spec terminée sans nouveau statut** **Statut final** : la complétude est signalée par `spec_ref` renseigné + `done_ratio Le ticket passe en `status = 100` sur le statut `Spec` (PAS de statut `ready_for_dev`). - [ ] **Démarrage du dev** : "ready_for_dev"` une fois la transition `Spec → In development` est effectuée au moment de la prise en charge du développement (automatique spécification validée (automatiquement si `should_split = false`, après validation PO manuelle si `should_split = true`). - [ ] **Tableau de bord Pipeliner** : les Les tickets en `Spec` `status = "spec"` apparaissent dans la colonne **Spec** (la notion « prêt pour le développement » = Spec complète) ; **"Spec"**, et ceux en `In development` `status = "ready_for_dev"` dans la colonne **In development**. **"Prêt pour le développement"**. - [ ] **Aggregator** : aucune modification du mapping des L’Aggregator reconnaît et affiche correctement les nouveaux statuts nécessaire (workflow inchangé) ; les comptes `by_stage` restent corrects. (`"spec"` et `"ready_for_dev"`). - [ ] **Pilotage par allowed_statuses** **Sécurité** : l'agent ne code Les mutations sur les tickets sont verrouillées après le passage en dur aucun id ni nom de statut ; il lit les transitions légales sur l'issue. - [ ] **Sécurité / verrouillage** : toute `"ready_for_dev"` (erreur `TicketLocked` si tentative de mutation d'un ticket au-delà de `Spec` renvoie `TicketLocked` (403). modification). - [ ] **Tests** : La suite backend (intégration incluse) (incluant les tests d’intégration) doit être verte deux fois sur une même base ; mypy, ruff, de données. Les outils de linting (mypy, ruff) et les tests frontend (tsc, vitest, eslint) doivent également être verts. - [ ] **Déploiement** : vérification Vérification manuelle sur la production via `/browse` (tickets pour confirmer que les tickets apparaissent correctement positionnés dans Pipeliner et Redmine). Redmine.