- Task #6: WebSocket /ws/dashboard + Kafka events (5 topics) * Backend: KafkaEventProducer, KafkaEventConsumer * Mobile: WebSocketService (reconnection, heartbeat, typed events) * DashboardBloc: Auto-refresh depuis WebSocket events - Finance Workflow: approbations + budgets (backend + mobile) * Backend: entities, services, resources, migrations Flyway V6 * Mobile: features finance_workflow complète avec BLoC - Corrections DI: interfaces IRepository partout * IProfileRepository, IOrganizationRepository, IMembreRepository * GetIt configuré avec @injectable - Spec-Kit: constitution + templates mis à jour * .specify/memory/constitution.md enrichie * Templates agent, plan, spec, tasks, checklist - Nettoyage: fichiers temporaires supprimés Signed-off-by: lions dev Team
239 lines
9.5 KiB
Markdown
239 lines
9.5 KiB
Markdown
---
|
|
|
|
description: "Modèle de liste de tâches pour l'implémentation d'une fonctionnalité"
|
|
---
|
|
|
|
# Tâches : [NOM DE LA FONCTIONNALITÉ]
|
|
|
|
**Entrée** : Documents de conception dans `/specs/[###-nom-court]/`
|
|
**Prérequis** : plan.md (obligatoire), spec.md (obligatoire pour les user stories), research.md, data-model.md, contracts/
|
|
|
|
**Tests** : Les exemples ci-dessous incluent des tâches de test. Les tests sont OPTIONNELS — ne les inclure que si la spécification de la feature le demande explicitement.
|
|
|
|
**Organisation** : Les tâches sont regroupées par user story pour permettre une implémentation et des tests indépendants par story.
|
|
|
|
## Format : `[ID] [P?] [Story] Description`
|
|
|
|
- **[P]** : Peut s'exécuter en parallèle (fichiers différents, pas de dépendances)
|
|
- **[Story]** : À quelle user story la tâche appartient (ex. US1, US2, US3)
|
|
- Inclure les chemins de fichiers exacts dans les descriptions
|
|
|
|
## Conventions de chemins
|
|
|
|
- **Projet unique** : `src/`, `tests/` à la racine du dépôt
|
|
- **Application web** : `backend/src/`, `frontend/src/`
|
|
- **Mobile** : `api/src/`, `ios/src/` ou `android/src/`
|
|
- **UnionFlow (monorepo)** : Backend = `unionflow-server-api/`, `unionflow-server-impl-quarkus/` ; Mobile = `unionflow-mobile-apps/lib/` (core/, features/, app/, shared/). Tâches mobile : chemins relatifs à `unionflow-mobile-apps/lib/` (ex. `features/epargne/presentation/pages/epargne_page.dart`).
|
|
- Adapter les chemins ci-dessous selon la structure dans plan.md
|
|
|
|
<!--
|
|
============================================================================
|
|
IMPORTANT : Les tâches ci-dessous sont des EXEMPLES à titre indicatif.
|
|
|
|
La commande /speckit.tasks DOIT les remplacer par les vraies tâches basées sur :
|
|
- Les user stories de spec.md (et leurs priorités P1, P2, P3...)
|
|
- Les exigences du plan.md
|
|
- Les entités de data-model.md
|
|
- Les endpoints de contracts/
|
|
|
|
Les tâches DOIVENT être organisées par user story pour que chaque story soit :
|
|
- Implémentable indépendamment
|
|
- Testable indépendamment
|
|
- Livrable en incrément MVP
|
|
|
|
NE PAS conserver ces tâches exemples dans le fichier tasks.md généré.
|
|
============================================================================
|
|
-->
|
|
|
|
## Phase 1 : Mise en place (infrastructure partagée)
|
|
|
|
**Objectif** : Initialisation et structure de base
|
|
|
|
- [ ] T001 Créer la structure du projet selon le plan d'implémentation
|
|
- [ ] T002 Initialiser le projet [langage] avec les dépendances [framework]
|
|
- [ ] T003 [P] Configurer le lint et le formatage
|
|
|
|
---
|
|
|
|
## Phase 2 : Fondations (prérequis bloquants)
|
|
|
|
**Objectif** : Infrastructure indispensable avant TOUTE implémentation de user story
|
|
|
|
**⚠️ CRITIQUE** : Aucune user story ne peut commencer avant la fin de cette phase
|
|
|
|
Exemples de tâches fondations (adapter au projet) :
|
|
|
|
- [ ] T004 Mettre en place le schéma BDD et le framework de migrations
|
|
- [ ] T005 [P] Implémenter le cadre d'authentification / autorisation
|
|
- [ ] T006 [P] Mettre en place le routage API et la structure middleware
|
|
- [ ] T007 Créer les modèles/entités de base dont dépendent toutes les stories
|
|
- [ ] T008 Configurer la gestion des erreurs et les logs
|
|
- [ ] T009 Mettre en place la gestion de la configuration d'environnement
|
|
|
|
**Jalon** : Fondations prêtes — l'implémentation des user stories peut commencer
|
|
|
|
---
|
|
|
|
## Phase 3 : User Story 1 - [Titre] (Priorité : P1) 🎯 MVP
|
|
|
|
**Objectif** : [Brève description de ce que livre cette story]
|
|
|
|
**Test indépendant** : [Comment vérifier que cette story fonctionne seule]
|
|
|
|
### Tests pour User Story 1 (OPTIONNEL — seulement si tests demandés) ⚠️
|
|
|
|
> **NOTE : Écrire ces tests EN PREMIER, s'assurer qu'ils ÉCHOUENT avant l'implémentation**
|
|
|
|
- [ ] T010 [P] [US1] Test de contrat pour [endpoint] dans tests/contract/test_[nom].py
|
|
- [ ] T011 [P] [US1] Test d'intégration pour [parcours] dans tests/integration/test_[nom].py
|
|
|
|
### Implémentation pour User Story 1
|
|
|
|
- [ ] T012 [P] [US1] Créer le modèle [Entité1] dans src/models/[entite1].py
|
|
- [ ] T013 [P] [US1] Créer le modèle [Entité2] dans src/models/[entite2].py
|
|
- [ ] T014 [US1] Implémenter [Service] dans src/services/[service].py (dépend de T012, T013)
|
|
- [ ] T015 [US1] Implémenter [endpoint/feature] dans src/[emplacement]/[fichier].py
|
|
- [ ] T016 [US1] Ajouter la validation et la gestion des erreurs
|
|
- [ ] T017 [US1] Ajouter les logs pour les opérations de la user story 1
|
|
|
|
**Jalon** : À ce stade, User Story 1 doit être entièrement fonctionnelle et testable seule
|
|
|
|
---
|
|
|
|
## Phase 4 : User Story 2 - [Titre] (Priorité : P2)
|
|
|
|
**Objectif** : [Brève description]
|
|
|
|
**Test indépendant** : [Comment vérifier]
|
|
|
|
### Tests pour User Story 2 (OPTIONNEL) ⚠️
|
|
|
|
- [ ] T018 [P] [US2] Test de contrat pour [endpoint] dans tests/contract/test_[nom].py
|
|
- [ ] T019 [P] [US2] Test d'intégration pour [parcours] dans tests/integration/test_[nom].py
|
|
|
|
### Implémentation pour User Story 2
|
|
|
|
- [ ] T020 [P] [US2] Créer le modèle [Entité] dans src/models/[entite].py
|
|
- [ ] T021 [US2] Implémenter [Service] dans src/services/[service].py
|
|
- [ ] T022 [US2] Implémenter [endpoint/feature] dans src/[emplacement]/[fichier].py
|
|
- [ ] T023 [US2] Intégrer avec les composants de User Story 1 (si besoin)
|
|
|
|
**Jalon** : User Stories 1 et 2 doivent toutes deux fonctionner indépendamment
|
|
|
|
---
|
|
|
|
## Phase 5 : User Story 3 - [Titre] (Priorité : P3)
|
|
|
|
**Objectif** : [Brève description]
|
|
|
|
**Test indépendant** : [Comment vérifier]
|
|
|
|
### Tests pour User Story 3 (OPTIONNEL) ⚠️
|
|
|
|
- [ ] T024 [P] [US3] Test de contrat pour [endpoint] dans tests/contract/test_[nom].py
|
|
- [ ] T025 [P] [US3] Test d'intégration pour [parcours] dans tests/integration/test_[nom].py
|
|
|
|
### Implémentation pour User Story 3
|
|
|
|
- [ ] T026 [P] [US3] Créer le modèle [Entité] dans src/models/[entite].py
|
|
- [ ] T027 [US3] Implémenter [Service] dans src/services/[service].py
|
|
- [ ] T028 [US3] Implémenter [endpoint/feature] dans src/[emplacement]/[fichier].py
|
|
|
|
**Jalon** : Toutes les user stories doivent être fonctionnelles indépendamment
|
|
|
|
---
|
|
|
|
[Ajouter d'autres phases user story si besoin, même pattern]
|
|
|
|
---
|
|
|
|
## Phase N : Finition et transversal
|
|
|
|
**Objectif** : Améliorations qui concernent plusieurs user stories
|
|
|
|
- [ ] TXXX [P] Mise à jour de la documentation dans docs/
|
|
- [ ] TXXX Nettoyage et refactoring du code
|
|
- [ ] TXXX Optimisation des performances sur l'ensemble des stories
|
|
- [ ] TXXX [P] Tests unitaires supplémentaires (si demandés) dans tests/unit/
|
|
- [ ] TXXX Renforcement de la sécurité
|
|
- [ ] TXXX Exécuter la validation quickstart.md
|
|
|
|
---
|
|
|
|
## Dépendances et ordre d'exécution
|
|
|
|
### Dépendances entre phases
|
|
|
|
- **Phase 1 (Mise en place)** : Aucune — peut démarrer tout de suite
|
|
- **Phase 2 (Fondations)** : Dépend de la Phase 1 — BLOQUE toutes les user stories
|
|
- **Phases 3+ (User stories)** : Dépendent de la fin de la Phase 2
|
|
- Les user stories peuvent ensuite avancer en parallèle (si plusieurs personnes)
|
|
- Ou dans l'ordre des priorités (P1 → P2 → P3)
|
|
- **Phase N (Finition)** : Dépend de la fin des user stories souhaitées
|
|
|
|
### Dépendances entre user stories
|
|
|
|
- **User Story 1 (P1)** : Peut démarrer après la Phase 2 — pas de dépendance à d'autres stories
|
|
- **User Story 2 (P2)** : Peut démarrer après la Phase 2 — peut s'appuyer sur US1 mais doit rester testable seule
|
|
- **User Story 3 (P3)** : Peut démarrer après la Phase 2 — peut s'appuyer sur US1/US2 mais doit rester testable seule
|
|
|
|
### Au sein de chaque user story
|
|
|
|
- Les tests (si inclus) DOIVENT être écrits et ÉCHOUER avant l'implémentation
|
|
- Modèles avant services
|
|
- Services avant endpoints
|
|
- Implémentation cœur avant intégration
|
|
- Finir une story avant de passer à la suivante
|
|
|
|
### Parallélisation possible
|
|
|
|
- Toutes les tâches de mise en place marquées [P] peuvent s'exécuter en parallèle
|
|
- Toutes les tâches fondations marquées [P] peuvent s'exécuter en parallèle (dans la Phase 2)
|
|
- Une fois la Phase 2 terminée, toutes les user stories peuvent démarrer en parallèle (si capacité équipe)
|
|
- Les tests d'une story marqués [P] peuvent s'exécuter en parallèle
|
|
- Les modèles d'une story marqués [P] peuvent s'exécuter en parallèle
|
|
- Différentes user stories peuvent être traitées en parallèle par différentes personnes
|
|
|
|
---
|
|
|
|
## Stratégie d'implémentation
|
|
|
|
### MVP d'abord (User Story 1 uniquement)
|
|
|
|
1. Terminer Phase 1 : Mise en place
|
|
2. Terminer Phase 2 : Fondations (CRITIQUE — bloque tout)
|
|
3. Terminer Phase 3 : User Story 1
|
|
4. **STOP et VALIDER** : Tester User Story 1 seule
|
|
5. Déployer / démo si prêt
|
|
|
|
### Livraison incrémentale
|
|
|
|
1. Mise en place + Fondations → base prête
|
|
2. Ajouter User Story 1 → tester seule → déployer/démo (MVP)
|
|
3. Ajouter User Story 2 → tester seule → déployer/démo
|
|
4. Ajouter User Story 3 → tester seule → déployer/démo
|
|
5. Chaque story ajoute de la valeur sans casser les précédentes
|
|
|
|
### Équipe en parallèle
|
|
|
|
Avec plusieurs développeurs :
|
|
|
|
1. L'équipe termine ensemble Mise en place + Fondations
|
|
2. Une fois les fondations faites :
|
|
- Dev A : User Story 1
|
|
- Dev B : User Story 2
|
|
- Dev C : User Story 3
|
|
3. Les stories se terminent et s'intègrent indépendamment
|
|
|
|
---
|
|
|
|
## Notes
|
|
|
|
- Tâches [P] = fichiers différents, pas de dépendances
|
|
- Le libellé [Story] relie la tâche à une user story pour la traçabilité
|
|
- Chaque user story doit être complétable et testable indépendamment
|
|
- Vérifier que les tests échouent avant d'implémenter
|
|
- Commiter après chaque tâche ou groupe logique
|
|
- S'arrêter à chaque jalon pour valider la story seule
|
|
- À éviter : tâches floues, conflits sur le même fichier, dépendances entre stories qui cassent l'indépendance
|