@atlashub/smartstack-cli 4.80.0 → 5.0.0

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

@@ -1,174 +0,0 @@
-# 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

@@ -1,149 +0,0 @@
-# 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/naming-conventions.md

@@ -1,253 +0,0 @@
-# Naming Conventions - SmartStack
-
-> **Loaded by:** business-analyse steps when generating codes and routes
-> **Purpose:** Define transformation rules between code identifiers (PascalCase) and URL routes (kebab-case)
-
----
-
-## Module & Application Codes
-
-### In JSON files
-
-- `modules[].code` = **PascalCase** (e.g., `"HumanResources"`, `"TimeManagement"`)
-- `metadata.application` = **PascalCase** (e.g., `"HumanResources"`)
-- Used for: C# namespaces, file paths, class names, folder structure
-
-### In Directory Names (BA docs structure)
-
-- **Project directories**: kebab-case slug chosen by user (e.g., `projet-rh`, `commande-repas`)
-- **Application directories**: kebab-case derived from PascalCase code (e.g., `HumanResources` → `human-resources`)
-- **Module directories**: kebab-case derived from PascalCase code (e.g., `Employees` → `employees`, `TimeManagement` → `time-management`)
-- **"My*" modules**: treated as normal modules (e.g., `MyFollowUp` → `my-follow-up`)
-- Path pattern: `docs/{project-slug}/v{X.Y}/{app-kebab}/{module-kebab}/`
-
-### In URL Routes
-
-- **kebab-case lowercase** (e.g., `"/human-resources/employees"`)
-- Transform: `PascalCase` → `kebab-case` via helper function
-- Used for: Web URLs, navigation routes, API paths
-
----
-
-## Transformation Rules
-
-| Source | Format | Example | Usage |
-|--------|--------|---------|-------|
-| Module code | `PascalCase` | `HumanResources` | C# files, classes, namespaces |
-| Application code | `PascalCase` | `HumanResources` | Namespaces, folders |
-| Route path | `kebab-case` | `/human-resources` | Web URLs, navigation |
-| Section code | `kebab-case` | `time-tracking`, `approve` | URLs, API paths, sections |
-| Resource code | `kebab-case` | `repair-grid`, `employee-form` | Component IDs, resources |
-
----
-
-## Why These Conventions?
-
-### PascalCase for Code
-- **C# Standard**: Namespaces, classes, properties follow PascalCase
-- **File Structure**: Matches .NET project conventions
-- **Compile-time**: Enforced by compiler and naming analyzers
-
-### kebab-case for URLs
-- **Web Standard**: Readable, SEO-friendly, case-insensitive
-- **REST API Convention**: Lowercase routes with hyphens
-- **Frontend Compatibility**: React Router, Vue Router expect lowercase
-- **Database Storage**: Navigation routes stored lowercase prevent case mismatch errors
-
-### Separation of Concerns
-- **Code Identity** ≠ **URL Identity**
-- Backend uses PascalCase internally
-- URLs transform to kebab-case at persistence layer (seed data)
-- Frontend consumes kebab-case routes from database
-
----
-
-## Helper Functions
-
-### C# (Backend Seed Data)
-
-**Location:** `NavigationSeedData.cs` templates in core-seed-data.md
-
-**Usage:**
-```csharp
-Route = ToKebabCase($"/{appCode}/{moduleCode}")
-```
-
-**Transformation Examples:**
-- `HumanResources` → `human-resources`
-- `TimeManagement` → `time-management`
-- `Projects` → `projects` (single word, no change)
-- `AI` → `ai` (acronym lowercase)
-
-**Implementation:** See `templates/skills/business-analyse-develop/references/core-seed-data.md` line 162
-
-### JavaScript (BA Handoff Generation)
-
-**Location:** Used in /business-analyse-html when building seedDataCore
-
-**Usage:**
-```javascript
-const route = `/${toKebabCase(appCode)}/${toKebabCase(moduleCode)}`;
-```
-
-**Implementation:**
-```javascript
-function toKebabCase(code) {
-  return code
-    .replace(/([a-z0-9])([A-Z])/g, '$1-$2')
-    .replace(/([A-Z]+)([A-Z][a-z])/g, '$1-$2')
-    .toLowerCase();
-}
-```
-
-### TypeScript (Frontend MCP)
-
-**Location:** Used in scaffold_routes and validate_frontend_routes
-
-**Usage:**
-```typescript
-const webPath = `/${navRoute.split('.').map(toKebabCase).join('/')}`;
-```
-
-**Implementation:**
-```typescript
-function toKebabCase(str: string): string {
-  return str
-    .replace(/([a-z0-9])([A-Z])/g, '$1-$2')
-    .replace(/([A-Z]+)([A-Z][a-z])/g, '$1-$2')
-    .toLowerCase();
-}
-```
-
----
-
-## Validation
-
-### During Generation (business-analyse-develop)
-
-POST-CHECK after NavigationSeedData generation:
-
-```bash
-# Detect routes with uppercase
-grep -E 'Route = "?/[^"]*[A-Z]' Infrastructure/Persistence/Seeding/Data/*/NavigationSeedData.cs
-```
-
-If match found → ERROR, routes not transformed to kebab-case.
-
-### Via MCP
-
-```bash
-validate_frontend_routes
-```
-
-**Detects:**
-- Routes with uppercase in URLs
-- Seed data routes not matching frontend expectations
-- PascalCase URLs without kebab-case conversion
-
-**Output Example:**
-```
-❌ Case mismatch detected (1 routes with uppercase):
-   Route "humanresources" uses PascalCase in URL.
-   Found: HumanResources → Expected: human-resources
-   Fix: Use ToKebabCase() in NavigationSeedData route generation
-```
-
----
-
-## Common Pitfalls
-
-### ❌ Generating Routes Without Transformation
-
-**Wrong (causes 404 on menu click):**
-```csharp
-Route = $"/{appCode}/{moduleCode}"
-// Result: /HumanResources/Projects
-```
-
-**Correct:**
-```csharp
-Route = ToKebabCase($"/{appCode}/{moduleCode}")
-// Result: /human-resources/projects
-```
-
-### ❌ Hardcoding Routes in lowercase
-
-**Wrong (loses traceability to code):**
-```csharp
-Route = "/humanresources"  // Flattens multi-word into single word
-```
-
-**Correct:**
-```csharp
-Route = ToKebabCase($"/{appCode}")
-// If appCode = "HumanResources" → /human-resources
-```
-
-### ❌ Inconsistent Section/Resource Codes
-
-**Wrong (mixing conventions):**
-```json
-{
-  "code": "TimeTracking",  // PascalCase
-  "route": "/time-tracking"  // kebab-case route doesn't match
-}
-```
-
-**Correct:**
-```json
-{
-  "code": "time-tracking",  // kebab-case from start
-  "route": "/human-resources/time-tracking"
-}
-```
-
-Sections and resources ALWAYS use kebab-case (no transformation needed).
-
----
-
-## Examples
-
-### Full Hierarchy Example
-
-**BA Input (index.json):**
-```json
-{
-  "metadata": {
-    "application": "HumanResources"
-  },
-  "modules": [
-    { "code": "TimeManagement" },
-    { "code": "Projects" }
-  ]
-}
-```
-
-**Generated Routes (seed data):**
-```
-Application: /human-resources
-Module 1:    /human-resources/time-management
-Module 2:    /human-resources/projects
-```
-
-**C# Code Structure:**
-```
-src/Domain/Entities/HumanResources/TimeManagement/TimeEntry.cs
-src/Application/Services/HumanResources/TimeManagement/TimeEntryService.cs
-src/API/Controllers/HumanResources/TimeManagementController.cs
-```
-
-**Frontend Routes (React Router):**
-```tsx
-<Route path="/human-resources/time-management" element={<TimeManagementPage />} />
-<Route path="/human-resources/projects" element={<ProjectsPage />} />
-```
-
----
-
-## References
-
-- **Template:** `templates/skills/business-analyse-develop/references/core-seed-data.md`
-- **Validation:** `src/mcp/tools/validate-frontend-routes.ts`
-- **POST-CHECK:** `templates/skills/business-analyse-develop/steps/step-02-execute.md` (section 5)
-- **Handoff:** `/business-analyse-handoff` skill (handoff section)

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

@@ -1,52 +0,0 @@
-# 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).