@atlashub/smartstack-cli 4.73.0 → 4.75.0

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

@@ -36,19 +36,112 @@ function resolveModuleDir(appCode, moduleCode) {
 - Step 02 (structure) completed
 - Applications, modules, sections, dependencies identified
 
+## Scope Verification (BLOCKING — before any module processing)
+
+Re-read `.business-analyse/config.json` and verify scope has not drifted:
+
+```javascript
+const config = readJSON('.business-analyse/config.json').currentFeature;
+const expectedApps = config.candidateApplications?.length || 1;
+const confirmedModules = /* read from step-02 output: application index.json modules[] */;
+
+// BLOCKING if scope drifted
+if (config.workflowMode === "project") {
+  const appIndexFiles = GLOB(`${config.docsDir}/*/index.json`);
+  if (appIndexFiles.length > expectedApps) {
+    BLOCKING_ERROR(`Scope drift: expected ${expectedApps} applications but found ${appIndexFiles.length}`);
+  }
+}
+
+// Log confirmed scope for traceability
+Display(`Scope locked: ${expectedApps} app(s), ${confirmedModules.length} module(s)`);
+```
+
+## INTERDICTIONS ABSOLUES (step-03)
+
++==============================================================================+
+|  INTERDICTIONS — Violation = analyse invalide                                |
++==============================================================================+
+|                                                                              |
+|  1. JAMAIS lancer ba-writer pour un module AVANT validation client           |
+|     des entites, regles, use cases ET permissions de ce module.              |
+|                                                                              |
+|  2. JAMAIS lancer des ba-writer en PARALLELE pour des modules differents.    |
+|     Chaque module est traite SEQUENTIELLEMENT avec interaction client.        |
+|                                                                              |
+|  3. JAMAIS persister des entites, regles, volumetries, filtres              |
+|     ou notifications sans VALIDATION CLIENT (confirmation du lot propose).   |
+|     L'auto-deduction avec confirmation groupee est une validation valide.    |
+|                                                                              |
+|  4. JAMAIS sauter la VALIDATION CLIENT meme si le domaine semble "evident". |
+|     Auto-deduction + confirmation groupee = OK. Pas de confirmation = KO.    |
+|                                                                              |
+|  5. SUBAGENT DISCIPLINE :                                                    |
+|     - MAX 1 ba-writer par module (ecriture finale apres validation)          |
+|     - Total ba-writer pour step-03 = nombre_de_modules (pas plus)            |
+|     - INTERDICTION de spawner des ba-writer pour des modules NON encore      |
+|       valides par le client                                                  |
+|                                                                              |
++==============================================================================+
+
 ## Sequential Execution
 
 **No team mode.** Each module receives 100% of LLM attention for maximum specification quality.
 
-Process modules in topological order (dependencies first):
+Process **application by application**, modules in dependency order within each app:
+
 ```
-For module in topologicalSort(modules):
+IF workflow_mode = "project" (multi-app):
+  // Group by application first, then topological sort within each app
+  // Cross-app dependencies: if Module A (App1) depends on Module B (App2),
+  // App2 must be processed before App1. Adjust application order accordingly.
+
+  applicationOrder = resolveApplicationOrder(modules, dependencies)
+  // e.g., [Rh, Crm, GestionDeProjet, Facturation, Portal]
+
+  For EACH application in applicationOrder:
+    Display application banner:
+    ═══════════════════════════════════════════════════════
+      APPLICATION {appIndex}/{appTotal} : {appName}
+    ═══════════════════════════════════════════════════════
+
+    appModules = modules.filter(m => m.applicationCode === app.code)
+    sortedAppModules = topologicalSort(appModules)
+
+    For EACH module in sortedAppModules:
+      specify(module)  // Full cycle: A-bis → A-ter → B → C-pre → C → D → E → F → H
+
+ELSE (single-app):
+  For module in topologicalSort(modules):
     specify(module)
 ```
 
-## Per-Module Specification Loop
+## Per-Module Specification Loop — STRICT MODE
+
+### VALIDATION MINIMALE (per module — ba-009 fix)
+
+Chaque module metier (hors Portal et config) requiert AU MINIMUM 2 AskUserQuestion :
+  1. Entites (B-ter) : "Voici les entites pour {module}. Corrections ?"
+  2. Regles + UCs + Permissions (C-bis + E-ter groupes) : "Voici les regles, UCs et permissions pour {module}. Corrections ?"
+
+Exceptions :
+- Modules **Portal** (read-only, 0 entites propres) : 1 validation groupee suffit.
+- Modules **config/lookup** (< 2 entites) : 1 validation groupee suffit.
+
+**INTERDICTION** de tout bundler en 1 seule question "Module complet, validez-vous ?" pour les modules metier.
+
+For each module (in topological order), execute the complete cycle below.
+
+### Banniere de progression
+
+Afficher au debut de chaque module :
+```
+═══════════════════════════════════════════════════════════════
+  MODULE {index}/{total} : {moduleName} ({applicationName})
+═══════════════════════════════════════════════════════════════
+```
 
-For each module, execute these sub-steps:
+Execute these sub-steps for the current module:
 
 ### A. Context Loading
 
@@ -57,20 +150,26 @@ Load via ba-reader:
 - Application `cadrage.json` for stakeholder context (including `_preAnalysis.domain_research`)
 - Completed modules' summaries (compact, <100 lines each)
 
-### A-bis. Entity Pattern Research (WebSearch — per module)
+### A-bis. Module Domain Research (MANDATORY for modules with >= 2 entities)
 
-> **Before defining entities, validate design against industry best practices.**
+> **MANDATORY — BLOCKING** pour les modules metier (>= 2 entites).
+> SKIP ONLY: Portal (0 entites propres), config (1 entite reference pure).
 > Uses domain_research from step-01 as baseline, then does targeted searches for this specific module.
+> → **Load** `references/domain-research-playbook.md` Level 2 for per-module search strategy.
+> Si WebSearch indisponible: s'appuyer sur `references/module-completeness-challenge.md` comme fallback.
 
 ```
-IF cadrage._preAnalysis.domain_research exists:
-  → Load as baseline (already researched in step-01)
+IF module is Portal OR (module has exactly 1 config/lookup entity):
+  → SKIP WebSearch (use step-01 domain_research only)
 ELSE:
-  → Run a quick WebSearch: "{module_domain} entity data model best practices"
+  SHOULD WebSearch: "{module_domain} entity data model best practices"
+  (e.g., "invoice entity design ERP", "timesheet data model best practices")
+
+IF cadrage._preAnalysis.domain_research exists:
+  → Load as baseline complement
 
-FOR each main entity in this module (max 2-3 searches):
+OPTIONAL: FOR complex entities (max 1-2 additional searches):
   Query: "{entity_name} entity design pattern {domain}"
-  (e.g., "invoice entity design ERP", "timesheet data model best practices")
 
   EXTRACT (ULTRATHINK — internal only):
   - Standard attributes for this entity type
@@ -89,163 +188,304 @@ FOR each main entity in this module (max 2-3 searches):
 > If web research suggests putting firstName on Employee, the B-bis guard still blocks it
 > because SmartStack uses auth_Users for personal data.
 
+**TRACK 2 — Section & View Completeness (MANDATORY):**
+
+```
+WebSearch: "{module_domain} management system features views screens UX"
+(e.g., "absence management system features views screens",
+       "invoice management application features views UX")
+
+EXTRACT (ULTRATHINK — internal only):
+  - Standard views/sections for this module type
+  - Contextual filtered views (open requests, rejected, my X, history)
+  - Dashboard/reporting expectations
+  - Standard UX patterns (approval queue, batch actions, etc.)
+
+CROSS-CHECK against anticipatedSections from step-02:
+  - List sections found in research but NOT in anticipatedSections
+  - For each missing section: prepare proposal for A-ter validation
+```
+
+### A-ter. Section Completeness Validation (MANDATORY)
+
+> **Ensure this module has all the sections a user would expect.**
+> Workflow modules without contextual views (open-requests, rejected, history) are incomplete.
+> → **Load** `references/module-completeness-challenge.md` for section archetypes per pattern.
+
+Compare module's `anticipatedSections` against:
+1. Domain research (Track 2 above)
+2. Module archetype from `module-completeness-challenge.md`
+3. Section archetypes per module pattern (workflow vs data-centric)
+
+Display comparison table:
+```
+### Sections pour {moduleName}
+
+| Section actuelle | Section standard (recherche/archetype) | Statut |
+|-----------------|---------------------------------------|--------|
+| list            | list                                   | ✓ OK   |
+| detail          | detail                                 | ✓ OK   |
+| approve         | approve                                | ✓ OK   |
+| calendar        | calendar                               | ✓ OK   |
+| —               | open-requests                          | ✗ MANQUANTE — vue filtree des demandes en attente |
+| —               | rejected                               | ✗ MANQUANTE — vue filtree des demandes rejetees |
+| —               | history                                | ✗ MANQUANTE — historique des absences passees |
+| —               | my-balance                             | ✗ MANQUANTE — solde personnel de l'employe |
+```
+
+AskUserQuestion (multiSelect: true):
+```
+question: "{language == 'fr'
+  ? 'Voici les sections standards trouvees pour un module {moduleType}. Quelles sections manquantes souhaitez-vous ajouter ?'
+  : 'Here are the standard sections found for a {moduleType} module. Which missing sections would you like to add?'}"
+header: "Sections {moduleName}"
+multiSelect: true
+options:
+  - For each missing section: label: "{section_code}", description: "{description}"
+  - label: "{language == 'fr' ? 'Aucune' : 'None'}"
+    description: "{language == 'fr' ? 'Garder les sections actuelles' : 'Keep current sections'}"
+```
+
+Update `anticipatedSections` with accepted additions. For each added section:
+- Determine `sectionType` (functional for filtered views, embedded for dashboards)
+- Determine `permissionMode` (read-only for history/reporting, custom for approval queues)
+- Add appropriate resources
+
 ### B. Entities
 
 For each entity identified in step 02:
 
-```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, "description": "Identifiant unique auto-généré" },
-    { "name": "userId", "type": "string", "required": 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, "description": "Date d'embauche" },
-    { "name": "position", "type": "string", "description": "Poste occupé" },
-    { "name": "status", "type": "enum", "options": ["Active", "Inactive", "OnLeave", "Terminated"], "defaultValue": "Active", "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" }
-  ]
-}
-```
+> → **Load** `references/03-json-schemas.md` section "Entity Schema Format" for the canonical JSON format.
 
 ### B-bis. SmartStack Entity Convention Guards (MANDATORY)
 
-Before finalizing each entity, apply these rules:
+> → **Load** `references/03-smartstack-entity-guards.md` for all convention rules before finalizing each entity.
+
+### B-ter. Client Validation — Entities (OBLIGATOIRE)
+
+**Mode : Auto-déduction + Confirmation groupée**
+
+> L'IA propose les entités basées sur le cadrage + recherche domaine (A-bis).
+> Le client valide PAR LOT au lieu de répondre aux questions individuellement.
+> Les questions détaillées (Q3.1-Q3.5) ne sont posées QUE si le cadrage est ambigu.
+
+1. **Construire la proposition d'entités** à partir de :
+   - `cadrage.json` (coverageMatrix, stakeholders, globalScope)
+   - Recherche domaine (A-bis : standard attributes, versioning patterns)
+   - Modules déjà spécifiés (dépendances, entités partagées)
+
+2. **Présenter la proposition COMPLÈTE** (markdown PUIS AskUserQuestion) :
+   ```
+   ### Entités proposées pour {moduleName}
+
+   | Entité | Attributs clés | Relations | Volume estimé |
+   |--------|---------------|-----------|---------------|
+   | {entity} | {top 5 attrs with flags} | {relations} | {monthly/total} |
+   ```
+   AskUserQuestion : "Voici les entités que je propose pour {moduleName}. Corrections ?"
+
+3. SI le client corrige → intégrer et re-présenter
+4. SI le client valide → continuer vers C
 
-**B-bis-1. Person Extension Pattern** (ref: `entity-architecture-decision.md` section 0)
-IF the entity matches a person role (Employee, Customer, Manager, Consultant, etc.):
-- **DO NOT** add firstName, lastName, email, phoneNumber as direct attributes
-- **DO** add `userId` (type: `string`, FK to auth_Users — ASP.NET Identity uses string IDs)
-- **DO** add `personRoleConfig` metadata with variant (mandatory/optional)
-- Personal fields come from User, not from the domain entity
+5. **SI le cadrage est ambigu** sur un point spécifique → poser la question ciblée :
+   - Q3.1 si les entités ne sont pas claires
+   - Q3.5 si la stratégie de code est ambiguë
 
-**B-bis-2. Versioned Sensitive Data**
-IF the entity has attributes that change over time with audit requirements (salary, rate, grade):
-- **DO NOT** put them directly on the entity as single fields
-- **DO** extract into a versioned satellite table (e.g., Employee → Salary with effectiveDate)
-- Mark with `"versionedAttributes"` in entity spec
+6. APRES validation entites, AVANT passage aux regles (C) — poser en 2 batches max :
 
-**B-bis-3. SmartStack Socle Entities (NEVER redefine)**
-- Users/Identity → `auth_Users` (managed by SmartStack Identity)
-- Tenants → `tenant_Tenants` (managed by SmartStack Core)
-- Departments → `ref_Departments` or `rh_Departments` (check if exists in target DB)
+   **Batch recherche/filtres** (Q3.19 + Q3.20) :
+   - Q3.19 : "Par quels criteres cherchez-vous un {entite} ? (nom, date, statut, code...)"
+   - Q3.20 : "Quels filtres rapides sont indispensables dans la liste ?"
 
-**B-bis-4. Foreign Key Conventions**
-- All FK attributes MUST end with `Id` suffix (e.g., `departmentId`, `userId`)
-- FK to Identity users MUST use type `string` (ASP.NET Identity convention, NOT guid)
-- FK to domain entities MUST use type `guid`
+   **RACCOURCI module 3+ :** Proposer "Meme logique de recherche/filtres que {module_precedent} ?"
+   → Si le client confirme, copier searchableFields et defaultFilters du module precedent.
+   → Sinon, poser les questions normalement.
+
+   **SKIP si:** module Portal (pas d'entites propres) ou module config (filtres evidents : name, code).
+
+INTERDICTION de passer à C (Business Rules) tant que le client n'a pas validé les entités ET les champs recherche/filtres.
 
 ### C. Business Rules
 
 For each entity/process, identify rules. **Each rule MUST specify `sectionCode`** matching a code from `anticipatedSections[]`:
 
-```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"
-}
-```
+> → **Load** `references/03-json-schemas.md` section "Business Rules Schema Format" for the canonical JSON format and all validation requirements.
 
-Categories: `validation`, `calculation`, `workflow`, `security`, `data`, `notification`
+### C-pre. Business Rules Domain Research (MANDATORY for workflow modules)
 
-> **OBLIGATOIRE** : Chaque attribut `enum` DOIT avoir un `defaultValue`. Chaque attribut numérique borné DOIT avoir `validation.min/max`. Les types userId (FK vers Identity) DOIVENT utiliser le type `string` (convention ASP.NET Identity).
+> **Domain-specific business rules are what separate a 2/10 analysis from a 9/10 analysis.**
+> Generic rules (date coherence, required fields) are the MINIMUM. Domain rules are the VALUE.
+> → **Load** `references/module-completeness-challenge.md` for domain-specific rule examples.
 
-> **OBLIGATOIRE** : Chaque attribut marqué "calculé" dans entities.json DOIT avoir une règle `category: "calculation"` correspondante avec le champ `formula`.
+```
+IF module has workflow states OR approval patterns:
+  WebSearch: "{module_domain} business rules constraints validation best practices"
+  (e.g., "absence leave management business rules HR constraints",
+         "invoice billing business rules validation constraints",
+         "CRM opportunity management business rules")
 
-Exemple de règle de calcul :
-```json
-{
-  "id": "BR-CALC-INV-003",
-  "category": "calculation",
-  "statement": "Le reste à payer = total - montant payé",
-  "formula": "remainingAmount = total - paidAmount",
-  "entities": ["Invoice"]
-}
+  EXTRACT (ULTRATHINK — internal only):
+    - Domain-specific validation rules (NOT just date coherence / required fields)
+    - Calculation rules with formulas
+    - Workflow constraints (capacity limits, notice periods, deadlines)
+    - Edge cases (half-day, probation, carry-over, expiry, partial payments)
+    - Regulatory constraints (legal leave types, mandatory approvals, numbering)
+    - Separation of duties rules (cannot approve own request)
+
+  CROSS-CHECK proposed rules (from B-ter entity analysis):
+    For each rule found in research but NOT already proposed:
+      → Add to proposal with source: "domain-research"
+      → Category: detected category (VAL, CALC, WF, SEC, DATA)
+      → Mark with domainSpecific: true
+
+  Example enrichments for Absences module:
+    Current generic rules: date coherence, no overlap, balance check, workflow transitions
+    Research-based additions:
+    - BR-VAL-ABS-004: "Half-day absence (morning/afternoon)" [domainSpecific]
+    - BR-VAL-ABS-005: "Minimum 48h notice for planned absences" [domainSpecific]
+    - BR-VAL-ABS-006: "Max 30% of team can be absent simultaneously" [domainSpecific]
+    - BR-VAL-ABS-007: "Restricted leave types during probation period" [domainSpecific]
+    - BR-DATA-ABS-001: "Carry-over days expire after March 31" [domainSpecific]
+    - BR-VAL-ABS-008: "Medical certificate required for absences > 3 days" [domainSpecific]
+    - BR-SEC-ABS-001: "Manager cannot approve their own absences" [domainSpecific]
+
+ELSE (non-workflow module):
+  → Use entity patterns from A-bis for validation rules
+  → Load archetype rules from module-completeness-challenge.md
 ```
 
+### C-bis. Client Validation — Business Rules (OBLIGATOIRE)
+
+**Mode : Auto-déduction + Confirmation groupée**
+
+1. **Construire les règles métier** à partir de :
+   - Entités validées en B-ter (attributs, types, contraintes)
+   - Patterns domaine (A-bis) : validations standards, calculs attendus
+   - Cadrage : errorFlows, processus décrits
+
+   **ENRICHISSEMENT OBLIGATOIRE pour chaque règle :**
+
+   Pour chaque BR proposée, inclure ces champs :
+   - `severity` : TOUJOURS spécifier (blocking/warning/info)
+   - `sectionCode` : TOUJOURS spécifier (section où la règle s'applique)
+   - `examples[]` : OBLIGATOIRE — au moins 1 exemple structuré `{input, expected}`
+     Ex: `{ input: "debut=15/03 fin=12/03", expected: "Erreur : date de fin avant date de debut" }`
+   - `conditions[]` : OBLIGATOIRE pour les règles conditionnelles (IF/THEN) — structuré `{entity, field, operator, value}`
+     Ex: `[{ entity: "Absence", field: "type", operator: "==", value: "Maladie" }, { entity: "Absence", field: "duration", operator: ">", value: 3 }]`
+   - `consequences[]` : OBLIGATOIRE pour les règles avec effets de bord
+     Ex: `[{ type: "notification", target: "RH Manager", description: "Certificat médical requis" }]`
+   - `formula` : OBLIGATOIRE pour les BR-CALC
+   - `domainSpecific: true` si la règle vient de la recherche domaine (C-pre)
+
+   **Minimums par module métier (hors Portal/config) :**
+   - >= 4 règles avec `examples[]` structurés `{input, expected}`
+   - >= 2 règles avec `conditions[]` structurés
+   - >= 1 règle avec `consequences[]`
+
+2. **Présenter le LOT complet** (markdown PUIS AskUserQuestion) :
+   ```
+   ### Règles métier proposées pour {moduleName}
+
+   | ID | Catégorie | Règle | Sévérité |
+   |----|-----------|-------|----------|
+   | BR-VAL-... | validation | {statement} | blocking |
+   | BR-CALC-... | calculation | {statement} (formula: {formula}) | blocking |
+   ```
+   AskUserQuestion : "Voici les {N} règles métier pour {moduleName}. Manques/corrections ?"
+
+3. SI le cadrage est ambigu → poser les questions ciblées :
+   - Q3.7 si les validations ne sont pas claires
+   - Q3.8 si les relations inter-champs sont complexes
+   - Q3.9 si les données sensibles ne sont pas identifiées
+
+INTERDICTION de passer à D (Use Cases) tant que le client n'a pas validé les règles.
+
 ### D. Use Cases
 
-For each stakeholder action. **Each use case MUST specify `sectionCode`** matching a code from `anticipatedSections[]` — this links the UC to the screen/page where it happens:
+> **Note (v3) :** Les questions parcours/decisions/erreurs (ex-Q2.16-Q2.18) sont desormais capturees ICI
+> lors de la specification des use cases, et non plus en step-01 cadrage. Cela evite la duplication
+> et produit des donnees directement exploitables par module.
 
-> **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.
+**D-pre. Capture du parcours utilisateur (1 question par module si pertinent)**
 
-```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'"
-    }
-  ]
-}
+> Avant de construire les UCs, comprendre le parcours type pour CE module.
+> SKIP si le module est un module config/lookup ou Portal (pas de parcours propre).
+
+```
+IF module is NOT config/lookup AND NOT Portal:
+  AskUserQuestion (1 question):
+  "{language == 'fr'
+    ? 'Pour le module {moduleName} : décrivez le parcours typique. L\'utilisateur arrive, que fait-il ? Quand quelque chose ne se passe pas comme prévu, que se passe-t-il ?'
+    : 'For the {moduleName} module: describe the typical journey. The user arrives, what do they do? When something doesn't go as planned, what happens?'}"
+
+  Record answer as:
+  - mainScenario steps → feed UC mainScenario
+  - decision points → feed UC alternativeScenarios
+  - error cases → feed UC errorScenarios + BR-WF rules
 ```
 
+For each stakeholder action. **Each use case MUST specify `sectionCode`** matching a code from `anticipatedSections[]` — this links the UC to the screen/page where it happens:
+
+> → **Load** `references/03-json-schemas.md` section "Use Cases Schema Format" for the canonical JSON format.
+
 ### E. Permissions
 
 Define the permission matrix:
 
-```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"
-  ]
-}
-```
+> → **Load** `references/03-json-schemas.md` section "Permissions Schema Format" for the canonical JSON format.
+
+### E-bis. Notifications et Dashboards (OBLIGATOIRE)
+
+> **Regle : 2 questions max par AskUserQuestion.**
+
+**Batch E-bis-1** — Notifications :
+- Q3.21 : "Quels evenements doivent declencher une notification dans {moduleName} ?"
+- Q3.22 : "Qui doit etre notifie ? Par quel canal ? (in-app, email)" (conditionnel si Q3.21 = oui)
+
+**Batch E-bis-2** — Dashboards (SI pertinent pour ce module) :
+- Q3.14 : "Des tableaux de bord ou indicateurs sont-ils requis ?"
+- Q3.15 : "Si oui, quels KPIs afficher ?" (conditionnel si Q3.14 = oui)
+
+### E-ter. Client Validation — Use Cases & Permissions (OBLIGATOIRE)
+
+**Mode : Auto-déduction + Confirmation groupée**
 
-**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)
+1. **Construire UCs et permissions** à partir des entités + règles validées :
+   - CRUD UCs dérivés des entités (Create, Read, Update, Delete)
+   - Export UC si cadrage mentionne export/Excel/CSV
+   - Import UC si cadrage mentionne import/upload
+   - Workflow UCs si entité a des états (enum status)
+
+   **ENRICHISSEMENT OBLIGATOIRE pour chaque Use Case :**
+
+   Pour chaque UC proposé, inclure ces champs :
+   - `postconditions[]` : OBLIGATOIRE — effets après le UC
+     Ex: `["Absence.status = Approved", "AbsenceBalance.taken += duration", "Notification envoyee a l'employe"]`
+   - `errorScenarios[]` : OBLIGATOIRE pour les UCs workflow (>= 1 par UC workflow)
+     Ex: `{ name: "Solde insuffisant", steps: ["Systeme affiche le solde restant", "Systeme bloque la soumission", "Employe peut modifier les dates"] }`
+   - `mainScenario[]` : MINIMUM 5 steps pour les UCs workflow (3 suffisent pour list/read)
+   - `alternativeScenarios[]` : MINIMUM 1 pour les UCs avec branchements
+
+   **Minimums par module métier :**
+   - >= 3 UCs avec `errorScenarios[]` non vides
+   - >= 4 UCs avec `postconditions[]` non vides
+   - Moyenne mainScenario >= 4 steps
+
+2. **Présenter les deux lots en 1 seule interaction** (markdown PUIS AskUserQuestion) :
+   ```
+   ### Use Cases proposés pour {moduleName}
+   | ID | Nom | Acteur | Règles liées |
+   ...
+
+   ### Permissions proposées
+   | Rôle | Permissions |
+   ...
+   ```
+   AskUserQuestion : "Voici les UCs et permissions pour {moduleName}. Corrections ?"
+
+3. SI le cadrage est ambigu → poser les questions ciblées du lot E-bis (notifications, dashboards)
+
+INTERDICTION de passer à F (Seed Data) / H (Write) tant que le client n'a pas validé use cases ET permissions.
 
 ### F. Seed Data pour tables de référence
 
@@ -265,13 +505,273 @@ Define the permission matrix:
 }
 ```
 
+### F-bis. LifeCycle State Machine (MANDATORY for workflow entities)
+
+> Les lifeCycles sont déjà dans le schema (`specification-schema.json` l.317-383).
+> Ils doivent être générés pour CHAQUE entité ayant un attribut status de type enum.
+> Ces données alimentent les diagrammes d'état Mermaid ET le code généré.
+
+Pour CHAQUE entité avec attribut `type: "enum"` contenant "status" dans ses `options[]` :
+
+  1. Extraire les états depuis `options[]` de l'attribut enum
+  2. Identifier les transitions depuis les règles BR-WF-*
+  3. Lier chaque transition à :
+     - `permission` : depuis permissions.json
+     - `guards[]` : BR-VAL-* qui doivent passer avant la transition
+     - `effects[]` : BR-NOTIF-* et BR-CALC-* déclenchées par la transition
+
+  Générer le `lifeCycle` complet :
+  ```json
+  {
+    "entity": "Absence",
+    "field": "status",
+    "initialState": "Draft",
+    "states": [
+      { "id": "Draft", "displayName": "Brouillon", "color": "gray", "allowedTransitions": ["Submitted"], "isTerminal": false },
+      { "id": "Submitted", "displayName": "Soumis", "color": "blue", "allowedTransitions": ["Approved", "Rejected"], "isTerminal": false },
+      { "id": "Approved", "displayName": "Approuvé", "color": "green", "allowedTransitions": [], "isTerminal": true },
+      { "id": "Rejected", "displayName": "Refusé", "color": "red", "allowedTransitions": [], "isTerminal": true }
+    ],
+    "transitions": [
+      { "from": "Draft", "to": "Submitted", "action": "submit", "permission": "Rh.Absences.Create",
+        "guards": ["BR-VAL-ABS-001", "BR-VAL-ABS-002", "BR-VAL-ABS-003"],
+        "effects": [{ "type": "notification", "target": "RH Manager", "template": "absence-submitted" }] },
+      { "from": "Submitted", "to": "Approved", "action": "approve", "permission": "Rh.Absences.Approve",
+        "guards": [],
+        "effects": [
+          { "type": "field-update", "target": "AbsenceBalance.taken", "template": "+= duration" },
+          { "type": "notification", "target": "employee", "template": "absence-approved" }
+        ] }
+    ]
+  }
+  ```
+
+  Présenter le lifecycle au client dans le lot E-ter (avec UCs et permissions).
+
+  **Écriture :** Stocker dans `usecases.json` sous la clé `lifeCycles[]` (déjà dans le schema).
+
+### F-ter. Gherkin Auto-Generation from Enriched UCs (MANDATORY)
+
+> **Les Gherkin doivent être DERIVES des UCs enrichis, pas inventés séparément.**
+> Chaque `mainScenario` → 1 Gherkin happy path.
+> Chaque `errorScenario` → 1 Gherkin error path.
+> Chaque `alternativeScenario` → 1 Gherkin alternative path.
+> Les `examples[]{input, expected}` des BRs alimentent les `Examples:` tables Gherkin.
+
+**Process :**
+
+```
+For EACH UC in module:
+  // 1. Happy path from mainScenario + postconditions
+  Generate Gherkin:
+    Feature: {UC.name}
+    Scenario: {UC.name} - happy path
+      Given {UC.preconditions[] joined as Given/And}
+      When {UC.mainScenario[] mapped to When/And steps}
+      Then {UC.postconditions[] mapped to Then/And assertions}
+
+  // 2. Error paths from errorScenarios
+  For EACH errorScenario in UC.errorScenarios:
+    Scenario: {UC.name} - {errorScenario.name}
+      Given {UC.preconditions[] + error setup conditions}
+      When {trigger action from mainScenario step 1}
+      Then {errorScenario.steps[] mapped to Then/And}
+
+  // 3. Alternative paths from alternativeScenarios
+  For EACH alt in UC.alternativeScenarios:
+    Scenario: {UC.name} - {alt.name}
+      Given {modified preconditions}
+      When {alt trigger}
+      Then {alt.steps[] mapped to Then/And}
+
+  // 4. Data-driven examples from linked BR examples
+  IF UC.linkedRules references BRs with structured examples[]:
+    Scenario Outline: {UC.name} - validation rules
+      Given a {entity} with <field> = <value>
+      When the user submits the form
+      Then the system shows <expected>
+    Examples:
+      | field | value | expected |
+      {for each BR example: | {input} | {expected} |}
+```
+
+**Exemple concret (Absence - Soumission) :**
+
+```gherkin
+Feature: Soumettre une demande d'absence (UC-ABS-001)
+
+  Scenario: Soumission reussie
+    Given un employe avec la permission Rh.Absences.Create
+    And un solde de CP >= duree demandee
+    When il selectionne le type CP, dates 15/03 au 19/03
+    And le systeme calcule la duree en jours ouvres (5j)
+    And le systeme verifie les dates, chevauchements et solde
+    And il soumet la demande
+    Then Absence.status = Submitted
+    And AbsenceBalance.taken reste inchange (pas encore approuve)
+    And notification envoyee au RH Manager
+
+  Scenario: Soumission echouee - solde insuffisant
+    Given un employe avec 2 jours de CP restants
+    When il soumet une absence de 5 jours de type CP
+    Then le systeme affiche le solde restant (2 jours)
+    And la soumission est bloquee
+
+  Scenario: Soumission echouee - chevauchement
+    Given un employe avec une absence approuvee du 15/03 au 19/03
+    When il soumet une absence du 17/03 au 21/03
+    Then le systeme affiche l'absence existante en conflit
+    And la soumission est bloquee
+
+  Scenario Outline: Validation des dates
+    Given un employe connecte
+    When il saisit debut=<debut> fin=<fin>
+    Then le systeme affiche <resultat>
+    Examples:
+      | debut | fin | resultat |
+      | 15/03 | 12/03 | Erreur : date de fin avant date de debut |
+      | 15/03 | 15/03 | OK (1 jour) |
+      | 15/03 | 19/03 | OK (5 jours ouvres) |
+```
+
+**Minimums :** >= 3 scnarios Gherkin par module mtier (1 happy + 2 error/alt minimum).
+
+**criture :** Stocker dans `usecases.json` sous la cl `gherkinScenarios[]`.
+
+### F-quater. Field-Level Validations Auto-Generation (MANDATORY)
+
+> **Gnrer les validations field-level depuis les attributs d'entits + rgles mtier.**
+> Ces validations alimentent directement les validators frontend (FluentValidation backend + form validation frontend).
+
+```
+For EACH entity in module:
+  For EACH attribute in entity.attributes:
+
+    validations = []
+
+    // From attribute metadata
+    IF attribute.required: validations.push({ rule: "required", errorMessageKey: "{module}.{entity}.{attr}.required" })
+    IF attribute.type === "string" AND attribute.maxLength: validations.push({ rule: "maxLength", params: { max: attribute.maxLength }, errorMessageKey: "..." })
+    IF attribute.type === "string" AND attribute.unique: validations.push({ rule: "unique", errorMessageKey: "..." })
+    IF attribute.type === "email": validations.push({ rule: "email", errorMessageKey: "..." })
+    IF attribute.type === "decimal" AND (context is amount/price): validations.push({ rule: "min", params: { min: 0 }, errorMessageKey: "..." })
+    IF attribute.type === "int": validations.push({ rule: "integer", errorMessageKey: "..." })
+    IF attribute.type === "date": validations.push({ rule: "date", errorMessageKey: "..." })
+
+    // From linked business rules (BR-VAL-*)
+    IF exists BR-VAL referencing this attribute:
+      For EACH matching BR:
+        validations.push({ rule: "custom", brRef: BR.id, description: BR.statement, errorMessageKey: "..." })
+
+    Store: { entity: entity.name, field: attribute.name, rules: validations }
+```
+
+**Exemple concret (Absence) :**
+
+```json
+[
+  { "entity": "Absence", "field": "startDate", "rules": [
+    { "rule": "required", "errorMessageKey": "absences.absence.startDate.required" },
+    { "rule": "date", "errorMessageKey": "absences.absence.startDate.date" },
+    { "rule": "custom", "brRef": "BR-VAL-ABS-001", "description": "startDate <= endDate", "errorMessageKey": "absences.absence.startDate.beforeEnd" }
+  ]},
+  { "entity": "Absence", "field": "endDate", "rules": [
+    { "rule": "required", "errorMessageKey": "absences.absence.endDate.required" },
+    { "rule": "date", "errorMessageKey": "absences.absence.endDate.date" }
+  ]},
+  { "entity": "Absence", "field": "reason", "rules": [
+    { "rule": "maxLength", "params": { "max": 500 }, "errorMessageKey": "absences.absence.reason.maxLength" }
+  ]}
+]
+```
+
+**criture :** Stocker dans `usecases.json` sous la cl `validations[]` (dj dans le schema specification-schema.json).
+
 ### G. Interface Specs — Delegated to /business-analyse-design
 
 > **Screen specifications are NOT produced in this step.**
 > Interface design (SmartTable columns, SmartForm fields, wireframes, navigation) is handled by Phase 2: `/business-analyse-design`.
 > This separation allows iterating on UI design without replaying the full analysis cycle.
 
-### H. Write & Advance
+### G-bis. API Endpoint Schema Enrichment (MANDATORY)
+
+> **Gnrer les request/response schemas pour chaque API endpoint depuis les entits.**
+> Les apiEndpoints[] existent dj dans le schema mais manquent les DTOs.
+> Ce sont ces DTOs qui permettent au develop de gnrer le bon code du premier coup.
+
+```
+For EACH apiEndpoint in module:
+  // Derive requestSchema from entity attributes
+  IF method in ["POST", "PUT", "PATCH"]:
+    requestSchema = {}
+    For EACH attribute in entity.attributes:
+      IF attribute is NOT computed AND attribute is NOT auto-generated:
+        requestSchema[attribute.name] = {
+          type: attribute.type,
+          required: attribute.required || false,
+          description: attribute.description
+        }
+
+  // Derive responseSchema from entity attributes + computed fields
+  responseSchema = { id: "guid" }
+  For EACH attribute in entity.attributes:
+    responseSchema[attribute.name] = {
+      type: attribute.type,
+      computed: attribute.computed || false
+    }
+  // Add navigation properties for relationships
+  For EACH relationship in entity.relationships:
+    IF relationship.type === "ManyToOne":
+      responseSchema[relationship.target + "Name"] = { type: "string", computed: true }
+
+  // Derive errorCodes from linked BRs
+  errorCodes = []
+  For EACH linkedRule in UC.linkedRules:
+    IF rule.severity === "blocking":
+      errorCodes.push({ code: 400, reason: rule.id, description: rule.statement })
+  errorCodes.push({ code: 403, reason: "Forbidden", description: "Missing permission: " + endpoint.permission })
+  errorCodes.push({ code: 404, reason: "NotFound", description: entity.name + " not found" })
+```
+
+**Exemple concret (POST /api/rh/absences) :**
+
+```json
+{
+  "method": "POST",
+  "path": "/api/rh/absences",
+  "permission": "Rh.Absences.Create",
+  "linkedUC": "UC-ABS-001",
+  "requestSchema": {
+    "employeeId": { "type": "guid", "required": true },
+    "absenceTypeId": { "type": "guid", "required": true },
+    "startDate": { "type": "date", "required": true },
+    "endDate": { "type": "date", "required": true },
+    "reason": { "type": "string", "required": false }
+  },
+  "responseSchema": {
+    "id": { "type": "guid" },
+    "code": { "type": "string" },
+    "status": { "type": "enum", "computed": false },
+    "duration": { "type": "decimal", "computed": true },
+    "employeeName": { "type": "string", "computed": true }
+  },
+  "errorCodes": [
+    { "code": 400, "reason": "BR-VAL-ABS-001", "description": "Date de debut apres date de fin" },
+    { "code": 400, "reason": "BR-VAL-ABS-002", "description": "Chevauchement avec absence existante" },
+    { "code": 400, "reason": "BR-VAL-ABS-003", "description": "Solde insuffisant" },
+    { "code": 403, "reason": "Forbidden", "description": "Permission Rh.Absences.Create requise" },
+    { "code": 404, "reason": "NotFound", "description": "Employee not found" }
+  ]
+}
+```
+
+**criture :** Stocker dans `usecases.json` sous la cl `apiEndpoints[]` (enrichi).
+
+### H. Write & Advance (SEULEMENT apres validation complete)
+
+> **GATE:** ba-writer ne peut etre lance QUE si le client a valide :
+> entites (B-ter) + regles (C-bis) + use cases/permissions (E-ter).
+> Si un lot n'est pas valide → RETOUR au lot concerne.
 
 After completing all sub-steps for a module:
 
@@ -295,6 +795,15 @@ After completing all sub-steps for a module:
 
 3. Advance to next module in topological order
 
+### H-bis. Module Transition Summary
+
+Afficher un resume compact du module termine :
+```
+✓ {moduleName} — {entityCount} entites, {ruleCount} regles, {ucCount} UCs, {permCount} permissions
+```
+
+Passer au module suivant. INTERDICTION de lancer des ba-writer en parallele pour des modules differents.
+
 ### I. Module Completion Check
 
 After all modules are specified:
@@ -303,102 +812,16 @@ After all modules are specified:
 - Remind user: "Run /business-analyse-design to design interfaces for these modules"
 - Transition to step 04
 
-## POST-CHECK (EXECUTABLE — BLOCKING)
+### I-bis. Cross-Module Questions (apres tous les modules)
 
-Before advancing to step 04, run these validations for EACH module:
+SI des dependances cross-module existent (identifiees en step-02) :
+→ Charger questionnaire/05-cross-module.md et poser les questions pertinentes via AskUserQuestion.
+→ Integrer les reponses dans les modules concernes via ba-writer.
 
-```javascript
-const errors = [];
-const warnings = [];
-
-for (const mod of modules) {
-  // mod.dir = resolveModuleDir(applicationCode, mod.code)
-  // e.g., docs/projet-rh/v1.0/human-resources/employees/
-  const ent = READ(mod.dir + '/entities.json')?.entities || [];
-  const ucs = READ(mod.dir + '/usecases.json')?.useCases || [];
-  const brs = READ(mod.dir + '/rules.json')?.rules || [];
-  const perms = READ(mod.dir + '/permissions.json');
-  const sections = mod.anticipatedSections || [];
-  const sectionCodes = new Set(sections.map(s => s.code));
-
-  // Mandatory checks (BLOCKING)
-  if (ent.length === 0) errors.push(mod.code + ": 0 entities");
-  if (ucs.length === 0) errors.push(mod.code + ": 0 use cases");
-  if (brs.length === 0) errors.push(mod.code + ": 0 business rules");
-  if (!perms?.permissionPaths?.length) errors.push(mod.code + ": no permissions");
-
-  // sectionCode validation
-  for (const uc of ucs) {
-    if (!uc.sectionCode) errors.push(mod.code + ": UC '" + uc.id + "' missing sectionCode");
-    else if (!sectionCodes.has(uc.sectionCode)) errors.push(mod.code + ": UC '" + uc.id + "' sectionCode '" + uc.sectionCode + "' not in anticipatedSections");
-  }
-  for (const br of brs) {
-    if (!br.sectionCode) errors.push(mod.code + ": BR '" + br.id + "' missing sectionCode");
-    else if (!sectionCodes.has(br.sectionCode)) errors.push(mod.code + ": BR '" + br.id + "' sectionCode '" + br.sectionCode + "' not in anticipatedSections");
-  }
-
-  // Entity attribute checks
-  for (const e of ent) {
-    for (const a of (e.attributes || [])) {
-      if (!a.type) warnings.push(mod.code + ": entity " + e.name + " attr '" + a.name + "' missing type");
-      if (a.type === 'enum' && !a.defaultValue) errors.push(mod.code + ": enum attr '" + a.name + "' missing defaultValue");
-      // FK naming convention: must end with "Id"
-      if ((a.type === 'guid' || a.type === 'string') && a.foreignKey && !a.name.endsWith('Id'))
-        warnings.push(mod.code + ": entity " + e.name + " FK attr '" + a.name + "' should end with 'Id'");
-    }
-    // Person Extension Pattern check
-    const personFields = ['firstName', 'lastName', 'email', 'phoneNumber', 'phone'];
-    const foundPersonFields = (e.attributes || []).filter(a => personFields.includes(a.name));
-    if (foundPersonFields.length >= 3 && !e.personRoleConfig) {
-      errors.push(mod.code + ": entity '" + e.name + "' has " + foundPersonFields.length +
-        " person fields (" + foundPersonFields.map(f => f.name).join(", ") +
-        ") but no personRoleConfig — use Person Extension Pattern (entity-architecture-decision.md section 0). " +
-        "Person fields (firstName, lastName, email) belong on auth_Users, not on the domain entity.");
-    }
-  }
-
-  // Canonical usecases key check
-  const rawUCFile = READ(mod.dir + '/usecases.json');
-  if (rawUCFile && !rawUCFile.useCases && rawUCFile.usecases) {
-    errors.push(mod.code + ": usecases.json uses 'usecases' key instead of canonical 'useCases' — fix before proceeding");
-  }
-  // Check steps serialization format
-  for (const uc of ucs) {
-    if (uc.steps && Array.isArray(uc.steps) && uc.steps.length > 0 && typeof uc.steps[0] === 'object') {
-      errors.push(mod.code + ": UC '" + uc.id + "' uses steps[] with objects — must use mainScenario[] with strings");
-    }
-    if (uc.actor && !uc.primaryActor) {
-      warnings.push(mod.code + ": UC '" + uc.id + "' uses 'actor' instead of canonical 'primaryActor'");
-    }
-  }
-
-  // Cross-reference checks
-  for (const uc of ucs) {
-    for (const brRef of (uc.businessRules || [])) {
-      if (!brs.find(br => br.id === brRef)) warnings.push(mod.code + ": UC '" + uc.id + "' references non-existent BR '" + brRef + "'");
-    }
-  }
-
-  // Section permission checks
-  for (const section of sections) {
-    if (section.sectionType === 'view') {
-      const viewPerms = (perms?.permissionPaths || []).filter(p => p.includes('.' + section.code + '.'));
-      if (viewPerms.length > 0) errors.push(mod.code + ": view section '" + section.code + "' has " + viewPerms.length + " permissions (should inherit)");
-    }
-  }
-}
+## POST-CHECK (EXECUTABLE — BLOCKING)
 
-if (errors.length > 0) {
-  Display("POST-CHECK FAILED (" + errors.length + " errors):");
-  errors.forEach(e => Display("  ✗ " + e));
-  BLOCKING_ERROR("Fix all errors before advancing to step 04");
-}
-if (warnings.length > 0) {
-  Display("POST-CHECK warnings (" + warnings.length + "):");
-  warnings.forEach(w => Display("  ⚠ " + w));
-}
-Display("POST-CHECK PASS: " + modules.length + " modules validated");
-```
+> → **Load** `references/03-post-check-validation.md` and execute ALL checks.
+> Any BLOCKING check failure must be resolved before proceeding to step 04.
 
 ## Transition