# Category 6: Security & Permissions

> **Usage:** Definition of access and restrictions
> **When to load:** ALWAYS (core, minimal)

---

## 6.1 Access

| # | Question | Answer Type |
|---|----------|-------------|
| Q6.1 | Who can VIEW data? | List of roles |
| Q6.2 | Who can CREATE entries? | List of roles |
| Q6.3 | Who can MODIFY? | List of roles |
| Q6.4 | Who can DELETE? | List of roles |

## 6.2 Restrictions

| # | Question | Answer Type |
|---|----------|-------------|
| Q6.5 | Geographic restrictions? | Countries/regions |
| Q6.6 | Time-based restrictions? (hours, periods) | Ranges |
| Q6.7 | Audit trail required? Which actions? | List |
| Q6.8 | Regulatory compliance? (GDPR, etc.) | List of standards |

---

## Platform Permission

**Format:** `business.{application}.{module}.{action}`

| Action | Permission |
|--------|------------|
| Read | `.read` |
| Create | `.create` |
| Update | `.update` |
| Delete | `.delete` |
| Export | `.export` |
| Import | `.import` |
| Admin | `.admin` |

> **⚠️ RBAC ARCHITECTURE: La plateforme gère les rôles et permissions via son système RBAC intégré (HasData).**
>
> - Les rôles identifiés en Q6.1-Q6.4 sont des **ensembles de permissions**, pas des données métier
> - L'accès est contrôlé par des permissions attribuées aux rôles, pas par des propriétés d'entité
> - Ne jamais proposer de créer une entité `Role`, `UserRole`, ou un attribut `User.Role`
> - Le mapping rôle → permissions se fait dans la **Permission Matrix** (step-03c-compile)

## Elicitation Guide

### Follow-ups by Question

| Question | If answer is vague/insufficient | Probe |
|----------|-------------------------------|-------|
| Q6.1-Q6.4 (access) | "Admin peut tout faire" | "Tout = aussi supprimer ? Aussi exporter des données sensibles ? Aussi modifier les données d'un autre tenant ?" |
| Q6.1-Q6.4 (access) | Un seul rôle défini | "Qui ne fait que consulter ? Qui peut modifier mais pas supprimer ? Qui valide les actions critiques ?" |
| Q6.4 (delete) | "Tout le monde peut supprimer" | "Suppression logique ou physique ? Confirmation requise ? Possibilité de restaurer ?" |
| Q6.7 (audit) | "Non" | "Pas besoin de savoir qui a modifié quoi et quand ? Pas de traçabilité réglementaire ?" |
| Q6.8 (compliance) | "Pas concerné" | "Données personnelles (RGPD) ? Données financières (SOX) ? Données de santé (HDS) ?" |

### Anti-patterns to Detect

| Signal | Anti-pattern | Action |
|--------|-------------|--------|
| "Admin = accès total sans restriction" | **Super-admin sans granularité** | Même l'admin devrait avoir des permissions explicites, pas un bypass global |
| Aucune mention de multi-tenant | **Isolation oubliée** | La plateforme est multi-tenant : chaque requête est filtrée par TenantId automatiquement |
| Pas d'audit trail | **Traçabilité absente** | `AuditableEntity` fournit CreatedBy/ModifiedBy. Suffisant ou besoin d'un audit log détaillé ? |
| Permissions uniquement CRUD | **Actions métier non couvertes** | Y a-t-il des actions spécifiques ? (valider, approuver, archiver, publier) → permissions custom |
