@atlashub/smartstack-cli 4.19.0 → 4.21.0

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

@@ -1,40 +1,34 @@
 # Categorie 2 : Parties prenantes et perimetre
 
-> **Usage :** Identifier les acteurs, leurs besoins, et delimiter le perimetre fonctionnel
+> **Usage :** Identifier les profils utilisateurs, leurs droits, et delimiter le perimetre fonctionnel
 > **Quand charger :** TOUJOURS (noyau)
-> **Objectif :** Comprendre QUI utilise le systeme, COMMENT, et QUOI il doit faire
+> **Objectif :** Comprendre QUI utilise le systeme, avec quels DROITS, et QUOI il doit faire
 
 ---
 
 ## 2.1 Identification des utilisateurs
 
-> **But :** Dresser la carte complete de toutes les personnes qui interagiront avec le systeme.
+> **But :** Identifier les types de profils/roles qui interagiront avec le systeme.
 
 | # | Question | Type de reponse |
 |---|----------|-----------------|
-| Q2.1 | Qui sont les personnes qui utiliseront ce systeme au quotidien ? Decrivez leurs postes et ce qu'ils font dans l'entreprise. | Liste de profils utilisateurs |
-| Q2.2 | Y a-t-il des personnes qui ne l'utiliseront pas directement mais qui beneficieront des resultats (rapports, donnees, decisions) ? | Liste de beneficiaires indirects |
-| Q2.3 | Qui est le decideur final sur ce projet ? Qui peut dire "oui, on lance" ou "non, on arrete" ? | Nom et role du decideur |
-| Q2.4 | Y a-t-il des personnes ou des services qui pourraient s'opposer a ce projet ou le freiner ? Pourquoi ? | Liste de resistances potentielles |
+| Q2.1 | Qui sont les types de profils qui utiliseront ce systeme ? Decrivez leurs roles et ce qu'ils font. | Liste de profils utilisateurs |
 
 ---
 
-## 2.2 Le quotidien de chaque utilisateur
+## 2.2 Taches par profil
 
-> **But :** Comprendre concretement ce que chaque type d'utilisateur fait et a besoin de faire.
+> **But :** Comprendre concretement ce que chaque type d'utilisateur fait.
 
 | # | Question | Type de reponse |
 |---|----------|-----------------|
 | Q2.5 | Pour chaque type d'utilisateur : quelles sont les 3 a 5 taches principales qu'il doit accomplir avec ce systeme ? | Taches par profil utilisateur |
-| Q2.6 | A quelle frequence chaque utilisateur se servira-t-il du systeme ? Tous les jours ? Plusieurs fois par jour ? Une fois par semaine ? | Frequence d'utilisation par profil |
-| Q2.7 | Quel est le niveau de confort de chaque utilisateur avec les outils informatiques ? | Niveau d'aisance par profil |
-| Q2.8 | Pour chaque utilisateur : quelles sont ses 2 a 3 plus grandes frustrations avec la facon de travailler actuelle ? | Frustrations par profil |
 
 ---
 
 ## 2.3 Les niveaux d'acces
 
-> **But :** Definir qui peut voir quoi et faire quoi, en langage simple.
+> **But :** Definir qui peut voir quoi et faire quoi.
 
 | # | Question | Type de reponse |
 |---|----------|-----------------|
@@ -52,7 +46,6 @@
 |---|----------|-----------------|
 | Q2.12 | Listez toutes les fonctionnalites que vous souhaitez dans ce systeme. Ne vous censurez pas. | Liste libre de fonctionnalites |
 | Q2.13 | Parmi cette liste, quelles sont les fonctionnalites INDISPENSABLES ? Celles sans lesquelles le systeme n'a aucun interet ? | Liste de fonctionnalites vitales |
-| Q2.14 | Quelles fonctionnalites seraient tres utiles mais pourraient attendre une deuxieme version ? | Liste de fonctionnalites importantes |
 | Q2.15 | Y a-t-il des choses que le systeme ne doit explicitement PAS faire ? Des limites claires a poser ? | Liste d'exclusions |
 
 **Test de priorite :**
@@ -73,19 +66,6 @@
 
 ---
 
-## 2.6 Besoins transversaux
-
-> **But :** Identifier les fonctionnalites qui traversent tout le systeme.
-
-| # | Question | Type de reponse |
-|---|----------|-----------------|
-| Q2.19 | Les utilisateurs ont-ils besoin de recevoir des notifications ou des alertes ? Si oui, dans quelles situations ? | Liste de situations de notification |
-| Q2.20 | Faut-il pouvoir exporter des donnees du systeme (rapports, fichiers, impressions) ? Dans quel format et pour qui ? | Besoins d'export |
-| Q2.21 | Faut-il pouvoir importer des donnees dans le systeme depuis une source externe ? | Besoins d'import |
-| Q2.22 | Faut-il garder un historique de qui a fait quoi et quand ? Pour quelles actions ? | Besoins de tracabilite |
-
----
-
 ## Guide d'elicitation approfondi
 
 ### Techniques de relance
@@ -93,7 +73,6 @@
 | Question | Si la reponse est vague | Relance recommandee |
 |----------|------------------------|---------------------|
 | Q2.1 (utilisateurs) | Un seul type mentionne | "Pensez aux differents moments de la journee : qui saisit ? Qui consulte les rapports ? Qui gere les cas particuliers ?" |
-| Q2.4 (oppositions) | "Personne ne s'opposera" | "Quand un nouvel outil est introduit, qui doit changer ses habitudes le plus ?" |
 | Q2.5 (taches) | Taches generiques | "Quand il arrive le matin et ouvre le systeme, quelle est sa premiere action ?" |
 | Q2.9 (visibilite) | Reponse ambigue | "Un employe du service A peut-il voir les donnees du service B ? Un stagiaire voit-il la meme chose qu'un directeur ?" |
 | Q2.13 (indispensable) | Tout est indispensable | "Si vous ne pouviez garder que 3 fonctionnalites pour un premier lancement, lesquelles ?" |
@@ -116,27 +95,7 @@
 
 | Reponse | Alimente |
 |---------|----------|
-| Q2.1-Q2.4 | `cadrage.stakeholders[]` |
-| Q2.5-Q2.8 | `cadrage.stakeholders[].tasks`, `.frequency`, `.painPoints` |
+| Q2.1, Q2.5 | `cadrage.stakeholders[]` |
 | Q2.9-Q2.11 | `cadrage.applicationRoles[]` |
-| Q2.12-Q2.15 | `cadrage.globalScope` (vital, important, optional, excluded) |
+| Q2.12-Q2.13, Q2.15 | `cadrage.globalScope` (vital, important, excluded) |
 | Q2.16-Q2.18 | `cadrage.coverageMatrix` + base pour les cas d'utilisation |
-| Q2.19-Q2.22 | `cadrage.coverageMatrix` + detection de modules transversaux |
-
----
-
-## Strategie de questionnement
-
-### Ordre des questions en 4 lots
-
-**Lot 1 (Q2.1-Q2.4) : Qui est concerne ?**
-- Identifier tous les acteurs du projet
-
-**Lot 2 (Q2.5-Q2.11) : Que font-ils et quels droits ?**
-- Detailler les taches, frequences et niveaux d'acces par profil
-
-**Lot 3 (Q2.12-Q2.15) : Quel perimetre ?**
-- Lister et hierarchiser les fonctionnalites
-
-**Lot 4 (Q2.16-Q2.22) : Comment ca se deroule ?**
-- Cartographier le parcours principal et les besoins transversaux

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

@@ -13,7 +13,6 @@
 | Q3.1 | Quelles sont les entites principales gerees par ce module ? | Liste d'entites |
 | Q3.2 | Pour chaque entite : quels sont les attributs importants ? | Par entite |
 | Q3.3 | Quelles relations existent entre les entites ? (appartient a, contient, reference) | Schema relationnel |
-| Q3.4 | Volume de donnees attendu ? (dizaines, centaines, milliers, millions) | Estimation par entite |
 | Q3.5 | Pour chaque entite : le Code doit-il etre auto-genere ou saisi par l'utilisateur ? | Par entite |
 | Q3.6 | Si auto-genere : quelle strategie ? (sequentiel, timestamp, annee, UUID court) | Par entite |
 
@@ -56,7 +55,6 @@
 | Q3.1 (entites) | Mention de "User" | "L'utilisateur est gere par la plateforme. Decrivez l'entite METIER (Client, Employee, Contact...)" |
 | Q3.2 (attributs) | Champs techniques (ID, CreatedDate) | "Les champs techniques sont auto-geres. Quels sont les attributs METIER ?" |
 | Q3.3 (relations) | "1:N" sans detail | "Un {Parent} peut avoir combien de {Children} max ? Un {Child} peut-il exister sans {Parent} ?" |
-| Q3.4 (volume) | "Beaucoup" | "Ordre de grandeur : dizaines, centaines, milliers, millions ? Croissance par mois ?" |
 | Q3.11 (ecrans) | "Un ecran de liste" | "Avec pages dediees pour creation et edition ? Detail en page avec onglets ?" |
 | Q3.13 (actions) | "CRUD classique" | "Actions metier specifiques ? (valider, dupliquer, archiver, changer statut, assigner)" |
 | Q3.14 (dashboards) | "Juste des chiffres" | "Les tendances ne seraient-elles pas plus lisibles en graphique ?" |
@@ -88,7 +86,7 @@
 
 | Reponse | Alimente |
 |---------|----------|
-| Q3.1-Q3.6 | `entities.json` (entites, attributs, relations, codePattern) |
+| Q3.1-Q3.3, Q3.5-Q3.6 | `entities.json` (entites, attributs, relations, codePattern) |
 | Q3.7-Q3.9 | `rules.json` (regles metier de validation et securite) |
 | Q3.10-Q3.13 | `screens.json` (sections, resources, colonnes, actions) |
 | Q3.14-Q3.16 | `screens.json` (sections dashboard, KPI resources) |

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

@@ -1,150 +1,6 @@
 # Categorie 4 : Risques et criteres de reussite
 
-> **Usage :** Identifier les risques et definir comment mesurer le succes
-> **Quand charger :** TOUJOURS (noyau, charge dans le cadrage)
-> **Objectif :** Anticiper les problemes et etablir des criteres observables
-
----
-
-## 4.1 Les risques identifies
-
-> **But :** Lister tout ce qui pourrait empecher le projet de reussir.
-
-| # | Question | Type de reponse |
-|---|----------|-----------------|
-| Q4.1 | Quels sont les principaux risques que vous voyez pour ce projet ? Qu'est-ce qui pourrait mal tourner ? | Liste de risques |
-| Q4.2 | Parmi ces risques, lesquels auraient les consequences les plus graves ? | Hierarchisation par gravite |
-| Q4.3 | Pour chaque risque grave : avez-vous une idee de comment le prevenir ou le reduire ? | Mesures de mitigation |
-
-**Reformulation guidee pour Q4.1 :**
-```
-question: "Quels sont les principaux risques que vous voyez pour ce projet ?"
-header: "Risques"
-multiSelect: true
-options:
-  - label: "Adoption par les utilisateurs"
-    description: "Les utilisateurs pourraient ne pas vouloir changer leurs habitudes"
-  - label: "Qualite des donnees existantes"
-    description: "Les donnees actuelles sont incompletes, incorrectes ou dispersees"
-  - label: "Complexite des regles metier"
-    description: "Certaines regles sont mal documentees ou connues uniquement par quelques personnes"
-  - label: "Dependances externes"
-    description: "Le projet depend de systemes ou decisions externes qui pourraient retarder"
-```
-
----
-
-## 4.2 Les hypotheses a valider
-
-> **But :** Rendre explicites les certitudes non verifiees.
-
-| # | Question | Type de reponse |
-|---|----------|-----------------|
-| Q4.4 | Quelles hypotheses faites-vous sur le projet ? Qu'est-ce que vous tenez pour acquis sans l'avoir verifie ? | Liste d'hypotheses |
-| Q4.5 | Parmi ces hypotheses, lesquelles seraient les plus graves si elles se revelaient fausses ? | Hierarchisation par impact |
-| Q4.6 | Comment pourriez-vous verifier ces hypotheses avant que le projet avance trop loin ? | Methodes de validation |
-
----
-
-## 4.3 Les lecons du passe
-
-| # | Question | Type de reponse |
-|---|----------|-----------------|
-| Q4.7 | Y a-t-il eu des projets similaires dans l'entreprise ? Qu'est-ce qui a fonctionne ou echoue ? | Retour d'experience |
-| Q4.8 | Si ce projet devait echouer, quelle serait la raison la plus probable ? | Cause d'echec anticipee |
-
----
-
-## 4.4 La definition du succes
-
-> **But :** Determiner concretement ce qui fera dire "ce projet est un succes".
-
-| # | Question | Type de reponse |
-|---|----------|-----------------|
-| Q4.9 | Quand le systeme sera en place, comment saurez-vous que le projet est un succes ? Quel changement concret observerez-vous ? | Description du succes observable |
-| Q4.10 | Si vous deviez convaincre votre direction que le projet a reussi, quels chiffres presenteriez-vous ? | Metriques de succes |
-| Q4.11 | Au bout de combien de temps apres le lancement pourrez-vous juger si ca fonctionne ? | Delai d'evaluation |
-
-**Reformulation guidee pour Q4.9 :**
-```
-question: "Comment saurez-vous que le projet est un succes ?"
-header: "Succes"
-options:
-  - label: "Gain de temps mesurable"
-    description: "Un processus qui prenait X heures ne prend plus que Y minutes"
-  - label: "Reduction des erreurs"
-    description: "Le nombre d'erreurs a diminue de maniere significative"
-  - label: "Meilleure satisfaction"
-    description: "Les utilisateurs expriment que leur quotidien s'est ameliore"
-  - label: "Indicateurs en hausse"
-    description: "Des chiffres cles se sont ameliores"
-```
-
----
-
-## 4.5 Les objectifs mesurables
-
-| # | Question | Type de reponse |
-|---|----------|-----------------|
-| Q4.12 | Pour chaque amelioration attendue, pouvez-vous donner un objectif chiffre ? | Objectifs quantifies |
-| Q4.13 | Quels indicateurs suivez-vous deja aujourd'hui qui pourraient servir de reference ? | Indicateurs existants |
-
----
-
-## 4.6 Les criteres d'acceptation
-
-| # | Question | Type de reponse |
-|---|----------|-----------------|
-| Q4.14 | Quelles sont les conditions minimales pour que vous acceptiez de mettre le systeme en service ? | Liste de conditions obligatoires |
-| Q4.15 | Qui decide officiellement que le systeme est pret a etre utilise ? | Processus de validation |
-
----
-
-## Guide d'elicitation approfondi
-
-### Techniques de relance
-
-| Question | Si la reponse est vague | Relance recommandee |
-|----------|------------------------|---------------------|
-| Q4.1 (risques) | "Je ne vois pas de risque" | "Pensez aux projets passes : qu'est-ce qui a coince ? Les delais ? L'adoption ? La qualite des donnees ?" |
-| Q4.4 (hypotheses) | "On ne fait pas d'hypotheses" | "Est-on certain que tous les utilisateurs ont un ordinateur ? Que les donnees actuelles sont completes ?" |
-| Q4.8 (echec) | Refuse de repondre | "C'est une question difficile mais importante. Imaginons le pire scenario : cela nous aide a le prevenir." |
-| Q4.9 (succes) | "Que tout fonctionne bien" | "Imaginons que je visite votre bureau 3 mois apres le lancement. Qu'est-ce que je verrais de different ?" |
-| Q4.12 (objectifs) | "Difficile a chiffrer" | "Meme approximativement : le processus prend combien de temps aujourd'hui ? Quel serait un temps acceptable ?" |
-| Q4.14 (conditions) | "Il faut que tout soit parfait" | "Si vous deviez lancer avec seulement 80% des fonctionnalites, lesquelles seraient dans ces 80% ?" |
-
-### Signaux d'alerte
-
-| Signal du client | Probleme sous-jacent | Action |
-|------------------|---------------------|--------|
-| "Il n'y a aucun risque" | Manque de recul | Proposer des risques standards |
-| Risques uniquement techniques | Vision incomplete | Ajouter dimensions humaines et organisationnelles |
-| Aucun critere mesurable | Succes non defini | Proposer metriques standards : temps, erreurs, adoption, satisfaction |
-| "Ca doit etre parfait" | Attentes irrealistes | "Quel est le niveau minimum acceptable pour un premier lancement ?" |
-
----
-
-## Mapping vers le cadrage
-
-| Reponse | Alimente |
-|---------|----------|
-| Q4.1-Q4.3 | `cadrage.risks[]` |
-| Q4.4-Q4.6 | `cadrage.risks[]` (type: "assumption") |
-| Q4.7-Q4.8 | `cadrage.risks[]` (enrichissement contexte historique) |
-| Q4.9-Q4.13 | `cadrage.acceptanceCriteria[]` |
-| Q4.14-Q4.15 | `cadrage.acceptanceCriteria[]` (conditions de livraison) |
-
----
-
-## Strategie de questionnement
-
-### Ordre en 3 lots
-
-**Lot 1 (Q4.1-Q4.6) : Risques et hypotheses**
-- Commencer par les risques visibles puis les hypotheses implicites
-
-**Lot 2 (Q4.7-Q4.8) : Lecons du passe**
-- Tirer les lecons des experiences precedentes
-
-**Lot 3 (Q4.9-Q4.15) : Succes et acceptation**
-- Definir le succes, quantifier, etablir les conditions de livraison
+> **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`.

package/templates/skills/business-analyse/questionnaire/05-cross-module.md

@@ -2,7 +2,7 @@
 
 > **Usage :** Analyser l'impact sur les modules existants et les dependances partagees
 > **Quand charger :** TOUJOURS pour les nouveaux modules (pas les ameliorations)
-> **Objectif :** Detecter les interactions, les entites partagees et les risques de conflit
+> **Objectif :** Detecter les interactions, les entites partagees et les impacts d'integration
 
 ---
 
@@ -21,8 +21,8 @@
 |---|----------|-----------------|
 | Q5.5 | Les modules existants doivent-ils etre modifies pour supporter ce nouveau module ? | Liste de changements |
 | Q5.6 | Y a-t-il des composants UI ou des changements de navigation partages ? | Liste |
-| Q5.7 | Ce module affectera-t-il les permissions ou roles existants ? | Oui/Non + detail |
-| Q5.8 | Y a-t-il un risque de conflit de modele de donnees ? (meme entite modifiee par 2 modules) | Evaluation du risque |
+| Q5.7 | Ce module affectera-t-il les permissions ou roles existants ? Quel impact sur l'integration ? | Oui/Non + detail |
+| Q5.8 | Y a-t-il des entites partagees modifiees par plusieurs modules ? Quel impact sur l'integration ? | Evaluation de l'impact |
 
 ---
 
@@ -49,7 +49,7 @@
 | Q5.2 (donnees partagees) | "Je ne sais pas" | Utiliser le `{codebase_context}` : "J'ai trouve les entites {list}. Ce module a-t-il besoin de les referencer ?" |
 | Q5.3 (FK references) | Vague | "Une {entity} de ce module appartient-elle a un {existing_entity} ?" |
 | Q5.4 (evenements) | "Non" | "Quand un {entity} est cree/modifie/supprime, faut-il notifier un autre module ?" |
-| Q5.8 (conflits) | "Pas de risque" | "Deux modules modifient-ils la meme entite ?" |
+| Q5.8 (impact) | "Pas d'impact" | "Deux modules modifient-ils la meme entite ? Quel est l'impact sur l'integration ?" |
 
 ### Anti-patterns a detecter
 
@@ -66,4 +66,4 @@
 | Reponse | Alimente |
 |---------|----------|
 | Q5.1-Q5.4 | `consolidation.crossModuleInteractions[]`, `consolidation.sharedEntities[]` |
-| Q5.5-Q5.8 | `consolidation.globalRiskAssessment[]`, `consolidation.permissionCoherence` |
+| Q5.5-Q5.8 | `consolidation.impactAssessment[]`, `consolidation.permissionCoherence` |

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

@@ -3,7 +3,7 @@
 > **Usage:** Structured questions for step-01-cadrage and step-03-specify
 > **Standard:** BABOK v3 - Elicitation Techniques (Interactive analysis)
 > **Model:** OPUS with ULTRATHINK
-> **Total:** ~90 targeted questions across 5 questionnaire files
+> **Total:** ~20 targeted questions across 4 active questionnaire files
 
 ---
 
@@ -34,11 +34,11 @@
 
 | File | Questions | Phase | Focus |
 |------|-----------|-------|-------|
-| `questionnaire/01-context.md` | ~20 | step-01-cadrage | Problem, current state, vision, triggers, application identity |
-| `questionnaire/02-stakeholders-scope.md` | ~25 | step-01-cadrage | User profiles, priorities, scope boundaries, MoSCoW |
-| `questionnaire/03-data-ui.md` | ~20 | step-03-specify (per module) | Data entities, UI expectations, integrations |
-| `questionnaire/04-risks-metrics.md` | ~15 | step-01-cadrage | Risks, success criteria, constraints, performance |
-| `questionnaire/05-cross-module.md` | ~10 | step-03-specify (conditional) | Cross-module dependencies, shared data, E2E flows |
+| `questionnaire/01-context.md` | 3 | step-01-cadrage | Business process, friction points, vision |
+| `questionnaire/02-stakeholders-scope.md` | 10 | step-01-cadrage | User profiles, access levels, scope boundaries, MoSCoW |
+| `questionnaire/03-data-ui.md` | ~15 | step-03-specify (per module) | Data entities, UI expectations, dashboards |
+| `questionnaire/04-risks-metrics.md` | — | NOT USED | Risks/metrics out of BA scope |
+| `questionnaire/05-cross-module.md` | ~8 | step-03-specify (conditional) | Cross-module dependencies, integration impact |
 
 ---
 
@@ -48,7 +48,7 @@
 
 | Phase | Questionnaires charges |
 |-------|----------------------|
-| step-01-cadrage | 01-context, 02-stakeholders-scope, 04-risks-metrics |
+| step-01-cadrage | 01-context, 02-stakeholders-scope |
 | step-03-specify (par module) | 03-data-ui, conditionnellement 05-cross-module |
 
 ### Phase de cadrage (step-01)
@@ -58,7 +58,6 @@
 3. **Approfondir :** Poser des questions de relance sur les reponses vagues
 4. **Challenger :** Ne pas accepter "on verra plus tard" sur les fonctionnalites indispensables
 5. **Par lots :** Presenter 3 a 4 questions par interaction (AskUserQuestion)
-6. **Risques et succes :** Charger 04-risks-metrics en fin de cadrage
 
 ### Phase de specification (step-03)
 

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:** step-05-deploy.md
+> **Loaded in:** /ba-generate-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

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:** step-05-deploy.md (for web app rendering)
+> **Loaded in:** /ba-generate-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), step-05-deploy (pre-handoff gate), ralph-loop step-01-task (input validation)
+> **Loaded by:** step-03-specify (post-check), ralph-loop 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,12 +137,7 @@ 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. step-05-deploy.md (pre-handoff gate)
-
-Before writing handoff for each module, run the bash script on the module index.json.
-IF FAIL → STOP handoff for this module, report which criteria failed.
-
-### 3. ralph-loop step-01-task.md (input validation)
+### 2. ralph-loop 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".

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

@@ -63,7 +63,7 @@ function detectReviewMode(feature_description) {
     reviewJsonPath: reviewFilePath,
     applicationName: latestApp.metadata.application,
     docsDir: versionDir,
-    nextStep: 'step-06-review.md'
+    nextStep: 'redirect-to-ba-review'
   };
 }
 ```
@@ -73,7 +73,7 @@ function detectReviewMode(feature_description) {
 | Condition | Action |
 |-----------|--------|
 | `{feature_description}` starts with `-review` | Activate review mode detection |
-| ba-review.json found | Skip to step-06-review.md |
+| ba-review.json found | Redirect user to `/ba-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: Load ba-review.json, skip to step-06-review.md
+- Expected: Redirect user to `/ba-review` skill
 
 **Test Case 5: Review Mode - File Missing**
 - Input: `"-review"`

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

@@ -75,7 +75,7 @@ Route = ToKebabCase($"/{appCode}/{moduleCode}")
 
 ### JavaScript (BA Handoff Generation)
 
-**Location:** Used in step-05-deploy.md when building seedDataCore
+**Location:** Used in /ba-generate-html when building seedDataCore
 
 **Usage:**
 ```javascript
@@ -240,4 +240,4 @@ src/API/Controllers/HumanResources/TimeManagementController.cs
 - **Template:** `templates/skills/ralph-loop/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:** `templates/skills/business-analyse/steps/step-05-deploy.md` (handoff section)
+- **Handoff:** `/derive-prd` skill (handoff section)

package/templates/skills/business-analyse/references/robustness-checks.md

@@ -264,96 +264,7 @@ DEVELOPMENT CANNOT PROCEED WITH CIRCULAR DEPENDENCIES
 
 ---
 
-## Phase 3: Ralph Readiness Validation (Step-05)
-
-> **When:** After artifacts deployed (step-05), before launching /ralph-loop
-> **Blocking:** YES - Development blocked if critical checks fail
-
-### Purpose
-
-Final gate to ensure business analysis is 100% ready for implementation. Catches issues before ralph-loop starts, preventing failed development attempts.
-
-### Checks (9 categories)
-
-| # | Category | Checks | Blocking | Purpose |
-|---|----------|--------|----------|---------|
-| 1 | Module Status | All modules status = "handed-off" | YES | Incomplete modules break ralph-loop |
-| 2 | PRD Files | All .ralph/prd-{module}.json files exist, valid structure, file counts match index.json | YES | Ralph-loop reads PRDs for tasks |
-| 3 | Dependency Graph | Valid, no cycles, topological order correct | YES | Determines module implementation order |
-| 4 | Cross-Module References | All references resolvable | YES | Prevents FK constraint errors |
-| 5 | Handoff Completeness | All 8 file categories, brToCodeMapping, apiEndpointSummary | YES | Missing data breaks code generation |
-| 6 | i18n Keys | All keys have 4 languages | NO (WARNING) | Missing translations won't block dev |
-| 7 | Master Feature | Status = "handed-off", handoff complete | YES | Ralph-loop needs master handoff |
-| 8 | Progress Tracker | File exists, structure valid, task count matches | NO (WARNING) | Used for progress tracking |
-| 9 | Final Readiness | Aggregate all checks, calculate score | YES if <100% | All critical checks must pass |
-
-### Readiness Score
-
-```
-Readiness Score = (passed critical checks / total critical checks) × 100%
-```
-
-**Thresholds:**
-- **100%** → READY FOR DEVELOPMENT ✓
-- **<100%** → NOT READY - FIX REQUIRED ✗
-
-### Example Output
-
-**Ready:**
-
-```
-═══════════════════════════════════════════════════════════════
-  RALPH READINESS CHECK - COMPLETE
-═══════════════════════════════════════════════════════════════
-
-Validation Summary:
-  ✓ Module status validation: PASS (5/5 modules)
-  ✓ PRD files validation: PASS (5/5 files)
-  ✓ Dependency graph validation: PASS (4 edges)
-  ✓ Cross-module references validation: PASS (4 references)
-  ✓ Handoff completeness check: PASS (5/5 modules)
-  ⚠ i18n keys validation: WARNING (1 missing translation)
-  ✓ Master feature validation: PASS
-  ✓ Progress tracker validation: PASS
-
-Readiness Score: 100% (7/7 critical checks passed, 1 warning)
-
-Status: READY FOR DEVELOPMENT ✓
-
-Next Steps:
-  1. Address warnings (optional, recommended)
-  2. Review progress tracker: .ralph/progress.txt
-  3. Launch development: /ralph-loop
-     (Use /ralph-loop -r ONLY to resume an interrupted loop)
-═══════════════════════════════════════════════════════════════
-```
-
-**Not Ready:**
-
-```
-═══════════════════════════════════════════════════════════════
-  RALPH READINESS CHECK - FAILED
-═══════════════════════════════════════════════════════════════
-
-Status: NOT READY FOR DEVELOPMENT ✗
-
-Critical Issues Found:
-  ✗ Module status validation: FAIL (1/5 modules incomplete)
-    - Reporting module status is "specified", must be "handed-off"
-    - Fix: Return to step-05-deploy.md for Reporting module
-
-  ✗ PRD files validation: FAIL (1/5 files invalid)
-    - prd-Reporting.json has wrong structure (filesToCreate at root level)
-    - Fix: Re-run ss derive-prd --feature {path} --output .ralph/prd-Reporting.json
-
-Required Actions:
-  1. Fix all critical issues listed above
-  2. Re-run validation: load step-05-deploy.md
-  3. Only proceed to /ralph-loop when all critical checks pass
-
-DO NOT PROCEED TO /RALPH-LOOP UNTIL ALL CRITICAL CHECKS PASS
-═══════════════════════════════════════════════════════════════
-```
+> **Note:** Ralph Readiness Validation (PRD files, handoff completeness, etc.) is handled by the `/derive-prd` skill.
 
 ---
 
@@ -374,7 +285,6 @@ DO NOT PROCEED TO /RALPH-LOOP UNTIL ALL CRITICAL CHECKS PASS
 **Checkpoints:**
 - Step-03d: Module completeness (before marking "specified")
 - Step-04: Cross-module coherence (before marking "consolidated")
-- Step-05c: Development readiness (before /ralph-loop)
 
 ### 3. Auto-Fix vs. Manual Fix
 
@@ -486,25 +396,6 @@ WHERE: Return to step-03-specify.md for TimeTracking module
 
 ---
 
-### Issue: Ralph Readiness Check Fails
-
-**Symptoms:**
-- Step-05c reports readiness score < 100%
-- Critical checks failed
-
-**Diagnosis:**
-1. Review failed checks in summary
-2. Identify missing/invalid artifacts
-
-**Fix:**
-- **Module status incomplete:** Return to step-05-deploy for affected module
-- **PRD files invalid:** Re-run `ss derive-prd` for affected module
-- **Handoff incomplete:** Return to step-05-deploy, complete handoff section
-- **Cross-module refs broken:** Return to step-04-consolidate, fix references
-- Re-run step-05-deploy after fixes
-
----
-
 ## Metrics & Success Criteria
 
 ### Module Specification Checklist
@@ -525,17 +416,7 @@ WHERE: Return to step-03-specify.md for TimeTracking module
 
 **Success:**
 - Application marked as "consolidated"
-- Ready for handoff
-
-### Ralph Readiness (Step-05)
-
-**Target:**
-- 100% critical checks passed
-- Warnings addressed or documented
-
-**Success:**
-- Application ready for /ralph-loop
-- Development can proceed with full confidence
+- Ready for `/ba-generate-html` and `/derive-prd`
 
 ---
 

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

@@ -147,18 +147,17 @@ const checklist = {
   },
 
   wireframeSchemaCompliance: {
-    check: "All wireframes have required fields: screen, section, mockupFormat, elements[], componentMapping[], layout (object), permissionsRequired[]",
+    check: "All wireframes have required fields: screen, section, mockupFormat, elements[], layout (object), permissionsRequired[]",
     status: (specification.uiWireframes || specification.wireframes || []).every(wf =>
       (wf.screen || wf.title) && wf.section && (wf.mockupFormat || wf.mockup || wf.ascii) &&
       Array.isArray(wf.elements) && wf.elements.length > 0 &&
-      Array.isArray(wf.componentMapping) && wf.componentMapping.length > 0 &&
       typeof wf.layout === 'object' && wf.layout !== null &&
       Array.isArray(wf.permissionsRequired)
     ) ? "PASS" : "FAIL",
     blocking: true,
-    details: "Wireframes missing metadata render as empty frames in HTML documentation. " +
+    details: "Wireframes missing metadata render as empty frames. " +
              "Check: screen (not name/id/title), section, mockupFormat, elements[] non-empty, " +
-             "componentMapping[] as array of {wireframeElement, reactComponent}, layout as object (not string). " +
+             "layout as object (not string). " +
              "Also see references/acceptance-criteria.md for bash-verifiable checks."
   },
 

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) | step-05-deploy → handoff-schema.json (filesToCreate, brToCodeMapping, apiEndpointSummary) + (prd, progress, manifest, ba-interactive.html) | step-06-review → applies ba-review.json corrections, creates new version",
+  "$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",
 
   "$defs": {
     "stepStatus": { "$ref": "shared/common-defs.json#/$defs/stepStatus" },