Pipeliner Client

### Problème
Actuellement, les développeurs et autres rôles (Designer, PO, etc.) doivent manuellement créer des PR et faire avancer les statuts des tickets Redmine. Cela ralentit le workflow et introduit des risques d'erreurs ou d'oublis dans les transitions.

### Contexte
Le client souhaite automatiser ces processus via **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** vers la branche `dev` avec du code conforme aux bonnes pratiques (TDD, architecture hexagonale, atomic design).
- **Faire avancer automatiquement les statuts** des tickets Redmine selon les actions menées, **via les transitions autorisées** (`allowed_statuses`).
- **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 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 agents génèrent code/design et créent une PR vers `dev` avec description automatique (lien ticket Redmine + résumé) et labels pertinents (`frontend`, `design`, …). Les PR sont bloquées avant `preprod`/`master` (commentaire automatique pour validation humaine).
4. **Transitions de statut (toutes via `allowed_statuses`)** :
- Designer → `Design` (depuis `Spec`).
- Senior Dev → `In development` (depuis `Design` ou `Spec` si pas d'étape design).
- Senior Dev → `QA`.
- QA → `Preprod` (si validé) ou retour `In development` (si rejeté).
5. **Verrouillage** : les agents ne modifient pas 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é).

### 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]` 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 des mockups, prend des captures d'écran, **les joint au ticket** (pièces jointes Redmine), puis effectue la transition `Spec → Design`.
- [ ] Les agents créent des PR vers `dev` avec description automatique (ticket lié + résumé) et labels pertinents ; code conforme (TDD, hexagonal, atomic design).
- [ ] Les agents font les transitions de statut **uniquement à partir de `allowed_statuses`** (aucun id/nom codé en dur) :
- Designer → `Design` ; Senior Dev → `In development` ; → `QA` ; QA → `Preprod` ou retour `In development`.
- [ ] 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 couvrent : création de PR par les agents ; transitions de statut (dont `Spec → Design → In development`) ; verrouillage selon le statut ; comptage correct de `Design` dans l'aggregator `by_stage`/`open_total`.
- [ ] Vérification live sur prod : un ticket en `Design` est **compté** dans `by_stage`/`open_total` et s'affiche avec la **bonne colonne + le bon libellé** (pas « Submitted »).
- [ ] La documentation est mise à jour : liste des agents et rôles ; workflow des statuts (avec `Design`) ; invocation `/agent [rôle]`. Le tableau du spec gouvernance §2 et du factory-spec §4.2 sont mis à jour avec `Design`.