@atlashub/smartstack-cli 3.2.0 → 3.3.1

package/templates/skills/business-analyse/_shared.md

@@ -1,33 +1,12 @@
-# Business Analysis - Shared Functions (v4 - Iterative Multi-Module Workflow)
+# Business Analysis - Shared Core
 
-> **Ref:** This file contains common functions for all BA phases.
-> **Version:** 4.0 - Iterative multi-module workflow with 5-level navigation hierarchy
-
----
-
-## Architecture Progressive
-
-The BusinessAnalyse skill uses **progressive loading** to minimize context:
-
-```
-SKILL.md (entry point) → routes to use case
-    ↓
-steps/step-00-init.md (parse flags, create master feature.json via ba-writer)
-    ↓
-steps/step-01-cadrage.md (framing: context, stakeholders, scope, roles)
-    ↓
-steps/step-02-decomposition.md (module identification, dependency graph, CLIENT CHECKPOINT)
-    ↓
-steps/step-03-specify.md (ITERATIVE per module: sections, entities, BR, permissions, mockups)
-    ↓                      ↻ loops back for each module in dependency order
-steps/step-04-consolidation.md (cross-module validation, E2E flows, permissions coherence)
-    ↓
-steps/step-05-handoff.md (generates ralph prd.json per module)
-```
-
-**No digest files needed** — each step reads/writes `feature.json` directly via `ba-writer` and `ba-reader` agents.
-
-**Benefit:** ~70% context reduction per phase
+> **Ref:** Core shared functions loaded by ALL BA steps.
+>
+> **Conditional files (loaded per-step as needed):**
+> - `_elicitation.md` — Interactive protocol, techniques 1-8, AskUserQuestion format, ULTRATHINK
+> - `_architecture.md` — SmartStack 5 layers, entity base classes, DB conventions, SeedData Core
+> - `_module-loop.md` — Module iteration protocol, state management, resume logic
+> - `_suggestions.md` — Proactive suggestions, Context7 libraries
 
 ---
 
@@ -78,25 +57,25 @@ The BA aligns with the SmartStack navigation hierarchy:
 
 ```
 Level 1: Context (business)
-  └── Level 2: Application (Sales)
-       ├── Level 3: Module (Customers)
-       │    ├── Level 4: Section (list)
-       │    │    └── Level 5: Ressource (customer-card)
-       │    ├── Level 4: Section (detail)
-       │    │    └── Level 5: Ressource (customer-form)
-       │    └── Level 4: Section (create)
-       └── Level 3: Module (Orders)
-            ├── Level 4: Section (list)
-            ├── Level 4: Section (detail)
-            ├── Level 4: Section (create)
-            └── Level 4: Section (approve)
+  Level 2: Application (Sales)
+       Level 3: Module (Customers)
+            Level 4: Section (list)
+                 Level 5: Ressource (customer-card)
+            Level 4: Section (detail)
+                 Level 5: Ressource (customer-form)
+            Level 4: Section (create)
+       Level 3: Module (Orders)
+            Level 4: Section (list)
+            Level 4: Section (detail)
+            Level 4: Section (create)
+            Level 4: Section (approve)
 ```
 
 | BA Phase | Levels treated | What is defined |
 |----------|---------------|-----------------|
 | Cadrage (step-01) | Context + Application | Problem, stakeholders, scope, application-level roles |
 | Decomposition (step-02) | Modules | Module list, dependencies, processing order |
-| Specification (step-03) | Module → Sections → Resources | Entities, BR, UC, permissions, ASCII/SVG mockups per section |
+| Specification (step-03) | Module -> Sections -> Resources | Entities, BR, UC, permissions, ASCII/SVG mockups per section |
 | Consolidation (step-04) | Cross-module | Interactions, permission coherence, E2E flows |
 | Handoff (step-05) | All levels | Implementation mapping, prd.json |
 
@@ -119,74 +98,6 @@ Level 1: Context (business)
 
 ---
 
-## Module Loop Protocol
-
-> **Step-03 iterates over modules.** State is persisted in the master feature.json.
-
-### State Management
-
-```json
-{
-  "metadata": {
-    "workflow": {
-      "mode": "application",
-      "moduleOrder": ["Customers", "Products", "Orders", "Invoices"],
-      "currentModuleIndex": 2,
-      "completedModules": ["Customers", "Products"],
-      "currentModule": "Orders"
-    }
-  }
-}
-```
-
-### Loop Logic (end of each step-03 iteration)
-
-```
-1. Mark current module as "validated" in master feature.json
-2. Add to completedModules[]
-3. IF currentModuleIndex + 1 < moduleOrder.length:
-     currentModuleIndex++
-     currentModule = moduleOrder[currentModuleIndex]
-     Write master feature.json
-     Display: "Module {name} complete. Next: {next_name} ({N}/{total})"
-     RE-LOAD: steps/step-03-specify.md
-4. ELSE:
-     master.status = "specified"
-     Load: steps/step-04-consolidation.md
-```
-
-### Context Management During Loop
-
-To prevent context explosion as modules accumulate:
-- **Current module:** Load full module feature.json
-- **Completed modules:** Only load compact summary via `ba-reader.getCompletedModulesSummary()` (max 100 lines)
-- **Master feature.json:** Only read workflow state + application roles
-
-### Resume After Interruption
-
-```
-1. ba-reader.findApplicationFeature() → locate master feature.json
-2. Read metadata.workflow.currentModuleIndex
-3. IF currentModule has a feature.json with status != "validated":
-     Resume step-03-specify for that module
-4. ELSE:
-     Start step-03-specify for next module
-```
-
----
-
-## Use Case Routing
-
-| Flag | Use Case | Workflow |
-|------|----------|---------|
-| (none) | Single module | step-00 → step-01 → step-02 (trivial) → step-03 (1 iteration) → step-04 (auto) → step-05 |
-| `-app` | Application (multi-module) | step-00 → step-01 → step-02 → step-03 (N iterations) → step-04 → step-05 |
-| `-q FEAT-ID "question"` | Question | ba-reader.answerQuestion → EXIT |
-| `-r FEAT-ID "change"` | Refactoring | ba-writer.createVersion → step-01 (delta) → step-02 → step-03 → step-04 → step-05 |
-| `-m` | Micro-feature | step-00 (minimal) → step-05 (simplified) |
-
----
-
 ## Business Context Validation
 
 ```
@@ -202,168 +113,47 @@ validate_business_context(context):
 
 ---
 
-## Architecture SmartStack (Référence BA)
-
-> **Objectif :** Fournir le contexte architectural au BA pour des questions pertinentes et des recommandations alignées.
-
-### 5 Couches (Clean Architecture)
-
-| Couche | Projet | Contenu | Impact BA |
-|--------|--------|---------|-----------|
-| **Domain** | `SmartStack.Domain` | Entités, enums, interfaces | Entités identifiées en discovery |
-| **Application** | `SmartStack.Application` | CQRS (Commands/Queries), validations, DTOs | Use cases de la spécification |
-| **Infrastructure** | `SmartStack.Infrastructure` | EF Core, services externes, jobs | Intégrations et contraintes techniques |
-| **API** | `SmartStack.API` | Controllers REST, permissions | Endpoints et sécurité |
-| **Web** | `smartstack-web` | React 19, pages, composants | UI/UX et navigation |
-
-### Hiérarchie de Navigation
-
-```
-Context (business) → Application (Sales) → Module (Orders) → Section (list/detail)
-```
-
-Route pattern : `/business/{application}/{module}/{section}`
-
-### Classes de Base des Entités
-
-| Classe | Interface | Champs auto-inclus | Quand utiliser |
-|--------|-----------|---------------------|----------------|
-| `BaseEntity` | - | `Id` (Guid), `TenantId`, `CreatedAt`, `UpdatedAt` | **Défaut pour toute entité métier** |
-| `BaseEntity` | `IAuditableEntity` | + `CreatedBy`, `UpdatedBy` | Entité avec audit complet |
-| `SystemEntity` | - | `Id` (Guid), `CreatedAt` (pas de TenantId) | Entités système (navigation, permissions) |
-| `BaseEntity` | `ISoftDeletable` | + `IsDeleted`, `DeletedBy`, `DeletedAt` | Entité avec suppression logique |
-| `HierarchicalEntity` | - | + `ParentId`, `Level`, `Path` | Arborescences (catégories, menus) |
-
-> **IMPORTANT :** Ne JAMAIS proposer `CreatedBy`, `UpdatedBy`, `IsDeleted`, `TenantId` comme champs explicites — ils sont AUTOMATIQUES via la classe de base ou l'interface.
-
-### Services d'Intégration Disponibles
-
-| Service | Interface | Quand le proposer |
-|---------|-----------|-------------------|
-| Notifications in-app | `INotificationService` | Alertes, événements, rappels |
-| Workflow automatisé | `IWorkflowService` | Emails transactionnels, webhooks, actions chaînées |
-| Complétion IA | `IAICompletionService` | Suggestions, classification, génération contenu |
-| SignalR temps réel | `IHubContext<BusinessHub>` | Mises à jour en temps réel |
-| Jobs planifiés | Hangfire `IBackgroundJobClient` | Traitements différés, purges, imports |
-
-### Conventions Base de Données
-
-| Aspect | Convention | Exemple |
-|--------|------------|---------|
-| Schema | `core` (socle SmartStack) vs `extensions` (entités client/métier) | `core.auth_Roles`, `extensions.bik_FreeBickes` |
-| Tables | `{prefix}_{EntityPlural}` (préfixe domaine + PascalCase pluriel) | `auth_Users`, `nav_Applications`, `supp_Tickets` |
-| Préfixes domaine | `auth_` (auth), `nav_` (navigation), `cfg_` (config), `ref_` (références), `wkf_` (workflows), `ai_` (IA), `loc_` (i18n), `lic_` (licences), `tenant_` (tenants), `support_` (support) | Pour un nouveau module métier : choisir un préfixe court (3-5 chars) |
-| FK | `{Entity}Id` (ex: `ClientId`, `OrderId`) | |
-| Index | `IX_{Table}_{Column}` | `IX_bik_FreeBickes_TenantId_Code` |
-| Migration | 1 migration par feature, nommée via MCP (`suggest_migration`) | `extensions_v1.0.0_001_AddFreeBicke` |
-
-### Conventions de Dossiers (Clean Architecture)
-
-| Couche | Pattern de dossiers | Exemple (module FreeBicke dans business > operations) |
-|--------|--------------------|---------------------------------------------------------|
-| **Domain** | `{Project}.Domain/Business/{Application}/{Module}/` | `Domain/Business/Operations/FreeBicke/FreeBicke.cs` |
-| **Application/DTOs** | `{Project}.Application/Business/{Application}/{Module}/DTOs/` | `Application/Business/Operations/FreeBicke/DTOs/FreeBickeDto.cs` |
-| **Application/Interfaces** | `{Project}.Application/Common/Interfaces/` | `Application/Common/Interfaces/IFreeBickeService.cs` |
-| **Infrastructure/Config** | `{Project}.Infrastructure/Persistence/Configurations/{Module}/` | `Configurations/FreeBicke/FreeBickeConfiguration.cs` |
-| **Infrastructure/Services** | `{Project}.Infrastructure/Services/{Module}/` | `Services/FreeBicke/FreeBickeService.cs` |
-| **Infrastructure/SeedData** | `{Project}.Infrastructure/Persistence/Seeding/Data/{Module}/` | `Seeding/Data/FreeBicke/FreeBickeSeedData.cs` |
-| **API/Controllers** | `{Project}.Api/Controllers/Business/{Application}/` | `Controllers/Business/Operations/FreeBickeController.cs` |
-| **Frontend/Pages** | `web/src/pages/business/{application}/{module}/` | `pages/business/operations/freebicke/page.tsx` |
-| **Frontend/i18n** | `web/src/i18n/locales/{lang}/{module}.json` | `locales/fr/freebicke.json` |
-
-> **IMPORTANT :** Chaque module a son **propre sous-dossier** dans chaque couche. Ne JAMAIS mettre tous les fichiers à la racine d'une couche.
-
-### SeedData Core (Obligatoire pour chaque feature)
-
-> **Chaque nouvelle feature nécessite des SeedData dans 5 fichiers core** pour être fonctionnelle (navigation visible, permissions actives, rôles assignés).
-
-| # | Fichier | Contenu | Mécanisme |
-|---|---------|---------|-----------|
-| 1 | `NavigationModuleConfiguration.cs` | Entrée module dans `nav_Modules` (HasData) | EF Core Migration |
-| 2 | `NavigationTranslationConfiguration.cs` | Traductions du module (4 langues × chaque entité nav) | EF Core Migration |
-| 3 | `PermissionConfiguration.cs` | Permissions CRUD + wildcards dans `nav_Permissions` (HasData) | EF Core Migration |
-| 4 | `Permissions.cs` (Application layer) | Constantes compile-time pour `[RequirePermission]` | Code |
-| 5 | `RolePermissionConfiguration.cs` | Associations rôle-permission dans `auth_RolePermissions` (HasData) | EF Core Migration |
-
-**Rôles par défaut pour chaque application (4 niveaux) :**
-
-| Rôle | Permissions | Description |
-|------|-------------|-------------|
-| **{App} Admin** | `{context}.{app}.*` (wildcard) | Accès complet à l'application |
-| **{App} Manager** | `read`, `create`, `update`, `assign` | Gestion complète sans suppression |
-| **{App} Contributor** | `read`, `create`, `update` | Contribution active |
-| **{App} Viewer** | `read` uniquement | Consultation seule |
-
-> **CRITIQUE :** Si les SeedData ne sont pas créés, le module sera invisible dans la navigation et les permissions retourneront 403.
-
-### Contraintes Non-Négociables
-
-| Contrainte | Détail |
-|------------|--------|
-| **Multi-tenant** | `TenantId` sur toute entité métier, isolation automatique |
-| **RBAC** | Permissions `business.{app}.{module}.{action}`, HasData pattern |
-| **CQRS** | Commands (write) et Queries (read) séparés via MediatR |
-| **Validation** | FluentValidation pour toute commande |
-| **i18n** | 4 langues obligatoires (fr, en, it, de) |
-| **Soft Delete** | Pas de DELETE physique sauf purge RGPD planifiée |
-
-### Outils MCP Pertinents pour le BA
-
-| Phase BA | Outil MCP | Usage |
-|----------|-----------|-------|
-| Pre-research (01) | `analyze_extension_points` | Découvrir modules/entités existants |
-| Pre-research (01) | `api_docs` | Consulter la documentation API existante |
-| Analyse (02) | `validate_conventions` | Vérifier les noms d'entités proposés |
-| Spécification (03) | `generate_permissions` | Générer la matrice de permissions |
-| Handoff (05) | `scaffold_extension` | Préparer le scaffolding |
-
----
-
 ## Feature Directory Structure
 
 ```
 docs/
-├── business/
-│   └── {application}/
-│       ├── business-analyse/
-│       │   ├── schemas/                  ← JSON SCHEMAS (deployed by step-00)
-│       │   │   ├── feature-schema.json
-│       │   │   ├── application-schema.json
-│       │   │   ├── sections/
-│       │   │   │   ├── analysis-schema.json
-│       │   │   │   ├── discovery-schema.json
-│       │   │   │   ├── handoff-schema.json
-│       │   │   │   ├── metadata-schema.json
-│       │   │   │   ├── specification-schema.json
-│       │   │   │   └── validation-schema.json
-│       │   │   └── shared/
-│       │   │       └── common-defs.json
-│       │   └── v1.0/
-│       │       └── feature.json          ← APPLICATION master ($schema: ../schemas/application-schema.json)
-│       ├── {module1}/
-│       │   └── business-analyse/
-│       │       └── v1.0/
-│       │           └── feature.json      ← MODULE detail ($schema: ../../../business-analyse/schemas/feature-schema.json)
-│       └── {module2}/
-│           └── business-analyse/
-│               └── v1.0/
-│                   └── feature.json      ← MODULE detail
+  business/
+    {application}/
+        business-analyse/
+            schemas/                  <- JSON SCHEMAS (deployed by step-00)
+                feature-schema.json
+                application-schema.json
+                sections/
+                    analysis-schema.json
+                    discovery-schema.json
+                    handoff-schema.json
+                    metadata-schema.json
+                    specification-schema.json
+                    validation-schema.json
+                shared/
+                    common-defs.json
+            v1.0/
+                feature.json          <- APPLICATION master ($schema: ../schemas/application-schema.json)
+        {module1}/
+            business-analyse/
+                v1.0/
+                    feature.json      <- MODULE detail ($schema: ../../../business-analyse/schemas/feature-schema.json)
+        {module2}/
+            business-analyse/
+                v1.0/
+                    feature.json      <- MODULE detail
 ```
 
 **Ralph Loop Integration (generated by step-05):**
 
 ```
 .ralph/
-├── prd.json          # Task breakdown derived from handoff (for /ralph-loop -r)
-├── progress.txt      # Links back to BA feature documents
-├── logs/
-└── reports/
+  prd.json          # Task breakdown derived from handoff (for /ralph-loop -r)
+  progress.txt      # Links back to BA feature documents
+  logs/
+  reports/
 ```
 
-**Integrated Documentation (SmartStack app):**
-- Application view: `/docs/business/{app}` → reads master feature.json
-- Module view: `/docs/business/{app}/{module}` → reads module feature.json
-
 ---
 
 ## Feature ID Generation
@@ -378,252 +168,6 @@ generate_feature_id():
 
 ---
 
-## Models by Phase (Step)
-
-| Step | Model | Reason |
-|------|-------|--------|
-| 00-init | Haiku | Quick structure setup |
-| 01-cadrage | **Opus** | ULTRATHINK framing |
-| 02-decomposition | Sonnet | Module identification + dependency analysis |
-| 03-specify | **Opus** | ULTRATHINK per-module specification |
-| 04-consolidation | Sonnet | Cross-module validation |
-| 05-handoff | **Opus** | Zero-ambiguity prompt |
-
----
-
-## Interactive Elicitation Protocol
-
-> **RULE: ALL questions MUST be asked interactively using `AskUserQuestion`.**
-> **NEVER dump a list of questions as text. ALWAYS use the tool.**
-
-### Protocol
-
-1. **Group questions by theme** — max 4 questions per `AskUserQuestion` call (tool limit)
-2. **Propose predefined options** — for questions with predictable answers, provide 2-4 options
-3. **The user can always choose "Other"** — the tool adds this automatically for free-text answers
-4. **Process answers immediately** — apply ULTRATHINK + follow-ups before moving to next group
-5. **Adapt next questions** — based on previous answers, skip irrelevant questions
-
-### Batching Strategy
-
-| Category | Questions | Batches |
-|----------|-----------|---------|
-| 01-context | Q1.1-Q1.4 | 1 call |
-| 02-stakeholders | Q2.1-Q2.8 | 2 calls |
-| 03-scope | Q3.1-Q3.8 | 2 calls |
-| 04-data | Q4.1-Q4.8 | 2 calls |
-| 05-integrations | Q5.1-Q5.8 | 2 calls |
-| 06-security | Q6.1-Q6.8 | 2 calls |
-| 07-ui | Q7.1-Q7.8 | 2 calls |
-| 08-performance | Q8.1-Q8.4 | 1 call |
-| 09-constraints | Q9.1-Q9.4 | 1 call |
-| 10-documentation | Q10.1-Q10.4 | 1 call |
-| 11-data-lifecycle | Q11.1-Q11.8 | 2 calls |
-| 12-migration | Q12.1-Q12.8 | 2 calls |
-| 13-cross-module | Q13.1-Q13.8 | 2 calls |
-
-### AskUserQuestion Format
-
-> **⚠️ FORMATTING CRITICAL: `AskUserQuestion` does NOT support markdown or line breaks.**
-> Le champ `question` est rendu en texte brut (plain text). Il n'y a pas de retour à la ligne,
-> pas de gras, pas de puces. Une question simple reste lisible meme longue. Mais du contenu
-> structuré (listes, résumés multi-points, tableaux) devient un mur de texte illisible.
-
-| Field | Rule |
-|-------|------|
-| `question` | **1 question ou 1 phrase.** Jamais de liste, résumé multi-points ou contenu structuré. |
-| `header` | 1-2 mots (max 12 chars) |
-| `label` (option) | Court et clair (~20 chars) |
-| `description` (option) | 1 phrase explicative (~60 chars) |
-
-> **Pour afficher du contenu structuré** (résumés, listes, tableaux, synthèses) :
-> **TOUJOURS** utiliser du **texte direct** (output text) AVANT l'appel `AskUserQuestion`.
-> Le texte direct supporte le markdown et sera correctement formaté avec titres, puces, gras, etc.
->
-> **Exemple — Validation de synthèse :**
-> 1. Afficher le résumé structuré en markdown (texte direct)
-> 2. Puis poser une question courte : "Cette synthèse est-elle correcte ?"
-
-```
-AskUserQuestion({
-  questions: [
-    {
-      question: "Quel problème métier ce module doit-il résoudre ?",
-      header: "Problème",       // max 12 chars
-      options: [
-        { label: "Processus manuel", description: "Automatiser un processus existant fait manuellement" },
-        { label: "Données dispersées", description: "Centraliser des données éparpillées dans plusieurs outils" },
-        { label: "Manque visibilité", description: "Obtenir des indicateurs et du suivi inexistants aujourd'hui" },
-        { label: "Conformité", description: "Répondre à une obligation réglementaire ou de sécurité" }
-      ],
-      multiSelect: false
-    },
-    // ... up to 4 questions per call
-  ]
-})
-```
-
-### After Each Batch
-
-1. **Evaluate answer quality** (see Answer Quality Indicators)
-2. **If insufficient** → follow-up AskUserQuestion with targeted probes from the Elicitation Guide
-3. **If solution-oriented** → reframe using Technique 1 before proceeding
-4. **If sufficient/excellent** → record and move to next batch
-5. **Summarize** what was understood before moving to the next category
-
----
-
-## Techniques d'elicitation
-
-> **Charge par :** step-01-cadrage (Opus ULTRATHINK)
-> **Objectif :** Guider COMMENT questionner, pas seulement QUOI demander.
-> **Principe :** Chaque technique doit etre appliquee naturellement dans le flux de la conversation,
-> pas comme un outil supplementaire. L'analyste choisit la technique adaptee a la situation.
-
-### Technique 1 : Reformulation du besoin
-
-Quand le client decrit une **solution** (bouton, ecran, champ, outil), reformuler en **besoin** :
-
-| Le client dit | L'analyste demande |
-|---------------|-------------------|
-| "Il me faut un menu deroulant pour les roles" | "Quel probleme rencontrez-vous aujourd'hui avec la gestion des acces ? Pourquoi certaines personnes doivent-elles avoir des acces differents ?" |
-| "On a besoin d'un bouton d'export" | "Que faites-vous avec les donnees une fois exportees ? Qui en a besoin et pourquoi ?" |
-| "Ajoutez un champ statut" | "Quel parcours suit cet element du debut a la fin ? Quels evenements declenchent un changement d'etat ?" |
-
-### Technique 2 : Chaine des pourquoi
-
-Quand le besoin semble superficiel, enchainez jusqu'a 5 "Pourquoi ?" pour trouver la cause racine :
-
-```
-Client : "On a besoin de suivre l'activite des utilisateurs"
-→ Pourquoi ? "Pour savoir qui a modifie quoi"
-→ Pourquoi ? "Parce qu'on a eu des problemes de donnees incorrectes"
-→ Pourquoi ? "Parce que plusieurs personnes modifient les memes fiches"
-→ CAUSE RACINE : Conflit d'edition simultanee → Besoin de journal d'activite + protection des modifications
-```
-
-### Technique 3 : Extraction de scenario concret
-
-Ne jamais accepter de descriptions abstraites. Toujours demander un **scenario de vie reelle** :
-
-```
-"Racontez-moi une journee type : vous arrivez au bureau, vous ouvrez l'application.
- Quelle est la PREMIERE chose que vous devez faire ?
- Puis ensuite ? Quelles informations consultez-vous ? Quelles decisions prenez-vous ?"
-```
-
-### Technique 4 : Test d'absence
-
-Valider la necessite en demandant ce qui se passe SANS :
-
-```
-"Si cette fonctionnalite N'EXISTAIT PAS, que feriez-vous a la place ?
- Combien de temps ou d'argent le contournement actuel coute-t-il ?"
-```
-
-### Technique 5 : Verification de completude
-
-Pour chaque reponse sous forme de liste, verifier qu'il ne manque rien :
-
-| Type de reponse | Relance |
-|-----------------|---------|
-| "Il y a 3 types d'utilisateurs" | "Y a-t-il des acteurs externes ? Des auditeurs ? Des administrateurs systeme ? Des processus automatiques ?" |
-| "Le flux principal est A puis B puis C" | "Que se passe-t-il si l'utilisateur annule a l'etape B ? Si l'etape C echoue ? S'il veut revenir a A ?" |
-| "Champs obligatoires : nom et email" | "Quelles contraintes d'unicite ? Quel format ? Que se passe-t-il en cas de doublon ?" |
-
-### Technique 6 : Projection dans le futur
-
-Demander au client de se projeter pour decouvrir des besoins non exprimes :
-
-```
-"Imaginons que nous sommes 2 ans dans le futur et que l'application fonctionne parfaitement.
- Qu'est-ce qui a change dans votre facon de travailler ?
- Quels nouveaux besoins sont apparus auxquels vous ne pensez pas aujourd'hui ?"
-```
-
-### Technique 7 : Test de contradiction
-
-Quand deux reponses semblent contradictoires, les confronter pour clarifier :
-
-```
-"Vous avez mentionne que [affirmation A], mais vous dites aussi que [affirmation B].
- Ces deux elements semblent en tension. Pouvez-vous m'aider a comprendre
- comment ils coexistent dans la realite ?"
-```
-
-### Technique 8 : Escalade d'impact
-
-Augmenter progressivement l'echelle pour tester les limites :
-
-```
-"Aujourd'hui vous avez 50 fiches. Que se passe-t-il avec 500 ? Avec 5000 ?
- Est-ce que le processus reste le meme ou faudrait-il faire differemment ?"
-```
-
-### Indicateurs de qualite des reponses
-
-| Qualite | Signal | Action |
-|---------|--------|--------|
-| **Insuffisante** | Moins d'une phrase, "je ne sais pas", adjectif vague | Appliquer les techniques 1 a 8, demander un exemple concret |
-| **Orientee solution** | Contient des termes d'interface ou techniques (bouton, champ, base de donnees) | Appliquer la technique 1 (reformuler en besoin) |
-| **Suffisante** | Contient QUI, QUOI, POURQUOI et un exemple concret | Continuer, noter le niveau de confiance |
-| **Excellente** | Inclut les cas limites, les contraintes et des criteres mesurables | Continuer, marquer comme "Confirme" |
-
----
-
-## ULTRATHINK
-
-Behavioral mode for critical phases (01, 02, 04):
-
-```
-ULTRATHINK MODE:
-- Consider ALL edge cases
-- Challenge EVERY assumption
-- Anticipate UNEXPRESSED needs
-- Validate completeness before output
-- Apply Elicitation Techniques (see above)
-
-DO NOT:
-- Accept vague answers
-- Skip question categories
-- Assume stakeholder thought of everything
-- Accept solutions without understanding the problem first
-```
-
-**DO NOT invoke** as a skill/tool - it is a thinking mode.
-
----
-
-## Proactive Suggestions
-
-After scope definition in step-01, the skill suggests complementary modules/sections:
-
-1. Analyze feature type and scope from questionnaire answers
-2. Load `patterns/suggestion-catalog.md`
-3. Match against catalog patterns
-4. Present suggestions via AskUserQuestion (accept/reject per suggestion)
-5. Store in feature.json.suggestions[]
-
-Accepted suggestions become candidates for future /business-analyse runs.
-
----
-
-## Context7 (Step 04)
-
-```
-Prompt pattern:
-"use context7 with /facebook/react and /i18next/react-i18next
- to generate {component} following SmartStack patterns"
-```
-
-Libraries:
-- `/facebook/react` - React 19 patterns
-- `/i18next/react-i18next` - Internationalization
-- `/remix-run/react-router` - React Router v7
-- `/lucide-icons/lucide-react` - Icons
-
----
-
 ## Permission Path Format
 
 **Format:** `business.{application}.{module}.{action}`
@@ -685,8 +229,8 @@ State is persisted in `feature.json.metadata` and `feature.json.metadata.steps`.
 
 ```
 resume_workflow(feat_id):
-  1. ba-reader.findFeature(feat_id) → latest feature.json
-  2. Read feature.json.metadata.steps → find last completed step
+  1. ba-reader.findFeature(feat_id) -> latest feature.json
+  2. Read feature.json.metadata.steps -> find last completed step
   3. Load next step file
   4. If not found in docs/: fallback to .business-analyse/ (legacy)
 ```
@@ -697,10 +241,10 @@ resume_workflow(feat_id):
 
 ```
 {STEP_NAME} - {feature_id}
-├── Status: {status in feature.json}
-├── Section enriched: {discovery|analysis|specification|validation|handoff}
-├── feature.json: {path}
-└── Next: {next step name}
+  Status: {status in feature.json}
+  Section enriched: {discovery|analysis|specification|validation|handoff}
+  feature.json: {path}
+  Next: {next step name}
 ```
 
 ---
@@ -709,42 +253,42 @@ resume_workflow(feat_id):
 
 > **Objectif :** La langue de communication avec le client est configurable.
 > Toute interaction via `AskUserQuestion` (questions, options, reformulations, relances)
-> doit être dans la langue configurée.
+> doit etre dans la langue configuree.
 
 ### Configuration
 
-Le champ `language` dans `feature.json.metadata.language` définit la langue :
+Le champ `language` dans `feature.json.metadata.language` definit la langue :
 
-| Langue | Code | Défaut |
+| Langue | Code | Defaut |
 |--------|------|--------|
-| Français | `fr` | **Oui** |
+| Francais | `fr` | **Oui** |
 | English | `en` | Non |
 | Italiano | `it` | Non |
 | Deutsch | `de` | Non |
 
-### Portée
+### Portee
 
-| Élément | Adapté à la langue ? |
+| Element | Adapte a la langue ? |
 |---------|---------------------|
 | Questions `AskUserQuestion` (labels, descriptions, options) | **OUI** — toujours dans `{language}` |
-| Reformulations et résumés de catégorie | **OUI** — toujours dans `{language}` |
-| Relances et follow-ups (Elicitation Guide) | **OUI** — traduire les probes à la volée |
-| Documents générés (discovery, analysis, specification, handoff) | **OUI** — rédigés dans `{language}` |
-| Référence technique interne (patterns, architecture) | NON — reste en langue du fichier |
-| Noms de code (entités, permissions, paths) | NON — toujours en anglais (convention plateforme) |
+| Reformulations et resumes de categorie | **OUI** — toujours dans `{language}` |
+| Relances et follow-ups (Elicitation Guide) | **OUI** — traduire les probes a la volee |
+| Documents generes (discovery, analysis, specification, handoff) | **OUI** — rediges dans `{language}` |
+| Reference technique interne (patterns, architecture) | NON — reste en langue du fichier |
+| Noms de code (entites, permissions, paths) | NON — toujours en anglais (convention plateforme) |
 
-### Règle
+### Regle
 
 ```
-1. Lire {language} depuis feature.json.metadata.language (défaut: "fr")
+1. Lire {language} depuis feature.json.metadata.language (defaut: "fr")
 2. Adapter TOUTE communication AskUserQuestion dans {language}
-3. Les exemples de probes/relances dans les questionnaires sont en français
-   → Si {language} ≠ "fr", les traduire à la volée
-4. Les documents générés sont rédigés dans {language}
-5. Le code, les noms d'entités et les paths restent TOUJOURS en anglais
+3. Les exemples de probes/relances dans les questionnaires sont en francais
+   -> Si {language} != "fr", les traduire a la volee
+4. Les documents generes sont rediges dans {language}
+5. Le code, les noms d'entites et les paths restent TOUJOURS en anglais
 6. Ne JAMAIS utiliser "SmartStack" dans les communications utilisateur
-   → Utiliser "la plateforme", "l'application" ou "le système" à la place
-   → SmartStack est le nom interne du framework, le projet client a son propre nom
+   -> Utiliser "la plateforme", "l'application" ou "le systeme" a la place
+   -> SmartStack est le nom interne du framework, le projet client a son propre nom
 ```
 
 ---