lionsdev/unionflow-server-api
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
c190867c59b319f4f47bd1f28d21d5b225fc0c0c
unionflow-server-api/unionflow/.specify/templates/tasks-template.md
dahoud e8ad874015 feat: WebSocket temps réel + Finance Workflow + corrections 
- 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
2026-03-15 02:12:17 +00:00

9.5 KiB
Raw Blame History

description
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

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