@atlashub/smartstack-cli 3.39.0 → 3.41.0

package/templates/skills/business-analyse/references/cadrage-challenge-patterns.md

@@ -1,41 +1,41 @@
-# Cadrage Challenge Patterns
-
-Reference material for identifying and challenging implicit assumptions in business requirements analysis.
-
-## Challenge Question 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?" |
-
-## Elicitation 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?"
-
-## MoSCoW Prioritization Template
-
-When client classifies ALL features as "must-have", apply this blocking challenge:
-
-```
-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: "{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'}"
-```
-
-If client moves items → update categories. If client confirms ALL mustHave → accept but log in changelog.
+# Cadrage Challenge Patterns
+
+Reference material for identifying and challenging implicit assumptions in business requirements analysis.
+
+## Challenge Question 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?" |
+
+## Elicitation 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?"
+
+## MoSCoW Prioritization Template
+
+When client classifies ALL features as "must-have", apply this blocking challenge:
+
+```
+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: "{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'}"
+```
+
+If client moves items → update categories. If client confirms ALL mustHave → accept but log in changelog.

package/templates/skills/business-analyse/references/cadrage-coverage-matrix.md

@@ -1,74 +1,74 @@
-# Coverage Matrix with Sections & Resources
-
-Reference for building and validating the coverage matrix that maps requirements to modules, sections, and resources.
-
-## Section Rule (CRITICAL)
-
-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
-
-## Coverage Matrix Template
-
-Print a markdown table with columns: **Fonctionnalité | Priorité | Module | Section | Resources clés | Onglets détail**
-
-### Example
-
-```
-| 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 | — | — | — | — |
-```
-
-## Priority Distribution POST-CHECK (BLOCKING)
-
-```javascript
-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
-
-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"
-```
-
-## Cross-Cutting Coverage POST-CHECK (WARNING)
-
-```javascript
-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?
-```
-
-## Building Coverage Matrix from Feature Analysis
-
-For EACH distinct feature/requirement identified during phases 2-4:
-
-1. Create an entry in `cadrage.coverageMatrix[]`
-2. Assign it to mustHave, shouldHave, couldHave, or outOfScope
-3. Assign the module that will cover it (or null if cross-cutting)
-4. **List anticipated sections** (Level 4) — ONLY functional zones
-5. **List anticipated resources** (Level 5) for each section
-6. **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.
+# Coverage Matrix with Sections & Resources
+
+Reference for building and validating the coverage matrix that maps requirements to modules, sections, and resources.
+
+## Section Rule (CRITICAL)
+
+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
+
+## Coverage Matrix Template
+
+Print a markdown table with columns: **Fonctionnalité | Priorité | Module | Section | Resources clés | Onglets détail**
+
+### Example
+
+```
+| 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 | — | — | — | — |
+```
+
+## Priority Distribution POST-CHECK (BLOCKING)
+
+```javascript
+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
+
+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"
+```
+
+## Cross-Cutting Coverage POST-CHECK (WARNING)
+
+```javascript
+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?
+```
+
+## Building Coverage Matrix from Feature Analysis
+
+For EACH distinct feature/requirement identified during phases 2-4:
+
+1. Create an entry in `cadrage.coverageMatrix[]`
+2. Assign it to mustHave, shouldHave, couldHave, or outOfScope
+3. Assign the module that will cover it (or null if cross-cutting)
+4. **List anticipated sections** (Level 4) — ONLY functional zones
+5. **List anticipated resources** (Level 5) for each section
+6. **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.

package/templates/skills/business-analyse/references/cadrage-pre-analysis.md

@@ -1,115 +1,115 @@
-# Cadrage: Pre-Analysis Reference
-
-> Reference for step-01-cadrage.md — silent pre-analysis to PREPARE the interactive conversation.
-> **This file does NOT replace the conversation — it prepares it.**
-
-## Purpose
-
-Before engaging the client, the AI silently analyzes the `{feature_description}` to:
-1. Understand what was said (extract explicit requirements)
-2. Detect what was NOT said (identify shadow zones to challenge)
-3. Prepare targeted questions (not generic ones)
-4. Pre-identify modules, sections, and resources
-
-**The output of this pre-analysis is INTERNAL ONLY.** It is never shown directly to the client — it feeds the reformulation (Phase 2) and challenge questions (Phase 3).
-
-## Pre-Analysis Rules
-
-### 1. Problem Type Inference
-
-Derive the problem type from `{feature_description}` keywords:
-
-```yaml
-problem_type:
-  → Keywords "remplacer", "migrer", "existant" → "replace" (existing tool to replace)
-  → Keywords "automatiser", "manuel", "processus" → "automate" (manual process to automate)
-  → Keywords "centraliser", "dispersees", "eparpillees" → "centralize" (data scattered across systems)
-  → Default (new tool) → "new_tool" (no system in place)
-```
-
-### 2. Explicit Module/Feature Extraction
-
-Extract functional areas explicitly mentioned in the description:
-
-```yaml
-detected_modules:
-  → For each distinct functional area mentioned:
-    - name: "{PascalCase module name}"
-    - description: "{what the user said about it}"
-    - detected_sections: ["{inferred sections based on description}"]
-    - detected_resources: ["{inferred resources}"]
-```
-
-### 3. Shadow Zone Detection (CRITICAL)
-
-> **Shadow zones are the most valuable output of pre-analysis.**
-> They become the challenge questions in Phase 3.
-
-For EACH detected module, check for missing information:
-
-| What to check | Shadow zone if missing | Challenge question pattern |
-|--------------|----------------------|--------------------------|
-| Stakeholders | Who uses this module? | "Who interacts with {module} daily? Only {mentioned role} or also managers, admins, external users?" |
-| Cardinality | Relationships stated as fact | "You said {A} is 1:1 with {B}. Can {A} exist without {B}? Can {B} have multiple {A}?" |
-| Granularity | Level of detail unclear | "What granularity for {feature}? Day, half-day, hour? Single entry or batch?" |
-| Reports | Mentioned but not detailed | "Which reports exactly? For whom? What format? How often?" |
-| Validation workflow | Actions without approval | "Does {action} require approval? Who validates? What happens if rejected?" |
-| Edge cases | Only happy path described | "What happens when {something goes wrong}? When data is incomplete? When two users do it simultaneously?" |
-| Non-functional | Security, performance, compliance | "Is there sensitive data (GDPR)? Expected concurrent users? Compliance requirements?" |
-| Integration | Standalone or connected | "Does {module} need to exchange data with external systems? Import? Export? API?" |
-
-### 4. Domain-Specific Anticipation Patterns
-
-When the problem domain is identified, pre-load domain-specific needs:
-
-| Domain keywords | Anticipated needs (suggest in Phase 4) |
-|----------------|---------------------------------------|
-| RH, employes, personnel | Contrats, competences, organigramme, RGPD, conges, jours feries, calendriers |
-| Temps, activites, absences | Granularite saisie, validation manageriale, soldes conges, compteurs, export paie |
-| Ventes, commandes, clients | Devis, factures, pipeline, relances, taux conversion, segments client |
-| Stock, inventaire, produits | Categories, fournisseurs, seuils reapprovisionnement, mouvements, valorisation |
-| Projets, taches, planning | Jalons, ressources, Gantt, charge, budget, risques projet |
-| Tickets, support, incidents | SLA, escalade, base connaissances, satisfaction, priorites |
-| Documents, GED | Versionning, workflows validation, templates, OCR, archivage legal |
-
-### 5. Section & Resource Pre-Identification
-
-For each detected module, anticipate sections (Level 4) and resources (Level 5) based on feature type:
-
-| Feature type | Sections (functional zones) | Resources (in list section) | Detail page tabs |
-|-------------|---------------------------|---------------------------|------------------|
-| data-centric | list | {entity}-grid, {entity}-filters, {entity}-form | Infos, {relations} |
-| workflow | list, approve | {entity}-grid, {entity}-filters, {entity}-form, approval-queue | Infos, {relations}, Historique |
-| reporting | dashboard | summary-chart, kpi-cards, export-panel | — |
-| integration | list | sync-status-grid, config-form, log-viewer | Infos, Config, Logs |
-
-> **RULE:** Sections = functional zones only (`list`, `dashboard`, `approve`, `import`, `rapport`, `planning`).
-> `create`/`edit` = separate pages with own URL routes (`/create` and `/:id/edit`). `detail` = tabbed page reached by clicking a row in `list`.
-
-**Always check:** Does the user's description imply additional functional sections? (e.g., "reports" → `dashboard`, "calendar view" → `planning`, "approval workflow" → `approve`)
-
-## Output Format (Internal Only)
-
-```yaml
-pre_analysis:
-  problem_type: "new_tool|replace|automate|centralize"
-  detected_modules:
-    - name: "ModuleName"
-      description: "What the user said"
-      detected_sections: ["list", "detail", "create"]
-      detected_resources: ["entity-grid", "entity-form"]
-  shadow_zones:
-    - topic: "Cardinality Employee-User"
-      why_it_matters: "1:1 assumption may not hold for temp workers"
-      challenge_question: "Can a user be linked to multiple employee records?"
-    - topic: "Report granularity"
-      why_it_matters: "Reports mentioned but not specified"
-      challenge_question: "Which reports exactly? For whom? What format?"
-  anticipated_suggestions:
-    - suggestion: "Leave balance management"
-      justification: "Time tracking without leave balances is incomplete"
-      module: "TimeTracking"
-    - suggestion: "GDPR compliance module"
-      justification: "HR data is personal data under GDPR"
-      module: "Employees"
-```
+# Cadrage: Pre-Analysis Reference
+
+> Reference for step-01-cadrage.md — silent pre-analysis to PREPARE the interactive conversation.
+> **This file does NOT replace the conversation — it prepares it.**
+
+## Purpose
+
+Before engaging the client, the AI silently analyzes the `{feature_description}` to:
+1. Understand what was said (extract explicit requirements)
+2. Detect what was NOT said (identify shadow zones to challenge)
+3. Prepare targeted questions (not generic ones)
+4. Pre-identify modules, sections, and resources
+
+**The output of this pre-analysis is INTERNAL ONLY.** It is never shown directly to the client — it feeds the reformulation (Phase 2) and challenge questions (Phase 3).
+
+## Pre-Analysis Rules
+
+### 1. Problem Type Inference
+
+Derive the problem type from `{feature_description}` keywords:
+
+```yaml
+problem_type:
+  → Keywords "remplacer", "migrer", "existant" → "replace" (existing tool to replace)
+  → Keywords "automatiser", "manuel", "processus" → "automate" (manual process to automate)
+  → Keywords "centraliser", "dispersees", "eparpillees" → "centralize" (data scattered across systems)
+  → Default (new tool) → "new_tool" (no system in place)
+```
+
+### 2. Explicit Module/Feature Extraction
+
+Extract functional areas explicitly mentioned in the description:
+
+```yaml
+detected_modules:
+  → For each distinct functional area mentioned:
+    - name: "{PascalCase module name}"
+    - description: "{what the user said about it}"
+    - detected_sections: ["{inferred sections based on description}"]
+    - detected_resources: ["{inferred resources}"]
+```
+
+### 3. Shadow Zone Detection (CRITICAL)
+
+> **Shadow zones are the most valuable output of pre-analysis.**
+> They become the challenge questions in Phase 3.
+
+For EACH detected module, check for missing information:
+
+| What to check | Shadow zone if missing | Challenge question pattern |
+|--------------|----------------------|--------------------------|
+| Stakeholders | Who uses this module? | "Who interacts with {module} daily? Only {mentioned role} or also managers, admins, external users?" |
+| Cardinality | Relationships stated as fact | "You said {A} is 1:1 with {B}. Can {A} exist without {B}? Can {B} have multiple {A}?" |
+| Granularity | Level of detail unclear | "What granularity for {feature}? Day, half-day, hour? Single entry or batch?" |
+| Reports | Mentioned but not detailed | "Which reports exactly? For whom? What format? How often?" |
+| Validation workflow | Actions without approval | "Does {action} require approval? Who validates? What happens if rejected?" |
+| Edge cases | Only happy path described | "What happens when {something goes wrong}? When data is incomplete? When two users do it simultaneously?" |
+| Non-functional | Security, performance, compliance | "Is there sensitive data (GDPR)? Expected concurrent users? Compliance requirements?" |
+| Integration | Standalone or connected | "Does {module} need to exchange data with external systems? Import? Export? API?" |
+
+### 4. Domain-Specific Anticipation Patterns
+
+When the problem domain is identified, pre-load domain-specific needs:
+
+| Domain keywords | Anticipated needs (suggest in Phase 4) |
+|----------------|---------------------------------------|
+| RH, employes, personnel | Contrats, competences, organigramme, RGPD, conges, jours feries, calendriers |
+| Temps, activites, absences | Granularite saisie, validation manageriale, soldes conges, compteurs, export paie |
+| Ventes, commandes, clients | Devis, factures, pipeline, relances, taux conversion, segments client |
+| Stock, inventaire, produits | Categories, fournisseurs, seuils reapprovisionnement, mouvements, valorisation |
+| Projets, taches, planning | Jalons, ressources, Gantt, charge, budget, risques projet |
+| Tickets, support, incidents | SLA, escalade, base connaissances, satisfaction, priorites |
+| Documents, GED | Versionning, workflows validation, templates, OCR, archivage legal |
+
+### 5. Section & Resource Pre-Identification
+
+For each detected module, anticipate sections (Level 4) and resources (Level 5) based on feature type:
+
+| Feature type | Sections (functional zones) | Resources (in list section) | Detail page tabs |
+|-------------|---------------------------|---------------------------|------------------|
+| data-centric | list | {entity}-grid, {entity}-filters, {entity}-form | Infos, {relations} |
+| workflow | list, approve | {entity}-grid, {entity}-filters, {entity}-form, approval-queue | Infos, {relations}, Historique |
+| reporting | dashboard | summary-chart, kpi-cards, export-panel | — |
+| integration | list | sync-status-grid, config-form, log-viewer | Infos, Config, Logs |
+
+> **RULE:** Sections = functional zones only (`list`, `dashboard`, `approve`, `import`, `rapport`, `planning`).
+> `create`/`edit` = separate pages with own URL routes (`/create` and `/:id/edit`). `detail` = tabbed page reached by clicking a row in `list`.
+
+**Always check:** Does the user's description imply additional functional sections? (e.g., "reports" → `dashboard`, "calendar view" → `planning`, "approval workflow" → `approve`)
+
+## Output Format (Internal Only)
+
+```yaml
+pre_analysis:
+  problem_type: "new_tool|replace|automate|centralize"
+  detected_modules:
+    - name: "ModuleName"
+      description: "What the user said"
+      detected_sections: ["list", "detail", "create"]
+      detected_resources: ["entity-grid", "entity-form"]
+  shadow_zones:
+    - topic: "Cardinality Employee-User"
+      why_it_matters: "1:1 assumption may not hold for temp workers"
+      challenge_question: "Can a user be linked to multiple employee records?"
+    - topic: "Report granularity"
+      why_it_matters: "Reports mentioned but not specified"
+      challenge_question: "Which reports exactly? For whom? What format?"
+  anticipated_suggestions:
+    - suggestion: "Leave balance management"
+      justification: "Time tracking without leave balances is incomplete"
+      module: "TimeTracking"
+    - suggestion: "GDPR compliance module"
+      justification: "HR data is personal data under GDPR"
+      module: "Employees"
+```

package/templates/skills/business-analyse/references/cadrage-shared-modules.md

@@ -1,69 +1,68 @@
-# Cross-Application Shared Module Detection
-
-Reference for detecting and extracting shared modules when `workflow_mode = "project"`.
-
-## Detection Algorithm
-
-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"] }
-}
-```
-
-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) }));
-```
-
-## Extraction Logic
-
-If shared modules found, propose extraction:
-
-```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.
-
-## Question Template
-
-```
-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'}"
-```
+# Cross-Application Shared Module Detection
+
+Reference for detecting and extracting shared modules when `workflow_mode = "project"`.
+
+## Detection Algorithm
+
+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"] }
+}
+```
+
+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) }));
+```
+
+## Extraction Logic
+
+If shared modules found, propose extraction:
+
+```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],
+    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.
+
+## Question Template
+
+```
+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'}"
+```