@atlashub/smartstack-cli 4.74.0 → 4.76.0

package/templates/skills/business-analyse/steps/step-01-cadrage.md

@@ -123,61 +123,42 @@ IF docs/**/*.md files found:
 - Pre-identify integration points: new feature may depend on or extend existing modules
 - NEVER re-specify what's already handed-off (status = "handed-off") — reference it instead
 
-### 2d. Domain Research (WebSearch — BEFORE engaging the client)
+### 2d. Domain Research (WebSearch — MANDATORY — BLOCKING)
 
-> **Ground the analysis in real-world patterns. This prevents greenfield mistakes
-> (e.g., putting firstName on Employee instead of linking to User).**
-> This step takes 30-60 seconds and dramatically improves entity design quality.
+> → **Load** `references/domain-research-playbook.md` for search strategy, query templates, and extraction format.
+> **MANDATORY — BLOCKING.** Web research is the #1 quality factor. An analysis without research is a 2/10.
+> Do NOT rely on "built-in domain expertise" — real-world research catches what the LLM misses.
 
-**WHEN to search:** ALWAYS for the main business domain. Skip only if the domain is purely SmartStack-internal (e.g., config, admin tools).
-
-**HOW to search:** Use WebSearch tool with targeted queries based on the detected domain.
+**Execute Level 1 research from the playbook:**
 
 ```
-1. DOMAIN MODEL SEARCH
-   Query: "{detected_domain} data model best practices" (e.g., "HR management data model best practices")
-   → Extract: standard entities, common relationships, industry patterns
-   → Store key findings in {domain_research}.dataModel
+IF workflow_mode = "project" (multi-app):
+  For EACH candidateApplication in config.candidateApplications:
+    1. WebSearch 1a: "{app_type} application modules features complete list"
+    2. WebSearch 1b: "best {app_type} software features comparison"
+    3. WebSearch 1c: "{app_type} data model entities relationships"
+    → Store in {domain_research}.applications[{app_code}]
 
-2. ENTITY PATTERN SEARCH (for the 2-3 most complex detected entities)
-   Query: "{entity_name} entity design pattern ERP" (e.g., "employee entity design pattern ERP")
-   → Extract: standard attributes, versioning patterns, common pitfalls
-   → Store in {domain_research}.entityPatterns[entity_name]
+ELSE (single-app):
+  1. WebSearch 1a: "{app_type} application modules features complete list"
+  2. WebSearch 1b: "best {app_type} software features comparison"
+  3. WebSearch 1c: "{app_type} data model entities relationships"
+  → Store in {domain_research}
 
-3. WORKFLOW SEARCH (if the domain involves approval/validation flows)
-   Query: "{domain} approval workflow pattern" (e.g., "timesheet approval workflow pattern")
-   → Extract: standard states, transition rules, multi-level approval
-   → Store in {domain_research}.workflows
+IF applicable domain (Billing, HR, Finance):
+  Execute Level 3 regulatory research from playbook
+  → Store in {domain_research}.regulatory[]
 ```
 
-**WHAT to extract (ULTRATHINK — internal only):**
-```yaml
-domain_research:
-  domain: "{detected domain — e.g., HR, CRM, Billing}"
-  dataModel:
-    standardEntities: ["Entity1", "Entity2"]     # what the industry considers standard
-    commonRelationships: ["Entity1 → Entity2"]   # typical FK patterns
-    antiPatterns: ["storing salary directly on employee"]  # mistakes to avoid
-  entityPatterns:
-    Employee:
-      standardAttributes: ["code", "userId", "departmentId", "hireDate", "status"]
-      versionedData: ["salary → separate table with effectiveDate"]
-      personPattern: "link to User via FK, never duplicate personal info"
-    Invoice:
-      standardAttributes: ["number", "clientId", "issueDate", "dueDate", "status"]
-      calculatedFields: ["subtotal", "taxAmount", "total"]
-      workflowStates: ["Draft", "Sent", "Paid", "Overdue", "Cancelled"]
-  workflows:
-    timesheetApproval: "Draft → Submitted → ManagerApproved → ClientApproved"
-    invoiceLifecycle: "Draft → Validated → Sent → Paid"
-```
-
-> **CRITICAL:** This research is INTERNAL context. Do NOT show raw search results to the client.
-> Use the findings to:
-> - Improve pre-analysis quality (detect shadow zones the client won't mention)
-> - Ground entity architecture decisions in Phase 4d-bis
-> - Inform proactive suggestions in Phase 4 (ANTICIPATION)
-> - Prevent common anti-patterns during step-03 entity specification
+**FALLBACK (WebSearch unavailable):**
+```
+IF WebSearch tool is not available or fails:
+  → Display WARNING: "WebSearch indisponible. Qualite d'analyse degradee (max 4/10)."
+  → AskUserQuestion: "Continuer sans recherche web ? (Non recommande)"
+  → IF user confirms: proceed with {domain_research}.source = "built-in-only"
+    → Load references/module-completeness-challenge.md as fallback
+  → IF user declines: STOP
+```
 
 ### 2b. Silent Pre-Analysis (ULTRATHINK — no output to client)
 
@@ -196,19 +177,43 @@ Analyze `{feature_description}` AND `{domain_research}` silently:
 4. **Prepare challenge questions** — specific to this brief, not generic
 5. **Pre-identify anticipated sections and resources** per detected module
 
+6. **MODULE COMPLETENESS CROSS-CHECK** (CRITICAL — requires domain research from 2d):
+   For EACH application:
+     - Compare detected modules vs `{domain_research}.applications[app].standardModules`
+     - For EACH **CORE** module absent → add to `shadow_zones` with `priority: "HIGH"`
+     - For EACH **STANDARD** module absent → add to `shadow_zones` with `priority: "MEDIUM"`
+   Example: User says "Facturation avec factures".
+   Research reveals CORE modules: [Factures, Avoirs, Paiements].
+   → `shadow_zones += [{topic: "Avoirs/Credit Notes", priority: "HIGH", why: "Module CORE manquant — legalement requis pour corriger une facture"}]`
+
+7. **BUSINESS PROCESS MAPPING** (MANDATORY for multi-app):
+   Before decomposing into modules, map the end-to-end business processes:
+   - From `{domain_research}` and `{feature_description}`, identify cross-app processes:
+     - "Cycle commercial: Prospect → Client → Opportunite → Devis → Facture → Paiement"
+     - "Cycle RH: Embauche → Fiche employe → Absences → Documents"
+     - "Cycle projet: Devis accepte → Projet → Affectation → Saisie heures → Validation → Facturation"
+   - For EACH process step, check if a module covers it. Flag uncovered steps.
+   Store in `{_preAnalysis.businessProcesses}`
+
 Store in `{pre_analysis}` — Write pre_analysis to cadrage.json as a `_preAnalysis` field (transient — removed on cadrage completion). This ensures the data survives context compaction:
 ```yaml
 _preAnalysis:
   problem_type: "new_tool|replace|automate|centralize"
   detected_modules: [{name, description, detected_sections}]
-  shadow_zones: [{topic, why_it_matters, challenge_question}]
+  shadow_zones: [{topic, why_it_matters, challenge_question, priority}]
   anticipated_suggestions: [{suggestion, justification, module}]
   domain_research:                          # from Phase 2d web search
     domain: "{detected domain}"
-    standardEntities: [...]
-    antiPatterns: [...]
-    entityPatterns: {entity: {standardAttributes, versionedData, personPattern}}
-    workflows: {name: "state1 → state2 → state3"}
+    applications:                           # Level 1 research per app
+      {app_code}:
+        standardModules: [{name, classification, description, standardSections}]
+        competitiveInsights: [{product, keyFeatures}]
+        dataModel: {entities, relationships, antiPatterns}
+    regulatory: []                          # Level 3 if applicable
+  businessProcesses:                        # from step 7 above
+    - name: "Cycle commercial"
+      apps: ["Crm", "Facturation"]
+      steps: [{name, module, covered: true|false}]
 ```
 
 ---
@@ -273,6 +278,77 @@ options:
 
 ---
 
+### 3b. Challenge Against Industry Standards (MANDATORY — BEFORE scope lock)
+
+> **Use domain research to challenge scope completeness BEFORE locking.**
+> This is what distinguishes a 2/10 analysis from a 9/10 analysis.
+
+1. From `{domain_research}.applications`, build a completeness comparison:
+
+Display as markdown (direct text, NOT inside AskUserQuestion):
+
+```
+## {language == "fr" ? "Analyse competitive" : "Competitive Analysis"}
+
+{language == "fr"
+  ? "Pour chaque application, j'ai recherche ce que proposent les solutions du marche :"
+  : "For each application, I researched what market solutions offer:"}
+
+| Application | Vos modules | Modules standard industrie | Ecart |
+|-------------|------------|---------------------------|-------|
+| {app} | {user_modules} | {research_standard_modules} | {missing_CORE + missing_STANDARD} |
+
+{language == "fr" ? "**Modules CORE manquants** (standard dans toute solution de ce type) :" : "**Missing CORE modules:**"}
+{for each missing CORE module:}
+- **{module_name}** : {description} — {why it matters for this project}
+
+{language == "fr" ? "**Modules STANDARD manquants** (presents dans la majorite des solutions) :" : "**Missing STANDARD modules:**"}
+{for each missing STANDARD module:}
+- **{module_name}** : {description}
+```
+
+2. AskUserQuestion (multiSelect: true):
+```
+question: "{language == 'fr'
+  ? 'Quels modules manquants souhaitez-vous ajouter ? Les modules CORE sont fortement recommandes.'
+  : 'Which missing modules would you like to add? CORE modules are strongly recommended.'}"
+header: "{language == 'fr' ? 'Completude des applications' : 'Application completeness'}"
+multiSelect: true
+options:
+  - For each missing CORE module: label: "{name} (CORE — fortement recommande)", description: "{why}"
+  - For each missing STANDARD module: label: "{name} (STANDARD — recommande)", description: "{why}"
+  - label: "{language == 'fr' ? 'Aucun — perimetre initial' : 'None — keep initial scope'}"
+    description: "{language == 'fr' ? 'Garder uniquement les modules initiaux' : 'Keep only initial modules'}"
+```
+
+3. IF user adds modules → update `{pre_analysis}.detected_modules` and `candidateApplications`
+4. IF user excludes CORE modules → document exclusion reason in `cadrage.globalScope.outOfScope`
+
+---
+
+## SCOPE LOCK (MANDATORY — after validated reformulation + competitive challenge)
+
+> **The modules and applications identified in the validated reformulation are the LOCKED SCOPE.**
+
++==============================================================================+
+|  SCOPE LOCK RULES — Applied from this point forward                          |
++==============================================================================+
+|                                                                              |
+|  1. The NUMBER of applications is LOCKED (confirmed in step-00 Step 3b).     |
+|     Phase 4d-bis (Entity Sourcing) CANNOT create new applications.           |
+|                                                                              |
+|  2. Phase 4d-bis CAN recommend entities as `config_list` or                  |
+|     `in_app_section` — but CANNOT recommend `new_module` or                  |
+|     `new_application` without EXPLICIT AskUserQuestion confirmation.         |
+|                                                                              |
+|  3. Portal detection (4b-bis) creates ONE "Portal" module with sections,     |
+|     NOT multiple MyX modules.                                                |
+|                                                                              |
+|  4. Any scope expansion beyond the reformulation = AskUserQuestion.          |
+|     Silent scope expansion is FORBIDDEN.                                     |
+|                                                                              |
++==============================================================================+
+
 ## PHASE 3: APPROFONDISSEMENT (Challenge & Deepen)
 
 ### 4. Targeted Questionnaires
@@ -282,12 +358,30 @@ options:
 > Apply elicitation techniques from `_shared.md` after each batch.
 > The goal is a CONVERSATION, not an interrogation.
 
-#### 4a. Business Context (ALWAYS — from `questionnaire/01-context.md`)
+#### 4a. Batch 1 — Contexte & Vision (from `questionnaire/01-context.md`)
 
 > Load the full questionnaire reference for elicitation guides and alert signals.
-> The questionnaire contains 3 targeted questions: Q1.1 (business process), Q1.4 (friction points), Q1.8 (vision).
+> **Principe analyste expert :** Poser les questions necessaires pour une couverture metier complete.
+> Proposer proactivement les modules et regles que le client n'a pas mentionnes.
+> Challenger chaque zone d'ombre. L'auto-deduction est un COMPLEMENT, jamais un SUBSTITUT aux questions critiques.
+
+**Questions a poser (1 batch via AskUserQuestion) :**
+- Q1.1 (OBLIGATOIRE) : processus metier
+- Q1.8 (OBLIGATOIRE) : vision cible
+- Q1.4 (CONDITIONNEL) : frictions — poser UNIQUEMENT si `_preAnalysis.problem_type IN ("replace", "automate")`
+
+```
+IF _preAnalysis.problem_type IN ("new_tool", "centralize"):
+  → Skip Q1.4
+  → Auto-remplir: cadrage.asIs = "Aucun outil existant — nouveau système"
+  → Ask Q1.1 + Q1.8 in 1 batch (2 questions)
+ELSE:
+  → Ask Q1.1 + Q1.4 + Q1.8 in 1 batch (3 questions)
+```
 
-Ask all 3 questions in 1 batch via AskUserQuestion.
+**Aussi dans ce batch :** Detection utilisateurs externes (avancee depuis ex-4b-bis) :
+- Ajouter la question : "Des utilisateurs externes (clients, fournisseurs, partenaires) accederont-ils au systeme ?"
+- Cette reponse active `_portalDetected` DES LE DEBUT pour adapter les questions stakeholders en consequence.
 
 Apply ULTRATHINK after the batch:
 - If answer is vague → probe deeper using the elicitation guide from 01-context.md
@@ -295,74 +389,62 @@ Apply ULTRATHINK after the batch:
 - If answer is superficial → apply Technique 2 (chain of whys)
 - If answer is excellent → record and move on
 
-#### 4b. Stakeholders (ALWAYS — from `questionnaire/02-stakeholders-scope.md`)
+#### 4b. Batch 2 — Utilisateurs & Acces (from `questionnaire/02-stakeholders-scope.md`)
 
-> The questionnaire contains 10 targeted questions covering profiles, tasks, access levels, scope, and user journey.
+> **5 questions obligatoires** couvrant profils, taches et niveaux d'acces.
+> **Regle : 2 questions max par AskUserQuestion** — ne jamais submerger l'utilisateur.
 
-**Mandatory minimum:** Q2.1 (users), Q2.5 (tasks per profile), Q2.9-Q2.11 (access levels).
-
-Ask in 1-2 batches. After each batch:
+**Batch 2a** (Q2.1 + Q2.5) : Profils et taches.
+Ask via AskUserQuestion (2 questions).
 - If only 1 user type mentioned → probe: "Who else interacts? Managers? Admins? External users?"
-- If "no restrictions" → probe: "Are there sensitive data (salary, contracts, personal info) that should be restricted to specific roles?"
 - If tasks are generic → ask for a concrete scenario: "Walk me through a typical day"
 
-#### 4b-bis. Détection Portail Client (ULTRATHINK — après batch stakeholders)
-
-Analyser les réponses stakeholders pour signaux d'utilisateurs externes :
+**Batch 2b** (Q2.9 + Q2.10) : Restrictions d'acces et droits de modification.
+Ask via AskUserQuestion (2 questions).
+- If "no restrictions" → probe: "Are there sensitive data (salary, contracts, personal info) that should be restricted to specific roles?"
 
-```
-EXTERNAL_SIGNALS = ["client", "customer", "fournisseur", "supplier", "partenaire",
-  "partner", "portail", "portal", "externe", "external", "tiers", "third-party",
-  "organisation cliente"]
-```
+**Batch 2c** (Q2.11) : Actions sensibles (suppression, validation, export).
+Ask via AskUserQuestion (1 question).
 
-> **SmartStack gère nativement les utilisateurs externes :**
-> - **Person Extension Pattern** : User → Employee, Contact, Customer via `UserId` FK
-> - **Organisation Extension** : Organisation → Client, Supplier via `OrganisationId` FK
-> - **Multi-tenant** : portail et interne déployés sur des tenants séparés automatiquement
+Apply ULTRATHINK after EACH batch:
+- If answer is vague → probe deeper using the elicitation guide
+- If answer is solution-oriented → apply Technique 1 (reformulate as need)
+- If answer is superficial → apply Technique 2 (chain of whys)
+- If answer is excellent → record and move on
 
-SI un profil stakeholder match EXTERNAL_SIGNALS :
-  → Stocker dans `{pre_analysis}`: `_portalDetected: true`
-  → **Auto-classifier** chaque stakeholder détecté : `audience: "internal" | "external" | "shared"`
-  → **Auto-déduire** `_portalMode` :
+#### 4b-bis. Résolution Portail Client (ULTRATHINK — après batch 2)
 
-| Stakeholders détectés | `_portalMode` |
-|----------------------|---------------|
-| Internes + Externes | `"dual"` |
-| Uniquement externes | `"portal-only"` |
-| Uniquement internes | `"internal-only"` |
+> → **Load** `references/portal-classification.md` for external signal detection, classification rules, and portal mode resolution.
 
-  → **Informer le client** (statement, PAS de question) :
+Execute portal classification following the reference. Store result in `_portalMode`.
 
-```
-"{language == 'fr'
-  ? 'J\'ai détecté des utilisateurs externes ({profiles}). SmartStack déploiera automatiquement un portail dédié ({_portalMode}) avec isolation multi-tenant. Les extensions Person/Organisation gèrent nativement la séparation des profils internes et externes.'
-  : 'I detected external users ({profiles}). SmartStack will automatically deploy a dedicated portal ({_portalMode}) with multi-tenant isolation. Person/Organisation extensions natively handle the separation of internal and external profiles.'}"
-```
+#### 4c. Batch 3 — Perimetre & Limites (from `questionnaire/02-stakeholders-scope.md`)
 
-SI aucun profil ne match EXTERNAL_SIGNALS → `_portalMode = "internal-only"` (défaut silencieux, rien à informer).
+> **Objectif :** Borner le perimetre — exclusions explicites + integrations/imports si pertinent.
+> Les fonctionnalites IN-SCOPE sont couvertes par la reformulation (phase 2) et ne necessitent plus de question explicite.
+> Le parcours utilisateur (ex-Q2.16-Q2.18) est desormais capture en step-03 lors de la specification des use cases.
 
-#### 4c. Functional Scope (ALWAYS — from `questionnaire/02-stakeholders-scope.md`)
+**Questions a poser (1 batch via AskUserQuestion) :**
+- Q2.15 (OBLIGATOIRE) : exclusions
+- Q2.19 (CONDITIONNEL) : integrations — poser uniquement si le brief mentionne un systeme externe
+- Q2.20 (CONDITIONNEL) : import donnees — poser uniquement si le brief mentionne migration/import
 
-**Mandatory minimum:** Q2.13 (in-scope), Q2.15 (exclusions), Q2.16 (main journey).
+```
+IF brief mentions external system OR integration:
+  → Ask Q2.15 + Q2.19 + Q2.20 in 1 batch
+ELIF brief mentions import OR migration:
+  → Ask Q2.15 + Q2.20 in 1 batch
+ELSE:
+  → Ask Q2.15 only
+  → Auto-remplir: cadrage.externalIntegrations = [], cadrage.dataImport = null
+```
 
-Ask in 1-2 batches. After each batch:
+After the batch:
 - If no exclusions → probe: "What should this system explicitly NOT do?"
-- If journey is too simple → detail: "What happens when something goes wrong? When someone cancels?"
-
-> **MANDATORY Error Path Challenge (run for EVERY project after the main journey is described):**
->
-> Ask via AskUserQuestion (1 batch, 2-3 questions):
-> - "Si l'action principale échoue (erreur serveur, données invalides, timeout), que doit-il se passer ?"
-> - "Qui est notifié en cas d'erreur ? L'utilisateur ? Un administrateur ? Via quel canal ?"
-> - "L'état doit-il être annulé (rollback) ou conservé partiellement ?"
->
-> Record answers in `cadrage.errorFlows[]`:
-> ```json
-> { "scenario": "...", "trigger": "...", "notification": "...", "recovery": "rollback|partial|manual" }
-> ```
->
-> These error flows become **Business Rules** in step-03 (BR-WF category: workflow/guard conditions).
+
+> **Error Path Challenge :** Deplace vers step-03 — les scenarios d'erreur sont captures par module
+> lors de la specification des use cases (alternativeScenarios, errorScenarios).
+> En step-01, les erreurs globales sont couvertes par les suggestions (phase 4 — Anticipation).
 
 #### 4d. Challenge Implicit Assumptions (CRITICAL)
 
@@ -386,182 +468,108 @@ Ask challenge questions via AskUserQuestion (1-2 batches of max 4).
 
 For EACH referenced entity/concept detected during phases 2-4 that is NOT already covered by an identified module:
 
-##### PHASE 1 — ULTRATHINK: Silent Architecture Analysis (NO output to client)
+> → **Load** `references/entity-sourcing-presentation.md` for the 4-phase entity sourcing flow:
+> PHASE 1 (ULTRATHINK analysis), PHASE 2 (display to client), PHASE 3 (AskUserQuestion), PHASE 4 (process answer).
 
-> **The AI reasons about the entity BEFORE presenting options. This is internal thinking only.**
+Execute ALL 4 phases from the reference for EACH referenced entity detected.
 
-```
-ULTRATHINK — Entity Architecture Analysis for {entity_name}:
+#### 4e. Conditional Deep-Dives
 
-1. DOMAIN COHERENCE (from decision tree in reference)
-   - Application domain: {app_description}
-   - Entity fit: CORE | SUPPORT | PERIPHERAL
-   - Justification: {1 sentence — why this entity is/isn't core to the app}
-   - Example: "Projets" in a time management app = CORE (without projects, time entries have no target)
-   - Example: "Codes d'imputation" in a time management app = SUPPORT (useful for accounting, but not central)
+Based on brief analysis, load additional materials if relevant:
 
-2. ENTITY SCORING (5 criteria, 0-3 each — from scoring grid in reference)
-   - Lifecycle:  {score}/3 — {brief justification}
-   - Actors:     {score}/3 — {brief justification}
-   - Relations:  {score}/3 — {brief justification}
-   - Volume:     {score}/3 — {brief justification}
-   - Autonomy:   {score}/3 — {brief justification}
-   - TOTAL:      {total}/15 → {classification: config_list | in_app | light_module | full_module}
+| Condition | Questionnaire |
+|-----------|---------------|
+| Security or compliance mentioned | `questionnaire/03-data-ui.md` (security section) |
+| External system integration | `questionnaire/05-cross-module.md` (integration section) |
+| Performance requirements | Additional probing on non-functional needs |
+| Technical constraints | Additional probing on platform constraints |
 
-3. PRE-CLASSIFICATION CHECK (from entity patterns in reference)
-   - Does {entity_name} match a known pattern? → {yes: which one | no: use scoring}
-   - Override needed? → {yes: why | no}
+---
 
-4. RECOMMENDATION
-   - Option: {config_list | in_app_section | new_module | external_system}
-   - Confidence: HIGH | MEDIUM | LOW
-   - Reasoning: {1-2 sentences}
-   - Risk if wrong choice: {what goes wrong if user picks a different option}
+## PHASE 4: ANTICIPATION (Suggest Unexpressed Needs)
 
-5. IF recommendation = new_module → PRE-BUILD ARCHITECTURE
-   - Module code: {PascalCase}
-   - Section `list`: {main entity grid + create action + navigation to detail}
-   - Detail page tabs: [{tab_name: content}] (accessible by clicking a row in list)
-   - Additional sections: [{code: justification}] (ONLY functional sections: dashboard, approve, import, rapport...)
-   - Dependencies: [{which modules reference/are referenced by this entity}]
-   - Topological position: layer {N} (foundation if no dependencies)
-```
+### 4f. Detection des besoins structurants (MANDATORY — BEFORE suggestions)
 
-##### PHASE 2 — Present Analysis & Recommendation to Client
+> **Auto-deduire les besoins structurants depuis le domain research et confirmer en 1 seule question.**
+> Ces choix impactent la structure du systeme et doivent etre captures AVANT la specification.
 
-**BEFORE the AskUserQuestion, display the analysis as markdown:**
+**ULTRATHINK — Detection des besoins structurants :**
 
 ```
-### {language == "fr" ? "Analyse" : "Analysis"} : {entity_plural}
+1. HISTORIQUE DES MODIFICATIONS
+   → Analyse: {domain_research} — le domaine necessite-t-il de tracer qui a modifie quoi et quand ?
+   → Default: OUI pour les entites principales, NON pour les tables de reference
+   → Exemples: Employes (OUI), AbsenceType (NON)
 
-{language == "fr"
-  ? "Les **{entity_plural}** sont référencés par {parent_module} ({relationship_description})."
-  : "**{entity_plural}** are referenced by {parent_module} ({relationship_description})."}
+2. DONNEES HIERARCHIQUES (parent-enfant)
+   → Analyse: existe-t-il des structures arborescentes ? (departements → sous-departements, categories → sous-categories)
+   → Default: NON sauf si explicitement detecte
 
-{language == "fr" ? "**Mon analyse :**" : "**My analysis:**"}
-- {language == "fr" ? "Cohérence domaine" : "Domain coherence"} : **{CORE|SUPPORT|PERIPHERAL}** — {justification}
-- {language == "fr" ? "Score de complexité" : "Complexity score"} : **{score}/15** ({classification})
-- {language == "fr" ? "Recommandation" : "Recommendation"} : **{recommended_option}** — {reasoning}
-```
-
-**IF recommendation = new_module AND confidence >= MEDIUM, ALSO display:**
+3. SUPPRESSION RECUPERABLE
+   → Analyse: les donnees supprimees doivent-elles pouvoir etre restaurees ?
+   → Default: OUI pour les entites metier, NON pour les tables de liaison
 
+4. CYCLE DE VIE (etats et transitions)
+   → Analyse: quelles entites passent par des etats successifs ?
+   → Lister: [{entity, states: ["Brouillon", "Actif", ...], transitions: ["Brouillon→Actif", ...]}]
 ```
-{language == "fr" ? "**Architecture proposée :**" : "**Proposed architecture:**"}
-
-| {language == "fr" ? "Niveau" : "Level"} | {language == "fr" ? "Valeur" : "Value"} | {language == "fr" ? "Justification" : "Rationale"} |
-|--------|--------|---------------|
-| Application | `{app_code}` | {app_name} |
-| Module | `{ModuleCode}` | {language == "fr" ? "{pourquoi ce découpage}" : "{why this decomposition}"} |
 
-| Section | {language == "fr" ? "Justification" : "Rationale"} | Resources |
-|---------|---------------|-----------|
-| `list` | {language == "fr" ? "Page principale : grille, création, navigation vers détail" : "Main page: grid, create action, navigate to detail"} | {entity}-grid, {entity}-filters, {entity}-form |
-| {additional_section} | {justification} | {resources} |
+**Presenter en 1 AskUserQuestion :**
 
-{language == "fr"
-  ? "**Page détail** (onglets accessibles depuis la liste) :"
-  : "**Detail page** (tabs accessible from list):"}
+```
+question: "{language == 'fr'
+  ? 'Voici les besoins structurants que j\'ai déduits pour votre domaine. Confirmez-vous ?'
+  : 'Here are the structural needs I deduced for your domain. Do you confirm?'}"
+header: "{language == 'fr' ? 'Besoins structurants' : 'Structural needs'}"
+
+Display as markdown BEFORE the question:
+  | Besoin | Détection | Données concernées |
+  |--------|----------|--------------------|
+  | Historique des modifications | {OUI/NON} | {liste entites} |
+  | Données hiérarchiques | {OUI/NON} | {liste entites si OUI} |
+  | Suppression récupérable | {OUI/NON} | {liste entites} |
+  | Cycle de vie | {OUI/NON} | {entite: [etats]} |
 
-| {language == "fr" ? "Onglet" : "Tab"} | {language == "fr" ? "Contenu" : "Content"} |
-|--------|---------|
-| {language == "fr" ? "Informations" : "Information"} | {language == "fr" ? "Fiche principale" : "Main record"} |
-| {tab_name} | {tab_content} |
+options:
+  - label: "{language == 'fr' ? 'Oui, c\'est correct' : 'Yes, correct'}"
+  - label: "{language == 'fr' ? 'À ajuster' : 'Needs adjustment'}"
+    description: "{language == 'fr' ? 'Certains points sont à modifier' : 'Some points need modification'}"
+```
 
-{language == "fr"
-  ? "**Impact :** {ModuleName} deviendra une dépendance de {parent_module} (couche {N} du graphe)."
-  : "**Impact:** {ModuleName} will become a dependency of {parent_module} (layer {N} in the graph)."}
+Store confirmed patterns in `cadrage.smartStackPatterns`:
+```json
+{
+  "auditTrail": { "enabled": true, "entities": ["Employee", "Invoice"] },
+  "hierarchy": { "enabled": false, "entities": [] },
+  "softDelete": { "enabled": true, "entities": ["Employee", "Client", "Invoice"] },
+  "workflowStates": [
+    { "entity": "Invoice", "states": ["Draft", "Sent", "Paid", "Overdue"], "transitions": [...] }
+  ]
+}
 ```
 
-##### PHASE 3 — Ask with Recommended Option First
+### 4g. Evolution et risques de donnees (MANDATORY)
+
+> **Anticiper les changements futurs et les risques de qualite de donnees.**
 
-**Order the options with the recommendation FIRST, marked "(Recommandé)" / "(Recommended)":**
+Ask via AskUserQuestion (2 questions max) :
 
 ```
 question: "{language == 'fr'
-  ? 'Comment souhaitez-vous gérer les {entity_plural} ?'
-  : 'How do you want to manage {entity_plural}?'}"
-header: "{entity_name}"
-options:
-  (ORDER: recommended option FIRST, then the 3 remaining options in logical order)
-
-  IF recommendation = new_module:
-  - label: "{language == 'fr' ? 'Nouveau module dédié (Recommandé)' : 'New dedicated module (Recommended)'}"
-    description: "{language == 'fr'
-      ? 'Module {ModuleCode} avec page liste, détail par onglets, permissions dédiées'
-      : '{ModuleCode} module with list page, tabbed detail, dedicated permissions'}"
-  - label: "{language == 'fr' ? 'Géré dans l\'app' : 'Managed in app'}"
-    description: "..."
-  - label: "{language == 'fr' ? 'Système externe' : 'External system'}"
-    description: "..."
-  - label: "{language == 'fr' ? 'Liste simple en config' : 'Simple config list'}"
-    description: "..."
-
-  IF recommendation = config_list:
-  - label: "{language == 'fr' ? 'Liste simple en config (Recommandé)' : 'Simple config list (Recommended)'}"
-    description: "{language == 'fr'
-      ? 'Table de référence administrable, pas de module dédié'
-      : 'Admin-managed reference table, no dedicated module'}"
-  - label: "{language == 'fr' ? 'Géré dans l\'app' : 'Managed in app'}"
-    description: "..."
-  - label: "{language == 'fr' ? 'Nouveau module dédié' : 'New dedicated module'}"
-    description: "..."
-  - label: "{language == 'fr' ? 'Système externe' : 'External system'}"
-    description: "..."
-
-  IF recommendation = in_app_section:
-  - label: "{language == 'fr' ? 'Géré dans l\'app (Recommandé)' : 'Managed in app (Recommended)'}"
-    description: "{language == 'fr'
-      ? 'Accessible via un onglet dans la page détail de {parent_module}'
-      : 'Accessible via a tab in {parent_module} detail page'}"
-  - label: "{language == 'fr' ? 'Nouveau module dédié' : 'New dedicated module'}"
-    description: "..."
-  - label: "{language == 'fr' ? 'Liste simple en config' : 'Simple config list'}"
-    description: "..."
-  - label: "{language == 'fr' ? 'Système externe' : 'External system'}"
-    description: "..."
-
-  IF recommendation = external_system:
-  - label: "{language == 'fr' ? 'Système externe (Recommandé)' : 'External system (Recommended)'}"
-    description: "{language == 'fr'
-      ? 'Les {entity_plural} viennent d\'un autre système (import ou API)'
-      : '{entity_plural} come from another system (import or API)'}"
-  - label: "{language == 'fr' ? 'Nouveau module dédié' : 'New dedicated module'}"
-    description: "..."
-  - label: "{language == 'fr' ? 'Géré dans l\'app' : 'Managed in app'}"
-    description: "..."
-  - label: "{language == 'fr' ? 'Liste simple en config' : 'Simple config list'}"
-    description: "..."
-
-  IF confidence = LOW (no clear recommendation):
-  (all 4 options in neutral order, NO "(Recommandé)" tag)
-```
-
-##### PHASE 4 — Process Answer
-
-| Choice | Action |
-|--------|--------|
-| **Géré dans l'app** | Entity becomes a sub-entity of the parent module. Add as a **tab in the detail page** of the referencing module. Note in coverageMatrix with `parentModule` field. |
-| **Nouveau module dédié** | **Add new module to `{pre_analysis}.detected_modules[]`** with the proposed architecture (sections, detail tabs, dependencies). Add to `coverageMatrix` as inScope. The `list` section is ALWAYS the main section. Additional sections ONLY for distinct functional sections (dashboard, approve, import...). `create` and `edit` are ACTIONS within `list` and detail pages, NEVER standalone sections. |
-| **Système externe** | Flag for integration specification. Add to `coverageMatrix` as integration. Load questionnaire materials on integrations if not already covered. |
-| **Liste simple en config** | Entity becomes a lookup/reference table (no dedicated module, no section). Note in coverageMatrix as config data. |
-
-> **CRITICAL:** The intelligence of this step is in the ULTRATHINK analysis. The AI must REASON about domain coherence, score the entity, and recommend — not just present 4 neutral options. The client can always override the recommendation, but they should benefit from expert architectural guidance.
-
-#### 4e. Conditional Deep-Dives
-
-Based on brief analysis, load additional materials if relevant:
-
-| Condition | Questionnaire |
-|-----------|---------------|
-| Security or compliance mentioned | `questionnaire/03-data-ui.md` (security section) |
-| External system integration | `questionnaire/05-cross-module.md` (integration section) |
-| Performance requirements | Additional probing on non-functional needs |
-| Technical constraints | Additional probing on platform constraints |
+  ? 'Qu\'est-ce qui risque de changer dans votre activité dans les 6 prochains mois ? Dans 1 an ? (nouveaux utilisateurs, réglementations, croissance des volumes...)'
+  : 'What is likely to change in your business in the next 6 months? 1 year? (new users, regulations, volume growth...)'}"
+header: "{language == 'fr' ? 'Évolution prévisible' : 'Expected evolution'}"
+```
 
----
+Then ask:
+```
+question: "{language == 'fr'
+  ? 'Que se passe-t-il si une donnée est saisie incorrectement ou manquante ? Quels sont les risques métier ?'
+  : 'What happens if data is entered incorrectly or is missing? What are the business risks?'}"
+header: "{language == 'fr' ? 'Risques de données' : 'Data risks'}"
+```
 
-## PHASE 4: ANTICIPATION (Suggest Unexpressed Needs)
+Store answers in `cadrage.anticipatedEvolution` and `cadrage.dataRisks`.
 
 ### 5. Proactive Suggestions
 
@@ -611,6 +619,51 @@ options:
 
 ---
 
+## PHASE 4b: BUSINESS PROCESS MAPPING (MANDATORY for multi-app)
+
+> **Map the end-to-end business processes BEFORE bounding scope.**
+> Business processes reveal cross-app dependencies and missing modules.
+> A process step without a covering module = a GAP in the application.
+
+1. From `{domain_research}` and cadrage answers, identify the main business processes:
+
+Display as markdown:
+```
+### {language == "fr" ? "Processus metier identifies" : "Identified business processes"}
+
+| # | Processus | Applications concernees | Flux |
+|---|-----------|----------------------|------|
+| 1 | {process_name} | {app1} → {app2} | {step1} → {step2} → ... → {stepN} |
+```
+
+2. For EACH process, check that every step has a corresponding module:
+
+```
+For each step in process:
+  IF no module covers this step:
+    FLAG as gap: "{process_name} step '{step_name}' has no covering module"
+
+Display flagged gaps:
+  "�� Etapes non couvertes :"
+  - {process} : "{step}" — pas de module correspondant
+```
+
+3. AskUserQuestion:
+```
+question: "{language == 'fr'
+  ? 'Voici les processus metier identifies. Des etapes ne sont pas couvertes par vos modules. Souhaitez-vous les couvrir ?'
+  : 'Here are the identified business processes. Some steps are not covered by your modules. Would you like to cover them?'}"
+header: "{language == 'fr' ? 'Processus metier' : 'Business processes'}"
+options:
+  - label: "{language == 'fr' ? 'Oui, ajouter les modules manquants' : 'Yes, add missing modules'}"
+  - label: "{language == 'fr' ? 'Exclure ces etapes du perimetre' : 'Exclude these steps from scope'}"
+  - label: "{language == 'fr' ? 'Revoir les processus' : 'Review the processes'}"
+```
+
+4. Store confirmed processes in `cadrage._preAnalysis.businessProcesses`
+
+---
+
 ## PHASE 5: PERIMETRE (Bound Scope)
 
 ### 6. Application Roles Definition
@@ -643,10 +696,10 @@ options:
     description: "{language == 'fr' ? 'Modifier le nombre ou les permissions des rôles' : 'Modify number or permissions of roles'}"
 ```
 
-### 6b. Table Prefix Definition (MANDATORY)
+### 6b. Identifiant court de l'application (MANDATORY)
 
-> **Every business application MUST define a table prefix.**
-> This prefix identifies which application a database table belongs to (e.g., `rh_Employees`, `fi_Invoices`).
+> **Chaque application metier a besoin d'un identifiant court** (2-5 lettres) pour distinguer ses donnees
+> dans le systeme. Cet identifiant sera utilise en interne pour le nommage.
 
 **Process:**
 
@@ -658,19 +711,19 @@ options:
 
 ```
 {language == "fr"
-  ? "### Préfixe de table\n\nToutes les tables de cette application en base de données porteront un préfixe pour identifier leur appartenance.\n\nPréfixe suggéré : **`{suggested_prefix}`**\n\nExemple : `{suggested_prefix}Employees`, `{suggested_prefix}Contracts`"
-  : "### Table Prefix\n\nAll database tables for this application will carry a prefix to identify their ownership.\n\nSuggested prefix: **`{suggested_prefix}`**\n\nExample: `{suggested_prefix}Employees`, `{suggested_prefix}Contracts`"}
+  ? "### Identifiant de l'application\n\nPour distinguer les données de votre application dans le système, un identifiant court est nécessaire.\n\nIdentifiant suggéré : **`{suggested_prefix}`**"
+  : "### Application identifier\n\nTo distinguish your application's data in the system, a short identifier is needed.\n\nSuggested identifier: **`{suggested_prefix}`**"}
 ```
 
 3. Ask via AskUserQuestion:
 ```
-question: "{language == 'fr' ? 'Ce préfixe de table vous convient-il ?' : 'Does this table prefix work for you?'}"
-header: "Préfixe"
+question: "{language == 'fr' ? 'Cet identifiant court vous convient-il ?' : 'Does this short identifier work for you?'}"
+header: "{language == 'fr' ? 'Identifiant' : 'Identifier'}"
 options:
   - label: "{language == 'fr' ? 'Oui, parfait' : 'Yes, perfect'}"
-    description: "{language == 'fr' ? 'Utiliser le préfixe suggéré' : 'Use the suggested prefix'}"
+    description: "{language == 'fr' ? 'Utiliser l\'identifiant suggéré' : 'Use the suggested identifier'}"
   - label: "{language == 'fr' ? 'Personnaliser' : 'Customize'}"
-    description: "{language == 'fr' ? 'Choisir un autre préfixe (2-5 lettres minuscules + _)' : 'Choose a different prefix (2-5 lowercase letters + _)'}"
+    description: "{language == 'fr' ? 'Choisir un autre identifiant (2-5 lettres)' : 'Choose a different identifier (2-5 letters)'}"
 ```
 
 4. IF "Customize" → ask for custom prefix via AskUserQuestion (open-ended "Other" option)
@@ -737,6 +790,34 @@ BEFORE transitioning to step-02:
 
 7. Iterate until the client confirms
 
+### 7b. Validation de completude (MANDATORY — apres confirmation de la matrice)
+
+> **Jouer l'avocat du diable avant de clore le cadrage.**
+
+Ask via AskUserQuestion (1 question avec options) :
+```
+question: "{language == 'fr'
+  ? 'Avant de passer à la phase suivante, quelques vérifications :'
+  : 'Before moving to the next phase, a few checks:'}"
+header: "{language == 'fr' ? 'Complétude du périmètre' : 'Scope completeness'}"
+```
+
+Display as markdown BEFORE the question:
+```
+{language == "fr"
+  ? "### Vérifications finales\n\n1. **Remplacement** — Ce système remplace-t-il complètement l'outil ou processus actuel ? Ou cohabitera-t-il avec l'existant ?\n2. **Tâches manuelles** — Reste-t-il des tâches aujourd'hui faites sur Excel, papier ou email qui ne sont pas couvertes ?\n3. **Utilisateurs rares** — Y a-t-il des utilisateurs occasionnels ou des cas d'usage peu fréquents mais réels qui ne sont pas couverts ?"
+  : "### Final checks\n\n1. **Replacement** — Does this system fully replace the current tool or process? Or will it coexist?\n2. **Manual tasks** — Are there tasks currently done in Excel, on paper, or by email that are not covered?\n3. **Edge users** — Are there occasional users or infrequent but real use cases that are not covered?"}
+```
+
+```
+options:
+  - label: "{language == 'fr' ? 'Tout est couvert' : 'Everything is covered'}"
+  - label: "{language == 'fr' ? 'Il manque des éléments' : 'Some elements are missing'}"
+    description: "{language == 'fr' ? 'Préciser les manques' : 'Specify what is missing'}"
+```
+
+IF "Il manque des éléments" → iterate: collect missing items, update coverageMatrix and globalScope.
+
 ---
 
 ## WRITE & SUMMARY
@@ -758,13 +839,28 @@ ba-writer.enrichSection({
     problem: {from Phase 3, section 4a — Q1.1 answer or refined problem},
     asIs: {from Phase 3, section 4a — Q1.4 answer},
     toBe: {from Phase 3, section 4a — Q1.8 answer},
-    stakeholders: [{from Phase 3, section 4b — each with audience: "internal"|"external"|"shared" if portalMode is "dual"}],
+    stakeholders: [
+      // Shape: {name, role, type: "internal"|"external",
+      //         audience: "internal"|"external"|"shared" (if portalMode="dual"),
+      //         tasks: [], involvement?: "daily"|"weekly"|"monthly",
+      //         frequency?: string, painPoints?: []}
+      // 'involvement', 'frequency', 'painPoints' are OPTIONAL — include when known
+      {from Phase 3, section 4b}
+    ],
     globalScope: {
-      inScope: [{from Phase 3, section 4c + Phase 4 accepted suggestions + coverage matrix}],
-      outOfScope: [{from Phase 3, section 4c — Q2.15 exclusions}]
+      inScope: [
+        // Shape: {feature, priority: "must"|"should"|"could", module, app?}
+        {from Phase 3, section 4c + Phase 4 accepted suggestions + coverage matrix}
+      ],
+      outOfScope: [
+        // Shape: {feature, reason}
+        {from Phase 3, section 4c — Q2.15 exclusions}
+      ]
     },
     applicationRoles: [{from Phase 5, section 6}],
-    errorFlows: [{from Phase 3, section 4c}],
+    smartStackPatterns: {from Phase 4, section 4f — confirmed patterns},
+    anticipatedEvolution: "{from Phase 4, section 4g — changes in 6mo/1yr}",
+    dataRisks: "{from Phase 4, section 4g — business risks if data is incorrect/missing}",
     coverageMatrix: [{from Phase 5, section 7 — with anticipatedSections and anticipatedResources}],
     codebaseContext: "{string summary of codebase findings}"
   }