lionsdev/unionflow-server-api
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
7e929ac440aebdd3b8ae1ccb60592e665f0fb9de
unionflow-server-api/unionflow/specs/000-unionflow-baseline/audit-spec-kit-vs-code.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

10 KiB
Raw Blame History

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é.