docs: rationalisation post-0.1.0 + bilan (depuis develop).

Co-authored-by: Cursor <cursoragent@cursor.com>

docs/00_INDEX.md

@@ -1,17 +1,17 @@
 # Index de la documentation — P'titsPas
 
-Index de navigation du dépôt. Dernière révision : **septembre 2026** (CDC V1.4 + SRS users #117).
+Index de navigation du dépôt. Dernière révision : **septembre 2026** (clôture doc 0.1.0).
 
 ## Produit & versions
 
 | Doc | Contenu |
 |-----|---------|
-| [01 — Cahier des charges V1.4](./01_CAHIER-DES-CHARGES.md) | CDC **complet** (cible) ; gestion utilisateurs alignée `v0.1.0` |
-| [12 — SRS gestion utilisateurs](./12_SRS-GESTION-UTILISATEURS.md) | Spécification **technique** du domaine users / dossiers |
+| [01 — Cahier des charges](./01_CAHIER-DES-CHARGES.md) | CDC actuel (V1.3) — amendement via **#117** |
+| [EVOLUTIONS_CDC.md](./EVOLUTIONS_CDC.md) | Écarts CDC → app (intrant amendement) |
 | [05 — Versions & milestones](./05_VERSIONS-ET-MILESTONES.md) | Semver Gitea + bilans |
-| [29 — Bilan version 0.1.0](./29_BILAN-VERSION-0.1.0.md) | Tickets livrés 0.1.0 |
+| [29 — Bilan version 0.1.0](./29_BILAN-VERSION-0.1.0.md) | Tickets livrés 0.1.0 + thèmes |
 | [04 — Roadmap générale](./04_ROADMAP-GENERALE.md) | Vision phases long terme |
-| [28 — Évolution famille / responsables](./28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md) | Limites modèle foyer / contournements |
+| [28 — Évolution famille / responsables](./28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md) | Modèle dossier / foyer |
 
 ## Architecture & infra
 
@@ -28,7 +28,7 @@ Index de navigation du dépôt. Dernière révision : **septembre 2026** (CDC V1
 
 | Doc | Contenu |
 |-----|---------|
-| [20 — Workflow création de compte](./20_WORKFLOW-CREATION-COMPTE.md) | Inscription / validation (détail historique) |
+| [20 — Workflow création de compte](./20_WORKFLOW-CREATION-COMPTE.md) | Inscription / validation |
 | [juridique/](./juridique/README.md) | CGU / CGC / privacy + [22 technique](./juridique/22_DOCUMENTS-LEGAUX.md) |
 | [CHARTE_GRAPHIQUE.md](./CHARTE_GRAPHIQUE.md) | Charte UI |
 
@@ -36,7 +36,7 @@ Index de navigation du dépôt. Dernière révision : **septembre 2026** (CDC V1
 
 | Doc | Contenu |
 |-----|---------|
-| [23 — Suivi tickets](./23_SUIVI-TICKETS.md) | Pointeur Gitea |
+| [23 — Suivi tickets](./23_SUIVI-TICKETS.md) | Pointeur Gitea (plus de liste figée) |
 | [24 — Décisions projet](./24_DECISIONS-PROJET.md) | ADR / décisions |
 | [26 — API Gitea](./26_GITEA-API.md) | Issues, PR, milestones |
 | [27 — Briefing frontend](./27_BRIEFING-FRONTEND.md) | Accès Git, priorités |
@@ -52,7 +52,7 @@ Index de navigation du dépôt. Dernière révision : **septembre 2026** (CDC V1
 | Emplacement | Usage |
 |-------------|--------|
 | [archive/](./archive/README.md) | Obsolete / temporaires |
-| [archive/obsolete/](./archive/obsolete/) | CDC V1.3, EVOLUTIONS_CDC, SuperNounou, listes figées |
+| [archive/obsolete/](./archive/obsolete/) | CDC SuperNounou, ancienne liste tickets, backlog Phase 2 figé, notes ponctuelles |
 
 ## Données de test
 

docs/01_CAHIER-DES-CHARGES.md

@@ -1,19 +1,14 @@
 ---
 title: "P'titsPas - Cahier des Charges Fonctionnel"
 author: "Julien MARTIN"
-date: "Septembre 2026"
-version: "v1.4"
+date: "Novembre 2025"
+version: "v1.3"
 ---
 
 # P'titsPas – Cahier des Charges Fonctionnel
 
 > **Objet :** Définir le périmètre fonctionnel, les rôles utilisateurs, les processus métiers et les exigences techniques de la plateforme P'titsPas, destinée à accompagner les collectivités locales dans la gestion de la garde d’enfants.
 
-> **V1.4 (sept. 2026)** — Mise à jour de la **gestion des utilisateurs / dossiers / validation** pour coller au livré produit **`v0.1.0`**. Le reste du CDC (contrats, messagerie, agenda, paie, recherche AM, etc.) est **conservé** comme cible fonctionnelle.  
-> Détail technique du domaine utilisateurs : [12_SRS-GESTION-UTILISATEURS.md](./12_SRS-GESTION-UTILISATEURS.md).  
-> Bilan tickets `v0.1.0` : [29_BILAN-VERSION-0.1.0.md](./29_BILAN-VERSION-0.1.0.md).  
-> Archive V1.3 : [archive/obsolete/01_CAHIER-DES-CHARGES-v1.3.md](./archive/obsolete/01_CAHIER-DES-CHARGES-v1.3.md).
-
 ---
 
 ## Historique des versions
@@ -24,7 +19,6 @@ version: "v1.4"
 | 1.1     | 24/04/2025 | Julien MARTIN  | Ajouts : gestion multi-enfants, fin de contrat, tableau de bord étendu |
 | 1.2     | 26/05/2025 | Julien MARTIN  | Remplacement de "SuperNounou" par "P'titsPas" |
 | 1.3     | 24/11/2025 | Julien MARTIN  | Correction : retrait photo de profil parent (section 3.1.1) |
-| **1.4** | **15/09/2026** | Julien MARTIN  | **Gestion utilisateurs** alignée `v0.1.0` (dossiers, validation/refus/reprise, fiches staff, suppressions, retrait naissance multiple & SMS) ; reste du CDC inchangé en cible |
 
 ---
 
@@ -48,8 +42,6 @@ version: "v1.4"
 ### 3.4 Création d’un administrateur  
 ### 3.5 Fiche enfant  
 ### 3.6 Authentification et sécurité  
-### 3.7 Numéro de dossier, validation, refus et reprise  
-### 3.8 Suppressions (vue métier)  
 
 ## 4. Tableaux de bord  
 ### 4.1 Vue d’ensemble  
@@ -68,15 +60,15 @@ version: "v1.4"
 #### 4.3.5 Heures supplémentaires  
 #### 4.3.6 Messagerie  
 ### 4.4 Tableau de bord des gestionnaires  
-#### 4.4.1 Dossiers à valider  
-#### 4.4.2 Gestion des utilisateurs (partagée)  
+#### 4.4.1 Comptes à valider  
+#### 4.4.2 Liste des utilisateurs  
 #### 4.4.3 Contrats  
 #### 4.4.4 Messagerie  
 #### 4.4.5 Événements RPE  
 #### 4.4.6 Alertes  
 ### 4.5 Tableau de bord des administrateurs  
 #### 4.5.1 Menu Profil  
-#### 4.5.2 Gestion des utilisateurs (partagée admin + gestionnaire)  
+#### 4.5.2 Gestion des utilisateurs  
 #### 4.5.3 Gestion des enfants  
 #### 4.5.4 Paramètres de la plateforme  
 #### 4.5.5 Statistiques et supervision  
@@ -201,23 +193,18 @@ Les assistantes maternelles peuvent :
 
 Les gestionnaires (responsables de relais petite enfance) disposent d’un tableau de bord de supervision. Ils peuvent :
 
-- Valider ou refuser les **dossiers** (inscriptions parent / AM) et accompagner les reprises
-- Gérer les usagers (fiches parent / AM / enfant, rattachements, dossiers) — socle partagé avec l’admin
-- Suivre les mises en relation et les contrats (cible CDC)
-- Organiser des événements ou des rendez-vous (cible CDC)
-- Gérer les conflits ou les fins de contrat (cible CDC)
+- Valider ou rejeter les demandes de création de compte
+- Suivre les mises en relation et les contrats
+- Organiser des événements ou des rendez-vous
+- Gérer les conflits ou les fins de contrat
 - Lancer des sondages ou modérer un blog RPE (si activé)
 - Voir les historiques et statistiques liés à leur périmètre
 
-Ils **ne créent pas** les comptes gestionnaire / administrateur (réservé à l’admin).
-
 ### 2.1.4 Administrateurs
 
 Les administrateurs sont les représentants techniques et institutionnels de la collectivité (DSI ou agents désignés). Ils peuvent :
 
-- Tout ce que peut faire un gestionnaire sur les usagers / dossiers
-- Créer ou supprimer des comptes **staff** (gestionnaires, administrateurs) selon garde-fous
-- Créer ou supprimer des comptes usagers (parents, AM, enfants) selon droits
+- Créer ou supprimer des comptes (gestionnaires, parents, assistantes maternelles)
 - Personnaliser l’interface (logo, couleurs, nom de la ville)
 - Activer ou désactiver des modules complémentaires
 - Consulter les statistiques d’usage
@@ -258,15 +245,12 @@ Le parcours de création d’un compte parent s’effectue en plusieurs étapes
 **Note** : Le parent 2 ne définit **pas** de mot de passe lors de l'inscription. Il recevra un email avec un lien pour créer son mot de passe après validation du gestionnaire. Cette approche est particulièrement adaptée aux situations de parents séparés ou divorcés où la communication peut être difficile.
 
 ### 3.1.3 Informations sur l'enfant
-- Un ou **plusieurs** enfants peuvent être ajoutés
 - Prénom (facultatif si enfant à naître)
 - Nom (hérité des parents)
-- Genre (H / F / Autre) — obligatoire
+- Genre (H / F) - obligatoire
 - Date de naissance ou **date prévisionnelle de naissance** (si l'enfant n'est pas encore né, un switch modifie le label)
-- Photo (selon règles d’inscription) et **consentement photo**
-- Rattachement automatique au parent 1 et au parent 2 s’il est renseigné
-
-**Note V1.4** : il n’existe **pas** de champ « naissance multiple / jumeaux » (retiré du produit).
+- Photo obligatoire si l'enfant est né
+- Rattachement automatique aux deux parents
 
 ### 3.1.4 Présentation du dossier
 - Zone de texte libre permettant aux parents de décrire leur situation
@@ -281,12 +265,10 @@ Le parcours de création d’un compte parent s’effectue en plusieurs étapes
 ### 3.1.6 Récapitulatif et validation
 - Résumé des données saisies
 - Vérification, puis envoi de la demande
-- Attribution d’un **numéro de dossier** (format type AAAA-NNNNNN)
 - Les comptes parent sont soumis à validation par un gestionnaire avant activation
-- Une fois validé, chaque parent (Parent 1 et Parent 2 si renseigné) reçoit un **e-mail** contenant un lien pour créer son mot de passe
-- Le lien est valable pendant une durée limitée (jeton à usage unique)
+- Une fois validé, chaque parent (Parent 1 et Parent 2 si renseigné) reçoit un e-mail ou un SMS contenant un lien pour créer son mot de passe
+- Le lien est valable pendant 7 jours
 - Une fois le mot de passe créé, le parent peut se connecter à son espace
-- En cas de **refus**, le dossier n’est pas supprimé : l’usager peut **reprendre** sa demande (lien e-mail ou numéro de dossier) — voir §3.7
 
 ## 3.2 Création de compte assistante maternelle
 
@@ -316,7 +298,7 @@ Ce parcours est divisé en deux panneaux.
 - Champ libre : message à destination du gestionnaire
 - Permet de justifier une demande ou d’ajouter des précisions
 
-### 3.2.4 – Acceptation des CGU
+### 3.1.4 – Acceptation des CGU
 - Les utilisateurs doivent cocher la case  
   « J’ai lu et j’accepte les Conditions Générales d’Utilisation et la Politique de confidentialité ».  
 - Un lien direct ouvre la version PDF des CGU.  
@@ -325,26 +307,23 @@ Ce parcours est divisé en deux panneaux.
 ### 3.2.5 Récapitulatif et validation
 - Résumé des données saisies
 - Vérification, puis envoi de la demande
-- Attribution d’un **numéro de dossier**
 - Validation par un gestionnaire requise avant activation
-- Une fois validé, l'assistante maternelle reçoit un **e-mail** contenant un lien pour créer son mot de passe
-- Le lien est valable pendant une durée limitée (jeton à usage unique)
+- Une fois validé, l'assistante maternelle reçoit un e-mail ou un SMS contenant un lien pour créer son mot de passe
+- Le lien est valable pendant 7 jours
 - Une fois le mot de passe créé, l'assistante maternelle peut se connecter à son espace
-- En cas de **refus** : reprise possible — voir §3.7
 
 ## 3.3 Création d’un gestionnaire
 
-- Réalisée par un **administrateur** (ou super administrateur) — un gestionnaire ne crée pas de comptes staff
-- Champs : nom, prénom, e-mail, téléphone, mot de passe, **relais principal** (optionnel)
-- Le mot de passe peut être modifié à la première connexion si la politique l’exige
-- Formulaire unifié de création / édition (même présentation que pour les administrateurs)
+- Réalisée par un administrateur
+- Champs obligatoires : nom, prénom, adresse e-mail, mot de passe
+- Affectation à un ou plusieurs relais petite enfance
+- Le mot de passe doit être modifié lors de la première connexion
 
 ## 3.4 Création d’un administrateur
 
-- Seuls les **administrateurs** (et super administrateur) peuvent créer de nouveaux comptes administrateurs
-- Champs : nom, prénom, e-mail, téléphone, mot de passe (pas de relais)
-- Les droits sont équivalents entre administrateurs (le **super administrateur** est un compte d’installation non supprimable)
-- Obligation de changer le mot de passe à la première connexion si exigé
+- Seuls les administrateurs existants peuvent créer de nouveaux comptes administrateurs
+- Les droits sont équivalents (possibilité de restreindre par périmètre dans une version multi-mairies)
+- Obligation de changer le mot de passe à la première connexion
 
 ## 3.5 Fiche enfant
 
@@ -352,68 +331,22 @@ Chaque enfant est représenté par une fiche :
 
 - Prénom (facultatif si enfant à naître)
 - Nom
-- Genre (H / F / Autre) — obligatoire
+- Genre (H / F) - obligatoire
 - Date de naissance ou date prévisionnelle
-- Photo et consentement photo selon configuration (consentement tracé)
-- Statut : à naître / actif / scolarisé (évolutions de libellés possibles ultérieurement)
-- Responsables (parents) rattachés — liens vers les fiches parent
-- Assistante maternelle de rattachement (le cas échéant)
-
-**Note V1.4** : pas d’indication « jumeaux / triplés » comme champ dédié.
-
-Les fiches enfants sont :
-- Accessibles depuis la fiche parent, la fiche AM, l’onglet **Enfants** du dashboard staff
-- Créables par le staff pour un foyer existant
-- Partagées entre les responsables rattachés
+- Photo (obligatoire si l'enfant est né ET si l'option *Photo obligatoire* est activée)  
+- Consentement photo enregistré : valeur booléenne + horodatage liés à l'accord donné par le parent
+- Statut : à naître / actif / scolarisé
+- Indication possible : jumeaux, triplés, etc.
+- Possibilité de rattacher un enfant à plusieurs parents (garde alternée)
 
 ## 3.6 Authentification et sécurité
 
-- Authentification par e-mail + mot de passe
-- Comptes **en attente** ou **suspendus** : connexion refusée
-- Les gestionnaires et administrateurs doivent modifier leur mot de passe à la première connexion (si exigé)
-- **Création de mot de passe** post-validation : lien e-mail (jeton TTL, usage unique)
-- **Mot de passe oublié** : parcours distinct (demande → e-mail → réinitialisation)
-- Pas d’envoi de lien de mot de passe par SMS (canal **e-mail** uniquement)
+- Tous les comptes utilisent une combinaison adresse e-mail + mot de passe
+- Les gestionnaires et administrateurs doivent modifier leur mot de passe à la première connexion
+- Des mécanismes de récupération sont disponibles en cas de perte
 
 Un lien direct vers les **Mentions légales** et la **Politique de confidentialité** est accessible en permanence depuis le pied de page, y compris avant la connexion.
 
-## 3.7 Numéro de dossier, validation, refus et reprise
-
-### Numéro de dossier
-- Format type **AAAA-NNNNNN**
-- Affiché dans les listes staff, les modales et les e-mails concernés
-- Sert de clé métier pour validation, refus et reprise
-
-### Validation
-- Le staff (gestionnaire / administrateur) examine le dossier (wizard de revue)
-- Action **Valider** : activation du circuit comptes + e-mails de création de mot de passe
-
-### Refus
-- Action **Refuser** : le dossier est refusé **sans suppression** des données
-- L’usager est informé par e-mail et peut reprendre sa demande
-
-### Reprise
-- Via le **lien** reçu par e-mail, ou depuis l’écran de connexion avec le **numéro de dossier**
-- Formulaire prérempli / correction des informations
-- Nouvelle soumission → retour en file « à valider »
-
-### Création et édition de dossiers par le staff
-- En plus de l’inscription publique, le staff peut **créer** un dossier famille ou AM (wizard)
-- Le staff peut **éditer** un dossier existant (y compris ajout d’un 2ᵉ parent pour une famille mono-parent)
-
-## 3.8 Suppressions (vue métier)
-
-Sous réserve des droits (détail technique : [SRS gestion utilisateurs](./12_SRS-GESTION-UTILISATEURS.md)) :
-
-| Cible | Principe |
-|-------|----------|
-| Parent, AM, enfant, dossier | Gestionnaire, administrateur, super admin — avec confirmation |
-| Gestionnaire | Administrateur / super admin uniquement |
-| Administrateur | Admin / super admin, hors soi-même, hors cible super admin ; garde-fou sur le dernier administrateur |
-| Super administrateur | Non supprimable |
-
-Un gestionnaire ne peut pas supprimer **son propre** compte.
-
 # 4. Tableaux de bord
 
 Chaque rôle utilisateur dispose d’un tableau de bord personnalisé, adapté à ses fonctions dans la plateforme. Ces interfaces sont pensées pour être lisibles, fonctionnelles et évolutives.
@@ -424,8 +357,8 @@ Chaque rôle utilisateur dispose d’un tableau de bord personnalisé, adapté
 |------------------------|-------------------------------------------------------------------|
 | Parents                | Recherche d'assistante maternelle, gestion des enfants, contrat, agenda         |
 | Assistantes maternelles| Dossiers reçus, enfants accueillis, heures sup, agenda, messagerie|
-| Gestionnaires          | Dossiers à valider, gestion utilisateurs/enfants (partagée), contrats, messagerie, événements RPE |
-| Administrateurs        | Paramètres globaux, même gestion utilisateurs (droits staff élargis), statistiques        |
+| Gestionnaires          | Validation de comptes, contrats, messagerie, événements RPE       |
+| Administrateurs        | Paramètres globaux, gestion des utilisateurs, statistiques        |
 
 Les tableaux de bord intègrent :
 - Une **barre de navigation supérieure** (liens de navigation rapide)
@@ -569,24 +502,17 @@ L’assistante maternelle accède à une interface dédiée à la gestion de ses
 
 Le gestionnaire RPE dispose d’une vision transversale sur les utilisateurs, les dossiers et les activités de la structure. Son rôle est d'accompagner, superviser, et arbitrer si nécessaire.
 
-### 4.4.1 Dossiers à valider
+### 4.4.1 Comptes à valider
 
-- File d’attente des **dossiers** (famille / AM) en attente de validation
-- Affichage du **numéro de dossier** et des informations essentielles
-- Ouverture en **revue** (wizard étapes) : Valider / Refuser
-- Le refus n’efface pas le dossier : l’usager peut reprendre (voir §3.7)
-- L’onglet **Dossiers** du dashboard regroupe aussi une **liste unifiée** des dossiers (au-delà de la seule file « à valider »)
+- File d’attente des demandes de création de compte
+- Détails de chaque demande : parent, assistante maternelle
+- Actions possibles : Valider / Refuser / Demander des précisions
 
-### 4.4.2 Gestion des utilisateurs (partagée)
+### 4.4.2 Liste des utilisateurs
 
-> **V1.4** — La gestion opérationnelle des usagers (parents, AM, enfants, dossiers) est **partagée** entre gestionnaire et administrateur via le même dashboard. Seule la gestion des **comptes staff** (création / suppression gestionnaire ou admin) est réservée à l’administrateur.
-
-- Onglets : Parents, Assistantes maternelles, Enfants, Gestionnaires (selon droits), Administrateurs (admin)
-- Accès aux **fiches** (identité, rattachements, capacité AM, etc.)
-- Création de dossiers / enfants par le staff
-- Filtres et recherche ; ouverture des fiches depuis les cartes / listes
-
-Le détail des panneaux admin historiques est décrit en §4.5.2 (même socle fonctionnel).
+- Filtres par rôle, statut, date d’inscription
+- Accès rapide aux informations et historiques
+- Possibilité de contacter un utilisateur
 
 ### 4.4.3 Contrats
 
@@ -640,56 +566,47 @@ Le menu profil de l’administrateur comprend uniquement :
 
 Toutes les fonctionnalités de gestion sont accessibles via des onglets distincts dans le tableau de bord.
 
-### 4.5.2 Gestion des utilisateurs (partagée admin + gestionnaire)
+### 4.5.2 Gestion des utilisateurs
 
-L’administration des utilisateurs est organisée par panneaux / onglets. **Admin et gestionnaire** partagent les panneaux usagers ; l’admin dispose en plus des droits staff.
+L’administration des utilisateurs est organisée par panneaux distincts pour chaque type de profil.
 
 #### a. Gestion des gestionnaires
 - Liste des gestionnaires existants
-- Création / édition (nom, prénom, e-mail, téléphone, mot de passe, relais principal) — **administrateur uniquement** pour la création
-- Réinitialisation / nouveau mot de passe en édition
-- Suppression du compte — **administrateur uniquement** (pas d’auto-suppression)
+- Création (nom, prénom, e-mail, mot de passe)
+- Attribution à un ou plusieurs RPE
+- Réinitialisation du mot de passe
+- Suppression du compte
 
 #### b. Gestion des parents
-- Liste des parents enregistrés
-- Ouverture de la **fiche parent** (identité, statut, enfants, lien co-parent)
-- Rattacher / détacher un enfant
-- Création de dossier famille (wizard staff)
-- Suppression d’un compte / dossier selon droits (§3.8)
+- Liste complète des parents enregistrés
+- Recherche par nom, statut, enfants associés
+- Modification des informations
+- Suppression d’un compte
+- Consultation du statut des dossiers liés
 
 #### c. Gestion des assistantes maternelles
-- Liste des AM (agrément, capacité, etc.)
-- **Fiche AM** (identité, professionnel, enfants accueillis)
-- Respect de la **capacité max** pour les rattachements
-- Création de dossier AM (wizard staff)
-- Suppression selon droits
+- Liste des assistantes avec numéro d’agrément
+- Modification ou suppression d’un compte
+- Filtrage par zone géographique ou capacité
 
 #### d. Gestion des administrateurs
-- Création de nouveaux comptes administrateurs — **administrateur / super admin**
+- Création de nouveaux comptes administrateurs
 - Suivi des droits
-- Obligation de modification du mot de passe à la première connexion si exigé
-- Suppression avec garde-fous (pas soi-même, pas le super admin, dernier admin)
-
-#### e. Onglet Dossiers
-- Liste unifiée + dossiers à valider
-- Revue / édition des dossiers (wizards)
+- Obligation de modification du mot de passe à la première connexion
 
 ### 4.5.3 Gestion des enfants
 
 Deux accès possibles à la gestion des enfants :
 
-#### a. Par fiche parent (ou fiche AM)
-- Consultation et édition des enfants associés
-- Rattacher / détacher depuis la fiche
+#### a. Par fiche parent
+- Consultation et édition des enfants associés à chaque parent
 
 #### b. Vue globale “Enfants”
 - Liste complète avec :
   - Nom, prénom, date de naissance ou prévisionnelle
   - Statut (à naître, actif, scolarisé)
-  - Parents associés (alerte si **sans responsable**)
-  - AM associée le cas échéant
-  - Contrat en cours (si applicable — module contrats)
-- Création d’un enfant rattaché à un **foyer existant**
+  - Parents associés
+  - Contrat en cours (si applicable)
 - Possibilité de modifier ou supprimer une fiche enfant
 
 ### 4.5.4 Paramètres de la plateforme
@@ -988,10 +905,10 @@ Certains outils de la plateforme sont accessibles à plusieurs profils et favori
   - Le gestionnaire (à titre d’information)
 - Contient :
   - Identité
-  - Photo (selon configuration / consentement)
+  - Photo (obligatoire si né)
   - Statut (à naître / actif / scolarisé)
   - Parents associés
-  - AM associée le cas échéant
+  - Mention s’il s’agit de jumeaux, triplés, etc.
 
 ## 6.4 Contrats et avenants
 
@@ -1268,11 +1185,11 @@ P'titsPas s’inscrit dans une démarche de service public, avec des fondements
 | **Gestionnaires**       | Suivi global des situations, outils de médiation, organisation d’événements |
 | **Administrateurs**     | Supervision complète, gouvernance multi-rôle, contrôle des données       |
 
-## 10.3 Périmètre fonctionnel
+## 10.3 Périmètre fonctionnel de la V1
 
-**Cible CDC (plateforme complète)** — fonctionnalités décrites dans ce document :
-- Création de comptes et gestion des utilisateurs / dossiers
-- Recherche et sélection d’assistantes maternelles
+Fonctionnalités incluses dès la première version :
+- Création de comptes
+- Recherche et sélection de nounous
 - Suivi des dossiers
 - Génération de contrat et avenants
 - Messagerie
@@ -1281,8 +1198,6 @@ P'titsPas s’inscrit dans une démarche de service public, avec des fondements
 - Gestion des heures supplémentaires
 - Suivi RGPD et administration
 
-**Livré produit `v0.1.0`** (voir [bilan](./29_BILAN-VERSION-0.1.0.md)) : cœur **gestion des utilisateurs** — inscription, validation/refus/reprise, auth, dashboard staff (dossiers, fiches, rattachements, suppressions). Les autres modules du CDC restent la **feuille de route**.
-
 ## 10.4 Perspectives
 
 La structure du produit permet une montée en charge progressive :

docs/05_VERSIONS-ET-MILESTONES.md

@@ -29,14 +29,6 @@ Liens Gitea : [milestones](https://git.ptits-pas.fr/jmartin/petitspas/milestones
 |---------|----------|
 | 0.1.0 | [29_BILAN-VERSION-0.1.0.md](./29_BILAN-VERSION-0.1.0.md) |
 
-## Documents produit de référence (post-0.1.0)
-
-| Doc | Rôle |
-|-----|------|
-| [01_CAHIER-DES-CHARGES.md](./01_CAHIER-DES-CHARGES.md) | CDC **complet** V1.4 (users mis à jour ; reste = cible) |
-| [12_SRS-GESTION-UTILISATEURS.md](./12_SRS-GESTION-UTILISATEURS.md) | SRS technique domaine utilisateurs |
-| Archive CDC V1.3 | [archive/obsolete/01_CAHIER-DES-CHARGES-v1.3.md](./archive/obsolete/01_CAHIER-DES-CHARGES-v1.3.md) |
-
 ---
 
 ## Relation avec la roadmap phases

docs/12_SRS-GESTION-UTILISATEURS.md

@@ -1,250 +0,0 @@
-# SRS — Gestion des utilisateurs (domaine livré v0.1.0)
-
-**Version** : 1.0  
-**Date** : 15/09/2026  
-**Ticket** : [#117](https://git.ptits-pas.fr/jmartin/petitspas/issues/117)  
-**Niveau** : **technique** (dev / QA)  
-**CDC associé** : [01_CAHIER-DES-CHARGES.md](./01_CAHIER-DES-CHARGES.md) (V1.4 — **CDC complet** ; cette SRS ne couvre que le domaine utilisateurs)
-
-> Périmètre SRS : comptes, auth liée, dossiers famille/AM, enfants, affiliations, dashboard staff, suppressions.  
-> Le CDC V1.4 conserve **l’ensemble** des chapitres cibles (contrats, messagerie, etc.) ; ils ne sont **pas** redécrits ici.  
-> Hors SRS technique : OpenAPI exhaustif, PRA/CI → voir [11_API](./11_API.md), [10_DATABASE](./10_DATABASE.md).
-
----
-
-## 1. Glossaire
-
-| Terme | Définition |
-|-------|------------|
-| **User / utilisateur** | Compte authentifiable (`utilisateurs`) avec `role` et `statut` |
-| **Parent pivot** | Responsable principal du foyer à l’inscription / création staff |
-| **Co-parent** | Second responsable optionnel (au plus un), lié au pivot |
-| **Foyer** | Pivot + co-parent éventuel + enfants affiliés |
-| **Dossier** | Unité métier identifiée par `numero_dossier` (format `AAAA-NNNNNN`) — famille ou AM |
-| **Pending / en_attente** | Compte ou dossier en attente de validation staff |
-| **Refus** | Rejet sans suppression ; ouvre la **reprise** |
-| **Relais** | Structure RPE ; rattachement optionnel d’un gestionnaire |
-| **Staff** | `gestionnaire`, `administrateur`, `super_admin` |
-
----
-
-## 2. Acteurs et rôles applicatifs
-
-| `role` | Inscription publique | Dashboard staff | Créer staff | Suppressions métier usagers | Supprimer gestionnaire | Supprimer admin |
-|--------|---------------------|-----------------|-------------|----------------------------|------------------------|-----------------|
-| `parent` | oui | non | non | non | non | non |
-| `assistante_maternelle` | oui | non | non | non | non | non |
-| `gestionnaire` | non (créé staff) | oui | non | oui* | non | non |
-| `administrateur` | non | oui | oui | oui* | oui | oui** |
-| `super_admin` | non (install) | oui | oui | oui* | oui | oui** |
-
-\* Sous réserve des garde-fous (pas soi-même pour sa fiche staff, etc.).  
-\*\* Pas soi-même ; pas de cible `super_admin` ; dernier admin : règles `canDeleteAdministrateur` (front `staff_deletion_rights.dart`).
-
-Réf. front : `frontend/lib/utils/staff_deletion_rights.dart`  
-- `canCreateStaffAccounts` → admin / super_admin  
-- `canDeleteMetier` → gestionnaire / admin / super_admin  
-- `canDeleteGestionnaire` → admin / super_admin  
-
----
-
-## 3. Statuts
-
-### 3.1 Utilisateur (`statut_utilisateur_type`)
-
-| Statut | Signification |
-|--------|----------------|
-| `en_attente` | Inscrit, non validé ; **login refusé** |
-| `actif` | Validé / utilisable |
-| `suspendu` | Bloqué ; **login refusé** |
-
-### 3.2 Enfant (`statut_enfant_type`)
-
-Valeurs actuelles : `a_naitre`, `actif`, `scolarise` (évolution métier « gardé / sans garde » **hors** cette SRS — ticket dédié).
-
-### 3.3 Validation dossier
-
-Circuit staff : revue → **valider** ou **refuser**. Refus ≠ delete. Reprise → nouveau passage en attente.
-
----
-
-## 4. Modèle de données (vue synthétique)
-
-```mermaid
-flowchart TB
-  user[utilisateurs]
-  parent[parents]
-  am[assistantes_maternelles]
-  enfant[enfants]
-  ep[enfants_parents]
-  df[dossier_famille]
-  user --> parent
-  user --> am
-  parent --> ep
-  enfant --> ep
-  parent --> df
-```
-
-| Concept | Tables / liens clés |
-|---------|---------------------|
-| Compte | `utilisateurs` (role, statut, email, numero_dossier, relais…) |
-| Parent | `parents` (+ `id_co_parent` optionnel) |
-| AM | `assistantes_maternelles` (agrément, capacité, NIR…) |
-| Enfant | `enfants` |
-| Affiliation parent | `enfants_parents` (N–N) |
-| Dossier famille | `dossier_famille` (+ enfants dossier) |
-| Tokens MDP | tables / flux tokens création & reset (TTL, usage unique) |
-
-Détail colonnes : [10_DATABASE.md](./10_DATABASE.md).
-
-### Invariants
-
-1. **Pas** de champ `est_multiple` / naissance multiple (#152).  
-2. Au plus **un** co-parent par fiche parent.  
-3. Affiliation création enfant : rattache **pivot + co-parent** s’il existe (#158).  
-4. Détachement du **dernier** parent → enfant **sans responsable** possible (#157).  
-5. Rattachement AM plafonné par **capacité** (#148 / #149).  
-6. `super_admin` **non supprimable**.
-
----
-
-## 5. Flux
-
-### 5.1 Inscription → validation → mot de passe
-
-```mermaid
-sequenceDiagram
-  participant U as Usager
-  participant API as API
-  participant S as Staff
-  participant M as Mail
-  U->>API: register parent/AM
-  API-->>U: numero_dossier, statut en_attente
-  S->>API: review / valider
-  API->>M: mail lien create-password
-  U->>API: verify token + set password
-  API-->>U: compte actif, login OK
-```
-
-Variante **refus** : staff refuse → mail refus → usager **reprise** (token lien ou n° dossier) → resoumission → à valider.
-
-### 5.2 Mot de passe oublié
-
-Flux distinct de la création post-validation : demande → e-mail → reset (#127). Tokens durcis (#123).
-
-### 5.3 Création dossier staff
-
-- Famille : wizard + `POST` staff parent/dossier (#129).  
-- AM : wizard + API staff AM (#156).  
-- Édition : mode `edit` wizards + PATCH fiches ; ajout co-parent `POST …/co-parent` (#135).
-
-### 5.4 Rattachements
-
-| Lien | Opérations |
-|------|------------|
-| Parent ↔ enfant | attach / detach (fiche parent, fiche enfant) |
-| AM ↔ enfant | attach / detach (fiche AM, fiche enfant) ; UI capacité |
-
-API : tickets #115 / #116 ; liste enfants enrichie #136.
-
----
-
-## 6. Matrice droits × actions (synthèse)
-
-| Action | gestionnaire | administrateur | super_admin |
-|--------|:------------:|:--------------:|:-----------:|
-| Voir dashboard usagers / dossiers | ✓ | ✓ | ✓ |
-| Valider / refuser dossier | ✓ | ✓ | ✓ |
-| Créer dossier parent / AM | ✓ | ✓ | ✓ |
-| Éditer fiches parent / AM / enfant | ✓ | ✓ | ✓ |
-| Rattacher / détacher enfant | ✓ | ✓ | ✓ |
-| GET liste relais (combo) | ✓ | ✓ | ✓ |
-| Créer gestionnaire / admin | ✗ | ✓ | ✓ |
-| Supprimer parent / AM / enfant / dossier | ✓ | ✓ | ✓ |
-| Supprimer gestionnaire | ✗ | ✓ | ✓ |
-| Supprimer admin (garde-fous) | ✗ | ✓* | ✓* |
-| Supprimer super_admin | ✗ | ✗ | ✗ |
-| Supprimer son propre compte staff | ✗ | ✗ | ✗ |
-
-\* Voir `canDeleteAdministrateur` / messages `adminDeleteBlockedReason`.
-
----
-
-## 7. UI staff (points d’entrée code)
-
-| Zone | Emplacement typique |
-|------|---------------------|
-| Panneau gestion users | `widgets/dashboard/user_management_panel.dart` |
-| Onglets parents / AM / enfants / dossiers | `widgets/dashboard/*_management_widget.dart` |
-| Fiche parent | `parent_edit_modal.dart` |
-| Fiche AM | `am_edit_modal.dart` |
-| Fiche enfant | `child_detail_modal.dart` |
-| Wizards dossier | `parent_dossier_wizard.dart`, `am_dossier_wizard.dart` |
-| Modale staff | `staff_user_form_modal.dart` (`StaffUserFormModal`) |
-| Confirm suppressions | `widgets/dashboard/common/suppression_confirm_dialog.dart` |
-| Champs contrôlés | `validation_detail_section.dart` (`ValidationEmailField`, `ValidationPhoneField`…) |
-| Thème primaire modales | `validation_modal_theme.dart` |
-
-Shell fiches / wizards : largeur **930**, labels au-dessus, primaire violet `ValidationModalTheme`.
-
----
-
-## 8. API — groupes (renvoi)
-
-Ne pas dupliquer OpenAPI ici. Groupes utiles au domaine :
-
-| Groupe | Exemples d’usage |
-|--------|------------------|
-| Auth / register | Inscription parent & AM, login, tokens MDP, oubli MDP |
-| Dossiers | `GET /dossiers/:numero`, listes à valider / unifiées, validate/refuse |
-| Parents | Fiche PATCH, co-parent POST, dossier staff POST |
-| AM | Fiche PATCH, dossier staff POST |
-| Enfants | CRUD staff, attach/detach parent & AM |
-| Users / staff | CRUD gestionnaires / admins, DELETE métier |
-| Relais | `GET /relais` (autorisé gestionnaire — #151) |
-| Config | setup / configuration instance |
-
-Référence : [11_API.md](./11_API.md) (à maintenir en parallèle si écart).
-
----
-
-## 9. Exigences non fonctionnelles (domaine users)
-
-| ID | Exigence |
-|----|----------|
-| NFR-U1 | Tokens création / reset MDP : TTL strict, usage unique |
-| NFR-U2 | Mots de passe : politique min. longueur (création staff / usager selon flux) |
-| NFR-U3 | E-mails métier (validation, refus, MDP) via config SMTP instance |
-| NFR-U4 | Pas de login si `en_attente` ou `suspendu` |
-| NFR-U5 | Confirmations explicites avant toute suppression |
-| NFR-U6 | Champs e-mail / téléphone : validation & normalisation côté UI staff (SRS UX #164) |
-
-Hors scope immédiat : normalisation erreurs auth globale (#121), observabilité (#122), audit trail complet (#128).
-
----
-
-## 10. Limites modèle famille (assumées)
-
-Documentées pour les développeurs — détail produit : [28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md](./28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md).
-
-- Un `numero_dossier` / user ; un seul co-parent.  
-- Familles recomposées multi-contextes : contournement (2ᵉ compte / composition staff) jusqu’à epic #139.  
-- La SRS **n’exige pas** N responsables en v0.1.0.
-
----
-
-## 11. Traçabilité livré 0.1.0
-
-Source : [29_BILAN-VERSION-0.1.0.md](./29_BILAN-VERSION-0.1.0.md) — 48 tickets milestone 0.1.0 (auth, inscription, fiches, dossiers, suppressions, cleanups #152/#155/#162/#164).
-
----
-
-## 12. Hors périmètre de cette SRS
-
-- Contrats, avenants, fin de contrat (restent dans le **CDC** cible)  
-- Messagerie, agenda, événements RPE (idem CDC)  
-- Paie / Pajemploi  
-- Recherche AM côté parent  
-- PRA, CI/CD, monitoring infra  
-- Spécification OpenAPI ligne à ligne  
-- Texte fonctionnel complet → [01_CAHIER-DES-CHARGES.md](./01_CAHIER-DES-CHARGES.md)

docs/24_DECISIONS-PROJET.md

@@ -427,9 +427,15 @@ ptitspas-app/
 ```
 docs/
 ├── 00_INDEX.md
-├── 01_CAHIER-DES-CHARGES.md   # V1.4 fonctionnel
+├── 01_CAHIER-DES-CHARGES.md
+├── 02_ARCHITECTURE.md
+├── 03_DEPLOYMENT.md
+├── 04_ROADMAP-GENERALE.md
 ├── 05_VERSIONS-ET-MILESTONES.md
-├── 12_SRS-GESTION-UTILISATEURS.md
+├── 10_DATABASE.md
+├── 11_API.md
+├── 20_WORKFLOW-CREATION-COMPTE.md
+├── 21_CONFIGURATION-SYSTEME.md
 ├── 23_SUIVI-TICKETS.md
 ├── 24_DECISIONS-PROJET.md (ce document)
 ├── 26_GITEA-API.md
@@ -437,6 +443,7 @@ docs/
 ├── 28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md
 ├── 29_BILAN-VERSION-0.1.0.md
 ├── 99_REGLES-CODAGE.md
+├── EVOLUTIONS_CDC.md
 ├── CHARTE_GRAPHIQUE.md
 ├── juridique/               # CGU + 22_DOCUMENTS-LEGAUX.md
 ├── archive/                 # obsolete / temporaires

docs/28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md

@@ -3,9 +3,7 @@
 **Version** : 1.1  
 **Date** : 16 juin 2026  
 **Statut** : Réflexions produit / architecture — complément au [CDC](./01_CAHIER-DES-CHARGES.md)  
-**Documents liés** : [01_CAHIER-DES-CHARGES.md](./01_CAHIER-DES-CHARGES.md) (V1.4), [12_SRS-GESTION-UTILISATEURS.md](./12_SRS-GESTION-UTILISATEURS.md), [24_DECISIONS-PROJET.md](./24_DECISIONS-PROJET.md), [23_SUIVI-TICKETS.md](./23_SUIVI-TICKETS.md), [29_BILAN-VERSION-0.1.0.md](./29_BILAN-VERSION-0.1.0.md)  
-**Archive** : ancien patch CDC → [archive/obsolete/EVOLUTIONS_CDC.md](./archive/obsolete/EVOLUTIONS_CDC.md)
-
+**Documents liés** : [EVOLUTIONS_CDC.md](./EVOLUTIONS_CDC.md), [24_DECISIONS-PROJET.md](./24_DECISIONS-PROJET.md), [23_SUIVI-TICKETS.md](./23_SUIVI-TICKETS.md), [29_BILAN-VERSION-0.1.0.md](./29_BILAN-VERSION-0.1.0.md)
 
 ---
 

docs/29_BILAN-VERSION-0.1.0.md

@@ -182,7 +182,7 @@ Voir aussi [05_VERSIONS-ET-MILESTONES.md](./05_VERSIONS-ET-MILESTONES.md).
 
 ## 5. Suite documentaire
 
-1. **Amendement CDC (#117)** — CDC V1.4 : mise à jour **gestion utilisateurs** ; le reste du CDC reste la cible. SRS technique : [12_SRS-GESTION-UTILISATEURS.md](./12_SRS-GESTION-UTILISATEURS.md). Intrants historiques archivés : [archive/obsolete/EVOLUTIONS_CDC.md](./archive/obsolete/EVOLUTIONS_CDC.md), [28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md](./28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md).
+1. **Amendement CDC** — ticket **#117** : intégrer les écarts réellement livrés (dossiers staff, onglet Enfants, suppressions, retrait naissance multiple, etc.) à partir de ce bilan, [EVOLUTIONS_CDC.md](./EVOLUTIONS_CDC.md) et [28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md](./28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md).
 2. **Tag** `v0.1.0` sur `master` lorsque milestone fermée + ce bilan mergé.
 3. Enchaîner les milestones **0.2.0+** selon [05_VERSIONS-ET-MILESTONES.md](./05_VERSIONS-ET-MILESTONES.md).
 

docs/archive/README.md

@@ -5,7 +5,7 @@ Fichiers **hors références actives** : brouillons livrés, CDC historiques, li
 ## Règle de nommage (racine `docs/`)
 
 - Documents **normatifs** : préfixe **`NN_`**.
-- Exceptions héritage listées dans [00_INDEX.md](../00_INDEX.md) (`CHARTE_GRAPHIQUE.md`).
+- Exceptions héritage listées dans [00_INDEX.md](../00_INDEX.md) (`CHARTE_GRAPHIQUE.md`, `EVOLUTIONS_CDC.md`).
 
 ## Sous-dossiers
 

docs/archive/obsolete/README.md

@@ -4,15 +4,13 @@ Ancienne documentation **déplacée** depuis `docs/` :
 
 | Fichier | Motif |
 |---------|--------|
-| `01_CAHIER-DES-CHARGES-v1.3.md` | CDC V1.3 — remplacé par [01 V1.4](../../01_CAHIER-DES-CHARGES.md) |
-| `EVOLUTIONS_CDC.md` | Patch CDC — absorbé dans V1.4 + [12_SRS](../../12_SRS-GESTION-UTILISATEURS.md) |
 | `PROCEDURE-API-GITEA.md` | Doublon de [26_GITEA-API.md](../../26_GITEA-API.md) |
 | `ARCHITECTURE_TECHNIQUE.md` | Remplacé par [02_ARCHITECTURE.md](../../02_ARCHITECTURE.md) |
 | `STATUS-APPLICATION.md` | Instantané daté |
-| `23_LISTE-TICKETS.md` | Liste Phase 1 figée — suivi = Gitea + bilans |
+| `23_LISTE-TICKETS.md` | Liste Phase 1 figée (avr. 2026) — suivi = Gitea + bilans |
 | `25_PHASE-2-BACKLOG.md` | Backlog technique figé — voir [05_VERSIONS…](../../05_VERSIONS-ET-MILESTONES.md) |
 | `SuperNounou_*` | CDC / SSS historiques |
 | `14_NOTE-BACKEND-CONFIG-SETUP.md` | Note ticket ponctuelle |
 | `92_NOTE-BACKEND-GESTIONNAIRES.md` | Note ticket ponctuelle |
 
-Références actives : [01 CDC V1.4](../../01_CAHIER-DES-CHARGES.md), [12 SRS users](../../12_SRS-GESTION-UTILISATEURS.md), [29 bilan 0.1.0](../../29_BILAN-VERSION-0.1.0.md).
+Mémoire produit des versions livrées : [29_BILAN-VERSION-0.1.0.md](../../29_BILAN-VERSION-0.1.0.md).

docs/tmp/129-contrat-api-staff-parent.md

@@ -0,0 +1,89 @@
+# Mini-spec API — POST /parents/dossier (#129)
+
+Contrat pour le **plan front** (wizard création dossier famille staff).
+
+Miroir de **#156** (`POST /assistantes-maternelles/dossier`).
+
+## Endpoint
+
+| | |
+|--|--|
+| **Méthode** | `POST` |
+| **URL** | `{base}/parents/dossier` |
+| **Auth** | Bearer JWT |
+| **Rôles** | `gestionnaire`, `administrateur`, `super_admin` |
+| **Content-Type** | `application/json` |
+
+Ne **pas** appeler `POST /auth/register/parent` depuis le dashboard.
+
+## Body (JSON)
+
+Aligné `RegisterParentCompletDto`, **sans** CGU/privacy obligatoires (acceptées serveur).
+
+### Parent 1 (obligatoire)
+
+| Champ | Type | Obligatoire | Notes |
+|-------|------|-------------|--------|
+| `email` | string | oui | unique |
+| `prenom` | string | oui | |
+| `nom` | string | oui | |
+| `telephone` | string | oui | `0X…` ou `+33…` |
+| `adresse` | string | non | |
+| `code_postal` | string | non | |
+| `ville` | string | non | |
+
+### Co-parent (optionnel)
+
+`co_parent_email`, `co_parent_prenom`, `co_parent_nom`, `co_parent_telephone`,
+`co_parent_meme_adresse`, `co_parent_adresse`, `co_parent_code_postal`, `co_parent_ville`.
+
+Si co-parent fourni : e-mail distinct ; mêmes règles téléphone / adresse que register.
+
+### Enfants (≥ 1)
+
+| Champ | Type | Notes |
+|-------|------|--------|
+| `enfants` | `EnfantInscriptionDto[]` | `prenom`, `nom`, `date_naissance` / `date_previsionnelle_naissance`, `genre`, `photo_base64`, `photo_filename`, etc. |
+
+### Présentation
+
+| Champ | Type | Obligatoire |
+|-------|------|-------------|
+| `presentation_dossier` | string | non (max 2000) |
+
+## Réponses
+
+### 201 Created
+
+```json
+{
+  "message": "Dossier famille créé et validé. Un e-mail de création de mot de passe a été envoyé.",
+  "numero_dossier": "2026-000043",
+  "parent_user_id": "uuid-pivot",
+  "co_parent_user_id": "uuid-ou-null",
+  "statut": "actif",
+  "enfant_ids": ["uuid", "..."]
+}
+```
+
+Effets serveur : user(s) parent **actif**, fiches `parents`, enfants + foyer, n° dossier,
+**e-mail création MDP** pour chaque compte sans MDP (pas d’accusé « en attente »).
+
+### Erreurs
+
+| Code | Cas |
+|------|-----|
+| 400 | Validation DTO / métier (enfants vides, dates, etc.) |
+| 401 | Token manquant / invalide |
+| 403 | Rôle non staff |
+| 409 | Conflit e-mail (pivot et/ou co-parent) |
+
+## Front
+
+- `UserService.createParentDossier(body)` → cet endpoint
+- Wizard create basé sur `ValidationFamilyWizard`
+- Ne pas envoyer `acceptation_cgu` / `acceptation_privacy` (optionnels)
+
+## Branche
+
+`feature/129-creation-dossier-parent`

docs/tmp/135-contrat-api-ajout-co-parent.md

@@ -0,0 +1,73 @@
+# Mini-spec API — POST /parents/:id/co-parent (#135)
+
+Contrat back pour l’ajout d’un **2ᵉ parent** sur un foyer mono-parent (staff).
+
+## Endpoint
+
+| | |
+|--|--|
+| **Méthode** | `POST` |
+| **URL** | `{base}/api/v1/parents/{parentUserId}/co-parent` |
+| **Auth** | Bearer JWT |
+| **Rôles** | `gestionnaire`, `administrateur`, `super_admin` |
+| **Succès** | **201** |
+
+`parentUserId` = UUID du **parent pivot** (déjà dans le dossier).
+
+Ne **pas** appeler `POST /auth/register/parent` ni `POST /parents/dossier`.
+
+---
+
+## Body (JSON)
+
+| Champ | Type | Obligatoire | Notes |
+|-------|------|-------------|--------|
+| `email` | string | oui | unique |
+| `prenom` | string | oui | |
+| `nom` | string | oui | |
+| `telephone` | string | oui | `0X…` ou `+33…` |
+| `meme_adresse` | bool | non | défaut **true** → copie adresse du pivot |
+| `adresse` | string | si `meme_adresse=false` | |
+| `code_postal` | string | si `meme_adresse=false` | |
+| `ville` | string | si `meme_adresse=false` | |
+
+---
+
+## Comportement 201
+
+- User co-parent **actif** + token création MDP
+- Fiche `parents` + liens pivot ↔ co-parent + même `numero_dossier`
+- Enfants du foyer rattachés au co-parent
+- E-mail **création MDP** (pas mail « en attente »)
+
+```json
+{
+  "message": "Co-parent ajouté au foyer. Un e-mail de création de mot de passe a été envoyé.",
+  "numero_dossier": "2026-000043",
+  "parent_user_id": "uuid-pivot",
+  "co_parent_user_id": "uuid-co",
+  "statut": "actif"
+}
+```
+
+## Erreurs
+
+| Code | Cas |
+|------|-----|
+| 400 | Déjà un co-parent / 2 responsables / validation adresse |
+| 401 | Token invalide |
+| 403 | Rôle non staff |
+| 404 | Pivot introuvable |
+| 409 | Email déjà pris |
+
+## Réemploi édition identité
+
+| Endpoint | Usage |
+|----------|--------|
+| `GET /dossiers/:numero` | Préremplir wizard edit |
+| `PATCH /parents/:id/fiche` | Sauver identité pivot / co-parent existant |
+| `PATCH /assistantes-maternelles/:id/fiche` | Édition AM |
+
+## Branche
+
+`feature/135-edition-dossier`

docs/tmp/135-mini-spec-front-edition-dossier.md

@@ -0,0 +1,83 @@
+# Mini-spec front — Mode édition dossier + ajout 2ᵉ parent (#135)
+
+Branche : `feature/135-edition-dossier`  
+Ticket : **#135** (full-stack)
+
+Prérequis : **#153** (liste Dossiers) livré.
+
+---
+
+## Objectif
+
+1. Clic sur un dossier (liste #153) → ouvrir le wizard en mode **`edit`**
+2. Foyer **mono-parent** : page co-parent → **switch** ajouter un 2ᵉ parent
+3. Sauvegarder les champs via APIs existantes + nouvel endpoint co-parent
+
+---
+
+## Modes wizard
+
+| Mode | Famille | AM |
+|------|---------|-----|
+| `review` | déjà | déjà |
+| `create` | déjà (#129) | déjà (#156) |
+| **`edit`** | **à faire** | **à faire** |
+
+Factories : `ParentDossierWizard.edit(...)` / `AmDossierWizard.edit(...)`  
+Préremplir via `UserService.getDossierByNumero(numero)`.
+
+---
+
+## APIs
+
+| Action | Endpoint |
+|--------|----------|
+| Charger | `GET /dossiers/:numero` |
+| Sauver parent | `PATCH /parents/:id/fiche` |
+| Sauver AM | `PATCH /assistantes-maternelles/:id/fiche` |
+| **Ajouter co-parent** | **`POST /parents/:pivotUserId/co-parent`** — voir `docs/tmp/135-contrat-api-ajout-co-parent.md` |
+
+Body co-parent :
+
+```json
+{
+  "email": "thomas@…",
+  "prenom": "Thomas",
+  "nom": "MARTIN",
+  "telephone": "0678456789",
+  "meme_adresse": true
+}
+```
+
+`UserService.addCoParent(pivotUserId, body)` → cet endpoint.
+
+---
+
+## UX
+
+- Depuis `DossiersManagementWidget` / carte liste : clic → edit (plus seulement review pending)
+- Pending : garder validation (review) ; dossiers actifs → edit
+- Mono-parent : switch « Ajouter un co-parent » (comme create) → au save, `POST …/co-parent` si nouveau
+- Déjà 2 parents : éditer les deux fiches ; pas de 3ᵉ
+- Pas de bouton créer dans l’onglet Dossiers
+
+---
+
+## Hors scope
+
+- Famille N responsables (#139)
+- Suppressions (#154)
+- Création dossier initial (#129 / #156)
+
+---
+
+## Critères d’acceptation
+
+- [ ] Clic dossier actif → wizard edit prérempli
+- [ ] PATCH fiche enregistre les modifs
+- [ ] Mono-parent + switch → co-parent créé (actif + mail MDP)
+- [ ] review / create inchangés
+
+## Branche
+
+`feature/135-edition-dossier`

docs/tmp/152-mini-spec-front-est-multiple.md

@@ -0,0 +1,65 @@
+# Mini-spec — Suppression complète grossesse multiple / `est_multiple`
+
+**Ticket** : **#152** — https://git.ptits-pas.fr/jmartin/petitspas/issues/152  
+**Branche** : `feature/152-remove-est-multiple` (depuis `develop`)  
+**Périmètre** : **full stack** — BDD + back + front + scripts + docs. **Aucun fantôme.**
+
+---
+
+## Décision
+
+On **supprime tout**. Pas de DTO « ignorés », pas de compat payload.
+
+`forbidNonWhitelisted: true` ⇒ back et front **partent ensemble** (même feature / même déploiement).
+
+---
+
+## Alias retirés
+
+`est_multiple` · `is_multiple` · `grossesse_multiple` · `multipleBirth` · `estMultiple` · `isMultiple` · `jumeau_multiple`
+
+---
+
+## Back / BDD (fait sur la branche)
+
+- [x] Migration `database/migrations/2026_drop_enfants_est_multiple.sql`
+- [x] `BDD.sql`, seeds, CSV test
+- [x] Entity `Children` sans colonne
+- [x] DTO create/inscription/réponse/dossier famille **sans** le champ
+- [x] Services auth / enfants / parents : plus de mapping
+- [x] Prisma legacy `isMultiple` retiré
+
+## Front (fait sur la branche)
+
+- [x] Modèles admin / dossier / inscription
+- [x] Payloads inscription + reprise
+- [x] Modale enfant + wizard dossier famille
+- [x] Step3 inscription parent
+
+## Scripts / docs
+
+- [x] `tests/scripts/register-parent-*.mjs`
+- [x] `docs/10_DATABASE.md`, `docs/99_REGLES-CODAGE.md`
+- Docs tmp/archive #112 : mentions historiques OK (archive)
+
+---
+
+## Déploiement
+
+1. Appliquer la migration SQL sur la BDD vivante  
+2. Deploy back **et** front de cette branche  
+3. Smoke : création enfant staff, inscription parent, reprise, wizard famille
+
+## Vérif
+
+```bash
+rg -n 'est_multiple|is_multiple|grossesse_multiple|multipleBirth|estMultiple|isMultiple|jumeau_multiple' \
+  backend/src frontend/lib database tests/scripts docs/10_DATABASE.md docs/99_REGLES-CODAGE.md
+```
+→ **0** hit (hors ce fichier mini-spec / archives).
+
+## Hors scope
+
+- Métier futur « fratrie / jumeaux » → nouveau ticket  
+- #155 rename Admin*  
+- Ticket modales staff

docs/tmp/153-contrat-api-liste-dossiers.md

@@ -0,0 +1,77 @@
+# Mini-spec API — GET /dossiers (#153)
+
+Contrat pour le **plan front** (onglet permanent Dossiers).
+
+## Endpoint
+
+| | |
+|--|--|
+| **Méthode** | `GET` |
+| **URL** | `{base}/api/v1/dossiers` |
+| **Auth** | Bearer JWT |
+| **Rôles** | `gestionnaire`, `administrateur`, `super_admin` |
+| **Query** | `q` (optionnel) — recherche n° / libellé / email |
+
+Complète `GET /dossiers/:numeroDossier` (#119) déjà existant.
+
+---
+
+## Réponse 200
+
+Tableau de lignes (1 entrée = 1 `numero_dossier`) :
+
+```json
+[
+  {
+    "type": "famille",
+    "numero_dossier": "2026-000043",
+    "libelle": "Claire MARTIN & Thomas MARTIN",
+    "emails": ["claire@test.fr", "thomas@test.fr"],
+    "user_ids": ["uuid-pivot", "uuid-co"],
+    "statut": "actif",
+    "a_valider": false,
+    "date_reference": "2026-01-12T10:00:00.000Z"
+  },
+  {
+    "type": "assistante_maternelle",
+    "numero_dossier": "2026-000042",
+    "libelle": "Marie DUPONT",
+    "emails": ["marie@test.fr"],
+    "user_ids": ["uuid-am"],
+    "statut": "en_attente",
+    "a_valider": true,
+    "date_reference": "2026-02-01T08:00:00.000Z"
+  }
+]
+```
+
+### Champs
+
+| Champ | Notes |
+|-------|--------|
+| `type` | `famille` \| `assistante_maternelle` |
+| `numero_dossier` | Clé d’unité |
+| `libelle` | Noms formatés (foyer : `A & B`) |
+| `emails` / `user_ids` | Membres du foyer ou AM |
+| `statut` | Agrégé : `en_attente` si au moins un user pending |
+| `a_valider` | `true` si pending → section haute UI |
+| `date_reference` | `MIN(cree_le)` des users |
+
+**Tri** : `a_valider` d’abord, puis `numero_dossier` décroissant.
+
+**Famille** : dédupliquée par `numero_dossier` (pivot + co-parent = 1 ligne).
+
+---
+
+## Front
+
+- `UserService.getDossiers({ q? })` → cet endpoint
+- Section haute : filtrer `a_valider == true` **ou** continuer pending APIs existantes
+- Section basse : liste complète (ou hors pending selon règle UX)
+- Clic → `GET /dossiers/:numero` (détail) / validation review
+
+Composition client `getParents`+`getAM` **plus nécessaire** si cet endpoint est déployé.
+
+## Branche
+
+`feature/153-onglet-dossiers`

docs/tmp/153-mini-spec-front-dossiers.md

@@ -0,0 +1,167 @@
+# Mini-spec front — Onglet permanent « Dossiers » (#153)
+
+Branche Git (front + back) : `feature/153-onglet-dossiers`  
+Ticket Gitea : **#153** (ticket normal, plus epic)
+
+> Suite prévue : **#135** = au clic, mode **édition** wizard + ajout 2ᵉ parent.  
+> **#153** = onglet + listes + navigation / validation pending. **Pas** de création, **pas** d’édition complète.
+
+---
+
+## Contexte / objectif
+
+Remplacer l’onglet conditionnel **« À valider »** (apparaît/disparaît selon pending) par un onglet **permanent « Dossiers »** dans le dashboard admin/gestionnaire.
+
+Quand on ouvre **Dossiers** :
+
+1. **En haut** — section **Dossiers à valider** (AM + familles pending)
+2. **En dessous** — liste de **tous les dossiers** (familles **et** AM), 1 ligne = 1 `numero_dossier`
+3. Différenciation visuelle famille vs AM : **couleur + icône**
+4. **Barre de recherche** (n° dossier, nom, email…)
+
+**Pas** de bouton « Créer un dossier » ici (création via **+ Parents** #129 / **+ Asmat** #156).
+
+---
+
+## UX cible
+
+### Onglets dashboard (`UserManagementPanel`)
+
+| Avant (#107) | Après (#153) |
+|--------------|--------------|
+| « À valider » **conditionnel** si pending | **« Dossiers » toujours visible** (admin + gestionnaire) |
+| Contenu = seulement pending | Pending **en haut** + liste complète **en bas** |
+
+Ordre suggéré des onglets :
+
+`Dossiers` | `Parents` | `Enfants` | `Assistantes maternelles` | `Gestionnaires` | (`Administrateurs`)
+
+### Section haute — À valider
+
+- Réutiliser / adapter `PendingValidationWidget` (ou extraire la liste dans un sous-widget).
+- Sources déjà branchées :
+  - `UserService.getPendingUsers(role: 'assistante_maternelle')`
+  - `UserService.getPendingFamilies()`
+- Clic ligne pending → **`ValidationDossierModal`** / wizards `.review` (inchangé).
+- Si section vide : ne pas afficher de gros vide ; masquer la section ou message court « Aucun dossier en attente ».
+
+### Section basse — Tous les dossiers
+
+1 ligne = **1 dossier** (`numero_dossier`), type :
+
+| Type | Libellé UI | Couleur (suggestion) |
+|------|------------|----------------------|
+| `famille` | Famille / Parents | teinte existante parents (ex. violet / rose dashboard) |
+| `assistante_maternelle` | AM | teinte existante AM (ex. teal / bleu) |
+
+Colonnes / infos utiles (cartes style `AdminUserCard` ou lignes type pending) :
+
+- n° dossier
+- type (pastille couleur + icône)
+- libellé (noms parents ou AM)
+- email(s) principal(aux)
+- statut user / dossier si dispo (`actif`, `en_attente`, …)
+- date utile si dispo
+
+**Déduplication** : un foyer (pivot + co-parent) = **une** ligne famille (même `numero_dossier`). Idem AM.
+
+### Recherche
+
+- La search bar du panel (aujourd’hui désactivée / hint « pas de recherche » sur À valider) doit **filtrer la liste unifiée** (et idéalement aussi le pending affiché).
+- Critères **minimum** : `numero_dossier`, nom, prénom, email.
+- Harmoniser le hint : `Rechercher un dossier (n°, nom, email)…`
+
+### État vide liste complète
+
+Aide optionnelle : *« Pour créer un dossier → onglet Parents (+ Parents) ou Assistantes maternelles (+ Asmat) »*.
+
+### Clic sur un dossier de la liste complète (#153)
+
+| Cas | Comportement #153 |
+|-----|-------------------|
+| Pending | Ouvrir validation (review) — déjà en place |
+| Dossier **actif** / non pending | Ouvrir consultation via `GET /dossiers/:numeroDossier` (`UserService.getDossierByNumero`) en **lecture / review** si possible **sans** save édition |
+
+**Ne pas** implémenter le mode `edit` ni le switch 2ᵉ parent → **#135**.
+
+Si l’ouverture « review » d’un dossier actif est trop lourde pour ce ticket : clic peut temporairement no-op / snackbar *« Édition dossier : prochainement (#135) »* — **à éviter** si `getDossierByNumero` + wizard review marche déjà pour les deux types.
+
+---
+
+## Données / APIs (front)
+
+### Déjà disponibles (préférer composer côté front pour #153)
+
+| Besoin | API / service |
+|--------|----------------|
+| Pending AM | `getPendingUsers(role: assistante_maternelle)` |
+| Pending familles | `getPendingFamilies()` |
+| Parents (avec `numero_dossier`) | `getParents()` |
+| AM (avec `numero_dossier`) | `getAssistantesMaternelles()` |
+| Détail unifié | `getDossierByNumero(numero)` → `GET /dossiers/:numeroDossier` |
+
+**Pas d’endpoint `GET /dossiers` liste** aujourd’hui. Pour #153 :
+
+- Construire la liste unifiée **côté client** à partir de `getParents()` + `getAssistantesMaternelles()` (group by `numero_dossier`).
+- Exclure ou marquer les pending déjà dans la section haute (éviter doublons visuels, ou les laisser dans les deux avec badge « à valider » — **préférence** : pending **uniquement** en haut ; liste basse = tous **hors** pending **ou** tous avec badge ; choisir une règle claire et documenter dans le PR).
+
+**Règle recommandée** :
+- Haut = pending only
+- Bas = **tous** les dossiers ayant un `numero_dossier` (y compris pending) **OU** bas = non-pending only  
+→ **Recommandation produit** : bas = **tous** (vision complète), pending aussi en haut pour action rapide. Si doublon gênant : bas = non-pending only.
+
+### Si le back ajoute plus tard `GET /dossiers`
+
+Brancher `UserService.getDossiers()` — hors scope bloquant #153 front si composition client OK.
+
+---
+
+## Fichiers front probables
+
+| Fichier | Rôle |
+|---------|------|
+| `frontend/lib/widgets/admin/user_management_panel.dart` | Onglet permanent **Dossiers** ; retirer logique conditionnelle À valider ; search sur cet onglet |
+| `frontend/lib/widgets/admin/pending_validation_widget.dart` | Réemploi section haute (ou refactor léger) |
+| **Nouveau** `…/dossiers_management_widget.dart` (nom libre) | Shell onglet : pending + liste unifiée + refresh |
+| **Nouveau** modèle léger `DossierListItem` (type, numero, libelle, emails, statut…) | Mapping parents/AM → ligne |
+| `user_service.dart` / `api_config.dart` | Seulement si helper `getDossiersUnified()` côté client (pas forcément nouvel endpoint) |
+| `validation_dossier_modal.dart` | Réemploi ouverture pending / détail |
+
+Réutiliser look & feel cartes / hover « Ouvrir » de `_PendingValidationRow` / `AdminUserCard`.
+
+---
+
+## Hors scope (#153)
+
+- Bouton créer dossier
+- Mode `edit` wizard + ajout 2ᵉ parent → **#135**
+- Suppressions → **#154**
+- Famille N responsables → **#139**
+- Changer les onglets Parents / AM / Enfants (restent)
+
+---
+
+## Critères d’acceptation front
+
+- [ ] Onglet **Dossiers** toujours visible (même 0 pending)
+- [ ] Plus d’onglet conditionnel **« À valider »**
+- [ ] Section haute pending si non vide ; validation au clic OK
+- [ ] Liste unifiée familles + AM en dessous ; 1 ligne / `numero_dossier`
+- [ ] Couleur + icône différencient famille / AM
+- [ ] Recherche filtre (n° + nom + email minimum)
+- [ ] **Aucun** bouton créer dans cet onglet
+- [ ] Pas de régression validation pending (valider / refuser)
+
+---
+
+## Back (info — Cursor back séparé si besoin)
+
+- Liste unifiée : **pas bloquante** si composition front
+- Optionnel : `GET /api/v1/dossiers` (liste) pour perf / pagination plus tard
+- `GET /dossiers/:numero` déjà là (#119)
+
+---
+
+## Branche
+
+`feature/153-onglet-dossiers` (depuis `develop`)

docs/tmp/154-matrice-suppression.md

@@ -0,0 +1,35 @@
+# Matrice suppression — #154 / back **#159** / front **#160**
+
+**Statut** : cadrage PO validé (sept. 2026)  
+**Milestone** : 0.1.0  
+**Email** : pas d’email de suppression (cas rare)
+
+## Droits
+
+| Cible | Qui peut supprimer |
+|-------|-------------------|
+| Dossier / parent / enfant / AM | `GESTIONNAIRE`, `ADMINISTRATEUR`, `SUPER_ADMIN` |
+| Gestionnaire (user) | `ADMINISTRATEUR`, `SUPER_ADMIN` |
+| Administrateur (user) | Autre admin OK ; **self interdit** ; **dernier admin** = `SUPER_ADMIN` only ; `SUPER_ADMIN` non supprimable |
+
+## Matrice métier
+
+| Point d’entrée | Action | Effet |
+|----------------|--------|--------|
+| Dossiers | Delete dossier **famille** | Tous **parents** + tous **enfants** ; clore placements AM des enfants |
+| Dossiers / AM | Delete dossier **AM** ou compte AM | **Compte AM + dossier AM** ; enfants **conservés** ; placements **clos** |
+| Parents | Co-parent (autre parent reste) | Compte parent seul ; dossier + enfants restent |
+| Parents | Dernier parent | Parent + **enfants** rattachés |
+| Enfants | Pas dernier | Enfant seul (retiré du dossier) |
+| Enfants | Dernier + `deleteDossier=true` | Cascade dossier famille (parents + enfants) |
+| Enfants | Dernier + `deleteDossier=false` | Enfant seul ; dossier peut apparaître **`sans_enfant`** |
+| Pending / validé | — | **Mêmes règles** (pas de différenciation) |
+
+## Warning
+
+- `sans_enfant` sur liste `GET /dossiers` (dossier famille sans enfant lié).
+- Miroir de `sans_responsable` (#157) côté enfants.
+
+## Hors scope
+
+Soft-delete RGPD, audit (#128), famille N (#139), restriction admin-only métier (plus tard).

docs/tmp/154-mini-spec-front-suppression.md

@@ -0,0 +1,169 @@
+# Mini-spec front — Suppressions dashboard
+
+**Ticket front** : **#160** — https://git.ptits-pas.fr/jmartin/petitspas/issues/160  
+**Ticket back** : **#159** — https://git.ptits-pas.fr/jmartin/petitspas/issues/159  
+**Epic** : #154 (complète #133)  
+**Branche back** : `feature/159-suppressions-backend`  
+**Doc matrice** : [154-matrice-suppression.md](./154-matrice-suppression.md)
+
+Travail **en parallèle** : ce contrat est la source de vérité UI ↔ API.
+
+---
+
+## UX commune
+
+Sur chaque ligne / carte des listes :
+
+- Icône **poubelle** en bout de ligne
+- Clic → **dialog de confirmation** (texte d’impact) → DELETE → **refresh** liste
+- Pending = **mêmes** règles que validés
+- **Pas** d’email
+
+| Liste | Poubelle visible si |
+|-------|---------------------|
+| Dossiers, Parents, Enfants, AM | gestionnaire **ou** admin |
+| Gestionnaires | **admin** only |
+| Administrateurs | admin+ ; **pas** sur sa propre ligne ; dernier admin : UI warning + réservé super_admin |
+
+---
+
+## Contrat API
+
+Base : auth Bearer. Erreurs : `400` / `403` / `404` / `409` avec `message` FR.
+
+### 1. `DELETE /dossiers/:numeroDossier`
+
+- **Famille** → supprime tous parents + enfants du n° ; clos placements AM des enfants.
+- **AM** → compte AM + dossier AM ; enfants gardés ; placements clos.
+
+**Réponse 200** (exemple) :
+
+```json
+{
+  "type": "famille",
+  "numero_dossier": "2026-000043",
+  "deleted_user_ids": ["…"],
+  "deleted_enfant_ids": ["…"],
+  "message": "Dossier famille supprimé."
+}
+```
+
+ou
+
+```json
+{
+  "type": "assistante_maternelle",
+  "numero_dossier": "2026-000015",
+  "deleted_user_ids": ["…"],
+  "deleted_enfant_ids": [],
+  "message": "Dossier assistante maternelle supprimé."
+}
+```
+
+**Dialog UI** : lister libellé + n° + « X parent(s), Y enfant(s) » (ou « compte AM, enfants conservés »).
+
+---
+
+### 2. `DELETE /users/:id`
+
+Comportement selon le **rôle** de la cible :
+
+| Cible | Effet |
+|-------|--------|
+| Parent **co-parent** | Delete ce user seul |
+| Parent **dernier** du dossier | Delete user + enfants du foyer |
+| AM | Delete user AM + dossier AM ; enfants conservés ; placements clos |
+| Gestionnaire | Admin only ; self → 403 |
+| Administrateur | Self → 403 ; dernier admin → super_admin only sinon 403 ; super_admin → 403 |
+
+**Réponse 200** :
+
+```json
+{
+  "deleted_user_ids": ["…"],
+  "deleted_enfant_ids": ["…"],
+  "message": "…"
+}
+```
+
+**Dialogs** :
+
+- Co-parent : « Ce parent sera retiré / supprimé du dossier {n°}. Les enfants restent avec le co-parent. »
+- Dernier parent : « Dernier parent du dossier {n°}. Les enfants rattachés seront aussi supprimés. »
+- AM : « Le compte et le dossier AM seront supprimés. Les enfants accueillis ne seront pas supprimés. »
+
+Optionnel (si exposé) : `GET /users/:id/suppression-impact` — sinon calculer depuis données déjà en liste / détail dossier.
+
+---
+
+### 3. `DELETE /enfants/:id?deleteDossier=true|false`
+
+- Pas dernier enfant → delete enfant (`deleteDossier` ignoré ou false).
+- Dernier enfant + `deleteDossier=false` → delete enfant ; dossier famille peut passer `sans_enfant`.
+- Dernier enfant + `deleteDossier=true` → cascade dossier famille (parents + enfants).
+
+**Réponse 200** :
+
+```json
+{
+  "deleted_enfant_ids": ["…"],
+  "deleted_user_ids": ["…"],
+  "dossier_supprime": false,
+  "message": "…"
+}
+```
+
+**Dialog** :
+
+- Standard : « L’enfant sera supprimé du dossier de {famille} ({n°}). »
+- Dernier : proposer **deux actions** :
+  1. Supprimer l’enfant seulement (`deleteDossier=false`)
+  2. Supprimer aussi le dossier / parents (`deleteDossier=true`)
+
+Pour savoir si dernier : compter enfants du `numero_dossier` (détail dossier ou champ impact API).
+
+---
+
+### 4. `GET /dossiers` — flag `sans_enfant`
+
+Chaque item famille peut exposer :
+
+```json
+"sans_enfant": true
+```
+
+- `true` si dossier **famille** sans enfant lié.
+- AM : `false` ou omis.
+
+**UI** : badge / warning vigilance (comme `sans_responsable` / alertes AM).
+
+---
+
+## UserService (Flutter) — signatures cibles
+
+```dart
+Future<void> deleteDossier(String numeroDossier);
+Future<Map<String, dynamic>> deleteUser(String userId);
+Future<Map<String, dynamic>> deleteEnfant(String enfantId, {bool deleteDossier = false});
+```
+
+(Adapter le parsing au JSON réel une fois le back mergé ; en parallèle, stubber sur ce contrat.)
+
+---
+
+## Fichiers front probables
+
+- Cartes listes : `admin_user_card.dart`, `admin_enfant_user_card.dart`, cartes dossiers
+- Listes : `dossiers_management_widget.dart`, `parent_managmant_widget.dart`, `enfant_management_widget.dart`, `assistante_maternelle_management_widget.dart`, `gestionnaire_management_widget.dart`, `admin_management_widget.dart`
+- `user_service.dart`
+
+---
+
+## Critères front (#160)
+
+- [ ] Poubelle selon droits
+- [ ] Confirmations avec impact
+- [ ] Refresh après succès
+- [ ] Dernier enfant : choix dossier oui/non
+- [ ] Warning `sans_enfant`
+- [ ] Self-admin / dernier admin gérés côté UI (masquer ou message 403)

docs/tmp/155-mini-spec-rename-admin-prefix.md

@@ -0,0 +1,54 @@
+# Mini-spec — Rename préfixe `Admin*` dashboard partagé (#155)
+
+**Ticket** : **#155**  
+**Branche** : `feature/155-rename-admin-prefix-dashboard` (depuis `develop`)  
+**Décision naming** : **option C** — dossier neutre `widgets/dashboard/` + noms **sans** préfixe `Admin`.
+
+---
+
+## Principe
+
+Les widgets partagés **admin + gestionnaire** ne doivent plus s’appeler `Admin*`.  
+On garde `Admin*` seulement là où c’est vraiment le rôle administrateur.
+
+## Gardé `Admin*` (hors rename)
+
+| Élément | Raison |
+|---------|--------|
+| `AdminManagementWidget` | Onglet **Administrateurs** |
+| `screens/administrateurs/*` | `AdminDashboardScreen`, `AdminCreateDialog`, `AdminUserFormDialog` |
+| `EnfantAdminModel` | Modèle API (pas un widget) — hors scope ticket |
+
+## Renames faits
+
+| Avant | Après |
+|-------|--------|
+| `widgets/admin/common/admin_child_detail_modal.dart` → `AdminChildDetailModal` | `widgets/dashboard/child_detail_modal.dart` → `ChildDetailModal` |
+| `admin_am_edit_modal` → `AdminAmEditModal` | `am_edit_modal` → `AmEditModal` |
+| `admin_parent_edit_modal` → `AdminParentEditModal` | `parent_edit_modal` → `ParentEditModal` |
+| `admin_user_card` → `AdminUserCard` | `user_card` → `UserCard` |
+| `admin_enfant_user_card` → `AdminEnfantUserCard` | `enfant_user_card` → `EnfantUserCard` |
+| `admin_am_photo_frame` → `AdminAmPhotoFrame` | `am_photo_frame` → `AmPhotoFrame` |
+| `admin_am_children_capacity_grid` | `am_children_capacity_grid` → `AmChildrenCapacityGrid` |
+| `admin_children_affiliation_panel` | `children_affiliation_panel` → `ChildrenAffiliationPanel` |
+| `admin_select_*` / `AdminSelect*` / `AdminFamilleFoyer` | `select_*` / `Select*` / `FamilleFoyer` |
+| `admin_status_capsule` | `status_capsule` → `StatusCapsule` |
+| `admin_list_state` → `AdminListState` | `user_list_state` → `UserListState` |
+| `admin_detail_modal` → `AdminDetailModal` / `AdminDetailField` | `detail_modal` → `DetailModal` / `DetailField` |
+| `dashboard_admin.dart` | `user_management_sub_bar.dart` (`DashboardUserManagementSubBar` inchangé) |
+
+Dossier `widgets/admin/` conserve encore les panels métier (`user_management_panel`, wizards, etc.) + `AdminManagementWidget`.
+
+**Phase 2** (même ticket #155) : déplacer ces panels → `widgets/dashboard/` — voir [155-suite-move-admin-panels-to-dashboard.md](./155-suite-move-admin-panels-to-dashboard.md).
+
+## Hors scope
+
+- Refonte UX modales (ticket dédié)
+- Rename API / back
+- Déplacer tout `widgets/admin/` → `widgets/dashboard/` (panels) — possible follow-up
+
+## Critères
+
+- [x] Plus de préfixe `Admin` sur les composants **partagés** listés
+- [ ] Build Flutter / recette dashboard admin + gestionnaire OK
+- [x] Pas de changement comportemental (rename mécanique)

docs/tmp/155-suite-move-admin-panels-to-dashboard.md

@@ -0,0 +1,203 @@
+# Mini-spec — Déplacer les panels `widgets/admin/` → `widgets/dashboard/`
+
+**Ticket** : **#155** (phase 2 — même ticket que le rename `Admin*`)  
+**Phase 1** : widgets `Admin*` → `widgets/dashboard/` (déjà sur `feature/155-rename-admin-prefix-dashboard`)  
+**Branche** : poursuivre / rebaser `feature/155-rename-admin-prefix-dashboard` (ou nouvelle branche depuis `develop` après merge phase 1)  
+**Nature** : rename / move mécanique — **zéro** changement UX / métier
+
+---
+
+## Contexte
+
+Après la phase 1 (#155), la situation est **hybride** :
+
+| Emplacement | Contenu |
+|-------------|---------|
+| `widgets/dashboard/` | Composants partagés sans préfixe `Admin*` (modales, cartes, selects, sub-bar…) |
+| `widgets/admin/` | **Panels** du dashboard staff (listes, wizards, validation, shell `UserManagementPanel`…) + `AdminManagementWidget` |
+
+Le dossier `admin/` laisse encore croire « réservé administrateur », alors que **gestionnaire** consomme les mêmes panels (`GestionnaireDashboardScreen` → `UserManagementPanel`).
+
+Ce ticket **termine l’option C** au niveau dossier : tout le dashboard staff vit sous `widgets/dashboard/`, sauf ce qui est **vraiment** rôle admin.
+
+---
+
+## Objectif
+
+```
+frontend/lib/widgets/admin/<panels & common partagés>
+        ↓  git mv + update imports
+frontend/lib/widgets/dashboard/…
+```
+
+Critère : un nouveau dev ne doit plus ouvrir `widgets/admin/` pour du code partagé admin+gestionnaire.
+
+---
+
+## Cible d’arborescence (proposée)
+
+```
+widgets/dashboard/
+  ├── (déjà là #155) child_detail_modal.dart, am_edit_modal.dart, user_card.dart, …
+  ├── user_management_panel.dart          ← shell onglets
+  ├── user_management_sub_bar.dart        ← déjà déplacé #155
+  ├── dossiers_management_widget.dart
+  ├── dossier_list_card.dart
+  ├── parent_management_widget.dart       ← corriger le typo managmant au passage ?
+  ├── enfant_management_widget.dart
+  ├── assistante_maternelle_management_widget.dart
+  ├── gestionnaire_management_widget.dart
+  ├── pending_validation_widget.dart
+  ├── parent_dossier_create_modal.dart
+  ├── parent_dossier_wizard.dart
+  ├── am_dossier_create_modal.dart
+  ├── am_dossier_wizard.dart
+  ├── validation_*.dart                   ← family/am wizards, refus, theme, confirm
+  ├── parametres_panel.dart               ← utilisé par écran admin (OK dans dashboard)
+  ├── relais_management_panel.dart
+  ├── common/                             ← sous-dossier optionnel
+  │     ├── suppression_confirm_dialog.dart
+  │     ├── user_list.dart
+  │     └── validation_detail_section.dart
+  └── …
+
+widgets/admin/                            ← mince, rôle admin seulement
+  └── admin_management_widget.dart        ← onglet Administrateurs
+```
+
+### Variante B (plus stricte)
+
+`AdminManagementWidget` + éventuels helpers purement admin →  
+`screens/administrateurs/widgets/`  
+et **suppression** du dossier `widgets/admin/`.
+
+**Reco** : **variante A** (garder `widgets/admin/` minimal avec seulement `AdminManagementWidget`) — moins de churn screens, clair.
+
+---
+
+## Inventaire à déplacer (état actuel)
+
+### Racine `widgets/admin/` → `widgets/dashboard/`
+
+| Fichier actuel | Notes |
+|----------------|--------|
+| `user_management_panel.dart` | Shell partagé admin + gestionnaire |
+| `dossiers_management_widget.dart` | |
+| `dossier_list_card.dart` | |
+| `parent_managmant_widget.dart` | Typo historique `managmant` — **option** : renommer → `parent_management_widget.dart` dans le même ticket ou ticket typo séparé |
+| `enfant_management_widget.dart` | |
+| `assistante_maternelle_management_widget.dart` | |
+| `gestionnaire_management_widget.dart` | |
+| `pending_validation_widget.dart` | |
+| `parent_dossier_create_modal.dart` | |
+| `parent_dossier_wizard.dart` | |
+| `am_dossier_create_modal.dart` | |
+| `am_dossier_wizard.dart` | |
+| `validation_am_wizard.dart` | |
+| `validation_family_wizard.dart` | |
+| `validation_dossier_modal.dart` | |
+| `validation_modal_theme.dart` | |
+| `validation_refus_form.dart` | |
+| `validation_valider_confirm_dialog.dart` | |
+| `parametres_panel.dart` | Écran admin seulement, mais pas préfixé Admin — OK dashboard |
+| `relais_management_panel.dart` | |
+
+### `widgets/admin/common/` → `widgets/dashboard/common/` (ou plat)
+
+| Fichier | Notes |
+|---------|--------|
+| `suppression_confirm_dialog.dart` | Partagé (y compris `screens/administrateurs/creation/*`) |
+| `user_list.dart` | |
+| `validation_detail_section.dart` | |
+
+### **Ne pas** déplacer
+
+| Fichier | Destination |
+|---------|-------------|
+| `admin_management_widget.dart` | Reste `widgets/admin/` (ou variante B → screens) |
+
+### Déjà fait (#155) — ne pas retraiter
+
+Tout ce qui est déjà sous `widgets/dashboard/` (`child_detail_modal`, `am_edit_modal`, `user_card`, `select_*`, `user_management_sub_bar`, …).
+
+---
+
+## Consommateurs d’imports (à mettre à jour)
+
+### Screens
+- `screens/administrateurs/admin_dashboardScreen.dart` — `UserManagementPanel`, `ParametresPanel`
+- `screens/gestionnaire/gestionnaire_dashboard_screen.dart` — `UserManagementPanel`
+- `screens/administrateurs/creation/admin_create.dart` — `suppression_confirm_dialog`
+- `screens/administrateurs/creation/gestionnaires_create.dart` — idem
+
+### Widgets déjà en `dashboard/`
+- `am_edit_modal`, `child_detail_modal`, `parent_edit_modal`, `select_*` — imports vers `widgets/admin/common/*` ou panels
+
+### Divers
+- `widgets/common/identity_block.dart` (si import admin)
+- Tous les fichiers **déplacés** entre eux (imports relatifs / package)
+
+### Hors scope rename classes
+Sauf décision explicite sur le typo `parent_managmant_widget` → pas de rename de **classes** métier dans ce ticket (seulement chemins de fichiers + imports).  
+`AdminManagementWidget` **conserve** son nom.
+
+---
+
+## Plan d’exécution
+
+1. Partir de `feature/155-rename-admin-prefix-dashboard` (phase 1) **ou** `develop` si phase 1 déjà mergée
+2. `git mv` fichiers selon inventaire
+3. Remplacer globalement  
+   `package:p_tits_pas/widgets/admin/` → `package:p_tits_pas/widgets/dashboard/`  
+   **sauf** `…/widgets/admin/admin_management_widget.dart`
+4. Corriger imports relatifs cassés
+5. Grep de contrôle (ci-dessous)
+6. Build Flutter web (Docker) + smoke dashboard admin **et** gestionnaire
+7. Merge → squash master si flux habituel
+
+---
+
+## Vérifs
+
+```bash
+# Plus de panels partagés sous admin (seul AdminManagement attendu)
+find frontend/lib/widgets/admin -name '*.dart'
+
+# Plus d’imports panels vers l’ancien chemin (sauf AdminManagement)
+rg -n "widgets/admin/(user_management|dossiers_|parent_|enfant_|assistante|gestionnaire|pending|validation_|parametres|relais|am_dossier|parent_dossier|dossier_list|common/)" frontend/lib
+
+# Screens OK
+rg -n "widgets/admin/" frontend/lib/screens
+```
+
+Attendu screens : **0** hit vers panels ; éventuellement plus aucun hit `widgets/admin/` sauf si import explicite `AdminManagementWidget` depuis `user_management_panel` (chemin `widgets/admin/admin_management_widget.dart`).
+
+---
+
+## Hors scope
+
+- Refonte UX des modales / panels (ticket dédié annoncé)
+- Rename `EnfantAdminModel`
+- Rename `screens/administrateurs/`
+- Rename `AdminUserFormDialog` / `AdminCreateDialog`
+- Changement API / back
+- #152 (`est_multiple`) — autre branche
+
+---
+
+## Critères d’acceptation
+
+- [ ] Inventaire déplacé selon tableau
+- [ ] `widgets/admin/` ne contient plus que `admin_management_widget.dart` (variante A)
+- [ ] Imports screens + widgets à jour
+- [ ] Build Flutter OK
+- [ ] Recette : dashboard **administrateur** et **gestionnaire** (listes, ouverture fiches, validation, création dossier) sans régression
+- [ ] Aucun changement comportemental volontaire
+
+---
+
+## Risques / notes
+
+- **Conflits de merge** si d’autres features touchent les panels → faire ce ticket quand la surface dashboard est calme (fin 0.1.0 OK)
+- Typo `parent_managmant_widget` : soit inclus (bonus), soit ticket cleanup 1-ligne séparé
+- Docs d’archive citant `widgets/admin/…` : pas obligatoire de mettre à jour ; `docs/27_BRIEFING-FRONTEND.md` oui si encore listé

docs/tmp/156-contrat-api-staff-am.md

@@ -0,0 +1,75 @@
+# Mini-spec API — POST /assistantes-maternelles/dossier (#156)
+
+Contrat pour le **plan front** (wizard création AM staff).
+
+## Endpoint
+
+| | |
+|--|--|
+| **Méthode** | `POST` |
+| **URL** | `{base}/assistantes-maternelles/dossier` |
+| **Auth** | Bearer JWT |
+| **Rôles** | `gestionnaire`, `administrateur`, `super_admin` |
+| **Content-Type** | `application/json` |
+
+Ne **pas** appeler `POST /auth/register/am` depuis le dashboard.
+
+## Body (JSON)
+
+Aligné inscription AM publique, **sans** CGU/privacy obligatoires (acceptées serveur).
+
+| Champ | Type | Obligatoire | Notes |
+|-------|------|-------------|--------|
+| `email` | string | oui | unique |
+| `prenom` | string | oui | |
+| `nom` | string | oui | |
+| `telephone` | string | oui | `0X…` ou `+33…` |
+| `adresse` | string | non | |
+| `code_postal` | string | non | |
+| `ville` | string | non | |
+| `photo_base64` | string | non | data-URL `data:image/…;base64,…` |
+| `photo_filename` | string | non | hint nom fichier |
+| `consentement_photo` | bool | oui | |
+| `date_naissance` | date ISO | non | `YYYY-MM-DD` |
+| `lieu_naissance_ville` | string | oui | |
+| `lieu_naissance_pays` | string | oui | |
+| `nir` | string | oui | 15 car. (Corse 2A/2B OK) |
+| `numero_agrement` | string | oui | unique |
+| `date_agrement` | date ISO | non | |
+| `capacite_accueil` | int | oui | 1–10 |
+| `places_disponibles` | int | oui | 0–10, ≤ capacité |
+| `biographie` | string | non | max 2000 |
+
+## Réponses
+
+### 201 Created
+
+```json
+{
+  "message": "Dossier AM créé et validé. Un e-mail de création de mot de passe a été envoyé.",
+  "user_id": "uuid",
+  "statut": "actif",
+  "numero_dossier": "2026-000042"
+}
+```
+
+Effets serveur : user AM **actif**, fiche `assistantes_maternelles`, n° dossier, **e-mail création MDP** (pas d’accusé « en attente »).
+
+### Erreurs
+
+| Code | Cas |
+|------|-----|
+| 400 | Validation / NIR / places > capacité |
+| 403 | Rôle non staff |
+| 409 | Email, NIR ou agrément déjà pris |
+| 401 | Token manquant / invalide |
+
+## Front
+
+- `UserService.createAmDossier(body)` → cet endpoint
+- Après 201 : refresh liste AM ; snackbar OK
+- Wizard create : ne pas envoyer `acceptation_cgu` / `acceptation_privacy` (optionnels)
+
+## Branche
+
+`feature/156-creation-dossier-am`

docs/tmp/164-staff-modal-uniformisation-mini-spec.md

@@ -0,0 +1,14 @@
+# Mini-spec — Uniformisation modale staff (Gestionnaire / Administrateur)
+
+**Ticket** : **#164** — https://git.ptits-pas.fr/jmartin/petitspas/issues/164  
+**Branche** : `feature/164-staff-modal-uniformisation` (depuis `develop`)  
+**Périmètre** : **front only** — pas d’API / BDD  
+**Milestone** : **0.1.0**
+
+Voir le corps du ticket #164 pour la spec complète.
+
+## Livré
+
+- `frontend/lib/widgets/dashboard/staff_user_form_modal.dart` → `StaffUserFormModal`
+- Ancien `AdminUserFormDialog` / `gestionnaires_create.dart` retiré
+- Imports : `user_management_panel`, `gestionnaire_management_widget`, `admin_management_widget`