@atlashub/smartstack-cli 2.2.0 → 2.4.0

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

@@ -1,6 +1,6 @@
 ---
 name: business-analyse
-description: Business Analysis - VibeCoding-focused workflow with JSON output, proactive suggestions, and 4 use cases (new, question, refactoring, micro).
+description: Business Analysis v4.0 - Iterative multi-module workflow with 5-level navigation hierarchy, client checkpoints, and integrated documentation.
 argument-hint: "[-a] [-e] [-q <FEAT-ID> \"question\"] [-r <FEAT-ID> \"change\"] [-m] <feature description>"
 ---
 
@@ -45,6 +45,7 @@ See `<parameters>` for complete flag list.
 | `-q` | `--question` | Question mode: query an existing feature (requires FEAT-ID + question) |
 | `-r` | `--refactor` | Refactoring mode: delta changes on existing feature (requires FEAT-ID + change description) |
 | `-m` | `--micro` | Micro-feature mode: minimal questions, direct handoff |
+| `-app` | `--application` | Application mode: multi-module analysis with module decomposition |
 | `-i` | `--interactive` | Interactive mode: configure flags via AskUserQuestion |
 
 **Disable flags (turn OFF):**
@@ -56,26 +57,26 @@ See `<parameters>` for complete flag list.
 
 <examples>
 ```bash
-# A. New feature analysis (full workflow)
+# A. New feature analysis (single module - goes through full workflow)
 /business-analyse Order management module
 
-# B. Question about existing feature
+# B. Application analysis (multi-module)
+/business-analyse -app Complete sales management system
+
+# C. Question about existing feature
 /business-analyse -q FEAT-001 "What permissions does the manager have?"
 
-# C. Refactoring (create v1.1)
+# D. Refactoring (create v1.1)
 /business-analyse -r FEAT-001 "Add export PDF functionality"
 
-# D. Micro-feature (minimal questions)
+# E. Micro-feature (minimal questions)
 /business-analyse -m Add a status field to orders
 
-# Autonomous mode
-/business-analyse -a New payment gateway
+# Autonomous application mode
+/business-analyse -app -a New HR management system
 
 # Economy mode (no subagents)
 /business-analyse -e Order management
-
-# Combined flags
-/business-analyse -a -e Order management
 ```
 </examples>
 
@@ -95,22 +96,23 @@ See `<parameters>` for complete flag list.
 **All outputs saved to PROJECT directory:**
 
 ```
-docs/business/{app}/{module}/business-analyse/
-├── v1.0/
-│   └── feature.json    # Single JSON enriched progressively (new)
-├── v1.1/
-│   └── feature.json    # Delta version (refactoring)
-└── v2.0/
-    └── feature.json    # Major version
+docs/business/{app}/business-analyse/v{X.Y}/
+    feature.json              # APPLICATION-level master (modules, dependencies, roles)
+docs/business/{app}/{module}/business-analyse/v{X.Y}/
+    feature.json              # MODULE-level detail (entities, UC, FR, permissions, mockups)
 ```
 
-**Ralph Loop files (generated by step-04):**
+**Ralph Loop files (generated by step-05):**
 ```
 .ralph/
 ├── prd.json            # Task breakdown for /ralph-loop -r
 └── progress.txt        # Links to BA documents
 ```
 
+**Documentation integrated in SmartStack app:**
+- Application view: `/docs/business/{app}` (module overview, dependency graph, roles)
+- Module view: `/docs/business/{app}/{module}` (full specification, mockups)
+
 **No intermediate markdown files - all state in feature.json**
 </output_structure>
 
@@ -139,19 +141,35 @@ When provided, step-00 will:
 1. Parse flags and feature description
 2. If `-q`: Load ba-reader, answer question → EXIT
 3. If `-r`: Load existing feature.json, create new version
-4. If `-m`: Create minimal feature.json, skip discovery/analysis → handoff
-5. If default: Full workflow (steps 01-04)
-
-**Full workflow (new features):**
-- **Step 00:** Parse flags, route use case, create feature.json (draft)
-- **Step 01:** Merged discovery + BRD, proactive suggestions (analysed)
-- **Step 02:** FRD + use cases + permissions + navigation (specified)
-- **Step 03:** Validation gate (APPROVED/REJECTED)
-- **Step 04:** Development prompt + Ralph Loop prd.json (handed-off)
-
-**Micro workflow (micro features):**
+4. If `-m`: Create minimal feature.json → simplified handoff
+5. If `-app` or auto-detected multi-module: Full application workflow
+6. Default: Single module workflow (same phases, decomposition is trivial)
+
+**Application workflow (multi-module):**
+- **Step 00:** Parse flags, create master feature.json (draft)
+- **Step 01:** Cadrage: context, stakeholders, scope, application roles (framed)
+- **Step 02:** Decomposition: modules, dependencies, client checkpoint (decomposed)
+- **Step 03:** Iterative specification per module (specified)
+  - For each module in dependency order:
+    - Walk through sections & resources with client
+    - Propose ASCII/SVG mockups per section
+    - Define entities + business rules
+    - Generate specification (UC, FR, permissions, SeedData)
+    - Per-module validation + client confirmation
+- **Step 04:** Cross-module consolidation (consolidated)
+- **Step 05:** Handoff with per-module prd.json (handed-off)
+
+**Single module workflow (same phases, simplified):**
+- **Step 00:** Parse flags, create master feature.json (draft)
+- **Step 01:** Cadrage: context, stakeholders, scope, roles (framed)
+- **Step 02:** Decomposition: trivial (1 module), quick checkpoint (decomposed)
+- **Step 03:** Specification: single iteration (specified)
+- **Step 04:** Consolidation: auto-pass (consolidated)
+- **Step 05:** Handoff (handed-off)
+
+**Micro workflow:**
 - **Step 00:** Create minimal feature.json
-- **Step 04:** Direct handoff (skip 01-03)
+- **Step 05:** Direct handoff (skip 01-04)
 </workflow>
 
 <state_variables>
@@ -168,6 +186,7 @@ When provided, step-00 will:
 | `{context}`             | string  | Always "business" for BA                               |
 | `{auto_mode}`           | boolean | Skip confirmations                                     |
 | `{economy_mode}`        | boolean | No subagents, direct tool usage only                   |
+| `{workflow_mode}`       | string  | "application" or "module"                              |
 | `{docs_dir}`            | string  | `docs/business/{app}/{module}/business-analyse/v{X.Y}/` |
 
 </state_variables>
@@ -181,13 +200,14 @@ When provided, step-00 will:
 <step_files>
 **Progressive loading - only load current step:**
 
-| Step | File                         | Model  | Purpose                                              |
-| ---- | ---------------------------- | ------ | ---------------------------------------------------- |
-| 00   | `steps/step-00-init.md`      | Haiku  | Parse flags, route use case, create feature.json     |
-| 01   | `steps/step-01-analyse.md`   | Opus   | Merged discovery+BRD, proactive suggestions          |
-| 02   | `steps/step-02-specify.md`   | Sonnet | FRD + use cases + permissions + navigation           |
-| 03   | `steps/step-03-validate.md`  | Haiku  | Validation gate (APPROVED/REJECTED)                  |
-| 04   | `steps/step-04-handoff.md`   | Opus   | Development prompt + Ralph Loop prd.json             |
+| Step | File                              | Model  | Purpose                                              |
+| ---- | --------------------------------- | ------ | ---------------------------------------------------- |
+| 00   | `steps/step-00-init.md`           | Haiku  | Parse flags, route use case, create master feature.json |
+| 01   | `steps/step-01-cadrage.md`        | Opus   | Framing: context, stakeholders, scope, application roles |
+| 02   | `steps/step-02-decomposition.md`  | Sonnet | Module decomposition, dependency graph, client checkpoint |
+| 03   | `steps/step-03-specify.md`        | Opus   | Iterative per-module specification + validation |
+| 04   | `steps/step-04-consolidation.md`  | Sonnet | Cross-module validation, E2E flows, permissions coherence |
+| 05   | `steps/step-05-handoff.md`        | Opus   | Development prompt + Ralph Loop prd.json |
 
 </step_files>
 
@@ -198,6 +218,7 @@ Load ONLY relevant categories based on feature type:
 
 | Category | File                                | Questions | When to load |
 | -------- | ----------------------------------- | --------- | ------------ |
+| 00       | `questionnaire/00-application.md` | 8         | If application mode |
 | 01       | `questionnaire/01-context.md`       | 4         | Always       |
 | 02       | `questionnaire/02-stakeholders.md`  | 6         | Always       |
 | 03       | `questionnaire/03-scope.md`         | 6         | Always       |
@@ -239,10 +260,12 @@ Load ONLY relevant categories based on feature type:
 
 <success_criteria>
 
-- feature.json enriched progressively through all steps
-- Validation gate passed (APPROVED)
+- Master feature.json created and enriched progressively through all steps
+- Module decomposition validated by client (step-02 checkpoint)
+- Each module specified iteratively with client validation
+- ASCII/SVG mockups proposed for each module's sections
+- Cross-module consolidation passed (step-04)
 - Development handoff ready for `/ralph-loop -r` or `/feature-full`
-- Ralph Loop prd.json generated
-- Proactive suggestions presented to user
-- All outputs in `docs/business/{app}/{module}/business-analyse/v{X.Y}/`
+- Ralph Loop prd.json generated (per module or consolidated)
+- All outputs renderable by SmartStack app viewer at `/docs/business/{app}/`
 </success_criteria>

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

@@ -1,7 +1,7 @@
-# Business Analysis - Shared Functions (v3 - JSON-First Progressive Loading)
+# Business Analysis - Shared Functions (v4 - Iterative Multi-Module Workflow)
 
 > **Ref:** This file contains common functions for all BA phases.
-> **Version:** 3.0 - JSON-First architecture with progressive loading
+> **Version:** 4.0 - Iterative multi-module workflow with 5-level navigation hierarchy
 
 ---
 
@@ -12,15 +12,17 @@ The BusinessAnalyse skill uses **progressive loading** to minimize context:
 ```
 SKILL.md (entry point) → routes to use case
     ↓
-steps/step-00-init.md (parse flags, create feature.json via ba-writer)
+steps/step-00-init.md (parse flags, create master feature.json via ba-writer)
     ↓
-steps/step-01-analyse.md (merged discovery+BRD, loads questionnaire/*.md)
+steps/step-01-cadrage.md (framing: context, stakeholders, scope, roles)
     ↓
-steps/step-02-specify.md (FRD + use cases + permissions)
+steps/step-02-decomposition.md (module identification, dependency graph, CLIENT CHECKPOINT)
     ↓
-steps/step-03-validate.md (validation gate)
+steps/step-03-specify.md (ITERATIVE per module: sections, entities, BR, permissions, mockups)
+    ↓                      ↻ loops back for each module in dependency order
+steps/step-04-consolidation.md (cross-module validation, E2E flows, permissions coherence)
     ↓
-steps/step-04-handoff.md (generates ralph prd.json)
+steps/step-05-handoff.md (generates ralph prd.json per module)
 ```
 
 **No digest files needed** — each step reads/writes `feature.json` directly via `ba-writer` and `ba-reader` agents.
@@ -31,27 +33,143 @@ steps/step-04-handoff.md (generates ralph prd.json)
 
 ## JSON-First Architecture
 
-All BA outputs are stored in a single `feature.json` file, enriched progressively:
+All BA outputs are stored in **two levels** of feature.json, enriched progressively:
+
+### Application-Level (Master)
+**Path:** `docs/business/{app}/business-analyse/v{X.Y}/feature.json`
+**Schema:** `schemas/application-schema.json`
 
 | Step | Section enriched | Status after |
 |------|-----------------|--------------|
 | 00-init | metadata | draft |
-| 01-analyse | discovery + analysis + suggestions | analysed |
-| 02-specify | specification | specified |
-| 03-validate | validation | approved |
-| 04-handoff | handoff | handed-off |
+| 01-cadrage | cadrage (problem, stakeholders, scope, roles) | framed |
+| 02-decomposition | modules, dependencyGraph | decomposed |
+| 03-specify | modules[].status updated per iteration | specified |
+| 04-consolidation | consolidation | consolidated |
+| 05-handoff | (per-module handoff) | handed-off |
+
+### Module-Level (Per Module)
+**Path:** `docs/business/{app}/{module}/business-analyse/v{X.Y}/feature.json`
+**Schema:** `schemas/feature-schema.json`
+
+| Step | Section enriched | Status after |
+|------|-----------------|--------------|
+| 03-specify (init) | metadata, applicationContext | in-progress |
+| 03-specify (sections) | specification.wireframes | in-progress |
+| 03-specify (entities) | analysis.entities, analysis.businessRules | in-progress |
+| 03-specify (spec) | specification (full) | specified |
+| 03-specify (validate) | validation | validated |
 
 **Agents:**
-- **ba-writer**: Writes/updates feature.json (create, enrichSection, updateStatus, createVersion)
-- **ba-reader**: Reads feature.json (findFeature, readSection, answerQuestion, getSummaryForSkill)
+- **ba-writer**: Writes/updates feature.json (create, enrichSection, updateStatus, createVersion, createApplicationFeature, advanceModuleLoop)
+- **ba-reader**: Reads feature.json (findFeature, readSection, answerQuestion, getSummaryForSkill, readApplicationContext, getCompletedModulesSummary)
 
-**Schema:** `schemas/feature-schema.json`
+**Schemas:** `schemas/application-schema.json` (master) + `schemas/feature-schema.json` (module)
+
+---
+
+## 5-Level Navigation Hierarchy (SmartStack)
+
+> **This is the structuring principle of the entire BA workflow.**
+
+The BA aligns with the SmartStack navigation hierarchy:
+
+```
+Level 1: Context (business)
+  └── Level 2: Application (Sales)
+       ├── Level 3: Module (Customers)
+       │    ├── Level 4: Section (list)
+       │    │    └── Level 5: Ressource (customer-card)
+       │    ├── Level 4: Section (detail)
+       │    │    └── Level 5: Ressource (customer-form)
+       │    └── Level 4: Section (create)
+       └── Level 3: Module (Orders)
+            ├── Level 4: Section (list)
+            ├── Level 4: Section (detail)
+            ├── Level 4: Section (create)
+            └── Level 4: Section (approve)
+```
+
+| BA Phase | Levels treated | What is defined |
+|----------|---------------|-----------------|
+| Cadrage (step-01) | Context + Application | Problem, stakeholders, scope, application-level roles |
+| Decomposition (step-02) | Modules | Module list, dependencies, processing order |
+| Specification (step-03) | Module → Sections → Resources | Entities, BR, UC, permissions, ASCII/SVG mockups per section |
+| Consolidation (step-04) | Cross-module | Interactions, permission coherence, E2E flows |
+| Handoff (step-05) | All levels | Implementation mapping, prd.json |
+
+### Route pattern
+```
+/business/{application}/{module}/{section}
+```
+
+### Standard Sections per Module
+| Section | Purpose | Typical Components |
+|---------|---------|-------------------|
+| `list` | Main entity list with filters | DataGrid, FilterBar, Pagination |
+| `detail` | Entity detail view | DetailCard, TabPanel, StatusBadge |
+| `create` | Create new entity | Form, Validation, SubmitButton |
+| `edit` | Edit existing entity | Form (pre-filled), Validation |
+| `approve` | Approval workflow | ApprovalPanel, StatusTimeline |
+| `dashboard` | Module overview/KPIs | Charts, StatCards, RecentActivity |
+| `import` | Bulk data import | FileUpload, MappingTable, Preview |
+| `export` | Data export | FormatSelector, FilterOptions |
+
+---
 
-**Cross-references in JSON:**
-- `specification.useCases[].linkedRules` → `analysis.businessRules[].id`
-- `specification.functionalRequirements[].linkedUseCases` → `specification.useCases[].id`
-- `specification.functionalRequirements[].linkedRules` → `analysis.businessRules[].id`
-- `handoff.brToCodeMapping[].ruleId` → `analysis.businessRules[].id`
+## Module Loop Protocol
+
+> **Step-03 iterates over modules.** State is persisted in the master feature.json.
+
+### State Management
+
+```json
+{
+  "metadata": {
+    "workflow": {
+      "mode": "application",
+      "moduleOrder": ["Customers", "Products", "Orders", "Invoices"],
+      "currentModuleIndex": 2,
+      "completedModules": ["Customers", "Products"],
+      "currentModule": "Orders"
+    }
+  }
+}
+```
+
+### Loop Logic (end of each step-03 iteration)
+
+```
+1. Mark current module as "validated" in master feature.json
+2. Add to completedModules[]
+3. IF currentModuleIndex + 1 < moduleOrder.length:
+     currentModuleIndex++
+     currentModule = moduleOrder[currentModuleIndex]
+     Write master feature.json
+     Display: "Module {name} complete. Next: {next_name} ({N}/{total})"
+     RE-LOAD: steps/step-03-specify.md
+4. ELSE:
+     master.status = "specified"
+     Load: steps/step-04-consolidation.md
+```
+
+### Context Management During Loop
+
+To prevent context explosion as modules accumulate:
+- **Current module:** Load full module feature.json
+- **Completed modules:** Only load compact summary via `ba-reader.getCompletedModulesSummary()` (max 100 lines)
+- **Master feature.json:** Only read workflow state + application roles
+
+### Resume After Interruption
+
+```
+1. ba-reader.findApplicationFeature() → locate master feature.json
+2. Read metadata.workflow.currentModuleIndex
+3. IF currentModule has a feature.json with status != "validated":
+     Resume step-03-specify for that module
+4. ELSE:
+     Start step-03-specify for next module
+```
 
 ---
 
@@ -59,24 +177,11 @@ All BA outputs are stored in a single `feature.json` file, enriched progressivel
 
 | Flag | Use Case | Workflow |
 |------|----------|---------|
-| (none) | New feature | step-00 → step-01 → step-02 → step-03 → step-04 |
+| (none) | Single module | step-00 → step-01 → step-02 (trivial) → step-03 (1 iteration) → step-04 (auto) → step-05 |
+| `-app` | Application (multi-module) | step-00 → step-01 → step-02 → step-03 (N iterations) → step-04 → step-05 |
 | `-q FEAT-ID "question"` | Question | ba-reader.answerQuestion → EXIT |
-| `-r FEAT-ID "change"` | Refactoring | ba-writer.createVersion → step-01 (delta) → step-02 → step-03 → step-04 |
-| `-m` | Micro-feature | step-00 (minimal) → step-01 (micro) → step-02 (minimal) → step-03 (auto) → step-04 (simplified) |
-
-### Delta Mode (Refactoring)
-- ba-reader loads existing feature.json
-- ba-writer creates new version folder (v{X.Y+1})
-- step-01 only asks questions about the CHANGE, not the entire module
-- step-02 only adds/modifies affected UCs, FRs, permissions
-- Existing data preserved, only delta applied
-
-### Micro Mode
-- Questions: entity, fields, values, who can change (4-6 questions max)
-- step-01: simplified analysis (no ULTRATHINK, no proactive suggestions)
-- step-02: minimal specification (1-2 UCs, standard CRUD)
-- step-03: auto-validation (structural check only)
-- step-04: simplified handoff
+| `-r FEAT-ID "change"` | Refactoring | ba-writer.createVersion → step-01 (delta) → step-02 → step-03 → step-04 → step-05 |
+| `-m` | Micro-feature | step-00 (minimal) → step-05 (simplified) |
 
 ---
 
@@ -218,18 +323,20 @@ Route pattern : `/business/{application}/{module}/{section}`
 docs/
 ├── business/
 │   └── {application}/
-│       └── {module}/
-│           ├── business-analyse/
-│           │   ├── v1.0/
-│           │   │   └── feature.json
-│           │   └── v1.1/
-│           │       └── feature.json
-│           └── user-guide/          ← post-development (separate skill)
+│       ├── business-analyse/
+│       │   └── v1.0/
+│       │       └── feature.json          ← APPLICATION master
+│       ├── {module1}/
+│       │   └── business-analyse/
+│       │       └── v1.0/
+│       │           └── feature.json      ← MODULE detail
+│       └── {module2}/
+│           └── business-analyse/
 │               └── v1.0/
-│                   └── guide.json
+│                   └── feature.json      ← MODULE detail
 ```
 
-**Ralph Loop Integration (generated by step-04):**
+**Ralph Loop Integration (generated by step-05):**
 
 ```
 .ralph/
@@ -239,7 +346,9 @@ docs/
 └── reports/
 ```
 
-> **Note:** `.ralph/prd.json` is generated by step-04-handoff from the feature.json 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).
+**Integrated Documentation (SmartStack app):**
+- Application view: `/docs/business/{app}` → reads master feature.json
+- Module view: `/docs/business/{app}/{module}` → reads module feature.json
 
 ---
 
@@ -260,10 +369,11 @@ generate_feature_id():
 | Step | Model | Reason |
 |------|-------|--------|
 | 00-init | Haiku | Quick structure setup |
-| 01-analyse | **Opus** | ULTRATHINK merged discovery+BRD |
-| 02-specify | Sonnet | FRD + Use Cases |
-| 03-validate | Haiku | Binary gate |
-| 04-handoff | **Opus** | Zero-ambiguity prompt |
+| 01-cadrage | **Opus** | ULTRATHINK framing |
+| 02-decomposition | Sonnet | Module identification + dependency analysis |
+| 03-specify | **Opus** | ULTRATHINK per-module specification |
+| 04-consolidation | Sonnet | Cross-module validation |
+| 05-handoff | **Opus** | Zero-ambiguity prompt |
 
 ---
 

package/templates/skills/business-analyse/questionnaire/00-application.md

@@ -0,0 +1,166 @@
+# Category 00: Application Context
+
+> **Loaded by:** step-01-cadrage.md (application mode only)
+> **When:** Always loaded when workflow.mode = "application"
+> **Purpose:** Define application-level scope, roles, and module landscape before decomposition
+
+---
+
+## Questions
+
+### 0.1 Application Identity
+
+| # | Question | Type | Options |
+|---|----------|------|---------|
+| Q0.1 | What is the name of this application? | Free text | PascalCase name (e.g., Sales, Operations, HumanResources) |
+| Q0.2 | Briefly describe the application's purpose (1-2 sentences) | Free text | Business goal, target audience |
+
+**AskUserQuestion batch 1:**
+```
+Q0.1: "Quel est le nom de cette application ?"
+  header: "Application"
+  options:
+    - label: "Ventes / Sales"
+      description: "Gestion des ventes, commandes, clients"
+    - label: "Opérations / Operations"
+      description: "Gestion des opérations, logistique, stocks"
+    - label: "RH / HR"
+      description: "Gestion des ressources humaines"
+    - label: "Finance"
+      description: "Gestion financière, facturation, comptabilité"
+
+Q0.2: "Quel est l'objectif principal de cette application en 1-2 phrases ?"
+  header: "Objectif"
+  options:
+    - label: "Automatiser un processus"
+      description: "Remplacer un processus manuel par un système numérique"
+    - label: "Centraliser les données"
+      description: "Regrouper des informations dispersées dans plusieurs outils"
+    - label: "Améliorer la visibilité"
+      description: "Obtenir des tableaux de bord et du suivi en temps réel"
+    - label: "Conformité"
+      description: "Répondre à des obligations réglementaires ou de sécurité"
+```
+
+### 0.2 Module Landscape
+
+| # | Question | Type | Options |
+|---|----------|------|---------|
+| Q0.3 | How many distinct functional areas (modules) do you envision? | Number + list | Module names and brief descriptions |
+| Q0.4 | Which modules are essential for the first release (must-have)? | Multi-select | From Q0.3 list |
+
+**AskUserQuestion batch 2:**
+```
+Q0.3: "Combien de domaines fonctionnels distincts (modules) envisagez-vous ?"
+  header: "Modules"
+  options:
+    - label: "2-3 modules"
+      description: "Application ciblée avec peu de domaines fonctionnels"
+    - label: "4-6 modules"
+      description: "Application standard couvrant plusieurs domaines"
+    - label: "7-10 modules"
+      description: "Application complète avec de nombreux domaines"
+    - label: "10+ modules"
+      description: "Application d'entreprise très complète"
+
+Q0.4: "Quels modules sont indispensables pour la première release ?"
+  header: "Priorité"
+  multiSelect: true
+  options: [Dynamic - populated from Q0.3 answers]
+```
+
+### 0.3 Application Roles
+
+| # | Question | Type | Options |
+|---|----------|------|---------|
+| Q0.5 | Do the standard 4-tier roles work for this application? (Admin/Manager/Contributor/Viewer) | Yes/Customize | Default SmartStack roles |
+| Q0.6 | Are there roles specific to certain modules only? | List | Per-module role restrictions |
+
+**AskUserQuestion batch 3:**
+```
+Q0.5: "Les 4 rôles standards conviennent-ils pour cette application ?"
+  header: "Rôles"
+  options:
+    - label: "Oui, 4 rôles standards"
+      description: "Admin (tout), Manager (gestion), Contributeur (saisie), Lecteur (consultation)"
+    - label: "Personnaliser les noms"
+      description: "Garder les 4 niveaux mais renommer les rôles (ex: Directeur, Responsable...)"
+    - label: "Ajouter des rôles"
+      description: "Plus de 4 rôles nécessaires (ex: Approbateur, Auditeur...)"
+    - label: "Moins de rôles"
+      description: "Seulement 2-3 rôles suffisent pour cette application"
+
+Q0.6: "Y a-t-il des rôles limités à certains modules seulement ?"
+  header: "Restrictions"
+  options:
+    - label: "Non, tous les rôles sont globaux"
+      description: "Chaque rôle a accès à tous les modules (avec ses permissions)"
+    - label: "Oui, certains rôles sont restreints"
+      description: "Certains rôles ne voient que certains modules"
+```
+
+### 0.4 Cross-Module Expectations
+
+| # | Question | Type | Options |
+|---|----------|------|---------|
+| Q0.7 | Are there business processes that span multiple modules? | Yes/No + description | E2E flows |
+| Q0.8 | What is the default role for new users? | Selection | From role list |
+
+**AskUserQuestion batch 4:**
+```
+Q0.7: "Y a-t-il des processus métier qui traversent plusieurs modules ?"
+  header: "Flux E2E"
+  options:
+    - label: "Oui, plusieurs flux"
+      description: "Des processus impliquent 2+ modules (ex: commande → facturation → livraison)"
+    - label: "Oui, un flux principal"
+      description: "Un processus principal traverse les modules"
+    - label: "Non, modules indépendants"
+      description: "Chaque module fonctionne de manière autonome"
+    - label: "Pas encore défini"
+      description: "Les interactions seront identifiées pendant l'analyse"
+
+Q0.8: "Quel rôle par défaut pour les nouveaux utilisateurs ?"
+  header: "Rôle défaut"
+  options:
+    - label: "Lecteur (Viewer)"
+      description: "Accès en lecture seule par défaut, droits ajoutés manuellement"
+    - label: "Contributeur"
+      description: "Peut créer et modifier, mais pas supprimer ni approuver"
+    - label: "Aucun accès"
+      description: "Pas d'accès tant qu'un admin n'assigne pas de rôle"
+```
+
+---
+
+## Elicitation Guide
+
+### Follow-up probes (if answers are vague)
+
+| Signal | Probe |
+|--------|-------|
+| "We need everything" | "Si vous ne pouviez garder que 3 modules pour le lancement, lesquels ?" |
+| Vague module names | "Pouvez-vous décrire ce que fait concrètement le module {name} en 1 phrase ?" |
+| "Standard roles are fine" | "Qui utilise l'application au quotidien ? Quel est son titre exact ?" |
+| No cross-module flows | "Quand un {entity} est créé dans le module A, est-ce qu'un autre module doit en être informé ?" |
+
+### Anti-patterns
+
+| Anti-pattern | Signal | Action |
+|--------------|--------|--------|
+| Too many modules | > 10 modules for v1 | Suggest phased approach: core modules first |
+| No clear priority | "Everything is must-have" | Apply MoSCoW: "If you could only ship 3 modules?" |
+| Role confusion | Mixing business roles with system roles | Clarify: "We're defining system access levels, not job titles" |
+| Monolithic thinking | "It's all one big module" | Challenge: "Could a user only need access to part of this?" |
+
+---
+
+## Technical Mapping
+
+| Answer | Maps to |
+|--------|---------|
+| Application name | `metadata.application`, `cadrage.applicationRoles[].role` prefix |
+| Module list | `modules[]` in master feature.json |
+| Roles | `cadrage.applicationRoles[]` |
+| Cross-module flows | `consolidation.e2eFlows[]` (populated later in step-04) |
+| Default role | `cadrage.applicationRoles[].isDefault` |

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

@@ -12,7 +12,7 @@
 | Q3.1 | List ESSENTIAL features (Must-Have) | List |
 | Q3.2 | List DESIRED features (Should-Have) | List |
 | Q3.3 | List OPTIONAL features (Could-Have) | List |
-| Q3.4 | Any known constraints limiting v1 scope? | List of constraints |
+| Q3.4 | Any known constraints limiting scope? | List of constraints |
 
 ## 3.2 Business Process
 
@@ -29,10 +29,10 @@
 
 | Priority | Criterion |
 |----------|-----------|
-| Must | Without this feature, the module has no value |
-| Should | Brings significant value but can wait for v2 |
-| Could | Nice-to-have, can be implemented if time available |
-| Won't | Deferred — will be considered for future versions |
+| Must | Without this feature, the module has no value — implement first |
+| Should | Brings significant value — implement right after Must items |
+| Could | Nice-to-have — implement if no technical blocker |
+| Won't | Out of scope for this feature — belongs to a different module or feature |
 
 ## Elicitation Guide
 
@@ -40,9 +40,9 @@
 
 | 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) | > 10 items listed | "Si vous ne pouviez en garder que 3 à implémenter en premier, 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.2 (Should-Have) | Vide | "Y a-t-il des fonctionnalités utiles mais moins critiques ? Export, filtres avancés, notifications ?" |
 | Q3.4 (limites) | Vide | "Y a-t-il des contraintes connues qui pourraient limiter le périmètre ? (budget, délai, dépendance)" |
 | 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 ?" |