amélioration architecture

Author: 2aiconcept

.cursor/rules/agents/agent-architecte-nx-prompt.md

@@ -33,12 +33,13 @@ Tu dois connaître et appliquer les règles suivantes (déjà configurées dans
 libs/
 ├── shared-ui/          # Composants UI réutilisables (UI pure, aucune dépendance métier)
 ├── data-access/        # Services HTTP, modèles, interceptors (pas de dépendance UI)
-└── feature-*/         # Features métier (peut dépendre de shared-ui et data-access)
-    ├── feature-orders/
-    ├── feature-auth/
-    └── feature-contacts/
+├── feature-orders/     # Feature commandes (peut dépendre de shared-ui et data-access)
+├── feature-auth/       # Feature authentification (peut dépendre de shared-ui et data-access)
+└── feature-contacts/   # Feature contacts (peut dépendre de shared-ui et data-access)
 ```
 
+**Note** : Toutes les libs sont au même niveau dans `libs/`. Le préfixe `feature-` est une convention de nommage, pas une hiérarchie de dossiers.
+
 ### Règles de Dépendances
 
 - ✅ `shared-ui` → **AUCUNE** dépendance (UI pure)
@@ -56,14 +57,16 @@ libs/
 
 ### Générer une nouvelle lib
 
+**✅ SYNTAXE CORRECTE** : Utiliser `--name` et `--directory` pour créer les libs dans `libs/`
+
 ```bash
-npx nx g @nx/angular:library libs/<nom-lib> --unitTestRunner=vitest
+npx nx g @nx/angular:library --name=<nom-lib> --directory=libs/<nom-lib> --unitTestRunner=vitest
 ```
 
 **Exemples** :
 
-- `npx nx g @nx/angular:library libs/shared-ui --unitTestRunner=vitest`
-- `npx nx g @nx/angular:library libs/feature-auth --unitTestRunner=vitest`
+- `npx nx g @nx/angular:library --name=shared-ui --directory=libs/shared-ui --unitTestRunner=vitest`
+- `npx nx g @nx/angular:library --name=feature-auth --directory=libs/feature-auth --unitTestRunner=vitest`
 
 ### Générer un composant dans une lib
 
@@ -155,10 +158,10 @@ depConstraints: [
 
 **Exemple : Créer une nouvelle feature**
 
-1. Générer la lib :
+1. Générer la lib avec la syntaxe correcte :
 
 ```bash
-npx nx g @nx/angular:library feature-contacts --unitTestRunner=vitest
+npx nx g @nx/angular:library --name=feature-contacts --directory=libs/feature-contacts --unitTestRunner=vitest
 ```
 
 2. **Ajouter les tags** dans `libs/feature-contacts/project.json` :
@@ -176,6 +179,22 @@ npx nx g @nx/angular:library feature-contacts --unitTestRunner=vitest
 npx nx lint feature-contacts
 ```
 
+### ⚠️ IMPORTANT : Quand modifier les depConstraints
+
+Les `depConstraints` dans `eslint.config.mjs` (racine) sont **déjà configurés** pour les types de libs standard de ce projet :
+
+- ✅ `type:app` → peut importer `type:feature`, `type:data-access`, `type:ui`
+- ✅ `type:feature` → peut importer `type:data-access`, `type:ui`
+- ✅ `type:ui` → peut importer `type:data-access`
+- ✅ `type:data-access` → ne peut rien importer
+
+**Vous devez modifier les `depConstraints` uniquement si** :
+
+1. ❗ Vous créez un **nouveau type** de lib (ex: `type:utils`, `type:config`)
+2. ❗ Vous changez les **règles de dépendances** entre les types existants
+
+**Sinon** : Il suffit d'ajouter les tags dans `project.json` et les contraintes existantes s'appliqueront automatiquement.
+
 ### Matrice de dépendances
 
 | Source → Cible  | app | feature | ui  | data-access |
@@ -305,7 +324,7 @@ Avant d'utiliser un composant/service d'une lib, vérifier :
 
 2. **Est-ce de la logique métier spécifique à une feature ?**
 
-   - OUI → `feature-*/components/` ou `feature-*/services/`
+   - OUI → Dans la feature concernée (ex: `libs/feature-orders/src/lib/components/` ou `libs/feature-orders/src/lib/services/`)
    - NON → Vérifier si c'est de l'accès aux données → `data-access`
 
 3. **Est-ce un appel HTTP ou un modèle de données ?**
@@ -321,12 +340,16 @@ Avant de créer un composant/service, vérifier :
 
 1. [ ] La lib cible existe-t-elle ? Sinon, la générer avec `nx generate`
 2. [ ] **Les tags Nx sont-ils ajoutés dans le `project.json` ?** (type:app, type:feature, type:ui, type:data-access)
-3. [ ] Le composant/service est-il dans la bonne lib selon sa responsabilité ?
-4. [ ] Les dépendances respectent-elles les frontières (pas de dépendance circulaire) ?
-5. [ ] Le selector utilise-t-il le bon préfixe (`lib-` pour libs, `app-` pour apps) ?
-6. [ ] Les imports utilisent-ils les alias Nx (`@mini-crm/...`) ?
-7. [ ] Le composant/service est-il exporté dans le barrel export (`src/index.ts`) ?
-8. [ ] Le `project.json` et `tsconfig.base.json` sont-ils correctement configurés ?
+3. [ ] **Les `depConstraints` dans `eslint.config.mjs` sont-ils configurés pour le nouveau type de lib ?**
+4. [ ] Le composant/service est-il dans la bonne lib selon sa responsabilité ?
+5. [ ] Les dépendances respectent-elles les frontières (pas de dépendance circulaire) ?
+6. [ ] Le selector utilise-t-il le bon préfixe (`lib-` pour libs, `app-` pour apps) ?
+7. [ ] Les imports utilisent-ils les alias Nx (`@mini-crm/...`) ?
+8. [ ] Le composant/service est-il exporté dans le barrel export (`src/index.ts`) ?
+9. [ ] Le `project.json` et `tsconfig.base.json` sont-ils correctement configurés ?
+10. [ ] **Tester avec `npx nx lint <project>` pour vérifier les contraintes**
+
+**Note importante** : Les `depConstraints` dans `eslint.config.mjs` (racine) définissent les règles de dépendances entre les types de libs. Ils sont **déjà configurés** pour les types standard (app, feature, ui, data-access). Si vous créez un **nouveau type** de lib, vous devrez ajouter les contraintes correspondantes.
 
 ## 🚀 Exemples de Prompts que Tu Peux Traiter
 

.cursor/rules/architecture.mdc

@@ -47,6 +47,10 @@ Ce projet utilise **Nx** pour organiser le code en **monorepo** avec des bibliot
 
 #### `libs/feature-*/` - Features métier
 
+**Note** : `feature-*` est une convention de nommage, pas un dossier parent. Toutes les features sont au même niveau dans `libs/`.
+
+**Exemples** : `libs/feature-orders/`, `libs/feature-auth/`, `libs/feature-contacts/`
+
 - **Rôle** : Features métier isolées et lazy-loadées.
 - **Structure interne d'une feature** :
   - `components/` : Composants Smart (logique) et Dumb (présentation)
@@ -64,12 +68,12 @@ Pour **garantir le respect des frontières de dépendances**, Nx utilise un syst
 
 Chaque projet (app ou lib) doit avoir des tags dans son `project.json` :
 
-| Type de projet | Tag obligatoire | Exemple |
-| -------------- | --------------- | ------- |
-| Application    | `type:app`      | `["type:app", "scope:mini-crm"]` |
-| Feature        | `type:feature`  | `["type:feature", "scope:orders"]` |
-| Data Access    | `type:data-access` | `["type:data-access"]` |
-| Shared UI      | `type:ui`       | `["type:ui"]` |
+| Type de projet | Tag obligatoire    | Exemple                            |
+| -------------- | ------------------ | ---------------------------------- |
+| Application    | `type:app`         | `["type:app", "scope:mini-crm"]`   |
+| Feature        | `type:feature`     | `["type:feature", "scope:orders"]` |
+| Data Access    | `type:data-access` | `["type:data-access"]`             |
+| Shared UI      | `type:ui`          | `["type:ui"]`                      |
 
 #### Exemple de configuration
 
@@ -125,7 +129,7 @@ depConstraints: [
     sourceTag: 'type:data-access',
     onlyDependOnLibsWithTags: [],
   },
-]
+];
 ```
 
 #### Règles de dépendances visuelles
@@ -164,10 +168,22 @@ npx nx lint <project-name>
 ```
 
 **Si une violation est détectée** :
+
 ```
 error  A project tagged with "type:feature" can only depend on libs tagged with "type:data-access", "type:ui"
 ```
 
+#### ⚠️ Quand modifier les depConstraints
+
+Les `depConstraints` dans `eslint.config.mjs` (racine) sont **déjà configurés** pour ce projet.
+
+**Vous devez les modifier uniquement si** :
+
+1. Vous créez un **nouveau type** de lib (ex: `type:utils`, `type:config`)
+2. Vous changez les **règles de dépendances** entre types existants
+
+**Sinon** : Ajoutez simplement les tags dans `project.json` et les contraintes existantes s'appliqueront automatiquement.
+
 ### Pourquoi cette organisation Nx ?
 
 1. **Isolation** : Chaque lib peut être développée/testée indépendamment
@@ -219,7 +235,7 @@ export * from './lib/confirm-modal/confirm-modal.component';
 
 ```typescript
 // Dans feature-orders
-import { SpinnerComponent } from '@mini-crm/shared-ui';  // ✅ Via barrel export
+import { SpinnerComponent } from '@mini-crm/shared-ui'; // ✅ Via barrel export
 
 // ❌ JAMAIS comme ça (contourne le barrel export)
 import { SpinnerComponent } from '@mini-crm/shared-ui/src/lib/spinner/spinner.component';

STARTER-PROMPT.md

@@ -282,21 +282,23 @@ Créer à la racine du projet.
 
 ### Étape 1 : Créer les libs Nx
 
+**⚠️ IMPORTANT** : Utiliser la syntaxe correcte avec `--name` et `--directory` pour garantir que les libs sont créées dans `libs/`
+
 ```bash
 # Lib UI partagée
-npx nx g @nx/angular:library shared-ui --unitTestRunner=vitest
+npx nx g @nx/angular:library --name=shared-ui --directory=libs/shared-ui --unitTestRunner=vitest
 
 # Lib data-access
-npx nx g @nx/angular:library data-access --unitTestRunner=vitest
+npx nx g @nx/angular:library --name=data-access --directory=libs/data-access --unitTestRunner=vitest
 
 # Lib feature-auth
-npx nx g @nx/angular:library feature-auth --unitTestRunner=vitest
+npx nx g @nx/angular:library --name=feature-auth --directory=libs/feature-auth --unitTestRunner=vitest
 
 # Lib feature-orders
-npx nx g @nx/angular:library feature-orders --unitTestRunner=vitest
+npx nx g @nx/angular:library --name=feature-orders --directory=libs/feature-orders --unitTestRunner=vitest
 
 # Lib layout (pour le layout system)
-npx nx g @nx/angular:library layout --unitTestRunner=vitest
+npx nx g @nx/angular:library --name=layout --directory=libs/layout --unitTestRunner=vitest
 ```
 
 Nx génère automatiquement :

starter-guide.md

@@ -517,12 +517,12 @@ Après chaque approche, réfléchissez à :
 **Solution** : Demander explicitement à l'agent de créer les libs d'abord
 
 ```
-Crée d'abord les libs Nx nécessaires :
-- npx nx g @nx/angular:library shared-ui --unitTestRunner=vitest
-- npx nx g @nx/angular:library data-access --unitTestRunner=vitest
-- npx nx g @nx/angular:library feature-auth --unitTestRunner=vitest
-- npx nx g @nx/angular:library feature-orders --unitTestRunner=vitest
-- npx nx g @nx/angular:library layout --unitTestRunner=vitest
+Crée d'abord les libs Nx nécessaires avec la syntaxe correcte :
+- npx nx g @nx/angular:library --name=shared-ui --directory=libs/shared-ui --unitTestRunner=vitest
+- npx nx g @nx/angular:library --name=data-access --directory=libs/data-access --unitTestRunner=vitest
+- npx nx g @nx/angular:library --name=feature-auth --directory=libs/feature-auth --unitTestRunner=vitest
+- npx nx g @nx/angular:library --name=feature-orders --directory=libs/feature-orders --unitTestRunner=vitest
+- npx nx g @nx/angular:library --name=layout --directory=libs/layout --unitTestRunner=vitest
 ```
 
 #### L'agent oublie des fichiers