docs(workflows) : plan d'implémentation + validations Matthieu sur le spec + gitignore dumps locaux

docs/superpowers/specs/2026-05-19-project-workflows-design.md

@@ -2,7 +2,7 @@
 
 **Date** : 2026-05-19
 **Branche** : `feat/project-workflows`
-**Statut** : design validé, en attente de plan d'implémentation
+**Statut** : design validé (2026-05-19, par Matthieu), en attente de plan d'implémentation
 
 ## Reprise sur un autre poste
 
@@ -12,11 +12,11 @@
 > 2. **Ce qui est fait** : design validé avec Matthieu et committé (ce fichier).
 > 3. **Aucun code applicatif n'a encore été écrit.**
 > 4. **Prochaine étape** : invoquer la skill `superpowers:writing-plans` pour transformer ce design en plan d'implémentation détaillé (découpage en tickets ordonnés, dépendances, estimations).
-> 5. **Avant de lancer le plan, vérifier avec Matthieu** s'il a relu le spec et veut des ajustements sur :
->    - Hors scope (§8) — rien d'oublié pour la V1 ?
->    - Fallback `in_progress` pour statuts non-mappables (§3, M2) — OK ou échec migration ?
->    - Suppression d'AdminStatusTab (§5) — OK de tout fusionner dans l'onglet Workflows ?
->    - Ordre des étapes de livraison (§10) — OK ou réordonner ?
+> 5. **Validations Matthieu (2026-05-19)** :
+>    - Hors scope (§8) → MCP `switch-project-workflow` **rapatrié dans la V1** (cf. §6).
+>    - Fallback `in_progress` pour statuts non-mappables → **abandonné**. Seuls les 5 statuts standards existent ; la migration M2 échoue explicitement si elle rencontre autre chose.
+>    - Suppression d'`AdminStatusTab` → **OK**.
+>    - Ordre des étapes de livraison (§10) → **OK**.
 > 6. **Time tracking** : créer un nouveau timer Lesstime au reprise (projet=5 Lesstime, tags=[3 Backend, 9 Gestion projet]).
 > 7. **Fichiers déjà modifiés sur develop (orphelins, pas liés à cette feature)** à ne PAS toucher : `.mcp.json`, `config/reference.php`, `frontend/package-lock.json`, `frontend/pages/profile.vue`.
 
@@ -75,13 +75,13 @@ Trois migrations Doctrine successives :
 **M2 — `add_workflow_to_task_status`**
 - Ajoute `task_status.workflow_id` nullable + `task_status.category` nullable
 - `UPDATE task_status SET workflow_id = <id Standard>` pour toutes les lignes existantes
-- Backfill catégories :
+- Backfill catégories (uniquement les 5 statuts standards existants — confirmé avec Matthieu 2026-05-19) :
   - "À faire" → `todo`
   - "En cours" → `in_progress`
   - "Bloqué" → `blocked`
   - "En attente de validation" → `review`
   - "Terminé" → `done`
-  - Tout autre statut existant non-mappable → `in_progress` (fallback neutre) + log warning
+- La migration **échoue** (exception) si elle rencontre un label non listé → garde-fou explicite contre toute prod qui aurait dérivé.
 - Passe les 2 colonnes en `NOT NULL`
 
 **M3 — `add_workflow_to_project`**
@@ -182,7 +182,7 @@ Security: ROLE_ADMIN
 | `list-statuses` | Ajout d'un param optionnel `projectId?: int`. Si fourni → renvoie les statuts du workflow du projet. Sinon → renvoie tous les statuts avec `workflowId` et `category` ajoutés. Description mise à jour pour mentionner les workflows. |
 | `list-workflows` (nouveau) | Liste tous les workflows avec leurs statuts groupés (`{ id, name, isDefault, statuses: [...] }`). |
 | `create-task` / `update-task` | La validation backend (côté entité Task) rejette automatiquement un `status` n'appartenant pas au workflow du projet. Documenter dans la description du tool. |
-| `switch-project-workflow` (V2 — non bloquant) | Permet de piloter le switch via MCP. Reporté à une itération ultérieure si pas critique. |
+| `switch-project-workflow` (nouveau, ROLE_ADMIN) | Wrappe l'endpoint `POST /api/projects/{id}/switch-workflow`. Params : `projectId`, `workflowId`, `mapping: { [sourceStatusId]: targetStatusId \| null }`. Renvoie `{ migratedTaskCount }`. Mêmes validations que l'endpoint HTTP. |
 
 ## 7. Permissions
 
@@ -199,11 +199,10 @@ Security: ROLE_ADMIN
 - **Transitions autorisées** entre statuts (ex : impossible de passer de "Backlog" directement à "Done") — pas demandé, ajouterait beaucoup de complexité
 - **Versioning des workflows** (historique des modifs) — pas demandé
 - **Workflow par groupe de tâches** (TaskGroup avec son propre workflow dans un projet) — pas demandé
-- **MCP `switch-project-workflow`** — peut être ajouté en V2 si le besoin se manifeste
 
 ## 9. Risques et limites
 
-- **Migration M2 (backfill catégories)** : si un déploiement intermédiaire a créé des statuts non prévus, ils tombent sur le fallback `in_progress`. Vérifier l'état de la prod avant migration et ajuster le SQL si besoin.
+- **Migration M2 (backfill catégories)** : la migration échoue si elle rencontre un label de statut autre que les 5 standards. Si la prod a dérivé entre temps, ajouter le mapping manuellement à la migration avant déploiement.
 - **`my-tasks` kanban groupé** : avec des projets multi-workflows, l'utilisateur voit une card "In Dev" et une card "En cours" dans la même colonne `in_progress`. Le badge statut sur la card doit rester lisible (taille suffisante, couleur du statut).
 - **Filtre statut dans `my-tasks` (vue liste)** : aujourd'hui pas de filtre statut côté `my-tasks` (cf. code), donc rien à adapter. Si on en ajoute un plus tard, il faudra qu'il propose les catégories plutôt que les statuts spécifiques.
 - **Sélection multi-projets dans `TaskBulkActions`** : le bouton "Changer de statut" se désactive ; à valider que le reste du bulk reste utilisable (assignee, priorité, effort, group — eux restent globaux ou per-project comme aujourd'hui).
@@ -219,7 +218,7 @@ Security: ROLE_ADMIN
 7. Adaptation `my-tasks.vue` (kanban groupé par catégorie)
 8. `ProjectWorkflowSwitchModal` + intégration dans `ProjectDrawer`
 9. Adaptation `TaskBulkActions` et autres écrans transverses
-10. MCP : modification `list-statuses` + nouveau `list-workflows` + mise à jour des descriptions
-11. Tests : PHPUnit pour le processor + validation cross-entity ; tests fonctionnels du switch
+10. MCP : modification `list-statuses` + nouveaux `list-workflows` et `switch-project-workflow` + mise à jour des descriptions
+11. Tests : PHPUnit pour le processor + validation cross-entity ; tests fonctionnels du switch (HTTP + MCP)
 
 Le découpage exact (tickets, ordre, dépendances) sera fait dans le plan d'implémentation.