MALIO-DEV/Lesstime
3
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases 32 Wiki Activity

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

Browse Source
This commit is contained in:
THOLOT DECHENE Matthieu
2026-05-19 20:46:01 +02:00
parent 1fd2c05db3
commit f86698e7cd
3 changed files with 3054 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
.gitignore vendored
View File

@@ -30,3 +30,9 @@
###> docker local ### ###> docker local ###
infra/dev/.env.docker.local infra/dev/.env.docker.local
###< docker local ### ###< docker local ###
###> local db dumps ###
*.sql.gz
*.sql.gz:Zone.Identifier
REVIEW.md
###< local db dumps ###

3036
docs/superpowers/plans/2026-05-19-project-workflows.md Normal file
View File

File diff suppressed because it is too large Load Diff

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

@@ -2,7 +2,7 @@
**Date** : 2026-05-19 **Date** : 2026-05-19
**Branche** : `feat/project-workflows` **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 ## Reprise sur un autre poste
@@ -12,11 +12,11 @@
> 2. **Ce qui est fait** : design validé avec Matthieu et committé (ce fichier). > 2. **Ce qui est fait** : design validé avec Matthieu et committé (ce fichier).
> 3. **Aucun code applicatif n'a encore été écrit.** > 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). > 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 : > 5. **Validations Matthieu (2026-05-19)** :
> - Hors scope (§8) — rien d'oublié pour la V1 ? > - Hors scope (§8) → MCP `switch-project-workflow` **rapatrié dans la V1** (cf. §6).
> - Fallback `in_progress` pour statuts non-mappables (§3, M2) — OK ou échec migration ? > - 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 (§5) — OK de tout fusionner dans l'onglet Workflows ? > - Suppression d'`AdminStatusTab` → **OK**.
> - Ordre des étapes de livraison (§10) — OK ou réordonner ? > - 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]). > 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`. > 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`** **M2 — `add_workflow_to_task_status`**
- Ajoute `task_status.workflow_id` nullable + `task_status.category` nullable - Ajoute `task_status.workflow_id` nullable + `task_status.category` nullable
- `UPDATE task_status SET workflow_id = <id Standard>` pour toutes les lignes existantes - `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` - "À faire" → `todo`
- "En cours" → `in_progress` - "En cours" → `in_progress`
- "Bloqué" → `blocked` - "Bloqué" → `blocked`
- "En attente de validation" → `review` - "En attente de validation" → `review`
- "Terminé" → `done` - "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` - Passe les 2 colonnes en `NOT NULL`
**M3 — `add_workflow_to_project`** **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-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: [...] }`). | | `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. | | `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 ## 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é - **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é - **Versioning des workflows** (historique des modifs) — pas demandé
- **Workflow par groupe de tâches** (TaskGroup avec son propre workflow dans un projet) — 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 ## 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). - **`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. - **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). - **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) 7. Adaptation `my-tasks.vue` (kanban groupé par catégorie)
8. `ProjectWorkflowSwitchModal` + intégration dans `ProjectDrawer` 8. `ProjectWorkflowSwitchModal` + intégration dans `ProjectDrawer`
9. Adaptation `TaskBulkActions` et autres écrans transverses 9. Adaptation `TaskBulkActions` et autres écrans transverses
10. MCP : modification `list-statuses` + nouveau `list-workflows` + mise à jour des descriptions 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 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. Le découpage exact (tickets, ordre, dépendances) sera fait dans le plan d'implémentation.