@atlashub/smartstack-cli 4.74.0 → 4.76.0

package/templates/skills/business-analyse/references/domain-research-playbook.md

@@ -0,0 +1,234 @@
+# Domain Research Playbook
+
+> **Web research is the #1 quality differentiator.**
+> An analysis WITHOUT research is a 2/10 regardless of structural quality.
+> An analysis WITH multi-level research can be 8-10/10.
+> This step takes 2-5 minutes per application and dramatically improves analysis quality.
+
+## MANDATORY — BLOCKING
+
+Web research is **MANDATORY and BLOCKING**. This is NOT optional.
+
+If WebSearch tool is unavailable:
+1. Display WARNING to user: "WebSearch indisponible. Qualite d'analyse degradee."
+2. AskUserQuestion: "Continuer sans recherche web ? (Non recommande — qualite 4/10 max)"
+3. IF user declines → STOP and recommend fixing WebSearch availability
+4. IF user confirms → proceed with `{domain_research}.source = "built-in-only"`
+   and flag EVERY module with `qualityFlag: "no-web-research"`
+   → Load `references/module-completeness-challenge.md` as primary fallback data source
+
+---
+
+## Level 1 : Recherche par APPLICATION (step-01 cadrage)
+
+> **WHEN:** During step-01 Phase 1 (ECOUTE), BEFORE engaging the client.
+> **WHO:** For EACH candidate application in a multi-app project, or the single app.
+
+For EACH application:
+
+### 1a. Module Discovery Search (MANDATORY)
+
+```
+Query: "{app_type} application modules features complete list"
+```
+
+Examples:
+- "billing invoicing application modules features complete list ERP"
+- "HR human resources application modules features complete list"
+- "CRM application modules features complete list"
+- "project management application modules features complete list"
+
+**EXTRACT:**
+- Standard modules for this app type
+- Which are CORE (always present) vs STANDARD vs OPTIONAL
+- Common module names and their scope
+- Module dependencies
+
+### 1b. Competitive Research (MANDATORY)
+
+```
+Query: "best {app_type} software features comparison"
+```
+
+Examples:
+- "best invoicing software features comparison 2025"
+- "best HR software absence management features"
+- "best CRM software features comparison"
+- "best project management software features"
+
+**EXTRACT:**
+- What do real commercial products offer? (BambooHR, Sage, Salesforce, etc.)
+- Common features users expect as baseline
+- Differentiating features that add value
+- Features that are table stakes vs nice-to-have
+
+### 1c. Data Model Research (1 per app)
+
+```
+Query: "{app_type} data model entities relationships best practices"
+```
+
+**EXTRACT:**
+- Standard entities and their relationships
+- Common anti-patterns to avoid (e.g., "storing salary on Employee instead of salary history table")
+- Industry-standard naming and cardinality
+
+### Storage Format
+
+```yaml
+{domain_research}.applications[{app_code}]:
+  standardModules:
+    - name: "Invoices"
+      classification: "CORE"  # CORE | STANDARD | OPTIONAL
+      description: "Invoice lifecycle management"
+      standardSections: ["list", "detail", "generate", "dashboard"]
+    - name: "CreditNotes"
+      classification: "CORE"
+      description: "Legally required for invoice corrections/cancellations"
+      standardSections: ["list", "detail"]
+  competitiveInsights:
+    - product: "Sage"
+      keyFeatures: ["auto-numbering", "multi-currency", "credit notes", "recurring invoices"]
+    - product: "Stripe Invoicing"
+      keyFeatures: ["payment tracking", "dunning", "tax calculation"]
+  dataModel:
+    entities: ["Invoice", "InvoiceLine", "CreditNote", "Payment", "PaymentTerm"]
+    relationships: ["Invoice → Client (N:1)", "Invoice → InvoiceLine (1:N)"]
+    antiPatterns: ["single invoice entity without credit notes"]
+```
+
+---
+
+## Level 2 : Recherche par MODULE (step-03 specify)
+
+> **WHEN:** During step-03 section A-bis, BEFORE entity specification.
+> **WHO:** For EACH module with >= 2 entities. SKIP: Portal, pure config modules.
+
+For EACH module:
+
+### 2a. Section/UX Research (MANDATORY)
+
+```
+Query: "{module_domain} management system features screens views UX"
+```
+
+Examples:
+- "absence management system features screens views"
+- "invoice management application features views UX"
+- "CRM opportunity pipeline features screens"
+
+**EXTRACT:**
+- Standard sections/views (list, detail, calendar, kanban, etc.)
+- **Contextual filtered views** — this is CRITICAL:
+  - Workflow modules: open-requests, rejected, history, my-{entity}
+  - Data modules: by-status, by-period, by-category
+- Dashboard/reporting expectations
+- Standard UX patterns (approval queue, batch actions, etc.)
+
+### 2b. Business Rules Research (MANDATORY for workflow modules)
+
+```
+Query: "{module_domain} business rules validation constraints best practices"
+```
+
+Examples:
+- "absence leave management business rules HR constraints"
+- "invoice billing business rules validation constraints"
+- "CRM opportunity management business rules"
+
+**EXTRACT:**
+- **Domain-specific validation rules** (NOT just "date must be valid"):
+  - Half-day absences, notice periods, capacity limits
+  - Invoice sequential numbering, credit note linking
+  - Opportunity probability rules, stage-gate validation
+- Calculation rules with formulas
+- Workflow constraints and edge cases
+- Regulatory/compliance requirements
+
+### 2c. Entity Design Research (1 per complex entity, OPTIONAL)
+
+```
+Query: "{entity_name} entity design pattern ERP best practices"
+```
+
+**EXTRACT:**
+- Standard attributes for this entity type
+- Versioned vs. inline data patterns (e.g., salary history)
+- Common relationships and cardinality
+- Known anti-patterns
+
+### Storage Format
+
+```yaml
+{domain_research}.modules[{module_code}]:
+  sections:
+    standard: ["list", "detail", "approve", "calendar"]
+    contextualViews: ["open-requests", "rejected", "history", "my-balance"]
+    dashboard: ["absence-kpi", "team-calendar"]
+  businessRules:
+    domainSpecific:
+      - "Half-day absences (morning/afternoon)"
+      - "Minimum 48h notice for planned leave"
+      - "Max 30% of team absent simultaneously"
+      - "Carry-over days expire after March 31"
+      - "Medical certificate for absences > 3 days"
+    regulatory:
+      - "Minimum 25 days paid leave per year (France)"
+  entityPatterns:
+    Absence:
+      standardAttributes: ["employeeId", "typeId", "startDate", "endDate", "duration", "status", "halfDay"]
+      versionedData: []
+      workflowStates: ["Draft", "Submitted", "Approved", "Rejected", "Cancelled"]
+```
+
+---
+
+## Level 3 : Recherche reglementaire (si applicable)
+
+> **WHEN:** During step-01 for applicable domains, alongside Level 1 research.
+> **WHO:** Billing/Finance, HR, any domain with legal requirements.
+
+### For Billing/Finance domains:
+```
+Query: "{country} invoice legal requirements numbering format"
+```
+
+**EXTRACT:** Sequential numbering, immutability of sent invoices, retention period, credit note requirements, VAT rules.
+
+### For HR domains:
+```
+Query: "{country} absence leave legal requirements types"
+```
+
+**EXTRACT:** Mandatory leave types, minimum days, carry-over rules, medical certificate requirements.
+
+Store in: `{domain_research}.regulatory[]`
+
+---
+
+## Search Budget
+
+| Project Type | Level 1 (per app) | Level 2 (per module) | Level 3 | Total |
+|---|---|---|---|---|
+| Single-app, 1-3 modules | 3 searches | 2/module = 4-6 | 0-2 | **7-11** |
+| Single-app, 4-6 modules | 3 searches | 2/module = 8-12 | 0-2 | **11-17** |
+| Multi-app (4 apps, ~10 modules) | 3/app = 12 | 2/module = 16-20 | 0-4 | **28-36** |
+
+> **Token impact:** Each search returns ~500-1000 tokens. Total for a 4-app project: ~15K-30K tokens.
+> This is a small price for dramatically improved analysis quality.
+
+---
+
+## Critical Notes
+
+> **CRITICAL:** This research is INTERNAL context. Do NOT show raw search results to the client.
+> Use the findings to:
+> - **Challenge scope completeness** — flag CORE modules the user didn't mention
+> - **Ground entity architecture** — use real-world data models, not guesswork
+> - **Propose domain-specific business rules** — go beyond generic CRUD validation
+> - **Anticipate contextual views** — workflow modules need filtered views
+> - **Inform proactive suggestions** — "standard billing also includes credit notes because..."
+> - **Prevent common anti-patterns** — catch mistakes before they become architecture
+
+> **NEVER use research as an excuse to skip user validation.**
+> Research INFORMS your proposals. The user VALIDATES them.

package/templates/skills/business-analyse/references/entity-sourcing-presentation.md

@@ -0,0 +1,166 @@
+# Entity Sourcing Presentation (4-Phase Flow)
+
+> **When the analysis detects a referenced entity/concept (e.g., "Projets" referenced by activities, "Clients" referenced by orders), ALWAYS analyze and recommend BEFORE asking the client.**
+> This pattern detects potential new modules not mentioned in the original brief.
+
+## PHASE 1 — ULTRATHINK: Silent Architecture Analysis (NO output to client)
+
+> **The AI reasons about the entity BEFORE presenting options. This is internal thinking only.**
+
+```
+ULTRATHINK — Entity Architecture Analysis for {entity_name}:
+
+1. DOMAIN COHERENCE (from decision tree in reference)
+   - Application domain: {app_description}
+   - Entity fit: CORE | SUPPORT | PERIPHERAL
+   - Justification: {1 sentence — why this entity is/isn't core to the app}
+   - Example: "Projets" in a time management app = CORE (without projects, time entries have no target)
+   - Example: "Codes d'imputation" in a time management app = SUPPORT (useful for accounting, but not central)
+
+2. ENTITY SCORING (5 criteria, 0-3 each — from scoring grid in reference)
+   - Lifecycle:  {score}/3 — {brief justification}
+   - Actors:     {score}/3 — {brief justification}
+   - Relations:  {score}/3 — {brief justification}
+   - Volume:     {score}/3 — {brief justification}
+   - Autonomy:   {score}/3 — {brief justification}
+   - TOTAL:      {total}/15 → {classification: config_list | in_app | light_module | full_module}
+
+3. PRE-CLASSIFICATION CHECK (from entity patterns in reference)
+   - Does {entity_name} match a known pattern? → {yes: which one | no: use scoring}
+   - Override needed? → {yes: why | no}
+
+4. RECOMMENDATION
+   - Option: {config_list | in_app_section | new_module | external_system}
+   - Confidence: HIGH | MEDIUM | LOW
+   - Reasoning: {1-2 sentences}
+   - Risk if wrong choice: {what goes wrong if user picks a different option}
+
+5. IF recommendation = new_module → PRE-BUILD ARCHITECTURE
+   - Module code: {PascalCase}
+   - Section `list`: {main entity grid + create action + navigation to detail}
+   - Detail page tabs: [{tab_name: content}] (accessible by clicking a row in list)
+   - Additional sections: [{code: justification}] (ONLY functional sections: dashboard, approve, import, rapport...)
+   - Dependencies: [{which modules reference/are referenced by this entity}]
+   - Topological position: layer {N} (foundation if no dependencies)
+```
+
+## PHASE 2 — Present Analysis & Recommendation to Client
+
+**BEFORE the AskUserQuestion, display the analysis as markdown:**
+
+```
+### {language == "fr" ? "Analyse" : "Analysis"} : {entity_plural}
+
+{language == "fr"
+  ? "Les **{entity_plural}** sont référencés par {parent_module} ({relationship_description})."
+  : "**{entity_plural}** are referenced by {parent_module} ({relationship_description})."}
+
+{language == "fr" ? "**Mon analyse :**" : "**My analysis:**"}
+- {language == "fr" ? "Cohérence domaine" : "Domain coherence"} : **{CORE|SUPPORT|PERIPHERAL}** — {justification}
+- {language == "fr" ? "Score de complexité" : "Complexity score"} : **{score}/15** ({classification})
+- {language == "fr" ? "Recommandation" : "Recommendation"} : **{recommended_option}** — {reasoning}
+```
+
+**IF recommendation = new_module AND confidence >= MEDIUM, ALSO display:**
+
+```
+{language == "fr" ? "**Architecture proposée :**" : "**Proposed architecture:**"}
+
+| {language == "fr" ? "Niveau" : "Level"} | {language == "fr" ? "Valeur" : "Value"} | {language == "fr" ? "Justification" : "Rationale"} |
+|--------|--------|---------------|
+| Application | `{app_code}` | {app_name} |
+| Module | `{ModuleCode}` | {language == "fr" ? "{pourquoi ce découpage}" : "{why this decomposition}"} |
+
+| Section | {language == "fr" ? "Justification" : "Rationale"} | Resources |
+|---------|---------------|-----------|
+| `list` | {language == "fr" ? "Page principale : grille, création, navigation vers détail" : "Main page: grid, create action, navigate to detail"} | {entity}-grid, {entity}-filters, {entity}-form |
+| {additional_section} | {justification} | {resources} |
+
+{language == "fr"
+  ? "**Page détail** (onglets accessibles depuis la liste) :"
+  : "**Detail page** (tabs accessible from list):"}
+
+| {language == "fr" ? "Onglet" : "Tab"} | {language == "fr" ? "Contenu" : "Content"} |
+|--------|---------|
+| {language == "fr" ? "Informations" : "Information"} | {language == "fr" ? "Fiche principale" : "Main record"} |
+| {tab_name} | {tab_content} |
+
+{language == "fr"
+  ? "**Impact :** {ModuleName} deviendra une dépendance de {parent_module} (couche {N} du graphe)."
+  : "**Impact:** {ModuleName} will become a dependency of {parent_module} (layer {N} in the graph)."}
+```
+
+## PHASE 3 — Ask with Recommended Option First
+
+**Order the options with the recommendation FIRST, marked "(Recommandé)" / "(Recommended)":**
+
+```
+question: "{language == 'fr'
+  ? 'Comment souhaitez-vous gérer les {entity_plural} ?'
+  : 'How do you want to manage {entity_plural}?'}"
+header: "{entity_name}"
+options:
+  (ORDER: recommended option FIRST, then the 3 remaining options in logical order)
+
+  IF recommendation = new_module:
+  - label: "{language == 'fr' ? 'Nouveau module dédié (Recommandé)' : 'New dedicated module (Recommended)'}"
+    description: "{language == 'fr'
+      ? 'Module {ModuleCode} avec page liste, détail par onglets, permissions dédiées'
+      : '{ModuleCode} module with list page, tabbed detail, dedicated permissions'}"
+  - label: "{language == 'fr' ? 'Géré dans l\'app' : 'Managed in app'}"
+    description: "..."
+  - label: "{language == 'fr' ? 'Système externe' : 'External system'}"
+    description: "..."
+  - label: "{language == 'fr' ? 'Liste simple en config' : 'Simple config list'}"
+    description: "..."
+
+  IF recommendation = config_list:
+  - label: "{language == 'fr' ? 'Liste simple en config (Recommandé)' : 'Simple config list (Recommended)'}"
+    description: "{language == 'fr'
+      ? 'Table de référence administrable, pas de module dédié'
+      : 'Admin-managed reference table, no dedicated module'}"
+  - label: "{language == 'fr' ? 'Géré dans l\'app' : 'Managed in app'}"
+    description: "..."
+  - label: "{language == 'fr' ? 'Nouveau module dédié' : 'New dedicated module'}"
+    description: "..."
+  - label: "{language == 'fr' ? 'Système externe' : 'External system'}"
+    description: "..."
+
+  IF recommendation = in_app_section:
+  - label: "{language == 'fr' ? 'Géré dans l\'app (Recommandé)' : 'Managed in app (Recommended)'}"
+    description: "{language == 'fr'
+      ? 'Accessible via un onglet dans la page détail de {parent_module}'
+      : 'Accessible via a tab in {parent_module} detail page'}"
+  - label: "{language == 'fr' ? 'Nouveau module dédié' : 'New dedicated module'}"
+    description: "..."
+  - label: "{language == 'fr' ? 'Liste simple en config' : 'Simple config list'}"
+    description: "..."
+  - label: "{language == 'fr' ? 'Système externe' : 'External system'}"
+    description: "..."
+
+  IF recommendation = external_system:
+  - label: "{language == 'fr' ? 'Système externe (Recommandé)' : 'External system (Recommended)'}"
+    description: "{language == 'fr'
+      ? 'Les {entity_plural} viennent d\'un autre système (import ou API)'
+      : '{entity_plural} come from another system (import or API)'}"
+  - label: "{language == 'fr' ? 'Nouveau module dédié' : 'New dedicated module'}"
+    description: "..."
+  - label: "{language == 'fr' ? 'Géré dans l\'app' : 'Managed in app'}"
+    description: "..."
+  - label: "{language == 'fr' ? 'Liste simple en config' : 'Simple config list'}"
+    description: "..."
+
+  IF confidence = LOW (no clear recommendation):
+  (all 4 options in neutral order, NO "(Recommandé)" tag)
+```
+
+## PHASE 4 — Process Answer
+
+| Choice | Action |
+|--------|--------|
+| **Géré dans l'app** | Entity becomes a sub-entity of the parent module. Add as a **tab in the detail page** of the referencing module. Note in coverageMatrix with `parentModule` field. |
+| **Nouveau module dédié** | **Add new module to `{pre_analysis}.detected_modules[]`** with the proposed architecture (sections, detail tabs, dependencies). Add to `coverageMatrix` as inScope. The `list` section is ALWAYS the main section. Additional sections ONLY for distinct functional sections (dashboard, approve, import...). `create` and `edit` are ACTIONS within `list` and detail pages, NEVER standalone sections. |
+| **Système externe** | Flag for integration specification. Add to `coverageMatrix` as integration. Load questionnaire materials on integrations if not already covered. |
+| **Liste simple en config** | Entity becomes a lookup/reference table (no dedicated module, no section). Note in coverageMatrix as config data. |
+
+> **CRITICAL:** The intelligence of this step is in the ULTRATHINK analysis. The AI must REASON about domain coherence, score the entity, and recommend — not just present 4 neutral options. The client can always override the recommendation, but they should benefit from expert architectural guidance.

package/templates/skills/business-analyse/references/init-resume-logic.md

@@ -0,0 +1,70 @@
+# Initialize Resume Logic & Error Handling
+
+> **Purpose:** Handle interruptions, resume previous workflows, and route based on status.
+> Executed at the end of initialization to check if a workflow can be resumed.
+
+## Error Handling Matrix
+
+| Error | Action |
+|-------|--------|
+| Config missing | Create fresh with defaults, continue |
+| Directory creation fails | Check permissions, display error, EXIT |
+| index.json creation fails | Validate ba-writer, retry or fallback |
+| Feature ID not unique | Generate new ID, retry |
+
+## Resume After Interruption
+
+If initialization was interrupted:
+
+1. Check `.business-analyse/config.json` for currentFeature or currentProject
+2. If project ID exists, search for project index.json in `docs/*/v*/` (or legacy `docs/business-analyse/`)
+   - If found with scope = "project": resume project mode (see Project Resume below)
+3. If feature ID exists, search for index.json in `docs/`
+4. If found, check status and `metadata.workflow.lastCompletedStep`
+
+## Status-Based Resume Routing (check in this order)
+
+### If status = `"handed-off"` or `"consolidated"`
+
+→ Display: "BA workflow complete. Use /business-analyse-html to generate HTML, /business-analyse-review for corrections."
+→ **STOP**
+
+### If status = `"specified"` AND `metadata.workflow.allModulesSpecified === true`
+
+→ Resume at `step-04-consolidate.md`
+→ Display: "All modules specified — resuming at consolidation..."
+
+### If status = `"specified"` AND `metadata.workflow.completedModules.length > 0` AND `metadata.workflow.completedModules.length < metadata.workflow.moduleOrder.length`
+
+→ Resume at `step-03-specify.md` (continue specifying remaining modules)
+→ Display: "Resuming module specification ({completedCount}/{totalCount})..."
+
+### Otherwise
+
+→ Offer to resume from last completed step
+
+### If not found
+
+→ Create fresh index.json
+
+## Project Resume (project mode)
+
+If a project-level index.json is found (scope = "project"):
+
+### If status = `"draft"` or `"framed"`
+
+→ Resume at `step-01-cadrage.md`
+
+### If status = `"decomposed"`
+
+→ Check `metadata.workflow.currentApplicationIndex` and `completedApplications[]`
+→ Resume module specification for current application (step-02 or step-03)
+
+### If status = `"specified"`
+
+→ All applications specified → Resume at `step-04-consolidate.md`
+
+### If status = `"consolidated"`
+
+→ Display: "BA workflow complete. Use /business-analyse-html to generate HTML."
+→ **STOP**

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)