lionsdev/unionflow-server-api
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: WebSocket temps réel + Finance Workflow + corrections

Browse Source 
- 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
This commit is contained in:
dahoud
2026-03-15 02:12:17 +00:00
parent bbc409de9d
commit e8ad874015
635 changed files with 58160 additions and 20674 deletions
Download Patch File Download Diff File Expand all files Collapse all files

128
unionflow/.specify/templates/spec-template.md
View File

@@ -1,115 +1,103 @@
# Feature Specification: [FEATURE NAME]
# Spécification de fonctionnalité : [NOM DE LA FONCTIONNALITÉ]
**Feature Branch**: `[###-feature-name]`
**Created**: [DATE]
**Status**: Draft
**Input**: User description: "$ARGUMENTS"
**Branche feature** : `[###-nom-court]`
**Créé le** : [DATE]
**Statut** : Brouillon
**Entrée** : Description utilisateur : « $ARGUMENTS »
## User Scenarios & Testing *(mandatory)*
Pour UnionFlow : ne pas inventer de packages, routes ou features non listés dans `.specify/memory/inventaire-code.md`.
## Scénarios utilisateur et tests *(obligatoire)*
<!--
IMPORTANT: User stories should be PRIORITIZED as user journeys ordered by importance.
Each user story/journey must be INDEPENDENTLY TESTABLE - meaning if you implement just ONE of them,
you should still have a viable MVP (Minimum Viable Product) that delivers value.
Assign priorities (P1, P2, P3, etc.) to each story, where P1 is the most critical.
Think of each story as a standalone slice of functionality that can be:
- Developed independently
- Tested independently
- Deployed independently
- Demonstrated to users independently
Les user stories doivent être PRIORISÉES par ordre d'importance.
Chaque user story doit être TESTABLE INDÉPENDAMMENT : en n'implémentant qu'une seule,
on doit avoir un MVP (Minimum Viable Product) qui apporte de la valeur.
Priorités : P1, P2, P3, etc. (P1 = le plus critique).
Chaque story = slice autonome : développable, testable, déployable, démontrable seule.
-->
### User Story 1 - [Brief Title] (Priority: P1)
### User Story 1 - [Titre court] (Priorité : P1)
[Describe this user journey in plain language]
[Décrire ce parcours utilisateur en langage simple]
**Why this priority**: [Explain the value and why it has this priority level]
**Pourquoi cette priorité** : [Valeur et justification]
**Independent Test**: [Describe how this can be tested independently - e.g., "Can be fully tested by [specific action] and delivers [specific value]"]
**Test indépendant** : [Comment tester cette story seule — ex. « Testable par [action] et livre [valeur] »]
**Acceptance Scenarios**:
**Scénarios d'acceptation** :
1. **Given** [initial state], **When** [action], **Then** [expected outcome]
2. **Given** [initial state], **When** [action], **Then** [expected outcome]
1. **Étant donné** [état initial], **quand** [action], **alors** [résultat attendu]
2. **Étant donné** [état initial], **quand** [action], **alors** [résultat attendu]
---
### User Story 2 - [Brief Title] (Priority: P2)
### User Story 2 - [Titre court] (Priorité : P2)
[Describe this user journey in plain language]
[Décrire ce parcours utilisateur en langage simple]
**Why this priority**: [Explain the value and why it has this priority level]
**Pourquoi cette priorité** : [Valeur et justification]
**Independent Test**: [Describe how this can be tested independently]
**Test indépendant** : [Comment tester cette story seule]
**Acceptance Scenarios**:
**Scénarios d'acceptation** :
1. **Given** [initial state], **When** [action], **Then** [expected outcome]
1. **Étant donné** [état initial], **quand** [action], **alors** [résultat attendu]
---
### User Story 3 - [Brief Title] (Priority: P3)
### User Story 3 - [Titre court] (Priorité : P3)
[Describe this user journey in plain language]
[Décrire ce parcours utilisateur en langage simple]
**Why this priority**: [Explain the value and why it has this priority level]
**Pourquoi cette priorité** : [Valeur et justification]
**Independent Test**: [Describe how this can be tested independently]
**Test indépendant** : [Comment tester cette story seule]
**Acceptance Scenarios**:
**Scénarios d'acceptation** :
1. **Given** [initial state], **When** [action], **Then** [expected outcome]
1. **Étant donné** [état initial], **quand** [action], **alors** [résultat attendu]
---
[Add more user stories as needed, each with an assigned priority]
[Ajouter d'autres user stories si besoin, chacune avec une priorité]
### Edge Cases
### Cas limites
<!--
ACTION REQUIRED: The content in this section represents placeholders.
Fill them out with the right edge cases.
-->
<!-- Remplir avec les vrais cas limites -->
- What happens when [boundary condition]?
- How does system handle [error scenario]?
- Que se passe-t-il quand [condition limite] ?
- Comment le système gère-t-il [scénario d'erreur] ?
## Requirements *(mandatory)*
## Exigences *(obligatoire)*
<!--
ACTION REQUIRED: The content in this section represents placeholders.
Fill them out with the right functional requirements.
-->
<!-- Remplir avec les exigences fonctionnelles réelles -->
### Functional Requirements
### Exigences fonctionnelles
- **FR-001**: System MUST [specific capability, e.g., "allow users to create accounts"]
- **FR-002**: System MUST [specific capability, e.g., "validate email addresses"]
- **FR-003**: Users MUST be able to [key interaction, e.g., "reset their password"]
- **FR-004**: System MUST [data requirement, e.g., "persist user preferences"]
- **FR-005**: System MUST [behavior, e.g., "log all security events"]
- **EF-001** : Le système DOIT [capacité, ex. « permettre aux utilisateurs de créer un compte »]
- **EF-002** : Le système DOIT [capacité, ex. « valider les adresses e-mail »]
- **EF-003** : Les utilisateurs DOIVENT pouvoir [interaction clé, ex. « réinitialiser leur mot de passe »]
- **EF-004** : Le système DOIT [exigence données, ex. « persister les préférences utilisateur »]
- **EF-005** : Le système DOIT [comportement, ex. « journaliser tous les événements de sécurité »]
*Example of marking unclear requirements:*
*Exemple de marquage d'exigences floues :*
- **FR-006**: System MUST authenticate users via [NEEDS CLARIFICATION: auth method not specified - email/password, SSO, OAuth?]
- **FR-007**: System MUST retain user data for [NEEDS CLARIFICATION: retention period not specified]
- **EF-006** : Le système DOIT authentifier les utilisateurs via [À PRÉCISER : méthode non précisée — email/mot de passe, SSO, OAuth ?]
- **EF-007** : Le système DOIT conserver les données utilisateur pendant [À PRÉCISER : durée de rétention non précisée]
### Key Entities *(include if feature involves data)*
### Entités clés *(si la feature concerne des données)*
- **[Entity 1]**: [What it represents, key attributes without implementation]
- **[Entity 2]**: [What it represents, relationships to other entities]
- **[Entité 1]** : [Ce qu'elle représente, attributs clés sans détail d'implémentation]
- **[Entité 2]** : [Ce qu'elle représente, relations avec les autres entités]
## Success Criteria *(mandatory)*
## Critères de succès *(obligatoire)*
<!--
ACTION REQUIRED: Define measurable success criteria.
These must be technology-agnostic and measurable.
-->
<!-- Définir des critères mesurables, indépendants de la technologie -->
### Measurable Outcomes
### Résultats mesurables
- **SC-001**: [Measurable metric, e.g., "Users can complete account creation in under 2 minutes"]
- **SC-002**: [Measurable metric, e.g., "System handles 1000 concurrent users without degradation"]
- **SC-003**: [User satisfaction metric, e.g., "90% of users successfully complete primary task on first attempt"]
- **SC-004**: [Business metric, e.g., "Reduce support tickets related to [X] by 50%"]
- **CS-001** : [Métrique mesurable, ex. « Les utilisateurs peuvent créer un compte en moins de 2 minutes »]
- **CS-002** : [Métrique mesurable, ex. « Le système supporte 1000 utilisateurs concurrents sans dégradation »]
- **CS-003** : [Métrique satisfaction, ex. « 90 % des utilisateurs réussissent la tâche principale du premier coup »]
- **CS-004** : [Métrique métier, ex. « Réduire de 50 % les tickets support liés à [X] »]