- 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
152 lines
10 KiB
Markdown
152 lines
10 KiB
Markdown
# Audit Spec-Kit vs code source existant
|
||
|
||
**Date** : 2026-03-08
|
||
**Objectif** : Vérifier la cohérence du Spec-Kit avec le code et identifier les points à corriger ou documenter pour que tout se passe correctement.
|
||
|
||
---
|
||
|
||
## 1. Résumé exécutif
|
||
|
||
| Domaine | Statut | Commentaire |
|
||
|--------|--------|-------------|
|
||
| Scripts PowerShell | OK | Chemins et logique cohérents avec la racine du dépôt. |
|
||
| Branche / répertoire feature | À documenter | Sur `main`/`master`, les commandes plan/tasks/implement échouent si `specs/<branche>` n’existe pas. |
|
||
| Inventaire vs code mobile | Globalement OK | Quelques précisions utiles (dashboards Consultant/HrManager, DI épargne). |
|
||
| Fichiers et chemins Spec-Kit | OK | Tous les artefacts listés existent. |
|
||
| Constitution / baseline | OK | Références et contenu alignés. |
|
||
|
||
**Verdict** : Le Spec-Kit est aligné avec le code. Pour que tout se passe bien, il faut **être sur une branche feature (ex. `001-mutuelles-anti-blanchiment`) ou définir `SPECIFY_FEATURE`** avant d’exécuter `/speckit.plan`, `/speckit.tasks` ou `/speckit.implement`. Aucune modification de code n’est requise ; des précisions en documentation sont recommandées.
|
||
|
||
---
|
||
|
||
## 2. Scripts PowerShell
|
||
|
||
### 2.1 Racine du dépôt (Get-RepoRoot)
|
||
|
||
- **Fichier** : `.specify/scripts/powershell/common.ps1`
|
||
- **Comportement** : À partir de `$PSScriptRoot` (répertoire du script appelant, en pratique `.specify/scripts/powershell`), remonte de trois niveaux puis cherche un répertoire contenant `.specify`. Retourne ce répertoire (= racine du dépôt `unionflow/`).
|
||
- **Vérification** : Lorsque `check-prerequisites.ps1` est exécuté depuis `unionflow/`, il charge `common.ps1` depuis `.specify/scripts/powershell/` ; `Get-RepoRoot` remonte bien vers `unionflow/` et trouve `.specify`. **OK.**
|
||
|
||
### 2.2 Chemins dérivés (Get-FeaturePathsEnv)
|
||
|
||
- **FEATURE_DIR** = `Join-Path $RepoRoot "specs/$Branch"` avec `$Branch` = branche Git courante ou variable d’environnement `SPECIFY_FEATURE`.
|
||
- **Conséquence** : Si la branche est `master` (ou `main`), alors `FEATURE_DIR` = `specs/master` (ou `specs/main`). Ce répertoire n’existe pas dans le dépôt.
|
||
- **Comportement observé** : `check-prerequisites.ps1 -Json` exécuté depuis `unionflow/` avec branche `master` retourne :
|
||
`ERROR: Feature directory not found: ...\specs\master`. **Comportement attendu** : les commandes plan / tasks / implement supposent un répertoire de feature existant.
|
||
- **Recommandation** : Documenter clairement dans `SPEC-KIT.md` et/ou dans les commandes Cursor que :
|
||
- pour **plan**, **tasks**, **implement** : il faut être sur une branche de type `00X-nom` **ou** définir `SPECIFY_FEATURE=00X-nom` (ex. `001-mutuelles-anti-blanchiment`) ;
|
||
- pour **specify** : la commande crée la branche et le répertoire `specs/00X-nom/`, donc pas de prérequis de répertoire.
|
||
|
||
### 2.3 Fichiers et chemins utilisés par les scripts
|
||
|
||
| Script | Fichiers / chemins utilisés | Existence |
|
||
|--------|-----------------------------|-----------|
|
||
| check-prerequisites.ps1 | common.ps1, FEATURE_DIR, IMPL_PLAN, TASKS, RESEARCH, DATA_MODEL, CONTRACTS_DIR, QUICKSTART | OK (chemins dérivés de FEATURE_DIR) |
|
||
| setup-plan.ps1 | common.ps1, FEATURE_DIR, REPO_ROOT, `.specify/templates/plan-template.md` | OK (template présent) |
|
||
| create-new-feature.ps1 | Find-RepositoryRoot (marqueur .specify), specs/, template spec | OK |
|
||
| update-agent-context.ps1 | common.ps1, IMPL_PLAN, REPO_ROOT, `.specify/templates/agent-file-template.md` | OK |
|
||
|
||
Aucun chemin en dur ne pointe vers un fichier ou dossier absent.
|
||
|
||
---
|
||
|
||
## 3. Inventaire vs code source (mobile)
|
||
|
||
### 3.1 Routes et navigation
|
||
|
||
- **Inventaire** : MaterialApp + `Map<String, WidgetBuilder>`, routes `/`, `/login`, `/dashboard` ; pas de go_router pour la racine.
|
||
- **Code** : `app/router/app_router.dart` définit bien un `Map` avec `/`, `/dashboard`, `/login` ; pas d’usage de go_router pour ces routes. **OK.**
|
||
|
||
### 3.2 Structure lib/
|
||
|
||
- **Inventaire** : `app/`, `core/` (config, constants, di, error, l10n, network, storage, usecases, utils, navigation), `features/<nom>/`, `shared/`.
|
||
- **Code** : Présence de `app/`, `core/` (avec les sous-dossiers mentionnés), `features/`, `shared/`. Fichiers cités (`environment.dart`, `api_client.dart`, `injection.dart`, `injection_container.dart`, `register_module.dart`, `main_navigation_layout.dart`, `more_page.dart`) existent. **OK.**
|
||
|
||
### 3.3 Features listées
|
||
|
||
- Les 21 features listées dans l’inventaire (about, adhesions, admin, authentication, backup, contributions, dashboard, epargne, events, explore, feed, help, logs, members, notifications, organizations, profile, reports, settings, solidarity) correspondent à des répertoires sous `lib/features/`. **OK.**
|
||
|
||
### 3.4 Dashboards par rôle
|
||
|
||
- **Inventaire** : « SuperAdmin, OrgAdmin, Moderator, ActiveMember, SimpleMember, Visitor, Consultant, HrManager ».
|
||
- **Code** :
|
||
- `UserRole` (user_role.dart) ne contient que : superAdmin, orgAdmin, moderator, activeMember, simpleMember, visitor (6 rôles).
|
||
- `main_navigation_layout.dart` ne branche que ces 6 rôles vers un dashboard.
|
||
- Les widgets `ConsultantDashboard` et `HrManagerDashboard` existent (fichiers `consultant_dashboard.dart`, `hr_manager_dashboard.dart`) mais ne sont pas utilisés dans le switch de `MainNavigationLayout`.
|
||
- **Recommandation** : Préciser dans l’inventaire que les dashboards « par rôle » effectivement utilisés dans la navigation principale sont les 6 rôles de `UserRole`, et que Consultant/HrManager existent comme écrans mais ne sont pas assignés à un rôle dans ce layout (ou les retirer de la liste des dashboards « par rôle » pour éviter toute ambiguïté).
|
||
|
||
### 3.5 Injection de dépendances (DI)
|
||
|
||
- **Inventaire** : Liste des types enregistrés dans `injection.config.dart` ; mention que `CompteEpargneRepository` et `TransactionEpargneRepository` ne sont pas enregistrés.
|
||
- **Code** : `injection.config.dart` enregistre bien les types listés (ApiClient, KeycloakAuthService, AuthBloc, ProfileRepository, MembreRepository, etc.). Aucun enregistrement pour `CompteEpargneRepository` ni `TransactionEpargneRepository`. **OK.**
|
||
- **Risque** : `EpargnePage` et `DepotEpargneDialog` utilisent `GetIt.I<CompteEpargneRepository>()` et `GetIt.I<TransactionEpargneRepository>()`. Sans enregistrement, l’écran épargne provoquera une exception au runtime. L’inventaire le signale déjà ; c’est un point de suivi fonctionnel (enregistrement ou autre moyen d’injection), pas un écart Spec-Kit / code.
|
||
|
||
### 3.6 Rôles utilisateur (mobile)
|
||
|
||
- **Inventaire** : `UserRole` : superAdmin, orgAdmin, moderator, activeMember, simpleMember, visitor.
|
||
- **Code** : Identique dans `user_role.dart`. **OK.**
|
||
|
||
---
|
||
|
||
## 4. Artefacts Spec-Kit (fichiers et dossiers)
|
||
|
||
Vérification que chaque élément référencé dans `SPEC-KIT.md` et dans l’inventaire (section 5) existe :
|
||
|
||
| Artefact | Présent |
|
||
|----------|---------|
|
||
| SPEC-KIT.md (racine) | Oui |
|
||
| CONSTITUTION.md (racine) | Oui |
|
||
| .specify/memory/constitution.md | Oui |
|
||
| .specify/memory/inventaire-code.md | Oui |
|
||
| .specify/scripts/powershell/common.ps1 | Oui |
|
||
| .specify/scripts/powershell/check-prerequisites.ps1 | Oui |
|
||
| .specify/scripts/powershell/setup-plan.ps1 | Oui |
|
||
| .specify/scripts/powershell/create-new-feature.ps1 | Oui |
|
||
| .specify/scripts/powershell/update-agent-context.ps1 | Oui |
|
||
| .specify/templates/spec-template.md | Oui |
|
||
| .specify/templates/plan-template.md | Oui |
|
||
| .specify/templates/tasks-template.md | Oui |
|
||
| .specify/templates/checklist-template.md | Oui |
|
||
| .specify/templates/constitution-template.md | Oui |
|
||
| .specify/templates/agent-file-template.md | Oui |
|
||
| .cursor/commands/speckit.*.md (9 fichiers) | Oui |
|
||
| .cursor/rules/unionflow-spec-kit.mdc | Oui |
|
||
| .cursor/rules/unionflow-backend.mdc | Oui |
|
||
| .cursor/rules/unionflow-mobile.mdc | Oui |
|
||
| specs/000-unionflow-baseline/spec.md | Oui |
|
||
| specs/001-mutuelles-anti-blanchiment/spec.md, plan.md, tasks.md | Oui |
|
||
|
||
Aucun fichier ou dossier référencé n’est manquant.
|
||
|
||
---
|
||
|
||
## 5. Commandes Cursor et scripts
|
||
|
||
- Les commandes qui appellent un script ne référencent plus que le script PowerShell (pas de script Bash). Les chemins indiqués sont relatifs à la racine du dépôt (ex. `.specify/scripts/powershell/check-prerequisites.ps1 -Json`). **OK.**
|
||
- Les commandes sont conçues pour être exécutées avec le répertoire de travail = racine du dépôt (unionflow/). C’est cohérent avec l’usage dans Cursor. **OK.**
|
||
|
||
---
|
||
|
||
## 6. Constitution et baseline
|
||
|
||
- **CONSTITUTION.md** (racine) et **.specify/memory/constitution.md** : tous deux présents ; la doc indique qu’ils doivent rester synchronisés. **OK.**
|
||
- **Section 13 (Mobile)** : La constitution décrit `core/config/environment.dart`, `AppConfig.initialize()`, Environment, etc., en phase avec le code. **OK.**
|
||
- **specs/000-unionflow-baseline/spec.md** : Décrit les modules, le workflow Spec-Kit, l’inventaire consolidé et les artefacts Spec-Kit. Aligné avec l’état actuel. **OK.**
|
||
|
||
---
|
||
|
||
## 7. Actions recommandées (sans changement de code)
|
||
|
||
1. **Documenter le prérequis branche / SPECIFY_FEATURE**
|
||
Dans `SPEC-KIT.md` (et éventuellement dans les descriptions des commandes plan, tasks, implement), ajouter explicitement que :
|
||
- pour **plan**, **tasks**, **implement** : la branche courante doit être une branche feature `00X-nom` **ou** la variable d’environnement `SPECIFY_FEATURE` doit être définie (ex. `001-mutuelles-anti-blanchiment`) ;
|
||
- le répertoire `specs/<branche>` doit exister (créé par exemple par `/speckit.specify` ou par création manuelle).
|
||
|
||
2. **Précision inventaire sur les dashboards**
|
||
Dans la section 4.2 (dashboard), préciser que les 6 rôles utilisés dans `MainNavigationLayout` sont ceux de `UserRole` (superAdmin, orgAdmin, moderator, activeMember, simpleMember, visitor), et que ConsultantDashboard et HrManagerDashboard existent comme widgets mais ne sont pas branchés dans ce layout.
|
||
|
||
3. **Rappel DI épargne**
|
||
Conserver dans l’inventaire la mention que CompteEpargneRepository et TransactionEpargneRepository ne sont pas enregistrés dans GetIt, et que l’écran épargne nécessitera un enregistrement ou une autre forme d’injection pour fonctionner.
|
||
|
||
Aucune modification du code source n’est nécessaire pour que le Spec-Kit soit cohérent avec le dépôt ; les actions ci-dessus sont des clarifications documentaires pour que l’usage des commandes et l’interprétation de l’inventaire soient sans ambiguïté.
|