@atlashub/smartstack-cli 4.74.0 → 4.76.0

package/templates/skills/apex-verify/steps/step-04-route-audit.md

@@ -0,0 +1,98 @@
+---
+name: step-04-route-audit
+description: Verify route alignment between navigation seed data, componentRegistry, and controllers
+next_step: steps/step-05-report.md
+---
+
+# Step 4: Route Audit
+
+## YOUR TASK:
+Verify that routes are consistent across 3 sources: navigation seed data, componentRegistry (PageRegistry), and backend controllers (NavRoute attributes).
+
+---
+
+## EXECUTION SEQUENCE:
+
+### 1. Extract Seed Data Routes
+
+From {seed_files}, extract all section routes:
+```
+{seed_routes} = [
+  { code: "departments", route: "/human-resources/employees/departments", file: "...", line: N },
+  { code: "list", route: "/human-resources/employees", file: "...", line: N },
+  ...
+]
+```
+
+### 2. Extract PageRegistry Keys
+
+From {registry_file}, extract all `PageRegistry.register()` calls:
+```typescript
+PageRegistry.register('human-resources.employees.departments', ...)
+PageRegistry.register('human-resources.employees', ...)
+```
+
+Build: `{registry_keys}` = all registered page keys.
+
+### 3. Extract Controller NavRoutes
+
+From {controller_files}, extract `[NavRoute("...")]` attributes:
+```csharp
+[NavRoute("human-resources.employees")]
+[NavRoute("human-resources.employees.departments")]
+```
+
+Build: `{controller_navroutes}` = all NavRoute values.
+
+### 4. Cross-Reference
+
+**Check A: Seed Routes → PageRegistry**
+For each seed route (excluding reserved sections and /:id routes):
+- Convert route to PageRegistry key: `/human-resources/employees/departments` → `human-resources.employees.departments`
+- Verify key exists in {registry_keys}
+- If missing → BLOCKING (seed route has no frontend page)
+
+**Check B: Controller NavRoutes → Seed Data**
+For each NavRoute:
+- Convert to route path: `human-resources.employees` → `/human-resources/employees`
+- Verify exists in seed data routes
+- If missing → WARNING (controller exists but no navigation entry)
+
+**Check C: PageRegistry → Page Files**
+For each registry entry:
+- Verify the imported component file exists on disk
+- If missing → BLOCKING (registry references non-existent page)
+
+**Check D: Orphan Pages**
+For each page file in {page_files}:
+- Check if it's registered in componentRegistry
+- If NOT registered → WARNING (page exists but has no route — unreachable)
+
+**Check E: DynamicRouter Convention Routes**
+For each section with a list page:
+- Verify these implicit routes are handled (either by registry or DynamicRouter convention):
+  - `{section}/:id` → detail page
+  - `{section}/create` → create page
+  - `{section}/:id/edit` → edit page
+- Note: DynamicRouter may resolve these by convention without explicit registry entries. Only flag if BOTH registry AND convention are missing.
+
+### 5. Record Findings
+
+| ID | Severity | Rule |
+|----|----------|------|
+| ROUTE-001 | BLOCKING | Seed data route has no matching PageRegistry entry |
+| ROUTE-002 | WARNING | Controller NavRoute has no matching seed data entry |
+| ROUTE-003 | BLOCKING | PageRegistry references non-existent page file |
+| ROUTE-004 | WARNING | Orphan page — exists on disk but not registered (unreachable) |
+| ROUTE-005 | WARNING | Implicit route (detail/create/edit) not resolvable |
+
+---
+
+## SUCCESS METRICS:
+- All 3 sources extracted completely
+- Cross-reference completed for all combinations
+- Orphan detection completed
+- DynamicRouter conventions accounted for
+
+## NEXT STEP:
+Proceed to `./step-05-report.md`

package/templates/skills/apex-verify/steps/step-05-report.md

@@ -0,0 +1,110 @@
+---
+name: step-05-report
+description: Generate consolidated audit report with all findings
+---
+
+# Step 5: Consolidated Report
+
+## YOUR TASK:
+Compile all findings from previous steps into a structured, actionable report.
+
+---
+
+## REPORT FORMAT:
+
+Display the following report to the user:
+
+```
+============================================================
+       APEX VERIFICATION REPORT
+============================================================
+
+Project: {project_name}
+Scope:   {scope}
+Date:    {current_date}
+
+------------------------------------------------------------
+  SUMMARY
+------------------------------------------------------------
+
+| Category     | BLOCKING | CRITICAL | WARNING | PASS |
+|-------------|----------|----------|---------|------|
+| Navigation  | {count}  | {count}  | {count} | {Y/N}|
+| CRUD        | {count}  | {count}  | {count} | {Y/N}|
+| Permissions | {count}  | {count}  | {count} | {Y/N}|
+| Routes      | {count}  | {count}  | {count} | {Y/N}|
+| **TOTAL**   | {total}  | {total}  | {total} |      |
+
+Result: {PASS / FAIL (N blocking issues)}
+
+------------------------------------------------------------
+  BLOCKING FINDINGS (must fix)
+------------------------------------------------------------
+
+[{ID}] {message}
+  File: {file_path}:{line}
+  Fix:  {fix_description}
+
+... (repeat for each blocking finding)
+
+------------------------------------------------------------
+  CRITICAL FINDINGS (should fix)
+------------------------------------------------------------
+
+[{ID}] {message}
+  File: {file_path}:{line}
+  Fix:  {fix_description}
+
+... (repeat for each critical finding)
+
+------------------------------------------------------------
+  WARNINGS (nice to fix)
+------------------------------------------------------------
+
+[{ID}] {message}
+  File: {file_path}:{line}
+  Fix:  {fix_description}
+
+... (repeat for each warning)
+
+============================================================
+```
+
+## ADDITIONAL SECTIONS (if --fix):
+
+When {fix_mode} is true, add a "FIX COMMANDS" section after the findings:
+
+```
+------------------------------------------------------------
+  FIX COMMANDS
+------------------------------------------------------------
+
+# NAV-001: Remove reserved section 'detail' from menu
+# File: src/.../EmployeesNavigationSeedData.cs
+# Action: Remove the section entry with code "detail" from Sections[] array
+
+# CRUD-004: Add Create button to EmployeeListPage
+# File: web/.../EmployeeListPage.tsx
+# Action: Add in the page header:
+#   <button onClick={() => navigate('create')} className="...">
+#     New Employee
+#   </button>
+
+... (repeat for each finding with specific fix instructions)
+```
+
+## RULES FOR REPORT GENERATION:
+
+1. **Sort by severity**: BLOCKING first, then CRITICAL, then WARNING
+2. **Within same severity**: Sort by category (NAV, CRUD, PERM, ROUTE)
+3. **No false positives**: Only include findings with concrete evidence (file:line)
+4. **No duplicates**: Merge findings that point to the same root cause
+5. **Actionable fixes**: Every finding must have a clear, specific fix instruction
+6. **If no findings in a category**: Display "PASS — No issues found" for that category
+
+## SUCCESS CRITERIA:
+- Report is complete and properly formatted
+- All findings from steps 1-4 are included
+- Pass/fail status is correct
+- Fix commands are included if --fix was specified
+- Report is immediately actionable by the developer

package/templates/skills/application/references/frontend-route-wiring-app-tsx.md

@@ -48,6 +48,9 @@ import './extensions/componentRegistry.generated';
 
 ## For Client SDK Pages
 
+> **CRITICAL:** Keys use DOT notation (`rh.employes.list`), NEVER hyphens (`rh-employes-list`).
+> Dots are hierarchy separators matching `NavigationService.ComponentKey` computation at runtime.
+
 Clients register their own pages directly:
 
 ```tsx

package/templates/skills/application/templates-frontend.md

@@ -114,7 +114,7 @@ export function $MODULE_PASCALDetailPage() {
     } finally {
       setLoading(false);
     }
-  }, [$entityId, t]);
+  }, [$entityId]);
 
   useEffect(() => {
     loadData();
@@ -239,7 +239,7 @@ export function $MODULE_PASCALEditPage() {
     } finally {
       setLoading(false);
     }
-  }, [$entityId, t]);
+  }, [$entityId]);
 
   useEffect(() => {
     loadData();

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

@@ -38,7 +38,7 @@ Path A — FAST (small module, < 5 min)          Path B — FULL (multi-module,
           │                                               │
           ▼                                               ▼
   ┌──────────────┐                               ┌──────────────────┐
-  │   /sketch    │  0-2 questions                 │ /business-analyse│  ~40 questions
+  │   /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
@@ -84,7 +84,7 @@ Path A — FAST (small module, < 5 min)          Path B — FULL (multi-module,
 
 | From | To | Data | Format |
 |------|----|------|--------|
-| `/sketch` | `/apex` | Inferred design (entities, FK, labels, code patterns) | Natural language prompt |
+| `/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`) |
@@ -104,7 +104,7 @@ Path A — FAST (small module, < 5 min)          Path B — FULL (multi-module,
 | Cadrage/scope only | `/business-analyse-html` | Just regenerate HTML |
 | No corrections (approved) | `/business-analyse-handoff` | Proceed to code generation |
 
-> **Rule:** Path A (`/sketch` → `/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.
+> **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
@@ -236,3 +236,17 @@ STEP 04 (consolidate) — FINAL BA STEP
 ## 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>

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

@@ -1,5 +1,69 @@
 # Business Analysis — Shared Conventions
 
+## Fundamental Analysis Rules
+
+1. **NEVER skip web research.** Domain research is MANDATORY and BLOCKING.
+   An analysis without research is a 2/10 regardless of structural quality.
+
+2. **NEVER accept a thin application.** Every application MUST be challenged
+   against industry standard module counts (see `references/module-completeness-challenge.md`).
+   A 1-module billing application is ALWAYS wrong — challenge it.
+
+3. **ALWAYS propose domain-specific business rules.** Generic CRUD rules
+   (date validation, required fields) are the MINIMUM baseline. Domain rules
+   (half-day absences, team capacity, carry-over limits, credit note linking,
+   sequential invoice numbering) are what make an analysis valuable.
+   **Target: >= 2 domain-specific rules per business module (`domainSpecific: true`).**
+   Post-check C19 enforces this as a WARNING.
+
+4. **ALWAYS propose contextual views.** A workflow module without filtered
+   views (open-requests, rejected, history, my-{entity}) is incomplete.
+
+5. **ALWAYS process application by application.** Research each app's domain
+   before decomposing into modules. Challenge module completeness per app.
+
+6. **ACT AS AN EXPERT ANALYST, NOT A NOTE-TAKER.** Challenge, propose,
+   question. If the user says "billing with invoices", your job is to say
+   "standard billing also includes credit notes, payment tracking, and
+   dunning. Would you like to add these?" The user came to you for expertise.
+
+7. **NEVER compress or batch module processing in step-03.** Each module MUST be
+   processed sequentially in the main context. Sub-agents do NOT have access to the
+   JSON schema and WILL produce inconsistent formats. If there are 15+ modules, the
+   correct approach is to maintain sequential processing, NOT to "accelerate" by
+   batching. The ba-012 audit proved that batching reduced schema conformity from
+   95% to 35% — the rework cost exceeded any time saved.
+
+8. **ALL generated JSON content values MUST be in `{language}`** (from metadata or config).
+   This applies to ALL text values written to JSON files:
+   - Entity `description`, attribute `description`, relationship `description`
+   - Business rule `name`, `statement`, `examples[].input`, `examples[].expected`
+   - Use case `name`, `mainScenario[]` steps, `alternativeScenarios[].steps[]`, `errorScenarios[].steps[]`, `preconditions[]`, `postconditions[]`
+   - Permission `description`, role `description`
+   - Lifecycle state `displayName`
+   - Section and resource labels
+
+   **Mixed-language content across modules is a BLOCKING quality defect.**
+   If `language == "fr"` : write "Créer une absence", NOT "Create an absence".
+   If `language == "en"` : write "Create an absence", NOT "Créer une absence".
+   Technical identifiers (entity names, field names, enum values, IDs) remain in English/PascalCase.
+
+9. **BR `examples[]` are TEST DATA, not documentation.** Each example must be a
+   concrete test case with the `{scenario, given, when, then}` format:
+   - `given`: object with `Entity.field: concreteValue` pairs (initial state)
+   - `when`: string action (`"create"`, `"submit"`, `"calculate_remaining"`)
+   - `then`: object with expected outcome (`{result: "success"|"error", Entity.field: value}`)
+
+   These examples directly feed:
+   - Gherkin `Examples:` tables (step-03, F-ter)
+   - `brToCodeMapping` in handoff
+   - Automated unit/integration tests in `/business-analyse-develop`
+
+   A rule without test-ready examples = a test gap in development.
+   Prose examples like `"code déjà existant"` are INSUFFICIENT — use concrete values.
+
+---
+
 ## JSON-First Architecture
 
 Feature data is stored as granular JSON files, NOT markdown. Each module has an `index.json` referencing thematic files.

package/templates/skills/business-analyse/patterns/suggestion-catalog.md

@@ -9,25 +9,35 @@
 
 ## 1. Module Patterns
 
-Suggests companion modules based on primary module type:
-
-| Module Type | Keywords | Suggested Modules | Rationale |
-|-------------|----------|-------------------|-----------|
-| **Orders/Commandes** | order, commande, purchase, sales order | Invoices, Shipping, Returns, OrderLines, Customers | Orders are complete business objects; need billing, logistics, and related tables |
-| **Clients/Customers** | client, customer, contact, account, party | Contacts, Addresses, Contracts, Documents, CRM | Customers have multiple contact types, billing addresses, legal relationships |
-| **Products/Articles** | product, article, item, catalog, sku | Categories, Inventory, Pricing, Suppliers, Images | Products need organization, stock tracking, and multiple pricing strategies |
-| **Employees/HR** | employee, staff, personnel, team, workforce | Leaves, TimeTracking, Evaluations, Documents, Departments | Employees have time off needs, performance management, and asset allocation |
-| **Tickets/Support** | ticket, support, incident, issue, case | SLA, Escalation, KnowledgeBase, Categories, Notifications | Support systems need SLA tracking, knowledge base, and routing logic |
-| **Projects** | project, task, milestone, workplan, roadmap | Tasks, Milestones, Resources, Budgets, Timeline | Projects decompose into work items, need resource allocation, and progress tracking |
-| **Invoices/Billing** | invoice, billing, payment, receipt, statement | Payments, CreditNotes, Dunning, Taxes, Subscriptions | Invoicing is incomplete without payment tracking, refunds, and tax handling |
-| **Inventory/Stock** | inventory, stock, warehouse, goods, warehouse | StockMovements, Locations, Transfers, Alerts, AuditLog | Stock control needs movement tracking, multi-location support, and alerts |
-| **Documents** | document, file, attachment, media, archive | Categories, Versions, Sharing, Templates, Workflow | Document management requires metadata, versioning, and access control |
-| **Contracts** | contract, agreement, legal, terms, service level | Parties, Obligations, Milestones, Renewal, Templates | Contracts involve multiple parties, obligations tracking, and lifecycle management |
-| **Permissions/Security** | permission, role, access, authority, rbac | UserRoles, Groups, Policies, Audit, Delegation | Permission systems need fine-grained control, group policies, and audit trails |
-| **Notifications** | notification, alert, email, message, broadcast | Templates, Channels, Scheduling, Preferences | Notification systems need template management, multi-channel support, scheduling |
-| **Reporting** | report, dashboard, analytics, BI, metrics | Dashboards, Exports, Scheduling, AlertRules | Reporting needs visualization, scheduled distribution, and data export |
-| **API Management / Integrations** | api, external, integration, webhook, export, data-export, machine-to-machine | ExternalApps, DataExportEndpoints, ExportAccess, AuditLogs, ApiKeys | API platforms need app registration, key management, granular endpoint access, rate limiting, and audit logging |
-| **Client Portal** | portal, external, client, fournisseur, partenaire, tiers | MyRequests, ClientDashboard, PortalNotifications | Les utilisateurs externes ont besoin de vues self-service, suivi de statut et soumission limitée |
+Suggests companion modules based on primary module type. Modules are classified as:
+- **CORE**: Always needed — absence = broken application. In step-02, CORE companions MUST be challenged as BLOCKING.
+- **STANDARD**: Usually needed — absence = incomplete application. Recommended as WARNING.
+- **OPTIONAL**: Nice to have — suggest only if context supports it.
+
+> **CRITICAL — step-02 usage:**
+> CORE companions are NOT optional suggestions. They are MANDATORY challenges.
+> In step-02, for each identified module type, check CORE companions.
+> If a CORE companion is absent → BLOCKING AskUserQuestion:
+> "Module {companion} is a CORE component of {module_type} applications.
+>  (a) Add as module (b) Add as section (c) Exclude with justification"
+
+| Module Type | Keywords | CORE Companions | STANDARD Companions | OPTIONAL Companions | Rationale |
+|-------------|----------|-----------------|---------------------|---------------------|-----------|
+| **Orders/Commandes** | order, commande, purchase, sales order | **Customers, Invoices** | Shipping, Returns | OrderLines | Orders need customer relationships and billing |
+| **Clients/Customers** | client, customer, contact, account, party | **Contacts, Addresses** | Contracts, Documents | CRM | Customers have contacts and addresses at minimum |
+| **Products/Articles** | product, article, item, catalog, sku | **Categories, Pricing** | Inventory, Suppliers | Images | Products need categorization and pricing |
+| **Employees/HR** | employee, staff, personnel, team, workforce | **Leaves, Documents** | Evaluations | TimeTracking, Departments | Employees always need leave mgmt + document storage |
+| **Tickets/Support** | ticket, support, incident, issue, case | **KnowledgeBase, Categories** | SLA, Escalation | Notifications | Support needs KB and categorization at minimum |
+| **Projects** | project, task, milestone, workplan, roadmap | **Tasks, TimeTracking** | Milestones, Resources | Budgets, Timeline | Projects decompose into tasks + need time tracking |
+| **Invoices/Billing** | invoice, billing, payment, receipt, statement | **CreditNotes, Payments** | Dunning, Reporting | Taxes, Subscriptions | Credit notes are legally required; payments are the purpose |
+| **Inventory/Stock** | inventory, stock, warehouse, goods | **StockMovements, Locations** | Transfers, Alerts | AuditLog | Stock needs movement tracking + locations |
+| **Documents** | document, file, attachment, media, archive | **Categories, Versions** | Sharing, Templates | Workflow | Document management needs categorization + versioning |
+| **Contracts** | contract, agreement, legal, terms, service level | **Parties, Milestones** | Obligations, Renewal | Templates | Contracts involve parties + lifecycle milestones |
+| **Permissions/Security** | permission, role, access, authority, rbac | **UserRoles, Policies** | Groups, Audit | Delegation | Permissions need role definitions + policies |
+| **Notifications** | notification, alert, email, message, broadcast | **Templates, Channels** | Scheduling, Preferences | — | Notifications need templates + multi-channel |
+| **Reporting** | report, dashboard, analytics, BI, metrics | **Dashboards, Exports** | Scheduling | AlertRules | Reporting needs visualization + export |
+| **API Management / Integrations** | api, external, integration, webhook, export, data-export, machine-to-machine | **ExternalApps, ApiKeys** | DataExportEndpoints, AuditLogs | ExportAccess | API platforms need app registration + key management |
+| **Client Portal** | portal, external, client, fournisseur, partenaire, tiers | **MyRequests, ClientDashboard** | PortalNotifications | — | External users need self-service views + status tracking |
 
 ---
 
@@ -241,7 +251,7 @@ When user selects suggestions:
       "name": "Email Notifications",
       "source": "Integration Pattern: Email mentioned",
       "accepted": false,
-      "rejectionReason": "Out of scope for MVP"
+      "rejectionReason": "Out of scope for initial delivery"
     }
   ]
 }
@@ -351,19 +361,17 @@ integrationPatterns:
 
 Skip suggestions if:
 
-- **Micro mode:** Skip all suggestions (keep MVP minimal)
+- **Perimetre minimal :** L'utilisateur souhaite garder le perimetre au strict necessaire
 - **Refactoring mode:** Skip module suggestions (only affect feature sections)
 - **User explicitly declines:** Respect user's scope boundary
-- **Budget/timeline constraints:** User indicated fixed scope
+- **Perimetre fixe :** L'utilisateur a indique un perimetre ferme
 
 ```
 Suggested modules: Customers, Shipping, Invoices, Returns
 
-But you indicated:
-  - Timeline: 2 weeks (MVP only)
-  - Budget: 1 developer
+But you indicated a minimal scope.
 
-Suggestion: Start with Orders + Customers (minimal), defer others.
+Suggestion: Start with Orders + Customers (essential), defer others.
 
 [OK] [Adjust scope] [Ignore suggestions]
 ```

package/templates/skills/business-analyse/questionnaire/01-context.md

@@ -2,11 +2,11 @@
 
 > **Usage :** Questions fondamentales pour comprendre le besoin métier
 > **Quand charger :** TOUJOURS (noyau)
-> **Objectif :** Comprendre le processus métier, les frictions, et la vision cible
+> **Objectif :** Comprendre le processus métier et la vision cible
 
 ---
 
-## 1.1 Le processus métier
+## 1.1 Le processus métier (OBLIGATOIRE)
 
 | # | Question | Type de réponse |
 |---|----------|-----------------|
@@ -14,7 +14,11 @@
 
 ---
 
-## 1.2 Les points de friction
+## 1.2 Les points de friction (CONDITIONNEL)
+
+> **Condition :** Poser UNIQUEMENT si `_preAnalysis.problem_type IN ("replace", "automate")`.
+> Pour un système neuf (problem_type = "new_tool" | "centralize"), il n'y a pas de processus existant.
+> Dans ce cas : `cadrage.asIs = "Aucun outil existant — nouveau système"` (auto-rempli).
 
 | # | Question | Type de réponse |
 |---|----------|-----------------|
@@ -22,7 +26,7 @@
 
 ---
 
-## 1.3 La vision souhaitée
+## 1.3 La vision souhaitée (OBLIGATOIRE)
 
 | # | Question | Type de réponse |
 |---|----------|-----------------|
@@ -32,8 +36,8 @@
 
 ## Mapping vers le cadrage
 
-| Réponse | Alimente |
-|---------|----------|
-| Q1.1 | `cadrage.problem` |
-| Q1.4 | `cadrage.asIs` |
-| Q1.8 | `cadrage.toBe` |
+| Réponse | Alimente | Remplissage |
+|---------|----------|-------------|
+| Q1.1 | `cadrage.problem` | Reponse directe |
+| Q1.4 | `cadrage.asIs` | Reponse directe OU auto-rempli si systeme neuf |
+| Q1.8 | `cadrage.toBe` | Reponse directe |

package/templates/skills/business-analyse/questionnaire/02-stakeholders-scope.md

@@ -39,38 +39,33 @@
 
 ---
 
-## 2.4 Périmètre fonctionnel
+## 2.4 Limites du périmètre (OBLIGATOIRE)
 
-> **But :** Lister tout ce que le système doit faire et ne pas faire, classifié par importance métier.
-> **Note :** SmartStack développe TOUS les modules identifiés. La classification vital/important/optionnel sert à doser la profondeur de spécification, PAS à phaser la livraison. Ne PAS présenter cette question comme un choix de "premier lancement" ou "quelle app d'abord".
+> **But :** Borner ce que le système ne doit PAS faire. Essentiel pour eviter le scope creep.
 
 | # | Question | Type de réponse |
 |---|----------|-----------------|
-| Q2.12 | Listez toutes les fonctionnalités que vous souhaitez dans ce système. Ne vous censurez pas. | Liste libre de fonctionnalités |
-| Q2.13 | Parmi ces fonctionnalités, classez-les : lesquelles sont VITALES (le système n'a aucun sens sans elles), lesquelles sont IMPORTANTES (forte valeur ajoutée) et lesquelles sont OPTIONNELLES (confort) ? | Classification vital / important / optionnel |
 | Q2.15 | Y a-t-il des choses que le système ne doit explicitement PAS faire ? Des limites claires à poser ? | Liste d'exclusions |
 
-**Test de classification :**
-> Pour chaque fonctionnalité classée comme vitale, poser la question :
-> "Si on enlevait cette fonctionnalité, le système aurait-il encore de la valeur ?"
+> **Note :** La detection des fonctionnalites IN-SCOPE est couverte par la reformulation (phase 2 de step-01).
+> L'IA detecte les modules depuis le brief + domain research et les presente pour validation.
+> Il n'est donc plus necessaire de demander au client de lister ses features (ex-Q2.12) ni de les classifier (ex-Q2.13).
 
 ---
 
-## 2.5 Le parcours principal
+## 2.5 Parcours principal (DEPLACE vers step-03)
 
-> **But :** Comprendre le flux de travail principal de bout en bout.
-
-| # | Question | Type de réponse |
-|---|----------|-----------------|
-| Q2.16 | Décrivez le parcours typique d'un utilisateur du début à la fin : il ouvre le système, que fait-il en premier ? | Liste d'étapes ordonnées |
-| Q2.17 | À quels moments l'utilisateur doit-il prendre une décision ? Quelles sont les options possibles ? | Points de décision et options |
-| Q2.18 | Que se passe-t-il quand quelque chose ne se déroule pas comme prévu ? Quels sont les cas particuliers ? | Scénarios alternatifs |
+> **IMPORTANT :** Les questions Q2.16 (parcours), Q2.17 (decisions), Q2.18 (erreurs) ont ete **deplacees vers step-03-specify**.
+> Elles alimentent directement les use cases par module et evitent la duplication cadrage → specification.
+> En step-01, le parcours est capture dans la reformulation : "Le parcours type que j'ai compris est X → Y → Z. Correct ?"
 
 ---
 
-## 2.6 Intégrations et systèmes externes
+## 2.6 Intégrations et systèmes externes (CONDITIONNEL)
 
 > **But :** Identifier les échanges de données avec l'extérieur et les migrations initiales.
+> **Condition :** Poser UNIQUEMENT si le brief mentionne un systeme externe, une integration, une migration ou un import de donnees.
+> Si non pertinent : `cadrage.externalIntegrations = []` et `cadrage.dataImport = null` (auto-rempli).
 
 | # | Question | Type de réponse |
 |---|----------|-----------------|
@@ -91,9 +86,7 @@
 | Q2.1 (utilisateurs) | Utilisateurs hors entreprise mentionnés (clients, fournisseurs, partenaires) | "Quelles données ces utilisateurs externes doivent-ils consulter ou créer ? Quelles restrictions par rapport aux internes ?" |
 | Q2.5 (tâches) | Tâches génériques | "Quand il arrive le matin et ouvre le système, quelle est sa première action ?" |
 | Q2.9 (restrictions) | Réponse ambiguë | "Un employé voit-il les données salariales ? Un manager voit-il uniquement son équipe ou toute l'entreprise ?" |
-| Q2.13 (indispensable) | Tout est indispensable | "Si vous ne pouviez garder que 3 fonctionnalités pour un premier lancement, lesquelles ?" |
 | Q2.15 (exclusions) | "Je ne vois pas" | "Certains utilisateurs pourraient-ils s'attendre à des fonctionnalités que vous ne souhaitez PAS inclure ?" |
-| Q2.16 (parcours) | Moins de 3 étapes | "Détaillons : l'utilisateur arrive sur l'écran d'accueil. Que voit-il ? Où clique-t-il ?" |
 
 ### Signaux d'alerte à détecter
 
@@ -101,18 +94,18 @@
 |------------------|---------------------|----------------------|
 | "Tous les utilisateurs font la même chose" | Rôles non différenciés | "Qui peut supprimer ? Qui ne fait que consulter ? Qui valide ?" |
 | "Tout le monde doit tout voir" | Restrictions non définies | "Quelles données sont sensibles ? Un manager voit-il les données de toutes les équipes ou seulement la sienne ?" |
-| Tout est vital (> 10 vitaux) | Classification non réfléchie | Appliquer le test de classification : "Si on enlevait X, le système aurait-il encore de la valeur ?" |
 | Aucune exclusion identifiée | Périmètre non borné | "Y a-t-il des aspects qui relèvent d'un autre projet ou d'une version future ?" |
-| Parcours linéaire sans alternative | Seul le cas idéal est décrit | "Que se passe-t-il à l'étape X si la condition Y n'est pas remplie ?" |
 | "Nos clients doivent pouvoir..." ou "Les fournisseurs voient..." | Utilisateurs externes accédant au système | Classifier auto en 4b-bis. Approfondir les RÈGLES MÉTIER : quelles données, quelles actions, quelles restrictions ? |
 
 ---
 
 ## Mapping vers le cadrage
 
-| Réponse | Alimente |
-|---------|----------|
-| Q2.1, Q2.5 | `cadrage.stakeholders[]` |
-| Q2.9-Q2.11 | `cadrage.applicationRoles[]` |
-| Q2.12-Q2.13, Q2.15 | `cadrage.globalScope` (vital, important, excluded) |
-| Q2.16-Q2.18 | `cadrage.coverageMatrix` + base pour les cas d'utilisation |
+| Réponse | Alimente | Remplissage |
+|---------|----------|-------------|
+| Q2.1, Q2.5 | `cadrage.stakeholders[]` | Reponse directe |
+| Q2.9-Q2.11 | `cadrage.applicationRoles[]` | Reponse directe |
+| Q2.15 | `cadrage.globalScope.excluded` | Reponse directe |
+| Q2.19, Q2.20 | `cadrage.externalIntegrations[]`, `cadrage.dataImport` | Reponse directe OU auto-rempli (vide) si non pertinent |
+| (reformulation) | `cadrage.globalScope.inScope` | Auto-deduit depuis brief + domain research, confirme en phase 2 |
+| (step-03) | `cadrage.coverageMatrix` | Construit lors de la specification des use cases |