@atlashub/smartstack-cli 3.39.0 → 3.41.0

package/templates/skills/business-analyse/questionnaire/11-data-lifecycle.md

@@ -1,59 +1,59 @@
-# Category 11: Data Lifecycle
-
-> **Usage:** Lifecycle, retention, archival and compliance for business data
-> **When to load:** If feature is data-centric or full module
-
----
-
-## 11.1 Data Retention
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q11.1 | How long must data be kept active? | Duration |
-| Q11.2 | Is there a legal retention period? (GDPR, fiscal, regulatory) | Duration + regulation |
-| Q11.3 | What happens after the retention period? | Archive/Purge/Anonymize |
-| Q11.4 | Who decides when data is archived or purged? | Role |
-
-## 11.2 Data States
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q11.5 | What states can a record go through? (draft, active, archived, deleted) | List of states |
-| Q11.6 | Can a deleted record be restored? | Yes/No + conditions |
-| Q11.7 | Should historical versions be kept? (versioning) | Yes/No + depth |
-| Q11.8 | Is there a "freeze" or "lock" state? (immutable after validation) | Yes/No + trigger |
-
----
-
-## Lifecycle Patterns
-
-| Need | Platform Pattern | Impact |
-|------|-------------------|--------|
-| Soft delete | `SoftDeletableEntity` | IsDeleted, DeletedBy, DeletedDate auto-managed |
-| Audit trail | `AuditableEntity` | CreatedBy/Date, ModifiedBy/Date auto-managed |
-| Versioning | Custom `EntityVersion` table | Manual implementation per entity |
-| Archival | Status enum + background job | Scheduled job moves old records |
-| GDPR purge | Anonymization service | Replace personal data with `[REDACTED]` |
-| Immutable after state | Validation in Update command | `if (entity.Status == Locked) throw` |
-
-## Elicitation Guide
-
-### Follow-ups by Question
-
-| Question | If answer is vague/insufficient | Probe |
-|----------|-------------------------------|-------|
-| Q11.1 (retention) | "Toujours" | "Pas de limite légale ? Avec 1M de lignes dans 5 ans, les performances resteront-elles acceptables ?" |
-| Q11.2 (legal) | "Je ne sais pas" | "Données personnelles = RGPD (effacement après demande). Données fiscales = 10 ans. Données RH = 5 ans après départ." |
-| Q11.3 (after retention) | "On supprime" | "Suppression physique ou logique ? Anonymisation des données personnelles ? Export avant suppression ?" |
-| Q11.5 (states) | "Actif ou supprimé" | "Pas de brouillon ? Pas de 'en attente de validation' ? Pas d'archivé consultable mais non modifiable ?" |
-| Q11.6 (restore) | "Non" | "Si un utilisateur supprime par erreur, aucun recours ? Même pas l'admin ?" |
-| Q11.8 (freeze) | "Non" | "Une fois une facture validée, peut-on encore la modifier ? Une commande livrée, peut-on changer son contenu ?" |
-
-### Anti-patterns to Detect
-
-| Signal | Anti-pattern | Action |
-|--------|-------------|--------|
-| "On garde tout pour toujours" | **Pas de stratégie de rétention** | Volume illimité = performance dégradée. Définir une politique d'archivage. |
-| Suppression physique de données personnelles | **Non-conformité RGPD** | RGPD exige la possibilité d'effacer/anonymiser. `SoftDeletableEntity` + anonymisation. |
-| Aucun état intermédiaire | **Lifecycle trop simple** | La plupart des entités métier passent par brouillon → actif → archivé minimum. |
-| Données modifiables sans limite | **Pas d'immutabilité** | Certains documents (factures, contrats) doivent être figés après validation. |
+# Category 11: Data Lifecycle
+
+> **Usage:** Lifecycle, retention, archival and compliance for business data
+> **When to load:** If feature is data-centric or full module
+
+---
+
+## 11.1 Data Retention
+
+| # | Question | Answer Type |
+|---|----------|-------------|
+| Q11.1 | How long must data be kept active? | Duration |
+| Q11.2 | Is there a legal retention period? (GDPR, fiscal, regulatory) | Duration + regulation |
+| Q11.3 | What happens after the retention period? | Archive/Purge/Anonymize |
+| Q11.4 | Who decides when data is archived or purged? | Role |
+
+## 11.2 Data States
+
+| # | Question | Answer Type |
+|---|----------|-------------|
+| Q11.5 | What states can a record go through? (draft, active, archived, deleted) | List of states |
+| Q11.6 | Can a deleted record be restored? | Yes/No + conditions |
+| Q11.7 | Should historical versions be kept? (versioning) | Yes/No + depth |
+| Q11.8 | Is there a "freeze" or "lock" state? (immutable after validation) | Yes/No + trigger |
+
+---
+
+## Lifecycle Patterns
+
+| Need | Platform Pattern | Impact |
+|------|-------------------|--------|
+| Soft delete | `SoftDeletableEntity` | IsDeleted, DeletedBy, DeletedDate auto-managed |
+| Audit trail | `AuditableEntity` | CreatedBy/Date, ModifiedBy/Date auto-managed |
+| Versioning | Custom `EntityVersion` table | Manual implementation per entity |
+| Archival | Status enum + background job | Scheduled job moves old records |
+| GDPR purge | Anonymization service | Replace personal data with `[REDACTED]` |
+| Immutable after state | Validation in Update command | `if (entity.Status == Locked) throw` |
+
+## Elicitation Guide
+
+### Follow-ups by Question
+
+| Question | If answer is vague/insufficient | Probe |
+|----------|-------------------------------|-------|
+| Q11.1 (retention) | "Toujours" | "Pas de limite légale ? Avec 1M de lignes dans 5 ans, les performances resteront-elles acceptables ?" |
+| Q11.2 (legal) | "Je ne sais pas" | "Données personnelles = RGPD (effacement après demande). Données fiscales = 10 ans. Données RH = 5 ans après départ." |
+| Q11.3 (after retention) | "On supprime" | "Suppression physique ou logique ? Anonymisation des données personnelles ? Export avant suppression ?" |
+| Q11.5 (states) | "Actif ou supprimé" | "Pas de brouillon ? Pas de 'en attente de validation' ? Pas d'archivé consultable mais non modifiable ?" |
+| Q11.6 (restore) | "Non" | "Si un utilisateur supprime par erreur, aucun recours ? Même pas l'admin ?" |
+| Q11.8 (freeze) | "Non" | "Une fois une facture validée, peut-on encore la modifier ? Une commande livrée, peut-on changer son contenu ?" |
+
+### Anti-patterns to Detect
+
+| Signal | Anti-pattern | Action |
+|--------|-------------|--------|
+| "On garde tout pour toujours" | **Pas de stratégie de rétention** | Volume illimité = performance dégradée. Définir une politique d'archivage. |
+| Suppression physique de données personnelles | **Non-conformité RGPD** | RGPD exige la possibilité d'effacer/anonymiser. `SoftDeletableEntity` + anonymisation. |
+| Aucun état intermédiaire | **Lifecycle trop simple** | La plupart des entités métier passent par brouillon → actif → archivé minimum. |
+| Données modifiables sans limite | **Pas d'immutabilité** | Certains documents (factures, contrats) doivent être figés après validation. |

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

@@ -1,58 +1,58 @@
-# Category 12: Migration & Transition
-
-> **Usage:** Plan transition from AS-IS to TO-BE, handle existing data
-> **When to load:** ALWAYS for new modules (not enhancements)
-
----
-
-## 12.1 Existing Data
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q12.1 | Is there existing data to migrate? | Yes/No + source |
-| Q12.2 | What format is the existing data in? | Excel/CSV/DB/API/Manual |
-| Q12.3 | What volume of data to migrate? | Estimation |
-| Q12.4 | What data quality issues exist? (duplicates, missing fields, inconsistencies) | List |
-
-## 12.2 Transition Plan
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q12.5 | Is there a coexistence period? (old + new system in parallel) | Duration |
-| Q12.6 | What is the cutover strategy? | Big-bang / Progressive / Parallel |
-| Q12.7 | Who validates the migrated data? | Role |
-| Q12.8 | What is the rollback plan if migration fails? | Strategy |
-
----
-
-## Migration Patterns
-
-| Need | Pattern | Tool |
-|------|---------|------|
-| CSV/Excel import | Background job + FluentValidation | Hangfire + custom importer |
-| Database migration | EF Core seed / SQL script | `dotnet ef` + seed data |
-| API import | HttpClient batch | Background job + Polly |
-| Data cleanup | Validation pipeline | FluentValidation + reporting |
-| Progressive rollout | Feature flag | LaunchDarkly / custom config |
-
-## Elicitation Guide
-
-### Follow-ups by Question
-
-| Question | If answer is vague/insufficient | Probe |
-|----------|-------------------------------|-------|
-| Q12.1 (existing data) | "Oui" sans détail | "Dans quel outil ? Excel, ERP, autre DB ? Combien de fichiers/tables ? Qui y a accès ?" |
-| Q12.2 (format) | "Excel" | "Un seul fichier ou plusieurs ? Avec des onglets ? Des macros ? Des formules ? Quelles colonnes ?" |
-| Q12.4 (quality) | "C'est propre" | "Pas de doublons ? Pas de champs vides obligatoires ? Pas de formats incohérents (dates, montants) ?" |
-| Q12.5 (coexistence) | "Non" | "Les utilisateurs passent directement au nouveau système ? Pas de période d'apprentissage en parallèle ?" |
-| Q12.6 (cutover) | "On verra" | "Big-bang (bascule à date fixe) ou progressif (équipe par équipe) ? Si progressif, quels groupes en premier ?" |
-| Q12.8 (rollback) | "Pas prévu" | "Si l'import échoue ou corrompt des données, comment revenir en arrière ? Backup avant migration ?" |
-
-### Anti-patterns to Detect
-
-| Signal | Anti-pattern | Action |
-|--------|-------------|--------|
-| "On saisira tout à la main" | **Migration non planifiée** | Si > 100 enregistrements, l'import automatisé est indispensable |
-| Pas de validation post-migration | **Données non vérifiées** | Prévoir un rapport de migration : importés / rejetés / à corriger |
-| Aucun rollback plan | **Risque de perte de données** | Toujours faire un backup avant migration + possibilité de rollback |
-| "On migrera plus tard" | **Dette technique** | Si la migration est nécessaire, la planifier dès le départ même si simplifiée |
+# Category 12: Migration & Transition
+
+> **Usage:** Plan transition from AS-IS to TO-BE, handle existing data
+> **When to load:** ALWAYS for new modules (not enhancements)
+
+---
+
+## 12.1 Existing Data
+
+| # | Question | Answer Type |
+|---|----------|-------------|
+| Q12.1 | Is there existing data to migrate? | Yes/No + source |
+| Q12.2 | What format is the existing data in? | Excel/CSV/DB/API/Manual |
+| Q12.3 | What volume of data to migrate? | Estimation |
+| Q12.4 | What data quality issues exist? (duplicates, missing fields, inconsistencies) | List |
+
+## 12.2 Transition Plan
+
+| # | Question | Answer Type |
+|---|----------|-------------|
+| Q12.5 | Is there a coexistence period? (old + new system in parallel) | Duration |
+| Q12.6 | What is the cutover strategy? | Big-bang / Progressive / Parallel |
+| Q12.7 | Who validates the migrated data? | Role |
+| Q12.8 | What is the rollback plan if migration fails? | Strategy |
+
+---
+
+## Migration Patterns
+
+| Need | Pattern | Tool |
+|------|---------|------|
+| CSV/Excel import | Background job + FluentValidation | Hangfire + custom importer |
+| Database migration | EF Core seed / SQL script | `dotnet ef` + seed data |
+| API import | HttpClient batch | Background job + Polly |
+| Data cleanup | Validation pipeline | FluentValidation + reporting |
+| Progressive rollout | Feature flag | LaunchDarkly / custom config |
+
+## Elicitation Guide
+
+### Follow-ups by Question
+
+| Question | If answer is vague/insufficient | Probe |
+|----------|-------------------------------|-------|
+| Q12.1 (existing data) | "Oui" sans détail | "Dans quel outil ? Excel, ERP, autre DB ? Combien de fichiers/tables ? Qui y a accès ?" |
+| Q12.2 (format) | "Excel" | "Un seul fichier ou plusieurs ? Avec des onglets ? Des macros ? Des formules ? Quelles colonnes ?" |
+| Q12.4 (quality) | "C'est propre" | "Pas de doublons ? Pas de champs vides obligatoires ? Pas de formats incohérents (dates, montants) ?" |
+| Q12.5 (coexistence) | "Non" | "Les utilisateurs passent directement au nouveau système ? Pas de période d'apprentissage en parallèle ?" |
+| Q12.6 (cutover) | "On verra" | "Big-bang (bascule à date fixe) ou progressif (équipe par équipe) ? Si progressif, quels groupes en premier ?" |
+| Q12.8 (rollback) | "Pas prévu" | "Si l'import échoue ou corrompt des données, comment revenir en arrière ? Backup avant migration ?" |
+
+### Anti-patterns to Detect
+
+| Signal | Anti-pattern | Action |
+|--------|-------------|--------|
+| "On saisira tout à la main" | **Migration non planifiée** | Si > 100 enregistrements, l'import automatisé est indispensable |
+| Pas de validation post-migration | **Données non vérifiées** | Prévoir un rapport de migration : importés / rejetés / à corriger |
+| Aucun rollback plan | **Risque de perte de données** | Toujours faire un backup avant migration + possibilité de rollback |
+| "On migrera plus tard" | **Dette technique** | Si la migration est nécessaire, la planifier dès le départ même si simplifiée |

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

@@ -1,69 +1,69 @@
-# Category 13: Cross-Module Impact
-
-> **Usage:** Analyze impact on existing modules and shared dependencies
-> **When to load:** ALWAYS for new modules (not enhancements)
-
----
-
-## 13.1 Existing Module Dependencies
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q13.1 | Which existing modules does this new module interact with? | List |
-| Q13.2 | What data is shared between modules? (entities, lookup tables) | Per module |
-| Q13.3 | Are there existing entities this module will reference? (FK relationships) | List |
-| Q13.4 | Will this module produce events that other modules consume? | List of events |
-
-## 13.2 Impact Assessment
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q13.5 | Will existing modules need modifications to support this new module? | List of changes |
-| Q13.6 | Are there shared UI components or navigation changes? | List |
-| Q13.7 | Will this module affect existing permissions/roles? | Yes/No + detail |
-| Q13.8 | Is there a risk of data model conflicts? (same entity modified by 2 modules) | Risk assessment |
-
----
-
-## Cross-Module Patterns
-
-| Need | Pattern | Example |
-|------|---------|---------|
-| Reference another entity | Navigation property + FK | `Order.ClientId → Client` |
-| Shared lookup data | Shared entity in Domain | `Status`, `Category` entities |
-| Event notification | MediatR notification | `OrderCreatedNotification` |
-| Cross-module query | Read-only DTO from other module | `IClientQueryService` |
-| Navigation link | Menu entry in NavRoute | `business/{app}/{module}` |
-| Shared permission | Permission hierarchy | `{app}.*` covers all modules |
-
-## Elicitation Guide
-
-### Follow-ups by Question
-
-| Question | If answer is vague/insufficient | Probe |
-|----------|-------------------------------|-------|
-| Q13.1 (interactions) | "Aucun" | "Ce module est totalement isolé ? Pas de lien avec des clients, produits, utilisateurs d'autres modules ?" |
-| Q13.2 (shared data) | "Je ne sais pas" | Use `{codebase_context}` from pre-research: "J'ai trouvé les entités {list} dans {app}. Ce module a-t-il besoin de les référencer ?" |
-| Q13.3 (FK references) | Vague | "Une {entity} de ce module appartient-elle à un {existing_entity} ? (ex: OrderLine → Product)" |
-| Q13.4 (events) | "Non" | "Quand un {entity} est créé/modifié/supprimé, faut-il notifier un autre module ? Mettre à jour un compteur ?" |
-| Q13.5 (modifications) | "Non" | "Pas de nouvelle colonne dans le menu ? Pas de lien depuis une page existante vers ce nouveau module ?" |
-| Q13.8 (conflicts) | "Pas de risque" | "Deux modules modifient-ils la même entité ? (ex: module A crée un Client, module B le modifie)" |
-
-### Anti-patterns to Detect
-
-| Signal | Anti-pattern | Action |
-|--------|-------------|--------|
-| Module totalement isolé | **Silo de données** | Rare qu'un module métier n'ait aucune connexion. Vérifier avec le codebase context. |
-| Duplication d'entité existante | **Entité dupliquée** | Si `Client` existe déjà, ne pas créer `Customer`. Référencer l'existant. |
-| Modification d'entité d'un autre module | **Couplage fort** | Utiliser des événements (MediatR) plutôt que des modifications directes. |
-| Aucune mention de navigation | **Module orphelin dans l'UI** | Le module doit apparaître dans le menu de l'application (NavRoute). |
-
-### Using Pre-Research Context
-
-> **IMPORTANT:** This category benefits most from step 3 (Pre-Research).
->
-> Use `{codebase_context}` to:
-> - **List existing entities** and ask the user which ones this module references
-> - **Show existing modules** and ask about interactions
-> - **Detect potential duplicates** (entity names similar to what the user describes)
-> - **Propose event patterns** based on existing MediatR notifications
+# Category 13: Cross-Module Impact
+
+> **Usage:** Analyze impact on existing modules and shared dependencies
+> **When to load:** ALWAYS for new modules (not enhancements)
+
+---
+
+## 13.1 Existing Module Dependencies
+
+| # | Question | Answer Type |
+|---|----------|-------------|
+| Q13.1 | Which existing modules does this new module interact with? | List |
+| Q13.2 | What data is shared between modules? (entities, lookup tables) | Per module |
+| Q13.3 | Are there existing entities this module will reference? (FK relationships) | List |
+| Q13.4 | Will this module produce events that other modules consume? | List of events |
+
+## 13.2 Impact Assessment
+
+| # | Question | Answer Type |
+|---|----------|-------------|
+| Q13.5 | Will existing modules need modifications to support this new module? | List of changes |
+| Q13.6 | Are there shared UI components or navigation changes? | List |
+| Q13.7 | Will this module affect existing permissions/roles? | Yes/No + detail |
+| Q13.8 | Is there a risk of data model conflicts? (same entity modified by 2 modules) | Risk assessment |
+
+---
+
+## Cross-Module Patterns
+
+| Need | Pattern | Example |
+|------|---------|---------|
+| Reference another entity | Navigation property + FK | `Order.ClientId → Client` |
+| Shared lookup data | Shared entity in Domain | `Status`, `Category` entities |
+| Event notification | MediatR notification | `OrderCreatedNotification` |
+| Cross-module query | Read-only DTO from other module | `IClientQueryService` |
+| Navigation link | Menu entry in NavRoute | `business/{app}/{module}` |
+| Shared permission | Permission hierarchy | `{app}.*` covers all modules |
+
+## Elicitation Guide
+
+### Follow-ups by Question
+
+| Question | If answer is vague/insufficient | Probe |
+|----------|-------------------------------|-------|
+| Q13.1 (interactions) | "Aucun" | "Ce module est totalement isolé ? Pas de lien avec des clients, produits, utilisateurs d'autres modules ?" |
+| Q13.2 (shared data) | "Je ne sais pas" | Use `{codebase_context}` from pre-research: "J'ai trouvé les entités {list} dans {app}. Ce module a-t-il besoin de les référencer ?" |
+| Q13.3 (FK references) | Vague | "Une {entity} de ce module appartient-elle à un {existing_entity} ? (ex: OrderLine → Product)" |
+| Q13.4 (events) | "Non" | "Quand un {entity} est créé/modifié/supprimé, faut-il notifier un autre module ? Mettre à jour un compteur ?" |
+| Q13.5 (modifications) | "Non" | "Pas de nouvelle colonne dans le menu ? Pas de lien depuis une page existante vers ce nouveau module ?" |
+| Q13.8 (conflicts) | "Pas de risque" | "Deux modules modifient-ils la même entité ? (ex: module A crée un Client, module B le modifie)" |
+
+### Anti-patterns to Detect
+
+| Signal | Anti-pattern | Action |
+|--------|-------------|--------|
+| Module totalement isolé | **Silo de données** | Rare qu'un module métier n'ait aucune connexion. Vérifier avec le codebase context. |
+| Duplication d'entité existante | **Entité dupliquée** | Si `Client` existe déjà, ne pas créer `Customer`. Référencer l'existant. |
+| Modification d'entité d'un autre module | **Couplage fort** | Utiliser des événements (MediatR) plutôt que des modifications directes. |
+| Aucune mention de navigation | **Module orphelin dans l'UI** | Le module doit apparaître dans le menu de l'application (NavRoute). |
+
+### Using Pre-Research Context
+
+> **IMPORTANT:** This category benefits most from step 3 (Pre-Research).
+>
+> Use `{codebase_context}` to:
+> - **List existing entities** and ask the user which ones this module references
+> - **Show existing modules** and ask about interactions
+> - **Detect potential duplicates** (entity names similar to what the user describes)
+> - **Propose event patterns** based on existing MediatR notifications