feat(help) : centre d'aide in-app — page /help avec sidebar + 9 sections markdown stylées, icône ? dans la topbar

frontend/content/help/02-projects-workflows.md

@@ -0,0 +1,58 @@
+# Projets & Workflows
+
+## Qu'est-ce qu'un projet ?
+
+Un projet regroupe un ensemble de **tâches**, **time entries** et éventuellement **tickets client**. Il est défini par :
+
+- Un **code court** (2-10 lettres majuscules, ex: `SIRH`, `CRM`) qui préfixe les numéros de tâches
+- Un **client** optionnel (ou interne si null)
+- Une **couleur** d'identification
+- Un **workflow** (obligatoire) qui définit ses colonnes kanban
+
+## Qu'est-ce qu'un workflow ?
+
+Un **workflow** est un *jeu de statuts kanban* réutilisable. Au lieu d'avoir une liste globale de statuts comme dans la plupart des outils, chaque projet a son propre kanban adapté à sa façon de travailler.
+
+### Exemple
+
+| Workflow | Statuts |
+|---|---|
+| **Standard** (par défaut) | À faire → En cours → Bloqué → En attente de validation → Terminé |
+| **DevKanban** | Backlog → Spec → In Dev → Review PR → QA → Done |
+| **Support** | Nouveau → Diagnostic → Résolu |
+
+Tu peux créer autant de workflows que tu veux depuis **Admin → Workflows**.
+
+## Les 5 catégories canoniques
+
+Chaque statut, peu importe son workflow, appartient à **une catégorie canonique** parmi :
+
+| Catégorie | Description |
+|---|---|
+| `todo` | À faire — pas encore commencé |
+| `in_progress` | En cours — quelqu'un bosse dessus |
+| `blocked` | Bloqué — attente d'une dépendance |
+| `review` | En validation — relecture, PR, QA |
+| `done` | Terminé — close |
+
+> 🎯 **Pourquoi des catégories ?** Pour que la vue *Mes tâches* puisse regrouper des tâches venant de projets avec des workflows différents (ex: une tâche "In Dev" de DevKanban et "En cours" de Standard apparaissent dans la même colonne `in_progress`).
+
+## Changer le workflow d'un projet
+
+1. Ouvrir le projet → **Modifier le projet** (drawer)
+2. Section **Workflow** → cliquer sur **Changer de workflow**
+3. Sélectionner le workflow cible
+4. **Mapper chaque statut source vers un statut cible** (le mapping est pré-rempli automatiquement par catégorie)
+5. **Confirmer** — toutes les tâches migrent dans une seule transaction
+
+### Règles du mapping
+
+- ✅ Chaque statut actuellement utilisé par une tâche **doit** être mappé (sinon erreur 422)
+- ✅ Un statut peut être mappé vers `null` → la tâche passe en backlog (sans statut)
+- ❌ Tu ne peux pas mapper vers un statut qui n'appartient pas au workflow cible
+
+## Supprimer un workflow
+
+Tu peux supprimer un workflow uniquement s'il n'est **lié à aucun projet** (HTTP 409 sinon). Réassigne d'abord les projets vers un autre workflow.
+
+> ⚠️ Le workflow **Standard** ne peut pas être supprimé tant qu'il reste le défaut (un seul workflow peut avoir `isDefault=true` à la fois, garanti par un listener Doctrine).