@atlashub/smartstack-cli 4.81.0 → 5.0.0

package/templates/skills/audit-route/steps/step-02-conformity.md

@@ -1,193 +0,0 @@
----
-name: step-02-conformity
-description: Evaluate conformity of each element and scan for anti-patterns
-next_step: steps/step-03-report.md
----
-
-# Step 2: Conformity Analysis
-
-## MANDATORY EXECUTION RULES:
-- Load `references/routing-pattern.md` FIRST for the reference pattern
-- Read each element's FULL source code before evaluating
-- NEVER judge developers — analyze code objectively
-- Distinguish errors from conscious architectural choices
-- If a deviation has a valid technical justification, say so explicitly
-- Cross-reference manual findings with MCP results from `{mcp_results}` (step-00)
-
-## YOUR TASK:
-For each of the 5 elements found in Step 1, evaluate conformity against the reference pattern. Then scan the entire codebase for anti-patterns.
-
----
-
-## EXECUTION SEQUENCE:
-
-### Phase A: Conformity Evaluation (per element)
-
-For each of the 5 elements, read the full source file and evaluate:
-
-#### Rating Scale:
-| Rating | Symbol | Meaning |
-|--------|--------|---------|
-| Conforme | ✅ | Implementation matches the pattern |
-| Partiellement conforme | ⚠️ | Intent is correct but execution deviates |
-| Non conforme | ❌ | Implementation contradicts the pattern |
-| Absent | 🔴 | Element does not exist |
-
-#### For each element, record:
-
-**If ✅ Conforme:**
-- Brief confirmation of what makes it compliant
-- Any notable strengths or best practices observed
-
-**If ⚠️ Partiellement conforme, ❌ Non conforme, or 🔴 Absent — answer ALL 5 questions:**
-
-**a) Qu'est-ce qui a ete fait a la place ?**
-Describe precisely the alternative implementation found in the code.
-Include specific file paths and line numbers.
-
-**b) Pourquoi est-ce que ca ne respecte pas le pattern ?**
-Technical explanation of the deviation:
-- Tight coupling (front depends on route structure)
-- Static routes (hardcoded in JSX instead of API-driven)
-- Missing guard (no permission check at route level)
-- Non-lazy imports (eager loading bloats bundle)
-- Incomplete implementation (partial API usage)
-
-**c) Pourquoi le developpeur a probablement fait ca ?**
-Formulate a benevolent hypothesis:
-- Pattern unknown at development time?
-- Technical constraint (bundler, framework limitation)?
-- Deliberate MVP simplification?
-- Misunderstanding of front/back responsibility separation?
-- Legacy architecture inheritance?
-- Confusion between static protected routes and dynamic routes?
-- Migration in progress (intentional intermediate state)?
-
-**d) Quelle est la consequence concrete de cette deviation ?**
-Concrete impact:
-- DB/front coupling (routes changes require front deploy)
-- Potential security flaw (permission bypass)
-- Rigidity (adding a route requires code change + deploy)
-- Technical debt (maintenance burden)
-- Bundle size impact (non-lazy loading)
-- User experience (flash of wrong page, etc.)
-
-**e) Comment migrer vers le pattern cible ?**
-Concrete migration steps considering existing code:
-- DO NOT propose a complete rewrite if a targeted refactor suffices
-- Number the steps in priority order
-- Estimate scope: small (1-2 files), medium (3-5 files), large (6+ files)
-- Note any prerequisites or dependencies between migration steps
-
----
-
-### Phase B: Anti-Pattern Scan
-
-Scan the ENTIRE codebase (not just routing files) for these anti-patterns:
-
-#### B1. Hardcoded Routes in JSX
-```
-Grep patterns (in {web_root}):
-  - <Route\s+path=      (outside DynamicRouter)
-  - path:\s*['"/]       (in non-config files)
-  - navigate\(['"]\/    (hardcoded navigation targets)
-  - to=['"]\/           (Link/NavLink with hardcoded paths)
-  - href=['"]\/(?!http) (internal links with hardcoded paths)
-```
-
-**IMPORTANT**: Exclude legitimate cases:
-- DynamicRouter.tsx itself (it generates routes dynamically)
-- Test files
-- Constants files that define route patterns for DynamicRouter consumption
-- Documentation files
-
-#### B2. Hardcoded Permissions in Components
-```
-Grep patterns (in {web_root}):
-  - hasPermission\(['"]   (string literal permission checks)
-  - permission.*===       (direct comparison)
-  - role.*===.*['"]admin  (role-based instead of permission-based)
-  - canAccess\(['"]       (string literal access checks)
-```
-
-**Distinguish**: Permission checks using API-provided data (OK) vs hardcoded permission strings (anti-pattern).
-
-**NOTE**: Components checking `permissionPath` from the menu API or from `useRouteConfig` data are CONFORMING — this is defense in depth, not hardcoding.
-
-#### B2bis. MCP-detected Hardcoded Paths (cross-reference)
-```
-If {mcp_results.frontend_routes} is available:
-  - Merge MCP apiClients.issues (type: 'invalid-path') with manual B1 findings
-  - Add any MCP-detected hardcoded navigate()/Link paths not found by manual grep
-  - Deduplicate: same file:line from both sources counts as ONE finding
-  - Mark source: [MANUAL], [MCP], or [BOTH] for each finding
-```
-
-#### B3. Non-Lazy Imports in Registry
-```
-Grep patterns (in componentRegistry files):
-  - ^import .* from      (eager imports of page components)
-  - require\(             (CommonJS require of pages)
-```
-
-**Expected pattern**: `lazy(() => import(...))`
-
-#### B4. Missing Suspense Boundaries
-```
-Grep patterns (in {web_root}):
-  - Check DynamicRouter and App.tsx for <Suspense> wrapping
-  - Check if lazy components are rendered without Suspense parent
-```
-
-#### B5. Route/Permission Path Misalignment
-```
-Cross-reference:
-  - Backend: permission paths in navigation seed data
-  - Frontend: permission checks in components
-  - Look for mismatches between API-provided paths and frontend expectations
-```
-
-#### B6. Duplicate Route Definitions
-```
-Check for routes defined in multiple places:
-  - DynamicRouter + another router file
-  - Static route config + dynamic route config
-  - Multiple files registering the same path
-```
-
----
-
-### Phase C: Compile Conformity Summary
-
-```
-## Conformity Results
-
-| # | Element | Rating | Key Finding |
-|---|---------|--------|-------------|
-| 1 | componentRegistry | ✅/⚠️/❌/🔴 | {one-line summary} |
-| 2 | ProtectedRoute | ✅/⚠️/❌/🔴 | {one-line summary} |
-| 3 | DynamicRouter | ✅/⚠️/❌/🔴 | {one-line summary} |
-| 4 | useRouteConfig | ✅/⚠️/❌/🔴 | {one-line summary} |
-| 5 | Navigation API | ✅/⚠️/❌/🔴 | {one-line summary} |
-
-## Anti-Patterns Detected: {count}
-
-| # | Anti-Pattern | File:Line | Severity | Description |
-|---|-------------|-----------|----------|-------------|
-| 1 | {type} | {file}:{line} | HIGH/MED/LOW | {description} |
-| ... | | | | |
-
--> Proceeding to final report...
-```
-
----
-
-## SUCCESS METRICS:
-- Each element rated with justification
-- All 5 causal questions answered for every deviation
-- Anti-pattern scan covers entire web_root (not just routing files)
-- False positives excluded (legitimate uses identified)
-- Conformity summary table complete
-
-## NEXT STEP:
-After displaying conformity results, proceed directly to `./step-03-report.md`

package/templates/skills/audit-route/steps/step-03-report.md

@@ -1,201 +0,0 @@
----
-name: step-03-report
-description: Generate the final structured audit report with migration plan
----
-
-# Step 3: Final Report
-
-## MANDATORY EXECUTION RULES:
-- Use ALL data collected from steps 0-2
-- Follow the EXACT output structure below
-- Prioritize migration steps by impact (critical > important > nice-to-have)
-- Include file:line references for every finding
-- Keep executive summary to 3 lines maximum
-
-## YOUR TASK:
-Generate the complete structured audit report.
-
----
-
-## OUTPUT STRUCTURE:
-
-Generate the following report EXACTLY in this format:
-
-```markdown
----
-
-# Audit Dynamic Routing — {project_name}
-
-**Date**: {current_date}
-**Branch**: {current_branch}
-**Scope**: {scope}
-**Strict mode**: {strict}
-
----
-
-## Resume executif
-
-**Score global : {X}/5 elements conformes — Statut : {OK / A corriger / Critique}**
-
-{Line 1: Overall architecture state in one sentence}
-{Line 2: Most critical finding or strength}
-{Line 3: Recommended immediate action (if any)}
-
----
-
-## 1. componentRegistry
-**Statut** : {✅ / ⚠️ / ❌ / 🔴}
-**Fichier** : {path:line or ABSENT}
-
-{If deviation: full 5-question causal analysis (a through e)}
-{If conforme: brief confirmation with notable strengths}
-
----
-
-## 2. ProtectedRoute
-**Statut** : {✅ / ⚠️ / ❌ / 🔴}
-**Fichier** : {path:line or ABSENT}
-
-{If deviation: full 5-question causal analysis}
-{If conforme: brief confirmation}
-
----
-
-## 3. DynamicRouter
-**Statut** : {✅ / ⚠️ / ❌ / 🔴}
-**Fichier** : {path:line or ABSENT}
-
-{If deviation: full 5-question causal analysis}
-{If conforme: brief confirmation}
-
----
-
-## 4. useRouteConfig (hook de fetch)
-**Statut** : {✅ / ⚠️ / ❌ / 🔴}
-**Fichier** : {path:line or ABSENT}
-
-{If deviation: full 5-question causal analysis}
-{If conforme: brief confirmation}
-
----
-
-## 5. API Navigation
-**Statut** : {✅ / ⚠️ / ❌ / 🔴}
-**Endpoint** : {method path or ABSENT}
-
-{If deviation: full 5-question causal analysis}
-{If conforme: brief confirmation}
-
----
-
-## Validation MCP (baseline automatique)
-
-{If MCP unavailable: "MCP non disponible — audit base sur l'analyse manuelle uniquement."}
-
-{If MCP available:}
-
-### validate_frontend_routes
-| Metrique | Valeur |
-|----------|--------|
-| Valid | {yes/no} |
-| Registry exists | {yes/no} |
-| Registered keys | {N} |
-| Missing keys | {N} |
-| API client issues | {N} |
-| Recommendations | {list} |
-
-### validate_conventions (frontend-routes)
-| Metrique | Valeur |
-|----------|--------|
-| Errors | {N} |
-| Warnings | {N} |
-| Seed data routes checked | {N} |
-
-### Divergences MCP vs analyse manuelle
-{List any differences between MCP automated results and manual analysis.
-If both agree, state: "Aucune divergence — MCP et analyse manuelle sont alignes."}
-
----
-
-## Anti-patterns detectes
-
-{If none: "Aucun anti-pattern detecte."}
-
-{If found, list ALL with file:line references:}
-
-| # | Type | Fichier:Ligne | Severite | Description |
-|---|------|--------------|----------|-------------|
-| 1 | {type} | {file}:{line} | {CRITIQUE/IMPORTANT/MINEUR} | {description} |
-
-### Detail par anti-pattern
-
-#### AP-{n}: {title}
-- **Localisation** : {file}:{line}
-- **Code concerne** :
-  ```tsx
-  {relevant code snippet, max 5 lines}
-  ```
-- **Probleme** : {why this is an anti-pattern}
-- **Impact** : {concrete consequence}
-- **Correction** : {specific fix}
-
----
-
-## Plan de migration priorise
-
-{If no migration needed: "Aucune migration necessaire — l'architecture est conforme au pattern cible."}
-
-{If migration needed:}
-
-### Critique (bloquer toute PR)
-{numbered list of critical fixes with file references and estimated scope}
-
-### Important (a planifier dans le sprint)
-{numbered list of important fixes}
-
-### Nice-to-have (backlog)
-{numbered list of improvements}
-
-### Ordre de migration recommande
-{If multiple fixes, specify dependency order:}
-1. {First fix — prerequisite for others}
-2. {Second fix — depends on #1}
-3. ...
-
----
-
-## Metriques
-
-| Metrique | Valeur |
-|----------|--------|
-| Elements conformes | {X}/5 |
-| Elements partiellement conformes | {Y}/5 |
-| Elements non conformes | {Z}/5 |
-| Elements absents | {W}/5 |
-| Anti-patterns detectes | {count} |
-| Anti-patterns critiques | {count} |
-| Fichiers a modifier | {count} |
-| Estimation effort migration | {Faible/Moyen/Eleve} |
-| MCP baseline disponible | {Oui/Non} |
-| Divergences MCP vs manuel | {count} |
-
----
-```
-
----
-
-## REPORT QUALITY RULES:
-
-1. **Every finding has evidence** — file:line or code snippet
-2. **No vague statements** — "some routes are hardcoded" -> "3 routes hardcoded in TicketListView.tsx:42, UserPage.tsx:18, AdminDashboard.tsx:7"
-3. **Migration steps are actionable** — not "refactor the routing" but "Move Route definition from App.tsx:34-56 to DynamicRouter, add componentKey 'admin.dashboard' to PageRegistry"
-4. **Distinguish SmartStack-specific patterns** — Some deviations from the generic pattern may be correct for SmartStack SDK architecture. Flag these as "SmartStack-specific: conforming to SDK pattern" rather than as deviations
-5. **Be honest about ambiguity** — If you cannot determine whether a deviation is intentional, say "Intention ambigue" and present both interpretations
-
-## SUCCESS METRICS:
-- Report follows exact structure above
-- All sections populated with data from steps 0-2
-- Executive summary is exactly 3 lines
-- Migration plan is prioritized and actionable
-- Metrics table is complete and accurate
-- Every finding has a file:line reference

package/templates/skills/business-analyse/SKILL.md

@@ -1,252 +0,0 @@
----
-name: business-analyse
-description: "Iterative multi-module business analysis with progressive context loading, JSON-first architecture, and interactive HTML deliverables."
-model: opus
-user_invocable: true
----
-
-# /business-analyse — v2
-
-## Architecture
-
-**2 phases, 5 steps** — "Macro vers Specification"
-
-### Phase 1 — Macro (Identification + Challenge)
-
-| Step | File | Model | Role |
-|------|------|-------|------|
-| 00 | `step-00-init.md` | Sonnet | Detection new/update, scan existing, create index.json structure |
-| 01 | `step-01-cadrage.md` | Opus | Context, stakeholders, scope, risks. ~40 core questions |
-| 02 | `step-02-structure.md` | Opus | Identify App > Module > Section > Resource hierarchy, CHALLENGE each element |
-
-### Phase 2 — Specification (Deep dive + Consolidation)
-
-| Step | File | Model | Role |
-|------|------|-------|------|
-| 03 | `step-03-specify.md` | Opus | Deep dive per module: entities, BRs, UCs, permissions. Sequential internal loop |
-| 04 | `step-04-consolidate.md` | Opus | Cross-module validation: data model, permission coherence, E2E flows |
-
-### Development Paths — When to use what
-
-SmartStack offers **two paths** from idea to code, depending on scope:
-
-```
-Path A — FAST (small module, < 5 min)          Path B — FULL (multi-module, hours/days)
-═══════════════════════════════════════         ═══════════════════════════════════════
-
-  "I want employees + absences"                  "Build a complete HR platform"
-          │                                               │
-          ▼                                               ▼
-  ┌──────────────┐                               ┌──────────────────┐
-  │   /business-analyse-quick│  0-2 questions                 │ /business-analyse│  ~40 questions
-  │  (2 min)     │  Pure inference                │  (steps 00-04)   │  JSON output
-  └──────┬───────┘                               └────────┬─────────┘
-         │ Natural language prompt                        │ entities/rules/usecases.json
-         ▼                                               ▼
-  ┌──────────────┐                               ┌──────────────────┐
-  │    /apex     │  1 module                      │  /business-analyse-design   │  screens/wireframes
-  │  (30-60 min) │  APEXE methodology             │                  │  navigation tree
-  └──────────────┘                               └────────┬─────────┘
-                                                          │ screens.json, navigation.json
-                                                          ▼
-                                                 ┌──────────────────┐
-                                                 │/business-analyse-html│  Interactive HTML
-                                                 │                  │  for client review
-                                                 └────────┬─────────┘
-                                                          │ ba-interactive.html
-                                                          ▼
-                                                 ┌──────────────────┐
-                                                 │/business-analyse-review│◄── ba-review.json
-                                                 │  Corrections?    │    (exported from HTML)
-                                                 └───┬─────────┬───┘
-                                              YES    │         │ NO (approved)
-                                         ┌───────────┘         └──────────┐
-                                         ▼                                ▼
-                                  Back to Phase 1             ┌────────────────────────┐
-                                  or Phase 2                  │/business-analyse-     │  PRD + handoff
-                                  (depends on scope)          │      handoff           │
-                                                              └────────┬───────────────┘
-                                                                       │ .ralph/prd-*.json
-                                                                       ▼
-                                                              ┌──────────────────┐
-                                                              │   /business-analyse-develop    │  Orchestrator
-                                                              │  (iterative)     │  delegates to ▼
-                                                              └────────┬─────────┘
-                                                                       │ /apex -d per module
-                                                                       ▼
-                                                              ┌──────────────────┐
-                                                              │    /apex -d      │  Code generation
-                                                              │  (per module)    │  5 layers
-                                                              └──────────────────┘
-```
-
-### Data flow between skills
-
-| From | To | Data | Format |
-|------|----|------|--------|
-| `/business-analyse-quick` | `/apex` | Inferred design (entities, FK, labels, code patterns) | Natural language prompt |
-| `/business-analyse` | `/business-analyse-design` | Entities, use cases, permissions | JSON (`entities.json`, `usecases.json`, `permissions.json`) |
-| `/business-analyse-design` | `/business-analyse-html` | Screen specs, wireframes, navigation | JSON (`screens.json`, `navigation.json`) |
-| `/business-analyse-html` | Client | Interactive review document | HTML (`ba-interactive.html`) |
-| Client | `/business-analyse-review` | Corrections | JSON (`ba-review.json`, exported from HTML) |
-| `/business-analyse-review` | `/business-analyse` or `/business-analyse-design` | Corrections applied, new version | JSON (updated thematic files) |
-| `/business-analyse` (approved) | `/business-analyse-handoff` | Consolidated BA data | JSON (all `index.json` + thematic files) |
-| `/business-analyse-handoff` | `/business-analyse-develop` | Handoff data + PRD | JSON (`.ralph/prd-*.json`, `handoff.json`) |
-| `/business-analyse-develop` | `/apex -d` | Module context + PRD | JSON (`.ralph/prd-{module}.json`) |
-
-### /business-analyse-review correction routing
-
-| Correction scope | Route to | Reason |
-|------------------|----------|--------|
-| Entities, rules, UCs, permissions | `/business-analyse` step-03 | Re-specify affected modules |
-| Screens, wireframes, navigation | `/business-analyse-design` | Re-design UI |
-| Both analysis + UI | `/business-analyse` step-03, then `/business-analyse-design` | Full re-spec |
-| Cadrage/scope only | `/business-analyse-html` | Just regenerate HTML |
-| No corrections (approved) | `/business-analyse-handoff` | Proceed to code generation |
-
-> **Rule:** Path A (`/business-analyse-quick` → `/apex`) is for quick, single-module additions. Path B (full cycle) is for multi-module projects or when the client needs a formal review process.
-> **PRD generation:** Handoff data and PRD files are generated by the `/business-analyse-handoff` skill.
-
-## JSON Architecture — Granular files + Index
-
-Each module is split into thematic JSON files with an `index.json` that references them:
-
-```
-docs/{app}/{module}/business-analyse/v1.0/
-  index.json              ← Index with metadata + file references
-  cadrage.json            ← Context, stakeholders, scope, risks (if app-level)
-  entities.json           ← Entities, attributes, relations
-  rules.json              ← Business rules (BRs)
-  usecases.json           ← Use cases (UCs)
-  permissions.json        ← Permissions, roles, access matrix
-  screens.json            ← Interface specs (produced by /business-analyse-design)
-  validation.json         ← Validation results, checks
-  handoff.json            ← File mapping, APIs, handoff data
-```
-
-### File hierarchy
-
-```
-docs/
-  business-analyse/v1.0/
-    index.json                    ← Project index (multi-app)
-    cadrage.json                  ← Project-level framing
-  {app}/
-    business-analyse/v1.0/
-      index.json                  ← Application index
-      cadrage.json                ← Application framing
-    {module}/
-      business-analyse/v1.0/
-        index.json                ← Module index
-        entities.json, rules.json, usecases.json, ...
-  ba-interactive.html             ← Single unified HTML
-```
-
-### Partial loading
-
-Each step loads only the files it needs via `index.json`:
-- Step 03 (specify): loads `index.json` + `entities.json` for current module only
-- Step 04 (consolidate): loads all `index.json` files for summary counts
-
-## Workflow Modes
-
-| Mode | Condition | Behavior |
-|------|-----------|----------|
-| `new` | No existing index.json | Full analysis from step 00 |
-| `update` | Existing index.json found | Delta analysis, skip completed sections |
-
-## Context Loading Rules
-
-Each step loads ONLY what it needs:
-
-| Step | Always loaded | Conditionally loaded |
-|------|---------------|---------------------|
-| 00 | `_shared.md` | — |
-| 01 | `_shared.md`, `step-01-cadrage.md` | questionnaires |
-| 02 | `_shared.md`, `step-02-structure.md` | cadrage.json from step 01 |
-| 03 | `_shared.md`, `step-03-specify.md` | current module's index.json + relevant files |
-| 04 | `_shared.md`, `step-04-consolidate.md` | all module index.json files |
-
-## Agents
-
-| Agent | Role | Operations |
-|-------|------|------------|
-| `ba-writer` | Write granular JSON files | create, enrichSection, updateIndex, createVersion, applyReview |
-| `ba-reader` | Read via index.json | findFeature, readSection, getModuleStatus, getSummaryForSkill |
-
-## HTML Output
-
-HTML generation is handled by the `/business-analyse-html` skill. After step-04, invoke `/business-analyse-html` to produce the interactive HTML document. For client review corrections, use `/business-analyse-review`.
-
-## Step Execution
-
-```
-STEP 00 (init)
-  → Load: _shared.md
-  → Execute: step-00-init.md
-  → Output: index.json structure, workflow mode detected
-
-STEP 01 (cadrage)
-  → Load: _shared.md, step-01-cadrage.md, questionnaires
-  → Execute: Interactive Q&A with client (~40 questions)
-  → Output: cadrage.json (context, stakeholders, scope, risks, criteria)
-
-STEP 02 (structure)
-  → Load: _shared.md, step-02-structure.md, cadrage.json
-  → Execute: Identify App > Module > Section > Resource hierarchy
-  → Challenge: Question each element's necessity
-  → Output: modules[], applications[], anticipatedSections per module
-
-STEP 03 (specify) — SEQUENTIAL MODULE LOOP
-  → For each module (in dependency order):
-    → Load: _shared.md, step-03-specify.md, module index.json
-    → Execute: entities, BRs, UCs, permissions
-    → Output: entities.json, rules.json, usecases.json, permissions.json
-  → No team mode — sequential ensures 100% context per module
-
-STEP 04 (consolidate) — FINAL BA STEP
-  → Load: _shared.md, step-04-consolidate.md, all index.json
-  → Execute: Data model validation, permission coherence, E2E flows
-  → Output: validation.json, consolidated data
-  → Next: invoke /business-analyse-design (Phase 2), then /business-analyse-html, then /business-analyse-review for client cycle
-```
-
-## References
-
-| File | Content |
-|------|---------|
-| `/business-analyse-html` skill | HTML generation (FEATURE_DATA mapping, build, render, verify) |
-| `/business-analyse-review` skill | Apply client corrections from ba-review.json |
-| `references/naming-conventions.md` | SmartStack naming rules |
-| `references/validation-checklist.md` | Validation criteria checklist |
-| `references/acceptance-criteria.md` | Acceptance criteria patterns |
-
-> **Cross-reference:** Handoff data, PRD generation, file templates, and BR-to-code mappings are in the `/business-analyse-handoff` skill.
-
-## Questionnaires
-
-| File | Questions | Focus |
-|------|-----------|-------|
-| `questionnaire/01-context.md` | 3 | Business process, friction points, vision |
-| `questionnaire/02-stakeholders-scope.md` | 10 | User profiles, access levels, scope boundaries |
-| `questionnaire/03-data-ui.md` | ~15 | Data entities, UI expectations, dashboards |
-| `questionnaire/04-risks-metrics.md` | — | NOT USED (risks/metrics out of BA scope) |
-| `questionnaire/05-cross-module.md` | ~8 | Cross-module dependencies, integration impact |
-
-## Entry Point
-
-**FIRST ACTION:** Load `steps/step-00-init.md`
-
-<success_criteria>
-- Web research performed: >= 2 WebSearch per application + 1 per complex module (Level 1 + Level 2)
-- cadrage.json with domain research findings, business process mapping, competitive analysis
-- Module completeness challenged per application against industry archetypes (module-completeness-challenge.md)
-- ALL CORE modules present or explicitly excluded with documented justification in globalScope.outOfScope
-- Section completeness: workflow modules have >= 5 sections including contextual views (open-requests, rejected, history, etc.)
-- Business rules: >= 2 domain-specific rules per module (not just generic CRUD validation)
-- entities.json, rules.json, usecases.json, permissions.json par module
-- Validation cross-module completee (modele de donnees, coherence permissions, flux E2E)
-- validation.json with qualityAssessment (self-scoring) and processCoverage
-- Quality self-assessment score >= 7/10 (research + modules + sections + rules)
-- Statut feature mis a jour a "consolidated" dans index.json
-</success_criteria>