@atlashub/smartstack-cli 4.18.0 → 4.20.0

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

@@ -1,124 +0,0 @@
-# Business Analysis - SmartStack Architecture Reference (_architecture.md)
-
-> **Loaded by:** step-01-cadrage, step-03a-data, step-05a-handoff
-> **Purpose:** Provide architectural context for relevant questions and aligned recommendations
-
----
-
-## 5 Couches (Clean Architecture)
-
-| Couche | Projet | Contenu | Impact BA |
-|--------|--------|---------|-----------|
-| **Domain** | `SmartStack.Domain` | Entites, enums, interfaces | Entites identifiees en discovery |
-| **Application** | `SmartStack.Application` | CQRS (Commands/Queries), validations, DTOs | Use cases de la specification |
-| **Infrastructure** | `SmartStack.Infrastructure` | EF Core, services externes, jobs | Integrations et contraintes techniques |
-| **API** | `SmartStack.API` | Controllers REST, permissions | Endpoints et securite |
-| **Web** | `smartstack-web` | React 19, pages, composants | UI/UX et navigation |
-
----
-
-## Classes de Base des Entites
-
-| Classe | Interface | Champs auto-inclus | Quand utiliser |
-|--------|-----------|---------------------|----------------|
-| `BaseEntity` | - | `Id` (Guid), `TenantId`, `CreatedAt`, `UpdatedAt` | **Defaut pour toute entite metier** |
-| `BaseEntity` | `IAuditableEntity` | + `CreatedBy`, `UpdatedBy` | Entite avec audit complet |
-| `SystemEntity` | - | `Id` (Guid), `CreatedAt` (pas de TenantId) | Entites systeme (navigation, permissions) |
-| `BaseEntity` | `ISoftDeletable` | + `IsDeleted`, `DeletedBy`, `DeletedAt` | Entite avec suppression logique |
-| `HierarchicalEntity` | - | + `ParentId`, `Level`, `Path` | Arborescences (categories, menus) |
-| `BaseEntity + UserId FK` | `ITenantEntity` | + `UserId` (Guid FK to User) | Person Role Extension — entity represents a person linked to User. Use `isPersonRole: true` in scaffold_extension. |
-
-> **IMPORTANT :** Ne JAMAIS proposer `CreatedBy`, `UpdatedBy`, `IsDeleted`, `TenantId` comme champs explicites — ils sont AUTOMATIQUES via la classe de base ou l'interface.
-
----
-
-## Services d'Integration Disponibles
-
-| Service | Interface | Quand le proposer |
-|---------|-----------|-------------------|
-| Notifications in-app | `INotificationService` | Alertes, evenements, rappels |
-| Workflow automatise | `IWorkflowService` | Emails transactionnels, webhooks, actions chainees |
-| Completion IA | `IAICompletionService` | Suggestions, classification, generation contenu |
-| SignalR temps reel | `IHubContext<BusinessHub>` | Mises a jour en temps reel |
-| Jobs planifies | Hangfire `IBackgroundJobClient` | Traitements differes, purges, imports |
-
----
-
-## Conventions Base de Donnees
-
-| Aspect | Convention | Exemple |
-|--------|------------|---------|
-| Schema | `core` (socle SmartStack) vs `extensions` (entites client/metier) | `core.auth_Roles`, `nav_Applications`, `supp_Tickets` |
-| Tables | `{prefix}_{EntityPlural}` (prefixe domaine + PascalCase pluriel) | `auth_Users`, `nav_Applications`, `supp_Tickets` |
-| Prefixes domaine | `auth_`, `nav_`, `cfg_`, `ref_`, `wkf_`, `ai_`, `loc_`, `lic_`, `tenant_`, `support_` | Pour un nouveau module metier : choisir un prefixe court (3-5 chars) |
-| FK | `{Entity}Id` (ex: `ClientId`, `OrderId`) | |
-| Index | `IX_{Table}_{Column}` | `IX_bik_FreeBickes_TenantId_Code` |
-| Migration | 1 migration par feature, nommee via MCP (`suggest_migration`) | `extensions_v1.0.0_001_AddFreeBicke` |
-
----
-
-## Conventions de Dossiers (Clean Architecture)
-
-| Couche | Pattern de dossiers | Exemple (module FreeBicke dans business > operations) |
-|--------|--------------------|---------------------------------------------------------|
-| **Domain** | `{Project}.Domain/Business/{Application}/{Module}/` | `Domain/Business/Operations/FreeBicke/FreeBicke.cs` |
-| **Application/DTOs** | `{Project}.Application/Business/{Application}/{Module}/DTOs/` | `Application/Business/Operations/FreeBicke/DTOs/FreeBickeDto.cs` |
-| **Application/Interfaces** | `{Project}.Application/Common/Interfaces/` | `Application/Common/Interfaces/IFreeBickeService.cs` |
-| **Infrastructure/Config** | `{Project}.Infrastructure/Persistence/Configurations/{Application}/{Module}/` | `Configurations/Operations/FreeBicke/FreeBickeConfiguration.cs` |
-| **Infrastructure/Services** | `{Project}.Infrastructure/Services/{Application}/{Module}/` | `Services/Operations/FreeBicke/FreeBickeService.cs` |
-| **Infrastructure/SeedData** | `{Project}.Infrastructure/Persistence/Seeding/Data/{Application}/{Module}/` | `Seeding/Data/Operations/FreeBicke/FreeBickeSeedData.cs` |
-| **API/Controllers** | `{Project}.Api/Controllers/Business/{Application}/` | `Controllers/Business/Operations/FreeBickeController.cs` |
-| **Frontend/Pages** | `web/src/pages/{application}/{module}/` | `pages/operations/freebicke/page.tsx` |
-| **Frontend/i18n** | `web/src/i18n/locales/{lang}/{module}.json` | `locales/fr/freebicke.json` |
-
-> **IMPORTANT :** Chaque module a son **propre sous-dossier** dans chaque couche. Ne JAMAIS mettre tous les fichiers a la racine d'une couche.
-
----
-
-## SeedData Core (Obligatoire pour chaque feature)
-
-> **Chaque nouvelle feature necessite des SeedData dans 5 fichiers core** pour etre fonctionnelle (navigation visible, permissions actives, roles assignes).
-
-| # | Fichier | Contenu | Mecanisme |
-|---|---------|---------|-----------|
-| 1 | `NavigationModuleConfiguration.cs` | Entree module dans `nav_Modules` (HasData) | EF Core Migration |
-| 2 | `NavigationTranslationConfiguration.cs` | Traductions du module (4 langues x chaque entite nav) | EF Core Migration |
-| 3 | `PermissionConfiguration.cs` | Permissions CRUD + wildcards dans `nav_Permissions` (HasData) | EF Core Migration |
-| 4 | `Permissions.cs` (Application layer) | Constantes compile-time pour `[RequirePermission]` | Code |
-| 5 | `RolePermissionConfiguration.cs` | Associations role-permission dans `auth_RolePermissions` (HasData) | EF Core Migration |
-
-**Roles par defaut pour chaque application (4 niveaux) :**
-
-| Role | Permissions | Description |
-|------|-------------|-------------|
-| **{App} Admin** | `{app}.*` (wildcard) | Acces complet a l'application |
-| **{App} Manager** | `read`, `create`, `update`, `assign` | Gestion complete sans suppression |
-| **{App} Contributor** | `read`, `create`, `update` | Contribution active |
-| **{App} Viewer** | `read` uniquement | Consultation seule |
-
-> **CRITIQUE :** Si les SeedData ne sont pas crees, le module sera invisible dans la navigation et les permissions retourneront 403.
-
----
-
-## Contraintes Non-Negociables
-
-| Contrainte | Detail |
-|------------|--------|
-| **Multi-tenant** | `TenantId` sur toute entite metier, isolation automatique |
-| **RBAC** | Permissions `{app}.{module}.{action}`, HasData pattern |
-| **CQRS** | Commands (write) et Queries (read) separes via MediatR |
-| **Validation** | FluentValidation pour toute commande |
-| **i18n** | 4 langues obligatoires (fr, en, it, de) |
-| **Soft Delete** | Pas de DELETE physique sauf purge RGPD planifiee |
-
----
-
-## Outils MCP Pertinents pour le BA
-
-| Phase BA | Outil MCP | Usage |
-|----------|-----------|-------|
-| Pre-research (01) | `analyze_extension_points` | Decouvrir modules/entites existants |
-| Pre-research (01) | `api_docs` | Consulter la documentation API existante |
-| Analyse (02) | `validate_conventions` | Verifier les noms d'entites proposes |
-| Specification (03) | `generate_permissions` | Generer la matrice de permissions |
-| Handoff (05) | `scaffold_extension` | Preparer le scaffolding |

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

@@ -1,206 +0,0 @@
-# Business Analysis - Elicitation & Interaction (_elicitation.md)
-
-> **Loaded by:** step-01-cadrage, step-03a-data
-> **Purpose:** Interactive questioning techniques, AskUserQuestion formatting, ULTRATHINK mode
-
----
-
-## Interactive Elicitation Protocol
-
-> **RULE: ALL questions MUST be asked interactively using `AskUserQuestion`.**
-> **NEVER dump a list of questions as text. ALWAYS use the tool.**
-
-### Protocol
-
-1. **Group questions by theme** — max 4 questions per `AskUserQuestion` call (tool limit)
-2. **Propose predefined options** — for questions with predictable answers, provide 2-4 options
-3. **The user can always choose "Other"** — the tool adds this automatically for free-text answers
-4. **Process answers immediately** — apply ULTRATHINK + follow-ups before moving to next group
-5. **Adapt next questions** — based on previous answers, skip irrelevant questions
-
-### Batching Strategy
-
-| Category | Questions | Batches |
-|----------|-----------|---------|
-| 01-context | Q1.1-Q1.4 | 1 call |
-| 02-stakeholders | Q2.1-Q2.8 | 2 calls |
-| 03-scope | Q3.1-Q3.8 | 2 calls |
-| 04-data | Q4.1-Q4.8 | 2 calls |
-| 05-integrations | Q5.1-Q5.8 | 2 calls |
-| 06-security | Q6.1-Q6.8 | 2 calls |
-| 07-ui | Q7.1-Q7.8 | 2 calls |
-| 08-performance | Q8.1-Q8.4 | 1 call |
-| 09-constraints | Q9.1-Q9.4 | 1 call |
-| 10-documentation | Q10.1-Q10.4 | 1 call |
-| 11-data-lifecycle | Q11.1-Q11.8 | 2 calls |
-| 12-migration | Q12.1-Q12.8 | 2 calls |
-| 13-cross-module | Q13.1-Q13.8 | 2 calls |
-
-### AskUserQuestion Format
-
-> **FORMATTING CRITICAL: `AskUserQuestion` does NOT support markdown or line breaks.**
-> Le champ `question` est rendu en texte brut (plain text). Il n'y a pas de retour a la ligne,
-> pas de gras, pas de puces. Une question simple reste lisible meme longue. Mais du contenu
-> structure (listes, resumes multi-points, tableaux) devient un mur de texte illisible.
-
-| Field | Rule |
-|-------|------|
-| `question` | **1 question ou 1 phrase.** Jamais de liste, resume multi-points ou contenu structure. |
-| `header` | 1-2 mots (max 12 chars) |
-| `label` (option) | Court et clair (~20 chars) |
-| `description` (option) | 1 phrase explicative (~60 chars) |
-
-> **Pour afficher du contenu structure** (resumes, listes, tableaux, syntheses) :
-> **TOUJOURS** utiliser du **texte direct** (output text) AVANT l'appel `AskUserQuestion`.
-> Le texte direct supporte le markdown et sera correctement formate avec titres, puces, gras, etc.
->
-> **Exemple — Validation de synthese :**
-> 1. Afficher le resume structure en markdown (texte direct)
-> 2. Puis poser une question courte : "Cette synthese est-elle correcte ?"
-
-```
-AskUserQuestion({
-  questions: [
-    {
-      question: "Quel probleme metier ce module doit-il resoudre ?",
-      header: "Probleme",       // max 12 chars
-      options: [
-        { label: "Processus manuel", description: "Automatiser un processus existant fait manuellement" },
-        { label: "Donnees dispersees", description: "Centraliser des donnees eparpillees dans plusieurs outils" },
-        { label: "Manque visibilite", description: "Obtenir des indicateurs et du suivi inexistants aujourd'hui" },
-        { label: "Conformite", description: "Repondre a une obligation reglementaire ou de securite" }
-      ],
-      multiSelect: false
-    },
-    // ... up to 4 questions per call
-  ]
-})
-```
-
-### After Each Batch
-
-1. **Evaluate answer quality** (see Answer Quality Indicators)
-2. **If insufficient** -> follow-up AskUserQuestion with targeted probes from the Elicitation Guide
-3. **If solution-oriented** -> reframe using Technique 1 before proceeding
-4. **If sufficient/excellent** -> record and move to next batch
-5. **Summarize** what was understood before moving to the next category
-
----
-
-## Techniques d'elicitation
-
-> **Objectif :** Guider COMMENT questionner, pas seulement QUOI demander.
-> **Principe :** Chaque technique doit etre appliquee naturellement dans le flux de la conversation,
-> pas comme un outil supplementaire. L'analyste choisit la technique adaptee a la situation.
-
-### Technique 1 : Reformulation du besoin
-
-Quand le client decrit une **solution** (bouton, ecran, champ, outil), reformuler en **besoin** :
-
-| Le client dit | L'analyste demande |
-|---------------|-------------------|
-| "Il me faut un menu deroulant pour les roles" | "Quel probleme rencontrez-vous aujourd'hui avec la gestion des acces ? Pourquoi certaines personnes doivent-elles avoir des acces differents ?" |
-| "On a besoin d'un bouton d'export" | "Que faites-vous avec les donnees une fois exportees ? Qui en a besoin et pourquoi ?" |
-| "Ajoutez un champ statut" | "Quel parcours suit cet element du debut a la fin ? Quels evenements declenchent un changement d'etat ?" |
-
-### Technique 2 : Chaine des pourquoi
-
-Quand le besoin semble superficiel, enchainez jusqu'a 5 "Pourquoi ?" pour trouver la cause racine :
-
-```
-Client : "On a besoin de suivre l'activite des utilisateurs"
--> Pourquoi ? "Pour savoir qui a modifie quoi"
--> Pourquoi ? "Parce qu'on a eu des problemes de donnees incorrectes"
--> Pourquoi ? "Parce que plusieurs personnes modifient les memes fiches"
--> CAUSE RACINE : Conflit d'edition simultanee -> Besoin de journal d'activite + protection des modifications
-```
-
-### Technique 3 : Extraction de scenario concret
-
-Ne jamais accepter de descriptions abstraites. Toujours demander un **scenario de vie reelle** :
-
-```
-"Racontez-moi une journee type : vous arrivez au bureau, vous ouvrez l'application.
- Quelle est la PREMIERE chose que vous devez faire ?
- Puis ensuite ? Quelles informations consultez-vous ? Quelles decisions prenez-vous ?"
-```
-
-### Technique 4 : Test d'absence
-
-Valider la necessite en demandant ce qui se passe SANS :
-
-```
-"Si cette fonctionnalite N'EXISTAIT PAS, que feriez-vous a la place ?
- Combien de temps ou d'argent le contournement actuel coute-t-il ?"
-```
-
-### Technique 5 : Verification de completude
-
-Pour chaque reponse sous forme de liste, verifier qu'il ne manque rien :
-
-| Type de reponse | Relance |
-|-----------------|---------|
-| "Il y a 3 types d'utilisateurs" | "Y a-t-il des acteurs externes ? Des auditeurs ? Des administrateurs systeme ? Des processus automatiques ?" |
-| "Le flux principal est A puis B puis C" | "Que se passe-t-il si l'utilisateur annule a l'etape B ? Si l'etape C echoue ? S'il veut revenir a A ?" |
-| "Champs obligatoires : nom et email" | "Quelles contraintes d'unicite ? Quel format ? Que se passe-t-il en cas de doublon ?" |
-
-### Technique 6 : Projection dans le futur
-
-Demander au client de se projeter pour decouvrir des besoins non exprimes :
-
-```
-"Imaginons que nous sommes 2 ans dans le futur et que l'application fonctionne parfaitement.
- Qu'est-ce qui a change dans votre facon de travailler ?
- Quels nouveaux besoins sont apparus auxquels vous ne pensez pas aujourd'hui ?"
-```
-
-### Technique 7 : Test de contradiction
-
-Quand deux reponses semblent contradictoires, les confronter pour clarifier :
-
-```
-"Vous avez mentionne que [affirmation A], mais vous dites aussi que [affirmation B].
- Ces deux elements semblent en tension. Pouvez-vous m'aider a comprendre
- comment ils coexistent dans la realite ?"
-```
-
-### Technique 8 : Escalade d'impact
-
-Augmenter progressivement l'echelle pour tester les limites :
-
-```
-"Aujourd'hui vous avez 50 fiches. Que se passe-t-il avec 500 ? Avec 5000 ?
- Est-ce que le processus reste le meme ou faudrait-il faire differemment ?"
-```
-
-### Indicateurs de qualite des reponses
-
-| Qualite | Signal | Action |
-|---------|--------|--------|
-| **Insuffisante** | Moins d'une phrase, "je ne sais pas", adjectif vague | Appliquer les techniques 1 a 8, demander un exemple concret |
-| **Orientee solution** | Contient des termes d'interface ou techniques (bouton, champ, base de donnees) | Appliquer la technique 1 (reformuler en besoin) |
-| **Suffisante** | Contient QUI, QUOI, POURQUOI et un exemple concret | Continuer, noter le niveau de confiance |
-| **Excellente** | Inclut les cas limites, les contraintes et des criteres mesurables | Continuer, marquer comme "Confirme" |
-
----
-
-## ULTRATHINK
-
-Behavioral mode for critical phases (01, 03a):
-
-```
-ULTRATHINK MODE:
-- Consider ALL edge cases
-- Challenge EVERY assumption
-- Anticipate UNEXPRESSED needs
-- Validate completeness before output
-- Apply Elicitation Techniques (see above)
-
-DO NOT:
-- Accept vague answers
-- Skip question categories
-- Assume stakeholder thought of everything
-- Accept solutions without understanding the problem first
-```
-
-**DO NOT invoke** as a skill/tool - it is a thinking mode.

package/templates/skills/business-analyse/_module-loop.md

@@ -1,115 +0,0 @@
-# Business Analysis - Module Loop Protocol (_module-loop.md)
-
-> **Loaded by:** step-03a1-setup, step-03b-ui, step-03c-compile, step-03d-validate
-> **Purpose:** State management and iteration logic for multi-module specification loop + application loop (project mode)
-
----
-
-## State Management (Application Mode — single app)
-
-```json
-{
-  "metadata": {
-    "workflow": {
-      "mode": "application",
-      "moduleOrder": ["Customers", "Products", "Orders", "Invoices"],
-      "currentModuleIndex": 2,
-      "completedModules": ["Customers", "Products"],
-      "currentModule": "Orders"
-    }
-  }
-}
-```
-
-## State Management (Project Mode — multi app)
-
-Project-level feature.json tracks the application loop:
-
-```json
-{
-  "metadata": {
-    "workflow": {
-      "mode": "project",
-      "applicationOrder": ["HumanResources", "EmployeeSelfService"],
-      "currentApplicationIndex": 0,
-      "completedApplications": [],
-      "currentApplication": "HumanResources"
-    }
-  }
-}
-```
-
-Each application-level feature.json tracks its own module loop (same as application mode).
-
-## Module Loop Logic (end of each step-03 iteration)
-
-```
-1. Mark current module as "validated" in application-level feature.json
-2. Add to completedModules[]
-3. IF currentModuleIndex + 1 < moduleOrder.length:
-     currentModuleIndex++
-     currentModule = moduleOrder[currentModuleIndex]
-     Write application-level feature.json
-     Display: "Module {name} complete. Next: {next_name} ({N}/{total})"
-     RE-LOAD: steps/step-03a1-setup.md
-4. ELSE (all modules for current application specified):
-     IF workflow.mode === "project":
-       → Execute APPLICATION LOOP LOGIC (below)
-     ELSE:
-       application.status = "specified"
-       Load: steps/step-04a-collect.md
-```
-
-## Application Loop Logic (project mode only)
-
-> Only applicable when `workflow.mode === "project"` in the project-level feature.json.
-
-```
-1. Mark current application as "specified" in project feature.json
-   ba-writer.updateApplicationStatus(projectId, currentApp, "specified")
-2. Add to completedApplications[]
-   ba-writer.advanceApplicationLoop(projectId)
-3. IF currentApplicationIndex + 1 < applicationOrder.length:
-     Display: "═══ Application {currentApp} complete ({N}/{total}). Next: {nextApp} ═══"
-     Load: steps/step-02-decomposition.md (for next application's module decomposition)
-4. ELSE (all applications specified):
-     Display: "═══ All applications specified! Proceeding to cross-application consolidation... ═══"
-     project.status = "specified"
-     Load: steps/step-04a-collect.md (with cross-application consolidation)
-```
-
-## Context Management During Loop
-
-To prevent context explosion as modules accumulate:
-- **Current module:** Load full module feature.json
-- **Completed modules:** Only load compact summary via `ba-reader.getCompletedModulesSummary()` (max 100 lines)
-- **Master feature.json:** Only read workflow state + application roles
-- **In project mode — completed applications:** Only load compact summary via `ba-reader.getCompletedApplicationsSummary()` (max 50 lines per app)
-
-## Resume After Interruption
-
-### Application Mode (single app)
-```
-1. ba-reader.findApplicationFeature() -> locate application-level feature.json
-2. Read metadata.workflow.currentModuleIndex
-3. IF currentModule has a feature.json with status != "validated":
-     Resume step-03a1-setup for that module
-4. ELSE:
-     Start step-03a1-setup for next module
-```
-
-### Project Mode (multi app)
-```
-1. ba-reader.findProjectFeature() -> locate project-level feature.json
-2. Read metadata.workflow.currentApplicationIndex
-3. Locate current application's feature.json
-4. Read application's metadata.workflow.currentModuleIndex
-5. IF currentModule has a feature.json with status != "validated":
-     Resume step-03a1-setup for that module in that application
-6. ELSE IF application has unspecified modules:
-     Start step-03a1-setup for next module in current application
-7. ELSE IF more applications remain:
-     Start step-02-decomposition for next application
-8. ELSE:
-     All done → Resume step-04a-collect
-```

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

@@ -1,142 +0,0 @@
-# Business Analyse — Canonical Rules
-
-> **This file is the SINGLE SOURCE OF TRUTH for all rules referenced across step files.**
-> Step files MUST reference this file instead of duplicating rules.
-
----
-
-## § ID Naming Convention
-
-All IDs MUST include a module prefix to guarantee application-wide uniqueness.
-The prefix is derived from the module code initials (2-4 chars):
-
-| Module | Prefix |
-|--------|--------|
-| UserManagement | UM |
-| VehicleManagement | VM |
-| PartsInventory | PI |
-| RepairManagement | RM |
-| MaintenanceSchedule | MS |
-| DataSync | DS |
-| Notifications | NT |
-| Dashboard | DB |
-| Orders | OR |
-| Customers | CU |
-
-**Patterns:**
-
-| ID Type | Pattern | Example |
-|---------|---------|---------|
-| Use Case | `UC-{PREFIX}-{NNN}` | UC-RM-001, UC-PI-003 |
-| Business Rule | `BR-{CAT}-{PREFIX}-{NNN}` | BR-VAL-RM-001, BR-CALC-PI-002 |
-| Functional Req | `FR-{PREFIX}-{NNN}` | FR-RM-001 |
-| Objective | `OBJ-{PREFIX}-{NNN}` | OBJ-RM-001 |
-| Acceptance Crit | `AC-{PREFIX}-{NNN}` | AC-RM-001 |
-| Risk | `RISK-{PREFIX}-{NNN}` | RISK-RM-001 |
-
-**NEVER use bare IDs** (UC-001, BR-VAL-001) in multi-module mode.
-
----
-
-## § Schema Conformity
-
-ALL data MUST fit within the defined `feature-schema.json` structure.
-
-- NEVER create custom top-level fields (KPIDefinitions, ChartConfigurations, etc.)
-- Dashboard modules MUST use `specification.dashboards[]` (it exists in the schema).
-- If truly needed, use `specification.extensions: {}` (additionalProperties: true).
-
----
-
-## § Auto-Fix: Wireframe Field Names
-
-Before writing wireframes to feature.json, normalize field names to canonical form.
-
-| Source field | Canonical field | Action |
-|---|---|---|
-| `title` | `screen` | Rename if `screen` absent |
-| `name` | `screen` | Rename if `screen` absent |
-| `ascii` | `mockup` | Rename if `mockup` absent |
-| `content` | `mockup` | Rename if `mockup` absent |
-
-After renaming, store wireframes under the canonical key `specification.uiWireframes`.
-
----
-
-## § Auto-Fix: Entity Attribute Type Inference
-
-When an entity attribute is missing a `type` field, infer it from the attribute name pattern.
-
-| Pattern (attribute name) | Inferred type |
-|---|---|
-| `*name`, `*title`, `*code`, `*description`, `*label`, `*email`, `*phone`, `*address` | `string` |
-| `*Id` (suffix) | `Guid` |
-| `*date*`, `*At` (suffix) | `DateTime` |
-| `is*`, `has*`, `*active`, `*enabled` | `bool` |
-| `*amount`, `*salary`, `*rate`, `*price`, `*total` | `decimal` |
-| `*count`, `*number`, `*order`, `*sort`, `*index` | `int` |
-| (no match — default) | `string` |
-
-**Additional normalization:**
-- If `validation` contains `max {N}`, extract and set `maxLength = N`.
-- If `required` is undefined, default to `true`.
-
----
-
-## § Minimum Counts (Authoritative)
-
-> **These are the AUTHORITATIVE minimums used across step-03d validation and robustness checks.**
-> When in doubt, use these values. They are the strictest (most correct) across all sources.
-
-| Section | Minimum | Blocking | Notes |
-|---|---|---|---|
-| `analysis.entities` | ≥ 2 | YES | Single-entity modules are rare and likely incomplete |
-| Entity attributes (each) | ≥ 3 | YES | Entities with < 3 attributes are incomplete |
-| `analysis.businessRules` | ≥ 4 | YES | Mix of VAL/CALC/WF/SEC/DATA |
-| BR categories | ≥ 2 | YES | Single-category modules likely incomplete |
-| `specification.useCases` | ≥ 6 | YES | CRUD (5) + 1 business-specific minimum |
-| `specification.functionalRequirements` | ≥ 4 | YES | FRs must cover key functionality |
-| UC-FR linkage | Every UC has ≥ 1 FR | YES | Orphan UCs indicate incomplete requirements |
-| `specification.actors` | ≥ 2 | YES | At least 2 roles with permissions |
-| `specification.permissionMatrix.permissions` | ≥ 5 | YES | CRUD (4) + 1 business action |
-| `specification.permissionMatrix.roleAssignments` | ≥ 2 | YES | All roles must have ≥ 1 permission |
-| `specification.sections` | ≥ 2 | YES | list + detail/form minimum |
-| Wireframes | 1 per section | YES | EVERY section MUST have a wireframe |
-| `specification.navigation.entries` | ≥ 1 | YES | Module must be accessible in menu |
-| `specification.seedDataCore` | All 9 arrays present | YES | Missing CORE data breaks deployment |
-| `specification.messages` | ≥ 4 | YES | 1 success, 1 error, 1 warning, 1 info |
-| `specification.validations` | ≥ 1 | YES | Modules need field validation rules |
-| `specification.apiEndpoints` | ≥ 5 | YES | CRUD (5) minimum |
-| `specification.i18nKeys` leaf count | ≥ 42 | YES | Entities, fields, messages, validation, navigation |
-| i18n languages per leaf | 4 (fr, en, it, de) | YES | Missing translations break multi-language |
-| `specification.gherkinScenarios` | ≥ 1 entry (array) | YES | Must be array, not single object |
-| Gherkin scenario count | ≥ 2 | NO (WARNING) | Enables automated testing |
-| `analysis.dataLifecycle` | present | YES | Missing causes BLOCKING errors downstream |
-
-**seedDataCore arrays (9 total):**
-1. `navigationApplications` — required for 1st module, can be `[]` for subsequent
-2. `applicationRoles` — required for 1st module, can be `[]` for subsequent
-3. `navigationModules` — min 1
-4. `navigationSections` — min 1
-5. `navigationResources` — min 1
-6. `navigationTranslations` — min 2 (fr + en)
-7. `permissions` — min 1
-8. `rolePermissions` — min 1
-9. `permissionConstants` — min 1
-
----
-
-## § Format Checks
-
-These format rules apply to ALL modules (including the first). They validate canonical schema compliance.
-
-| Check | Rule | Auto-fix |
-|---|---|---|
-| Gherkin format | `gherkinScenarios` MUST be an **array** `[{feature, scenarios}]`, not a single object | Wrap single object in array |
-| Validation rules | `validations[].rules` MUST be an **array**, not a singular `rule` string | Convert string to `[string]`; rename `rule` → `rules` |
-| Message field | `messages[]` MUST have a `message` field (not only `description`) | Copy `description` → `message` if `message` absent |
-| Wireframe fields | Wireframes MUST use canonical field names (`screen`, `mockup`) | Apply § "Auto-Fix: Wireframe Field Names" table above |
-| Entity attributes | Entities MUST use `attributes[]` (not `fields[]`), no `tableName` or `primaryKey` | Structural error — must be fixed manually |
-| Entity attribute types | ALL attributes MUST have a `type` field | Apply § "Auto-Fix: Entity Attribute Type Inference" table above |
-| Navigation routes | FORBIDDEN: `/module/list` (use `/module`), `/module/detail/:id` (use `/module/:id`) | Rewrite route |
-| Permission paths | Dot-separated lowercase: module-level `{app}.{module}.{action}` (3 segments) or section-level `{app}.{module}.{section}.{action}` (4 segments) | — |

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

@@ -1,34 +0,0 @@
-# Business Analysis - Suggestions & Context7 (_suggestions.md)
-
-> **Loaded by:** step-01-cadrage, step-04-consolidation
-> **Purpose:** Proactive suggestion patterns and Context7 library references
-
----
-
-## Proactive Suggestions
-
-After scope definition in step-01, the skill suggests complementary modules/sections:
-
-1. Analyze feature type and scope from questionnaire answers
-2. Load `patterns/suggestion-catalog.md`
-3. Match against catalog patterns
-4. Present suggestions via AskUserQuestion (accept/reject per suggestion)
-5. Store in feature.json.suggestions[]
-
-Accepted suggestions become candidates for future /business-analyse runs.
-
----
-
-## Context7 (Step 04)
-
-```
-Prompt pattern:
-"use context7 with /facebook/react and /i18next/react-i18next
- to generate {component} following SmartStack patterns"
-```
-
-Libraries:
-- `/facebook/react` - React 19 patterns
-- `/i18next/react-i18next` - Internationalization
-- `/remix-run/react-router` - React Router v7
-- `/lucide-icons/lucide-react` - Icons