@atlashub/smartstack-cli 4.18.0 → 4.19.0

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

@@ -2,10 +2,10 @@
 name: step-01-cadrage
 description: Application/module framing - listen, reformulate, challenge, anticipate, bound scope
 model: opus
-next_step: steps/step-01b-applications.md
+next_step: steps/step-02-structure.md
 ---
 
-> **Context files:** `_shared.md` | `_elicitation.md` | `_architecture.md` | `_suggestions.md`
+> **Context files:** `_shared.md`
 > **Reference (4d-bis):** `references/entity-architecture-decision.md` — Entity scoring, domain coherence, section patterns
 
 # Step 1: Cadrage (Framing)
@@ -13,11 +13,11 @@ next_step: steps/step-01b-applications.md
 ## MANDATORY EXECUTION RULES
 
 - ALWAYS use ULTRATHINK mode for this step
-- ALWAYS apply the Elicitation Techniques from `_elicitation.md`
+- ALWAYS apply the Elicitation Techniques from `_shared.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)
+- ALL communication in `{language}` (from index.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
 
@@ -41,36 +41,19 @@ Phase 5: PERIMETRE         → Bound scope with roles, coverage matrix (sections
 
 ---
 
-## PROJECT vs APPLICATION MODE
-
-> **When `workflow_mode = "project"` (detected in step-00 from prompt structure):**
-> The cadrage operates at the **PROJECT level**, not at a single application level.
-> - Phase 1-3: Gather requirements for the ENTIRE project (all applications combined)
-> - Phase 4: ANTICIPATION analyzes cross-application shared modules and suggests extracting them as dedicated applications
-> - Phase 5: Coverage matrix maps requirements to APPLICATIONS first, then modules within each application
-> - `candidate_applications` from step-00 are used as starting structure (can be modified during cadrage)
->
-> **When `workflow_mode = "application"` (single-app):**
-> The cadrage operates at the application level as before.
-
 ## PHASE 1: ECOUTE (Listen)
 
 ### 1. Read Current State
 
 ```
-IF workflow_mode === "project":
-  ba-reader.findProjectFeature({project_id})
-  → Read metadata: projectName, language, candidateApplications
-  → Read cadrage section (if resuming)
-ELSE:
-  ba-reader.findFeature({feature_id})
-  → Read metadata: application, language, workflow.mode, useCase
-  → Read cadrage section (if resuming)
+ba-reader.findFeature({feature_id})
+→ Read metadata: application, language, workflow.mode, useCase
+→ Read cadrage section (if resuming)
 ```
 
 IF cadrage already completed (status = "framed"):
   Display: "Cadrage already completed. Loading next step."
-  Load: steps/step-02-decomposition.md
+  Load: steps/step-02-structure.md
   STOP
 
 ### 2. Codebase Pre-Research
@@ -98,7 +81,7 @@ Launch 4 agents in parallel:
   Agent 1: Search for existing domain entities (Glob: **/Domain/**/*.cs)
   Agent 2: Search for existing services/integrations (Grep: IService, IRepository)
   Agent 3: Search for existing page patterns (Glob: **/pages/**/*.tsx)
-  Agent 4: Scan existing BA documentation (Glob: docs/**/business-analyse/**/feature.json)
+  Agent 4: Scan existing BA documentation (Glob: docs/**/business-analyse/**/index.json)
            → For each found file: read metadata.application, metadata.module, status, modules[].code
            → Also scan: docs/**/*.md (ERD, guides, specs)
 
@@ -111,7 +94,7 @@ Merge findings into {codebase_context}
 > This prevents re-specifying what already exists and surfaces integration constraints early.
 
 ```
-IF Agent 4 found existing feature.json files:
+IF Agent 4 found existing index.json files:
   For each file found:
     → Extract: application, modules[], entities[], status, version
     → Store as {existing_ba_context}: list of existing applications with their modules and key entities
@@ -123,16 +106,14 @@ IF docs/**/*.md files found:
   → Store relevant findings in {codebase_context}
 ```
 
-**Use in pre-analysis (§2b):**
+**Use in pre-analysis:**
 - Cross-reference detected modules against `{existing_ba_context}` — flag modules that already exist
 - 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
 
 ### 2b. Silent Pre-Analysis (ULTRATHINK — no output to client)
 
-> **The AI prepares the conversation before speaking.** This is NOT output — it's internal reasoning.
-
-Load: [references/cadrage-pre-analysis.md](../references/cadrage-pre-analysis.md)
+> **The AI prepares the conversation before speaking. This is NOT output — it's internal reasoning.**
 
 Analyze `{feature_description}` silently:
 
@@ -146,7 +127,7 @@ Analyze `{feature_description}` silently:
 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):
+Store in `{pre_analysis}` (internal use only, NOT written to index.json):
 ```yaml
 pre_analysis:
   problem_type: "new_tool|replace|automate|centralize"
@@ -222,7 +203,7 @@ options:
 
 > **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.
+> 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`)
@@ -240,7 +221,7 @@ Apply ULTRATHINK after each 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.md`)
+#### 4b. Stakeholders (ALWAYS — from `questionnaire/02-stakeholders-scope.md`)
 
 **Mandatory minimum:** Q2.1 (users), Q2.5 (tasks per profile), Q2.9 (access levels).
 
@@ -249,7 +230,7 @@ Ask in 1-2 batches. After each batch:
 - 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"
 
-#### 4c. Functional Scope (ALWAYS — from `questionnaire/03-scope.md`)
+#### 4c. Functional Scope (ALWAYS — from `questionnaire/02-stakeholders-scope.md`)
 
 **Mandatory minimum:** Q3.2 (must-have), Q3.4 (exclusions), Q3.5 (main journey).
 
@@ -270,16 +251,15 @@ Ask in 1-2 batches. After each batch:
 > { "scenario": "...", "trigger": "...", "notification": "...", "recovery": "rollback|partial|manual" }
 > ```
 >
-> These error flows become **Business Rules** in step-03a2 (BR-WF category: workflow/guard conditions).
-
+> These error flows become **Business Rules** in step-03 (BR-WF category: workflow/guard conditions).
+>
 > **BLOCKING RULE — MoSCoW DISTRIBUTION:**
 > If the client classifies ALL features as "must-have", you MUST challenge this BEFORE proceeding.
-> **Reference:** Load `references/cadrage-challenge-patterns.md` § "MoSCoW Prioritization Template" for the exact question format.
 > If client moves items → update categories. If client confirms ALL mustHave → accept but log in changelog.
 
 #### 4d. Challenge Implicit Assumptions (CRITICAL)
 
-> **Reference:** Load `references/cadrage-challenge-patterns.md` for domain-specific patterns and elicitation techniques.
+> **Load reference material from `_shared.md` for domain-specific patterns and elicitation techniques.**
 
 Apply elicitation techniques to challenge what the client considers "obvious".
 This is what separates a deep analysis from a shallow one.
@@ -456,44 +436,42 @@ options:
 |--------|--------|
 | **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 mustHave. The `list` section is ALWAYS the main section. Additional sections ONLY for distinct functional zones (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/05-integrations.md` if not already loaded. |
+| **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. Risks & Success Criteria (ALWAYS — from `questionnaire/14-risk-assumptions.md` and `questionnaire/15-success-metrics.md`)
+#### 4e. Risks & Success Criteria (ALWAYS — from `questionnaire/04-risks-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)
+- **04-risks-metrics.md:** Risk identification, assumptions validation
+- **04-risks-metrics.md:** Success definition, measurable objectives
 
 Ask in 1 batch via AskUserQuestion.
 
 #### 4f. Conditional Deep-Dives
 
-Based on brief analysis, load additional categories if relevant:
+Based on brief analysis, load additional materials 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` |
+| 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 |
 
-> **Categories 04 (data), 07 (UI), 11 (lifecycle), 12 (migration), 13 (cross-module) are per-module and loaded in step-03.**
-
-#### 4g. Documentation Needs (ALWAYS — from `questionnaire/10-documentation.md`)
+#### 4g. Documentation Needs (ALWAYS — from `questionnaire/03-data-ui.md`)
 
 > **Every application requires documentation decisions made upfront, not as an afterthought.**
-> Load `questionnaire/10-documentation.md` unconditionally — 7 questions, mandatory minimum 2 (Q10.1 + Q10.2).
+> Load relevant documentation section from questionnaire/03-data-ui.md
 
 Ask in 1 batch via AskUserQuestion (max 3 questions):
-- Q10.1: Will users need documentation (guide, FAQ, in-app tooltips)?
-- Q10.2: Is technical documentation required (API docs, ERD, developer guide)?
-- Q10.3: Who is responsible for maintaining documentation after delivery?
+- Will users need documentation (guide, FAQ, in-app tooltips)?
+- Is technical documentation required (API docs, ERD, developer guide)?
+- Who is responsible for maintaining documentation after delivery?
 
 After the batch:
-- If "Non" to Q10.1 AND Q10.2 → probe: "Pas même les docs API ou un guide d'accueil pour les nouveaux utilisateurs ?"
+- If "Non" to both → probe: "Pas même les docs API ou un guide d'accueil pour les nouveaux utilisateurs ?"
 - If "Oui" without detail → ask format: "Tooltips intégrés ? Guide PDF ? Wiki ? Portail dédié ?"
 - If "La doc se fera après" → challenge: "La documentation est planifiée maintenant et générée par `/documentation` après `/ralph-loop`. Quel niveau souhaitez-vous ?"
 
@@ -507,7 +485,7 @@ After the batch:
 }
 ```
 
-This feeds directly into handoff step-05a category `documentation` in `filesToCreate`.
+This feeds directly into handoff step-05 category `documentation` in `filesToCreate`.
 
 ---
 
@@ -520,7 +498,7 @@ This feeds directly into handoff step-05a category `documentation` in `filesToCr
 
 **Process:**
 
-1. Load: `patterns/suggestion-catalog.md`
+1. Load pattern guidance from `_shared.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
 
@@ -559,21 +537,6 @@ options:
 
 6. Accepted suggestions enrich `coverageMatrix` and `globalScope`.
 
-### 5b. Cross-Application Shared Module Detection (PROJECT MODE ONLY)
-
-> **When `workflow_mode = "project"`, analyze candidate applications for shared modules.**
-> A module that appears in 2+ applications should be extracted as a dedicated transversal application.
-
-**This section is SKIPPED if `workflow_mode !== "project"`.**
-
-**Reference:** Load `references/cadrage-shared-modules.md` for detection algorithm, extraction logic, and question template.
-
-The detection process:
-1. Build module inventory per candidate application
-2. Detect modules appearing in 2+ applications
-3. Propose extraction to user with the template from the reference
-4. IF "Yes" → Extract and update `candidate_applications` in the project feature.json
-
 ---
 
 ## PHASE 5: PERIMETRE (Bound Scope)
@@ -608,9 +571,6 @@ options:
     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
-
 ### 6b. Table Prefix Definition (MANDATORY)
 
 > **Every business application MUST define a table prefix.**
@@ -652,8 +612,6 @@ options:
 
 ### 7. Coverage Matrix with Sections & Resources (MANDATORY)
 
-> **Reference:** Load `references/cadrage-coverage-matrix.md` for complete coverage matrix building and validation rules.
-
 **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.
 
@@ -699,49 +657,40 @@ BEFORE transitioning to step-02:
 
 7. Iterate until the client confirms
 
-**The reference file includes:**
-- Section rule clarification (list, detail, create, edit, dashboard, etc.)
-- Priority distribution POST-CHECK (BLOCKING)
-- Cross-cutting coverage POST-CHECK (WARNING)
-
 ---
 
 ## 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`.
+Use ba-writer with granular JSON approach. Write to `cadrage.json` section:
 
 ```
-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",
+  subsection: "cadrage.json",
   data: {
+    metadata: {
+      tablePrefix: "{from Phase 5, section 6b — validated prefix, e.g., rh_}"
+    },
     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}],
+    stakeholders: [{from Phase 3, section 4b}],
     globalScope: {
       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 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}],
+    applicationRoles: [{from Phase 5, section 6}],
+    errorFlows: [{from Phase 3, section 4c}],
+    risks: [{from Phase 3, section 4e}],
+    acceptanceCriteria: [{from Phase 3, section 4e}],
+    coverageMatrix: [{from Phase 5, section 7 — with anticipatedSections and anticipatedResources}],
+    documentation: {from Phase 3, section 4g},
     codebaseContext: "{string summary of codebase findings}"
   }
 })
@@ -749,82 +698,7 @@ ba-writer.enrichSection({
 ba-writer.updateStatus({feature_id}, "framed")
 ```
 
-### 9. Multi-Application Detection
-
-> **Analyze whether the project spans multiple independent applications.**
-> **SKIP this section entirely if `workflow_mode = "project"`** — multi-app was already detected in step-00
-> and cross-app analysis was done in section 5b above.
-
-**IF `workflow_mode === "project"`:**
-→ SKIP section 9 entirely. Candidate applications are already identified and enriched.
-→ Write cadrage data to project-level feature.json:
-```
-ba-writer.enrichSection({
-  projectId: {project_id},
-  section: "cadrage",
-  data: {cadrage data collected in phases 1-5 above}
-})
-```
-→ Continue to section 10 (summary).
-
-**IF `workflow_mode === "application"` (single-app mode):**
-
-After coverage matrix is validated, check if the identified functional domains suggest multiple applications:
-
-**Detection triggers (ANY of these = suggest multi-app):**
-- Coverage matrix entries reference different application scopes (administration, support, myspace, etc.)
-- User mentioned "multiple applications", "several apps", "cross-platform"
-- Functional domains form clearly independent applications with separate user bases
-- Stakeholders only interact with specific domains (not shared across all)
-
-**IF detection triggers matched:**
-
-Display analysis as markdown:
-```
-{language == "fr"
-  ? "### Analyse multi-application\n\nD'après mon analyse, ce projet couvre plusieurs domaines fonctionnels qui pourraient former des applications indépendantes :\n\n"
-  : "### Multi-Application Analysis\n\nBased on my analysis, this project spans multiple functional domains that could form independent applications:\n\n"}
-
-| Domain | Suggested Application | Key Modules |
-|--------|----------------------|-------------|
-{for each identified domain: domain name | PascalCase name | top modules}
-```
-
-Ask via AskUserQuestion:
-```
-question: "{language == 'fr' ? 'Ce projet constitue-t-il une seule application ou plusieurs applications distinctes ?' : 'Is this a single application or multiple independent applications?'}"
-header: "Architecture"
-options:
-  - label: "{language == 'fr' ? 'Application unique' : 'Single application'}"
-    description: "{language == 'fr' ? 'Tous les domaines forment une seule application avec plusieurs modules' : 'All domains form one application with multiple modules'}"
-  - label: "{language == 'fr' ? 'Applications multiples' : 'Multiple applications'}"
-    description: "{language == 'fr' ? 'Chaque domaine est une application indépendante (navigation, rôles et préfixe de table séparés)' : 'Each domain is an independent application (separate navigation, roles, and table prefix)'}"
-```
-
-**IF "Multiple applications":**
-1. Create project-level feature.json:
-```
-ba-writer.createProjectFeature({
-  metadata: {
-    projectName: {project_name derived from feature_description},
-    language: {language},
-    featureDescription: {feature_description},
-    candidateApplications: [{detected candidates}]
-  },
-  cadrage: {cadrage data already collected in this step}
-})
-```
-2. Set `workflow_mode = "project"` and `project_id = PROJ-NNN`
-3. Load `questionnaire/00b-project.md` for additional project-level questions
-4. Continue to section 10 and then step-01b
-
-**IF "Single application":**
-→ Continue to step 10 (display summary) and step-02 as usual.
-
-**IF no detection triggers matched:**
-→ Skip this section entirely — continue to step 10 (display summary).
-
-### 10. Display Summary
+### 9. Display Summary
 
 ```
 ## Cadrage Complete - {feature_id}
@@ -845,13 +719,13 @@ ba-writer.createProjectFeature({
 {top 3-5 must-have items with their anticipated sections}
 
 ### Next Step
-→ Module decomposition (step-02-decomposition.md)
+→ Module structure analysis (step-02-structure.md)
 ```
 
 ---
 
 ## NEXT STEP
 
-Load: `./step-01b-applications.md`
+Load: `./step-02-structure.md`
 
-> step-01b handles both single-app (lightweight identity confirmation) and multi-app (full application decomposition).
+> step-02 handles module structure analysis and entity/section definition.

package/templates/skills/business-analyse/steps/step-02-structure.md

@@ -0,0 +1,175 @@
+---
+name: step-02-structure
+description: Identify and challenge hierarchy - App > Module > Section > Resource
+model: opus
+next_step: steps/step-03-specify.md
+---
+
+# Step 02 — Structure (Identify & Challenge)
+
+## Objective
+
+Identify the complete hierarchy **Application > Module > Section > Resource** from the cadrage data, then CHALLENGE each element to ensure nothing is missing or superfluous.
+
+## Prerequisites
+
+- Step 01 (cadrage) completed
+- `cadrage.json` available with context, stakeholders, scope, risks
+
+## Input
+
+Load via ba-reader:
+- `cadrage.json` — framing data from step 01
+
+## Process
+
+### 1. Application Detection
+
+Analyze the cadrage scope to determine if this is single-app or multi-app:
+
+**Single-app indicators:**
+- All scope items relate to one domain
+- Single set of stakeholders
+- No mention of separate systems
+
+**Multi-app indicators:**
+- Scope items spanning distinct domains (e.g., HR + CRM + Accounting)
+- Different stakeholder groups per domain
+- Mentions of separate applications or systems
+
+If multi-app:
+```
+For each application:
+  - Code (PascalCase)
+  - Name (display name)
+  - Route (URL prefix)
+  - Icon (optional)
+  - Description
+```
+
+If single-app: derive application from project context.
+
+### 2. Module Identification
+
+For each application, identify functional modules:
+
+```
+For each module:
+  - Code (PascalCase)
+  - Name (display name)
+  - ApplicationCode (parent app)
+  - Description
+  - FeatureType (data-centric | workflow | reporting | integration | full-module)
+  - Priority (must | should | could)
+  - Entities (preliminary list)
+```
+
+### 3. Section & Resource Anticipation
+
+For each module, anticipate the navigation structure:
+
+```
+For each section:
+  - code (kebab-case, e.g., "list", "detail", "dashboard")
+  - label (display name)
+  - resources: [
+      { code, type (SmartTable|SmartForm|SmartCard|SmartKanban|SmartDashboard|SmartFilter), label }
+    ]
+```
+
+Common patterns:
+- **Data-centric module**: list (SmartTable) + detail (SmartForm)
+- **Workflow module**: list + detail + kanban (SmartKanban)
+- **Reporting module**: dashboard (SmartDashboard) + detail
+- **Full module**: list + detail + dashboard
+
+### 4. Dependency Graph
+
+Map dependencies between modules:
+```
+For each dependency:
+  - from: module code
+  - to: module code (depends on)
+  - description: nature of dependency
+```
+
+### 5. CHALLENGE Phase
+
+For EACH identified element, ask yourself:
+
+**Applications:**
+- Is this really a separate application or should it be a module?
+- Are there shared users between applications?
+
+**Modules:**
+- Is this module too large? Should it be split?
+- Is this module too small? Should it merge with another?
+- Does every scope item have at least one module covering it?
+- Are there scope items NOT covered by any module?
+
+**Sections:**
+- Does this module need a dashboard?
+- Is the list/detail pattern sufficient or are there other views?
+- Are there workflow steps that need dedicated sections?
+
+**Resources:**
+- Is SmartTable the right component for this list?
+- Does the form need tabs?
+- Are there missing filter components?
+
+### 6. Present to User
+
+Display the complete hierarchy for validation:
+
+```
+[App: HumanResources]
+  ├── [Module: Employees] (must)
+  │   ├── list → SmartTable (employees-grid)
+  │   └── detail → SmartForm (employee-form)
+  ├── [Module: Absences] (must)
+  │   ├── list → SmartTable (absences-grid)
+  │   ├── detail → SmartForm (absence-form)
+  │   └── calendar → SmartKanban (absences-calendar)
+  └── [Module: Reports] (should)
+      └── dashboard → SmartDashboard (hr-dashboard)
+```
+
+Ask: "Does this structure match your vision? Any missing modules, sections, or resources?"
+
+## Output
+
+Write via ba-writer:
+1. **Application index** (`docs/{app}/business-analyse/v1.0/index.json`) with modules list
+2. **Module registrations** in application index
+3. **Each module's anticipated sections** as `anticipatedSections` in module data
+
+### Data written
+
+```json
+{
+  "applications": [
+    { "code": "HumanResources", "name": "Ressources Humaines", "route": "/hr", "modules": ["Employees", "Absences"] }
+  ],
+  "modules": [
+    {
+      "code": "Employees",
+      "applicationCode": "HumanResources",
+      "name": "Employes",
+      "featureType": "data-centric",
+      "priority": "must",
+      "entities": ["Employee", "Contract"],
+      "anticipatedSections": [
+        { "code": "list", "label": "Liste", "resources": [{ "code": "employees-grid", "type": "SmartTable" }] },
+        { "code": "detail", "label": "Fiche", "resources": [{ "code": "employee-form", "type": "SmartForm" }] }
+      ]
+    }
+  ],
+  "dependencies": [
+    { "from": "Absences", "to": "Employees", "description": "Une absence reference un employe" }
+  ]
+}
+```
+
+## Transition
+
+→ Step 03 (specify) — Sequential module specification