@atlashub/smartstack-cli 4.74.0 → 4.75.0

package/templates/skills/business-analyse/patterns/suggestion-catalog.md

@@ -9,25 +9,35 @@
 
 ## 1. Module Patterns
 
-Suggests companion modules based on primary module type:
-
-| Module Type | Keywords | Suggested Modules | Rationale |
-|-------------|----------|-------------------|-----------|
-| **Orders/Commandes** | order, commande, purchase, sales order | Invoices, Shipping, Returns, OrderLines, Customers | Orders are complete business objects; need billing, logistics, and related tables |
-| **Clients/Customers** | client, customer, contact, account, party | Contacts, Addresses, Contracts, Documents, CRM | Customers have multiple contact types, billing addresses, legal relationships |
-| **Products/Articles** | product, article, item, catalog, sku | Categories, Inventory, Pricing, Suppliers, Images | Products need organization, stock tracking, and multiple pricing strategies |
-| **Employees/HR** | employee, staff, personnel, team, workforce | Leaves, TimeTracking, Evaluations, Documents, Departments | Employees have time off needs, performance management, and asset allocation |
-| **Tickets/Support** | ticket, support, incident, issue, case | SLA, Escalation, KnowledgeBase, Categories, Notifications | Support systems need SLA tracking, knowledge base, and routing logic |
-| **Projects** | project, task, milestone, workplan, roadmap | Tasks, Milestones, Resources, Budgets, Timeline | Projects decompose into work items, need resource allocation, and progress tracking |
-| **Invoices/Billing** | invoice, billing, payment, receipt, statement | Payments, CreditNotes, Dunning, Taxes, Subscriptions | Invoicing is incomplete without payment tracking, refunds, and tax handling |
-| **Inventory/Stock** | inventory, stock, warehouse, goods, warehouse | StockMovements, Locations, Transfers, Alerts, AuditLog | Stock control needs movement tracking, multi-location support, and alerts |
-| **Documents** | document, file, attachment, media, archive | Categories, Versions, Sharing, Templates, Workflow | Document management requires metadata, versioning, and access control |
-| **Contracts** | contract, agreement, legal, terms, service level | Parties, Obligations, Milestones, Renewal, Templates | Contracts involve multiple parties, obligations tracking, and lifecycle management |
-| **Permissions/Security** | permission, role, access, authority, rbac | UserRoles, Groups, Policies, Audit, Delegation | Permission systems need fine-grained control, group policies, and audit trails |
-| **Notifications** | notification, alert, email, message, broadcast | Templates, Channels, Scheduling, Preferences | Notification systems need template management, multi-channel support, scheduling |
-| **Reporting** | report, dashboard, analytics, BI, metrics | Dashboards, Exports, Scheduling, AlertRules | Reporting needs visualization, scheduled distribution, and data export |
-| **API Management / Integrations** | api, external, integration, webhook, export, data-export, machine-to-machine | ExternalApps, DataExportEndpoints, ExportAccess, AuditLogs, ApiKeys | API platforms need app registration, key management, granular endpoint access, rate limiting, and audit logging |
-| **Client Portal** | portal, external, client, fournisseur, partenaire, tiers | MyRequests, ClientDashboard, PortalNotifications | Les utilisateurs externes ont besoin de vues self-service, suivi de statut et soumission limitée |
+Suggests companion modules based on primary module type. Modules are classified as:
+- **CORE**: Always needed — absence = broken application. In step-02, CORE companions MUST be challenged as BLOCKING.
+- **STANDARD**: Usually needed — absence = incomplete application. Recommended as WARNING.
+- **OPTIONAL**: Nice to have — suggest only if context supports it.
+
+> **CRITICAL — step-02 usage:**
+> CORE companions are NOT optional suggestions. They are MANDATORY challenges.
+> In step-02, for each identified module type, check CORE companions.
+> If a CORE companion is absent → BLOCKING AskUserQuestion:
+> "Module {companion} is a CORE component of {module_type} applications.
+>  (a) Add as module (b) Add as section (c) Exclude with justification"
+
+| Module Type | Keywords | CORE Companions | STANDARD Companions | OPTIONAL Companions | Rationale |
+|-------------|----------|-----------------|---------------------|---------------------|-----------|
+| **Orders/Commandes** | order, commande, purchase, sales order | **Customers, Invoices** | Shipping, Returns | OrderLines | Orders need customer relationships and billing |
+| **Clients/Customers** | client, customer, contact, account, party | **Contacts, Addresses** | Contracts, Documents | CRM | Customers have contacts and addresses at minimum |
+| **Products/Articles** | product, article, item, catalog, sku | **Categories, Pricing** | Inventory, Suppliers | Images | Products need categorization and pricing |
+| **Employees/HR** | employee, staff, personnel, team, workforce | **Leaves, Documents** | Evaluations | TimeTracking, Departments | Employees always need leave mgmt + document storage |
+| **Tickets/Support** | ticket, support, incident, issue, case | **KnowledgeBase, Categories** | SLA, Escalation | Notifications | Support needs KB and categorization at minimum |
+| **Projects** | project, task, milestone, workplan, roadmap | **Tasks, TimeTracking** | Milestones, Resources | Budgets, Timeline | Projects decompose into tasks + need time tracking |
+| **Invoices/Billing** | invoice, billing, payment, receipt, statement | **CreditNotes, Payments** | Dunning, Reporting | Taxes, Subscriptions | Credit notes are legally required; payments are the purpose |
+| **Inventory/Stock** | inventory, stock, warehouse, goods | **StockMovements, Locations** | Transfers, Alerts | AuditLog | Stock needs movement tracking + locations |
+| **Documents** | document, file, attachment, media, archive | **Categories, Versions** | Sharing, Templates | Workflow | Document management needs categorization + versioning |
+| **Contracts** | contract, agreement, legal, terms, service level | **Parties, Milestones** | Obligations, Renewal | Templates | Contracts involve parties + lifecycle milestones |
+| **Permissions/Security** | permission, role, access, authority, rbac | **UserRoles, Policies** | Groups, Audit | Delegation | Permissions need role definitions + policies |
+| **Notifications** | notification, alert, email, message, broadcast | **Templates, Channels** | Scheduling, Preferences | — | Notifications need templates + multi-channel |
+| **Reporting** | report, dashboard, analytics, BI, metrics | **Dashboards, Exports** | Scheduling | AlertRules | Reporting needs visualization + export |
+| **API Management / Integrations** | api, external, integration, webhook, export, data-export, machine-to-machine | **ExternalApps, ApiKeys** | DataExportEndpoints, AuditLogs | ExportAccess | API platforms need app registration + key management |
+| **Client Portal** | portal, external, client, fournisseur, partenaire, tiers | **MyRequests, ClientDashboard** | PortalNotifications | — | External users need self-service views + status tracking |
 
 ---
 
@@ -241,7 +251,7 @@ When user selects suggestions:
       "name": "Email Notifications",
       "source": "Integration Pattern: Email mentioned",
       "accepted": false,
-      "rejectionReason": "Out of scope for MVP"
+      "rejectionReason": "Out of scope for initial delivery"
     }
   ]
 }
@@ -351,19 +361,17 @@ integrationPatterns:
 
 Skip suggestions if:
 
-- **Micro mode:** Skip all suggestions (keep MVP minimal)
+- **Perimetre minimal :** L'utilisateur souhaite garder le perimetre au strict necessaire
 - **Refactoring mode:** Skip module suggestions (only affect feature sections)
 - **User explicitly declines:** Respect user's scope boundary
-- **Budget/timeline constraints:** User indicated fixed scope
+- **Perimetre fixe :** L'utilisateur a indique un perimetre ferme
 
 ```
 Suggested modules: Customers, Shipping, Invoices, Returns
 
-But you indicated:
-  - Timeline: 2 weeks (MVP only)
-  - Budget: 1 developer
+But you indicated a minimal scope.
 
-Suggestion: Start with Orders + Customers (minimal), defer others.
+Suggestion: Start with Orders + Customers (essential), defer others.
 
 [OK] [Adjust scope] [Ignore suggestions]
 ```

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

@@ -2,11 +2,11 @@
 
 > **Usage :** Questions fondamentales pour comprendre le besoin métier
 > **Quand charger :** TOUJOURS (noyau)
-> **Objectif :** Comprendre le processus métier, les frictions, et la vision cible
+> **Objectif :** Comprendre le processus métier et la vision cible
 
 ---
 
-## 1.1 Le processus métier
+## 1.1 Le processus métier (OBLIGATOIRE)
 
 | # | Question | Type de réponse |
 |---|----------|-----------------|
@@ -14,7 +14,11 @@
 
 ---
 
-## 1.2 Les points de friction
+## 1.2 Les points de friction (CONDITIONNEL)
+
+> **Condition :** Poser UNIQUEMENT si `_preAnalysis.problem_type IN ("replace", "automate")`.
+> Pour un système neuf (problem_type = "new_tool" | "centralize"), il n'y a pas de processus existant.
+> Dans ce cas : `cadrage.asIs = "Aucun outil existant — nouveau système"` (auto-rempli).
 
 | # | Question | Type de réponse |
 |---|----------|-----------------|
@@ -22,7 +26,7 @@
 
 ---
 
-## 1.3 La vision souhaitée
+## 1.3 La vision souhaitée (OBLIGATOIRE)
 
 | # | Question | Type de réponse |
 |---|----------|-----------------|
@@ -32,8 +36,8 @@
 
 ## Mapping vers le cadrage
 
-| Réponse | Alimente |
-|---------|----------|
-| Q1.1 | `cadrage.problem` |
-| Q1.4 | `cadrage.asIs` |
-| Q1.8 | `cadrage.toBe` |
+| Réponse | Alimente | Remplissage |
+|---------|----------|-------------|
+| Q1.1 | `cadrage.problem` | Reponse directe |
+| Q1.4 | `cadrage.asIs` | Reponse directe OU auto-rempli si systeme neuf |
+| Q1.8 | `cadrage.toBe` | Reponse directe |

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

@@ -39,38 +39,33 @@
 
 ---
 
-## 2.4 Périmètre fonctionnel
+## 2.4 Limites du périmètre (OBLIGATOIRE)
 
-> **But :** Lister tout ce que le système doit faire et ne pas faire, classifié par importance métier.
-> **Note :** SmartStack développe TOUS les modules identifiés. La classification vital/important/optionnel sert à doser la profondeur de spécification, PAS à phaser la livraison. Ne PAS présenter cette question comme un choix de "premier lancement" ou "quelle app d'abord".
+> **But :** Borner ce que le système ne doit PAS faire. Essentiel pour eviter le scope creep.
 
 | # | Question | Type de réponse |
 |---|----------|-----------------|
-| Q2.12 | Listez toutes les fonctionnalités que vous souhaitez dans ce système. Ne vous censurez pas. | Liste libre de fonctionnalités |
-| Q2.13 | Parmi ces fonctionnalités, classez-les : lesquelles sont VITALES (le système n'a aucun sens sans elles), lesquelles sont IMPORTANTES (forte valeur ajoutée) et lesquelles sont OPTIONNELLES (confort) ? | Classification vital / important / optionnel |
 | Q2.15 | Y a-t-il des choses que le système ne doit explicitement PAS faire ? Des limites claires à poser ? | Liste d'exclusions |
 
-**Test de classification :**
-> Pour chaque fonctionnalité classée comme vitale, poser la question :
-> "Si on enlevait cette fonctionnalité, le système aurait-il encore de la valeur ?"
+> **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 Le parcours principal
+## 2.5 Parcours principal (DEPLACE vers step-03)
 
-> **But :** Comprendre le flux de travail principal de bout en bout.
-
-| # | Question | Type de réponse |
-|---|----------|-----------------|
-| Q2.16 | Décrivez le parcours typique d'un utilisateur du début à la fin : il ouvre le système, que fait-il en premier ? | Liste d'étapes ordonnées |
-| Q2.17 | À quels moments l'utilisateur doit-il prendre une décision ? Quelles sont les options possibles ? | Points de décision et options |
-| Q2.18 | Que se passe-t-il quand quelque chose ne se déroule pas comme prévu ? Quels sont les cas particuliers ? | Scénarios alternatifs |
+> **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
+## 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 |
 |---|----------|-----------------|
@@ -91,9 +86,7 @@
 | 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.13 (indispensable) | Tout est indispensable | "Si vous ne pouviez garder que 3 fonctionnalités pour un premier lancement, lesquelles ?" |
 | Q2.15 (exclusions) | "Je ne vois pas" | "Certains utilisateurs pourraient-ils s'attendre à des fonctionnalités que vous ne souhaitez PAS inclure ?" |
-| Q2.16 (parcours) | Moins de 3 étapes | "Détaillons : l'utilisateur arrive sur l'écran d'accueil. Que voit-il ? Où clique-t-il ?" |
 
 ### Signaux d'alerte à détecter
 
@@ -101,18 +94,18 @@
 |------------------|---------------------|----------------------|
 | "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 ?" |
-| Tout est vital (> 10 vitaux) | Classification non réfléchie | Appliquer le test de classification : "Si on enlevait X, le système aurait-il encore de la valeur ?" |
 | 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 ?" |
-| Parcours linéaire sans alternative | Seul le cas idéal est décrit | "Que se passe-t-il à l'étape X si la condition Y n'est pas remplie ?" |
 | "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 |
-|---------|----------|
-| Q2.1, Q2.5 | `cadrage.stakeholders[]` |
-| Q2.9-Q2.11 | `cadrage.applicationRoles[]` |
-| Q2.12-Q2.13, Q2.15 | `cadrage.globalScope` (vital, important, excluded) |
-| Q2.16-Q2.18 | `cadrage.coverageMatrix` + base pour les cas d'utilisation |
+| 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.md

@@ -3,7 +3,7 @@
 > **Usage:** Structured questions for step-01-cadrage and step-03-specify
 > **Standard:** BABOK v3 - Elicitation Techniques (Interactive analysis)
 > **Model:** OPUS with ULTRATHINK
-> **Total:** ~20 targeted questions across 4 active questionnaire files
+> **Total:** ~15 targeted questions across 4 active questionnaire files
 
 ---
 
@@ -32,10 +32,55 @@
 
 ## 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` | 3 | step-01-cadrage | Business process, friction points, vision |
-| `questionnaire/02-stakeholders-scope.md` | 10 | step-01-cadrage | User profiles, access levels, scope boundaries |
+| `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 |
@@ -51,13 +96,23 @@
 | 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)
+### 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)
 
-1. **Début :** Commencer par 01-context (contexte métier, identité application)
-2. **Adapter :** Sauter les questions non pertinentes selon le contexte
-3. **Approfondir :** Poser des questions de relance sur les réponses vagues
-4. **Challenger :** Ne pas accepter "on verra plus tard" sur les fonctionnalités indispensables
-5. **Par lots :** Présenter 3 a 4 questions par interaction (AskUserQuestion)
+**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)
 
@@ -72,6 +127,28 @@ Pour chaque réponse vague, utiliser :
 - "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 :

package/templates/skills/business-analyse/references/03-json-schemas.md

@@ -0,0 +1,213 @@
+# JSON Schemas (step-03-specify)
+
+## Entity Schema Format
+
+```json
+{
+  "name": "Employee",
+  "description": "Représente un employé de l'entreprise",
+  "personRoleConfig": { "variant": "mandatory", "userFields": ["firstName", "lastName", "email"] },
+  "attributes": [
+    { "name": "code", "type": "string", "required": true, "unique": true, "searchable": true, "description": "Identifiant unique auto-généré" },
+    { "name": "userId", "type": "string", "required": true, "unique": true, "description": "FK vers auth_Users (ASP.NET Identity — type string, NOT guid)" },
+    { "name": "departmentId", "type": "guid", "required": true, "description": "Département d'affectation" },
+    { "name": "hireDate", "type": "date", "required": true, "searchable": true, "description": "Date d'embauche" },
+    { "name": "position", "type": "string", "searchable": true, "description": "Poste occupé" },
+    { "name": "status", "type": "enum", "options": ["Active", "Inactive", "OnLeave", "Terminated"], "defaultValue": "Active", "searchable": true, "description": "Statut de l'employé" }
+  ],
+  "versionedAttributes": [
+    { "entity": "Salary", "attributes": ["grossAmount", "netAmount", "effectiveDate", "currency"], "reason": "Historique salarial versionné" }
+  ],
+  "estimatedVolume": { "monthly": 50, "total2y": 1200 },
+  "searchableFields": ["code", "position", "status"],
+  "defaultFilters": ["status"],
+  "relationships": [
+    { "target": "Department", "type": "ManyToOne", "description": "Appartient à un département" },
+    { "target": "Contract", "type": "OneToMany", "description": "Possède plusieurs contrats" },
+    { "target": "Salary", "type": "OneToMany", "description": "Historique de salaires versionnés" }
+  ]
+}
+```
+
+**Attribute flags (OPTIONAL, default: false):**
+- `unique: true` — attribute has uniqueness constraint (e.g., `code`, `userId`)
+- `searchable: true` — attribute appears in search/filter results (e.g., `code`, `status`, `position`)
+- `computed: true` — attribute value is calculated (e.g., `subtotal`, `total`). **MUST** have a corresponding `BR-CALC` rule with `formula` field
+
+Omit flags when `false` (default). Include explicitly when `true`.
+
+## Business Rules Schema Format
+
+```json
+{
+  "id": "BR-VAL-EMPLOYEES-001",
+  "name": "Validation date embauche",
+  "category": "validation",
+  "sectionCode": "list",
+  "statement": "La date d'embauche ne peut pas être dans le futur",
+  "example": "Date embauche = 2027-01-01 → erreur car > date du jour",
+  "entities": ["Employee"],
+  "severity": "blocking"
+}
+```
+
+Categories: `validation`, `calculation`, `workflow`, `security`, `data`, `notification`
+
+**Mandatory requirements:**
+- Each enum attribute MUST have a `defaultValue`
+- Each bounded numeric attribute MUST have `validation.min/max`
+- FK attributes to Identity (userId) MUST use type `string` (ASP.NET Identity convention)
+- Each attribute marked "computed" in entities.json MUST have a rule with `category: "calculation"` and `formula` field
+
+**Calculation rule example:**
+```json
+{
+  "id": "BR-CALC-INV-003",
+  "category": "calculation",
+  "statement": "Le reste à payer = total - montant payé",
+  "formula": "remainingAmount = total - paidAmount",
+  "entities": ["Invoice"]
+}
+```
+
+**MANDATORY enrichment fields (added in v2):**
+- `severity` : `"blocking"` | `"warning"` | `"info"` — impact level of the rule
+- `sectionCode` : section where this rule applies (e.g., `"list"`, `"approve"`)
+- `examples[]` : structured as `{input: string, expected: string}` — at least 1 per rule
+  ```json
+  "examples": [{ "input": "debut=15/03 fin=12/03", "expected": "Erreur : date de fin avant date de debut" }]
+  ```
+
+**RECOMMENDED enrichment fields:**
+- `conditions[]` : structured IF conditions — `{entity, field, operator, value}`
+  ```json
+  "conditions": [{ "entity": "Absence", "field": "duration", "operator": ">", "value": 3 }]
+  ```
+- `consequences[]` : side effects when rule fires — `{type, target, description}`
+  ```json
+  "consequences": [{ "type": "notification", "target": "RH Manager", "description": "Certificat medical requis" }]
+  ```
+- `formula` : for BR-CALC rules (e.g., `"remaining = entitled + carried - taken"`)
+- `domainSpecific` : `true` if from domain research, `false` if generic CRUD validation
+
+## Use Cases Schema Format
+
+**CANONICAL FORMAT (MANDATORY):** The usecases.json file MUST use these exact keys:
+- Root key: `"useCases"` (camelCase, NOT "usecases")
+- Actor field: `"primaryActor"` (NOT "actor")
+- Steps field: `"mainScenario"` (string[], NOT "steps" with objects)
+- Alternatives: `"alternativeScenarios"` (object[] with `{name, steps}`, NOT "alternative" as flat string)
+- This matches specification-schema.json. Deviation causes normalization overhead in 4+ downstream skills.
+
+```json
+{
+  "useCases": [
+    {
+      "id": "UC-EMPLOYEES-001",
+      "name": "Créer un employé",
+      "sectionCode": "list",
+      "primaryActor": "Responsable RH",
+      "preconditions": ["L'utilisateur a la permission HumanResources.Employees.Create"],
+      "mainScenario": [
+        "L'utilisateur ouvre la page de création",
+        "Il remplit les champs obligatoires (nom, département, date embauche)",
+        "Il valide le formulaire",
+        "Le système vérifie les règles métier (BR-VAL-EMPLOYEES-001)",
+        "Le système crée l'employé et affiche la fiche"
+      ],
+      "alternativeScenarios": [
+        {
+          "name": "Données invalides",
+          "steps": ["Le système affiche les erreurs de validation", "L'utilisateur corrige et re-soumet"]
+        }
+      ],
+      "businessRules": ["BR-VAL-EMPLOYEES-001"],
+      "result": "L'employé est créé avec le statut 'Actif'"
+    }
+  ]
+}
+```
+
+**MANDATORY enrichment fields (activated in v2):**
+- `postconditions[]` : effects AFTER the UC completes (schema field exists, now mandatory)
+  ```json
+  "postconditions": ["Absence.status = Approved", "AbsenceBalance.taken += duration", "Notification envoyee"]
+  ```
+- `errorScenarios[]` : error paths — MANDATORY for workflow UCs (schema field exists, now mandatory)
+  ```json
+  "errorScenarios": [{ "name": "Solde insuffisant", "steps": ["Systeme affiche le solde restant", "Soumission bloquee"] }]
+  ```
+
+**Minimum requirements:**
+- Workflow UCs: `mainScenario[]` >= 5 steps, `errorScenarios[]` >= 1, `postconditions[]` required
+- CRUD UCs: `mainScenario[]` >= 3 steps, `postconditions[]` required
+
+## Permissions Schema Format
+
+```json
+{
+  "roles": ["RH Admin", "Manager", "Employee"],
+  "matrix": [
+    { "role": "RH Admin", "permissions": ["Read", "Create", "Update", "Delete", "Export"] },
+    { "role": "Manager", "permissions": ["Read", "Export"] },
+    { "role": "Employee", "permissions": ["Read"] }
+  ],
+  "permissionPaths": [
+    "HumanResources.Employees.Read",
+    "HumanResources.Employees.Create",
+    "HumanResources.Employees.Update",
+    "HumanResources.Employees.Delete",
+    "HumanResources.Employees.Export"
+  ]
+}
+```
+
+**Auto-detection rules:**
+- If the cadrage mentions "export", "Excel", "CSV", or "télécharger" → automatically add `.export` permission and an export use case (UC-{PREFIX}-EXPORT)
+- If the cadrage mentions "import", "importer", "upload" → automatically add `.import` permission and an import use case (UC-{PREFIX}-IMPORT)
+
+## LifeCycle Schema Format
+
+> Source: `specification-schema.json` `lifeCycles[]`
+> **MANDATORY** for each entity with a status enum attribute.
+> Generated in step-03 section F-bis. Consumed by Mermaid diagram generation (step-04) and code generation (handoff/develop).
+
+```json
+{
+  "entity": "EntityName",
+  "field": "status",
+  "initialState": "Draft",
+  "states": [
+    {
+      "id": "Draft",
+      "displayName": "Brouillon",
+      "color": "gray",
+      "allowedTransitions": ["Submitted"],
+      "isTerminal": false
+    }
+  ],
+  "transitions": [
+    {
+      "from": "Draft",
+      "to": "Submitted",
+      "action": "submit",
+      "permission": "App.Module.Action",
+      "guards": ["BR-VAL-XXX"],
+      "effects": [
+        { "type": "notification", "target": "Manager", "template": "entity-submitted" },
+        { "type": "field-update", "target": "Entity.field", "template": "= value" }
+      ],
+      "confirm": false
+    }
+  ]
+}
+```
+
+**Generation rules:**
+- Extract states from entity's status enum `options[]`
+- Extract transitions from BR-WF-* rules
+- Link `guards[]` to BR-VAL-* rules that must pass before transition
+- Link `effects[]` to BR-NOTIF-* and BR-CALC-* triggered by the transition
+- Link `permission` from permissions.json for each transition action
+- Set `color` based on state semantic: gray=draft, blue=active, green=success, red=error, yellow=warning
+- Set `isTerminal: true` for states with no allowed transitions