@atlashub/smartstack-cli 3.39.0 → 3.41.0

package/templates/skills/business-analyse/questionnaire/03-scope.md

@@ -1,164 +1,164 @@
-# Categorie 3 : Perimetre fonctionnel
-
-> **Usage :** Definir ce que le systeme doit faire et ne pas faire, avec des priorites claires
-> **Quand charger :** TOUJOURS (noyau)
-> **Objectif :** Delimiter le perimetre et hierarchiser les fonctionnalites
-
----
-
-## 3.1 Les fonctionnalites attendues
-
-> **But :** Lister tout ce que le systeme doit permettre de faire, puis hierarchiser.
-
-| # | Question | Type de reponse |
-|---|----------|-----------------|
-| Q3.1 | Listez toutes les fonctionnalites que vous souhaitez dans ce systeme. Ne vous censurez pas, notez tout ce qui vous vient a l'esprit. | Liste libre de fonctionnalites |
-| Q3.2 | Parmi cette liste, quelles sont les fonctionnalites INDISPENSABLES ? Celles sans lesquelles le systeme n'a aucun interet ? | Liste de fonctionnalites vitales |
-| Q3.3 | Quelles fonctionnalites seraient tres utiles mais pourraient attendre une deuxieme version si necessaire ? | Liste de fonctionnalites importantes |
-| Q3.4 | Y a-t-il des choses que le systeme ne doit explicitement PAS faire ? Des limites claires a poser ? | Liste d'exclusions |
-
-**Reformulation guidee pour Q3.2 :**
-```
-question: "Quelles fonctionnalites sont absolument indispensables ?"
-header: "Indispensable"
-options:
-  - label: "Creer et consulter les fiches"
-    description: "La base : pouvoir ajouter de nouvelles informations et les retrouver"
-  - label: "Suivre l'avancement"
-    description: "Voir ou en est chaque element, son statut et son historique"
-  - label: "Controler les acces"
-    description: "S'assurer que chaque personne ne voit et fait que ce qu'elle a le droit"
-  - label: "Generer des rapports"
-    description: "Produire des syntheses et des indicateurs pour la prise de decision"
-```
-
-**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 ?"
-> - Si la reponse est "non" : c'est bien indispensable
-> - Si la reponse est "oui, mais..." : c'est important mais pas vital
-
----
-
-## 3.2 Le parcours principal
-
-> **But :** Comprendre le flux de travail principal de bout en bout.
-
-| # | Question | Type de reponse |
-|---|----------|-----------------|
-| Q3.5 | Decrivez le parcours typique d'un utilisateur du debut a la fin : il ouvre le systeme, que fait-il en premier ? Puis ensuite ? Comment termine-t-il sa tache ? | Liste d'etapes ordonnees |
-| Q3.6 | A quels moments l'utilisateur doit-il prendre une decision ? Quelles sont les options possibles a chaque point de decision ? | Points de decision et options |
-| Q3.7 | Que se passe-t-il quand quelque chose ne se deroule pas comme prevu ? Quels sont les cas particuliers ou les exceptions ? | Scenarios alternatifs |
-| Q3.8 | Que se passe-t-il quand une erreur survient ? Comment l'utilisateur est-il informe ? Que doit-il faire pour corriger ? | Gestion des erreurs |
-
-**Reformulation guidee pour Q3.5 :**
-```
-question: "Decrivez le parcours typique d'un utilisateur du debut a la fin"
-header: "Parcours"
-options:
-  - label: "Saisie puis validation"
-    description: "L'utilisateur cree une fiche, un responsable la valide, elle est publiee"
-  - label: "Recherche puis action"
-    description: "L'utilisateur cherche une information, puis effectue une action dessus"
-  - label: "Reception puis traitement"
-    description: "Une demande arrive, l'utilisateur la traite etape par etape"
-  - label: "Suivi continu"
-    description: "L'utilisateur surveille un tableau de bord et intervient quand necessaire"
-```
-
----
-
-## 3.3 Les besoins transversaux
-
-> **But :** Identifier les fonctionnalites qui traversent tout le systeme.
-
-| # | Question | Type de reponse |
-|---|----------|-----------------|
-| Q3.9 | Les utilisateurs ont-ils besoin de recevoir des notifications ou des alertes ? Si oui, dans quelles situations ? | Liste de situations de notification |
-| Q3.10 | Faut-il pouvoir exporter des donnees du systeme (rapports, fichiers, impressions) ? Dans quel format et pour qui ? | Besoins d'export |
-| Q3.11 | Faut-il pouvoir importer des donnees dans le systeme depuis une source externe (fichiers, autres logiciels) ? | Besoins d'import |
-| Q3.12 | Faut-il garder un historique de qui a fait quoi et quand ? Pour quelles actions ? | Besoins de tracabilite |
-
-**Reformulation guidee pour Q3.9 :**
-```
-question: "Les utilisateurs ont-ils besoin de recevoir des notifications ou des alertes ?"
-header: "Alertes"
-options:
-  - label: "Oui, en temps reel"
-    description: "Notifications instantanees quand quelque chose de nouveau arrive ou change"
-  - label: "Oui, par email"
-    description: "Recapitulatif par email quotidien ou a chaque evenement important"
-  - label: "Oui, les deux"
-    description: "Notification en temps reel dans l'application et recapitulatif par email"
-  - label: "Non, pas necessaire"
-    description: "Les utilisateurs consulteront le systeme de leur propre initiative"
-```
-
----
-
-## Guide d'elicitation approfondi
-
-### Techniques de relance par question
-
-| Question | Si la reponse est vague ou insuffisante | Relance recommandee |
-|----------|----------------------------------------|---------------------|
-| Q3.1 (liste de fonctionnalites) | Moins de 5 elements | "Pensez a une journee complete de travail. De l'ouverture de session a la fermeture, quelles actions devriez-vous pouvoir faire ? Creation ? Recherche ? Modification ? Exportation ? Suivi ?" |
-| Q3.2 (indispensable) | Tout est marque comme indispensable | "Si vous ne pouviez garder que 3 fonctionnalites pour un premier lancement, lesquelles choisiriez-vous ? Les autres sont tres importantes mais pourraient venir dans un second temps." |
-| Q3.4 (exclusions) | "Je ne vois pas" | "Certains utilisateurs pourraient-ils s'attendre a des fonctionnalites que vous ne souhaitez PAS inclure ? Par exemple : gestion financiere, messagerie integree, application mobile ?" |
-| Q3.5 (parcours principal) | Moins de 3 etapes | "Detaillons : l'utilisateur arrive sur l'ecran d'accueil. Que voit-il ? Ou clique-t-il ? Que remplit-il ? Que se passe-t-il quand il valide ? Qui est notifie ?" |
-| Q3.6 (decisions) | "Il n'y a pas vraiment de choix" | "A chaque etape, l'utilisateur peut-il annuler ? Revenir en arriere ? Sauvegarder en brouillon ? Deleguer a quelqu'un d'autre ?" |
-| Q3.7 (cas particuliers) | "Il n'y en a pas" | "Que se passe-t-il si l'utilisateur n'a pas toutes les informations ? Si une donnee est incorrecte ? Si deux personnes modifient la meme fiche en meme temps ?" |
-| Q3.8 (erreurs) | "On verra" | "Prenons un exemple : l'utilisateur oublie un champ obligatoire. Le systeme le bloque ? L'avertit ? Le laisse continuer avec un rappel plus tard ?" |
-| Q3.9 (notifications) | Reponse vague | "Quand un element change de statut, qui doit etre prevenu ? Quand une action urgente est requise, comment l'utilisateur le sait-il aujourd'hui ?" |
-| Q3.12 (tracabilite) | "On ne sait pas" | "Si dans 6 mois quelqu'un demande 'Qui a modifie cette fiche et pourquoi ?', devez-vous pouvoir repondre ?" |
-
-### Signaux d'alerte a detecter
-
-| Signal du client | Probleme sous-jacent | Action de l'analyste |
-|------------------|---------------------|----------------------|
-| Tout est indispensable (> 10 elements vitaux) | **Priorites non definies** | Appliquer le test : "Si on enlevait cette fonctionnalite, le systeme aurait-il encore de la valeur ?" |
-| Aucune exclusion identifiee | **Perimetre non borne** | "Y a-t-il des aspects qui relevent d'un autre projet, d'un autre service, 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 ? Si l'utilisateur change d'avis ?" |
-| Melange fonctionnel et technique | **Solution dans le perimetre** | Separer : "gerer les commandes" (ce que fait le systeme) est fonctionnel, "utiliser tel outil" (comment il le fait) est technique |
-| Fonctionnalites tres detaillees pour certains sujets et vagues pour d'autres | **Expertise inegale** | Approfondir les zones vagues : "Ce sujet semble moins detaille. Est-ce parce qu'il est moins important ou parce qu'il est moins bien connu ?" |
-
-### Regles d'enchainement
-
-| Apres | Si la reponse indique... | Alors |
-|-------|-------------------------|-------|
-| Q3.1 | Plus de 15 fonctionnalites | Passer plus de temps sur Q3.2 pour hierarchiser |
-| Q3.2 | Plus de 10 elements indispensables | Challenger chaque element avec le test de priorite |
-| Q3.5 | Parcours avec approbation | Charger les questions de workflow (categorie 11 cycle de vie) |
-| Q3.7 | Beaucoup de cas particuliers | Prevoir de la complexite dans l'estimation des modules |
-| Q3.9 | Notifications en temps reel souhaitees | Noter pour la specification : integration de notifications |
-| Q3.11 | Import de donnees existantes | Charger le questionnaire de migration (categorie 12) |
-| Q3.12 | Tracabilite requise | Noter pour la specification : journal d'activite |
-
----
-
-## Mapping vers le cadrage
-
-| Reponse | Alimente |
-|---------|----------|
-| Q3.1, Q3.2, Q3.3 | `cadrage.globalScope` (indispensable, important, optionnel, hors perimetre) |
-| Q3.4 | `cadrage.globalScope.outOfScope` |
-| Q3.5, Q3.6, Q3.7, Q3.8 | `cadrage.coverageMatrix` + base pour les cas d'utilisation |
-| Q3.9, Q3.10, Q3.11, Q3.12 | `cadrage.coverageMatrix` + detection de modules transversaux |
-
----
-
-## Strategie de questionnement
-
-### Ordre des questions en 3 lots
-
-**Lot 1 (Q3.1, Q3.2, Q3.3, Q3.4) : Quoi et dans quel ordre ?**
-- Commencer par un brainstorming libre (Q3.1) puis hierarchiser
-- Bien definir les limites (Q3.4) pour eviter les derives
-
-**Lot 2 (Q3.5, Q3.6, Q3.7, Q3.8) : Comment ca se deroule ?**
-- Cartographier le parcours principal puis les variantes
-- Ne pas accepter un parcours uniquement ideal
-
-**Lot 3 (Q3.9, Q3.10, Q3.11, Q3.12) : Quels besoins transversaux ?**
-- Identifier les fonctionnalites qui traversent tout le systeme
-- Ces reponses orientent le choix des questionnaires conditionnels
+# Categorie 3 : Perimetre fonctionnel
+
+> **Usage :** Definir ce que le systeme doit faire et ne pas faire, avec des priorites claires
+> **Quand charger :** TOUJOURS (noyau)
+> **Objectif :** Delimiter le perimetre et hierarchiser les fonctionnalites
+
+---
+
+## 3.1 Les fonctionnalites attendues
+
+> **But :** Lister tout ce que le systeme doit permettre de faire, puis hierarchiser.
+
+| # | Question | Type de reponse |
+|---|----------|-----------------|
+| Q3.1 | Listez toutes les fonctionnalites que vous souhaitez dans ce systeme. Ne vous censurez pas, notez tout ce qui vous vient a l'esprit. | Liste libre de fonctionnalites |
+| Q3.2 | Parmi cette liste, quelles sont les fonctionnalites INDISPENSABLES ? Celles sans lesquelles le systeme n'a aucun interet ? | Liste de fonctionnalites vitales |
+| Q3.3 | Quelles fonctionnalites seraient tres utiles mais pourraient attendre une deuxieme version si necessaire ? | Liste de fonctionnalites importantes |
+| Q3.4 | Y a-t-il des choses que le systeme ne doit explicitement PAS faire ? Des limites claires a poser ? | Liste d'exclusions |
+
+**Reformulation guidee pour Q3.2 :**
+```
+question: "Quelles fonctionnalites sont absolument indispensables ?"
+header: "Indispensable"
+options:
+  - label: "Creer et consulter les fiches"
+    description: "La base : pouvoir ajouter de nouvelles informations et les retrouver"
+  - label: "Suivre l'avancement"
+    description: "Voir ou en est chaque element, son statut et son historique"
+  - label: "Controler les acces"
+    description: "S'assurer que chaque personne ne voit et fait que ce qu'elle a le droit"
+  - label: "Generer des rapports"
+    description: "Produire des syntheses et des indicateurs pour la prise de decision"
+```
+
+**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 ?"
+> - Si la reponse est "non" : c'est bien indispensable
+> - Si la reponse est "oui, mais..." : c'est important mais pas vital
+
+---
+
+## 3.2 Le parcours principal
+
+> **But :** Comprendre le flux de travail principal de bout en bout.
+
+| # | Question | Type de reponse |
+|---|----------|-----------------|
+| Q3.5 | Decrivez le parcours typique d'un utilisateur du debut a la fin : il ouvre le systeme, que fait-il en premier ? Puis ensuite ? Comment termine-t-il sa tache ? | Liste d'etapes ordonnees |
+| Q3.6 | A quels moments l'utilisateur doit-il prendre une decision ? Quelles sont les options possibles a chaque point de decision ? | Points de decision et options |
+| Q3.7 | Que se passe-t-il quand quelque chose ne se deroule pas comme prevu ? Quels sont les cas particuliers ou les exceptions ? | Scenarios alternatifs |
+| Q3.8 | Que se passe-t-il quand une erreur survient ? Comment l'utilisateur est-il informe ? Que doit-il faire pour corriger ? | Gestion des erreurs |
+
+**Reformulation guidee pour Q3.5 :**
+```
+question: "Decrivez le parcours typique d'un utilisateur du debut a la fin"
+header: "Parcours"
+options:
+  - label: "Saisie puis validation"
+    description: "L'utilisateur cree une fiche, un responsable la valide, elle est publiee"
+  - label: "Recherche puis action"
+    description: "L'utilisateur cherche une information, puis effectue une action dessus"
+  - label: "Reception puis traitement"
+    description: "Une demande arrive, l'utilisateur la traite etape par etape"
+  - label: "Suivi continu"
+    description: "L'utilisateur surveille un tableau de bord et intervient quand necessaire"
+```
+
+---
+
+## 3.3 Les besoins transversaux
+
+> **But :** Identifier les fonctionnalites qui traversent tout le systeme.
+
+| # | Question | Type de reponse |
+|---|----------|-----------------|
+| Q3.9 | Les utilisateurs ont-ils besoin de recevoir des notifications ou des alertes ? Si oui, dans quelles situations ? | Liste de situations de notification |
+| Q3.10 | Faut-il pouvoir exporter des donnees du systeme (rapports, fichiers, impressions) ? Dans quel format et pour qui ? | Besoins d'export |
+| Q3.11 | Faut-il pouvoir importer des donnees dans le systeme depuis une source externe (fichiers, autres logiciels) ? | Besoins d'import |
+| Q3.12 | Faut-il garder un historique de qui a fait quoi et quand ? Pour quelles actions ? | Besoins de tracabilite |
+
+**Reformulation guidee pour Q3.9 :**
+```
+question: "Les utilisateurs ont-ils besoin de recevoir des notifications ou des alertes ?"
+header: "Alertes"
+options:
+  - label: "Oui, en temps reel"
+    description: "Notifications instantanees quand quelque chose de nouveau arrive ou change"
+  - label: "Oui, par email"
+    description: "Recapitulatif par email quotidien ou a chaque evenement important"
+  - label: "Oui, les deux"
+    description: "Notification en temps reel dans l'application et recapitulatif par email"
+  - label: "Non, pas necessaire"
+    description: "Les utilisateurs consulteront le systeme de leur propre initiative"
+```
+
+---
+
+## Guide d'elicitation approfondi
+
+### Techniques de relance par question
+
+| Question | Si la reponse est vague ou insuffisante | Relance recommandee |
+|----------|----------------------------------------|---------------------|
+| Q3.1 (liste de fonctionnalites) | Moins de 5 elements | "Pensez a une journee complete de travail. De l'ouverture de session a la fermeture, quelles actions devriez-vous pouvoir faire ? Creation ? Recherche ? Modification ? Exportation ? Suivi ?" |
+| Q3.2 (indispensable) | Tout est marque comme indispensable | "Si vous ne pouviez garder que 3 fonctionnalites pour un premier lancement, lesquelles choisiriez-vous ? Les autres sont tres importantes mais pourraient venir dans un second temps." |
+| Q3.4 (exclusions) | "Je ne vois pas" | "Certains utilisateurs pourraient-ils s'attendre a des fonctionnalites que vous ne souhaitez PAS inclure ? Par exemple : gestion financiere, messagerie integree, application mobile ?" |
+| Q3.5 (parcours principal) | Moins de 3 etapes | "Detaillons : l'utilisateur arrive sur l'ecran d'accueil. Que voit-il ? Ou clique-t-il ? Que remplit-il ? Que se passe-t-il quand il valide ? Qui est notifie ?" |
+| Q3.6 (decisions) | "Il n'y a pas vraiment de choix" | "A chaque etape, l'utilisateur peut-il annuler ? Revenir en arriere ? Sauvegarder en brouillon ? Deleguer a quelqu'un d'autre ?" |
+| Q3.7 (cas particuliers) | "Il n'y en a pas" | "Que se passe-t-il si l'utilisateur n'a pas toutes les informations ? Si une donnee est incorrecte ? Si deux personnes modifient la meme fiche en meme temps ?" |
+| Q3.8 (erreurs) | "On verra" | "Prenons un exemple : l'utilisateur oublie un champ obligatoire. Le systeme le bloque ? L'avertit ? Le laisse continuer avec un rappel plus tard ?" |
+| Q3.9 (notifications) | Reponse vague | "Quand un element change de statut, qui doit etre prevenu ? Quand une action urgente est requise, comment l'utilisateur le sait-il aujourd'hui ?" |
+| Q3.12 (tracabilite) | "On ne sait pas" | "Si dans 6 mois quelqu'un demande 'Qui a modifie cette fiche et pourquoi ?', devez-vous pouvoir repondre ?" |
+
+### Signaux d'alerte a detecter
+
+| Signal du client | Probleme sous-jacent | Action de l'analyste |
+|------------------|---------------------|----------------------|
+| Tout est indispensable (> 10 elements vitaux) | **Priorites non definies** | Appliquer le test : "Si on enlevait cette fonctionnalite, le systeme aurait-il encore de la valeur ?" |
+| Aucune exclusion identifiee | **Perimetre non borne** | "Y a-t-il des aspects qui relevent d'un autre projet, d'un autre service, 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 ? Si l'utilisateur change d'avis ?" |
+| Melange fonctionnel et technique | **Solution dans le perimetre** | Separer : "gerer les commandes" (ce que fait le systeme) est fonctionnel, "utiliser tel outil" (comment il le fait) est technique |
+| Fonctionnalites tres detaillees pour certains sujets et vagues pour d'autres | **Expertise inegale** | Approfondir les zones vagues : "Ce sujet semble moins detaille. Est-ce parce qu'il est moins important ou parce qu'il est moins bien connu ?" |
+
+### Regles d'enchainement
+
+| Apres | Si la reponse indique... | Alors |
+|-------|-------------------------|-------|
+| Q3.1 | Plus de 15 fonctionnalites | Passer plus de temps sur Q3.2 pour hierarchiser |
+| Q3.2 | Plus de 10 elements indispensables | Challenger chaque element avec le test de priorite |
+| Q3.5 | Parcours avec approbation | Charger les questions de workflow (categorie 11 cycle de vie) |
+| Q3.7 | Beaucoup de cas particuliers | Prevoir de la complexite dans l'estimation des modules |
+| Q3.9 | Notifications en temps reel souhaitees | Noter pour la specification : integration de notifications |
+| Q3.11 | Import de donnees existantes | Charger le questionnaire de migration (categorie 12) |
+| Q3.12 | Tracabilite requise | Noter pour la specification : journal d'activite |
+
+---
+
+## Mapping vers le cadrage
+
+| Reponse | Alimente |
+|---------|----------|
+| Q3.1, Q3.2, Q3.3 | `cadrage.globalScope` (indispensable, important, optionnel, hors perimetre) |
+| Q3.4 | `cadrage.globalScope.outOfScope` |
+| Q3.5, Q3.6, Q3.7, Q3.8 | `cadrage.coverageMatrix` + base pour les cas d'utilisation |
+| Q3.9, Q3.10, Q3.11, Q3.12 | `cadrage.coverageMatrix` + detection de modules transversaux |
+
+---
+
+## Strategie de questionnement
+
+### Ordre des questions en 3 lots
+
+**Lot 1 (Q3.1, Q3.2, Q3.3, Q3.4) : Quoi et dans quel ordre ?**
+- Commencer par un brainstorming libre (Q3.1) puis hierarchiser
+- Bien definir les limites (Q3.4) pour eviter les derives
+
+**Lot 2 (Q3.5, Q3.6, Q3.7, Q3.8) : Comment ca se deroule ?**
+- Cartographier le parcours principal puis les variantes
+- Ne pas accepter un parcours uniquement ideal
+
+**Lot 3 (Q3.9, Q3.10, Q3.11, Q3.12) : Quels besoins transversaux ?**
+- Identifier les fonctionnalites qui traversent tout le systeme
+- Ces reponses orientent le choix des questionnaires conditionnels

package/templates/skills/business-analyse/questionnaire/04-data.md

@@ -1,88 +1,88 @@
-# Category 4: Data
-
-> **Usage:** Definition of entities and data rules
-> **When to load:** If feature is data-centric or full module
-
----
-
-## 4.1 Entities
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q4.1 | What are the main entities handled? | List |
-| Q4.2 | For each entity: important attributes? | Per entity |
-| Q4.3 | What relationships exist between entities? | Text schema |
-| Q4.4 | Expected data volume? | Estimation |
-| Q4.4b | For each entity: should the Code be auto-generated or user-provided? | Per entity |
-| Q4.4c | If auto-generated: what strategy? (sequential, daily timestamp, yearly, UUID short) | Per entity |
-| Q4.4d | What prefix represents this entity? (2-6 lowercase letters, e.g., emp, inv) | Per entity |
-
-## 4.2 Data Rules
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q4.5 | What validations on data? | List of rules |
-| Q4.6 | Which fields are required vs optional? | Per field |
-| Q4.7 | What specific formats/constraints? | List |
-| Q4.8 | Sensitive data to protect? | List + level |
-
----
-
-## Technical Mapping
-
-| Business Concept | Platform |
-|-----------------|------------|
-| Main entity | Domain Entity |
-| Required attribute | `[Required]` |
-| Unique attribute | `HasIndex().IsUnique()` |
-| 1:N relationship | Navigation property |
-| Sensitive data | Encryption + audit |
-| Code auto-generation | `ICodeGenerator<T>.NextCodeAsync()` with retry — see `apex/references/code-generation.md` |
-| Code pattern config | `analysis.entities[].codePattern` in feature.json |
-
-> **⚠️ RBAC EXCLUSION: The following concepts are handled by the platform's RBAC system
-> and MUST NOT be modeled as entity attributes or separate entities:**
->
-> | Concept | ❌ Wrong (entity attribute) | ✅ Correct (RBAC) |
-> |---------|---------------------------|-------------------|
-> | User role | `User.Role` property | Permission set `{app}.{module}.*` |
-> | Access level | `User.AccessLevel` enum | Permission matrix per role |
-> | Is admin | `User.IsAdmin` boolean | `{app}.{module}.admin` permission |
-> | Can edit | `User.CanEdit` boolean | `{app}.{module}.update` permission |
->
-> When Q4.2 asks for "important attributes", **exclude** any role/permission/access concept.
-
-## Elicitation Guide
-
-### Follow-ups by Question
-
-| Question | If answer is vague/insufficient | Probe |
-|----------|-------------------------------|-------|
-| Q4.1 (entities) | Single entity listed | "Cette entité a-t-elle des sous-éléments ? (lignes de commande, pièces jointes, historique)" |
-| Q4.1 (entities) | Mentions "User" as entity | "L'utilisateur est géré par la plateforme (Identity). Décrivez plutôt l'entité MÉTIER (Client, Employee, Contact...)" |
-| Q4.2 (attributes) | Liste de champs techniques (ID, CreatedDate) | "Les champs techniques (Id, TenantId, audit) sont auto-gérés. Quels sont les attributs MÉTIER ?" |
-| Q4.3 (relationships) | "1:N" without detail | "Un {Parent} peut avoir combien de {Children} max ? Un {Child} peut-il exister sans {Parent} ?" |
-| Q4.4 (volume) | "Beaucoup" | "Ordre de grandeur : dizaines, centaines, milliers, millions ? Croissance par mois ?" |
-| Q4.4b (code pattern) | "User enters the code" or no answer | "Le code doit-il suivre un format spécifique ? (numéro séquentiel, date, combinaison ?)" |
-| Q4.4c (code strategy) | No answer | Propose strategy based on entity type: invoices/orders → timestamp-daily, employees/customers → sequential, references/categories → uuid-short, contracts → year-sequential, tickets → timestamp-minute |
-| Q4.4d (code prefix) | Too long or ambiguous | "Le préfixe est limité à 2-6 lettres minuscules. Exemple : 'emp' pour Employee, 'inv' pour Invoice, 'ctr' pour Contract." |
-| Q4.5 (validations) | Validations basiques seulement | "Y a-t-il des règles inter-champs ? (date fin > date début, montant selon statut)" |
-| Q4.8 (sensitive) | "Non" | "Pas de données personnelles (nom, email, téléphone) ? Pas de données financières ?" |
-
-### Anti-patterns to Detect
-
-| Signal | Anti-pattern | Action |
-|--------|-------------|--------|
-| Entity "User" avec attributs métier | **Confusion User/Identity** | La plateforme gère les Users via Identity. L'entité métier = Client, Employee, Contact |
-| Attributs Id, TenantId, CreatedBy listés | **Champs techniques comme métier** | Ces champs sont auto-générés par `AuditableEntity`. Ne pas les lister. |
-| Pas de soft delete mentionné | **Suppression non clarifiée** | "Les données supprimées sont-elles effacées définitivement ou archivées ?" → `SoftDeletableEntity` |
-| Aucune contrainte d'unicité | **Unicité non vérifiée** | "Deux entités peuvent-elles avoir le même nom/code/email ?" |
-
-### Entity Patterns
-
-| Besoin métier | Base class plateforme | Inclut automatiquement |
-|---------------|----------------------|----------------------|
-| Entité simple | `Entity` | Id, TenantId |
-| Avec audit | `AuditableEntity` | + CreatedBy, CreatedDate, ModifiedBy, ModifiedDate |
-| Avec suppression logique | `SoftDeletableEntity` | + IsDeleted, DeletedBy, DeletedDate |
-| Avec hiérarchie | `HierarchicalEntity` | + ParentId, Level, Path |
+# Category 4: Data
+
+> **Usage:** Definition of entities and data rules
+> **When to load:** If feature is data-centric or full module
+
+---
+
+## 4.1 Entities
+
+| # | Question | Answer Type |
+|---|----------|-------------|
+| Q4.1 | What are the main entities handled? | List |
+| Q4.2 | For each entity: important attributes? | Per entity |
+| Q4.3 | What relationships exist between entities? | Text schema |
+| Q4.4 | Expected data volume? | Estimation |
+| Q4.4b | For each entity: should the Code be auto-generated or user-provided? | Per entity |
+| Q4.4c | If auto-generated: what strategy? (sequential, daily timestamp, yearly, UUID short) | Per entity |
+| Q4.4d | What prefix represents this entity? (2-6 lowercase letters, e.g., emp, inv) | Per entity |
+
+## 4.2 Data Rules
+
+| # | Question | Answer Type |
+|---|----------|-------------|
+| Q4.5 | What validations on data? | List of rules |
+| Q4.6 | Which fields are required vs optional? | Per field |
+| Q4.7 | What specific formats/constraints? | List |
+| Q4.8 | Sensitive data to protect? | List + level |
+
+---
+
+## Technical Mapping
+
+| Business Concept | Platform |
+|-----------------|------------|
+| Main entity | Domain Entity |
+| Required attribute | `[Required]` |
+| Unique attribute | `HasIndex().IsUnique()` |
+| 1:N relationship | Navigation property |
+| Sensitive data | Encryption + audit |
+| Code auto-generation | `ICodeGenerator<T>.NextCodeAsync()` with retry — see `apex/references/code-generation.md` |
+| Code pattern config | `analysis.entities[].codePattern` in feature.json |
+
+> **⚠️ RBAC EXCLUSION: The following concepts are handled by the platform's RBAC system
+> and MUST NOT be modeled as entity attributes or separate entities:**
+>
+> | Concept | ❌ Wrong (entity attribute) | ✅ Correct (RBAC) |
+> |---------|---------------------------|-------------------|
+> | User role | `User.Role` property | Permission set `{app}.{module}.*` |
+> | Access level | `User.AccessLevel` enum | Permission matrix per role |
+> | Is admin | `User.IsAdmin` boolean | `{app}.{module}.admin` permission |
+> | Can edit | `User.CanEdit` boolean | `{app}.{module}.update` permission |
+>
+> When Q4.2 asks for "important attributes", **exclude** any role/permission/access concept.
+
+## Elicitation Guide
+
+### Follow-ups by Question
+
+| Question | If answer is vague/insufficient | Probe |
+|----------|-------------------------------|-------|
+| Q4.1 (entities) | Single entity listed | "Cette entité a-t-elle des sous-éléments ? (lignes de commande, pièces jointes, historique)" |
+| Q4.1 (entities) | Mentions "User" as entity | "L'utilisateur est géré par la plateforme (Identity). Décrivez plutôt l'entité MÉTIER (Client, Employee, Contact...)" |
+| Q4.2 (attributes) | Liste de champs techniques (ID, CreatedDate) | "Les champs techniques (Id, TenantId, audit) sont auto-gérés. Quels sont les attributs MÉTIER ?" |
+| Q4.3 (relationships) | "1:N" without detail | "Un {Parent} peut avoir combien de {Children} max ? Un {Child} peut-il exister sans {Parent} ?" |
+| Q4.4 (volume) | "Beaucoup" | "Ordre de grandeur : dizaines, centaines, milliers, millions ? Croissance par mois ?" |
+| Q4.4b (code pattern) | "User enters the code" or no answer | "Le code doit-il suivre un format spécifique ? (numéro séquentiel, date, combinaison ?)" |
+| Q4.4c (code strategy) | No answer | Propose strategy based on entity type: invoices/orders → timestamp-daily, employees/customers → sequential, references/categories → uuid-short, contracts → year-sequential, tickets → timestamp-minute |
+| Q4.4d (code prefix) | Too long or ambiguous | "Le préfixe est limité à 2-6 lettres minuscules. Exemple : 'emp' pour Employee, 'inv' pour Invoice, 'ctr' pour Contract." |
+| Q4.5 (validations) | Validations basiques seulement | "Y a-t-il des règles inter-champs ? (date fin > date début, montant selon statut)" |
+| Q4.8 (sensitive) | "Non" | "Pas de données personnelles (nom, email, téléphone) ? Pas de données financières ?" |
+
+### Anti-patterns to Detect
+
+| Signal | Anti-pattern | Action |
+|--------|-------------|--------|
+| Entity "User" avec attributs métier | **Confusion User/Identity** | La plateforme gère les Users via Identity. L'entité métier = Client, Employee, Contact |
+| Attributs Id, TenantId, CreatedBy listés | **Champs techniques comme métier** | Ces champs sont auto-générés par `AuditableEntity`. Ne pas les lister. |
+| Pas de soft delete mentionné | **Suppression non clarifiée** | "Les données supprimées sont-elles effacées définitivement ou archivées ?" → `SoftDeletableEntity` |
+| Aucune contrainte d'unicité | **Unicité non vérifiée** | "Deux entités peuvent-elles avoir le même nom/code/email ?" |
+
+### Entity Patterns
+
+| Besoin métier | Base class plateforme | Inclut automatiquement |
+|---------------|----------------------|----------------------|
+| Entité simple | `Entity` | Id, TenantId |
+| Avec audit | `AuditableEntity` | + CreatedBy, CreatedDate, ModifiedBy, ModifiedDate |
+| Avec suppression logique | `SoftDeletableEntity` | + IsDeleted, DeletedBy, DeletedDate |
+| Avec hiérarchie | `HierarchicalEntity` | + ParentId, Level, Path |

package/templates/skills/business-analyse/questionnaire/05-integrations.md

@@ -1,58 +1,58 @@
-# Category 5: Integrations
-
-> **Usage:** Connections with internal and external systems
-> **When to load:** If feature involves integrations
-
----
-
-## 5.1 Existing Systems
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q5.1 | What internal systems should we integrate with? | List |
-| Q5.2 | What external systems? | List |
-| Q5.3 | Existing APIs to use? | Documentation |
-| Q5.4 | Data to import from another system? | List + format |
-
-## 5.2 Data Flows
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q5.5 | Flow direction? (inbound/outbound/bidirectional) | Per system |
-| Q5.6 | Synchronization frequency? | Real-time/Batch |
-| Q5.7 | Data conflict management? | Strategy |
-| Q5.8 | Fallback if external system unavailable? | Behavior |
-
----
-
-## Integration Patterns
-
-| Integration Type | Pattern | When to use |
-|-----------------|---------|-------------|
-| REST API | HttpClient + Polly | Appel synchrone à un service externe avec retry/circuit-breaker |
-| Message Queue | MassTransit | Communication asynchrone entre modules/services |
-| Webhook | Controller endpoint | Réception d'événements depuis un système externe |
-| Real-time | SignalR | Notifications temps réel vers le navigateur |
-| Batch import | Background job (Hangfire) | Import/traitement de gros volumes en arrière-plan |
-| File storage | Azure Blob / local | Upload/download de documents et pièces jointes |
-
-## Elicitation Guide
-
-### Follow-ups by Question
-
-| Question | If answer is vague/insufficient | Probe |
-|----------|-------------------------------|-------|
-| Q5.1 (internal) | "Aucun" | "Ce module doit-il notifier d'autres modules ? Lire des données d'un autre contexte ?" |
-| Q5.2 (external) | "Aucun" | "Pas d'envoi d'emails ? Pas de connexion ERP, CRM, comptabilité ? Pas de SSO externe ?" |
-| Q5.3 (APIs) | "Oui il y a une API" | "Avez-vous la documentation (Swagger/OpenAPI) ? Quel format (REST/SOAP/GraphQL) ? Auth (API key, OAuth) ?" |
-| Q5.6 (frequency) | "Temps réel" | "Temps réel = chaque seconde (SignalR) ou à chaque modification (event-driven) ? Quelle latence acceptable ?" |
-| Q5.7 (conflicts) | "Pas de conflits" | "Si le système externe envoie une donnée qui existe déjà, on écrase, on ignore ou on signale ?" |
-| Q5.8 (fallback) | "Ça ne devrait pas arriver" | "Si le service est down 1h, que fait l'utilisateur ? File d'attente, mode dégradé, retry ?" |
-
-### Anti-patterns to Detect
-
-| Signal | Anti-pattern | Action |
-|--------|-------------|--------|
-| Intégration synchrone pour tout | **Couplage fort** | Si l'autre système peut être lent/down, proposer pattern asynchrone (MassTransit) |
-| "On verra plus tard pour l'intégration" | **Intégration non planifiée** | Documenter minimum : système cible, direction du flux, format attendu |
-| Pas de stratégie d'erreur | **Pas de résilience** | Toute intégration externe DOIT avoir un fallback (Polly retry + circuit breaker) |
+# Category 5: Integrations
+
+> **Usage:** Connections with internal and external systems
+> **When to load:** If feature involves integrations
+
+---
+
+## 5.1 Existing Systems
+
+| # | Question | Answer Type |
+|---|----------|-------------|
+| Q5.1 | What internal systems should we integrate with? | List |
+| Q5.2 | What external systems? | List |
+| Q5.3 | Existing APIs to use? | Documentation |
+| Q5.4 | Data to import from another system? | List + format |
+
+## 5.2 Data Flows
+
+| # | Question | Answer Type |
+|---|----------|-------------|
+| Q5.5 | Flow direction? (inbound/outbound/bidirectional) | Per system |
+| Q5.6 | Synchronization frequency? | Real-time/Batch |
+| Q5.7 | Data conflict management? | Strategy |
+| Q5.8 | Fallback if external system unavailable? | Behavior |
+
+---
+
+## Integration Patterns
+
+| Integration Type | Pattern | When to use |
+|-----------------|---------|-------------|
+| REST API | HttpClient + Polly | Appel synchrone à un service externe avec retry/circuit-breaker |
+| Message Queue | MassTransit | Communication asynchrone entre modules/services |
+| Webhook | Controller endpoint | Réception d'événements depuis un système externe |
+| Real-time | SignalR | Notifications temps réel vers le navigateur |
+| Batch import | Background job (Hangfire) | Import/traitement de gros volumes en arrière-plan |
+| File storage | Azure Blob / local | Upload/download de documents et pièces jointes |
+
+## Elicitation Guide
+
+### Follow-ups by Question
+
+| Question | If answer is vague/insufficient | Probe |
+|----------|-------------------------------|-------|
+| Q5.1 (internal) | "Aucun" | "Ce module doit-il notifier d'autres modules ? Lire des données d'un autre contexte ?" |
+| Q5.2 (external) | "Aucun" | "Pas d'envoi d'emails ? Pas de connexion ERP, CRM, comptabilité ? Pas de SSO externe ?" |
+| Q5.3 (APIs) | "Oui il y a une API" | "Avez-vous la documentation (Swagger/OpenAPI) ? Quel format (REST/SOAP/GraphQL) ? Auth (API key, OAuth) ?" |
+| Q5.6 (frequency) | "Temps réel" | "Temps réel = chaque seconde (SignalR) ou à chaque modification (event-driven) ? Quelle latence acceptable ?" |
+| Q5.7 (conflicts) | "Pas de conflits" | "Si le système externe envoie une donnée qui existe déjà, on écrase, on ignore ou on signale ?" |
+| Q5.8 (fallback) | "Ça ne devrait pas arriver" | "Si le service est down 1h, que fait l'utilisateur ? File d'attente, mode dégradé, retry ?" |
+
+### Anti-patterns to Detect
+
+| Signal | Anti-pattern | Action |
+|--------|-------------|--------|
+| Intégration synchrone pour tout | **Couplage fort** | Si l'autre système peut être lent/down, proposer pattern asynchrone (MassTransit) |
+| "On verra plus tard pour l'intégration" | **Intégration non planifiée** | Documenter minimum : système cible, direction du flux, format attendu |
+| Pas de stratégie d'erreur | **Pas de résilience** | Toute intégration externe DOIT avoir un fallback (Polly retry + circuit breaker) |