@atlashub/smartstack-cli 4.74.0 → 4.75.0

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

@@ -39,31 +39,26 @@ Load via ba-reader:
 
 ## Process
 
-### 1. Application Detection
+### 1. Application Verification (SCOPE LOCKED)
 
-Analyze the cadrage scope to determine if this is single-app or multi-app:
+> **Multi-app detection was already done in step-00 Step 3b and confirmed by the user.**
+> This step does NOT re-detect applications. It reads the confirmed structure.
 
-**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
+Read .business-analyse/config.json:
+  IF workflow_mode = "project":
+    applications = config.candidateApplications  // Confirmed in step-00
+    For each application:
+      - Code (PascalCase) — from candidateApplications[].name
+      - Name (display name)
+      - Route (URL prefix) — toKebabCase(code)
+      - Description — from candidateApplications[].description
+  ELSE (workflow_mode = "application"):
+    Single application from config.application / config.applicationCode
 ```
 
-If single-app: derive application from project context.
+**INTERDICTION** de re-analyser le cadrage pour detecter de nouvelles applications.
+Le nombre d'applications est VERROUILLE par step-00.
 
 ### 2. Module Identification
 
@@ -82,6 +77,67 @@ For each module:
       if ALL external → "external", else → "shared"
 ```
 
+### 2b. Per-Application Module Completeness Challenge (MANDATORY — BLOCKING)
+
+> **Load** `references/module-completeness-challenge.md` for application archetypes.
+> **Load** `{domain_research}.applications[{app_code}]` from step-01 research.
+> This gate ensures no application is left with fewer modules than the industry standard.
+
+For EACH application:
+
+  1. Load archetype for this app type from `module-completeness-challenge.md`
+  2. Load `{domain_research}.applications[{app_code}].standardModules` (if available)
+  3. Merge research + archetype into a single reference list
+  4. Compare identified modules vs reference CORE modules
+
+  Display as markdown:
+  ```
+  ### {language == "fr" ? "Completude modules" : "Module completeness"} : {appName}
+
+  | Module identifie | Classification | Statut |
+  |-----------------|---------------|--------|
+  | {identified_module} | CORE | ✓ Present |
+  | — | CORE | ✗ **{missing_core_module}** — {description} |
+  | — | STANDARD | △ {missing_standard_module} — {description} |
+  ```
+
+  For EACH missing **CORE** module:
+    AskUserQuestion:
+    ```
+    question: "{missing_module} est un composant CORE d'une application {app_type}.
+      {reason_why_core}. Comment souhaitez-vous le traiter ?"
+    options:
+      - label: "Ajouter comme module"
+        description: "Creer un module dedie {missing_module}"
+      - label: "Integrer comme section"
+        description: "Ajouter comme section dans {closest_existing_module}"
+      - label: "Exclure du perimetre"
+        description: "Exclure explicitement avec justification"
+    ```
+
+    IF "Exclure" → document in `cadrage.globalScope.outOfScope` with reason
+
+  For EACH missing **STANDARD** module:
+    Display as suggestion (non-blocking):
+    "△ Module {name} (STANDARD) : {description} — Recommande pour une application {app_type} complete."
+
+  **Module Count Sanity Check (BLOCKING):**
+
+  | Application Type | Minimum Modules | Reason |
+  |-----------------|----------------|--------|
+  | HR | 3 | Employees + Absences + at least 1 more (Documents, Evaluations, Organisation) |
+  | CRM | 3 | Contacts/Accounts + Opportunities + at least 1 (Quotes, Activities, Campaigns) |
+  | Billing/Invoicing | 3 | Invoices + Credit Notes + Payment Tracking (minimum legal) |
+  | Project Management | 3 | Projects + Tasks/Time + at least 1 (Milestones, Resources, Reports) |
+
+  IF application has fewer modules than minimum → **BLOCKING:**
+    "L'application {app} a {N} modules. Le minimum standard est {min}.
+     Modules manquants probables : {list from archetype}.
+     Veuillez ajouter des modules ou justifier l'exclusion."
+
+  **INTERDICTION** de valider la structure tant que chaque module CORE manquant
+  n'est pas traite (ajoute, integre, ou exclu avec justification documentee).
+
 ### 3. Section & Resource Anticipation
 
 For each module, anticipate the navigation structure:
@@ -114,6 +170,28 @@ Common patterns:
 - **Reporting**: dashboard (`primary`/`read-only`) → detail (`view`/`inherit`, parent: dashboard)
 - **Full module**: list (`primary`/`crud`) → detail (`view`/`inherit`, parent: list) + dashboard (`embedded`/`read-only`, parent: list)
 
+### 3b. Section Anticipation from Domain Research (MANDATORY)
+
+> **Enrich anticipated sections using domain research BEFORE presenting to user.**
+
+For EACH module:
+  IF `{domain_research}` contains section data for this module type (from Level 1 research or archetype):
+    Compare `anticipatedSections` against research/archetype standard sections
+    Add missing standard sections to `anticipatedSections` with `source: "domain-research"`
+
+  Example: Module "Absences" (workflow type)
+    Archetype standard sections: list, detail, approve, calendar, open-requests, rejected, history, my-balance
+    Currently anticipated: list, detail, approve, calendar
+    → ADDING: open-requests (functional/custom), rejected (functional/read-only), history (functional/read-only), my-balance (embedded/read-only)
+
+  Example: Module "Factures" (workflow type)
+    Archetype standard sections: list, detail, generate, dashboard, overdue
+    Currently anticipated: list, detail, generate, dashboard
+    → ADDING: overdue (functional/read-only)
+
+> **These enriched sections are PROPOSALS.** They will be presented to the user
+> for validation in section 6 (Present to User). The user can accept or reject.
+
 ### 4. Dependency Graph
 
 Map dependencies between modules: