@atlashub/smartstack-cli 3.4.1 → 3.6.0

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

@@ -70,7 +70,163 @@ Launch 3 agents in parallel:
 Merge findings into {codebase_context}
 ```
 
-### 3. Application-Level Questionnaire (application mode)
+### 3. MODE ROUTING
+
+```
+Read metadata.vibeCoding from feature.json
+
+IF metadata.vibeCoding == true:
+  → Execute VIBE CODING FLOW (section 3v below)
+  → SKIP sections 3s through 8s (standard flow)
+  → Go directly to section 9 (Coverage Matrix)
+
+ELSE:
+  → Execute STANDARD FLOW (sections 3s through 8s below)
+```
+
+---
+
+## VIBE CODING FLOW (accelerated — 3 lots max)
+
+> **In vibe coding mode, 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.
+
+### 3v. Vibe Coding — Lot 1: Problem & Scope
+
+**Goal:** Capture the core need and must-have features in a single batch.
+
+Ask via AskUserQuestion (2 questions):
+```
+question: "Quel est le besoin principal de cette application ?"
+header: "Besoin"
+options:
+  - label: "Automatiser un processus manuel"
+    description: "Remplacer des taches repetitives par une application"
+  - label: "Creer un outil manquant"
+    description: "Construire quelque chose qui n'existe pas encore"
+  - label: "Remplacer un outil existant"
+    description: "Remplacer un logiciel ou tableur qui ne convient plus"
+  - label: "Centraliser des donnees"
+    description: "Rassembler des informations dispersees en un seul endroit"
+```
+
+```
+question: "Quelles fonctionnalites sont indispensables pour la V1 ?"
+header: "Indispensable"
+multiSelect: true
+options:
+  → Generate 4 options dynamically from {feature_description}
+  → Each option = one functional area detected in the description
+  → Example for HR app: "Gestion des employes", "Saisie des heures", "Gestion des conges", "Rapports et exports"
+```
+
+**Store:**
+```yaml
+problem_type: string (from Q1)
+must_have_features: string[] (from Q2)
+```
+
+### 4v. Vibe Coding — Lot 2: Users & Permissions
+
+**Goal:** Determine access model (solo vs multi-user) and roles.
+
+Ask via AskUserQuestion:
+```
+question: "Qui va utiliser cette application ?"
+header: "Utilisateurs"
+options:
+  - label: "Moi seul"
+    description: "Application mono-utilisateur, je suis l'unique admin"
+  - label: "Quelques utilisateurs (2-10)"
+    description: "Petite equipe avec des roles differents"
+  - label: "Organisation (10+)"
+    description: "Deploiement a l'echelle d'une equipe ou entreprise"
+```
+
+```
+IF "Moi seul":
+  Auto-set:
+    applicationRoles = [{ role: "{App} Admin", level: "admin", permissionPattern: "business.{app}.*" }]
+    stakeholders = [{ role: "Developpeur", function: "Product owner et developpeur", involvement: "decision-maker", tasks: ["Toutes les operations"] }]
+  → SKIP role question
+
+IF "Quelques utilisateurs" or "Organisation":
+  Display standard 4-tier roles table, then ask:
+  question: "Ces 4 roles (Admin, Manager, Contributor, Viewer) conviennent-ils ?"
+  header: "Roles"
+  options:
+    - label: "Oui, parfait"
+      description: "Utiliser les 4 roles standards"
+    - label: "Personnaliser"
+      description: "Modifier les roles ou permissions"
+
+  Auto-set stakeholders from user type:
+    IF "Quelques utilisateurs":
+      stakeholders = [
+        { role: "Administrateur", function: "Gere le systeme et les utilisateurs", involvement: "decision-maker", tasks: ["Configuration", "Gestion utilisateurs"] },
+        { role: "Utilisateur", function: "Utilise le systeme au quotidien", involvement: "end-user", tasks: ["Saisie", "Consultation"] }
+      ]
+    IF "Organisation":
+      stakeholders = [
+        { role: "Administrateur", function: "Gere le systeme", involvement: "decision-maker", tasks: ["Configuration", "Gestion"] },
+        { role: "Manager", function: "Supervise et valide", involvement: "approver", tasks: ["Validation", "Reporting"] },
+        { role: "Utilisateur", function: "Operations quotidiennes", involvement: "end-user", tasks: ["Saisie", "Consultation"] }
+      ]
+```
+
+### 5v. Vibe Coding — Lot 3: Technical Challenges
+
+**Goal:** Identify technical risks specific to AI-assisted development.
+
+Ask via AskUserQuestion:
+```
+question: "Quels defis techniques anticipez-vous ?"
+header: "Defis"
+multiSelect: true
+options:
+  - label: "Regles metier complexes"
+    description: "Calculs, validations ou workflows difficiles a specifier"
+  - label: "Volume de donnees"
+    description: "Grandes quantites de donnees a gerer ou migrer"
+  - label: "Integrations externes"
+    description: "APIs, services tiers ou synchronisation avec d'autres systemes"
+  - label: "Interface riche"
+    description: "Ecrans avec beaucoup d'interactions, graphiques ou visualisations"
+```
+
+**Auto-infer cadrage data (DO NOT ask these — derive from answers):**
+
+```yaml
+cadrage.problem: "{feature_description} — {problem_type}"
+cadrage.asIs: "Aucun systeme en place" | "Processus manuel existant" | "Outil existant a remplacer"
+  → Derived from Lot 1 problem_type
+cadrage.toBe: "Application {application_name} couvrant: {must_have_features joined}"
+cadrage.trigger: "Projet vibe coding initie par le developpeur"
+cadrage.risks:
+  → Map each selected technical challenge to a RISK entry:
+    - "Regles metier complexes" → RISK-001, type: "technical", probability: "medium", impact: "high"
+    - "Volume de donnees" → RISK-002, type: "technical", probability: "low", impact: "medium"
+    - "Integrations externes" → RISK-003, type: "technical", probability: "medium", impact: "medium"
+    - "Interface riche" → RISK-004, type: "technical", probability: "low", impact: "low"
+  → Add mitigation for each: "Specification detaillee dans step-03 + generation iterative"
+cadrage.acceptanceCriteria:
+  - { id: "AC-001", criterion: "Toutes les fonctionnalites must-have implementees et fonctionnelles", validated: false }
+  - { id: "AC-002", criterion: "Application deployable et utilisable", validated: false }
+cadrage.globalScope:
+  mustHave: {must_have_features}
+  shouldHave: [] → Determined later in coverage matrix
+  couldHave: [] → Determined later in coverage matrix
+  outOfScope: []
+```
+
+**After Lot 3:** Go directly to **section 9 (Coverage Matrix)**.
+
+---
+
+## STANDARD FLOW (full questionnaire — sections 3s through 8s)
+
+### 3s. Application-Level Questionnaire (application mode)
 
 > **Only loaded when workflow.mode = "application"**
 
@@ -96,7 +252,7 @@ Ask questions in batches of max 4 via AskUserQuestion:
 
 After each batch: Apply ULTRATHINK + Elicitation Techniques.
 
-### 4. Core Questionnaires (always)
+### 4s. Core Questionnaires (always in standard mode)
 
 Load these categories in order. Each questionnaire contains its own batching strategy and elicitation guide.
 
@@ -125,7 +281,7 @@ Load these categories in order. Each questionnaire contains its own batching str
 - 2 lots AskUserQuestion
 - TOUJOURS charge (noyau) - ne jamais sauter cette categorie
 
-### 5. Conditional Questionnaires
+### 5s. Conditional Questionnaires
 
 Based on feature description analysis, load additional categories:
 
@@ -139,7 +295,7 @@ Based on feature description analysis, load additional categories:
 
 > **Categories 04 (donnees), 07 (interface), 11 (cycle de vie), 12 (migration), 13 (inter-modules) sont par module et chargees dans step-03.**
 
-### 6. Application Roles Definition
+### 6s. Application Roles Definition
 
 > **Define roles at the APPLICATION level, not per-module.**
 
@@ -173,7 +329,7 @@ options:
 IF single-module mode:
   Same role definition but inferred from stakeholders
 
-### 7. Proactive Suggestions
+### 7s. Proactive Suggestions
 
 > **Same pattern as previous step-01.** Load suggestion catalog.
 
@@ -184,7 +340,7 @@ Load: `patterns/suggestion-catalog.md`
 3. Present top 3-4 suggestions via AskUserQuestion (multiSelect: true)
 4. Store accepted suggestions in `suggestions[]`
 
-### 8. Risk Analysis
+### 8s. Risk Analysis
 
 Ask via AskUserQuestion:
 ```
@@ -207,6 +363,10 @@ Classify per probability/impact:
 - High/Low or Low/High → Medium (monitor)
 - Low/Low → Low (accept)
 
+---
+
+## COMMON FLOW (both modes rejoin here)
+
 ### 9. Coverage Matrix (MANDATORY)
 
 BEFORE transitioning to step-02:

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

@@ -1,8 +1,8 @@
 ---
 name: step-02-decomposition
 description: Module decomposition - identify modules, dependency graph, topological sort, client checkpoint
-model: sonnet
-next_step: steps/step-03a-specify.md
+model: opus
+next_step: steps/step-03a-data.md
 ---
 
 > **Context files:** `_shared.md`
@@ -38,7 +38,7 @@ ba-reader.findFeature({feature_id})
 
 IF status already "decomposed":
   Display: "Decomposition already completed. Loading next step."
-  Load: steps/step-03a-specify.md
+  Load: steps/step-03a-data.md
   STOP
 
 ### 2. Module Identification
@@ -292,4 +292,4 @@ When `workflow.mode = "module"` or only 1 scope item identified:
 
 ## NEXT STEP
 
-Load: `./step-03a-specify.md`
+Load: `./step-03a-data.md`

package/templates/skills/business-analyse/steps/{step-03a-specify.md → step-03a-data.md}

@@ -1,13 +1,13 @@
 ---
-name: step-03a-specify
-description: Per-module specification - sections, entities, BR, wireframes, use cases (interactive phase)
+name: step-03a-data
+description: Per-module specification - sections, entities, business rules, questionnaires (data & logic phase)
 model: opus
-next_step: steps/step-03b-compile.md
+next_step: steps/step-03b-ui.md
 ---
 
 > **Context files:** `_shared.md` | `_elicitation.md` | `_architecture.md` | `_module-loop.md`
 
-# Step 3a: Specification (Interactive Phase)
+# Step 3a: Specification - Data & Logic
 
 ## MANDATORY EXECUTION RULES
 
@@ -19,7 +19,6 @@ next_step: steps/step-03b-compile.md
 - ALL questions via AskUserQuestion tool
 - ALL communication in `{language}`
 - NEVER skip per-module validation
-- **WIREFRAME RULE:** Every section MUST have a wireframe in `specification.uiWireframes[]`. No section without a validated mockup.
 - **ID NAMING RULE (MANDATORY, NO EXCEPTION):**
   All IDs MUST include a module prefix to guarantee application-wide uniqueness.
   The prefix is derived from the module code initials (2-4 chars):
@@ -44,7 +43,7 @@ next_step: steps/step-03b-compile.md
 
 ## YOUR TASK
 
-Specify one module completely: walk through its sections and resources with the client, define entities, business rules, use cases, permissions, mockups, and validate before moving to the next module.
+Specify one module's data model and business logic: walk through sections, define entities, business rules, and validate with client before proceeding to UI specification.
 
 ---
 
@@ -298,355 +297,6 @@ Display to client:
 
 Write auto-generated sections to `specification.sections[]` via ba-writer.enrichSection()
 
-#### 3a-state. Define Entity State Machine (Full Depth)
-
-> **For full depth modules with entities that have a status/enum field, define the complete state machine.**
-> **This drives conditional actions, badges, and transition effects throughout the UI.**
-
-For each entity with a status-like attribute:
-
-1. **Identify states** from the enum values or business rules:
-```
-Ask client: "Quels sont les états possibles pour {Entity}.{statusField} ?"
-```
-
-2. **Define transitions** - for each state, ask:
-```
-Ask client: "Depuis l'état {state}, quelles transitions sont possibles ?"
-```
-
-3. **For each transition**, capture:
-   - `action`: verb label (submit, approve, reject, cancel, archive)
-   - `permission`: which permission is required
-   - `guards`: which BR must pass (reference existing BR-XXX from analysis)
-   - `effects`: what happens after (notification, email, field update)
-   - `confirm`: does the user need to confirm?
-
-4. **Assign colors** to states for badge rendering:
-   - Draft/New → gray
-   - In Progress/Submitted → blue
-   - Approved/Active → green
-   - Warning/Pending → yellow
-   - Error/Rejected → red
-   - Archived/Cancelled → purple
-
-5. **Store** in `specification.lifeCycles[]`:
-```json
-{
-  "entity": "{Entity}",
-  "field": "status",
-  "initialState": "{firstState}",
-  "states": [
-    { "id": "draft", "displayName": "Brouillon", "color": "gray", "allowedTransitions": ["submitted"], "isTerminal": false }
-  ],
-  "transitions": [
-    {
-      "from": "draft", "to": "submitted", "action": "submit",
-      "permission": "business.{app}.{module}.submit",
-      "guards": ["BR-VAL-{PREFIX}-001"],
-      "effects": [{ "type": "notification", "target": "role:manager", "template": "{module}-submitted" }],
-      "confirm": true
-    }
-  ]
-}
-```
-
-6. **Cross-validate:** Every `allowedTransitions` entry must have a matching `transitions[]` entry.
-
-#### 3a-bis. Structure Sections with Resources (Levels 4 & 5)
-
-> **DEPTH GATE:** Execute this section for **full** depth, or for individual sections flagged for customization in **override** depth. For **convention** depth, sections are auto-generated by 3a-infer — skip to 3b.
-
-For EACH section confirmed in 3a, build the `specification.sections[]` structure:
-
-1. For each resource in the section, determine:
-   - The SmartStack component type (SmartTable, SmartForm, DetailCard, KpiPanel, Chart, Map, Timeline, etc.)
-   - The entity it operates on
-   - Columns/fields based on entity attributes
-   - Permission (inherit from section or more specific)
-   - Available actions
-
-2. Link use cases to sections:
-   - Each UC MUST belong to exactly ONE section
-   - Map UC to section based on the primary action (list → UC-XX-001, create → UC-XX-003, etc.)
-
-3. Link business rules to sections:
-   - Each BR can belong to one or more sections
-   - Map BR based on where it's enforced (validation BR → create/edit section, calc BR → detail section)
-
-4. Build the section object:
-
-> **STRUCTURE CARD: specification.sections[]** — Resources MUST include full depth definitions.
-> ```json
-> {
->   "code": "list",
->   "labels": { "fr": "Liste", "en": "List", "it": "Elenco", "de": "Liste" },
->   "route": "/business/{app}/{module}/list",
->   "icon": "list",
->   "permission": "business.{app}.{module}.read",
->   "wireframe": "{module}-list",
->   "useCases": ["UC-{PREFIX}-001", "UC-{PREFIX}-002"],
->   "businessRules": ["BR-VAL-{PREFIX}-001"],
->   "resources": [
->     {
->       "code": "{module}-grid",
->       "type": "SmartTable",
->       "entity": "{MainEntity}",
->       "permission": "business.{app}.{module}.read",
->       "columns": ["name", "status", "createdAt"],
->       "columnDefs": [
->         { "field": "code", "label": {"fr": "Code", "en": "Code"}, "format": "text", "sortable": true, "filterable": true, "clickAction": "navigate:detail" },
->         { "field": "name", "label": {"fr": "Nom", "en": "Name"}, "format": "text", "sortable": true, "filterable": true },
->         { "field": "status", "label": {"fr": "Statut", "en": "Status"}, "format": "badge", "sortable": true, "filterable": true, "colorMap": "stateMachine:{Entity}" },
->         { "field": "createdAt", "label": {"fr": "Créé le", "en": "Created"}, "format": "date-relative", "sortable": true }
->       ],
->       "actions": ["view", "edit", "delete"],
->       "rowActions": [
->         { "action": "view", "icon": "eye", "permission": "business.{app}.{module}.read" },
->         { "action": "edit", "icon": "edit", "permission": "business.{app}.{module}.update", "showWhen": {"status": ["draft"]} },
->         { "action": "delete", "icon": "trash", "permission": "business.{app}.{module}.delete", "confirm": true }
->       ],
->       "filters": ["status", "dateRange"],
->       "defaultSort": { "field": "createdAt", "direction": "desc" },
->       "defaultPageSize": 20,
->       "emptyState": { "icon": "inbox", "message": {"fr": "Aucun enregistrement", "en": "No records"}, "createAction": true }
->     }
->   ]
-> }
-> ```
->
-> **SmartForm resource example (for create/edit sections):**
-> ```json
-> {
->   "code": "{module}-form",
->   "type": "SmartForm",
->   "entity": "{MainEntity}",
->   "permission": "business.{app}.{module}.create",
->   "fields": [
->     { "name": "code", "component": "Input", "required": true, "validation": "Unique, auto-generated" },
->     { "name": "name", "component": "Input", "required": true },
->     { "name": "type", "component": "Select", "required": true, "source": "EntityTypeEnum" },
->     { "name": "description", "component": "TextArea", "required": false },
->     { "name": "parentId", "component": "EntitySelect", "source": "ParentEntity", "required": true },
->     { "name": "startDate", "component": "DatePicker", "required": true },
->     { "name": "isActive", "component": "Toggle", "default": true }
->   ],
->   "formLayout": {
->     "type": "tabs",
->     "tabs": [
->       { "code": "general", "label": {"fr": "Général", "en": "General"}, "fields": ["code", "name", "type", "description"] },
->       { "code": "details", "label": {"fr": "Détails", "en": "Details"}, "fields": ["parentId", "startDate", "isActive"] }
->     ]
->   }
-> }
-> ```
-> **MANDATORY for SmartTable:** `columnDefs`, `rowActions`, `defaultSort`, `emptyState`
-> **MANDATORY for SmartForm:** `fields` with `component` type, `formLayout`
-
-5. Write `specification.sections[]` via ba-writer.enrichSection()
-
-**VALIDATION:** Every UC must appear in exactly one section.useCases[]. No orphan UCs.
-
-#### 3b. For Each Section: Generate MANDATORY ASCII Mockup
-
-> **BLOCKING RULE:** Every section MUST have a wireframe. No section proceeds to entity definition (step 6) without a validated mockup stored in `specification.uiWireframes[]`.
-> **HTML INTEGRATION:** These wireframes are also rendered in the interactive HTML document (`ba-interactive.html`) deployed at handoff. The client can review and annotate mockups directly in their browser.
-
-For each confirmed section, generate an ASCII mockup and validate with client:
-
-Example for a list section:
-
-```
-╔═══════════════════════════════════════════════════════════╗
-║  {Module} > Liste                                 [+ Nouveau] ║
-╠═══════════════════════════════════════════════════════════╣
-║  🔍 Rechercher...  │ Statut: [Tous ▾]  │ Date: [Ce mois ▾] ║
-╠═══════════════════════════════════════════════════════════╣
-║  # │ {Field1}  │ {Field2}    │ {Field3} │ Statut  │ ···  ║
-║  1 │ VAL-001   │ Exemple 1   │ 12'500.- │ ● Brouillon │ ⋮ ║
-║  2 │ VAL-002   │ Exemple 2   │  8'300.- │ ● Envoyé    │ ⋮ ║
-╠═══════════════════════════════════════════════════════════╣
-║  1-25 de 142  │  ◀  1  2  3  ···  6  ▶                   ║
-╚═══════════════════════════════════════════════════════════╝
-```
-
-Store in specification.uiWireframes[] (**MANDATORY** for every section):
-
-> **STRUCTURE CARD: specification.uiWireframes[]** — ALL fields below are MANDATORY.
-> ```json
-> {
->   "screen": "{module}-{section}",
->   "section": "{section}",
->   "description": "Description of the screen",
->   "mockupFormat": "ascii",
->   "mockup": "╔═══...",
->   "elements": ["DataGrid", "FilterBar", "Pagination", "CreateButton"],
->   "actions": ["filter", "sort", "create", "view-detail"],
->   "permissionsRequired": ["business.{app}.{module}.read"],
->   "componentMapping": [
->     { "wireframeElement": "DataGrid", "reactComponent": "SmartTable" },
->     { "wireframeElement": "FilterBar", "reactComponent": "SmartFilter" },
->     { "wireframeElement": "CreateButton", "reactComponent": "Button" }
->   ],
->   "layout": {
->     "type": "page",
->     "regions": [
->       { "id": "toolbar", "position": "top", "components": [
->         { "type": "FilterBar", "resourceRef": "{module}-filters" },
->         { "type": "ActionMenu", "resourceRef": "{module}-actions", "permission": "business.{app}.{module}.create" }
->       ]},
->       { "id": "content", "position": "main", "span": 12, "components": [
->         { "type": "SmartTable", "resourceRef": "{module}-grid" }
->       ]}
->     ]
->   }
-> }
-> ```
-> **REQUIRED fields:** `screen`, `mockup`, `elements`, `section`, `componentMapping`, `layout` are ALL mandatory.
-> A wireframe without `componentMapping` or `layout` will FAIL validation in step 9.
-> **layout.regions[].components[].resourceRef** MUST match a `sections[].resources[].code`.
-
-Ask client to validate each mockup via AskUserQuestion (batch 2-3 mockups at once if possible).
-
-> **IF client rejects a mockup:** Revise and re-propose until validated. Do NOT proceed without client approval on the layout.
-
-#### 3b-bis. Wireframe-to-Component Mapping
-
-After client validates the mockup, map each wireframe element to a SmartStack React component:
-
-| Wireframe Element | SmartStack Component | Notes |
-|-------------------|---------------------|-------|
-| DataGrid | `SmartTable` or `EntityCard` grid | Use EntityCard for card layouts |
-| FilterBar | `SmartFilter` | Integrated with SmartTable |
-| SearchInput | `SearchInput` | Debounced search |
-| Pagination | Built into `SmartTable` | Server-side pagination |
-| ActionButton | `Button` + `RequirePermission` | Always wrapped in permission check |
-| StatusBadge | `StatusBadge` | Uses entity lifecycle states |
-| DetailCard | `EntityDetailCard` | Standard detail layout |
-| Form | `SmartForm` | FluentValidation-backed |
-| KpiCard | `StatCard` (Recharts) | Dashboard KPI display |
-| Chart:bar/line/pie | Recharts `BarChart`/`LineChart`/`PieChart` | CSS variables for colors |
-
-Store the component mapping alongside the wireframe to ensure downstream skills use the correct components.
-
-#### 3b-ter. Generate Structural Layout
-
-For EACH wireframe generated in 3b, generate a `layout` object alongside the ASCII mockup:
-
-1. From the ASCII mockup, extract the visual regions (header, toolbar, main content, sidebar, etc.)
-2. For each region, map the visual elements to SmartStack component types
-3. Build the layout structure:
-```json
-{
-  "type": "page",
-  "regions": [
-    { "id": "toolbar", "position": "top", "components": [
-      { "type": "FilterBar", "resourceRef": "{module}-filters" },
-      { "type": "ActionMenu", "resourceRef": "{module}-actions", "permission": "business.{app}.{module}.create" }
-    ]},
-    { "id": "content", "position": "main", "span": 12, "components": [
-      { "type": "SmartTable", "resourceRef": "{module}-grid" }
-    ]}
-  ]
-}
-```
-4. Cross-validate: each component in layout.regions[].components[] MUST have a corresponding resource in sections[].resources[]
-5. Write layout alongside mockup in uiWireframes[]
-
-**RULE:** The layout is the source of truth for ralph-loop. The mockup is for human validation only.
-
-#### 3c. Identify Resources per Section
-
-For each section, identify what resources/components are needed:
-
-- List section → DataGrid, FilterBar, SearchInput, ExportButton
-- Detail section → DetailCard, StatusBadge, ActionButtons, Timeline
-- Create section → Form, ValidationMessages, SubmitButton
-- Approve section → StatusTransitionPanel, CommentBox, ApproveRejectButtons
-- Dashboard section → StatCard, RechartsChart (Bar/Line/Pie/Area), DashboardGrid, FilterBar
-
-#### 3d. Dashboard Specification (if section = dashboard)
-
-When a "dashboard" section is selected, capture structured KPI and chart data **in addition** to the standard ASCII mockup.
-
-1. **Ask client for KPIs** via AskUserQuestion (batch):
-   - KPI name and metric description
-   - Visualization type: `kpi-card`, `bar`, `line`, `pie`, `area`, `donut`, `stacked-bar`
-   - Data source entity
-   - Format: `number`, `currency`, `percent`, `duration`
-   - Thresholds (warning/critical) if applicable
-
-2. **Ask client for filters:**
-   - Date range filter? Default period? (day/week/month/quarter/year)
-   - Entity-based filters? (status, category, etc.)
-
-3. **Ask client for refresh mode:**
-   - Static (load on page open)
-   - Polling (periodic refresh)
-   - SignalR (real-time push)
-
-4. **Store in specification.dashboards[]:**
-
-```json
-{
-  "code": "{module}-dashboard",
-  "title": "{Module} Dashboard",
-  "description": "Vue d'ensemble des métriques {module}",
-  "linkedUCs": ["UC-XXX"],
-  "refreshMode": "static",
-  "defaultPeriod": "month",
-  "kpis": [
-    {
-      "code": "total-items",
-      "label": "Total Items",
-      "metric": "COUNT(entity)",
-      "format": "number",
-      "visualization": "kpi-card",
-      "dataSource": "Entity",
-      "thresholds": { "warning": 100, "critical": 50 }
-    },
-    {
-      "code": "items-by-status",
-      "label": "Items by Status",
-      "metric": "COUNT(entity) GROUP BY status",
-      "format": "number",
-      "visualization": "pie",
-      "dataSource": "Entity",
-      "dimensions": ["status"]
-    }
-  ],
-  "filters": [
-    { "field": "dateRange", "type": "dateRange", "label": "Période" },
-    { "field": "status", "type": "multiselect", "label": "Statut" }
-  ],
-  "permissionsRequired": ["business.{app}.{module}.read"]
-}
-```
-
-5. **ALSO generate the standard ASCII mockup** for the dashboard with KPI cards + chart placeholders:
-
-```
-╔═══════════════════════════════════════════════════════════════╗
-║  {Module} > Dashboard              Période: [Ce mois ▾]     ║
-╠═══════════════════════════════════════════════════════════════╣
-║  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐    ║
-║  │ KPI #1   │  │ KPI #2   │  │ KPI #3   │  │ KPI #4   │    ║
-║  │  1,234   │  │  567     │  │  89.2%   │  │  12,400  │    ║
-║  │  ↑ +12%  │  │  ↓ -3%  │  │  → 0%   │  │  ↑ +5%   │    ║
-║  └──────────┘  └──────────┘  └──────────┘  └──────────┘    ║
-╠═══════════════════════════════════════════════════════════════╣
-║  ┌─────────────────────────┐  ┌─────────────────────────┐    ║
-║  │  [Bar Chart]            │  │  [Pie Chart]            │    ║
-║  │  Items by Month         │  │  Items by Status        │    ║
-║  │  ████                   │  │      ████████           │    ║
-║  │  ████ ████              │  │   ███      ███          │    ║
-║  │  ████ ████ ████         │  │  ██   42%    ██         │    ║
-║  └─────────────────────────┘  └─────────────────────────┘    ║
-╚═══════════════════════════════════════════════════════════════╝
-```
-
-Store the mockup in specification.wireframes[] AS WELL (for visual reference).
-
 ### 4. Conditional Questionnaires
 
 Based on module type, load questionnaires per-module:
@@ -806,19 +456,20 @@ Extract business rules specific to this module:
 
 ---
 
-## SELF-VERIFICATION (MANDATORY before loading step-03b)
+## SELF-VERIFICATION (MANDATORY before loading step-03b-ui)
 
-Before proceeding to step-03b-compile.md, VERIFY:
+Before proceeding to step-03b-ui.md, VERIFY:
 
 1. **Module feature.json exists** at expected path (`docs/business/{app}/{module}/business-analyse/v{X.Y}/feature.json`)
 2. **Module feature.json has analysis section** with `entities[]` (at least 1) and `businessRules[]` (at least 1)
 3. **Module status in master** = "in-progress" (set by section 2 above)
 4. **Master modules[].featureJsonPath** for this module ≠ null (set by ba-writer.create)
+5. **Sections identified** with clear roles and entities assigned
 
-**IF any check fails → FIX before proceeding.** Do NOT load step-03b with incomplete data.
+**IF any check fails → FIX before proceeding.** Do NOT load step-03b-ui with incomplete data.
 
 ---
 
 ## NEXT STEP
 
-Load: `steps/step-03b-compile.md`
+Load: `steps/step-03b-ui.md`