e8ad874015
- 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
101 lines
6.7 KiB
Markdown
101 lines
6.7 KiB
Markdown
# 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.
|