lionsdev/unionflow-server-api
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
6ba710401c64e7b50e518bbc3b0c8967ae5b5146
unionflow-server-api/unionflow/specs/001-mutuelles-anti-blanchiment/tasks.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

6.7 KiB
Raw Blame History

Tâches : Gestion des mutuelles orientée anti-blanchiment (LCB-FT)

Entrée : specs/001-mutuelles-anti-blanchiment/spec.md, plan.md
Prérequis : plan.md, spec.md

Ordre d’exécution : Respecter strictement l’ordre des phases (API → Migrations → Impl → Mobile). Les tâches mobile ne doivent être traitées qu’après les tâches backend correspondantes (ou en parallèle si l’API est déjà disponible).

Format : [ID] [P?] Description

  • [P] : Peut s’exécuter en parallèle (fichiers différents, pas de dépendances).
  • Les chemins sont relatifs à la racine du dépôt unionflow/.

Phase 1 : API (unionflow-server-api)

Objectif : Ajouter les champs et enums LCB-FT dans l’API (spec §3.1).

  • T001 [P] Étendre TransactionEpargneRequest (ou équivalent) avec origineFonds (String, optionnel), pieceJustificativeId (UUID, optionnel) si ce n’est pas déjà fait — unionflow-server-api/.../dto/mutuelle/epargne/
  • T002 [P] Étendre TransactionEpargneResponse avec origineFonds, pieceJustificativeId en lecture si nécessaire
  • T003 [P] Ajouter en API les enums NiveauVigilanceKyc, StatutKyc (ex. enums.membre) et champs membre : niveauVigilanceKyc, dateVerificationIdentite, statutKyc (DTOs membre)
  • T004 [P] Étendre les DTOs d’intentions de paiement / paiement avec origineFonds, justificationLcbFt et étendre type_objet pour EPARGNE_DEPOT, EPARGNE_RETRAIT, CREDIT_REMBOURSEMENT si prévu par la spec
  • T005 [P] Ajouter ou étendre le contrat (DTO / config) pour les paramètres LCB-FT (seuils : montant justification, montant validation manuelle, devise) — ex. parametres_organisation / parametres_plateforme
  • T006 Mettre à jour .specify/memory/inventaire-code.md avec les nouveaux DTOs/enums/champs API

Jalon : API prête pour impl et mobile (contrats stables).

Phase 2 : Migrations Flyway (unionflow-server-impl-quarkus)

Objectif : Schéma BDD aligné avec la spec §3.2 (sans modifier les migrations existantes).

  • T007 Vérifier ou créer la migration LCB-FT : colonnes membres (ou table membre_kyc) niveau_vigilance_kyc, date_verification_identite, statut_kyc
  • T008 Vérifier ou créer les colonnes origine_fonds, piece_justificative_id (et si besoin seuil_lcb_ft_atteint) sur la table des transactions épargne
  • T009 Vérifier ou créer les colonnes origine_fonds, justification_lcb_ft sur la table intentions_paiement
  • T010 Vérifier ou créer la table ou colonnes pour les paramètres LCB-FT (seuils : montant_seuil_justification, montant_seuil_validation_manuelle, code_devise)
  • T011 Mettre à jour l’inventaire avec le numéro et le contenu de la migration LCB-FT

Jalon : Schéma BDD prêt pour l’impl des services.

Phase 3 : Implémentation Quarkus (unionflow-server-impl-quarkus)

Objectif : Règles métier, validation des seuils, audit (spec §3.3).

  • T012 Implémenter la lecture des paramètres LCB-FT (seuils) depuis la BDD ou la config (organisation / plateforme)
  • T013 Dans le service de transaction épargne : si montant ≥ seuil configuré, exiger origineFonds (et éventuellement pieceJustificativeId) ; sinon rejet 400 avec message clair
  • T014 Enregistrer dans audit_logs les opérations mutuelles (épargne/crédit) avec portee ORGANISATION et détails (montant, type, membre, seuil franchi)
  • T015 (Optionnel) Crédit : exiger ou vérifier dateVerificationIdentite à jour pour le membre avant déblocage selon la spec
  • T016 (Optionnel) Créer la ressource ou le type d’événement « alertes LCB-FT » pour dépassement de seuil / motif vide (spec §3.3)
  • T017 Exposer un endpoint ou une config (ex. paramètres organisation) pour que le mobile récupère le seuil LCB-FT (montant au-dessus duquel origine des fonds obligatoire)

Jalon : Backend LCB-FT opérationnel et consommable par le mobile.

Phase 4 : Mobile (unionflow-mobile-apps)

Objectif : Écrans mutuelles conformes LCB-FT (origine des fonds, pièce justificative si seuil) ; fiche membre avec statut KYC et date de vérification d’identité (spec §3.4).

4.1 Épargne – Seuil et champs LCB-FT

  • T018 Récupérer le seuil LCB-FT depuis l’API (paramètres organisation) ou la config ; utiliser ce seuil dans les dialogs (dépôt/retrait/transfert) au lieu ou en complément de lcb_ft_constants.dart
  • T019 S’assurer que les formulaires de dépôt, retrait et transfert épargne affichent et envoient origineFonds (obligatoire si montant ≥ seuil) — lib/features/epargne/presentation/widgets/ (ex. DepotEpargneDialog, retrait, transfert)
  • T020 Ajouter la saisie et l’upload de la pièce justificative dans les dialogs épargne lorsque le montant ≥ seuil ; envoyer pieceJustificativeId dans TransactionEpargneRequest après upload
  • T021 Afficher un message d’erreur clair côté mobile si l’API retourne 400 (ex. origine des fonds manquante au-dessus du seuil)

Jalon : Flux épargne mobile conformes LCB-FT (sans données fictives).

4.2 Fiche membre – Affichage KYC

  • T022 Étendre le modèle membre (ex. MembreModel ou DTO détail) avec niveauVigilanceKyc, statutKyc, dateVerificationIdentite selon l’API — lib/features/members/data/models/
  • T023 Sur la fiche membre (détail membre ou écran équivalent), afficher en lecture seule le statut KYC et la date de vérification d’identité — lib/features/members/presentation/ et/ou lib/features/profile/
  • T024 S’assurer que les données KYC proviennent uniquement de l’API (pas de valeurs en dur)

Jalon : Fiche membre affiche les informations KYC conformément à la spec.

Phase 5 : Finition et transversal

  • T025 Mettre à jour .specify/memory/inventaire-code.md avec les changements mobile (modèles, écrans, constantes)
  • T026 Vérifier qu’aucune donnée fictive n’est utilisée en production (listes en dur, mocks métier) pour les flux mutuelles et KYC
  • T027 Exécuter les tests backend et mobile ; corriger les régressions

Dépendances et ordre d’exécution

  • Phase 1 (API) : Peut démarrer immédiatement.
  • Phase 2 (Migrations) : Dépend de la stabilité des champs API (Phase 1).
  • Phase 3 (Impl) : Dépend des Phases 1 et 2.
  • Phase 4 (Mobile) : Dépend des contrats API (Phase 1) et de préférence de l’endpoint/config de seuil (T017). Les tâches 4.1 et 4.2 peuvent être traitées en parallèle une fois les modèles API disponibles.
  • Phase 5 : Après les Phases 1–4.

Pour continuer strictement l’ordre sur la version mobile : exécuter d’abord T018 → T019 → T020 → T021 (épargne), puis T022 → T023 → T024 (fiche membre), puis T025–T027.