@atlashub/smartstack-cli 3.37.0 → 3.39.0

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

@@ -97,7 +97,7 @@ IF mcp_available:
 Launch 3 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/business/**/*.tsx)
+  Agent 3: Search for existing page patterns (Glob: **/pages/**/*.tsx)
 
 Merge findings into {codebase_context}
 ```
@@ -228,56 +228,26 @@ Ask in 1-2 batches. After each batch:
 **Mandatory minimum:** Q3.2 (must-have), Q3.4 (exclusions), Q3.5 (main journey).
 
 Ask in 1-2 batches. After each batch:
-- If everything is "must-have" → **BLOCKING**: apply MoSCoW prioritization question (see POST-CHECK below)
+- If everything is "must-have" → **BLOCKING**: apply MoSCoW prioritization question
 - 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?"
 
 > **BLOCKING RULE — MoSCoW DISTRIBUTION:**
 > If the client classifies ALL features as "must-have", you MUST challenge this BEFORE proceeding.
-> Ask via AskUserQuestion:
-> ```
-> question: "{language == 'fr'
->   ? 'Toutes les fonctionnalités sont marquées indispensables. Si vous ne pouviez livrer que 60% du périmètre en v1, lesquelles pourraient attendre la v2 ?'
->   : 'All features are marked must-have. If you could only deliver 60% of scope in v1, which ones could wait for v2?'}"
-> header: "Priorisation"
-> multiSelect: true
-> options:
->   - label: "{feature_1}"
->     description: "{language == 'fr' ? 'Pourrait passer en Important (v1.x)' : 'Could move to Important (v1.x)'}"
->   - label: "{feature_2}"
->     description: "{language == 'fr' ? 'Pourrait passer en Optionnel (v2)' : 'Could move to Optional (v2)'}"
->   - label: "{feature_3}"
->     description: "{language == 'fr' ? 'Pourrait passer en Important (v1.x)' : 'Could move to Important (v1.x)'}"
->   - label: "{language == 'fr' ? 'Tout est vraiment indispensable' : 'Everything is truly must-have'}"
->     description: "{language == 'fr' ? 'Je confirme que toutes les fonctionnalités sont critiques pour la v1' : 'I confirm all features are critical for v1'}"
-> ```
+> **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)
 
-> **Apply elicitation techniques to challenge what the client considers "obvious".**
-> This is what separates a deep analysis from a shallow one.
+> **Reference:** Load `references/cadrage-challenge-patterns.md` for domain-specific patterns and elicitation techniques.
 
-For EACH specific point from the brief, prepare a targeted challenge question.
+Apply elicitation techniques to challenge what the client considers "obvious".
+This is what separates a deep analysis from a shallow one.
 
-**Rules for challenge questions:**
+For EACH specific point from the brief, prepare a targeted challenge question:
 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)
-
-**Examples by domain pattern:**
-
-| 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?" |
-
-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?"
+3. Use techniques from the reference (Scenario, Absence Test, Impact Escalation)
 
 Ask challenge questions via AskUserQuestion (1-2 batches of max 4).
 
@@ -354,7 +324,6 @@ ULTRATHINK — Entity Architecture Analysis for {entity_name}:
 
 | {language == "fr" ? "Niveau" : "Level"} | {language == "fr" ? "Valeur" : "Value"} | {language == "fr" ? "Justification" : "Rationale"} |
 |--------|--------|---------------|
-| Context | `business` | {language == "fr" ? "Contexte métier standard" : "Standard business context"} |
 | Application | `{app_code}` | {app_name} |
 | Module | `{ModuleCode}` | {language == "fr" ? "{pourquoi ce découpage}" : "{why this decomposition}"} |
 
@@ -531,83 +500,13 @@ options:
 
 **This section is SKIPPED if `workflow_mode !== "project"`.**
 
-**Process:**
-
-1. Build module inventory per candidate application:
-
-```javascript
-// From candidateApplications (step-00) + enriched by cadrage phases 1-4
-const modulesByApp = {};
-for (const app of candidate_applications) {
-  modulesByApp[app.name] = app.modules;  // e.g., { "RH": ["Employes", "Conges", "Temps"], "Projet": ["Projets", "Temps"] }
-}
-```
-
-2. Detect modules appearing in 2+ applications:
-
-```javascript
-const allModules = Object.values(modulesByApp).flat();
-const moduleCounts = {};
-for (const mod of allModules) {
-  const normalized = normalizeModuleName(mod);  // "Temps", "Saisie du temps", "Time Tracking" → same concept
-  moduleCounts[normalized] = (moduleCounts[normalized] || 0) + 1;
-}
-const sharedModules = Object.entries(moduleCounts)
-  .filter(([_, count]) => count >= 2)
-  .map(([name, count]) => ({ name, appearsIn: count, applications: findAppsContaining(name) }));
-```
-
-3. IF shared modules found, propose extraction:
+**Reference:** Load `references/cadrage-shared-modules.md` for detection algorithm, extraction logic, and question template.
 
-```
-{language == "fr"
-  ? "### Modules partagés détectés\n\nCertains modules apparaissent dans plusieurs applications. Les extraire en application(s) dédiée(s) améliore la réutilisabilité et évite la duplication :"
-  : "### Shared modules detected\n\nSome modules appear in multiple applications. Extracting them as dedicated application(s) improves reusability and avoids duplication:"}
-
-| Module | Présent dans | Suggestion |
-|--------|-------------|-----------|
-{for each shared: name | apps.join(", ") | "Extraire en application '{name}'" }
-
-{language == "fr"
-  ? "**Exemple :** Si 'Gestion du temps' est dans RH et Projet, créer une application 'Temps' dédiée que les deux autres consomment."
-  : "**Example:** If 'Time Management' is in HR and Project, create a dedicated 'Time' application that the other two consume."}
-```
-
-Ask via AskUserQuestion:
-```
-question: "{language == 'fr' ? 'Souhaitez-vous extraire les modules partagés en application(s) dédiée(s) ?' : 'Do you want to extract shared modules as dedicated application(s)?'}"
-header: "Extraction"
-options:
-  - label: "{language == 'fr' ? 'Oui, extraire' : 'Yes, extract'}"
-    description: "{language == 'fr' ? 'Créer {sharedModules.length} application(s) transversale(s) supplémentaire(s)' : 'Create {sharedModules.length} additional cross-cutting application(s)'}"
-  - label: "{language == 'fr' ? 'Non, garder en l\'état' : 'No, keep as-is'}"
-    description: "{language == 'fr' ? 'Chaque application garde sa propre version du module' : 'Each application keeps its own version of the module'}"
-```
-
-**IF "Oui, extraire":**
-```javascript
-for (const shared of sharedModules) {
-  // Create new candidate application
-  candidate_applications.push({
-    name: shared.name,
-    description: `Application transversale pour ${shared.name}`,
-    modules: [shared.name],
-    context: "business",
-    isTransversal: true,
-    consumedBy: shared.applications
-  });
-
-  // Remove the shared module from original applications
-  for (const appName of shared.applications) {
-    const app = candidate_applications.find(a => a.name === appName);
-    app.modules = app.modules.filter(m => normalizeModuleName(m) !== shared.name);
-    app.dependencies = app.dependencies || [];
-    app.dependencies.push({ target: shared.name, type: "data-dependency" });
-  }
-}
-```
-
-Update `candidate_applications` in the project feature.json.
+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
 
 ---
 
@@ -624,7 +523,7 @@ Application Roles for {application_name}:
 
 | Role | Level | Default Permissions |
 |------|-------|-------------------|
-| {App} Admin | admin | business.{app}.* (wildcard) |
+| {App} Admin | admin | {app}.* (wildcard) |
 | {App} Manager | manager | read, create, update, assign |
 | {App} Contributor | contributor | read, create, update |
 | {App} Viewer | viewer | read only |
@@ -687,95 +586,33 @@ options:
 
 ### 7. Coverage Matrix with Sections & Resources (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.
+> **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.
 
 BEFORE transitioning to step-02:
 
 1. Re-read the original prompt/brief in its entirety
 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)
-   d. **List anticipated sections** (Level 4) — ONLY functional zones (see `references/entity-architecture-decision.md` section 4)
-   e. **List anticipated resources** (Level 5) for each section
-   f. **List detail page tabs** — for entities accessible via click from `list`
-
-> **SECTION RULE:** Sections are functional zones (list, dashboard, approve, import, rapport...).
-> `create` and `edit` are SEPARATE PAGES with their own URL routes (`/create` and `/:id/edit`).
-> `detail` is a page with tabs accessible by clicking a row in `list`, NOT a standalone 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 | Section | Resources clés | Onglets détail**
-
-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 | Section | Resources clés | Onglets détail |
-|---|---|---|---|---|---|
-| Gestion des employés | mustHave | Employees | list | employee-grid, employee-filters, employee-form | Infos, Contrats, Documents |
-| Suivi des activités | mustHave | TimeTracking | list | activity-grid, activity-filters, activity-form | Infos, Imputations |
-| Saisie d'absences | mustHave | TimeTracking | list | absence-grid, absence-form, absence-calendar | Infos, Justificatifs |
-| Rapports temps | shouldHave | TimeTracking | dashboard | time-kpi-cards, time-summary-chart | — |
-| Validation absences | shouldHave | TimeTracking | approve | approval-queue, status-timeline | — |
-| Export PDF/Excel | couldHave | TimeTracking | rapport | export-panel | — |
-| Intégration paie | outOfScope | — | — | — | — |
-```
-
-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'}"
-```
-
-6. Iterate until the client confirms.
+   - Create an entry in `cadrage.coverageMatrix[]`
+   - Assign it to mustHave, shouldHave, couldHave, or outOfScope
+   - Assign the module that will cover it (or null if cross-cutting)
+   - List anticipated sections (Level 4) — ONLY functional zones
+   - List anticipated resources (Level 5) for each section
+   - List detail page tabs — for entities accessible via click from `list`
 
-**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.
+4. **OUTPUT the matrix as text** (do NOT put it inside AskUserQuestion — it won't render)
 
-**POST-CHECK — PRIORITY DISTRIBUTION (BLOCKING):**
+5. **THEN** (after the table is displayed) ask via AskUserQuestion for confirmation
 
-```
-coverageItems = cadrage.coverageMatrix[]
-mustHaveCount = coverageItems.filter(i => i.category === "mustHave").length
-shouldHaveCount = coverageItems.filter(i => i.category === "shouldHave").length
-couldHaveCount = coverageItems.filter(i => i.category === "couldHave").length
-outOfScopeCount = coverageItems.filter(i => i.category === "outOfScope").length
+6. Iterate until the client confirms
 
-IF shouldHaveCount === 0 AND couldHaveCount === 0 AND outOfScopeCount === 0:
-  → FAIL: ALL {mustHaveCount} items are mustHave — no distribution.
-  → ACTION: Return to Phase 3 section 4c and apply MoSCoW question.
-  → DO NOT write cadrage until at least shouldHave OR outOfScope has ≥ 1 item.
-  → EXCEPTION: If client explicitly confirmed "tout est indispensable" during
-    Phase 3 section 4c, accept but ADD a changelog entry:
-    "Client confirmed all {N} features as mustHave after MoSCoW challenge"
-```
-
-**POST-CHECK — CROSS-CUTTING COVERAGE (WARNING):**
-
-```
-FOR each item in coverageMatrix WHERE item.module === null:
-  IF item.category === "mustHave":
-    → WARNING: "{item.item}" is mustHave but has no assigned module.
-    → Ensure it is covered by infrastructure or a cross-cutting concern.
-    → Add a note explaining HOW it will be implemented (e.g., "handled by platform notification service").
-  IF item.anticipatedSections.length === 0 AND item.category !== "outOfScope":
-    → WARNING: "{item.item}" has no anticipated sections — will it be implemented?
-```
+**The reference file includes:**
+- Section rule clarification (list, detail, create, edit, dashboard, etc.)
+- Priority distribution POST-CHECK (BLOCKING)
+- Cross-cutting coverage POST-CHECK (WARNING)
 
 ---
 
@@ -858,9 +695,9 @@ Display analysis as markdown:
   ? "### 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 Context | Suggested Application | Key Modules |
-|--------|-------------------|----------------------|-------------|
-{for each identified domain: domain name | business/platform/personal | PascalCase name | top modules}
+| Domain | Suggested Application | Key Modules |
+|--------|----------------------|-------------|
+{for each identified domain: domain name | PascalCase name | top modules}
 ```
 
 Ask via AskUserQuestion:

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

@@ -51,8 +51,7 @@ From the cadrage data, derive the formal application identity:
 ```javascript
 applicationCode = toPascalCase(metadata.application)  // e.g., "HumanResources"
 applicationLabel = metadata.application                // e.g., "Ressources Humaines" (human-readable)
-context = metadata.context                             // "business" (validated in step-00)
-applicationRoute = `/${context}/${toKebabCase(applicationCode)}`  // e.g., "/business/human-resources"
+applicationRoute = `/${toKebabCase(applicationCode)}`  // e.g., "/human-resources"
 applicationIcon = suggestIconFromDomain(applicationCode) // e.g., "users" for HR, "shopping-cart" for Sales
 tablePrefix = metadata.tablePrefix                     // e.g., "rh_" (already defined in step-01)
 sort = 1                                               // First (and only) application
@@ -82,7 +81,6 @@ Display the application identity:
 
 | {language == "fr" ? "Niveau" : "Level"} | {language == "fr" ? "Valeur" : "Value"} |
 |-------|-------|
-| Context | `{context}` |
 | Application Code | `{applicationCode}` |
 | Application Name | `{applicationLabel}` |
 | Route | `{applicationRoute}` |
@@ -96,7 +94,7 @@ Display the application identity:
 
 | Role | Level | Permission Pattern |
 |------|-------|--------------------|
-{for each role in cadrage.applicationRoles: role.role | role.level | {context}.{kebab(applicationCode)}.* }
+{for each role in cadrage.applicationRoles: role.role | role.level | {kebab(applicationCode)}.* }
 ```
 
 Ask via AskUserQuestion:
@@ -117,7 +115,7 @@ options:
 
 ### 0d. Build Application SeedData Entries
 
-Create the `navigationApplications` entry (Level 2 hierarchy entry):
+Create the `navigationApplications` entry (Level 1 hierarchy entry):
 
 ```json
 {
@@ -207,19 +205,19 @@ For EACH candidate application from the cadrage analysis:
 Display proposed application:
 ```
 {language == "fr"
-  ? "### Application : {suggestedName}\n\n**Contexte de navigation :** {suggestedContext}\n**Description :** {description based on coverage matrix items}"
-  : "### Application: {suggestedName}\n\n**Navigation context:** {suggestedContext}\n**Description:** {description based on coverage matrix items}"}
+  ? "### Application : {suggestedName}\n\n**Description :** {description based on coverage matrix items}"
+  : "### Application: {suggestedName}\n\n**Description:** {description based on coverage matrix items}"}
 ```
 
 Ask via AskUserQuestion:
 ```
-question: "{language == 'fr' ? 'Cette application et son contexte vous conviennent-ils ?' : 'Does this application and its context suit you?'}"
+question: "{language == 'fr' ? 'Cette application vous convient-elle ?' : 'Does this application suit you?'}"
 header: "{appName}"
 options:
   - label: "{language == 'fr' ? 'Oui, parfait' : 'Yes, perfect'}"
-    description: "{language == 'fr' ? 'Nom et contexte corrects' : 'Name and context are correct'}"
+    description: "{language == 'fr' ? 'Nom et description corrects' : 'Name and description are correct'}"
   - label: "{language == 'fr' ? 'Modifier' : 'Modify'}"
-    description: "{language == 'fr' ? 'Changer le nom, le contexte ou la description' : 'Change name, context, or description'}"
+    description: "{language == 'fr' ? 'Changer le nom ou la description' : 'Change name or description'}"
 ```
 
 #### 2b. Table Prefix (per application)
@@ -244,7 +242,7 @@ Based on global roles from cadrage + application-specific needs:
 
 | Role | Level | Permission Pattern |
 |------|-------|--------------------|
-{for each role: name | admin/manager/contributor/viewer | context.app.* pattern}
+{for each role: name | admin/manager/contributor/viewer | app.* pattern}
 ```
 
 Ask via AskUserQuestion if additional roles are needed for this specific application.
@@ -300,9 +298,9 @@ Display the full application structure:
   ? "### Structure du projet\n\nVoici les applications identifiées :"
   : "### Project Structure\n\nHere are the identified applications:"}
 
-| # | Application | Contexte | Préfixe | Rôles | Dépendances |
-|---|-------------|----------|---------|-------|-------------|
-{for each app: index | name | context | prefix | role count | dependency list}
+| # | Application | Préfixe | Rôles | Dépendances |
+|---|-------------|---------|-------|-------------|
+{for each app: index | name | prefix | role count | dependency list}
 
 {language == "fr"
   ? "### Ordre de traitement\n\nLes applications seront traitées dans cet ordre (fondations d'abord) :"
@@ -343,9 +341,8 @@ ba-writer.createApplicationFeature({
   metadata: {
     application: {app.code},
     applicationCode: {toPascalCase(app.code)},
-    applicationRoute: {`/${app.context}/${toKebabCase(app.code)}`},
+    applicationRoute: {`/${toKebabCase(app.code)}`},
     applicationIcon: {app.icon},
-    context: {app.context},
     language: {language},
     featureDescription: {app.description},
     workflowType: "new",
@@ -375,7 +372,6 @@ ba-writer.enrichApplicationRegistry({
     {
       code: {app1.code},
       name: {app1.name},
-      context: {app1.context},
       tablePrefix: {app1.tablePrefix},
       icon: {app1.icon},
       route: {app1.route},
@@ -407,9 +403,9 @@ ba-writer.updateStatus({project_id}, "decomposed")
   ? "### Décomposition en applications terminée\n\n"
   : "### Application decomposition complete\n\n"}
 
-| Application | Contexte | Préfixe | Route | Feature ID |
-|-------------|----------|---------|-------|------------|
-{for each app: name | context | prefix | route | FEAT-NNN}
+| Application | Préfixe | Route | Feature ID |
+|-------------|---------|-------|------------|
+{for each app: name | prefix | route | FEAT-NNN}
 
 {language == "fr"
   ? "→ Prochaine étape : décomposition en modules pour **{firstApp}** (application {1}/{total})"

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

@@ -303,7 +303,7 @@ ba-writer.updateStatus({feature_id}, "decomposed")
 
 For each module in moduleOrder:
 ```
-Create: docs/business/{app}/{module_code}/business-analyse/v1.0/
+Create: docs/{app}/{module_code}/business-analyse/v1.0/
 ```
 
 > Module feature.json files will be created by step-03 when each module is processed.

package/templates/skills/business-analyse/steps/step-03a1-setup.md

@@ -128,7 +128,7 @@ ba-writer.create({
   scope: "module",
   applicationRef: {feature_id},
   moduleCode: {currentModule.code},
-  path: "docs/business/{app}/{module_code}/business-analyse/v1.0/feature.json"
+  path: "docs/{app}/{module_code}/business-analyse/v1.0/feature.json"
 })
 
 // Inherit application roles from master
@@ -213,8 +213,8 @@ Total: {N} requirements mapped to this module
 
 ### 3. Section Walkthrough with Client
 
-> **This is the key interactive phase aligned with the 5-level SmartStack hierarchy.**
-> Level 3 = Module, Level 4 = Section, Level 5 = Resource
+> **This is the key interactive phase aligned with the 4-level SmartStack hierarchy.**
+> Level 2 = Module, Level 3 = Section, Level 4 = Resource
 
 #### 3a. Identify Module Sections
 
@@ -435,7 +435,7 @@ ULTRATHINK — Entity Architecture Analysis for {entity_name} (discovered during
 - **{language == "fr" ? "Recommandation" : "Recommendation"}** : **{recommended_option}** — {reasoning}
 ```
 
-**IF recommendation = new_module AND confidence >= MEDIUM, ALSO display the architecture proposal** (same format as cadrage 4d-bis Phase 2: Context/Application/Module table + Sections table + Detail tabs table + Impact).
+**IF recommendation = new_module AND confidence >= MEDIUM, ALSO display the architecture proposal** (same format as cadrage 4d-bis Phase 2: Application/Module table + Sections table + Detail tabs table + Impact).
 
 ##### C. Ask with Recommended Option First
 

package/templates/skills/business-analyse/steps/step-03a2-analysis.md

@@ -226,7 +226,7 @@ Extract business rules specific to this module:
 
 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`)
+1. **Module feature.json exists** at expected path (`docs/{app}/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. **Entity schema compliance (BLOCKING)** — EVERY entity has `attributes[]` (NOT `fields[]`) and `relationships[]` arrays.
    Quick check: `analysis.entities.every(e => Array.isArray(e.attributes) && e.attributes.length >= 1)`

package/templates/skills/business-analyse/steps/step-03b-ui.md

@@ -100,7 +100,7 @@ Ask client: "Depuis l'état {state}, quelles transitions sont possibles ?"
   "transitions": [
     {
       "from": "draft", "to": "submitted", "action": "submit",
-      "permission": "business.{app}.{module}.submit",
+      "permission": "{app}.{module}.submit",
       "guards": ["BR-VAL-{PREFIX}-001"],
       "effects": [{ "type": "notification", "target": "role:manager", "template": "{module}-submitted" }],
       "confirm": true
@@ -255,7 +255,7 @@ A wireframe without `componentMapping` or `layout` will FAIL validation in step
 
 Adaptation rules for the detail mockup:
 - **Header**: entity code + name + status badge (if lifeCycles) + action buttons (edit, delete)
-- **Back button**: navigates to `/business/{app}/{module}`
+- **Back button**: navigates to `/{app}/{module}`
 - **Tabs**: one per identified tab (Info + relations + history)
 - **Info tab content**: all entity attributes as label:value pairs (read-only by default)
 - **Edit button**: toggles the Info tab into SmartForm edit mode
@@ -273,7 +273,7 @@ Transition buttons are contextual: only show actions allowed from the current st
 5. **Store** in `specification.uiWireframes[]` with `section: "detail"`.
    See [references/ui-resource-cards.md](../references/ui-resource-cards.md) "Detail Page Wireframe" for exact JSON format.
 
-6. **Create the detail section** in `specification.sections[]` with `navigation: "hidden"` and route `/business/{app}/{module}/:id`.
+6. **Create the detail section** in `specification.sections[]` with `navigation: "hidden"` and route `/{app}/{module}/:id`.
    See [references/ui-resource-cards.md](../references/ui-resource-cards.md) "Detail Page section" for exact JSON format.
 
 ### 3b-bis. Wireframe-to-Component Mapping
@@ -312,7 +312,7 @@ For EACH wireframe generated in 3b, generate a `layout` object alongside the ASC
   "regions": [
     { "id": "toolbar", "position": "top", "components": [
       { "type": "FilterBar", "resourceRef": "{module}-filters" },
-      { "type": "ActionMenu", "resourceRef": "{module}-actions", "permission": "business.{app}.{module}.create" }
+      { "type": "ActionMenu", "resourceRef": "{module}-actions", "permission": "{app}.{module}.create" }
     ]},
     { "id": "content", "position": "main", "span": 12, "components": [
       { "type": "SmartTable", "resourceRef": "{module}-grid" }