@atlashub/smartstack-cli 4.41.0 → 4.43.0

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

@@ -26,25 +26,86 @@ user_invocable: true
 | 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 |
 
-### Post-BA Workflow
+### Development Paths — When to use what
+
+SmartStack offers **two paths** from idea to code, depending on scope:
+
 ```
-Phase 1: /business-analyse (steps 00-04)
-    |
-    v
-Phase 2: /ba-design-ui (screens, wireframes, navigation)
-    |
-    v
-Phase 3: /ba-generate-html (interactive HTML with mockups, ERD, permissions)
-    |
-    v
-Phase 4: /ba-review (client corrections → back to Phase 1 or 2)
-    |
-    v (client approves)
-Phase 5: /derive-prd → Phase 6: /ralph-loop
+Path A — FAST (small module, < 5 min)          Path B — FULL (multi-module, hours/days)
+═══════════════════════════════════════         ═══════════════════════════════════════
+
+  "I want employees + absences"                  "Build a complete HR platform"
+          │                                               │
+          ▼                                               ▼
+  ┌──────────────┐                               ┌──────────────────┐
+  │   /sketch    │  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
+                                                              └──────────────────┘
 ```
 
-> After step-04, invoke `/ba-design-ui` to design interfaces, then `/ba-generate-html` to generate the HTML, then `/ba-review` for the client correction cycle.
-> **PRD generation:** Handoff data and PRD files are generated by the `/derive-prd` skill.
+### Data flow between skills
+
+| From | To | Data | Format |
+|------|----|------|--------|
+| `/sketch` | `/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 (`/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.
+> **PRD generation:** Handoff data and PRD files are generated by the `/business-analyse-handoff` skill.
 
 ## JSON Architecture — Granular files + Index
 
@@ -58,7 +119,7 @@ docs/{app}/{module}/business-analyse/v1.0/
   rules.json              ← Business rules (BRs)
   usecases.json           ← Use cases (UCs)
   permissions.json        ← Permissions, roles, access matrix
-  screens.json            ← Interface specs (produced by /ba-design-ui)
+  screens.json            ← Interface specs (produced by /business-analyse-design)
   validation.json         ← Validation results, checks
   handoff.json            ← File mapping, APIs, handoff data
 ```
@@ -115,7 +176,7 @@ Each step loads ONLY what it needs:
 
 ## HTML Output
 
-HTML generation is handled by the `/ba-generate-html` skill. After step-04, invoke `/ba-generate-html` to produce the interactive HTML document. For client review corrections, use `/ba-review`.
+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
 
@@ -147,20 +208,20 @@ 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 /ba-design-ui (Phase 2), then /ba-generate-html, then /ba-review for client cycle
+  → Next: invoke /business-analyse-design (Phase 2), then /business-analyse-html, then /business-analyse-review for client cycle
 ```
 
 ## References
 
 | File | Content |
 |------|---------|
-| `/ba-generate-html` skill | HTML generation (FEATURE_DATA mapping, build, render, verify) |
-| `/ba-review` skill | Apply client corrections from ba-review.json |
+| `/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 `/derive-prd` skill.
+> **Cross-reference:** Handoff data, PRD generation, file templates, and BR-to-code mappings are in the `/business-analyse-handoff` skill.
 
 ## Questionnaires
 

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

@@ -76,7 +76,7 @@ Steps load only the files they need:
 2. Otherwise → mode = "new"
 ```
 
-> **Note:** Review mode (`ba-review.json`) is handled by the `/ba-review` skill.
+> **Note:** Review mode (`ba-review.json`) is handled by the `/business-analyse-review` skill.
 
 ## Navigation Hierarchy
 
@@ -124,33 +124,36 @@ Reads via index.json. Key operations:
 - `readSection(moduleCode, fileType)` — Read specific file via index
 - `getModuleStatus()` — Status table of all modules
 - `getCompletedModulesSummary()` — Compact summaries for context loading
-- `getSummaryForSkill(skill)` — Context for other skills (ralph-loop, etc.)
+- `getSummaryForSkill(skill)` — Context for other skills (business-analyse-develop, etc.)
 
 ## Status Progression
 
 ```
-draft → identified → specified → validated → reviewed
+draft → framed → decomposed → specified → consolidated → designed → reviewed → handed-off
 ```
 
 | Status | Set by | Meaning |
 |--------|--------|---------|
 | draft | Step 00 | Feature created, no content |
-| identified | Step 02 | Hierarchy identified (App > Module > Section > Resource) |
+| framed | Step 01 | Application-level framing complete (scope, stakeholders, roles) |
+| decomposed | Step 02 | Module hierarchy identified (App > Module > Section > Resource) |
 | specified | Step 03 | Module fully specified (entities, UCs, BRs, permissions, screens) |
-| validated | Step 04 | Cross-module validation passed |
-| reviewed | `/ba-review` | Client review applied |
+| consolidated | Step 04 | Cross-module validation and consolidation passed |
+| designed | Step 05 | UI/UX design and navigation complete |
+| reviewed | `/business-analyse-review` | Client review applied |
+| handed-off | `/business-analyse-handoff` | PRD files generated, ready for development |
 
 ## Handoff & PRD Generation
 
-Handoff data and PRD files are generated by the `/derive-prd` skill. The workflow is:
+Handoff data and PRD files are generated by the `/business-analyse-handoff` skill. The workflow is:
 
 ```
-/business-analyse (steps 00-04) → /ba-generate-html → /ba-review (if needed) → /derive-prd → /ralph-loop
+/business-analyse (steps 00-04) → /business-analyse-html → /business-analyse-review (if needed) → /business-analyse-handoff → /business-analyse-develop
 ```
 
 ## HTML Generation
 
-For HTML generation, use the `/ba-generate-html` skill after step-04 consolidation. For client review corrections, use `/ba-review`.
+For HTML generation, use the `/business-analyse-html` skill after step-04 consolidation. For client review corrections, use `/business-analyse-review`.
 
 ## Resume Protocol
 

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

@@ -28,11 +28,12 @@
 
 ## 2.3 Les niveaux d'accès
 
-> **But :** Définir qui peut voir quoi et faire quoi.
+> **But :** Définir les règles métier de permissions par rôle (SmartStack gère nativement RBAC + isolation tenant).
+> **Note :** Ne PAS demander le modèle de visibilité (cloisonné, tout visible, etc.) — SmartStack utilise toujours RBAC avec isolation tenant. Se concentrer sur les RÈGLES MÉTIER : quel rôle accède à quoi.
 
 | # | Question | Type de réponse |
 |---|----------|-----------------|
-| Q2.9 | Tous les utilisateurs doivent-ils voir les mêmes informations ? Si non, qui voit quoi ? | Règles de visibilité des données |
+| Q2.9 | Pour chaque profil identifié, quelles données ou sections doivent lui être restreintes ? Y a-t-il des données sensibles visibles uniquement par certains rôles ? | Restrictions par rôle |
 | Q2.10 | Qui a le droit de modifier ou supprimer des informations ? Tout le monde ou seulement certaines personnes ? | Règles de modification |
 | Q2.11 | Y a-t-il des actions sensibles qui nécessitent une validation par un supérieur ? | Liste des actions à valider |
 
@@ -40,16 +41,17 @@
 
 ## 2.4 Périmètre fonctionnel
 
-> **But :** Lister tout ce que le système doit faire et ne pas faire, avec des priorités claires.
+> **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".
 
 | # | 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 cette liste, quelles sont les fonctionnalités INDISPENSABLES ? Celles sans lesquelles le système n'a aucun intérêt ? | Liste de fonctionnalités vitales |
+| 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 priorité :**
-> Pour chaque fonctionnalité classée comme indispensable, poser la question :
+**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 ?"
 
 ---
@@ -66,6 +68,19 @@
 
 ---
 
+## 2.6 Intégrations et systèmes externes
+
+> **But :** Identifier les échanges de données avec l'extérieur et les migrations initiales.
+
+| # | Question | Type de réponse |
+|---|----------|-----------------|
+| Q2.19 | Ce système doit-il échanger des données avec d'autres outils ? (comptabilité, email, banque, API tierces) | Liste d'intégrations |
+| Q2.20 | Y a-t-il des données existantes à importer lors du démarrage ? (Excel, ancien système) | Description import |
+
+- Mapping → `cadrage.json` : champs `externalIntegrations[]` et `dataImport`
+
+---
+
 ## Guide d'élicitation approfondi
 
 ### Techniques de relance
@@ -74,7 +89,7 @@
 |----------|------------------------|---------------------|
 | Q2.1 (utilisateurs) | Un seul type mentionné | "Pensez aux différents moments de la journée : qui saisit ? Qui consulte les rapports ? Qui gère les cas particuliers ?" |
 | 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 (visibilité) | Réponse ambiguë | "Un employé du service A peut-il voir les données du service B ? Un stagiaire voit-il la même chose qu'un directeur ?" |
+| 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 ?" |
@@ -84,8 +99,8 @@
 | Signal du client | Problème sous-jacent | Action de l'analyste |
 |------------------|---------------------|----------------------|
 | "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" | Sécurité non réfléchie | "Même les stagiaires ? Les prestataires externes ? Les données salariales ?" |
-| Tout est indispensable (> 10 vitaux) | Priorités non définies | Appliquer le test de priorité |
+| "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 ?" |
 

package/templates/skills/business-analyse/questionnaire/03-data-ui.md

@@ -35,6 +35,35 @@
 | Q3.12 | Informations clés par écran ? Quelles colonnes dans la liste, quels champs dans le formulaire ? | Par écran |
 | Q3.13 | Actions possibles par écran ? (créer, éditer, supprimer, valider, exporter, changer statut) | Par écran |
 
+## 3.5 Volumétrie et performance
+
+| # | Question | Type de réponse |
+|---|----------|-----------------|
+| Q3.17 | Combien de [entité] prévoyez-vous ? (par mois et total à 2 ans) | Estimation chiffrée |
+| Q3.18 | Y a-t-il des pics d'utilisation ? (fin de mois, clôture annuelle) | Description des pics |
+
+- Relance si vague : "Moins de 100 ? Entre 100-10 000 ? Plus de 10 000 ?"
+- Mapping → `entities.json` : champ `estimatedVolume` (`monthly`, `total2y`)
+
+## 3.6 Recherche et filtres
+
+| # | Question | Type de réponse |
+|---|----------|-----------------|
+| Q3.19 | Par quels critères cherchez-vous un [entité] ? (nom, date, statut, code...) | Liste de critères |
+| Q3.20 | Quels filtres rapides sont indispensables dans la liste ? | Liste de filtres |
+
+- Relance : "Triez-vous souvent par date ? Filtrez-vous par statut ?"
+- Mapping → `entities.json` : champs `searchableFields[]` et `defaultFilters[]`
+
+## 3.7 Notifications et alertes
+
+| # | Question | Type de réponse |
+|---|----------|-----------------|
+| Q3.21 | Quels événements doivent déclencher une notification ? (création, approbation, deadline...) | Liste d'événements |
+| Q3.22 | Qui doit être notifié ? Par quel canal ? (in-app, email) | Cible + canal |
+
+- Mapping → `rules.json` : règles de catégorie `notification`
+
 ## 3.4 Tableaux de bord
 
 | # | Question | Type de réponse |
@@ -58,6 +87,7 @@
 | Q3.11 (écrans) | "Un écran de liste" | "Avec pages dédiées pour création et édition ? Détail en page avec onglets ?" |
 | Q3.13 (actions) | "CRUD classique" | "Actions métier spécifiques ? (valider, dupliquer, archiver, changer statut, assigner)" |
 | Q3.14 (dashboards) | "Juste des chiffres" | "Les tendances ne seraient-elles pas plus lisibles en graphique ?" |
+| Q3.17 (volume) | "Je ne sais pas" | "Commençons petit : combien d'employés dans l'entreprise ? Combien de factures par mois environ ?" |
 
 ### Anti-patterns à détecter
 
@@ -90,3 +120,6 @@
 | Q3.7-Q3.9 | `rules.json` (règles métier de validation et sécurité) |
 | Q3.10-Q3.13 | `screens.json` (sections, resources, colonnes, actions) |
 | Q3.14-Q3.16 | `screens.json` (sections dashboard, KPI resources) |
+| Q3.17-Q3.18 | `entities.json` (estimatedVolume) |
+| Q3.19-Q3.20 | `entities.json` (searchableFields, defaultFilters) |
+| Q3.21-Q3.22 | `rules.json` (règles category: notification) |

package/templates/skills/business-analyse/questionnaire/04-risks-metrics.md

@@ -3,4 +3,4 @@
 > **NOT USED** — Les risques projet, hypotheses, lecons du passe, metriques de succes et conditions de livraison
 > ne sont pas du scope de la BA en vibe coding.
 >
-> La documentation technique est generee automatiquement par `/documentation` apres `/ralph-loop`.
+> La documentation technique est generee automatiquement par `/documentation` apres `/business-analyse-develop`.

package/templates/skills/business-analyse/react/components.md

@@ -1,7 +1,7 @@
 # React Components - Business Analyse Viewer
 
 > **Usage:** React component that renders index.json directly
-> **Loaded in:** /ba-generate-html
+> **Loaded in:** /business-analyse-html
 > **Data source (module):** `docs/{app}/{module}/business-analyse/v{X.Y}/index.json`
 > **Data source (application):** `docs/{app}/business-analyse/v{X.Y}/index.json`
 > **Related:** `react/application-viewer.md` for application-level view
@@ -23,9 +23,7 @@ import {
   Shield,
   CheckCircle,
   AlertTriangle,
-  ChevronRight,
   ArrowRight,
-  List,
   Layout,
   Database,
   GitBranch,
@@ -202,25 +200,6 @@ export function BusinessAnalyseViewer() {
         </p>
       </header>
 
-      {/* Table of Contents */}
-      <div className="card p-4 bg-[var(--bg-secondary)]">
-        <h2 className="font-semibold mb-3 flex items-center gap-2">
-          <List className="w-4 h-4" />
-          {t('common.tableOfContents', 'Table of Contents')}
-        </h2>
-        <nav className="grid grid-cols-2 md:grid-cols-4 gap-2">
-          {sections.map((section, idx) => (
-            <a
-              key={section.key}
-              href={`#section-${idx + 1}`}
-              className="flex items-center gap-2 p-2 rounded hover:bg-[var(--bg-tertiary)] text-sm"
-            >
-              <ChevronRight className="w-4 h-4 text-[var(--color-primary-600)]" />
-              {section.label}
-            </a>
-          ))}
-        </nav>
-      </div>
 
       {/* Stats Overview */}
       <div className="grid grid-cols-2 md:grid-cols-5 gap-4">

package/templates/skills/business-analyse/react/schema.md

@@ -1,7 +1,7 @@
 # TypeScript Schema - Feature JSON Types
 
 > **Usage:** TypeScript interfaces aligned with index.json and application-schema.json
-> **Loaded in:** /ba-generate-html (for web app rendering)
+> **Loaded in:** /business-analyse-html (for web app rendering)
 > **Source (module):** `docs/{app}/{module}/business-analyse/v{X.Y}/index.json`
 > **Source (application):** `docs/{app}/business-analyse/v{X.Y}/index.json`
 

package/templates/skills/business-analyse/references/acceptance-criteria.md

@@ -1,6 +1,6 @@
 # Module Acceptance Criteria (Shared Reference)
 
-> **Loaded by:** step-03-specify (post-check), ralph-loop step-01-task (input validation)
+> **Loaded by:** step-03-specify (post-check), business-analyse-develop step-01-task (input validation)
 > **Purpose:** Define measurable, bash-verifiable acceptance criteria that a module MUST pass before being marked "specified".
 > **Key principle:** These checks read the REAL JSON files on disk — NOT in-memory data the model "thinks" it wrote.
 
@@ -137,11 +137,11 @@ console.log('PASS: All acceptance criteria met (AC-01 to AC-17)');
 After writing module JSON files, run the bash script above.
 IF FAIL → re-execute section 11 write with corrected data → re-run until PASS.
 
-### 2. ralph-loop step-01-task.md (input validation)
+### 2. business-analyse-develop step-01-task.md (input validation)
 
 At PRD load time, run the bash script on each module index.json.
 IF FAIL → BLOCKING: "Module {name} does not meet acceptance criteria — run /business-analyse to fix".
-This prevents ralph-loop from generating code from incomplete specifications.
+This prevents business-analyse-develop from generating code from incomplete specifications.
 
 ---
 

package/templates/skills/business-analyse/references/consolidation-structural-checks.md

@@ -20,7 +20,7 @@
 | `specification.wireframes[]` | YES | Must have >=1 wireframe with `layout` object |
 | `specification.lifeCycles[]` | IF entities have status | States must be objects (NOT strings) |
 | `specification.seedDataCore` | YES | Must have 9 arrays: navigationApplications, applicationRoles, navigationModules, navigationSections, navigationResources, navigationTranslations, permissions, rolePermissions, permissionConstants |
-| `specification.seedDataBusiness` | NO (WARNING) | Business seed data is generated during implementation (ralph-loop), not during BA. If present, validates format. |
+| `specification.seedDataBusiness` | NO (WARNING) | Business seed data is generated during implementation (business-analyse-develop), not during BA. If present, validates format. |
 | `specification.gherkinScenarios` | YES | Must be `[{feature, scenarios[]}]` (array of objects, NOT single object or flat array) |
 | `specification.navigation` | YES | Must have entries[] |
 | `specification.i18nKeys[]` | YES | Must have >=1 key with fr, en, it, de |

package/templates/skills/business-analyse/references/detection-strategies.md

@@ -73,7 +73,7 @@ function detectReviewMode(feature_description) {
 | Condition | Action |
 |-----------|--------|
 | `{feature_description}` starts with `-review` | Activate review mode detection |
-| ba-review.json found | Redirect user to `/ba-review` skill |
+| ba-review.json found | Redirect user to `/business-analyse-review` skill |
 | ba-review.json NOT found | Display error with fix instructions, STOP |
 | No applications exist | Display error, STOP |
 
@@ -416,7 +416,7 @@ interface DetectionResult {
 **Test Case 4: Review Mode**
 - Input: `"-review"`
 - Existing: `HumanResources` with ba-review.json present
-- Expected: Redirect user to `/ba-review` skill
+- Expected: Redirect user to `/business-analyse-review` skill
 
 **Test Case 5: Review Mode - File Missing**
 - Input: `"-review"`

package/templates/skills/business-analyse/references/entity-architecture-decision.md

@@ -135,7 +135,7 @@ L'entite {E} est-elle CORE pour cette application ?
 
 ## 4. Section Pattern for Modules
 
-> **REGLE FONDAMENTALE : Les sections representent des zones fonctionnelles, PAS des operations CRUD.**
+> **REGLE FONDAMENTALE : Les sections representent des sections fonctionnelles, PAS des operations CRUD.**
 
 ### Le pattern de navigation SmartStack
 

package/templates/skills/business-analyse/references/naming-conventions.md

@@ -71,11 +71,11 @@ Route = ToKebabCase($"/{appCode}/{moduleCode}")
 - `Projects` → `projects` (single word, no change)
 - `AI` → `ai` (acronym lowercase)
 
-**Implementation:** See `templates/skills/ralph-loop/references/core-seed-data.md` line 162
+**Implementation:** See `templates/skills/business-analyse-develop/references/core-seed-data.md` line 162
 
 ### JavaScript (BA Handoff Generation)
 
-**Location:** Used in /ba-generate-html when building seedDataCore
+**Location:** Used in /business-analyse-html when building seedDataCore
 
 **Usage:**
 ```javascript
@@ -113,7 +113,7 @@ function toKebabCase(str: string): string {
 
 ## Validation
 
-### During Generation (ralph-loop)
+### During Generation (business-analyse-develop)
 
 POST-CHECK after NavigationSeedData generation:
 
@@ -237,7 +237,7 @@ src/API/Controllers/HumanResources/TimeManagementController.cs
 
 ## References
 
-- **Template:** `templates/skills/ralph-loop/references/core-seed-data.md`
+- **Template:** `templates/skills/business-analyse-develop/references/core-seed-data.md`
 - **Validation:** `src/mcp/tools/validate-frontend-routes.ts`
-- **POST-CHECK:** `templates/skills/ralph-loop/steps/step-02-execute.md` (section 5)
-- **Handoff:** `/derive-prd` skill (handoff section)
+- **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/robustness-checks.md

@@ -5,7 +5,7 @@
 
 ## Overview
 
-This document consolidates all robustness checks implemented across the business-analyse workflow. Each check serves to catch issues early, before they cause ralph-loop failures or runtime errors.
+This document consolidates all robustness checks implemented across the business-analyse workflow. Each check serves to catch issues early, before they cause business-analyse-develop failures or runtime errors.
 
 ---
 
@@ -151,7 +151,7 @@ DO NOT PROCEED TO CONSOLIDATION UNTIL ALL CHECKS PASS
 
 ### Purpose
 
-Verifies ALL cross-module entity references are resolvable. Prevents FK constraint violations and runtime errors during ralph-loop code generation.
+Verifies ALL cross-module entity references are resolvable. Prevents FK constraint violations and runtime errors during business-analyse-develop code generation.
 
 ### Process
 
@@ -264,7 +264,7 @@ DEVELOPMENT CANNOT PROCEED WITH CIRCULAR DEPENDENCIES
 
 ---
 
-> **Note:** Ralph Readiness Validation (PRD files, handoff completeness, etc.) is handled by the `/derive-prd` skill.
+> **Note:** Ralph Readiness Validation (PRD files, handoff completeness, etc.) is handled by the `/business-analyse-handoff` skill.
 
 ---
 
@@ -416,7 +416,7 @@ WHERE: Return to step-03-specify.md for TimeTracking module
 
 **Success:**
 - Application marked as "consolidated"
-- Ready for `/ba-generate-html` and `/derive-prd`
+- Ready for `/business-analyse-html` and `/business-analyse-handoff`
 
 ---
 

package/templates/skills/business-analyse/references/spec-auto-inference.md

@@ -32,9 +32,9 @@
 
 ## Auto-Generated UI Components by featureType
 
-> **RULE:** Sections = functional zones only. `create`/`edit` are separate pages with own URL routes (`/create` and `/:id/edit`). `detail` is a tabbed page reached from `list`.
+> **RULE:** Sections are functional, not CRUD-based. `create`/`edit` are separate pages with own URL routes (`/create` and `/:id/edit`). `detail` is a tabbed page reached from `list`.
 
-| featureType | Sections (functional zones) | permissionMode | List page includes | Form pages | Detail page tabs |
+| featureType | Sections (functional) | permissionMode | List page includes | Form pages | Detail page tabs |
 |---|---|---|---|---|---|
 | data-centric | list | `crud` | grid, filters, create button | `/create` page, `/:id/edit` page | Infos, {relations} |
 | data-centric | (detail — implicit) | `inherit` | — | — | — |

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

@@ -2,7 +2,7 @@
 
 > **Authoritative minimums:** See `_shared.md` for the single source of truth on all minimum thresholds.
 > **CRITICAL:** This checklist MUST be FULLY COMPLETED before marking module status = "specified".
-> **Rationale:** Prevents incomplete modules from reaching handoff, reduces ralph-loop failures.
+> **Rationale:** Prevents incomplete modules from reaching handoff, reduces business-analyse-develop failures.
 
 ## Checklist Structure
 
@@ -232,8 +232,8 @@ const checklist = {
   seedDataBusiness: {
     check: "Business seed data template defined (if applicable — generated during implementation, not BA)",
     status: specification.seedDataBusiness !== undefined ? "PASS" : "WARN",
-    blocking: false,  // WARNING only — business seed data is generated during ralph-loop implementation, not during BA phase
-    details: "Business seed data (reference types, categories, statuses) is generated during implementation (ralph-loop). " +
+    blocking: false,  // WARNING only — business seed data is generated during business-analyse-develop implementation, not during BA phase
+    details: "Business seed data (reference types, categories, statuses) is generated during implementation (business-analyse-develop). " +
              "BA phase ensures seedDataCore is complete (navigation, permissions). seedDataBusiness is optional at this stage."
   },
 

package/templates/skills/business-analyse/schemas/feature-schema.json

@@ -43,7 +43,7 @@
     }
   },
 
-  "$comment": "Sub-schema loading guide per BA step: step-00-init → metadata-schema.json | step-01-cadrage → discovery-schema.json (module) OR application-schema.json (master) | step-02-structure → application-schema.json (modules[], dependencyGraph) | step-03-specify → analysis-schema.json + specification-schema.json | step-04-consolidate → validation-schema.json + application-schema.json (consolidation). HTML generation → /ba-generate-html skill. Review corrections → /ba-review skill. Handoff → /derive-prd skill",
+  "$comment": "Sub-schema loading guide per BA step: step-00-init → metadata-schema.json | step-01-cadrage → discovery-schema.json (module) OR application-schema.json (master) | step-02-structure → application-schema.json (modules[], dependencyGraph) | step-03-specify → analysis-schema.json + specification-schema.json | step-04-consolidate → validation-schema.json + application-schema.json (consolidation). HTML generation → /business-analyse-html skill. Review corrections → /business-analyse-review skill. Handoff → /business-analyse-handoff skill",
 
   "$defs": {
     "stepStatus": { "$ref": "shared/common-defs.json#/$defs/stepStatus" },

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

@@ -2,7 +2,7 @@
   "$schema": "https://json-schema.org/draft/2020-12/schema",
   "$id": "handoff-schema.json",
   "title": "SmartStack BA - Handoff",
-  "description": "Module-level handoff: file mapping (8 categories), BR-to-code mapping, API endpoint summary. Used by /derive-prd skill.",
+  "description": "Module-level handoff: file mapping (8 categories), BR-to-code mapping, API endpoint summary. Used by /business-analyse-handoff skill.",
   "type": "object",
   "properties": {
     "complexity": { "type": "string", "enum": ["simple", "medium", "complex"] },
@@ -61,7 +61,7 @@
     },
     "ralphPrd": {
       "type": "object",
-      "description": "Embedded Ralph Loop task breakdown (also exported to .ralph/prd.json by ss derive-prd)",
+      "description": "Embedded Ralph Loop task breakdown (also exported to .ralph/prd.json by ss business-analyse-handoff)",
       "properties": {
         "tasks": {
           "type": "array",

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

@@ -26,6 +26,7 @@
           "id": { "type": "string", "pattern": "^UC-[A-Z]{2,4}-\\d{3}$", "description": "Module-prefixed UC ID (e.g., UC-RM-001)" },
           "name": { "type": "string" },
           "primaryActor": { "type": "string" },
+          "sectionCode": { "type": "string", "description": "Code of the anticipatedSection this UC belongs to (e.g., list, detail, dashboard). Must match a code in anticipatedSections[]." },
           "permission": { "type": "string", "description": "Module-level: {app}.{module}.{action} or section-level: {app}.{module}.{section}.{action}" },
           "preconditions": { "type": "array", "items": { "type": "string" } },
           "postconditions": { "type": "array", "items": { "type": "string" } },
@@ -214,7 +215,7 @@
           },
           "layout": {
             "type": "object",
-            "description": "Structural layout for deterministic consumption by ralph-loop. Source of truth for code generation.",
+            "description": "Structural layout for deterministic consumption by business-analyse-develop. Source of truth for code generation.",
             "properties": {
               "type": { "type": "string", "enum": ["page", "dialog", "panel"] },
               "regions": {
@@ -509,7 +510,7 @@
     },
     "sections": {
       "type": "array",
-      "description": "Level 4 (Section) decomposition. Each section = 1 React page. MANDATORY for ralph-loop consumption.",
+      "description": "Level 4 (Section) decomposition. Each section = 1 React page. MANDATORY for business-analyse-develop consumption.",
       "items": {
         "type": "object",
         "required": ["code", "labels", "route", "permission", "wireframe", "useCases", "resources"],