@atlashub/smartstack-cli 4.27.0 → 4.29.0

package/templates/skills/apex/steps/step-02-plan.md

@@ -108,6 +108,15 @@ Verify the plan respects dependencies:
 - Build gate between EVERY layer (must pass): Layer 0 → 1 → 2 → 3 → 4
 ```
 
+### 4b. Module Code Collision Guard (BLOCKING)
+
+```
+IF appCode == moduleCode:
+  BLOCK — module_code identique à app_code cause des segments doublés (e.g. /hr/hr).
+  Suggestion : "{appCode}-core", "{appCode}-management"
+  ASK user pour un module_code différent.
+```
+
 ---
 
 ## 5. Estimated Commits

package/templates/skills/apex/steps/step-03-execute.md

@@ -298,6 +298,39 @@ After controller generation, verify `[NavRoute]` attribute is present on every c
 - When calling `scaffold_extension(type: "controller")`, always pass `navRoute` in options
 - This is REQUIRED for `scaffold_routes` to auto-detect routes in Layer 3
 
+### Guard: NavRoute Uniqueness and Segment Count (MANDATORY)
+
+**BEFORE proceeding past Layer 2**, verify for EACH controller:
+
+1. **Unique NavRoute:** No two controllers may share the same `[NavRoute("...")]` value. Duplicate NavRoutes cause routing conflicts → 404s on one of the controllers.
+
+2. **Segment count matches hierarchy:** Count the dots in the NavRoute value:
+   - 1 dot = 2 segments (module-level, e.g., `human-resources.employees`) — controller is at `Controllers/{App}/`
+   - 2 dots = 3 segments (section-level, e.g., `human-resources.employees.contracts`) — controller is at `Controllers/{App}/{Module}/` or in a section subfolder
+   - **If a controller is in a section subfolder** (e.g., `Controllers/{App}/Employees/ContractsController.cs`) **but has only 2 segments** → the API route will be wrong → 404. It MUST have 3 segments.
+   - 0 dots = INVALID → BLOCK
+
+```bash
+# Quick validation
+CTRL_FILES=$(find src/ -path "*/Controllers/*" -name "*Controller.cs" 2>/dev/null)
+for f in $CTRL_FILES; do
+  NAVROUTE=$(grep -oP '\[NavRoute\("\K[^"]+' "$f")
+  if [ -n "$NAVROUTE" ]; then
+    DOTS=$(echo "$NAVROUTE" | tr -cd '.' | wc -c)
+    if [ "$DOTS" -eq 0 ]; then
+      echo "BLOCKING: NavRoute '$NAVROUTE' has only 1 segment (need minimum 2): $f"
+      exit 1
+    fi
+    # Check if controller is in a section subfolder but NavRoute has only 2 segments
+    DEPTH=$(echo "$f" | grep -oP 'Controllers/[^/]+/[^/]+/' | wc -l)
+    if [ "$DEPTH" -gt 0 ] && [ "$DOTS" -eq 1 ]; then
+      echo "WARNING: Controller in section subfolder but NavRoute has only 2 segments: $f"
+      echo "  NavRoute: $NAVROUTE — expected 3 segments (app.module.section)"
+    fi
+  fi
+done
+```
+
 ```bash
 # Quick check: all controllers must have [NavRoute] (not just [Route])
 CTRL_FILES=$(find src/ -path "*/Controllers/*" -name "*Controller.cs" 2>/dev/null)
@@ -386,11 +419,20 @@ TaskUpdate(taskId: progress_tracker_id,
 
 For each module:
 - API client: MCP scaffold_api_client
-- Routes: MCP scaffold_routes (outputFormat: 'applicationRoutes') → generates lazy imports + Suspense
+- Routes — TWO mandatory steps:
+  1. Generate registry: MCP scaffold_routes (source: 'controllers', outputFormat: 'applicationRoutes', dryRun: false)
+     → Creates navRoutes.generated.ts (required by POST-CHECK C2)
+  2. Wire to App.tsx (see below)
 - Wire Routes to App.tsx: After scaffold_routes, routes must be wired into App.tsx:
   → Read App.tsx and detect the routing pattern
   → Pattern A (`applicationRoutes: ApplicationRouteExtensions`): add routes to `applicationRoutes['{application_kebab}'][]` with RELATIVE paths
   → Pattern B (JSX `<Route>`): nest routes inside `<Route path="/{application}" element={<AppLayout />}>` + duplicate in tenant block
+  → **CRITICAL — Module Segment Required:** Route paths MUST include the module segment.
+    For a 3-level hierarchy (app → module → sections), paths are `{module_kebab}/{section_kebab}`.
+    Example: `employee-management/employees` NOT just `employees`.
+    Without the module segment, routes resolve to `/{app}/{section}` instead of `/{app}/{module}/{section}`,
+    causing mismatch with backend navigation seed data → nav links produce 404s.
+  → **BEFORE wiring:** Verify route ordering — static routes (`create`, `dashboard`, `departments`) MUST come BEFORE dynamic routes (`:id`, `:id/edit`). Redirect routes (`Navigate`) MUST be LAST. See `references/smartstack-layers.md` "RULE — Frontend Route Ordering".
   → Do not add business routes to `clientRoutes[]` — it is only for non-app routes (`/about`, `/pricing`)
   → All business applications use `<AppLayout />` as layout wrapper
   → See `references/frontend-route-wiring-app-tsx.md` for full Pattern A/B detection and examples
@@ -445,7 +487,9 @@ For each module:
     5. Verify: `grep -q "{module_namespace}" src/**/i18n/config.ts` → must match
 - Permissions: Call MCP generate_permissions for the module permission root (2 segments: {app}.{module}),
   then also call MCP generate_permissions for each section (3 segments: {app}.{module}.{section}).
-- Section routes: Add section child routes to the module's children array.
+- Section routes: Add section child routes to `applicationRoutes['{app_kebab}']`.
+  Route paths MUST include the module segment: `{module_kebab}/{section_kebab}` (e.g., `employee-management/employees`).
+  Do NOT use just `{section_kebab}` (e.g., `employees`) — this omits the module level and causes 404s.
   Wire PermissionGuard for section routes with section-level permissions.
 - MUST use src/pages/{App}/{Module}/ hierarchy (NOT flat)
 
@@ -480,8 +524,9 @@ IF NOT economy_mode AND entities.length > 1:
       prompt='Execute Layer 3 frontend for {EntityName}:
         **MANDATORY: Read references/smartstack-frontend.md FIRST**
         - API client: MCP scaffold_api_client
-        - Routes: MCP scaffold_routes (outputFormat: "applicationRoutes")
+        - Routes: MCP scaffold_routes (outputFormat: "applicationRoutes", dryRun: false) → MUST generate navRoutes.generated.ts
         - Wire Routes to App.tsx (BLOCKING): detect Pattern A/B, wire accordingly
+          → CRITICAL: Route paths MUST include module segment: {module_kebab}/{section_kebab} (e.g., employee-management/employees, NOT just employees)
           → See references/frontend-route-wiring-app-tsx.md for full patterns
           → Verify: mcp__smartstack__validate_frontend_routes (scope: "routes")
         - Pages: /ui-components skill (ALL 4 types: List, Detail, Create, Edit)
@@ -502,6 +547,7 @@ ELSE:
     1. MCP scaffold_api_client
     2. MCP scaffold_routes (outputFormat: 'applicationRoutes')
     3. Wire routes to App.tsx (Pattern A/B — see references/frontend-route-wiring-app-tsx.md)
+       CRITICAL: paths MUST include module segment: {module_kebab}/{section_kebab} (e.g., employee-management/employees)
     4. **INVOKE Skill("ui-components")** — pass entity context:
        - Entity: {EntityName}, Module: {ModuleName}, App: {AppName}
        - Page types: List, Detail, Create, Edit (+ Dashboard if applicable)

package/templates/skills/apex/steps/step-04-examine.md

@@ -65,6 +65,9 @@ Verify:
 - Routes nested inside correct Layout wrapper
 - Route paths match controller patterns
 - No orphan routes
+- Route paths include module segment (e.g., 'employee-management/employees', NOT just 'employees')
+  → Compare frontend route paths in App.tsx against backend NavigationSeedData routes
+  → If backend defines route /app/module/section, frontend must use module/section (relative)
 ```
 
 ### 3b. Frontend Page Completeness
@@ -196,6 +199,7 @@ AC2: {criterion} → PASS / FAIL (evidence: {file:line or test})
 | I18n registration | Namespaces registered in i18n config (POST-CHECK C39) | PASS / N/A |
 | Validators DI | FluentValidation registered in DI (POST-CHECK C40) | PASS / N/A |
 | Route/NavRoute conflict | No [Route] alongside [NavRoute] on controllers (POST-CHECK C43) | PASS / N/A |
+| Route module segment | Frontend routes include module segment matching seed data (POST-CHECK C52) | PASS / N/A |
 | Role-permission matrix | Admin=wildcard, Manager=CRU, Contributor=CR, Viewer=R (POST-CHECK C44) | PASS / N/A |
 | PermissionAction enum | No Enum.Parse, only typed enum values 0-10 (POST-CHECK C45) | PASS / N/A |
 | Navigation translations | 4 langs per level, section/resource translations present (POST-CHECK C46) | PASS / N/A |

package/templates/skills/application/references/frontend-route-wiring-app-tsx.md

@@ -69,6 +69,39 @@ const applicationRoutes: ApplicationRouteExtensions = {
 
 Routes are automatically injected into BOTH standard (`/{application}/...`) and tenant-prefixed (`/t/:slug/{application}/...`) route trees by `mergeRoutes()`. No manual duplication needed.
 
+#### RULE — Route Ordering in applicationRoutes
+
+> **CRITICAL:** Routes within each application key MUST follow static-before-dynamic order.
+> React Router matches top-to-bottom — a `:id` route placed before a `dashboard` route
+> will match `dashboard` as an `id` parameter → 404.
+
+```tsx
+const applicationRoutes: ApplicationRouteExtensions = {
+  'human-resources': [
+    // ✅ CORRECT ORDER — static before dynamic
+    { path: 'employees', element: <EmployeesPage /> },
+    { path: 'employees/create', element: <CreateEmployeePage /> },
+    { path: 'employees/dashboard', element: <EmployeeDashboardPage /> },
+    { path: 'employees/:id', element: <EmployeeDetailPage /> },
+    { path: 'employees/:id/edit', element: <EditEmployeePage /> },
+
+    // Redirect routes ALWAYS LAST
+    { path: '', element: <Navigate to="employees" replace /> },
+  ],
+};
+```
+
+```tsx
+// ❌ FORBIDDEN — :id before static routes
+'human-resources': [
+  { path: 'employees/:id', element: <EmployeeDetailPage /> },      // ← WRONG: catches 'dashboard'
+  { path: 'employees/dashboard', element: <DashboardPage /> },      // ← NEVER REACHED
+]
+```
+
+See `smartstack-layers.md` "RULE — Frontend Route Ordering" for the full ordering specification.
+POST-CHECK C49 detects and BLOCKS this anti-pattern.
+
 #### Custom Applications (Pattern A)
 
 Custom application keys (any key **not** in the built-in list: `administration`, `support`, `user`, `api`) are fully supported in `applicationRoutes`. `mergeRoutes()` automatically:

package/templates/skills/business-analyse/questionnaire/01-context.md

@@ -1,38 +1,38 @@
-# Categorie 1 : Contexte metier
+# Catégorie 1 : Contexte métier
 
-> **Usage :** Questions fondamentales pour comprendre le besoin metier
+> **Usage :** Questions fondamentales pour comprendre le besoin métier
 > **Quand charger :** TOUJOURS (noyau)
-> **Objectif :** Comprendre le processus metier, les frictions, et la vision cible
+> **Objectif :** Comprendre le processus métier, les frictions, et la vision cible
 
 ---
 
-## 1.1 Le processus metier
+## 1.1 Le processus métier
 
-| # | Question | Type de reponse |
+| # | Question | Type de réponse |
 |---|----------|-----------------|
-| Q1.1 | Decrivez en quelques phrases le processus metier que cette application doit gerer. Qu'est-ce qui se passe, qui intervient, et quel est le resultat attendu ? | Texte libre |
+| Q1.1 | Décrivez en quelques phrases le processus métier que cette application doit gérer. Qu'est-ce qui se passe, qui intervient, et quel est le résultat attendu ? | Texte libre |
 
 ---
 
 ## 1.2 Les points de friction
 
-| # | Question | Type de reponse |
+| # | Question | Type de réponse |
 |---|----------|-----------------|
-| Q1.4 | Quels sont les points de friction actuels ? Qu'est-ce qui bloque, ralentit, ou genere des erreurs dans ce processus ? | Description des frictions |
+| Q1.4 | Quels sont les points de friction actuels ? Qu'est-ce qui bloque, ralentit, ou génère des erreurs dans ce processus ? | Description des frictions |
 
 ---
 
-## 1.3 La vision souhaitee
+## 1.3 La vision souhaitée
 
-| # | Question | Type de reponse |
+| # | Question | Type de réponse |
 |---|----------|-----------------|
-| Q1.8 | Qu'est-ce qui doit changer ? Si le probleme etait resolu demain, que feriez-vous differemment dans votre journee de travail ? | Description du changement concret |
+| Q1.8 | Qu'est-ce qui doit changer ? Si le problème était résolu demain, que feriez-vous différemment dans votre journée de travail ? | Description du changement concret |
 
 ---
 
 ## Mapping vers le cadrage
 
-| Reponse | Alimente |
+| Réponse | Alimente |
 |---------|----------|
 | Q1.1 | `cadrage.problem` |
 | Q1.4 | `cadrage.asIs` |

package/templates/skills/business-analyse/questionnaire/02-stakeholders-scope.md

@@ -1,56 +1,56 @@
-# Categorie 2 : Parties prenantes et perimetre
+# Catégorie 2 : Parties prenantes et périmètre
 
-> **Usage :** Identifier les profils utilisateurs, leurs droits, et delimiter le perimetre fonctionnel
+> **Usage :** Identifier les profils utilisateurs, leurs droits, et délimiter le périmètre fonctionnel
 > **Quand charger :** TOUJOURS (noyau)
-> **Objectif :** Comprendre QUI utilise le systeme, avec quels DROITS, et QUOI il doit faire
+> **Objectif :** Comprendre QUI utilise le système, avec quels DROITS, et QUOI il doit faire
 
 ---
 
 ## 2.1 Identification des utilisateurs
 
-> **But :** Identifier les types de profils/roles qui interagiront avec le systeme.
+> **But :** Identifier les types de profils/rôles qui interagiront avec le système.
 
-| # | Question | Type de reponse |
+| # | Question | Type de réponse |
 |---|----------|-----------------|
-| Q2.1 | Qui sont les types de profils qui utiliseront ce systeme ? Decrivez leurs roles et ce qu'ils font. | Liste de profils utilisateurs |
+| Q2.1 | Qui sont les types de profils qui utiliseront ce système ? Décrivez leurs rôles et ce qu'ils font. | Liste de profils utilisateurs |
 
 ---
 
-## 2.2 Taches par profil
+## 2.2 Tâches par profil
 
-> **But :** Comprendre concretement ce que chaque type d'utilisateur fait.
+> **But :** Comprendre concrètement ce que chaque type d'utilisateur fait.
 
-| # | Question | Type de reponse |
+| # | Question | Type de réponse |
 |---|----------|-----------------|
-| Q2.5 | Pour chaque type d'utilisateur : quelles sont les 3 a 5 taches principales qu'il doit accomplir avec ce systeme ? | Taches par profil utilisateur |
+| Q2.5 | Pour chaque type d'utilisateur : quelles sont les 3 à 5 tâches principales qu'il doit accomplir avec ce système ? | Tâches par profil utilisateur |
 
 ---
 
-## 2.3 Les niveaux d'acces
+## 2.3 Les niveaux d'accès
 
-> **But :** Definir qui peut voir quoi et faire quoi.
+> **But :** Définir qui peut voir quoi et faire quoi.
 
-| # | Question | Type de reponse |
+| # | Question | Type de réponse |
 |---|----------|-----------------|
-| Q2.9 | Tous les utilisateurs doivent-ils voir les memes informations ? Si non, qui voit quoi ? | Regles de visibilite des donnees |
-| Q2.10 | Qui a le droit de modifier ou supprimer des informations ? Tout le monde ou seulement certaines personnes ? | Regles de modification |
-| Q2.11 | Y a-t-il des actions sensibles qui necessitent une validation par un superieur ? | Liste des actions a valider |
+| Q2.9 | Tous les utilisateurs doivent-ils voir les mêmes informations ? Si non, qui voit quoi ? | Règles de visibilité des données |
+| Q2.10 | Qui a le droit de modifier ou supprimer des informations ? Tout le monde ou seulement certaines personnes ? | Règles de modification |
+| Q2.11 | Y a-t-il des actions sensibles qui nécessitent une validation par un supérieur ? | Liste des actions à valider |
 
 ---
 
-## 2.4 Perimetre fonctionnel
+## 2.4 Périmètre fonctionnel
 
-> **But :** Lister tout ce que le systeme doit faire et ne pas faire, avec des priorites claires.
+> **But :** Lister tout ce que le système doit faire et ne pas faire, avec des priorités claires.
 
-| # | Question | Type de reponse |
+| # | Question | Type de réponse |
 |---|----------|-----------------|
-| Q2.12 | Listez toutes les fonctionnalites que vous souhaitez dans ce systeme. Ne vous censurez pas. | Liste libre de fonctionnalites |
-| Q2.13 | Parmi cette liste, quelles sont les fonctionnalites INDISPENSABLES ? Celles sans lesquelles le systeme n'a aucun interet ? | Liste de fonctionnalites vitales |
-| Q2.15 | Y a-t-il des choses que le systeme ne doit explicitement PAS faire ? Des limites claires a poser ? | Liste d'exclusions |
+| Q2.12 | Listez toutes les fonctionnalités que vous souhaitez dans ce système. Ne vous censurez pas. | Liste libre de fonctionnalités |
+| Q2.13 | Parmi cette liste, quelles sont les fonctionnalités INDISPENSABLES ? Celles sans lesquelles le système n'a aucun intérêt ? | Liste de fonctionnalités vitales |
+| Q2.15 | Y a-t-il des choses que le système ne doit explicitement PAS faire ? Des limites claires à poser ? | Liste d'exclusions |
 
-**Test de priorite :**
-> Pour chaque fonctionnalite classee comme indispensable, poser la question :
-> "Si on enlevait cette fonctionnalite, le systeme aurait-il encore de la valeur ?"
+**Test de priorité :**
+> Pour chaque fonctionnalité classée comme indispensable, poser la question :
+> "Si on enlevait cette fonctionnalité, le système aurait-il encore de la valeur ?"
 
 ---
 
@@ -58,42 +58,42 @@
 
 > **But :** Comprendre le flux de travail principal de bout en bout.
 
-| # | Question | Type de reponse |
+| # | Question | Type de réponse |
 |---|----------|-----------------|
-| Q2.16 | Decrivez le parcours typique d'un utilisateur du debut a la fin : il ouvre le systeme, que fait-il en premier ? | Liste d'etapes ordonnees |
-| Q2.17 | A quels moments l'utilisateur doit-il prendre une decision ? Quelles sont les options possibles ? | Points de decision et options |
-| Q2.18 | Que se passe-t-il quand quelque chose ne se deroule pas comme prevu ? Quels sont les cas particuliers ? | Scenarios alternatifs |
+| Q2.16 | Décrivez le parcours typique d'un utilisateur du début à la fin : il ouvre le système, que fait-il en premier ? | Liste d'étapes ordonnées |
+| Q2.17 | À quels moments l'utilisateur doit-il prendre une décision ? Quelles sont les options possibles ? | Points de décision et options |
+| Q2.18 | Que se passe-t-il quand quelque chose ne se déroule pas comme prévu ? Quels sont les cas particuliers ? | Scénarios alternatifs |
 
 ---
 
-## Guide d'elicitation approfondi
+## Guide d'élicitation approfondi
 
 ### Techniques de relance
 
-| Question | Si la reponse est vague | Relance recommandee |
+| Question | Si la réponse est vague | Relance recommandée |
 |----------|------------------------|---------------------|
-| Q2.1 (utilisateurs) | Un seul type mentionne | "Pensez aux differents moments de la journee : qui saisit ? Qui consulte les rapports ? Qui gere les cas particuliers ?" |
-| Q2.5 (taches) | Taches generiques | "Quand il arrive le matin et ouvre le systeme, quelle est sa premiere action ?" |
-| Q2.9 (visibilite) | Reponse ambigue | "Un employe du service A peut-il voir les donnees du service B ? Un stagiaire voit-il la meme chose qu'un directeur ?" |
-| Q2.13 (indispensable) | Tout est indispensable | "Si vous ne pouviez garder que 3 fonctionnalites pour un premier lancement, lesquelles ?" |
-| Q2.15 (exclusions) | "Je ne vois pas" | "Certains utilisateurs pourraient-ils s'attendre a des fonctionnalites que vous ne souhaitez PAS inclure ?" |
-| Q2.16 (parcours) | Moins de 3 etapes | "Detaillons : l'utilisateur arrive sur l'ecran d'accueil. Que voit-il ? Ou clique-t-il ?" |
+| Q2.1 (utilisateurs) | Un seul type mentionné | "Pensez aux différents moments de la journée : qui saisit ? Qui consulte les rapports ? Qui gère les cas particuliers ?" |
+| Q2.5 (tâches) | Tâches génériques | "Quand il arrive le matin et ouvre le système, quelle est sa première action ?" |
+| Q2.9 (visibilité) | Réponse ambiguë | "Un employé du service A peut-il voir les données du service B ? Un stagiaire voit-il la même chose qu'un directeur ?" |
+| Q2.13 (indispensable) | Tout est indispensable | "Si vous ne pouviez garder que 3 fonctionnalités pour un premier lancement, lesquelles ?" |
+| Q2.15 (exclusions) | "Je ne vois pas" | "Certains utilisateurs pourraient-ils s'attendre à des fonctionnalités que vous ne souhaitez PAS inclure ?" |
+| Q2.16 (parcours) | Moins de 3 étapes | "Détaillons : l'utilisateur arrive sur l'écran d'accueil. Que voit-il ? Où clique-t-il ?" |
 
-### Signaux d'alerte a detecter
+### Signaux d'alerte à détecter
 
-| Signal du client | Probleme sous-jacent | Action de l'analyste |
+| Signal du client | Problème sous-jacent | Action de l'analyste |
 |------------------|---------------------|----------------------|
-| "Tous les utilisateurs font la meme chose" | Roles non differencies | "Qui peut supprimer ? Qui ne fait que consulter ? Qui valide ?" |
-| "Tout le monde doit tout voir" | Securite non reflechie | "Meme les stagiaires ? Les prestataires externes ? Les donnees salariales ?" |
-| Tout est indispensable (> 10 vitaux) | Priorites non definies | Appliquer le test de priorite |
-| Aucune exclusion identifiee | Perimetre non borne | "Y a-t-il des aspects qui relevent d'un autre projet ou d'une version future ?" |
-| Parcours lineaire sans alternative | Seul le cas ideal est decrit | "Que se passe-t-il a l'etape X si la condition Y n'est pas remplie ?" |
+| "Tous les utilisateurs font la même chose" | Rôles non différenciés | "Qui peut supprimer ? Qui ne fait que consulter ? Qui valide ?" |
+| "Tout le monde doit tout voir" | Sécurité non réfléchie | "Même les stagiaires ? Les prestataires externes ? Les données salariales ?" |
+| Tout est indispensable (> 10 vitaux) | Priorités non définies | Appliquer le test de priorité |
+| Aucune exclusion identifiée | Périmètre non borné | "Y a-t-il des aspects qui relèvent d'un autre projet ou d'une version future ?" |
+| Parcours linéaire sans alternative | Seul le cas idéal est décrit | "Que se passe-t-il à l'étape X si la condition Y n'est pas remplie ?" |
 
 ---
 
 ## Mapping vers le cadrage
 
-| Reponse | Alimente |
+| Réponse | Alimente |
 |---------|----------|
 | Q2.1, Q2.5 | `cadrage.stakeholders[]` |
 | Q2.9-Q2.11 | `cadrage.applicationRoles[]` |

package/templates/skills/business-analyse/questionnaire/03-data-ui.md

@@ -1,8 +1,8 @@
-# Categorie 3 : Donnees et interface
+# Catégorie 3 : Données et interface
 
-> **Usage :** Definir les entites, les regles de donnees et l'experience utilisateur
-> **Quand charger :** Par module, lors de la specification (step-03)
-> **Objectif :** Comprendre les donnees manipulees et comment elles sont presentees
+> **Usage :** Définir les entités, les règles de données et l'expérience utilisateur
+> **Quand charger :** Par module, lors de la spécification (step-03)
+> **Objectif :** Comprendre les données manipulées et comment elles sont présentées
 
 ---
 
@@ -10,69 +10,69 @@
 
 | # | Question | Type de reponse |
 |---|----------|-----------------|
-| Q3.1 | Quelles sont les entites principales gerees par ce module ? | Liste d'entites |
-| Q3.2 | Pour chaque entite : quels sont les attributs importants ? | Par entite |
-| Q3.3 | Quelles relations existent entre les entites ? (appartient a, contient, reference) | Schema relationnel |
-| Q3.5 | Pour chaque entite : le Code doit-il etre auto-genere ou saisi par l'utilisateur ? | Par entite |
-| Q3.6 | Si auto-genere : quelle strategie ? (sequentiel, timestamp, annee, UUID court) | Par entite |
+| Q3.1 | Quelles sont les entités principales gérées par ce module ? | Liste d'entités |
+| Q3.2 | Pour chaque entité : quels sont les attributs importants ? | Par entité |
+| Q3.3 | Quelles relations existent entre les entités ? (appartient à, contient, référence) | Schéma relationnel |
+| Q3.5 | Pour chaque entité : le Code doit-il être auto-généré ou saisi par l'utilisateur ? | Par entité |
+| Q3.6 | Si auto-généré : quelle stratégie ? (séquentiel, timestamp, année, UUID court) | Par entité |
 
-## 3.2 Regles de donnees
+## 3.2 Règles de données
 
-| # | Question | Type de reponse |
+| # | Question | Type de réponse |
 |---|----------|-----------------|
-| Q3.7 | Quelles validations sur les donnees ? (champs obligatoires, formats, plages de valeurs) | Liste de regles |
-| Q3.8 | Y a-t-il des regles inter-champs ? (date fin > date debut, montant selon statut) | Liste de contraintes |
-| Q3.9 | Donnees sensibles a proteger ? (donnees personnelles, financieres, medicales) | Liste + niveau |
+| Q3.7 | Quelles validations sur les données ? (champs obligatoires, formats, plages de valeurs) | Liste de règles |
+| Q3.8 | Y a-t-il des règles inter-champs ? (date fin > date début, montant selon statut) | Liste de contraintes |
+| Q3.9 | Données sensibles à protéger ? (données personnelles, financières, médicales) | Liste + niveau |
 
 ---
 
-## 3.3 Interface et ecrans
+## 3.3 Interface et écrans
 
-| # | Question | Type de reponse |
+| # | Question | Type de réponse |
 |---|----------|-----------------|
-| Q3.10 | Peripheriques cibles ? (desktop, mobile, tablette) | Liste |
-| Q3.11 | Ecrans principaux necessaires pour ce module ? | Liste d'ecrans |
-| Q3.12 | Informations cles par ecran ? Quelles colonnes dans la liste, quels champs dans le formulaire ? | Par ecran |
-| Q3.13 | Actions possibles par ecran ? (creer, editer, supprimer, valider, exporter, changer statut) | Par ecran |
+| Q3.10 | Périphériques cibles ? (desktop, mobile, tablette) | Liste |
+| Q3.11 | Écrans principaux nécessaires pour ce module ? | Liste d'écrans |
+| Q3.12 | Informations clés par écran ? Quelles colonnes dans la liste, quels champs dans le formulaire ? | Par écran |
+| Q3.13 | Actions possibles par écran ? (créer, éditer, supprimer, valider, exporter, changer statut) | Par écran |
 
 ## 3.4 Tableaux de bord
 
-| # | Question | Type de reponse |
+| # | Question | Type de réponse |
 |---|----------|-----------------|
 | Q3.14 | Des tableaux de bord ou indicateurs sont-ils requis pour ce module ? | Oui/Non + description |
-| Q3.15 | KPIs a afficher ? (nom, metrique, format, seuils d'alerte) | Par dashboard |
-| Q3.16 | Types de graphiques souhaites ? (barres, lignes, camembert, cartes KPI) | Par KPI |
+| Q3.15 | KPIs à afficher ? (nom, métrique, format, seuils d'alerte) | Par dashboard |
+| Q3.16 | Types de graphiques souhaités ? (barres, lignes, camembert, cartes KPI) | Par KPI |
 
 ---
 
-## Guide d'elicitation approfondi
+## Guide d'élicitation approfondi
 
 ### Techniques de relance
 
-| Question | Si la reponse est vague | Relance recommandee |
+| Question | Si la réponse est vague | Relance recommandée |
 |----------|------------------------|---------------------|
-| Q3.1 (entites) | Une seule entite | "Cette entite a-t-elle des sous-elements ? (lignes de detail, pieces jointes, historique)" |
-| Q3.1 (entites) | Mention de "User" | "L'utilisateur est gere par la plateforme. Decrivez l'entite METIER (Client, Employee, Contact...)" |
-| Q3.2 (attributs) | Champs techniques (ID, CreatedDate) | "Les champs techniques sont auto-geres. Quels sont les attributs METIER ?" |
-| Q3.3 (relations) | "1:N" sans detail | "Un {Parent} peut avoir combien de {Children} max ? Un {Child} peut-il exister sans {Parent} ?" |
-| Q3.11 (ecrans) | "Un ecran de liste" | "Avec pages dediees pour creation et edition ? Detail en page avec onglets ?" |
-| Q3.13 (actions) | "CRUD classique" | "Actions metier specifiques ? (valider, dupliquer, archiver, changer statut, assigner)" |
+| Q3.1 (entités) | Une seule entité | "Cette entité a-t-elle des sous-éléments ? (lignes de détail, pièces jointes, historique)" |
+| Q3.1 (entités) | Mention de "User" | "L'utilisateur est géré par la plateforme. Décrivez l'entité MÉTIER (Client, Employee, Contact...)" |
+| Q3.2 (attributs) | Champs techniques (ID, CreatedDate) | "Les champs techniques sont auto-gérés. Quels sont les attributs MÉTIER ?" |
+| Q3.3 (relations) | "1:N" sans détail | "Un {Parent} peut avoir combien de {Children} max ? Un {Child} peut-il exister sans {Parent} ?" |
+| Q3.11 (écrans) | "Un écran de liste" | "Avec pages dédiées pour création et édition ? Détail en page avec onglets ?" |
+| Q3.13 (actions) | "CRUD classique" | "Actions métier spécifiques ? (valider, dupliquer, archiver, changer statut, assigner)" |
 | Q3.14 (dashboards) | "Juste des chiffres" | "Les tendances ne seraient-elles pas plus lisibles en graphique ?" |
 
-### Anti-patterns a detecter
+### Anti-patterns à détecter
 
 | Signal | Anti-pattern | Action |
 |--------|-------------|--------|
-| Entite "User" avec attributs metier | Confusion User/Identity | La plateforme gere les Users via Identity |
-| Attributs Id, TenantId, CreatedBy | Champs techniques comme metier | Ces champs sont auto-generes par AuditableEntity |
+| Entité "User" avec attributs métier | Confusion User/Identity | La plateforme gère les Users via Identity |
+| Attributs Id, TenantId, CreatedBy | Champs techniques comme métier | Ces champs sont auto-générés par AuditableEntity |
 | "Un seul gros formulaire avec tout" | Formulaire monolithique | Proposer des onglets ou wizard par section logique |
-| Actions sans confirmation | Actions destructives non protegees | "La suppression necessite-t-elle une confirmation ?" |
+| Actions sans confirmation | Actions destructives non protégées | "La suppression nécessite-t-elle une confirmation ?" |
 
 ---
 
 ## RBAC Exclusion
 
-> Les concepts suivants sont geres par le systeme RBAC de la plateforme et NE DOIVENT PAS etre modelises comme attributs d'entite :
+> Les concepts suivants sont gérés par le système RBAC de la plateforme et NE DOIVENT PAS être modélisés comme attributs d'entité :
 
 | Concept | Wrong (attribut) | Correct (RBAC) |
 |---------|-----------------|----------------|
@@ -84,9 +84,9 @@
 
 ## Mapping vers le feature
 
-| Reponse | Alimente |
+| Réponse | Alimente |
 |---------|----------|
-| Q3.1-Q3.3, Q3.5-Q3.6 | `entities.json` (entites, attributs, relations, codePattern) |
-| Q3.7-Q3.9 | `rules.json` (regles metier de validation et securite) |
+| Q3.1-Q3.3, Q3.5-Q3.6 | `entities.json` (entités, attributs, relations, codePattern) |
+| Q3.7-Q3.9 | `rules.json` (règles métier de validation et sécurité) |
 | Q3.10-Q3.13 | `screens.json` (sections, resources, colonnes, actions) |
 | Q3.14-Q3.16 | `screens.json` (sections dashboard, KPI resources) |

package/templates/skills/business-analyse/questionnaire/05-cross-module.md

@@ -1,28 +1,28 @@
-# Categorie 5 : Impact cross-module
+# Catégorie 5 : Impact cross-module
 
-> **Usage :** Analyser l'impact sur les modules existants et les dependances partagees
-> **Quand charger :** TOUJOURS pour les nouveaux modules (pas les ameliorations)
-> **Objectif :** Detecter les interactions, les entites partagees et les impacts d'integration
+> **Usage :** Analyser l'impact sur les modules existants et les dépendances partagées
+> **Quand charger :** TOUJOURS pour les nouveaux modules (pas les améliorations)
+> **Objectif :** Détecter les interactions, les entités partagées et les impacts d'intégration
 
 ---
 
-## 5.1 Dependances avec les modules existants
+## 5.1 Dépendances avec les modules existants
 
-| # | Question | Type de reponse |
+| # | Question | Type de réponse |
 |---|----------|-----------------|
 | Q5.1 | Avec quels modules existants ce nouveau module interagit-il ? | Liste de modules |
-| Q5.2 | Quelles donnees sont partagees entre modules ? (entites, tables de reference) | Par module |
-| Q5.3 | Y a-t-il des entites existantes que ce module va referencer ? (relations FK) | Liste de references |
-| Q5.4 | Ce module produira-t-il des evenements que d'autres modules consomment ? | Liste d'evenements |
+| Q5.2 | Quelles données sont partagées entre modules ? (entités, tables de référence) | Par module |
+| Q5.3 | Y a-t-il des entités existantes que ce module va référencer ? (relations FK) | Liste de références |
+| Q5.4 | Ce module produira-t-il des événements que d'autres modules consomment ? | Liste d'événements |
 
-## 5.2 Evaluation d'impact
+## 5.2 Évaluation d'impact
 
-| # | Question | Type de reponse |
+| # | Question | Type de réponse |
 |---|----------|-----------------|
-| Q5.5 | Les modules existants doivent-ils etre modifies pour supporter ce nouveau module ? | Liste de changements |
-| Q5.6 | Y a-t-il des composants UI ou des changements de navigation partages ? | Liste |
-| Q5.7 | Ce module affectera-t-il les permissions ou roles existants ? Quel impact sur l'integration ? | Oui/Non + detail |
-| Q5.8 | Y a-t-il des entites partagees modifiees par plusieurs modules ? Quel impact sur l'integration ? | Evaluation de l'impact |
+| Q5.5 | Les modules existants doivent-ils être modifiés pour supporter ce nouveau module ? | Liste de changements |
+| Q5.6 | Y a-t-il des composants UI ou des changements de navigation partagés ? | Liste |
+| Q5.7 | Ce module affectera-t-il les permissions ou rôles existants ? Quel impact sur l'intégration ? | Oui/Non + détail |
+| Q5.8 | Y a-t-il des entités partagées modifiées par plusieurs modules ? Quel impact sur l'intégration ? | Évaluation de l'impact |
 
 ---
 
@@ -30,40 +30,40 @@
 
 | Besoin | Pattern | Exemple |
 |--------|---------|---------|
-| Reference une entite | Navigation property + FK | `Order.ClientId -> Client` |
-| Donnees de reference partagees | Entite partagee dans Domain | `Status`, `Category` |
-| Notification evenementielle | MediatR notification | `OrderCreatedNotification` |
-| Requete cross-module | DTO en lecture seule | `IClientQueryService` |
+| Référence une entité | Navigation property + FK | `Order.ClientId -> Client` |
+| Données de référence partagées | Entité partagée dans Domain | `Status`, `Category` |
+| Notification événementielle | MediatR notification | `OrderCreatedNotification` |
+| Requête cross-module | DTO en lecture seule | `IClientQueryService` |
 | Lien de navigation | NavRoute entry | `business/{app}/{module}` |
-| Permission partagee | Hierarchie de permissions | `{app}.*` covers all modules |
+| Permission partagée | Hiérarchie de permissions | `{app}.*` covers all modules |
 
 ---
 
-## Guide d'elicitation
+## Guide d'élicitation
 
 ### Techniques de relance
 
-| Question | Si la reponse est vague | Relance recommandee |
+| Question | Si la réponse est vague | Relance recommandée |
 |----------|------------------------|---------------------|
-| Q5.1 (interactions) | "Aucun" | "Ce module est totalement isole ? Pas de lien avec des clients, produits, utilisateurs d'autres modules ?" |
-| Q5.2 (donnees partagees) | "Je ne sais pas" | Utiliser le `{codebase_context}` : "J'ai trouve les entites {list}. Ce module a-t-il besoin de les referencer ?" |
-| Q5.3 (FK references) | Vague | "Une {entity} de ce module appartient-elle a un {existing_entity} ?" |
-| Q5.4 (evenements) | "Non" | "Quand un {entity} est cree/modifie/supprime, faut-il notifier un autre module ?" |
-| Q5.8 (impact) | "Pas d'impact" | "Deux modules modifient-ils la meme entite ? Quel est l'impact sur l'integration ?" |
+| Q5.1 (interactions) | "Aucun" | "Ce module est totalement isolé ? Pas de lien avec des clients, produits, utilisateurs d'autres modules ?" |
+| Q5.2 (données partagées) | "Je ne sais pas" | Utiliser le `{codebase_context}` : "J'ai trouvé les entités {list}. Ce module a-t-il besoin de les référencer ?" |
+| Q5.3 (FK références) | Vague | "Une {entity} de ce module appartient-elle à un {existing_entity} ?" |
+| Q5.4 (événements) | "Non" | "Quand un {entity} est créé/modifié/supprimé, faut-il notifier un autre module ?" |
+| Q5.8 (impact) | "Pas d'impact" | "Deux modules modifient-ils la même entité ? Quel est l'impact sur l'intégration ?" |
 
-### Anti-patterns a detecter
+### Anti-patterns à détecter
 
 | Signal | Anti-pattern | Action |
 |--------|-------------|--------|
-| Module totalement isole | Silo de donnees | Rare qu'un module metier n'ait aucune connexion. Verifier avec le codebase context. |
-| Duplication d'entite existante | Entite dupliquee | Si `Client` existe deja, ne pas creer `Customer`. Referencer l'existant. |
-| Modification d'entite d'un autre module | Couplage fort | Utiliser des evenements (MediatR) plutot que des modifications directes. |
+| Module totalement isolé | Silo de données | Rare qu'un module métier n'ait aucune connexion. Vérifier avec le codebase context. |
+| Duplication d'entité existante | Entité dupliquée | Si `Client` existe déjà, ne pas créer `Customer`. Référencer l'existant. |
+| Modification d'entité d'un autre module | Couplage fort | Utiliser des événements (MediatR) plutôt que des modifications directes. |
 
 ---
 
 ## Mapping vers la consolidation
 
-| Reponse | Alimente |
+| Réponse | Alimente |
 |---------|----------|
 | Q5.1-Q5.4 | `consolidation.crossModuleInteractions[]`, `consolidation.sharedEntities[]` |
 | Q5.5-Q5.8 | `consolidation.impactAssessment[]`, `consolidation.permissionCoherence` |