@atlashub/smartstack-cli 1.33.0 → 1.35.0

package/templates/skills/apex/templates/04b-doc-sync.md

@@ -0,0 +1,31 @@
+# Step 04b: Documentation Sync
+
+**Task:** {{task_description}}
+**Started:** {{timestamp}}
+
+---
+
+## Manifest Status
+- **Found:** Yes | No
+- **Modules in manifest:** {{count}}
+
+## Affected Modules
+
+| Module | Changed Files | Impacted Sections | Updated |
+|--------|---------------|-------------------|---------|
+
+## Documentation Updates
+
+### Module: {{module_path}}
+- **frd-data.ts:** Updated fields: {{fields}}
+- **i18n FR:** {{updated|no_change}}
+- **Manifest:** Status → synced
+
+## Summary
+
+- **Modules checked:** {{count}}
+- **Modules updated:** {{count}}
+- **Modules skipped:** {{count}} (no documentation)
+- **Sections updated:** {{count}}
+
+**Status:** Complete

package/templates/skills/apex/templates/context-digest.md

@@ -0,0 +1,35 @@
+# Context Digest Template
+
+> This template defines the format for context digests generated between APEX steps.
+> Each step produces a digest (max 50 lines) that replaces reading full output files.
+
+## Digest Format
+
+```markdown
+# Digest: step-{NN}
+
+## Changes ({count} files)
+- `path/file.ts` - {brief description of what changed}
+- `path/other.ts` - {brief description}
+
+## Decisions
+- {key architectural or implementation decision}
+
+## Findings
+- {issue or pattern identified}
+
+## State Updates
+- {variable}: {new_value}
+
+## For Next Step
+- {what the next step needs to know}
+- {specific files to read if needed}
+```
+
+## Rules
+
+- **Max 50 lines** total
+- **Paths only** for files (no content)
+- **1 line per item** (no multi-line descriptions)
+- **Skip empty sections** (if no decisions, omit Decisions)
+- **Resume mode exception**: When resuming (`-r`), read full output files instead of digest

package/templates/skills/business-analyse/SKILL.md

@@ -106,6 +106,15 @@ All outputs saved to PROJECT directory:
     ├── bugs/
     └── hotfixes/
 ```
+
+**Ralph Loop files (generated by step-05):**
+```
+.ralph/
+├── prd.json          # Task breakdown for /ralph-loop -r
+├── progress.txt      # Links to BA documents
+├── logs/
+└── reports/
+```
 </output_structure>
 
 <resume_workflow>
@@ -187,6 +196,9 @@ Load ONLY relevant categories based on feature type:
 | 08       | `questionnaire/08-performance.md`   | If performance-critical |
 | 09       | `questionnaire/09-constraints.md`   | If constraints exist |
 | 10       | `questionnaire/10-documentation.md` | If doc required |
+| 11       | `questionnaire/11-data-lifecycle.md` | If data-centric or full module |
+| 12       | `questionnaire/12-migration.md`      | Always for new modules         |
+| 13       | `questionnaire/13-cross-module.md`   | Always for new modules         |
 
 </questionnaire_files>
 
@@ -195,10 +207,10 @@ Load ONLY relevant categories based on feature type:
 
 | Template | File                          | Used in step |
 | -------- | ----------------------------- | ------------ |
-| discovery | `templates/frd-discovery.md` | 01           |
-| brd       | `templates/frd-brd.md`       | 02           |
-| frd       | `templates/frd-spec.md`      | 03           |
-| handoff   | `templates/frd-handoff.md`   | 05           |
+| discovery | `templates/tpl-discovery.md` | 01           |
+| brd       | `templates/tpl-brd.md`       | 02           |
+| frd       | `templates/tpl-frd.md`       | 03           |
+| handoff   | `templates/tpl-handoff.md`   | 05           |
 
 </template_files>
 
@@ -218,6 +230,7 @@ Load ONLY relevant categories based on feature type:
 - Each step loaded progressively (max 300-400 lines/step)
 - All outputs saved to feature folder
 - Validation gate passed (APPROVED)
-- Development handoff ready for `/implement`
+- Development handoff ready for `/ralph-loop -r` (iterative) or `/feature-full` (one-shot)
+- Ralph Loop prd.json generated with atomic task breakdown
 - Clear completion summary with next steps
 </success_criteria>

package/templates/skills/business-analyse/_shared.md

@@ -16,13 +16,13 @@ steps/step-00-init.md (parse flags, create state)
     ↓
 steps/step-01-discover.md (charge questionnaire/XX.md on-demand)
     ↓
-steps/step-02-analyse.md (charge templates/frd-brd.md)
+steps/step-02-analyse.md (charge templates/tpl-brd.md)
     ↓
-steps/step-03-specify.md (charge templates/frd-spec.md)
+steps/step-03-specify.md (charge templates/tpl-frd.md)
     ↓
 steps/step-04-validate.md (validation gate)
     ↓
-steps/step-05-handoff.md (charge templates/frd-handoff.md)
+steps/step-05-handoff.md (charge templates/tpl-handoff.md)
     ↓
 steps/step-06-doc-html.md (charge react/*.md on-demand)
 ```
@@ -46,6 +46,82 @@ validate_business_context(context):
 
 ---
 
+## Architecture SmartStack (Référence BA)
+
+> **Objectif :** Fournir le contexte architectural au BA pour des questions pertinentes et des recommandations alignées.
+
+### 5 Couches (Clean Architecture)
+
+| Couche | Projet | Contenu | Impact BA |
+|--------|--------|---------|-----------|
+| **Domain** | `SmartStack.Domain` | Entités, enums, interfaces | Entités identifiées en discovery |
+| **Application** | `SmartStack.Application` | CQRS (Commands/Queries), validations, DTOs | Use cases de la spécification |
+| **Infrastructure** | `SmartStack.Infrastructure` | EF Core, services externes, jobs | Intégrations et contraintes techniques |
+| **API** | `SmartStack.API` | Controllers REST, permissions | Endpoints et sécurité |
+| **Web** | `smartstack-web` | React 19, pages, composants | UI/UX et navigation |
+
+### Hiérarchie de Navigation
+
+```
+Context (business) → Application (Sales) → Module (Orders) → Section (list/detail)
+```
+
+Route pattern : `/business/{application}/{module}/{section}`
+
+### Classes de Base des Entités
+
+| Classe | Champs auto-inclus | Quand utiliser |
+|--------|--------------------|----------------|
+| `Entity` | `Id` (Guid) | Entité simple sans audit |
+| `AuditableEntity` | + `CreatedBy`, `CreatedDate`, `ModifiedBy`, `ModifiedDate` | **Défaut pour toute entité métier** |
+| `SoftDeletableEntity` | + `IsDeleted`, `DeletedBy`, `DeletedDate` | Entité avec suppression logique |
+| `HierarchicalEntity` | + `ParentId`, `Level`, `Path` | Arborescences (catégories, menus) |
+
+> **IMPORTANT :** Ne JAMAIS proposer `CreatedBy`, `ModifiedBy`, `IsDeleted` comme champs explicites — ils sont AUTOMATIQUES via la classe de base.
+
+### Services d'Intégration Disponibles
+
+| Service | Interface | Quand le proposer |
+|---------|-----------|-------------------|
+| Notifications in-app | `INotificationService` | Alertes, événements, rappels |
+| Workflow automatisé | `IWorkflowService` | Emails transactionnels, webhooks, actions chaînées |
+| Complétion IA | `IAICompletionService` | Suggestions, classification, génération contenu |
+| SignalR temps réel | `IHubContext<BusinessHub>` | Mises à jour en temps réel |
+| Jobs planifiés | Hangfire `IBackgroundJobClient` | Traitements différés, purges, imports |
+
+### Conventions Base de Données
+
+| Aspect | Convention |
+|--------|------------|
+| Schema | `core` (socle) vs `ext` (extensions/métier) |
+| Tables | PascalCase au pluriel (`Orders`, `OrderLines`) |
+| FK | `{Entity}Id` (ex: `ClientId`, `OrderId`) |
+| Index | `IX_{Table}_{Column}` |
+| Migration | 1 migration par feature, nommée via MCP |
+
+### Contraintes Non-Négociables
+
+| Contrainte | Détail |
+|------------|--------|
+| **Multi-tenant** | `TenantId` sur toute entité métier, isolation automatique |
+| **RBAC** | Permissions `business.{app}.{module}.{action}`, HasData pattern |
+| **CQRS** | Commands (write) et Queries (read) séparés via MediatR |
+| **Validation** | FluentValidation pour toute commande |
+| **i18n** | 4 langues obligatoires (fr, en, it, de) |
+| **Soft Delete** | Pas de DELETE physique sauf purge RGPD planifiée |
+
+### Outils MCP Pertinents pour le BA
+
+| Phase BA | Outil MCP | Usage |
+|----------|-----------|-------|
+| Pre-research (01) | `analyze_extension_points` | Découvrir modules/entités existants |
+| Pre-research (01) | `api_docs` | Consulter la documentation API existante |
+| Analyse (02) | `validate_conventions` | Vérifier les noms d'entités proposés |
+| Spécification (03) | `generate_permissions` | Générer la matrice de permissions |
+| Handoff (05) | `scaffold_extension` | Préparer le scaffolding |
+
+---
+
 ## Feature Directory Structure
 
 ```
@@ -65,10 +141,24 @@ validate_business_context(context):
                         ├── 4-development-handoff.md
                         └── tracking/
                             ├── changes/
+                            │   └── CHANGE-NNN.md
                             ├── bugs/
-                            └── hotfixes/
+                            ├── hotfixes/
+                            └── docs-manifest-entry.json
+```
+
+**Ralph Loop Integration (generated by step-05):**
+
+```
+.ralph/
+├── prd.json          # Task breakdown derived from handoff (for /ralph-loop -r)
+├── progress.txt      # Links back to BA feature documents
+├── logs/
+└── reports/
 ```
 
+> **Note:** `.ralph/prd.json` is generated by step-05-handoff from the file mapping, business rules, and test requirements. It provides an atomic task list following the SmartStack layer order (Domain -> Application -> Infrastructure -> API -> Frontend -> i18n -> Tests -> Validation).
+
 ---
 
 ## Feature ID Generation
@@ -97,6 +187,129 @@ generate_feature_id():
 
 ---
 
+## Interactive Elicitation Protocol
+
+> **RULE: ALL questions MUST be asked interactively using `AskUserQuestion`.**
+> **NEVER dump a list of questions as text. ALWAYS use the tool.**
+
+### Protocol
+
+1. **Group questions by theme** — max 4 questions per `AskUserQuestion` call (tool limit)
+2. **Propose predefined options** — for questions with predictable answers, provide 2-4 options
+3. **The user can always choose "Other"** — the tool adds this automatically for free-text answers
+4. **Process answers immediately** — apply ULTRATHINK + follow-ups before moving to next group
+5. **Adapt next questions** — based on previous answers, skip irrelevant questions
+
+### Batching Strategy
+
+| Category | Questions | Batches |
+|----------|-----------|---------|
+| 01-context | Q1.1-Q1.8 | 2 calls (Q1.1-Q1.4 then Q1.5-Q1.8) |
+| 02-stakeholders | Q2.1-Q2.8 | 2 calls (Q2.1-Q2.4 then Q2.5-Q2.8) |
+| 03-scope | Q3.1-Q3.8 | 2 calls (Q3.1-Q3.4 then Q3.5-Q3.8) |
+| 04-data | Q4.1-Q4.8 | 2 calls (Q4.1-Q4.4 then Q4.5-Q4.8) |
+| 05-integrations | Q5.1-Q5.8 | 2 calls (Q5.1-Q5.4 then Q5.5-Q5.8) |
+| 06-security | Q6.1-Q6.8 | 2 calls (Q6.1-Q6.4 then Q6.5-Q6.8) |
+| 07-10 | Q7-Q10 | 1-2 calls each |
+
+### AskUserQuestion Format
+
+```
+AskUserQuestion({
+  questions: [
+    {
+      question: "Quel problème métier ce module doit-il résoudre ?",
+      header: "Problème",       // max 12 chars
+      options: [
+        { label: "Processus manuel", description: "Automatiser un processus existant fait manuellement" },
+        { label: "Données dispersées", description: "Centraliser des données éparpillées dans plusieurs outils" },
+        { label: "Manque visibilité", description: "Obtenir des indicateurs et du suivi inexistants aujourd'hui" },
+        { label: "Conformité", description: "Répondre à une obligation réglementaire ou de sécurité" }
+      ],
+      multiSelect: false
+    },
+    // ... up to 4 questions per call
+  ]
+})
+```
+
+### After Each Batch
+
+1. **Evaluate answer quality** (see Answer Quality Indicators)
+2. **If insufficient** → follow-up AskUserQuestion with targeted probes from the Elicitation Guide
+3. **If solution-oriented** → reframe using Technique 1 before proceeding
+4. **If sufficient/excellent** → record and move to next batch
+5. **Summarize** what was understood before moving to the next category
+
+---
+
+## Elicitation Techniques
+
+> **Loaded by:** step-01-discover (Opus ULTRATHINK)
+> **Purpose:** Guide HOW to question, not just WHAT to ask.
+
+### Technique 1: Solution → Problem Reframing
+
+If the user describes a **solution** (button, field, screen, API), reframe as a **need**:
+
+| User says | BA agent asks |
+|-----------|---------------|
+| "I need a Role dropdown on the User form" | "What problem are you trying to solve with different user access levels?" |
+| "We need an export button" | "What do you do with the exported data? Who needs it and why?" |
+| "Add a status field" | "What lifecycle does this entity go through? What triggers each transition?" |
+
+### Technique 2: 5 Whys (Root Cause)
+
+When the need seems superficial, chain up to 5 "Why?":
+
+```
+User: "We need to track user activity"
+→ Why? "To know who modified what"
+→ Why? "Because we had data integrity issues"
+→ Why? "Because multiple people edit the same records"
+→ ROOT CAUSE: Concurrent editing conflict → Need audit trail + optimistic locking
+```
+
+### Technique 3: Concrete Scenario Extraction
+
+Never accept abstract descriptions. Always ask for **a real day-in-the-life scenario**:
+
+```
+"Walk me through a typical day: you arrive at the office,
+ you open the application — what is the FIRST thing you need to do?
+ Then what? What information do you look at? What decisions do you make?"
+```
+
+### Technique 4: Absence Test
+
+Validate necessity by asking what happens WITHOUT:
+
+```
+"If this feature did NOT exist, what would you do instead?
+ How much time/money does the current workaround cost?"
+```
+
+### Technique 5: Completeness Probing
+
+For every list answer, challenge completeness:
+
+| Answer type | Probe |
+|-------------|-------|
+| "There are 3 user types" | "Are there external actors? Auditors? System admins? Automated processes?" |
+| "The main flow is A→B→C" | "What if the user cancels at step B? What if step C fails? What if they go back to A?" |
+| "Required fields: name, email" | "What uniqueness constraints? What format? What happens on duplicate?" |
+
+### Answer Quality Indicators
+
+| Quality | Signal | Action |
+|---------|--------|--------|
+| **Insufficient** | < 1 sentence, "I don't know", vague adjective | Apply technique 1-5, ask for concrete example |
+| **Solution-oriented** | Contains UI/tech terms (button, field, API, database) | Apply technique 1 (reframe to problem) |
+| **Sufficient** | Contains WHO, WHAT, WHY, concrete example | Proceed, note confidence level |
+| **Excellent** | Includes edge cases, constraints, measurable criteria | Proceed, mark as "Confirmed" |
+
+---
+
 ## ULTRATHINK
 
 Behavioral mode for critical phases (01, 02, 03, 05):
@@ -107,11 +320,13 @@ ULTRATHINK MODE:
 - Challenge EVERY assumption
 - Anticipate UNEXPRESSED needs
 - Validate completeness before output
+- Apply Elicitation Techniques (see above)
 
 DO NOT:
 - Accept vague answers
 - Skip question categories
 - Assume stakeholder thought of everything
+- Accept solutions without understanding the problem first
 ```
 
 **DO NOT invoke** as a skill/tool - it is a thinking mode.
@@ -228,6 +443,47 @@ Example:
 
 ---
 
+## Configuration Langue de Communication
+
+> **Objectif :** La langue de communication avec le client est configurable.
+> Toute interaction via `AskUserQuestion` (questions, options, reformulations, relances)
+> doit être dans la langue configurée.
+
+### Configuration
+
+Le champ `language` dans `.business-analyse/config.json` définit la langue :
+
+| Langue | Code | Défaut |
+|--------|------|--------|
+| Français | `fr` | **Oui** |
+| English | `en` | Non |
+| Italiano | `it` | Non |
+| Deutsch | `de` | Non |
+
+### Portée
+
+| Élément | Adapté à la langue ? |
+|---------|---------------------|
+| Questions `AskUserQuestion` (labels, descriptions, options) | **OUI** — toujours dans `{language}` |
+| Reformulations et résumés de catégorie | **OUI** — toujours dans `{language}` |
+| Relances et follow-ups (Elicitation Guide) | **OUI** — traduire les probes à la volée |
+| Documents générés (discovery, BRD, FRD, handoff) | **OUI** — rédigés dans `{language}` |
+| Référence technique interne (patterns, architecture) | NON — reste en langue du fichier |
+| Noms de code (entités, permissions, paths) | NON — toujours en anglais (convention SmartStack) |
+
+### Règle
+
+```
+1. Lire {language} depuis 00-context.md (défaut: "fr")
+2. Adapter TOUTE communication AskUserQuestion dans {language}
+3. Les exemples de probes/relances dans les questionnaires sont en français
+   → Si {language} ≠ "fr", les traduire à la volée
+4. Les documents générés sont rédigés dans {language}
+5. Le code, les noms d'entités et les paths restent TOUJOURS en anglais
+```
+
+---
+
 ## Config Template
 
 ```json
@@ -235,6 +491,7 @@ Example:
   "project": "{Name}",
   "lastFeatureId": 0,
   "context": "business",
+  "language": "fr",
   "standards": ["BABOK-v3", "IEEE-830"],
   "contact": "support@atlshub.ch"
 }
@@ -253,6 +510,51 @@ Example:
 
 ---
 
+## Context Digest (Between Steps)
+
+Each step produces a compressed digest file (max 50 lines) at completion to reduce token usage in the next step.
+
+**File naming:** `{output_dir}/digest-{step_number}.md` (e.g., `digest-01.md`, `digest-02.md`)
+
+| Section | Max Lines | Content |
+|---------|-----------|---------|
+| Changes | 10 | Files modified with brief description |
+| Decisions | 10 | Key architectural decisions |
+| Findings | 10 | Issues found, patterns identified |
+| State | 5 | Updated state variables |
+| Next | 5 | What the next step needs to know |
+
+**Protocol:**
+- **Generate:** Each step writes `digest-{step_number}.md` before completing
+- **Read:** Next step reads `digest-{prev_step_number}.md` instead of full output files
+- **Resume mode (`-r`):** Reads full output files directly (digest is for progressive loading only)
+- **Step-00:** Does not read a digest (it is the first step)
+- **Step-00:** Generates `digest-00.md` with initial state variables and configuration
+
+**Template:**
+```markdown
+# Digest: Step {NN} - {Step Name}
+
+## Changes
+- {file}: {brief description}
+
+## Decisions
+- {decision and rationale}
+
+## Findings
+- {finding}
+
+## State Updates
+| Variable | New Value |
+|----------|-----------|
+| {var} | {value} |
+
+## For Next Step
+- {what the next step needs to know}
+```
+
+---
+
 ## Support
 
 Contact: **support@atlshub.ch**

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

@@ -25,9 +25,24 @@
 
 ---
 
-## Follow-up Questions
-
-For each vague answer:
-- "Can you give a concrete example?"
-- "How do you measure that today?"
-- "What happens if this rule is not respected?"
+## Elicitation Guide
+
+### Follow-ups by Question
+
+| Question | If answer is vague/insufficient | Probe |
+|----------|-------------------------------|-------|
+| Q1.1 (problem) | User describes a solution, not a problem | "Oublions la solution un instant — quel problème rencontrez-vous concrètement aujourd'hui ?" |
+| Q1.2 (AS-IS) | No concrete workflow described | "Décrivez-moi une journée type : vous arrivez, vous ouvrez l'outil — que faites-vous en premier ?" |
+| Q1.3 (TO-BE) | Vague ("ça ira mieux") | "Concrètement, quel geste ou tâche sera différent ? Combien de clics/minutes en moins ?" |
+| Q1.4 (KPIs) | No measurable metric | "Comment saurez-vous dans 3 mois que cette fonctionnalité a réussi ? Quel chiffre regarderez-vous ?" |
+| Q1.5 (ROI) | "I don't know" | "Combien de temps passez-vous sur ce processus aujourd'hui par semaine ? À combien de personnes ?" |
+| Q1.7 (if NOT built) | Minimized impact | "Si on ne fait rien pendant 6 mois, qu'est-ce qui empire ? Quel est le coût de l'inaction ?" |
+
+### Anti-patterns to Detect
+
+| Signal | Anti-pattern | Action |
+|--------|-------------|--------|
+| "Il faudrait un bouton/écran/champ..." | **Solution disguised as need** | Apply Solution → Problem Reframing |
+| "C'est évident", "tout le monde sait" | **Implicit assumption** | "Pouvez-vous le formuler explicitement pour que je puisse le documenter ?" |
+| KPIs are feelings ("ça sera mieux") | **Non-measurable success** | "Quel chiffre regarderez-vous pour savoir si c'est réussi ?" |
+| Q1.7 = "rien de grave" | **Faible justification business** | Challenge: si ce n'est pas grave, pourquoi le développer ? |

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

@@ -27,9 +27,43 @@
 
 ## Role -> Permission Mapping
 
+> **⚠️ RBAC RULE: Roles are SmartStack permissions, NOT entity attributes.**
+>
+> When stakeholders mention "roles" (admin, manager, user...), these MUST be mapped
+> to SmartStack's RBAC permission system (`business.{app}.{module}.{action}`).
+>
+> **NEVER** model a role as:
+> - A property/column on a User entity (e.g. `User.Role`, `User.RoleType`)
+> - An enum or string attribute on any business entity
+> - A separate `Role` entity with a FK on User
+>
+> **ALWAYS** map roles to permission sets in the matrix below:
+
 | Discovered Role | SmartStack Permission |
 |-----------------|----------------------|
 | Admin | `*.admin` |
 | Manager | `*.read,create,update` |
 | User | `*.read,create` |
 | ReadOnly | `*.read` |
+
+> If the business need requires **custom roles beyond these 4**, document them
+> as additional permission sets — not as data model concepts.
+
+## Elicitation Guide
+
+### Follow-ups by Question
+
+| Question | If answer is vague/insufficient | Probe |
+|----------|-------------------------------|-------|
+| Q2.1 (end users) | Only 1-2 roles listed | "Y a-t-il des auditeurs, des administrateurs système, du support, des processus automatisés ?" |
+| Q2.5 (tasks per role) | Generic tasks ("manage data") | "Prenons le rôle {role} : en arrivant le matin, quelle est sa première action ? Et après ?" |
+| Q2.6 (frequency) | "Régulièrement" | "Quotidien ? 10 fois/jour ou 1 fois ? Certains jours plus que d'autres ?" |
+| Q2.8 (frustrations) | "Rien de particulier" | "Quel processus prend le plus de temps ? Qu'est-ce qui vous fait soupirer ?" |
+
+### Anti-patterns to Detect
+
+| Signal | Anti-pattern | Action |
+|--------|-------------|--------|
+| Un seul type d'utilisateur identifié | **Stakeholders manquants** | Proposer systématiquement : admin, utilisateur métier, lecteur, auditeur, support N1 |
+| "Tous les utilisateurs font la même chose" | **Rôles non différenciés** | "Qui peut supprimer ? Qui ne fait que consulter ? Qui valide ?" |
+| Mélange rôle organisationnel et accès | **Confusion rôle/permission** | Séparer : rôle métier (chef de projet) vs niveau d'accès (lecture/écriture) |

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

@@ -33,3 +33,26 @@
 | Should | Brings significant value but can wait for v2 |
 | Could | Nice-to-have, can be implemented if time available |
 | Won't | Explicitly excluded from scope |
+
+## Elicitation Guide
+
+### Follow-ups by Question
+
+| Question | If answer is vague/insufficient | Probe |
+|----------|-------------------------------|-------|
+| Q3.1 (Must-Have) | > 10 items listed | "Si vous ne pouviez en garder que 3 pour la v1, lesquels ? Les autres sont peut-être Should-Have." |
+| Q3.1 (Must-Have) | Mélange CRUD + complexe | "Le CRUD de base (liste, création, modification, suppression) est-il un Must, ou certaines actions sont Could ?" |
+| Q3.2 (Should-Have) | Vide | "Y a-t-il des fonctionnalités utiles mais qui peuvent attendre une v2 ? Export, filtres avancés, notifications ?" |
+| Q3.4 (exclusions) | Vide | "Que ne voulez-vous surtout PAS dans ce module ? Intégrations, reporting, mobile, historique ?" |
+| Q3.5 (main flow) | < 3 étapes | "Détaillez : l'utilisateur arrive sur l'écran → que voit-il ? → que clique-t-il ? → que se passe-t-il ?" |
+| Q3.7 (alt flows) | "Il n'y en a pas" | "Que se passe-t-il si l'utilisateur annule ? S'il n'a pas la permission ? Si les données sont invalides ?" |
+| Q3.8 (errors) | Liste vide | "Que se passe-t-il si le réseau coupe ? Si un champ obligatoire manque ? Si un doublon existe ?" |
+
+### Anti-patterns to Detect
+
+| Signal | Anti-pattern | Action |
+|--------|-------------|--------|
+| Tout est Must-Have | **Scope non priorisé** | Appliquer le test : "Sans cette fonctionnalité, le module a-t-il ZÉRO valeur ?" |
+| Q3.4 vide (rien d'exclu) | **Scope illimité** | "Si tout est inclus, le risque est de ne jamais livrer. Qu'est-ce qui est hors périmètre v1 ?" |
+| Flow linéaire sans alternative | **Happy path uniquement** | "Que se passe-t-il au step X si la condition Y n'est pas remplie ?" |
+| Mélange fonctionnel/technique | **Solution dans le scope** | Séparer : "gérer les commandes" (fonctionnel) vs "utiliser Redis" (technique) |

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

@@ -34,3 +34,47 @@
 | Unique attribute | `HasIndex().IsUnique()` |
 | 1:N relationship | Navigation property |
 | Sensitive data | Encryption + audit |
+
+> **⚠️ RBAC EXCLUSION: The following concepts are handled by SmartStack'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 `business.{app}.{module}.*` |
+> | Access level | `User.AccessLevel` enum | Permission matrix per role |
+> | Is admin | `User.IsAdmin` boolean | `business.{app}.{module}.admin` permission |
+> | Can edit | `User.CanEdit` boolean | `business.{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 SmartStack (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.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** | SmartStack 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 ?" |
+
+### SmartStack Entity Patterns
+
+| Besoin métier | Base class SmartStack | 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 |