@atlashub/smartstack-cli 4.42.0 → 4.44.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/templates/skills/business-analyse/questionnaire/02-stakeholders-scope.md +11 -9
- package/templates/skills/business-analyse/react/components.md +0 -21
- package/templates/skills/business-analyse/steps/step-01-cadrage.md +1 -1
- package/templates/skills/business-analyse-handoff/steps/step-00-validate.md +1 -1
- package/templates/skills/business-analyse-handoff/steps/step-01-transform.md +4 -4
- package/templates/skills/business-analyse-handoff/steps/step-02-export.md +2 -2
- package/templates/skills/business-analyse-html/html/ba-interactive.html +5 -9
- package/templates/skills/business-analyse-html/html/src/scripts/02-navigation.js +5 -9
package/package.json
CHANGED
|
@@ -28,11 +28,12 @@
|
|
|
28
28
|
|
|
29
29
|
## 2.3 Les niveaux d'accès
|
|
30
30
|
|
|
31
|
-
> **But :** Définir
|
|
31
|
+
> **But :** Définir les règles métier de permissions par rôle (SmartStack gère nativement RBAC + isolation tenant).
|
|
32
|
+
> **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.
|
|
32
33
|
|
|
33
34
|
| # | Question | Type de réponse |
|
|
34
35
|
|---|----------|-----------------|
|
|
35
|
-
| Q2.9 |
|
|
36
|
+
| 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 |
|
|
36
37
|
| Q2.10 | Qui a le droit de modifier ou supprimer des informations ? Tout le monde ou seulement certaines personnes ? | Règles de modification |
|
|
37
38
|
| Q2.11 | Y a-t-il des actions sensibles qui nécessitent une validation par un supérieur ? | Liste des actions à valider |
|
|
38
39
|
|
|
@@ -40,16 +41,17 @@
|
|
|
40
41
|
|
|
41
42
|
## 2.4 Périmètre fonctionnel
|
|
42
43
|
|
|
43
|
-
> **But :** Lister tout ce que le système doit faire et ne pas faire,
|
|
44
|
+
> **But :** Lister tout ce que le système doit faire et ne pas faire, classifié par importance métier.
|
|
45
|
+
> **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".
|
|
44
46
|
|
|
45
47
|
| # | Question | Type de réponse |
|
|
46
48
|
|---|----------|-----------------|
|
|
47
49
|
| Q2.12 | Listez toutes les fonctionnalités que vous souhaitez dans ce système. Ne vous censurez pas. | Liste libre de fonctionnalités |
|
|
48
|
-
| Q2.13 | Parmi
|
|
50
|
+
| 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 |
|
|
49
51
|
| Q2.15 | Y a-t-il des choses que le système ne doit explicitement PAS faire ? Des limites claires à poser ? | Liste d'exclusions |
|
|
50
52
|
|
|
51
|
-
**Test de
|
|
52
|
-
> Pour chaque fonctionnalité classée comme
|
|
53
|
+
**Test de classification :**
|
|
54
|
+
> Pour chaque fonctionnalité classée comme vitale, poser la question :
|
|
53
55
|
> "Si on enlevait cette fonctionnalité, le système aurait-il encore de la valeur ?"
|
|
54
56
|
|
|
55
57
|
---
|
|
@@ -87,7 +89,7 @@
|
|
|
87
89
|
|----------|------------------------|---------------------|
|
|
88
90
|
| 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 ?" |
|
|
89
91
|
| 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 ?" |
|
|
90
|
-
| Q2.9 (
|
|
92
|
+
| 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 ?" |
|
|
91
93
|
| Q2.13 (indispensable) | Tout est indispensable | "Si vous ne pouviez garder que 3 fonctionnalités pour un premier lancement, lesquelles ?" |
|
|
92
94
|
| Q2.15 (exclusions) | "Je ne vois pas" | "Certains utilisateurs pourraient-ils s'attendre à des fonctionnalités que vous ne souhaitez PAS inclure ?" |
|
|
93
95
|
| Q2.16 (parcours) | Moins de 3 étapes | "Détaillons : l'utilisateur arrive sur l'écran d'accueil. Que voit-il ? Où clique-t-il ?" |
|
|
@@ -97,8 +99,8 @@
|
|
|
97
99
|
| Signal du client | Problème sous-jacent | Action de l'analyste |
|
|
98
100
|
|------------------|---------------------|----------------------|
|
|
99
101
|
| "Tous les utilisateurs font la même chose" | Rôles non différenciés | "Qui peut supprimer ? Qui ne fait que consulter ? Qui valide ?" |
|
|
100
|
-
| "Tout le monde doit tout voir" |
|
|
101
|
-
| Tout est
|
|
102
|
+
| "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 ?" |
|
|
103
|
+
| 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 ?" |
|
|
102
104
|
| 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 ?" |
|
|
103
105
|
| 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 ?" |
|
|
104
106
|
|
|
@@ -23,9 +23,7 @@ import {
|
|
|
23
23
|
Shield,
|
|
24
24
|
CheckCircle,
|
|
25
25
|
AlertTriangle,
|
|
26
|
-
ChevronRight,
|
|
27
26
|
ArrowRight,
|
|
28
|
-
List,
|
|
29
27
|
Layout,
|
|
30
28
|
Database,
|
|
31
29
|
GitBranch,
|
|
@@ -202,25 +200,6 @@ export function BusinessAnalyseViewer() {
|
|
|
202
200
|
</p>
|
|
203
201
|
</header>
|
|
204
202
|
|
|
205
|
-
{/* Table of Contents */}
|
|
206
|
-
<div className="card p-4 bg-[var(--bg-secondary)]">
|
|
207
|
-
<h2 className="font-semibold mb-3 flex items-center gap-2">
|
|
208
|
-
<List className="w-4 h-4" />
|
|
209
|
-
{t('common.tableOfContents', 'Table of Contents')}
|
|
210
|
-
</h2>
|
|
211
|
-
<nav className="grid grid-cols-2 md:grid-cols-4 gap-2">
|
|
212
|
-
{sections.map((section, idx) => (
|
|
213
|
-
<a
|
|
214
|
-
key={section.key}
|
|
215
|
-
href={`#section-${idx + 1}`}
|
|
216
|
-
className="flex items-center gap-2 p-2 rounded hover:bg-[var(--bg-tertiary)] text-sm"
|
|
217
|
-
>
|
|
218
|
-
<ChevronRight className="w-4 h-4 text-[var(--color-primary-600)]" />
|
|
219
|
-
{section.label}
|
|
220
|
-
</a>
|
|
221
|
-
))}
|
|
222
|
-
</nav>
|
|
223
|
-
</div>
|
|
224
203
|
|
|
225
204
|
{/* Stats Overview */}
|
|
226
205
|
<div className="grid grid-cols-2 md:grid-cols-5 gap-4">
|
|
@@ -236,7 +236,7 @@ Apply ULTRATHINK after the batch:
|
|
|
236
236
|
|
|
237
237
|
Ask in 1-2 batches. After each batch:
|
|
238
238
|
- If only 1 user type mentioned → probe: "Who else interacts? Managers? Admins? External users?"
|
|
239
|
-
- If "
|
|
239
|
+
- If "no restrictions" → probe: "Are there sensitive data (salary, contracts, personal info) that should be restricted to specific roles?"
|
|
240
240
|
- If tasks are generic → ask for a concrete scenario: "Walk me through a typical day"
|
|
241
241
|
|
|
242
242
|
#### 4c. Functional Scope (ALWAYS — from `questionnaire/02-stakeholders-scope.md`)
|
|
@@ -106,7 +106,7 @@ Collect results per module: PASS count, FAIL count.
|
|
|
106
106
|
|
|
107
107
|
### 6. Calculate Readiness Score
|
|
108
108
|
|
|
109
|
-
> **Reference:**
|
|
109
|
+
> **Reference:** See loaded context `readiness-scoring.md` for the full algorithm.
|
|
110
110
|
|
|
111
111
|
For each module:
|
|
112
112
|
- Count input ACs passed vs total (7 input ACs)
|
|
@@ -127,7 +127,7 @@ for (const section of screens) {
|
|
|
127
127
|
|
|
128
128
|
### 3. Map Specification to Files (8 Categories)
|
|
129
129
|
|
|
130
|
-
> **Reference:**
|
|
130
|
+
> **Reference:** See loaded context `handoff-file-templates.md` for complete JSON templates.
|
|
131
131
|
> All backend paths MUST include `{ApplicationName}/` hierarchy.
|
|
132
132
|
|
|
133
133
|
| Category | Source | Key rules |
|
|
@@ -157,7 +157,7 @@ for (const section of screens) {
|
|
|
157
157
|
|
|
158
158
|
### 4. Map Business Rules to Code
|
|
159
159
|
|
|
160
|
-
> **Reference:**
|
|
160
|
+
> **Reference:** See loaded context `handoff-mappings.md` -- Section "Business Rules to Code Mapping"
|
|
161
161
|
|
|
162
162
|
For each rule in `rules.json > rules[]` of EACH module:
|
|
163
163
|
- ruleId, title, module, severity (from `rule.severity`)
|
|
@@ -187,11 +187,11 @@ Each seedData entry MUST include a `category` field:
|
|
|
187
187
|
- `category: "core"` -- Navigation, Permissions, Roles (mandatory infrastructure)
|
|
188
188
|
- `category: "business"` -- Domain-specific reference/lookup data
|
|
189
189
|
|
|
190
|
-
> **Reference:**
|
|
190
|
+
> **Reference:** See loaded context `handoff-seeddata-generation.md` for complete core seed generation.
|
|
191
191
|
|
|
192
192
|
### 7. Map Entity to Domain File (GAP #4 Fix)
|
|
193
193
|
|
|
194
|
-
> **Reference:**
|
|
194
|
+
> **Reference:** See loaded context `entity-domain-mapping.md` for complete mapping rules.
|
|
195
195
|
|
|
196
196
|
1:1 mapping from BA entity to Domain file:
|
|
197
197
|
|
|
@@ -59,7 +59,7 @@ Generates `prd-{moduleCode}.json` with `$version: "4.0.0"` containing:
|
|
|
59
59
|
|
|
60
60
|
### 2. POST-CHECK PRD (BLOCKING)
|
|
61
61
|
|
|
62
|
-
> **Reference:**
|
|
62
|
+
> **Reference:** See loaded context `prd-generation.md` for complete validation rules.
|
|
63
63
|
|
|
64
64
|
```javascript
|
|
65
65
|
const prd = readJSON(`.ralph/prd-${moduleCode}.json`);
|
|
@@ -113,7 +113,7 @@ Write to: `.ralph/modules-queue.json`
|
|
|
113
113
|
|
|
114
114
|
### 4. Generate progress.txt
|
|
115
115
|
|
|
116
|
-
> **Template:**
|
|
116
|
+
> **Template:** See loaded context `tpl-progress.md` for complete structure.
|
|
117
117
|
> **Data source:** Populate with module-specific data from index.json.
|
|
118
118
|
|
|
119
119
|
- One section per module in topological order
|
|
@@ -2736,21 +2736,17 @@ function renderModuleNavItem(mod) {
|
|
|
2736
2736
|
var html = '<div class="nav-module" data-group-id="' + groupId + '">';
|
|
2737
2737
|
|
|
2738
2738
|
// Module header (clickable to expand + navigate to module spec)
|
|
2739
|
+
var totalItems = ucCount + brCount + entCount;
|
|
2739
2740
|
html += '<a class="nav-item nav-module-header" onclick="toggleNavGroup(\'' + groupId + '\');showSection(\'module-spec-' + code + '\')" data-section="module-spec-' + code + '">';
|
|
2740
2741
|
html += '<span class="nav-chevron ' + (collapsed ? '' : 'expanded') + '">▸</span> ';
|
|
2741
2742
|
html += (mod.name || mod.code);
|
|
2743
|
+
if (totalItems > 0) html += ' <span class="nav-badge">' + totalItems + '</span>';
|
|
2742
2744
|
html += '</a>';
|
|
2743
2745
|
|
|
2744
|
-
// Children:
|
|
2746
|
+
// Children: sections/resources (navigable sub-tree)
|
|
2747
|
+
// Tab-level items (UC, BR, Données, etc.) are NOT shown here — they are accessed
|
|
2748
|
+
// via the tab bar in the module content area to avoid redundancy.
|
|
2745
2749
|
html += '<div class="nav-children"' + (collapsed ? ' style="display:none;"' : '') + '>';
|
|
2746
|
-
html += renderModuleTabNavItem(code, 'uc', 'Cas d\'utilisation', ucCount);
|
|
2747
|
-
html += renderModuleTabNavItem(code, 'br', 'Règles métier', brCount);
|
|
2748
|
-
html += renderModuleTabNavItem(code, 'ent', 'Données', entCount);
|
|
2749
|
-
html += renderModuleTabNavItem(code, 'perm', 'Droits d\'accès');
|
|
2750
|
-
html += renderModuleTabNavItem(code, 'mock', 'Maquettes');
|
|
2751
|
-
html += renderModuleTabNavItem(code, 'struct', 'Structure', sections.length);
|
|
2752
|
-
|
|
2753
|
-
// Children: sections/resources (deeper tree)
|
|
2754
2750
|
if (sections.length > 0) {
|
|
2755
2751
|
sections.forEach(function(section) {
|
|
2756
2752
|
var resources = section.resources || [];
|
|
@@ -156,21 +156,17 @@ function renderModuleNavItem(mod) {
|
|
|
156
156
|
var html = '<div class="nav-module" data-group-id="' + groupId + '">';
|
|
157
157
|
|
|
158
158
|
// Module header (clickable to expand + navigate to module spec)
|
|
159
|
+
var totalItems = ucCount + brCount + entCount;
|
|
159
160
|
html += '<a class="nav-item nav-module-header" onclick="toggleNavGroup(\'' + groupId + '\');showSection(\'module-spec-' + code + '\')" data-section="module-spec-' + code + '">';
|
|
160
161
|
html += '<span class="nav-chevron ' + (collapsed ? '' : 'expanded') + '">▸</span> ';
|
|
161
162
|
html += (mod.name || mod.code);
|
|
163
|
+
if (totalItems > 0) html += ' <span class="nav-badge">' + totalItems + '</span>';
|
|
162
164
|
html += '</a>';
|
|
163
165
|
|
|
164
|
-
// Children:
|
|
166
|
+
// Children: sections/resources (navigable sub-tree)
|
|
167
|
+
// Tab-level items (UC, BR, Données, etc.) are NOT shown here — they are accessed
|
|
168
|
+
// via the tab bar in the module content area to avoid redundancy.
|
|
165
169
|
html += '<div class="nav-children"' + (collapsed ? ' style="display:none;"' : '') + '>';
|
|
166
|
-
html += renderModuleTabNavItem(code, 'uc', 'Cas d\'utilisation', ucCount);
|
|
167
|
-
html += renderModuleTabNavItem(code, 'br', 'Règles métier', brCount);
|
|
168
|
-
html += renderModuleTabNavItem(code, 'ent', 'Données', entCount);
|
|
169
|
-
html += renderModuleTabNavItem(code, 'perm', 'Droits d\'accès');
|
|
170
|
-
html += renderModuleTabNavItem(code, 'mock', 'Maquettes');
|
|
171
|
-
html += renderModuleTabNavItem(code, 'struct', 'Structure', sections.length);
|
|
172
|
-
|
|
173
|
-
// Children: sections/resources (deeper tree)
|
|
174
170
|
if (sections.length > 0) {
|
|
175
171
|
sections.forEach(function(section) {
|
|
176
172
|
var resources = section.resources || [];
|