@atlashub/smartstack-cli 4.74.0 → 4.75.0

package/templates/skills/business-analyse/references/module-completeness-challenge.md

@@ -0,0 +1,174 @@
+# Module Completeness Challenge Reference
+
+> **Purpose:** Industry-standard module expectations per application type.
+> Used by step-01 (competitive challenge), step-02 (module completeness validation),
+> and step-03 (section completeness per module).
+> This is a FALLBACK when WebSearch is unavailable and a VALIDATION reference when it is.
+
+---
+
+## Application Archetypes
+
+### HR / Human Resources
+
+**Minimum modules: 3**
+
+| Module | Classification | Standard Sections | Key Entities |
+|--------|---------------|-------------------|-------------|
+| Employees | CORE | list, detail(tabs: info, contracts, documents, history), dashboard | Employee, Department, Position |
+| Absences/Leave | CORE | list, detail, calendar, approve, open-requests, rejected, history, my-balance | Absence, AbsenceType, AbsenceBalance |
+| Documents | STANDARD | list, detail, upload, my-documents | EmployeeDocument, DocumentType |
+| Evaluations | OPTIONAL | list, detail, campaign, my-evaluation | Evaluation, EvaluationCriteria, Campaign |
+| Organization | OPTIONAL | orgchart, departments | Department (hierarchy) |
+
+**Standard business rules (Absences — domain-specific, NOT generic CRUD):**
+- Half-day absences (morning/afternoon selection)
+- Minimum notice period for planned leave (e.g., 48h for non-urgent)
+- Team capacity limit (max % of team absent simultaneously)
+- Probation period restrictions (limited leave types during probation)
+- Carry-over limits and expiry dates (unused days expire after date X)
+- Medical certificate required for absences exceeding N days
+- Holiday calendar integration (exclude public holidays from business days)
+- Consecutive day limits (max N consecutive days for certain leave types)
+- Manager cannot approve their own absences (separation of duties)
+- Balance recalculation on approval/cancellation
+
+---
+
+### CRM
+
+**Minimum modules: 3**
+
+| Module | Classification | Standard Sections | Key Entities |
+|--------|---------------|-------------------|-------------|
+| Accounts/Clients | CORE | list, detail(tabs: info, contacts, opportunities, documents, history), dashboard | Client, Contact, Address |
+| Opportunities | CORE | list, detail, kanban/pipeline, dashboard, my-opportunities | Opportunity, PipelineStage, Activity |
+| Quotes/Proposals | CORE | list, detail(tabs: info, lines, history) | Quote, QuoteLine |
+| Activities/Tasks | STANDARD | list, detail, calendar, my-activities | Activity, ActivityType |
+| Campaigns | OPTIONAL | list, detail, dashboard, targeting | Campaign, CampaignTarget |
+| Products/Catalog | OPTIONAL | list, detail | Product, ProductCategory |
+
+**Standard business rules (Opportunities — domain-specific):**
+- Probability auto-updates based on pipeline stage
+- Mandatory reason when moving to "Lost" stage
+- Close date validation (cannot be in the past for active opps)
+- Weighted pipeline calculation (amount * probability)
+- Stage-gate validation (mandatory fields per stage)
+
+---
+
+### Billing / Invoicing
+
+**Minimum modules: 3**
+
+| Module | Classification | Standard Sections | Why CORE/STANDARD |
+|--------|---------------|-------------------|-------------------|
+| Invoices (Factures) | CORE | list, detail(tabs: info, lines, payments, history), generate, dashboard, overdue | Base entity — invoice lifecycle |
+| Credit Notes (Avoirs) | CORE | list, detail(tabs: info, lines, history) | **Legally required** to correct/cancel invoices. Cannot have invoicing without credit notes. |
+| Payment Tracking (Paiements) | CORE | list, detail, reconciliation, overdue, my-payments | **The whole point of invoicing** — who paid? who didn't? Partial payments? |
+| Dunning/Collections (Relances) | STANDARD | list, detail, schedule, history, overdue-dashboard | Automated follow-up on unpaid invoices |
+| Reporting | STANDARD | dashboard, export, period-comparison | Financial analysis, tax declarations |
+| Configuration | OPTIONAL | invoice-templates, tax-rates, numbering-rules, payment-terms | Advanced setup |
+
+**Why 1-module Billing is ALWAYS wrong:**
+- Credit notes are legally required in most jurisdictions (EU, US, etc.)
+- Payment tracking is the core purpose of invoicing (receivables management)
+- Without dunning/collections, overdue invoices are invisible to the business
+- A billing app without these is just a CRUD form, not a billing system
+- Any web search for "billing software features" confirms these as table stakes
+
+**Standard business rules (Invoices — domain-specific):**
+- Sequential invoice numbering (no gaps, legally required)
+- Immutability of sent invoices (cannot modify after sending)
+- Credit note must reference original invoice
+- Auto-transition to "Overdue" when dueDate passes and status != Paid
+- Partial payment support (remainingAmount = total - paidAmount)
+- Auto-generate from timesheet data (T&M projects)
+- PDF generation on send (with legal mentions)
+- Tax calculation rules (VAT, withholding, multi-rate)
+
+---
+
+### Project Management
+
+**Minimum modules: 3**
+
+| Module | Classification | Standard Sections | Key Entities |
+|--------|---------------|-------------------|-------------|
+| Projects | CORE | list, detail(tabs: info, tasks, team, budget, milestones, history), dashboard | Project, ProjectMember, ProjectBudget |
+| Tasks | CORE | list, detail, kanban, my-tasks | Task, TaskAssignment |
+| Time Tracking | STANDARD | list, timesheet, approve, my-entries | TimeEntry, TimeValidation |
+| Milestones | STANDARD | list, timeline | Milestone |
+| Resources/Team | OPTIONAL | list, allocation, availability | Resource, Allocation |
+| Reports | OPTIONAL | dashboard, export | (aggregation views) |
+
+**Standard business rules (Time Tracking — domain-specific):**
+- Cannot log time on closed/completed projects
+- Cannot log more than N hours per day
+- Cannot log time in the future
+- Timesheet submission deadline (e.g., end of week)
+- Manager approval required before invoicing
+- Rate calculation based on employee level/project rate
+- Billable vs non-billable hours tracking
+
+---
+
+### E-commerce / Orders
+
+**Minimum modules: 3**
+
+| Module | Classification | Standard Sections |
+|--------|---------------|-------------------|
+| Products | CORE | list, detail(tabs: info, variants, pricing, stock), dashboard |
+| Orders | CORE | list, detail(tabs: info, lines, payments, shipping, history), dashboard |
+| Customers | CORE | list, detail(tabs: info, addresses, orders, history) |
+| Inventory | STANDARD | list, movements, alerts |
+| Shipping | STANDARD | list, detail, tracking |
+| Returns | OPTIONAL | list, detail |
+
+---
+
+### Support / Ticketing
+
+**Minimum modules: 3**
+
+| Module | Classification | Standard Sections |
+|--------|---------------|-------------------|
+| Tickets | CORE | list, detail, dashboard, my-tickets, unassigned |
+| Knowledge Base | CORE | list, detail, search |
+| SLA Management | STANDARD | list, detail, dashboard |
+| Categories | STANDARD | list, detail (hierarchy) |
+| Reports | OPTIONAL | dashboard, export |
+
+---
+
+## Section Archetypes Per Module Pattern
+
+### Workflow Module (approval pattern)
+**MANDATORY sections:** list, detail, approve
+**STANDARD contextual views:** open-requests, rejected, history, my-{entity}
+**OPTIONAL:** dashboard, calendar
+
+### Data-Centric Module (CRUD)
+**MANDATORY sections:** list, detail
+**STANDARD:** dashboard (if > 100 records/month), import, export
+**OPTIONAL:** merge (deduplication)
+
+### Dashboard Module (reporting)
+**MANDATORY sections:** dashboard
+**STANDARD:** export, period-comparison
+**OPTIONAL:** alerts, scheduled-reports
+
+---
+
+## Usage Protocol
+
+1. **step-01 (cadrage):** Use competitive research + this reference to challenge scope BEFORE scope lock
+2. **step-02 (structure):** Compare identified modules against archetype for EACH application
+   - CORE missing = **BLOCKING** AskUserQuestion (add / integrate / exclude with justification)
+   - STANDARD missing = WARNING + proactive suggestion
+   - Module count below minimum = **BLOCKING** challenge
+3. **step-03 (specify):** Compare sections against archetype for EACH module
+   - Propose missing standard sections via AskUserQuestion (multiSelect)
+   - Propose domain-specific business rules from archetype
+4. **step-04 (consolidate):** Verify all CORE modules accounted for (present or excluded with justification)

package/templates/skills/business-analyse/references/multi-app-detection.md

@@ -0,0 +1,149 @@
+# Multi-App Detection Algorithm
+
+> **Purpose:** Detect and extract multiple applications from user prompts using a two-tier approach.
+> Executed early in initialization to determine `workflow_mode` ("application" vs "project").
+
+## Overview
+
+When the user's prompt describes multiple applications or spans multiple business domains, we must recognize this immediately and set `workflow.mode = "project"` to avoid doing cadrage for a single app.
+
+## Tier 1 — Explicit Patterns (ANY match = multi-app detected)
+
+### French patterns:
+- "une application X ... une application Y" (two occurrences of "une application")
+- "application 1: X ... application 2: Y" (numbered applications)
+- "première application ... deuxième application"
+- "app 1: ... app 2: ..."
+
+### English patterns:
+- "an application (for) X ... an application (for) Y" (two occurrences)
+- "application #1: ... application #2: ..." (numbered)
+- "first app ... second app"
+
+### Decision:
+
+If ANY of these patterns is found in `{feature_description}`:
+→ `isMultiApp = true`, `detectionTier = "explicit"`
+
+## Tier 2 — Domain Diversity Analysis (when Tier 1 does not match)
+
+### Definition
+
+A "domain" is an autonomous business perimeter with its own entities and processes (e.g., HR, CRM, Finance, Projects, Sales, Inventory).
+
+### Algorithm
+
+ULTRATHINK: Analyze `{feature_description}` to extract distinct business domains.
+
+1. List all business domains mentioned or implied in the description
+2. Classify each domain:
+   - **DISTINCT** — has its own entities, processes, and lifecycle (e.g., HR vs CRM)
+   - **RELATED** — is a sub-domain of another (e.g., Payroll is a sub-domain of HR)
+3. Count DISTINCT domains only
+
+### Threshold
+
+2+ DISTINCT domains → `isMultiApp = true`, `detectionTier = "domain-diversity"`
+
+### False Positive Protection
+
+- "RH complet avec employés, congés, paie, pointage" = 1 domain (HR) with 4 modules, NOT 4 domains
+- "HR and Payroll management" = 1 domain (HR) with 2 modules — Payroll is RELATED to HR
+- "gestion commerciale avec devis, commandes et facturation" = 1 domain (Sales) with 3 modules
+- Only count as DISTINCT when domains have genuinely independent entity models and processes
+
+## Extraction Algorithm (depends on detection tier)
+
+### IF Tier 1 (explicit):
+
+1. **Identify boundaries:** Split the prompt at each "une application" / "an application" occurrence. Each block = one candidate.
+2. **Extract per candidate:** For each block, derive `name` (application name), `description` (summary of purpose), and `modules[]` (listed modules/features).
+   - Example: `[{ name: "RH", description: "gestion des employés, congés, temps", modules: ["Employés", "Congés", "Temps"] }, ...]`
+3. **Detect shared modules:** Collect all module names across all candidates. Any module appearing in more than one candidate is a shared module.
+   - Example: `sharedModules = ["Temps"]` (appears in both RH and Projet)
+
+### IF Tier 2 (domain-diversity):
+
+1. Each DISTINCT domain = 1 candidate application:
+   - `name` = short domain label (e.g., "RH", "CRM", "Finance")
+   - `description` = user's expressed need for that domain
+   - `modules[]` = sub-functionalities mentioned (can be empty → "(à définir au cadrage)")
+2. Group RELATED sub-domains under their parent DISTINCT domain as modules
+3. **Detect shared modules:** Same logic as Tier 1 — modules appearing in multiple candidates
+
+## Confirmation Dialogue
+
+Display detection result:
+
+```
+{detectionTier == "explicit"
+  ? (language == "fr"
+    ? "### Détection multi-application\n\nJ'ai détecté **{candidates.length} applications** dans votre description :"
+    : "### Multi-application detection\n\nI detected **{candidates.length} applications** in your description:")
+  : (language == "fr"
+    ? "### Détection multi-application\n\nVotre description couvre **{candidates.length} domaines métier distincts**. Chaque domaine pourrait constituer une application séparée :"
+    : "### Multi-application detection\n\nYour description covers **{candidates.length} distinct business domains**. Each domain could be a separate application:")}
+
+| # | Application | Modules identifiés |
+|---|-------------|-------------------|
+{for each candidate: index | name | modules.join(", ") || "(à définir au cadrage)"}
+
+{sharedModules.length > 0
+  ? "⚠️ **Modules partagés détectés :** {sharedModules.join(', ')} — ces modules apparaissent dans plusieurs applications. Ils pourraient constituer une application transversale dédiée."
+  : ""}
+```
+
+### AskUserQuestion Options
+
+```
+question: "{language == 'fr' ? 'Confirmez-vous cette structure multi-application ?' : 'Do you confirm this multi-application structure?'}"
+header: "Architecture"
+options:
+  - label: "{language == 'fr' ? 'Oui, {candidates.length} applications' : 'Yes, {candidates.length} applications'}"
+    description: "{language == 'fr' ? 'Créer un projet avec les applications identifiées' : 'Create a project with the identified applications'}"
+  - label: "{language == 'fr' ? 'Extraire les modules partagés' : 'Extract shared modules'}" (only if sharedModules.length > 0)
+    description: "{language == 'fr' ? 'Créer une application dédiée pour {sharedModules.join(', ')} ({candidates.length + 1} applications au total)' : 'Create a dedicated app for {sharedModules.join(', ')} ({candidates.length + 1} total)'}"
+  - label: "{language == 'fr' ? 'Regrouper certains domaines' : 'Regroup some domains'}" (only if detectionTier == "domain-diversity")
+    description: "{language == 'fr' ? 'Fusionner des domaines en moins d\\'applications' : 'Merge domains into fewer applications'}"
+  - label: "{language == 'fr' ? 'Application unique' : 'Single application'}"
+    description: "{language == 'fr' ? 'Tout regrouper en une seule application avec plusieurs modules' : 'Group everything into one application with multiple modules'}"
+```
+
+## Handling User Responses
+
+### IF "Oui, N applications" or "Extraire les modules partagés":
+
+```yaml
+workflow_mode: "project"
+project_name: derived from feature_description
+candidate_applications: [{ name, description, modules, context }]
+shared_modules_extracted: boolean  # true if user chose extraction
+```
+
+→ Skip step 4 (application name) — applications will be confirmed in step-01-cadrage
+→ Continue to step 5 (language selection)
+
+### IF "Regrouper certains domaines" (Tier 2 only):
+
+Ask via AskUserQuestion:
+```
+question: "{language == 'fr' ? 'Comment souhaitez-vous regrouper ces domaines ? (ex: \"RH + Paie ensemble, CRM seul\")' : 'How would you like to regroup these domains? (e.g., \"HR + Payroll together, CRM alone\")'}"
+header: "Regroupement"
+```
+
+Process user response:
+1. Parse the grouping instructions (natural language)
+2. Rebuild `candidate_applications` based on the specified groups
+3. Re-display the confirmation dialogue with the updated candidates
+
+### IF "Application unique":
+
+```yaml
+workflow_mode: "application"
+```
+
+→ Continue to step 4 normally
+
+### IF no multi-app detected (neither Tier 1 nor Tier 2):
+
+→ Continue to step 4 normally

package/templates/skills/business-analyse/references/portal-classification.md

@@ -0,0 +1,52 @@
+# Portal Classification
+
+> **Note :** La detection initiale des utilisateurs externes a lieu dans le batch 1 (4a).
+> Ce bloc RESOUT la detection en classifiant les stakeholders et configurant le portail.
+
+## External Signals Detection
+
+```
+EXTERNAL_SIGNALS = ["client", "customer", "fournisseur", "supplier", "partenaire",
+  "partner", "portail", "portal", "externe", "external", "tiers", "third-party",
+  "organisation cliente"]
+```
+
+## SmartStack Native Support
+
+> **SmartStack gère nativement les utilisateurs externes :**
+> - **Person Extension Pattern** : User → Employee, Contact, Customer via `UserId` FK
+> - **Organisation Extension** : Organisation → Client, Supplier via `OrganisationId` FK
+> - **Multi-tenant** : portail et interne déployés sur des tenants séparés automatiquement
+
+## Classification and Portal Mode Resolution
+
+SI `_portalDetected` (from batch 1) OU un profil stakeholder (batch 2) match EXTERNAL_SIGNALS :
+  → **Auto-classifier** chaque stakeholder : `audience: "internal" | "external" | "shared"`
+  → **Auto-déduire** `_portalMode` :
+
+| Stakeholders détectés | `_portalMode` |
+|----------------------|---------------|
+| Internes + Externes | `"dual"` |
+| Uniquement externes | `"portal-only"` |
+| Uniquement internes | `"internal-only"` |
+
+## Portal Module Rule (SCOPE LOCK)
+
+SI `_portalMode = "dual"` ou `"portal-only"`:
+  Un portail = UN module "Portal" avec des sections view par entite.
+  INTERDICTION de creer des modules separes MyAccount, MyProjects, MyInvoices.
+  Le module Portal aura des sections (view/inherit) pour chaque zone accessible.
+
+## Client Notification
+
+→ **Informer le client** (statement, PAS de question) :
+
+```
+"{language == 'fr'
+  ? 'J\'ai détecté des utilisateurs externes ({profiles}). SmartStack déploiera automatiquement un portail dédié ({_portalMode}) avec isolation multi-tenant. Les extensions Person/Organisation gèrent nativement la séparation des profils internes et externes.'
+  : 'I detected external users ({profiles}). SmartStack will automatically deploy a dedicated portal ({_portalMode}) with multi-tenant isolation. Person/Organisation extensions natively handle the separation of internal and external profiles.'}"
+```
+
+## Default Case
+
+SI aucun profil ne match EXTERNAL_SIGNALS → `_portalMode = "internal-only"` (défaut silencieux, rien à informer).

package/templates/skills/business-analyse/references/validation-checklist.md

@@ -262,7 +262,36 @@ const checklist = {
     details: "Modules need field validation rules"
   },
 
-  // SECTION 10: GHERKIN SCENARIOS (BLOCKING for format, WARNING for count)
+  // SECTION 10: ANALYSIS DEPTH (BLOCKING)
+  analysisDepthRules: {
+    check: "Business rules include domain-specific rules (not just generic CRUD)",
+    status: countDomainSpecificRules(analysis.businessRules) >= 2 ? "PASS" : "FAIL",
+    blocking: true,
+    details: "Module must have at least 2 domain-specific rules beyond basic validation. " +
+             "Generic rules: date coherence, required fields, unique constraints, basic workflow transitions. " +
+             "Domain-specific: half-day absences, team capacity limits, carry-over expiry, " +
+             "invoice sequential numbering, credit note linking, opportunity probability rules, etc. " +
+             "If C-pre (Business Rules Domain Research) was executed, these should come from web research."
+  },
+
+  sectionCompleteness: {
+    check: "Workflow modules have contextual filtered views",
+    status: (moduleFeatureType === "workflow" && hasContextualViews(analysis.anticipatedSections)) ? "PASS" : "FAIL",
+    blocking: true,
+    details: "Workflow modules must have at least 1 contextual filtered view " +
+             "(e.g., open-requests, rejected, my-X, history) beyond the base CRUD sections. " +
+             "A workflow module with only list/detail/approve is incomplete."
+  },
+
+  webResearchPerformed: {
+    check: "Web research was performed for this module",
+    status: module.domainResearchSource !== "built-in-only" ? "PASS" : "WARNING",
+    blocking: false,
+    details: "Modules without web research have lower completeness confidence. " +
+             "Domain-specific rules and sections may be missing."
+  },
+
+  // SECTION 11: GHERKIN SCENARIOS (BLOCKING for format, WARNING for count)
   gherkinFormat: {
     check: "gherkinScenarios is ARRAY (not single object)",
     status: Array.isArray(specification.gherkinScenarios) ? "PASS" : "FAIL",

package/templates/skills/business-analyse/schemas/sections/analysis-schema.json

@@ -29,18 +29,51 @@
           "category": { "type": "string", "enum": ["validation", "calculation", "workflow", "security", "data"] },
           "statement": { "type": "string", "description": "IF ... THEN ... ELSE ..." },
           "priority": { "type": "string", "enum": ["must", "should", "could"] },
-          "conditions": { "type": "array", "items": { "type": "string" } },
+          "conditions": {
+            "type": "array",
+            "items": {
+              "oneOf": [
+                { "type": "string" },
+                {
+                  "type": "object",
+                  "properties": {
+                    "entity": { "type": "string" },
+                    "field": { "type": "string" },
+                    "operator": { "type": "string", "enum": ["==", "!=", ">", "<", ">=", "<=", "in", "not-in", "is-null", "is-not-null"] },
+                    "value": {}
+                  }
+                }
+              ]
+            }
+          },
           "examples": {
             "type": "array",
             "items": {
               "type": "object",
+              "required": ["input", "expected"],
               "properties": {
-                "input": { "type": "string" },
-                "expected": { "type": "string" }
+                "input": { "type": "string", "description": "Concrete input values" },
+                "expected": { "type": "string", "description": "Expected result/behavior" }
+              }
+            }
+          },
+          "testability": { "type": "string" },
+          "formula": { "type": "string", "description": "BR-CALC calculation formulas" },
+          "sectionCode": { "type": "string", "description": "Section code the rule applies to" },
+          "severity": { "type": "string", "enum": ["blocking", "warning", "info"] },
+          "consequences": {
+            "type": "array",
+            "items": {
+              "type": "object",
+              "required": ["type", "target"],
+              "properties": {
+                "type": { "type": "string", "enum": ["notification", "field-update", "status-change", "block-action", "recalculate"] },
+                "target": { "type": "string" },
+                "description": { "type": "string" }
               }
             }
           },
-          "testability": { "type": "string" }
+          "domainSpecific": { "type": "boolean", "default": false, "description": "True if from domain research" }
         }
       }
     },