@atlashub/smartstack-cli 4.81.0 → 5.0.0

package/templates/skills/business-analyse/questionnaire/02-stakeholders-scope.md

@@ -1,111 +0,0 @@
-# Catégorie 2 : Parties prenantes et périmètre
-
-> **Usage :** Identifier les profils utilisateurs, leurs droits, et délimiter le périmètre fonctionnel
-> **Quand charger :** TOUJOURS (noyau)
-> **Objectif :** Comprendre QUI utilise le système, avec quels DROITS, et QUOI il doit faire
-
----
-
-## 2.1 Identification des utilisateurs
-
-> **But :** Identifier les types de profils/rôles qui interagiront avec le système.
-
-| # | Question | Type de réponse |
-|---|----------|-----------------|
-| Q2.1 | Qui sont les types de profils qui utiliseront ce système ? Décrivez leurs rôles et ce qu'ils font. | Liste de profils utilisateurs |
-
----
-
-## 2.2 Tâches par profil
-
-> **But :** Comprendre concrètement ce que chaque type d'utilisateur fait.
-
-| # | Question | Type de réponse |
-|---|----------|-----------------|
-| Q2.5 | Pour chaque type d'utilisateur : quelles sont les 3 à 5 tâches principales qu'il doit accomplir avec ce système ? | Tâches par profil utilisateur |
-
----
-
-## 2.3 Les niveaux d'accès
-
-> **But :** Définir les règles métier de permissions par rôle (SmartStack gère nativement RBAC + isolation tenant).
-> **Note :** Ne PAS demander le modèle de visibilité (cloisonné, tout visible, etc.) — SmartStack utilise toujours RBAC avec isolation tenant. Se concentrer sur les RÈGLES MÉTIER : quel rôle accède à quoi.
-
-| # | Question | Type de réponse |
-|---|----------|-----------------|
-| Q2.9 | Pour chaque profil identifié, quelles données ou sections doivent lui être restreintes ? Y a-t-il des données sensibles visibles uniquement par certains rôles ? | Restrictions par rôle |
-| Q2.10 | Qui a le droit de modifier ou supprimer des informations ? Tout le monde ou seulement certaines personnes ? | Règles de modification |
-| Q2.11 | Y a-t-il des actions sensibles qui nécessitent une validation par un supérieur ? | Liste des actions à valider |
-
----
-
-## 2.4 Limites du périmètre (OBLIGATOIRE)
-
-> **But :** Borner ce que le système ne doit PAS faire. Essentiel pour eviter le scope creep.
-
-| # | Question | Type de réponse |
-|---|----------|-----------------|
-| Q2.15 | Y a-t-il des choses que le système ne doit explicitement PAS faire ? Des limites claires à poser ? | Liste d'exclusions |
-
-> **Note :** La detection des fonctionnalites IN-SCOPE est couverte par la reformulation (phase 2 de step-01).
-> L'IA detecte les modules depuis le brief + domain research et les presente pour validation.
-> Il n'est donc plus necessaire de demander au client de lister ses features (ex-Q2.12) ni de les classifier (ex-Q2.13).
-
----
-
-## 2.5 Parcours principal (DEPLACE vers step-03)
-
-> **IMPORTANT :** Les questions Q2.16 (parcours), Q2.17 (decisions), Q2.18 (erreurs) ont ete **deplacees vers step-03-specify**.
-> Elles alimentent directement les use cases par module et evitent la duplication cadrage → specification.
-> En step-01, le parcours est capture dans la reformulation : "Le parcours type que j'ai compris est X → Y → Z. Correct ?"
-
----
-
-## 2.6 Intégrations et systèmes externes (CONDITIONNEL)
-
-> **But :** Identifier les échanges de données avec l'extérieur et les migrations initiales.
-> **Condition :** Poser UNIQUEMENT si le brief mentionne un systeme externe, une integration, une migration ou un import de donnees.
-> Si non pertinent : `cadrage.externalIntegrations = []` et `cadrage.dataImport = null` (auto-rempli).
-
-| # | Question | Type de réponse |
-|---|----------|-----------------|
-| Q2.19 | Ce système doit-il échanger des données avec d'autres outils ? (comptabilité, email, banque, API tierces) | Liste d'intégrations |
-| Q2.20 | Y a-t-il des données existantes à importer lors du démarrage ? (Excel, ancien système) | Description import |
-
-- Mapping → `cadrage.json` : champs `externalIntegrations[]` et `dataImport`
-
----
-
-## Guide d'élicitation approfondi
-
-### Techniques de relance
-
-| Question | Si la réponse est vague | Relance recommandée |
-|----------|------------------------|---------------------|
-| Q2.1 (utilisateurs) | Un seul type mentionné | "Pensez aux différents moments de la journée : qui saisit ? Qui consulte les rapports ? Qui gère les cas particuliers ?" |
-| Q2.1 (utilisateurs) | Utilisateurs hors entreprise mentionnés (clients, fournisseurs, partenaires) | "Quelles données ces utilisateurs externes doivent-ils consulter ou créer ? Quelles restrictions par rapport aux internes ?" |
-| Q2.5 (tâches) | Tâches génériques | "Quand il arrive le matin et ouvre le système, quelle est sa première action ?" |
-| Q2.9 (restrictions) | Réponse ambiguë | "Un employé voit-il les données salariales ? Un manager voit-il uniquement son équipe ou toute l'entreprise ?" |
-| Q2.15 (exclusions) | "Je ne vois pas" | "Certains utilisateurs pourraient-ils s'attendre à des fonctionnalités que vous ne souhaitez PAS inclure ?" |
-
-### Signaux d'alerte à détecter
-
-| Signal du client | Problème sous-jacent | Action de l'analyste |
-|------------------|---------------------|----------------------|
-| "Tous les utilisateurs font la même chose" | Rôles non différenciés | "Qui peut supprimer ? Qui ne fait que consulter ? Qui valide ?" |
-| "Tout le monde doit tout voir" | Restrictions non définies | "Quelles données sont sensibles ? Un manager voit-il les données de toutes les équipes ou seulement la sienne ?" |
-| Aucune exclusion identifiée | Périmètre non borné | "Y a-t-il des aspects qui relèvent d'un autre projet ou d'une version future ?" |
-| "Nos clients doivent pouvoir..." ou "Les fournisseurs voient..." | Utilisateurs externes accédant au système | Classifier auto en 4b-bis. Approfondir les RÈGLES MÉTIER : quelles données, quelles actions, quelles restrictions ? |
-
----
-
-## Mapping vers le cadrage
-
-| Réponse | Alimente | Remplissage |
-|---------|----------|-------------|
-| Q2.1, Q2.5 | `cadrage.stakeholders[]` | Reponse directe |
-| Q2.9-Q2.11 | `cadrage.applicationRoles[]` | Reponse directe |
-| Q2.15 | `cadrage.globalScope.excluded` | Reponse directe |
-| Q2.19, Q2.20 | `cadrage.externalIntegrations[]`, `cadrage.dataImport` | Reponse directe OU auto-rempli (vide) si non pertinent |
-| (reformulation) | `cadrage.globalScope.inScope` | Auto-deduit depuis brief + domain research, confirme en phase 2 |
-| (step-03) | `cadrage.coverageMatrix` | Construit lors de la specification des use cases |

package/templates/skills/business-analyse/questionnaire/03-data-ui.md

@@ -1,125 +0,0 @@
-# Catégorie 3 : Données et interface
-
-> **Usage :** Définir les entités, les règles de données et l'expérience utilisateur
-> **Quand charger :** Par module, lors de la spécification (step-03)
-> **Objectif :** Comprendre les données manipulées et comment elles sont présentées
-
----
-
-## 3.1 Entites et attributs
-
-| # | Question | Type de reponse |
-|---|----------|-----------------|
-| Q3.1 | Quelles sont les entités principales gérées par ce module ? | Liste d'entités |
-| Q3.2 | Pour chaque entité : quels sont les attributs importants ? | Par entité |
-| Q3.3 | Quelles relations existent entre les entités ? (appartient à, contient, référence) | Schéma relationnel |
-| Q3.5 | Pour chaque entité : le Code doit-il être auto-généré ou saisi par l'utilisateur ? | Par entité |
-| Q3.6 | Si auto-généré : quelle stratégie ? (séquentiel, timestamp, année, UUID court) | Par entité |
-
-## 3.2 Règles de données
-
-| # | Question | Type de réponse |
-|---|----------|-----------------|
-| Q3.7 | Quelles validations sur les données ? (champs obligatoires, formats, plages de valeurs) | Liste de règles |
-| Q3.8 | Y a-t-il des règles inter-champs ? (date fin > date début, montant selon statut) | Liste de contraintes |
-| Q3.9 | Données sensibles à protéger ? (données personnelles, financières, médicales) | Liste + niveau |
-
----
-
-## 3.3 Interface et écrans
-
-| # | Question | Type de réponse |
-|---|----------|-----------------|
-| Q3.10 | Périphériques cibles ? (desktop, mobile, tablette) | Liste |
-| Q3.11 | Écrans principaux nécessaires pour ce module ? | Liste d'écrans |
-| Q3.12 | Informations clés par écran ? Quelles colonnes dans la liste, quels champs dans le formulaire ? | Par écran |
-| Q3.13 | Actions possibles par écran ? (créer, éditer, supprimer, valider, exporter, changer statut) | Par écran |
-
-## 3.5 Volumétrie et performance
-
-| # | Question | Type de réponse |
-|---|----------|-----------------|
-| Q3.17 | Combien de [entité] prévoyez-vous ? (par mois et total à 2 ans) | Estimation chiffrée |
-| Q3.18 | Y a-t-il des pics d'utilisation ? (fin de mois, clôture annuelle) | Description des pics |
-
-- Relance si vague : "Moins de 100 ? Entre 100-10 000 ? Plus de 10 000 ?"
-- Mapping → `entities.json` : champ `estimatedVolume` (`monthly`, `total2y`)
-
-## 3.6 Recherche et filtres
-
-| # | Question | Type de réponse |
-|---|----------|-----------------|
-| Q3.19 | Par quels critères cherchez-vous un [entité] ? (nom, date, statut, code...) | Liste de critères |
-| Q3.20 | Quels filtres rapides sont indispensables dans la liste ? | Liste de filtres |
-
-- Relance : "Triez-vous souvent par date ? Filtrez-vous par statut ?"
-- Mapping → `entities.json` : champs `searchableFields[]` et `defaultFilters[]`
-
-## 3.7 Notifications et alertes
-
-| # | Question | Type de réponse |
-|---|----------|-----------------|
-| Q3.21 | Quels événements doivent déclencher une notification ? (création, approbation, deadline...) | Liste d'événements |
-| Q3.22 | Qui doit être notifié ? Par quel canal ? (in-app, email) | Cible + canal |
-
-- Mapping → `rules.json` : règles de catégorie `notification`
-
-## 3.4 Tableaux de bord
-
-| # | Question | Type de réponse |
-|---|----------|-----------------|
-| Q3.14 | Des tableaux de bord ou indicateurs sont-ils requis pour ce module ? | Oui/Non + description |
-| Q3.15 | KPIs à afficher ? (nom, métrique, format, seuils d'alerte) | Par dashboard |
-| Q3.16 | Types de graphiques souhaités ? (barres, lignes, camembert, cartes KPI) | Par KPI |
-
----
-
-## Guide d'élicitation approfondi
-
-### Techniques de relance
-
-| Question | Si la réponse est vague | Relance recommandée |
-|----------|------------------------|---------------------|
-| Q3.1 (entités) | Une seule entité | "Cette entité a-t-elle des sous-éléments ? (lignes de détail, pièces jointes, historique)" |
-| Q3.1 (entités) | Mention de "User" | "L'utilisateur est géré par la plateforme. Décrivez l'entité MÉTIER (Client, Employee, Contact...)" |
-| Q3.2 (attributs) | Champs techniques (ID, CreatedDate) | "Les champs techniques sont auto-gérés. Quels sont les attributs MÉTIER ?" |
-| Q3.3 (relations) | "1:N" sans détail | "Un {Parent} peut avoir combien de {Children} max ? Un {Child} peut-il exister sans {Parent} ?" |
-| Q3.11 (écrans) | "Un écran de liste" | "Avec pages dédiées pour création et édition ? Détail en page avec onglets ?" |
-| Q3.13 (actions) | "CRUD classique" | "Actions métier spécifiques ? (valider, dupliquer, archiver, changer statut, assigner)" |
-| Q3.14 (dashboards) | "Juste des chiffres" | "Les tendances ne seraient-elles pas plus lisibles en graphique ?" |
-| Q3.17 (volume) | "Je ne sais pas" | "Commençons petit : combien d'employés dans l'entreprise ? Combien de factures par mois environ ?" |
-
-### Anti-patterns à détecter
-
-| Signal | Anti-pattern | Action |
-|--------|-------------|--------|
-| Entité "User" avec attributs métier | Confusion User/Identity | La plateforme gère les Users via Identity |
-| Attributs Id, TenantId, CreatedBy | Champs techniques comme métier | Ces champs sont auto-générés par AuditableEntity |
-| "Un seul gros formulaire avec tout" | Formulaire monolithique | Proposer des onglets ou wizard par section logique |
-| Actions sans confirmation | Actions destructives non protégées | "La suppression nécessite-t-elle une confirmation ?" |
-
----
-
-## RBAC Exclusion
-
-> Les concepts suivants sont gérés par le système RBAC de la plateforme et NE DOIVENT PAS être modélisés comme attributs d'entité :
-
-| Concept | Wrong (attribut) | Correct (RBAC) |
-|---------|-----------------|----------------|
-| Role utilisateur | `User.Role` | Permission set `{app}.{module}.*` |
-| Niveau d'acces | `User.AccessLevel` | Permission matrix per role |
-| Est admin | `User.IsAdmin` | `{app}.{module}.admin` permission |
-
----
-
-## Mapping vers le feature
-
-| Réponse | Alimente |
-|---------|----------|
-| Q3.1-Q3.3, Q3.5-Q3.6 | `entities.json` (entités, attributs, relations, codePattern) |
-| Q3.7-Q3.9 | `rules.json` (règles métier de validation et sécurité) |
-| Q3.10-Q3.13 | `screens.json` (sections, resources, colonnes, actions) |
-| Q3.14-Q3.16 | `screens.json` (sections dashboard, KPI resources) |
-| Q3.17-Q3.18 | `entities.json` (estimatedVolume) |
-| Q3.19-Q3.20 | `entities.json` (searchableFields, defaultFilters) |
-| Q3.21-Q3.22 | `rules.json` (règles category: notification) |

package/templates/skills/business-analyse/questionnaire/04-risks-metrics.md

@@ -1,6 +0,0 @@
-# Categorie 4 : Risques et criteres de reussite
-
-> **NOT USED** — Les risques projet, hypotheses, lecons du passe, metriques de succes et conditions de livraison
-> ne sont pas du scope de la BA en vibe coding.
->
-> La documentation technique est generee automatiquement par `/documentation` apres `/business-analyse-develop`.

package/templates/skills/business-analyse/questionnaire/05-cross-module.md

@@ -1,69 +0,0 @@
-# Catégorie 5 : Impact cross-module
-
-> **Usage :** Analyser l'impact sur les modules existants et les dépendances partagées
-> **Quand charger :** TOUJOURS pour les nouveaux modules (pas les améliorations)
-> **Objectif :** Détecter les interactions, les entités partagées et les impacts d'intégration
-
----
-
-## 5.1 Dépendances avec les modules existants
-
-| # | Question | Type de réponse |
-|---|----------|-----------------|
-| Q5.1 | Avec quels modules existants ce nouveau module interagit-il ? | Liste de modules |
-| Q5.2 | Quelles données sont partagées entre modules ? (entités, tables de référence) | Par module |
-| Q5.3 | Y a-t-il des entités existantes que ce module va référencer ? (relations FK) | Liste de références |
-| Q5.4 | Ce module produira-t-il des événements que d'autres modules consomment ? | Liste d'événements |
-
-## 5.2 Évaluation d'impact
-
-| # | Question | Type de réponse |
-|---|----------|-----------------|
-| Q5.5 | Les modules existants doivent-ils être modifiés pour supporter ce nouveau module ? | Liste de changements |
-| Q5.6 | Y a-t-il des composants UI ou des changements de navigation partagés ? | Liste |
-| Q5.7 | Ce module affectera-t-il les permissions ou rôles existants ? Quel impact sur l'intégration ? | Oui/Non + détail |
-| Q5.8 | Y a-t-il des entités partagées modifiées par plusieurs modules ? Quel impact sur l'intégration ? | Évaluation de l'impact |
-
----
-
-## Cross-Module Patterns
-
-| Besoin | Pattern | Exemple |
-|--------|---------|---------|
-| Référence une entité | Navigation property + FK | `Order.ClientId -> Client` |
-| Données de référence partagées | Entité partagée dans Domain | `Status`, `Category` |
-| Notification événementielle | MediatR notification | `OrderCreatedNotification` |
-| Requête cross-module | DTO en lecture seule | `IClientQueryService` |
-| Lien de navigation | NavRoute entry | `business/{app}/{module}` |
-| Permission partagée | Hiérarchie de permissions | `{app}.*` covers all modules |
-
----
-
-## Guide d'élicitation
-
-### Techniques de relance
-
-| Question | Si la réponse est vague | Relance recommandée |
-|----------|------------------------|---------------------|
-| Q5.1 (interactions) | "Aucun" | "Ce module est totalement isolé ? Pas de lien avec des clients, produits, utilisateurs d'autres modules ?" |
-| Q5.2 (données partagées) | "Je ne sais pas" | Utiliser le `{codebase_context}` : "J'ai trouvé les entités {list}. Ce module a-t-il besoin de les référencer ?" |
-| Q5.3 (FK références) | Vague | "Une {entity} de ce module appartient-elle à un {existing_entity} ?" |
-| Q5.4 (événements) | "Non" | "Quand un {entity} est créé/modifié/supprimé, faut-il notifier un autre module ?" |
-| Q5.8 (impact) | "Pas d'impact" | "Deux modules modifient-ils la même entité ? Quel est l'impact sur l'intégration ?" |
-
-### Anti-patterns à détecter
-
-| Signal | Anti-pattern | Action |
-|--------|-------------|--------|
-| Module totalement isolé | Silo de données | Rare qu'un module métier n'ait aucune connexion. Vérifier avec le codebase context. |
-| Duplication d'entité existante | Entité dupliquée | Si `Client` existe déjà, ne pas créer `Customer`. Référencer l'existant. |
-| Modification d'entité d'un autre module | Couplage fort | Utiliser des événements (MediatR) plutôt que des modifications directes. |
-
----
-
-## Mapping vers la consolidation
-
-| Réponse | Alimente |
-|---------|----------|
-| Q5.1-Q5.4 | `consolidation.crossModuleInteractions[]`, `consolidation.sharedEntities[]` |
-| Q5.5-Q5.8 | `consolidation.impactAssessment[]`, `consolidation.permissionCoherence` |

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

@@ -1,156 +0,0 @@
-# Elicitation Questionnaire - Business Analysis
-
-> **Usage:** Structured questions for step-01-cadrage and step-03-specify
-> **Standard:** BABOK v3 - Elicitation Techniques (Interactive analysis)
-> **Model:** OPUS with ULTRATHINK
-> **Total:** ~15 targeted questions across 4 active questionnaire files
-
----
-
-## ULTRATHINK RULE
-
-```
-+==============================================================================+
-|  ULTRATHINK: Deep thinking mode for exhaustive elicitation                   |
-+==============================================================================+
-|                                                                              |
-|  During the analyse phase, Claude MUST:                                      |
-|  - Consider ALL edge cases before formulating a question                     |
-|  - Challenge EVERY stakeholder assumption                                    |
-|  - Anticipate unexpressed needs                                              |
-|  - Validate completeness before moving to next question                      |
-|                                                                              |
-|  DO NOT:                                                                     |
-|  - Accept vague answers                                                      |
-|  - Skip question categories                                                  |
-|  - Assume stakeholder has thought of everything                              |
-|                                                                              |
-+==============================================================================+
-```
-
----
-
-## Questionnaire Files (v2)
-
-### Classification des questions
-
-| Marqueur | Signification |
-|----------|---------------|
-| **OBLIGATOIRE** | DOIT etre posee dans tous les cas |
-| **CONDITIONNEL** | Posee uniquement si la condition est remplie |
-| **RELANCE** | Posee si la reponse precedente est vague |
-
-#### Questionnaire 01 (cadrage)
-- Q1.1 : OBLIGATOIRE
-- Q1.4 : CONDITIONNEL (si problem_type = "replace" ou "automate" — pas pour systemes neufs)
-- Q1.8 : OBLIGATOIRE
-
-#### Questionnaire 02 (cadrage)
-- Q2.1 : OBLIGATOIRE
-- Q2.5 : OBLIGATOIRE
-- Q2.9 : OBLIGATOIRE
-- Q2.10 : OBLIGATOIRE
-- Q2.11 : OBLIGATOIRE
-- Q2.15 : OBLIGATOIRE
-- Q2.19 : CONDITIONNEL (si brief mentionne un systeme externe ou integration)
-- Q2.20 : CONDITIONNEL (si brief mentionne migration ou import de donnees)
-
-> **Questions SUPPRIMEES (v3) :**
-> - Q2.12 (lister features) : redondant — l'IA detecte les modules depuis le brief, la reformulation (phase 2) sert de validation
-> - Q2.13 (classifier vital/important/optionnel) : inutile — SmartStack construit tous les modules, la classification ne change rien au code genere
-> - Q2.16-Q2.18 (parcours, decisions, erreurs) : **deplaces vers step-03** — alimentent directement les use cases, evite la duplication
-
-#### Questionnaire 03 (specification, par module)
-- Q3.1 : OBLIGATOIRE
-- Q3.2 : OBLIGATOIRE
-- Q3.3 : OBLIGATOIRE
-- Q3.5 : OBLIGATOIRE
-- Q3.7 : OBLIGATOIRE
-- Q3.8 : CONDITIONNEL (si entites avec relations temporelles)
-- Q3.9 : OBLIGATOIRE
-- Q3.10 : CONDITIONNEL (premier module uniquement, reutilise ensuite)
-- Q3.11-Q3.13 : CONDITIONNEL (couvert par /business-analyse-design)
-- Q3.14-Q3.16 : CONDITIONNEL (si dashboard mentionne dans cadrage)
-- Q3.17 : OBLIGATOIRE
-- Q3.19 : OBLIGATOIRE
-- Q3.20 : OBLIGATOIRE
-- Q3.21 : OBLIGATOIRE
-- Q3.22 : CONDITIONNEL (si Q3.21 = oui)
-
-| File | Questions | Phase | Focus |
-|------|-----------|-------|-------|
-| `questionnaire/01-context.md` | 2-3 | step-01-cadrage | Business process, vision (+ friction points si remplacement) |
-| `questionnaire/02-stakeholders-scope.md` | 6-8 | step-01-cadrage | User profiles, access levels, exclusions (+ integrations/import si pertinent) |
-| `questionnaire/03-data-ui.md` | ~15 | step-03-specify (per module) | Data entities, UI expectations, dashboards |
-| `questionnaire/04-risks-metrics.md` | — | NOT USED | Risks/metrics out of BA scope |
-| `questionnaire/05-cross-module.md` | ~8 | step-03-specify (conditional) | Cross-module dependencies, integration impact |
-
----
-
-## Utilisation des questionnaires
-
-### Correspondance avec les phases
-
-| Phase | Questionnaires charges |
-|-------|----------------------|
-| step-01-cadrage | 01-context, 02-stakeholders-scope |
-| step-03-specify (par module) | 03-data-ui, conditionnellement 05-cross-module |
-
-### Phase de cadrage (step-01) — 3 batches
-
-> **Principe vibe coding :** L'utilisateur decrit son besoin, l'IA deduit et propose. Les questions servent a CONFIRMER et APPROFONDIR, pas a interroger.
-
-**Batch 1 — Contexte & Vision** (Q1.1, Q1.8, + Q1.4 si remplacement) :
-- Processus metier, vision cible, frictions (si applicable)
-
-**Batch 2 — Utilisateurs & Acces** (Q2.1, Q2.5, Q2.9-Q2.11) :
-- Profils, taches, restrictions, droits, validations
-
-**Batch 3 — Perimetre & Limites** (Q2.15, + Q2.19/Q2.20 si pertinent) :
-- Exclusions, integrations (conditionnel), import (conditionnel)
-
-**Regles :**
-1. **Adapter :** Sauter les questions non pertinentes selon le contexte
-2. **Approfondir :** Poser des questions de relance sur les reponses vagues
-3. **Challenger :** Ne pas accepter "on verra plus tard" sur les fonctionnalites indispensables
-
-### Phase de specification (step-03)
-
-1. **Par module :** Charger 03-data-ui pour chaque module en cours de spécification
-2. **Cross-module :** Charger 05-cross-module si le module a des dépendances identifiées en step-02
-
-### Questions de relance
-
-Pour chaque réponse vague, utiliser :
-- "Pouvez-vous me donner un exemple concret ?"
-- "Comment mesurez-vous cela aujourd'hui ?"
-- "Que se passe-t-il si cette règle n'est pas respectée ?"
-- "Qui est impacté par cette décision ?"
-
-### Mode Auto-déduction (step-03)
-
-> **Par défaut, step-03 utilise l'auto-déduction avec confirmation groupée.**
-> L'IA propose entités, règles, UCs et permissions basées sur le cadrage + recherche domaine,
-> puis demande une confirmation par lot au lieu de poser chaque question individuellement.
-
-| Mode | Déclencheur | Comportement |
-|------|------------|-------------|
-| **Auto-déduction** (défaut) | Cadrage complet + domaine clair | Proposition → confirmation groupée → questions ciblées si ambigu |
-| **Interactif** | Cadrage incomplet ou domaine inconnu | Questions individuelles Q3.1-Q3.22 |
-
-**Workflow auto-déduction :**
-1. L'IA construit la proposition à partir du cadrage + recherche domaine (A-bis)
-2. Présente le LOT complet : "Voici ce que je propose. Corrections ?"
-3. Le client valide, corrige ou demande des détails
-4. Les questions détaillées ne sont posées QUE pour les points ambigus
-
-**Traçabilité :** Le mode utilisé est tracé dans `config.json` : `specificationMode: "auto-deduction" | "interactive"`
-
-> **IMPORTANT :** L'auto-déduction ne dispense PAS de la validation client.
-> Chaque lot (entités, règles, UCs, permissions) DOIT être confirmé avant écriture.
-
-### Filtre de pertinence
-
-Chaque question conservée passe ce test :
-> "La réponse change-t-elle quelque chose dans le système a construire ?"
-> Oui -> Conserver | Non -> Supprimer