Feature #27
Updated by Redmine Admin about 2 months ago
### Problème Actuellement, les développeurs et autres rôles (Designer, PO, etc.) doivent manuellement créer des PR et faire avancer mettre à jour les statuts des tickets Redmine. Cela ralentit le workflow et introduit des risques d'erreurs ou d'oublis dans les transitions. transitions de statuts. ### Contexte Le client souhaite automatiser ces processus via en créant **7 agents spécialisés** (CTO, Lead Senior, Senior Dev Fullstack/Backend/Frontend, Designer, PO Marketer) accessibles via `/agent [rôle]`. Ces agents doivent : - **Créer des PR** PR directement** vers la branche `dev` avec du code conforme aux bonnes pratiques (TDD, architecture hexagonale, atomic design). - **Faire avancer **Mettre à jour automatiquement les statuts** statuts des tickets Redmine selon les Redmine** en fonction des actions menées, **via les transitions autorisées** (`allowed_statuses`). menées (ex. : Designer → statut `Design`, Senior Dev → statut `In development`). - **Ajouter un nouveau statut `Design`** dans Redmine pour refléter le travail en cours par le Designer. - **Respecter le workflow CI/CD** (PR → dev → preprod → master) avec validation humaine avant les merges en `preprod`/`master`. > **⚠️ MISE À JOUR (gouvernance des statuts, 2026-06-11)** — le statut **`Design` est RETENU** : pour certaines features, une intégration de maquettes (mockups) précède le développement ; c'est l'**agent Designer** qui produit les maquettes, prend des captures d'écran et les **joint au ticket**. `Design` est donc une véritable étape du pipeline, visible par le client, **entre `Spec` et `In development`**. > > **Deux corrections par rapport à la version initiale de ce ticket :** > 1. **Pas d'`id 15` codé en dur.** Redmine attribue l'id à la création — on ne le choisit pas. Le statut sera créé en admin puis l'id réel sera lu via `GET /issue_statuses.json` et utilisé partout. > 2. **Pas de couleur `#FF6B6B`.** Réutiliser un token `status-*` existant du design system (« no new colors », design v2.3 — cf. `Badge.tsx`). > > Ajouter `Design` est un changement **coordonné sur 4 systèmes / 10 points** (Redmine + workflow, aggregator `STAGE_KEY`, dashboard `RedmineStatus`/`BOARD_COLUMNS`/`STAGE_ORDER`/`mutability`, FE `StageKey`/`stageKey`/`isKnownStatusId`/`Badge`/`TaskStageGroup`, i18n). Oublier un point = échec **silencieux** (ticket décompté à zéro dans l'aggregator ; colonne peinte « Submitted » mais libellée « Design »). Réf. `docs/superpowers/specs/2026-06-11-redmine-status-governance.md` §3, §4, §5.1, §6. ### Comportement proposé 1. **Accès aux agents** : invoqués Invoqués via `/agent [rôle]` dans le chat (ex. : `/agent designer`). 2. **Étape Design (agent Designer)** : - S'applique aux features nécessitant des maquettes avant développement. - L'agent Designer produit les mockups, **prend des captures d'écran et les joint au ticket** (pièces jointes Redmine via l'API, compte de service). - Transition `Spec → Design`. 3. **Création de PR** : les - Les agents génèrent du code/design et créent une PR vers `dev` avec description : - Description automatique (lien au ticket Redmine + résumé) et labels Redmine, résumé des changements). - Labels pertinents (`frontend`, `design`, …). (ex. : `frontend`, `design`). - Les PR sont bloquées avant `preprod`/`master` (commentaire automatique pour validation humaine). 4. **Transitions de statut (toutes via `allowed_statuses`)** 3. **Gestion des statuts Redmine** : - Designer → Ajout du statut `Design` (depuis `Spec`). (id `15`, couleur `#FF6B6B`). - Transitions automatiques : - Designer → `Design`. - Senior Dev → `In development` (depuis `Design` ou `Spec` si pas d'étape design). development`. - Senior Dev → QA → `QA`. - QA → `Preprod` (si validé) ou retour en `In development` (si rejeté). 5. 4. **Verrouillage** : les Les agents ne modifient peuvent pas modifier les tickets au-delà de `Spec` côté dashboard (`TicketLocked`). Les pièces jointes de l'agent Designer en `Design` sont déposées **côté serveur via l'API Redmine** (compte de service), hors garde de mutabilité du dashboard ; le client peut les **consulter/télécharger** (GET, non bloqué). statut `QA`. ### Position de `Design` dans le workflow `Submitted → Spec → **Design** → In development → QA → Preprod → Ready to ship → Shipped` (+ `Blocked` off-ramp). À insérer entre `Spec` et `In development` dans `STAGE_ORDER`. ## Acceptance criteria - [ ] Les 7 agents sont accessibles via `/agent [rôle]` dans le chat et répondent aux prompts. - [ ] Le statut **`Design` est créé en Redmine** (admin) et son **id réel** est récupéré via `GET /issue_statuses.json` (PAS d'id supposé) puis câblé dans les 10 points (cf. spec gouvernance §3). - [ ] `Design` est positionné **entre `Spec` et `In development`** dans le workflow et dans `STAGE_ORDER`. - [ ] La couleur de `Design` **réutilise un token `status-*` existant** (pas de nouvelle couleur ; pas de `#FF6B6B`). - [ ] Les transitions du workflow `Feature` sont configurées en Redmine (Admin → Workflow) pour `Spec → Design → In development`, par rôle (y compris les comptes de service Pipeliner/Jenkins). - [ ] **Agent Designer** : produit prompts des mockups, prend des captures d'écran, **les joint au ticket** (pièces jointes Redmine), puis effectue la transition `Spec → Design`. utilisateurs. - [ ] Les agents créent des PR vers `dev` avec description : - Description automatique (ticket incluant le ticket Redmine lié + résumé) et labels un résumé des changements. - Labels pertinents ; code (ex. : `frontend`, `design`). - Code conforme aux bonnes pratiques (TDD, hexagonal, architecture hexagonale, atomic design). - [ ] Le statut `Design` est ajouté dans Redmine (id `15`, couleur `#FF6B6B`) et positionné entre `Spec` et `In development`. - [ ] Les agents font mettent à jour automatiquement les transitions de statut **uniquement à partir de `allowed_statuses`** (aucun id/nom codé en dur) statuts des tickets selon les règles suivantes : - Designer → `Design` ; `Design`. - Senior Dev → `In development` ; development`. - Senior Dev → `QA` ; QA → `QA`. - QA → `Preprod` ou retour en `In development`. - [ ] Les agents bloquent les modifications sur les tickets dont le statut est au-delà de `QA` (ex. : `Preprod`). - [ ] Les PR sont bloquées avant `preprod`/`master` avec un commentaire automatique pour validation humaine. - [ ] **Câblage complet de `Design` (sinon échec silencieux)** : - Aggregator `STAGE_KEY` (+ libellé `by_stage`). - Dashboard API `RedmineStatus`, `BOARD_COLUMNS`, `STAGE_ORDER`, `mutability` (décision : `Design` verrouillé côté dashboard). - Dashboard FE `StageKey`, `stageKey()` (case), `isKnownStatusId()` (élargir la plage), `Badge.STAGE_STYLES`, `TaskStageGroup.STAGE_ACCENT`. - i18n `tasks.status.*` + libellé court dans `en.ts` (FR hérité). - [ ] Les tests unitaires et d'intégration couvrent : - La création de PR par les agents ; agents. - Les transitions de statut (dont `Spec → Design → In development`) ; verrouillage selon le statut ; comptage correct de `Design` statuts dans l'aggregator `by_stage`/`open_total`. Redmine. - [ ] Vérification live sur prod : un ticket Le verrouillage des tickets en `Design` est **compté** dans `by_stage`/`open_total` et s'affiche avec la **bonne colonne + le bon libellé** (pas « Submitted »). fonction de leur statut. - [ ] La documentation est mise à jour pour inclure : - La liste des agents et rôles ; leurs rôles. - Le workflow des statuts Redmine (avec `Design`) ; invocation le nouveau statut `Design`). - Les instructions pour invoquer les agents via `/agent [rôle]`. Le tableau du spec gouvernance §2 et du factory-spec §4.2 sont mis à jour avec `Design`.