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