@atlashub/smartstack-cli 3.13.0 → 3.15.0

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

@@ -1,6 +1,6 @@
 ---
 name: step-01-cadrage
-description: Application/module framing - context, problem, stakeholders, scope, application roles
+description: Application/module framing - listen, reformulate, challenge, anticipate, bound scope
 model: opus
 next_step: steps/step-02-decomposition.md
 ---
@@ -12,21 +12,35 @@ next_step: steps/step-02-decomposition.md
 ## MANDATORY EXECUTION RULES
 
 - ALWAYS use ULTRATHINK mode for this step
-- ALWAYS apply the 5 Elicitation Techniques from `_shared.md`
+- ALWAYS apply the Elicitation Techniques from `_elicitation.md`
 - NEVER accept vague answers — probe deeper
 - NEVER define entities or business rules here — that's per-module in step-03
 - ALL questions via AskUserQuestion tool (NEVER as text dumps)
 - ALL communication in `{language}` (from feature.json.metadata.language)
+- **NEVER skip the reformulation phase** — it is the foundation of good analysis
+- **NEVER auto-infer cadrage data without client validation** — every key decision is confirmed
 
 ## YOUR TASK
 
-Frame the analysis scope at the **application level**: understand the problem, stakeholders, scope, and define application-level roles. This step works for both multi-module applications and single modules.
+Frame the analysis scope at the **application level** through an interactive conversation with the client: understand the problem, stakeholders, scope, and define application-level roles. The analysis phase is ALWAYS interactive — the AI listens, reformulates, challenges, and validates with the user.
 
-**Key difference from old step-01-analyse:** This step does NOT define entities, business rules, or process flows. Those are per-module and handled in step-03.
+**Key difference from step-03:** This step does NOT define entities, business rules, or process flows. Those are per-module and handled in step-03.
 
 ---
 
-## EXECUTION SEQUENCE
+## EXECUTION FLOW — 5 PHASES
+
+```
+Phase 1: ECOUTE           → Read brief + codebase pre-research + silent pre-analysis
+Phase 2: REFORMULATION     → Rephrase the need back to the client for validation
+Phase 3: APPROFONDISSEMENT → Challenge assumptions with targeted questionnaires
+Phase 4: ANTICIPATION      → Suggest unexpressed needs from domain expertise
+Phase 5: PERIMETRE         → Bound scope with roles, coverage matrix (sections + resources)
+```
+
+---
+
+## PHASE 1: ECOUTE (Listen)
 
 ### 1. Read Current State
 
@@ -43,7 +57,7 @@ IF cadrage already completed (status = "framed"):
 
 ### 2. Codebase Pre-Research
 
-> **Same pattern as previous step-01-analyse.** Understand what already exists.
+> **Understand what already exists before engaging the client.**
 
 **Phase 2a: MCP Tools (if available)**
 ```
@@ -70,100 +84,287 @@ Launch 3 agents in parallel:
 Merge findings into {codebase_context}
 ```
 
-### 3. VIBE CODING FLOW (always — 2 lots)
+### 2b. Silent Pre-Analysis (ULTRATHINK — no output to client)
 
-> **The developer IS the product owner, the user, and the builder.**
-> Skip organizational questions (adoption, change management, governance, KPIs).
-> Focus on functional decisions and technical challenges.
-> **Always optimize for high traffic and production-grade performance.**
+> **The AI prepares the conversation before speaking.** This is NOT output — it's internal reasoning.
 
-See [references/cadrage-vibe-coding.md](../references/cadrage-vibe-coding.md) for the 2-lot questionnaire:
-- **Lot 1 (3v):** Problem & Scope — capture core need + must-have features
-- **Lot 2 (4v):** Technical Challenges — risks specific to AI-assisted dev + auto-inferred cadrage data
+Load: [references/cadrage-pre-analysis.md](../references/cadrage-pre-analysis.md)
+
+Analyze `{feature_description}` silently:
+
+1. **Identify problem type** from keywords (replace, automate, centralize, new tool)
+2. **Extract explicit modules/features** mentioned in the description
+3. **Detect shadow zones** — what is NOT said but should be:
+   - Missing stakeholders (who else would use this?)
+   - Missing sections (reports mentioned but no details?)
+   - Implicit relationships (1:1, 1:N — why this cardinality?)
+   - Missing non-functional needs (security, performance, compliance)
+4. **Prepare challenge questions** — specific to this brief, not generic
+5. **Pre-identify anticipated sections and resources** per detected module
+
+Store in `{pre_analysis}` (internal use only, NOT written to feature.json):
+```yaml
+pre_analysis:
+  problem_type: "new_tool|replace|automate|centralize"
+  detected_modules: [{name, description, detected_sections}]
+  shadow_zones: [{topic, why_it_matters, challenge_question}]
+  anticipated_suggestions: [{suggestion, justification, module}]
+```
+
+---
+
+## PHASE 2: REFORMULATION (Rephrase & Validate)
+
+### 3. Reformulation du besoin (MANDATORY — NEVER SKIP)
+
+> **Golden rule of requirements analysis: NEVER proceed without reformulating.**
+> The analyst must prove they understood before digging deeper.
+> This is what distinguishes a professional analysis from a superficial one.
+
+**Process:**
+
+1. From `{feature_description}` and `{pre_analysis}`, build a structured reformulation.
+
+2. **Display as markdown** (direct text output, NOT inside AskUserQuestion):
+
+```
+## {language == "fr" ? "Voici ce que j'ai compris de votre besoin" : "Here is my understanding of your need"}
+
+**Application :** {detected application name}
+**Objectif :** {reformulation in 2-3 sentences of the global need — in the client's own words, not technical jargon}
+
+**Modules identifiés :**
+- **{Module 1}** : {functional description}
+  - Sections pressenties : {list, detail, create, edit...}
+  - Resources clés : {grid, form, card, chart...}
+- **{Module 2}** : {functional description}
+  - Sections pressenties : {list, create...}
+  - Resources clés : {grid, form...}
+
+**Points que j'ai notés :**
+- {specific point 1 from the brief, quoted verbatim when possible}
+- {specific point 2}
+
+**Points qui me semblent ambigus ou non précisés :**
+- {shadow zone 1 — what I don't know yet}
+- {shadow zone 2}
+```
+
+3. Then ask via AskUserQuestion:
+```
+question: "{language == 'fr' ? 'Cette reformulation correspond-elle à votre besoin ?' : 'Does this reformulation match your need?'}"
+header: "Validation"
+options:
+  - label: "{language == 'fr' ? 'Oui, c\'est correct' : 'Yes, correct'}"
+    description: "{language == 'fr' ? 'La reformulation reflète bien mon besoin' : 'The reformulation accurately reflects my need'}"
+  - label: "{language == 'fr' ? 'Partiellement' : 'Partially'}"
+    description: "{language == 'fr' ? 'Certains points sont corrects mais d\'autres à ajuster' : 'Some points are correct but others need adjustment'}"
+  - label: "{language == 'fr' ? 'Non, à revoir' : 'No, needs revision'}"
+    description: "{language == 'fr' ? 'La reformulation ne correspond pas à mon besoin' : 'The reformulation does not match my need'}"
+```
 
-**Users & Permissions:** Always auto-set to Organisation (500+ users) with standard 4-tier roles (Admin, Manager, Contributor, Viewer) and 3 stakeholders. No question needed. Pagination, caching, indexed queries, and async operations are mandatory defaults — not optimizations to discuss.
+4. IF "Partially" or "No":
+   - Ask for corrections via AskUserQuestion (open-ended "Other" option)
+   - Re-reformulate and re-validate (loop until confirmed)
 
-**After Lot 2:** Go directly to **section 9 (Coverage Matrix)**.
+5. Once confirmed, update `{pre_analysis}` with any corrections.
 
 ---
 
-## STANDARD FLOW (full questionnaire — sections 3s through 8s)
+## PHASE 3: APPROFONDISSEMENT (Challenge & Deepen)
+
+### 4. Targeted Questionnaires
+
+> **Principle: Do NOT ask ALL questions from ALL questionnaires.**
+> Select the RELEVANT questions based on the pre-analysis and detected shadow zones.
+> Apply elicitation techniques from `_elicitation.md` after each batch.
+> The goal is a CONVERSATION, not an interrogation.
+
+#### 4a. Business Context (ALWAYS — from `questionnaire/01-context.md`)
+
+> Load the full questionnaire reference for elicitation guides and alert signals.
 
-### 3s. Application-Level Questionnaire (application mode)
+Select the most relevant questions from Q1.1-Q1.12.
+**Mandatory minimum:** Q1.1 (problem), Q1.4 (current tools), Q1.8 (vision), Q1.11 (trigger).
 
-> **Only loaded when workflow.mode = "application"**
+Ask in 1-2 batches via AskUserQuestion (max 4 questions per batch).
 
-Load: `questionnaire/00-application.md`
+Apply ULTRATHINK after each batch:
+- If answer is vague → probe deeper using the elicitation guide from 01-context.md
+- 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
 
-Ask questions in batches of max 4 via AskUserQuestion:
+#### 4b. Stakeholders (ALWAYS — from `questionnaire/02-stakeholders.md`)
 
-**Batch 1 (Q0.1-Q0.2): Application Identity**
-- Application name (PascalCase)
-- Application purpose (1-2 sentences)
+**Mandatory minimum:** Q2.1 (users), Q2.5 (tasks per profile), Q2.9 (access levels).
 
-**Batch 2 (Q0.3-Q0.4): Module Landscape**
-- How many modules envisioned
-- Which are must-have for first release
+Ask in 1-2 batches. After each batch:
+- If only 1 user type mentioned → probe: "Who else interacts? Managers? Admins? External users?"
+- If "everyone sees everything" → challenge: "Even interns? Contractors? Salary data?"
+- If tasks are generic → ask for a concrete scenario: "Walk me through a typical day"
 
-**Batch 3 (Q0.5-Q0.6): Application Roles**
-- Standard 4-tier roles or customize
-- Module-specific role restrictions
+#### 4c. Functional Scope (ALWAYS — from `questionnaire/03-scope.md`)
 
-**Batch 4 (Q0.7-Q0.8): Cross-Module**
-- Business processes spanning modules
-- Default role for new users
+**Mandatory minimum:** Q3.2 (must-have), Q3.4 (exclusions), Q3.5 (main journey).
 
-After each batch: Apply ULTRATHINK + Elicitation Techniques.
+Ask in 1-2 batches. After each batch:
+- If everything is "must-have" → apply priority test: "If you could only keep 3 features, which ones?"
+- 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?"
 
-### 4s. Core Questionnaires (always in standard mode)
+#### 4d. Challenge Implicit Assumptions (CRITICAL)
 
-Load these categories in order. Each questionnaire contains its own batching strategy and elicitation guide.
+> **Apply elicitation techniques to challenge what the client considers "obvious".**
+> This is what separates a deep analysis from a shallow one.
 
-**Categorie 01 - Contexte metier** (`questionnaire/01-context.md`)
-- Q1.1-Q1.12 : Probleme, situation actuelle, vision, declencheur
-- 3 lots AskUserQuestion (probleme, processus actuel, vision et urgence)
-- ULTRATHINK : Identifier la douleur reelle, pas la solution imaginee
+For EACH specific point from the brief, prepare a targeted challenge question.
 
-**Categorie 02 - Parties prenantes** (`questionnaire/02-stakeholders.md`)
-- Q2.1-Q2.14 : Utilisateurs, taches, acces, conduite du changement
-- 4 lots AskUserQuestion
-- ULTRATHINK : Mapper les parties prenantes vers les profils d'acces
+**Rules for challenge questions:**
+1. Identify the assumption (what the client stated as fact)
+2. Formulate a "what if the opposite?" question
+3. Use Technique 4 (absence test) or Technique 7 (contradiction test)
 
-**Categorie 03 - Perimetre fonctionnel** (`questionnaire/03-scope.md`)
-- Q3.1-Q3.12 : Priorites (indispensable/important/optionnel/hors perimetre), parcours, besoins transversaux
-- 3 lots AskUserQuestion
-- ULTRATHINK : S'assurer que le perimetre couvre les besoins identifies
+**Examples by domain pattern:**
 
-**Categorie 14 - Risques et hypotheses** (`questionnaire/14-risk-assumptions.md`)
-- Q14.1-Q14.8 : Risques, hypotheses non verifiees, lecons du passe
-- 2 lots AskUserQuestion
-- TOUJOURS charge (noyau) - ne jamais sauter cette categorie
+| Brief statement | Implicit assumption | Challenge question |
+|----------------|--------------------|--------------------|
+| "Entities are 1:1 extensions of X" | Cardinality is always 1:1 | "Can a user be linked to multiple employee records (temp contracts, part-time multi-position)? Can an employee NOT have a user account?" |
+| "Entry split into activity and absence" | Binary decomposition is sufficient | "What granularity? Day, half-day, hour? Are activities linked to projects or clients? Are there other entry types (training, travel, on-call)?" |
+| "A reports section" | Reports are a simple addition | "Which reports exactly? For whom? How often? PDF/Excel export? Real-time dashboards? Aggregated or detailed?" |
+| "Module X manages Y" | The scope of "manages" is clear | "What does 'manage' mean concretely? Create, read, update, delete? Approve? Archive? Import/export?" |
 
-**Categorie 15 - Criteres de reussite** (`questionnaire/15-success-metrics.md`)
-- Q15.1-Q15.8 : Definition du succes, objectifs mesurables, conditions d'acceptation
-- 2 lots AskUserQuestion
-- TOUJOURS charge (noyau) - ne jamais sauter cette categorie
+Use these techniques:
+- **Technique 3** (concrete scenario): "Walk me through a typical day of [role] using this module"
+- **Technique 4** (absence test): "If [feature] didn't exist, how would you handle it?"
+- **Technique 8** (impact escalation): "With 50 records this works, but with 500? 5000? Does the process stay the same?"
 
-### 5s. Conditional Questionnaires
+Ask challenge questions via AskUserQuestion (1-2 batches of max 4).
 
-Based on feature description analysis, load additional categories:
+#### 4d-bis. Entity Sourcing Pattern (MANDATORY for detected dependencies)
 
-| Condition | Categorie | Questionnaire |
-|-----------|-----------|---------------|
-| Securite ou conformite mentionnee | 06 | `questionnaire/06-security.md` |
-| Integration avec des systemes externes | 05 | `questionnaire/05-integrations.md` |
-| Exigences de performance | 08 | `questionnaire/08-performance.md` |
-| Contraintes techniques | 09 | `questionnaire/09-constraints.md` |
-| Besoins de documentation | 10 | `questionnaire/10-documentation.md` |
+> **When the analysis detects a referenced entity/concept (e.g., "Projets" referenced by activities, "Clients" referenced by orders), ALWAYS ask how this entity is sourced.**
+> This question detects potential new modules that were not mentioned in the original brief.
+
+For EACH referenced entity/concept detected during phases 2-4 that is NOT already covered by an identified module:
+
+Ask via AskUserQuestion:
+```
+question: "{language == 'fr'
+  ? 'Les {entity_plural} auxquel(le)s les {parent_entity_plural} sont lié(e)s : comment sont-ils gérés ?'
+  : 'The {entity_plural} that {parent_entity_plural} are linked to: how are they managed?'}"
+header: "{entity_name}"
+options:
+  - label: "{language == 'fr' ? 'Gérés dans l\'app' : 'Managed in app'}"
+    description: "{language == 'fr'
+      ? 'Les {entity_plural} sont créés et gérés dans cette application (liste simple)'
+      : '{entity_plural} are created and managed in this application (simple list)'}"
+  - label: "{language == 'fr' ? 'Nouveau module dédié' : 'New dedicated module'}"
+    description: "{language == 'fr'
+      ? 'Les {entity_plural} méritent leur propre module avec CRUD complet, permissions et navigation'
+      : '{entity_plural} deserve their own module with full CRUD, permissions and navigation'}"
+  - label: "{language == 'fr' ? 'Système externe' : 'External system'}"
+    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' ? 'Liste simple en config' : 'Simple config list'}"
+    description: "{language == 'fr'
+      ? 'Juste une liste configurable par l\'admin, pas un module complet'
+      : 'Just a configurable list managed by admin, not a full module'}"
+```
 
-> **Categories 04 (donnees), 07 (interface), 11 (cycle de vie), 12 (migration), 13 (inter-modules) sont par module et chargees dans step-03.**
+**Processing each answer:**
+
+| Choice | Action |
+|--------|--------|
+| **Gérés dans l'app** | Entity stays as a child/section of the current module. Note in coverageMatrix. |
+| **Nouveau module dédié** | **Add new module to `{pre_analysis}.detected_modules[]`**. Flag for inclusion in decomposition (step-02). Add to `coverageMatrix` as mustHave with anticipated sections (list, detail, create, edit). This module becomes a dependency of the referencing module. |
+| **Système externe** | Flag for integration specification. Add to `coverageMatrix` as integration. Load `questionnaire/05-integrations.md` if not already loaded. |
+| **Liste simple en config** | Entity becomes a lookup/reference table (no dedicated module). Note in coverageMatrix as config data. |
+
+> **CRITICAL:** The "Nouveau module dédié" option is essential for detecting modules not mentioned in the original brief. Without it, complex entities get reduced to simple config lists when they deserve full CRUD management.
+
+#### 4e. Risks & Success Criteria (ALWAYS — from `questionnaire/14-risk-assumptions.md` and `questionnaire/15-success-metrics.md`)
+
+Select the most pertinent questions:
+- **14-risk-assumptions.md:** Q14.1 (identified risks), Q14.4 (unvalidated assumptions)
+- **15-success-metrics.md:** Q15.1 (success definition), Q15.4 (measurable objectives)
+
+Ask in 1 batch via AskUserQuestion.
+
+#### 4f. Conditional Deep-Dives
+
+Based on brief analysis, load additional categories if relevant:
+
+| Condition | Category | Questionnaire |
+|-----------|----------|---------------|
+| Security or compliance mentioned | 06 | `questionnaire/06-security.md` |
+| External system integration | 05 | `questionnaire/05-integrations.md` |
+| Performance requirements | 08 | `questionnaire/08-performance.md` |
+| Technical constraints | 09 | `questionnaire/09-constraints.md` |
+| Documentation needs | 10 | `questionnaire/10-documentation.md` |
+
+> **Categories 04 (data), 07 (UI), 11 (lifecycle), 12 (migration), 13 (cross-module) are per-module and loaded in step-03.**
+
+---
 
-### 6s. Application Roles Definition
+## PHASE 4: ANTICIPATION (Suggest Unexpressed Needs)
+
+### 5. Proactive Suggestions
+
+> **An expert analyst doesn't just capture what is said.**
+> They anticipate what the client hasn't thought to ask for.
+
+**Process:**
+
+1. Load: `patterns/suggestion-catalog.md`
+2. Match suggestion patterns against the project context (domain, modules, features)
+3. Add implicit needs for this type of system that weren't mentioned
+
+4. **Display as markdown** (direct text, NOT inside AskUserQuestion):
+
+```
+## {language == "fr" ? "Besoins complémentaires que je vous suggère" : "Complementary needs I suggest"}
+
+{language == "fr"
+  ? "D'après mon analyse de votre besoin, voici des aspects que vous n'avez peut-être pas mentionnés mais qui sont souvent nécessaires pour ce type d'application :"
+  : "Based on my analysis of your need, here are aspects you may not have mentioned but that are often necessary for this type of application:"}
+
+| # | Suggestion | Justification | Module concerné |
+|---|-----------|---------------|-----------------|
+| 1 | {suggestion} | {why it's relevant for THIS project} | {module} |
+| 2 | {suggestion} | {why} | {module} |
+| 3 | {suggestion} | {why} | {module} |
+| ... | ... | ... | ... |
+```
+
+5. Then ask via AskUserQuestion (multiSelect: true):
+```
+question: "{language == 'fr' ? 'Quelles suggestions souhaitez-vous inclure dans le périmètre ?' : 'Which suggestions would you like to include in scope?'}"
+header: "Suggestions"
+multiSelect: true
+options:
+  - label: "{suggestion 1 short name}"
+    description: "{justification in 1 sentence}"
+  - label: "{suggestion 2 short name}"
+    description: "{justification in 1 sentence}"
+  - label: "{suggestion 3 short name}"
+    description: "{justification in 1 sentence}"
+  - label: "{language == 'fr' ? 'Aucune' : 'None'}"
+    description: "{language == 'fr' ? 'Je n\'ai pas besoin de ces suggestions' : 'I don\'t need any of these suggestions'}"
+```
+
+6. Accepted suggestions enrich `coverageMatrix` and `globalScope`.
+
+---
+
+## PHASE 5: PERIMETRE (Bound Scope)
+
+### 6. Application Roles Definition
 
 > **Define roles at the APPLICATION level, not per-module.**
 
-IF application mode AND roles not yet defined from Q0.5:
-  Propose the standard 4-tier roles:
+Propose the standard 4-tier roles:
 
 ```
 Application Roles for {application_name}:
@@ -178,102 +379,152 @@ Application Roles for {application_name}:
 
 Ask via AskUserQuestion:
 ```
-question: "Ces 4 rôles conviennent-ils pour {application_name} ?"
+question: "{language == 'fr' ? 'Ces 4 rôles conviennent-ils pour votre application ?' : 'Do these 4 roles suit your application?'}"
 header: "Rôles"
 options:
-  - label: "Oui, parfait"
-    description: "Utiliser les 4 rôles standards tels quels"
-  - label: "Renommer"
-    description: "Garder 4 niveaux mais personnaliser les noms"
-  - label: "Personnaliser"
-    description: "Modifier le nombre ou les permissions des rôles"
+  - label: "{language == 'fr' ? 'Oui, parfait' : 'Yes, perfect'}"
+    description: "{language == 'fr' ? 'Utiliser les 4 rôles standards tels quels' : 'Use the 4 standard roles as-is'}"
+  - label: "{language == 'fr' ? 'Renommer' : 'Rename'}"
+    description: "{language == 'fr' ? 'Garder 4 niveaux mais personnaliser les noms' : 'Keep 4 levels but customize names'}"
+  - label: "{language == 'fr' ? 'Personnaliser' : 'Customize'}"
+    description: "{language == 'fr' ? 'Modifier le nombre ou les permissions des rôles' : 'Modify number or permissions of roles'}"
 ```
 
 IF single-module mode:
   Same role definition but inferred from stakeholders
 
-### 7s. Proactive Suggestions
+### 6b. Table Prefix Definition (MANDATORY)
 
-> **Same pattern as previous step-01.** Load suggestion catalog.
+> **Every business application MUST define a table prefix.**
+> This prefix identifies which application a database table belongs to (e.g., `rh_Employees`, `fi_Invoices`).
 
-Load: `patterns/suggestion-catalog.md`
+**Process:**
 
-1. Analyze scope items and stakeholder needs
-2. Match against catalog patterns
-3. Present top 3-4 suggestions via AskUserQuestion (multiSelect: true)
-4. Store accepted suggestions in `suggestions[]`
+1. Derive a suggested prefix from the application name:
+   - Use the most recognizable abbreviation (2-5 lowercase letters + `_`)
+   - Examples: HumanResources → `rh_`, SalesManagement → `sales_`, Finance → `fi_`, CRM → `crm_`
 
-### 8s. Risk Analysis
+2. **Display as markdown** (direct text output):
 
-Ask via AskUserQuestion:
 ```
-question: "Quels sont les principaux risques pour ce projet ?"
-header: "Risques"
-multiSelect: true
+{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`"}
+```
+
+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"
 options:
-  - label: "Adoption utilisateur"
-    description: "Risque que les utilisateurs n'adoptent pas le système"
-  - label: "Qualité des données"
-    description: "Données existantes incomplètes ou incohérentes à migrer"
-  - label: "Dépendances techniques"
-    description: "Dépendance à des systèmes externes ou des APIs"
-  - label: "Complexité fonctionnelle"
-    description: "Règles métier complexes ou mal documentées"
+  - label: "{language == 'fr' ? 'Oui, parfait' : 'Yes, perfect'}"
+    description: "{language == 'fr' ? 'Utiliser le préfixe suggéré' : 'Use the suggested prefix'}"
+  - 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 + _)'}"
 ```
 
-Classify per probability/impact:
-- High/High → Critical (mitigation required)
-- High/Low or Low/High → Medium (monitor)
-- Low/Low → Low (accept)
+4. IF "Customize" → ask for custom prefix via AskUserQuestion (open-ended "Other" option)
 
----
+5. **Validate the prefix:**
+   - Format: `^[a-z]{2,5}_$` (2-5 lowercase letters followed by underscore)
+   - Must NOT collide with platform prefixes: `auth_`, `nav_`, `usr_`, `ai_`, `cfg_`, `wkf_`, `support_`, `entra_`, `ref_`, `loc_`, `lic_`, `tenant_`
+   - If collision detected → ask the user to choose another prefix
+
+6. Store in `metadata.tablePrefix`
 
-## COMMON FLOW (both modes rejoin here)
+### 7. Coverage Matrix with Sections & Resources (MANDATORY)
 
-### 9. Coverage Matrix (MANDATORY)
+> **ENRICHMENT: The coverage matrix now includes anticipated sections (Level 4) and resources (Level 5).**
+> This gives downstream steps (step-02, step-03) a concrete starting point.
 
 BEFORE transitioning to step-02:
 
 1. Re-read the original prompt/brief in its entirety
-2. For EACH distinct feature/requirement mentioned:
-   a. Create an entry in cadrage.coverageMatrix[]
+2. Re-read ALL answers collected during phases 2-4
+3. For EACH distinct feature/requirement identified:
+   a. Create an entry in `cadrage.coverageMatrix[]`
    b. Assign it to mustHave, shouldHave, couldHave, or outOfScope
    c. Assign the module that will cover it (or null if cross-cutting)
-3. Present the matrix to the client:
-   "Voici la matrice de couverture de votre brief. {N} fonctionnalités identifiées :"
-   (show as markdown table)
-4. Ask: "Y a-t-il des éléments que j'ai oublié ou mal classé ?"
-5. Iterate until the client confirms
+   d. **List anticipated sections** (Level 4) based on module type and feature needs
+   e. **List anticipated resources** (Level 5) for each section
+
+4. **OUTPUT the matrix as text** (do NOT put it inside AskUserQuestion — it won't render):
+
+Print a markdown table with columns: **Fonctionnalité | Priorité | Module | Sections pressenties | Resources clés**
+
+Example:
+```
+{language == "fr"
+  ? "Voici la matrice de couverture enrichie. J'ai identifié {N} fonctionnalités :"
+  : "Here is the enriched coverage matrix. I identified {N} features:"}
+
+| Fonctionnalité | Priorité | Module | Sections pressenties | Resources clés |
+|---|---|---|---|---|
+| Gestion des employés | mustHave | Employees | list, detail, create, edit | employee-grid, employee-form, employee-card |
+| Saisie d'activités | mustHave | TimeTracking | list, create, edit | activity-grid, activity-form |
+| Saisie d'absences | mustHave | TimeTracking | list, create | absence-grid, absence-form, absence-calendar |
+| Rapports temps | mustHave | TimeTracking | dashboard, export | time-summary-chart, time-export-panel |
+| Soldes de congés | shouldHave | TimeTracking | detail | leave-balance-card |
+```
+
+5. **THEN** (after the table is displayed) ask via AskUserQuestion:
+```
+question: "{language == 'fr' ? 'Cette matrice de couverture vous convient-elle ?' : 'Does this coverage matrix suit you?'}"
+header: "Couverture"
+options:
+  - label: "{language == 'fr' ? 'Oui, parfait' : 'Yes, perfect'}"
+    description: "{language == 'fr' ? 'La classification et les sections sont correctes' : 'Classification and sections are correct'}"
+  - label: "{language == 'fr' ? 'Ajouter des éléments' : 'Add items'}"
+    description: "{language == 'fr' ? 'Il manque des fonctionnalités ou des sections' : 'Missing features or sections'}"
+  - label: "{language == 'fr' ? 'Réajuster' : 'Readjust'}"
+    description: "{language == 'fr' ? 'Modifier les priorités, modules ou sections' : 'Change priorities, modules, or sections'}"
+```
 
-**VALIDATION:** Every line of the original prompt must map to at least one coverageMatrix entry.
-If a feature is in mustHave → it MUST have at least one UC in the corresponding module (verified in step-03).
+6. Iterate until the client confirms.
 
-### 10. Write Cadrage to Feature.json
+**VALIDATION:**
+- Every line of the original prompt must map to at least one coverageMatrix entry.
+- If a feature is in mustHave → it MUST have at least one anticipated section.
+- Accepted suggestions from Phase 4 must appear in the matrix.
 
-Use ba-writer to enrich master feature.json. **Follow the STRUCTURE CARDS below exactly.**
+---
+
+## WRITE & SUMMARY
+
+### 8. Write Cadrage to Feature.json
+
+Use ba-writer to enrich master feature.json. **Follow the STRUCTURE CARDS exactly.**
 
 See [references/cadrage-structure-cards.md](../references/cadrage-structure-cards.md) for exact JSON formats of: `stakeholders[]`, `applicationRoles[]`, `risks[]`, `acceptanceCriteria[]`, `coverageMatrix[]`, `codebaseContext`.
 
 ```
+ba-writer.enrichSection({
+  featureId: {feature_id},
+  section: "metadata",
+  data: {
+    tablePrefix: "{from Phase 5, section 6b — validated prefix, e.g., rh_}"
+  }
+})
+
 ba-writer.enrichSection({
   featureId: {feature_id},
   section: "cadrage",
   data: {
-    problem: {Q1.1 answer},
-    asIs: {Q1.2 answer},
-    toBe: {Q1.3 answer},
-    trigger: {Q1.4 answer},
-    stakeholders: [{mapped from Q2.x — use STRUCTURE CARD format}],
+    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},
+    trigger: {from Phase 3, section 4a — Q1.11 answer},
+    stakeholders: [{from Phase 3, section 4b — use STRUCTURE CARD format}],
     globalScope: {
-      mustHave: [{from Q3.x}],
-      shouldHave: [{from Q3.x}],
-      couldHave: [{from Q3.x}],
-      outOfScope: [{from Q3.x}]
+      mustHave: [{from Phase 3, section 4c + Phase 4 accepted suggestions}],
+      shouldHave: [{from coverage matrix}],
+      couldHave: [{from coverage matrix}],
+      outOfScope: [{from Phase 3, section 4c — Q3.4 exclusions}]
     },
-    applicationRoles: [{from section 6 — use STRUCTURE CARD format}],
-    risks: [{from section 8 — use STRUCTURE CARD format}],
-    acceptanceCriteria: [{derived from scope — use STRUCTURE CARD format}],
-    coverageMatrix: [{from section 9 — use STRUCTURE CARD format}],
+    applicationRoles: [{from Phase 5, section 6 — use STRUCTURE CARD format}],
+    risks: [{from Phase 3, section 4e — use STRUCTURE CARD format}],
+    acceptanceCriteria: [{from Phase 3, section 4e — use STRUCTURE CARD format}],
+    coverageMatrix: [{from Phase 5, section 7 — use STRUCTURE CARD format with anticipatedSections and anticipatedResources}],
     codebaseContext: "{string summary of codebase findings}"
   }
 })
@@ -281,7 +532,7 @@ ba-writer.enrichSection({
 ba-writer.updateStatus({feature_id}, "framed")
 ```
 
-### 11. Display Summary
+### 9. Display Summary
 
 ```
 ## Cadrage Complete - {feature_id}
@@ -293,10 +544,14 @@ ba-writer.updateStatus({feature_id}, "framed")
 | Application roles | {count} |
 | Risks identified | {count} |
 | Suggestions accepted | {count} |
+| Anticipated sections | {total across all modules} |
 
 ### Application Roles
 {table of roles with permission levels}
 
+### Coverage Highlights
+{top 3-5 must-have items with their anticipated sections}
+
 ### Next Step
 → Module decomposition (step-02-decomposition.md)
 ```