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

unionflow/specs/001-mutuelles-anti-blanchiment/tasks.md

@@ -0,0 +1,100 @@
+# 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.