docs: rationalisation post-0.1.0 (bilan, purge tmp, archives).

- Bilan 29 + index versions 05 ; suivi tickets pointeur Gitea - Purge docs/tmp et archive/temporaires livrés - Archive SuperNounou, liste tickets figée, backlog Phase 2, notes 14/92 - Suppression stubs PROCEDURE/22 ; INDEX et roadmap alignés Co-authored-by: Cursor <cursoragent@cursor.com>
merge(#164 ): uniformisation modale staff gestionnaire / admin.
2026-09-14 17:45:43 +02:00 · 2026-09-14 17:29:31 +02:00
38 changed files with 379 additions and 2211 deletions
@@ -1,94 +1,77 @@
-# 📚 Index de la Documentation - PtitsPas App
+# Index de la documentation — P'titsPas
-Bienvenue dans la documentation complète de l'application PtitsPas.
+Index de navigation du dépôt. Dernière révision : **septembre 2026** (clôture doc 0.1.0).
-Ce fichier sert d'index pour naviguer dans toute la documentation du projet.
+## Produit & versions
-## 📖 Table des matières
+| Doc | Contenu |
 |-----|---------|
 | [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 + 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) | Modèle dossier / foyer |
-### 📋 Cahier des Charges
+## Architecture & infra
 - [**01 - Cahier des Charges**](./01_CAHIER-DES-CHARGES.md) - Cahier des charges complet du projet P'titsPas (V1.3 - 24/11/2025)
-### Architecture & Infrastructure
+| Doc | Contenu |
- [**02 - Architecture**](./02_ARCHITECTURE.md) - Vue d'ensemble de l'architecture mono-repo et multi-conteneurs
+|-----|---------|
- [**03 - Déploiement**](./03_DEPLOYMENT.md) - Guide complet de déploiement et configuration CI/CD
+| [02 — Architecture](./02_ARCHITECTURE.md) | Mono-repo, conteneurs |
 | [03 — Déploiement](./03_DEPLOYMENT.md) | Deploy / CI-CD |
 | [10 — Database](./10_DATABASE.md) | Schéma BDD |
 | [11 — API](./11_API.md) | Endpoints REST |
 | [21 — Configuration système](./21_CONFIGURATION-SYSTEME.md) | Config on-premise |
 | [99 — Règles de codage](./99_REGLES-CODAGE.md) | Conventions |
-### Planification
+## Workflows & métier
 - [**04 - Roadmap Générale**](./04_ROADMAP-GENERALE.md) - Roadmap complète du projet (Phases 1 à 5+)
-### Développement
+| Doc | Contenu |
- [**10 - Database Schema**](./10_DATABASE.md) - Schéma de la base de données et modèles
+|-----|---------|
- [**11 - API Documentation**](./11_API.md) - Documentation complète des endpoints REST
+| [20 — Workflow création de compte](./20_WORKFLOW-CREATION-COMPTE.md) | Inscription / validation |
- [**14 - Note backend config setup**](./14_NOTE-BACKEND-CONFIG-SETUP.md) - Setup configuration
+| [juridique/](./juridique/README.md) | CGU / CGC / privacy + [22 technique](./juridique/22_DOCUMENTS-LEGAUX.md) |
- [**92 - Note backend gestionnaires**](./92_NOTE-BACKEND-GESTIONNAIRES.md) - Gestionnaires
+| [CHARTE_GRAPHIQUE.md](./CHARTE_GRAPHIQUE.md) | Charte UI |
 - [**99 - Règles de codage**](./99_REGLES-CODAGE.md) - Conventions de code
-### Workflows Fonctionnels
+## Projet & outillage
 - [**20 - Workflow Création de Compte**](./20_WORKFLOW-CREATION-COMPTE.md) - Workflow complet de création et validation des comptes utilisateurs
 - [**21 - Configuration Système**](./21_CONFIGURATION-SYSTEME.md) - Configuration on-premise dynamique
 - [**22 - Documents Légaux**](./juridique/22_DOCUMENTS-LEGAUX.md) - Gestion CGU/Privacy avec versioning
-### Juridique (sources & technique)
+| Doc | Contenu |
- [**Dossier juridique**](./juridique/README.md) - Index : CGU/CGC en Markdown,
+|-----|---------|
-  export PDF, lien vers la doc technique n°22
+| [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 |
-### Projet & suivi (Gitea / tickets)
+## Audit
 - [**23 - Liste des Tickets**](./23_LISTE-TICKETS.md) - 61 tickets Phase 1 détaillés
 - [**24 - Décisions Projet**](./24_DECISIONS-PROJET.md) - Décisions architecturales et fonctionnelles
 - [**25 - Backlog Phase 2**](./25_PHASE-2-BACKLOG.md) - Fonctionnalités techniques reportées
 - [**28 - Évolution famille et responsables**](./28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md) - Modèle dossier/famille, recompositions, v1.0.0 vs post-1.0.0
 - [**26 - API Gitea**](./26_GITEA-API.md) - Procédure d'utilisation de l'API Gitea (issues, PR, branches, labels)
 - [**27 - Briefing frontend**](./27_BRIEFING-FRONTEND.md) - Accès Git, priorités, scripts Gitea (token)
-### Archive & convention de nommage
+| Doc | Contenu |
- [**Dossier archive**](./archive/README.md) - Fichiers **sans** `NN_` déplacés
+|-----|---------|
-  (temporaires, obsolètes) ; règles de rangement et suppression
+| [90 — Audit YNOV](./90_AUDIT.md) | Analyse code étudiant |
 - Pointeur : [PROCEDURE-API-GITEA.md](./PROCEDURE-API-GITEA.md) → voir **26**
-### Exceptions de nommage (racine `docs/`)
+## Archive
 Fichiers **sans préfixe numérique** encore à la racine par **héritage** ou
 références outils (`.cursorrules`, etc.) — **à renommer** en `NN_` quand
 possible :
 - `CHARTE_GRAPHIQUE.md`
 - [`EVOLUTIONS_CDC.md`](./EVOLUTIONS_CDC.md) — écarts CDC / app ; voir aussi [**28 - Évolution famille**](./28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md)
 - `SuperNounou_Cahier_Des_Charges_Complet_V1.1.md`
 - `SuperNounou_SSS-001.md`
-### Administration (À créer)
+| Emplacement | Usage |
- [**30 - Guide d'administration**](./30_ADMIN.md) - Gestion des utilisateurs, accès PgAdmin, logs
+|-------------|--------|
- [**31 - Troubleshooting**](./31_TROUBLESHOOTING.md) - Résolution des problèmes courants
+| [archive/](./archive/README.md) | Obsolete / temporaires |
 | [archive/obsolete/](./archive/obsolete/) | CDC SuperNounou, ancienne liste tickets, backlog Phase 2 figé, notes ponctuelles |
-### Frontend (À créer)
+## Données de test
 - [**40 - Frontend Flutter**](./40_FRONTEND.md) - Structure de l'application mobile/web
-### Audit & Analyse
+| Doc | Contenu |
- [**90 - Audit du projet YNOV**](./90_AUDIT.md) - Analyse complète du code étudiant et fonctionnalités
+|-----|---------|
 | [test-data/](./test-data/README.md) | Jeux utilisateurs test |
-## 🚀 Quick Start
+## Quick start
 ```bash
-# Cloner le projet
+git clone … ptitspas-app
 git clone ssh://gitea-jmartin/jmartin/app.git ptitspas-app
 # Lancer l'environnement de développement
 cd ptitspas-app
 docker compose up -d
-
+# Front https://app.ptits-pas.fr — API /api — PgAdmin /pgadmin
 # Accéder aux services
 Frontend: https://app.ptits-pas.fr
 API: https://app.ptits-pas.fr/api
 PgAdmin: https://app.ptits-pas.fr/pgadmin
 ```
-## 🔗 Liens utiles
+## Liens
- **Gitea** : https://git.ptits-pas.fr
+- Gitea : https://git.ptits-pas.fr/jmartin/petitspas  
- **Production** : https://app.ptits-pas.fr
+- Prod : https://app.ptits-pas.fr  
 - **Mail** : https://mail.ptits-pas.fr
 ## 📝 Maintenance
 Cette documentation est maintenue par Julien Martin (julien.martin@ptits-pas.fr).
 Dernière mise à jour : Juin 2026
 Mainteneur : Julien Martin (julien.martin@ptits-pas.fr).
@@ -44,22 +44,21 @@ Les **Phases 2, 3, 4+** sont des **ébauches indicatives** qui seront affinées
 - ✅ Logging & Monitoring
 - ✅ Tests & Documentation
-### Versions incrémentales
+### Versions incrémentales (semver / Gitea)
-| Version | Objectif | Tickets | Estimation |
+La table historique « ~21 tickets / 0.1.0 » est **obsolète**.  
-|---------|----------|---------|------------|
+État réel des milestones, bilans et tag : **[05_VERSIONS-ET-MILESTONES.md](./05_VERSIONS-ET-MILESTONES.md)**.
 | **0.1.0** | MVP Fonctionnel | ~21 | ~45h |
 | **0.2.0** | Sécurité & RGPD | ~10 | ~35h |
 | **0.3.0** | Interfaces Complètes | ~17 | ~52h |
 | **0.4.0** | Tests & Documentation | ~6 | ~24h |
 | **0.5.0** | Monitoring & Optimisations | ~7 | ~17h |
 | **1.0.0** | 🎉 **Release Phase 1** | **61** | **~173h** |
-### Livrable
+| Version | Statut (sept. 2026) |
 |---------|---------------------|
 | **0.1.0** | **Terminée** — [bilan](./29_BILAN-VERSION-0.1.0.md) (48 tickets fermés) |
 | **0.2.0+** | Ouvertes — voir Gitea + doc 05 |
-Application installable avec création et validation de comptes utilisateurs.
+### Livrable Phase 1 (visée)
-**Référence** : [23_LISTE-TICKETS.md](./23_LISTE-TICKETS.md)
+Application installable avec création et validation de comptes utilisateurs, puis enrichissements dashboard / dossiers (0.1.0 livré).
 **Tickets** : Gitea — pointeur [23_SUIVI-TICKETS.md](./23_SUIVI-TICKETS.md).
 ---
@@ -216,7 +215,7 @@ Suivi quotidien des enfants + Fonctionnalités complémentaires.
 Application mature, optimisée et riche en fonctionnalités.
-**Référence** : [25_PHASE-2-BACKLOG.md](./25_PHASE-2-BACKLOG.md) (anciennes fonctionnalités techniques)
+**Référence** : [archive/obsolete/25_PHASE-2-BACKLOG.md](./archive/obsolete/25_PHASE-2-BACKLOG.md) (figé) + [05_VERSIONS-ET-MILESTONES.md](./05_VERSIONS-ET-MILESTONES.md)
 ---
@@ -317,9 +316,10 @@ Exemples :
 - [00_INDEX.md](./00_INDEX.md) - Index général de la documentation
 - [01_CAHIER-DES-CHARGES.md](./01_CAHIER-DES-CHARGES.md) - Cahier des charges v1.3
 - [20_WORKFLOW-CREATION-COMPTE.md](./20_WORKFLOW-CREATION-COMPTE.md) - Workflow création de comptes
- [23_LISTE-TICKETS.md](./23_LISTE-TICKETS.md) - Liste des 61 tickets Phase 1
+- [23_SUIVI-TICKETS.md](./23_SUIVI-TICKETS.md) / [29_BILAN-VERSION-0.1.0.md](./29_BILAN-VERSION-0.1.0.md) — suivi Gitea + bilan 0.1.0
 - [24_DECISIONS-PROJET.md](./24_DECISIONS-PROJET.md) - Décisions architecturales
- [25_PHASE-2-BACKLOG.md](./25_PHASE-2-BACKLOG.md) - Anciennes fonctionnalités techniques
+- [05_VERSIONS-ET-MILESTONES.md](./05_VERSIONS-ET-MILESTONES.md) — milestones Gitea
 - [archive/obsolete/25_PHASE-2-BACKLOG.md](./archive/obsolete/25_PHASE-2-BACKLOG.md) — backlog Phase 2 figé
 ---
@@ -0,0 +1,56 @@
 # Versions & milestones — P'titsPas
 **Source de vérité tickets** : Gitea [`jmartin/petitspas`](https://git.ptits-pas.fr/jmartin/petitspas)  
 **Bilans de version** : documents `29_BILAN-…` (et suivants)
 Ce fichier remplace, pour le **semver / milestones**, les anciennes tables figées de la roadmap Phase 1.
 ---
 ## État des milestones
 | Milestone | Rôle | Statut |
 |-----------|------|--------|
 | **0.1.0** | MVP opérable (auth, inscription, dashboard dossiers/fiches, suppressions, cleanups) | **Terminée** — [bilan](./29_BILAN-VERSION-0.1.0.md) |
 | **0.2.0** | Suite produit (ex. recherche / échanges — sans contrat) | Ouverte |
 | **0.3.0** | Contrat + planning | Ouverte |
 | **0.4.0** | Carnet de liaison | Ouverte |
 | **0.9.0** | Hors périmètre cleanup 0.1.0 (doublons, upload, tech auth/photos, UX erreurs…) | Ouverte |
 | **1.0.0** | Release majeure Phase 1 (critères PO) | Réserve |
 | **Backlog transverse** | Doc étendue, CI/tests, RGPD avancé, monitoring — hors semver dédié | Ouverte |
 Liens Gitea : [milestones](https://git.ptits-pas.fr/jmartin/petitspas/milestones).
 ---
 ## Bilans
 | Version | Document |
 |---------|----------|
 | 0.1.0 | [29_BILAN-VERSION-0.1.0.md](./29_BILAN-VERSION-0.1.0.md) |
 ---
 ## Relation avec la roadmap phases
 La vision long terme (Phases 2–5 : mise en relation, contrats, carnet…) reste dans [04_ROADMAP-GENERALE.md](./04_ROADMAP-GENERALE.md).  
 Les **jalons livrables** se gèrent ici + dans Gitea.
 Ancien backlog « Phase 2 » technique ([archive](./archive/obsolete/25_PHASE-2-BACKLOG.md)) : à croiser avec les milestones ci-dessus ; ne plus maintenir en double.
 ---
 ## Suivi des tickets
 - **Création / état** : Gitea uniquement.
 - **Mémoire d’une version livrée** : bilan `29_…` (pas de re-copie exhaustive dans un fichier tickets).
 - Ancienne liste figée Phase 1 : [archive/obsolete/23_LISTE-TICKETS.md](./archive/obsolete/23_LISTE-TICKETS.md).
 - Pointeur court : [23_SUIVI-TICKETS.md](./23_SUIVI-TICKETS.md).
 ---
 ## Tag Git
 | Tag | Condition |
 |-----|-----------|
 | `v0.1.0` | Milestone 0.1.0 fermée + bilan mergé sur `master` |
@@ -1,8 +0,0 @@
 # Fichier déplacé
 La documentation **Documents légaux** a été déplacée vers :
 **[juridique/22_DOCUMENTS-LEGAUX.md](./juridique/22_DOCUMENTS-LEGAUX.md)**
 Voir aussi le dossier **[juridique/](./juridique/)** pour les sources **CGU**
 et **CGC** en Markdown.
@@ -0,0 +1,12 @@
 # Suivi des tickets — P'titsPas
 **Source de vérité** : [Gitea — issues](https://git.ptits-pas.fr/jmartin/petitspas/issues)  
 **Milestones / versions** : [05_VERSIONS-ET-MILESTONES.md](./05_VERSIONS-ET-MILESTONES.md)  
 **API Gitea** : [26_GITEA-API.md](./26_GITEA-API.md)
 Ne plus maintenir de catalogue exhaustif des tickets dans le dépôt : l’état (ouvert / fermé / milestone) change dans Gitea.
 Pour une **version livrée**, lire le bilan correspondant (ex. [29_BILAN-VERSION-0.1.0.md](./29_BILAN-VERSION-0.1.0.md)).
 Archive historique (liste Phase 1 figée, avril 2026) :  
 [archive/obsolete/23_LISTE-TICKETS.md](./archive/obsolete/23_LISTE-TICKETS.md).
@@ -423,31 +423,30 @@ ptitspas-app/
 - Maintenance (tout au même endroit)
 - Versioning (Git)
-**Structure** :
+**Structure** (sept. 2026) :
 ```
 docs/
 ├── 00_INDEX.md
 ├── 01_CAHIER-DES-CHARGES.md
 ├── 02_ARCHITECTURE.md
 ├── 03_DEPLOYMENT.md
 ├── 04_ROADMAP-GENERALE.md
 ├── 05_VERSIONS-ET-MILESTONES.md
 ├── 10_DATABASE.md
 ├── 11_API.md
 ├── 20_WORKFLOW-CREATION-COMPTE.md
 ├── 21_CONFIGURATION-SYSTEME.md
-├── 22_DOCUMENTS-LEGAUX.md   # pointeur → juridique/
+├── 23_SUIVI-TICKETS.md
 ├── 27_BRIEFING-FRONTEND.md
 ├── PROCEDURE-API-GITEA.md   # pointeur → 26_GITEA-API.md
 ├── juridique/
 │   ├── README.md
 │   ├── cgu.md
 │   ├── cgc.md
 │   └── 22_DOCUMENTS-LEGAUX.md
 ├── archive/
 │   ├── README.md
 │   ├── temporaires/
 │   └── obsolete/
 ├── 23_LISTE-TICKETS.md
 ├── 24_DECISIONS-PROJET.md (ce document)
 ├── 26_GITEA-API.md
 ├── 27_BRIEFING-FRONTEND.md
 ├── 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
 ├── 90_AUDIT.md
 └── test-data/
 ```
@@ -3,7 +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** : [EVOLUTIONS_CDC.md](./EVOLUTIONS_CDC.md), [24_DECISIONS-PROJET.md](./24_DECISIONS-PROJET.md), [23_LISTE-TICKETS.md](./23_LISTE-TICKETS.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)
 ---
@@ -0,0 +1,197 @@
 # Bilan — Version 0.1.0
 **Statut** : terminée  
 **Milestone Gitea** : [0.1.0](https://git.ptits-pas.fr/jmartin/petitspas/milestone/10)  
 **Dépôt** : `jmartin/petitspas`  
 **Tag prévu** : `v0.1.0` (sur `master` après merge de cette doc)
 Ce document est la **mémoire produit** de la version 0.1.0 : ce qui a été livré, ticket par ticket, et ce qui a été reporté.
 ---
 ## 1. Périmètre produit livré
 La 0.1.0 couvre le **MVP opérable** pour une collectivité :
 - Authentification, création / oubli de mot de passe, e-mails associés
 - Inscription parent & AM, validation / refus gestionnaire, reprise après refus
 - Dashboard staff (admin + gestionnaire) : listes, fiches, rattachements
 - Onglet **Dossiers** + wizards création / édition (famille & AM)
 - Suppressions métier (droits, confirms, cascades API)
 - Cleanups structurels (préfixe `Admin*`, panels dashboard, modale staff, retrait `est_multiple`)
 **Hors 0.1.0** (reporté) : doublons avancés, famille N responsables, statut enfant gardé/sans garde, combobox RPE AM, chantier CDC (#117), tickets tech/observabilité — voir §4 et [05_VERSIONS-ET-MILESTONES.md](./05_VERSIONS-ET-MILESTONES.md).
 ---
 ## 2. Thèmes livrés
 ### 2.1 Auth, mot de passe, e-mails
 | # | Titre | Livré |
 |---|-------|--------|
 | 24 | API Création mot de passe | Endpoints token → création MDP post-validation |
 | 28 | Templates Email — Validation | Mails validation avec lien MDP |
 | 30 | Connexion — Vérification statut | Blocage comptes pending / suspendus à la connexion |
 | 43 | Écran Création Mot de Passe | UI lien e-mail création MDP |
 | 47 | Écran Changement MDP Obligatoire | Première connexion staff |
 | 50 | Affichage dynamique CGU | CGU/Privacy versionnées à l’inscription |
 | 118 | Page création mot de passe (Front + API) | Alignement front/API du flux lien e-mail |
 | 123 | Durcissement token création MDP | TTL, usage unique, contrôles API |
 | 127 | Mot de passe oublié | Demande → e-mail → réinitialisation (flux distinct de #24/#43) |
 ### 2.2 Inscription, numéros de dossier, reprise
 | # | Titre | Livré |
 |---|-------|--------|
 | 104 | Numéro de dossier — frontend | Affichage listes / mails / modales ; format AAAA-… |
 | 112 | Reprise après refus — frontend | Lien e-mail `/reprise` + reprise par n° dossier |
 | 120 | Inscription AM — photo & UX | Chaîne photo / API / UX alignée parents |
 | 144 | Consentement photo enfant | Persistance du consentement à l’inscription |
 ### 2.3 Dashboard — fiches, listes, rattachements
 | # | Titre | Livré |
 |---|-------|--------|
 | 115 | Rattachement enfants — backend | Attach/detach parent↔enfant et AM↔enfant |
 | 116 | Rattachement enfants — frontend | UI fiches parent / AM |
 | 130 | UserService — APIs métier | Branchement parents / AM / enfants côté front |
 | 131 | Édition fiche parent + AM | Modales édition dashboard |
 | 132 | Création enfant (onglet Enfants) | Création + rattachement foyer |
 | 136 | API enfants — droits & liste | Droits gestionnaire + enrichissement liste |
 | 137 | Onglet Enfants — liste globale | Panneau liste dashboard |
 | 138 | Fiche enfant + liste dans parent | Fiche enfant ; enfants dans fiche parent |
 | 140 | Epic fiche parent / affiliation | Livraison regroupée dashboard admin/gestionnaire |
 | 142 | Clic carte → modale | Ouverture fiche depuis les listes |
 | 145 | Lien co-parent cliquable | Navigation fiche parent → co-parent |
 | 146 | Modale sélection enfant | UX rattacher enfant (AM + parent) |
 | 147 | Modale sélection AM | UX rattacher AM depuis fiche enfant |
 | 148 | Capacité max AM | Désactivation rattachement si capacité atteinte |
 | 149 | Case libre AM → rattacher | Clic emplacement vide pour rattacher |
 | 151 | GET /relais pour gestionnaire | Combo relais dans modale staff |
 | 157 | Enfant sans responsable | Détachement dernier parent + alerte liste |
 | 158 | Affiliation foyer (pivot + co-parent) | Attach/detach cohérents sur le foyer |
 ### 2.4 Dossiers staff (création, édition, liste)
 | # | Titre | Livré |
 |---|-------|--------|
 | 129 | Création dossier parent | Wizard + API staff famille |
 | 135 | Édition dossier + 2ᵉ parent | Mode edit wizards + `POST …/co-parent` |
 | 153 | Onglet Dossiers | Liste unifiée + à valider (sans création dans l’onglet) |
 | 156 | Création dossier AM | Wizard + API staff AM |
 ### 2.5 Suppressions & droits staff
 | # | Titre | Livré |
 |---|-------|--------|
 | 133 | Suppression parent + AM (UI) | Première vague UI (complétée par #160) |
 | 134 | Droits « Ajouter gestionnaire » | Visibilité / API selon rôle |
 | 143 | Bug supprimer sa propre fiche | Masquage / interdiction auto-suppression |
 | 154 | Epic suppressions | Cadrage règles métier suppressions |
 | 159 | Suppressions métier — backend | Cascades, garde-fous, droits API |
 | 160 | Suppressions dashboard — frontend | Poubelles + dialogues de confirmation |
 | 161 | Admin création staff 403 | Admin peut créer gestionnaire et administrateur |
 ### 2.6 Cleanups structure & UX
 | # | Titre | Livré |
 |---|-------|--------|
 | 25 | API Liste comptes en attente | Historique ; couvert par flux dossiers / validation |
 | 26 | API Validation / Refus | Historique ; couvert par flux dossiers / validation |
 | 152 | Retrait `est_multiple` | Suppression full stack (BDD, API, front, docs) |
 | 155 | Rename préfixe `Admin*` | Widgets partagés sans préfixe Admin (option C) |
 | 162 | Panels → `widgets/dashboard/` | Suite #155 — panels staff sous dashboard |
 | 164 | Modale staff uniformisée | `StaffUserFormModal` (shell 930, champs contrôlés) |
 ---
 ## 3. Inventaire exhaustif (48 tickets fermés, milestone 0.1.0)
 | # | Titre |
 |---|-------|
 | 24 | [Backend] API Création mot de passe |
 | 25 | [Backend] API Liste comptes en attente |
 | 26 | [Backend] API Validation/Refus comptes |
 | 28 | [Backend] Templates Email - Validation |
 | 30 | [Backend] Connexion - Vérification statut |
 | 43 | [Frontend] Écran Création Mot de Passe |
 | 47 | [Frontend] Écran Changement MDP Obligatoire |
 | 50 | [Frontend] Affichage dynamique CGU lors inscription |
 | 104 | Numéro de dossier – frontend |
 | 112 | Reprise après refus – frontend |
 | 115 | [Backend] Rattachement enfants — parent et AM |
 | 116 | [Frontend] Rattachement enfants — parent et AM |
 | 118 | Page création mot de passe (lien email) – Front + API |
 | 120 | [Full-stack] Inscription AM — photo, API et UX alignés sur les parents |
 | 123 | [Tech] Durcissement token création MDP |
 | 127 | [Full-stack] Mot de passe oublié — flux complet |
 | 129 | Création dossier parent (wizard + API staff) |
 | 130 | [Frontend] UserService — brancher APIs parents, AM et enfants |
 | 131 | [Frontend] Édition fiche parent + AM |
 | 132 | Création enfant depuis l’onglet Enfants |
 | 133 | [Frontend] Suppression compte parent + AM |
 | 134 | Droits bouton « Ajouter gestionnaire » |
 | 135 | Mode édition dossier (+ ajout 2ᵉ parent) |
 | 136 | [Backend] API enfants — droits gestionnaire + enrichissement liste |
 | 137 | [Frontend] Onglet Enfants — liste globale |
 | 138 | [Frontend] Fiche enfant + liste enfants dans fiche parent |
 | 140 | Dashboard admin — fiche parent, enfants et affiliation |
 | 142 | Clic sur carte → ouvrir la modale |
 | 143 | Bug — Gestionnaire Supprimer sur sa propre fiche |
 | 144 | Bug — Consentement photo enfant non sauvegardé |
 | 145 | Lien co-parent cliquable |
 | 146 | UX — modale sélection d'enfant |
 | 147 | UX — modale sélection d'AM |
 | 148 | Bug — capacité max AM |
 | 149 | Fiche AM — clic case libre pour rattacher |
 | 151 | Bug — GET /relais gestionnaire |
 | 152 | Cleanup — supprimer `est_multiple` |
 | 153 | Onglet permanent « Dossiers » |
 | 154 | Epic — suppressions utilisateurs / dossiers / enfants / AM |
 | 155 | Cleanup — renommer préfixe Admin* |
 | 156 | Création dossier AM (wizard + API staff) |
 | 157 | Enfant sans responsable |
 | 158 | Affiliation enfant au foyer (pivot + co-parent) |
 | 159 | Backend suppressions métier (#154) |
 | 160 | Frontend suppressions dashboard (#154) |
 | 161 | Bug — Admin création gestionnaire / administrateur |
 | 162 | Cleanup — panels vers `widgets/dashboard/` |
 | 164 | Uniformisation modale staff + champs contrôlés |
 Issues : https://git.ptits-pas.fr/jmartin/petitspas/issues?q=&type=all&state=closed&labels=&milestone=10&assignee=0
 ---
 ## 4. Reporté hors 0.1.0
 | # | Titre | Destination typique |
 |---|-------|---------------------|
 | 113 / 114 | Doublons inscription / alerte gestionnaire | 0.9.0 |
 | 117 | Évolution du cahier des charges | Doc (amendement CDC post-0.1.0) |
 | 121–122, 124–125 | Tech auth / photos / DB | 0.9.0 |
 | 126 | Upload documents légaux 500 | 0.9.0 |
 | 128 | Audit / traçabilité modifications | 0.9.0 |
 | 139 | Famille complexe N responsables | Post-0.1.0 / epic |
 | 141 | Statut enfant gardé / sans garde | Post-0.1.0 |
 | 150 | Combobox rattachement RPE (AM) | 0.2.0 |
 Voir aussi [05_VERSIONS-ET-MILESTONES.md](./05_VERSIONS-ET-MILESTONES.md).
 ---
 ## 5. Suite documentaire
 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).
 ---
 ## 6. Références code (points d’entrée)
 - Modale staff : `frontend/lib/widgets/dashboard/staff_user_form_modal.dart`
 - Fiches : `parent_edit_modal.dart`, `am_edit_modal.dart`, `child_detail_modal.dart`
 - Wizards dossiers : `parent_dossier_wizard.dart`, `am_dossier_wizard.dart`
 - Règles suppressions : tickets #154 / #159 / #160
 - Cleanup `est_multiple` : #152
@@ -2,7 +2,9 @@
 Ce document liste les modifications à apporter au cahier des charges original pour le rendre conforme à l'application développée.
-> **Document complémentaire (juin 2026)** — réflexions sur le **modèle famille / numéro de dossier**, familles recomposées, tuteurs et responsables légaux : voir **[28 - Évolution famille et responsables](./28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md)**.
+> **Intrant pour #117** (amendement CDC post-0.1.0). Compléter avec le [bilan 0.1.0](./29_BILAN-VERSION-0.1.0.md) et **[28 - Évolution famille et responsables](./28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md)**.
 > **Obsolète depuis #152** : ne plus proposer de champ « naissance multiple / `est_multiple` » — retiré de l’app (BDD, API, front).
 ## 1. Gestion des Enfants
@@ -11,7 +13,6 @@ Ce document liste les modifications à apporter au cahier des charges original p
 #### Situation actuelle dans le CDC :
 - Mentionne uniquement la collecte d'informations sur l'enfant
 - Ne précise pas la possibilité d'ajouter plusieurs enfants
 - Ne mentionne pas la gestion des naissances multiples
 - Ne mentionne pas la gestion des enfants à naître
 #### Modifications proposées :
@@ -22,17 +23,18 @@ Ajouter le paragraphe suivant après la description de la collecte d'information
 Les parents peuvent ajouter autant d'enfants que nécessaire. Pour chaque enfant, les informations suivantes sont collectées :
 - Prénom
 - Date de naissance (ou date prévue pour les enfants à naître)
 - Genre
 - Photo (optionnelle)
 - Consentement pour l'utilisation de la photo
 - Indication si l'enfant fait partie d'une naissance multiple (jumeaux, triplés, etc.)
 Les parents peuvent :
 - Ajouter un nouvel enfant à tout moment
 - Supprimer un enfant ajouté
 - Modifier les informations d'un enfant existant
 - Indiquer si l'enfant est à naître
 - Indiquer si l'enfant fait partie d'une naissance multiple
 - Donner ou retirer leur consentement pour l'utilisation de la photo de l'enfant
 Note : le concept de « naissance multiple » / jumeaux n'est pas géré par un champ dédié (retiré en 0.1.0, #152).
 ```
 ### Modifications à apporter dans la section "Workflow de création de compte"
@@ -50,9 +52,9 @@ Remplacer l'étape 3 par :
   - Pour chaque enfant :
     * Saisie du prénom
     * Saisie de la date de naissance (ou date prévue)
     * Genre
     * Option d'ajout d'une photo
     * Option de consentement photo
     * Indication si naissance multiple
     * Indication si enfant à naître
   - Possibilité de modifier ou supprimer un enfant
 ```
@@ -1,8 +0,0 @@
 # Fichier déplacé / fusionné
 La procédure **API Gitea** est désormais documentée sous :
 **[26_GITEA-API.md](./26_GITEA-API.md)**
 L’ancienne copie `PROCEDURE-API-GITEA.md` est archivée dans
 `docs/archive/obsolete/` (doublon).
@@ -1,30 +1,19 @@
 # Archive documentation · P'titsPas
-Ce dossier regroupe les fichiers **sans préfixe numérique** à la racine de
+Fichiers **hors références actives** : brouillons livrés, CDC historiques, listes figées.
 `docs/` qui ne sont plus des **références actives**, ou qui sont des
 **brouillons / temporaires**.
 ## Règle de nommage (racine `docs/`)
- Les documents **normatifs** à la racine portent un préfixe **`NN_`**
+- Documents **normatifs** : préfixe **`NN_`**.
-  (deux chiffres), ex. `23_LISTE-TICKETS.md`.
+- Exceptions héritage listées dans [00_INDEX.md](../00_INDEX.md) (`CHARTE_GRAPHIQUE.md`, `EVOLUTIONS_CDC.md`).
 - **Exceptions** (héritage ou outillage) listées dans
  [**00_INDEX.md**](../00_INDEX.md#exceptions-de-nommage) : charte, CDC
  historique, évolutions — **cible** : les renommer progressivement en `NN_`
  et mettre à jour `.cursorrules` / liens.
-## Sous-dossiers ici
+## Sous-dossiers
 | Dossier | Usage |
 |---------|--------|
-| [**temporaires/**](./temporaires/) | Notes jetables, exports de travail.
+| [**temporaires/**](./temporaires/) | Brouillons jetables. **Vider** dès livraison. |
-  **Supprimables** quand la tâche associée est close. |
+| [**obsolete/**](./obsolete/) | Doc remplacée (CDC SuperNounou, ancienne liste tickets, notes ponctuelles, backlog Phase 2 figé). |
 | [**obsolete/**](./obsolete/) | Ancienne doc **remplacée** ou **doublon**
  (conservée un temps pour historique). **Supprimer** après bascule confirmée
  si plus aucune référence. |
-## Hors `docs/` racine
+## Politique `tmp/`
-Les dossiers thématiques (**`juridique/`**, **`test-data/`**, etc.) peuvent
+Le dossier `docs/tmp/` **n’est plus utilisé**. Les mini-specs de tickets livrés sont purgés ; la mémoire produit = bilans de version (`29_…`) + tickets Gitea.
 contenir des fichiers sans `NN_` : la règle `NN_` s’applique surtout aux
 fichiers **directement** sous `docs/`.
@@ -4,11 +4,13 @@ Ancienne documentation **déplacée** depuis `docs/` :
 | Fichier | Motif |
 |---------|--------|
-| `PROCEDURE-API-GITEA.md` | Doublon fonctionnel de
+| `PROCEDURE-API-GITEA.md` | Doublon de [26_GITEA-API.md](../../26_GITEA-API.md) |
-  [**26_GITEA-API.md**](../../26_GITEA-API.md). |
+| `ARCHITECTURE_TECHNIQUE.md` | Remplacé par [02_ARCHITECTURE.md](../../02_ARCHITECTURE.md) |
-| `ARCHITECTURE_TECHNIQUE.md` | Non référencé ; la vue d’ensemble est dans
+| `STATUS-APPLICATION.md` | Instantané daté |
-  [**02_ARCHITECTURE.md**](../../02_ARCHITECTURE.md). |
+| `23_LISTE-TICKETS.md` | Liste Phase 1 figée (avr. 2026) — suivi = Gitea + bilans |
-| `STATUS-APPLICATION.md` | Instantané daté ; non tenu comme doc vivante. |
+| `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 |
-Après vérification qu’aucun lien externe ne pointe encore vers ces chemins, on
+Mémoire produit des versions livrées : [29_BILAN-VERSION-0.1.0.md](../../29_BILAN-VERSION-0.1.0.md).
 peut **supprimer** ce sous-dossier ou ne garder que des pointeurs minimalistes.
@@ -1,127 +0,0 @@
 # #131 — En-tête fiche parent : co-parent (note front → back)
 **Ticket :** #131 (fiche parent dashboard, doc `28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md` §6.1)  
 **Date :** 2026-06-01  
 **Statut front :** livré (en-tête dynamique)  
 **Modif backend demandée :** **aucune fonctionnelle** — ce document fixe le contrat attendu ; le back valide `co_parent` et masque les champs sensibles.
 ---
 ## 1. Comportement UI (front)
 Dans la modale **fiche parent** (`AdminParentEditModal`) :
 | Zone | Contenu |
 |------|---------|
 | **Titre** | `prenom` + `nom` du parent affiché (plus le libellé fixe « Fiche parent ») |
 | **Sous-titre** | `Co-parent : {prenom} {nom}` — affiché **uniquement** si un co-parent est connu |
 Le titre se met à jour en direct pendant l’édition des champs nom/prénom.  
 Le sous-titre provient du co-parent **chargé depuis l’API** (pas saisi à la main dans la modale).
 ---
 ## 2. Endpoints consommés
 | Méthode | Route | Usage front |
 |---------|-------|-------------|
 | `GET` | `/api/v1/parents` | Liste parents (onglet Parents) |
 | `GET` | `/api/v1/parents/:userId` | Rechargement fiche après rattachement/détachement enfant |
 | `PATCH` | `/api/v1/parents/:userId/fiche` | Sauvegarde identité + statut (inchangé) |
 Rôles : `super_admin`, `gestionnaire`, `administrateur` (selon route).
 ---
 ## 3. Contrat JSON attendu pour `co_parent`
 Le front parse `ParentModel.fromJson` avec la clé **`co_parent`** (snake_case), objet utilisateur imbriqué.
 ### Champs minimum utilisés pour le sous-titre
 | Clé JSON | Usage |
 |----------|--------|
 | `co_parent` | Objet ou absent/`null` |
 | `co_parent.id` | Identifiant (futur lien cliquable éventuel) |
 | `co_parent.prenom` | Affichage |
 | `co_parent.nom` | Affichage |
 Affichage front : `'{prenom} {nom}'.trim()` → libellé `Co-parent : …`.
 ### Exemple de fragment de réponse (`GET /parents/:id`)
 ```json
 {
  "user_id": "33333333-3333-3333-3333-333333333333",
  "numero_dossier": "2026-000042",
  "user": {
    "id": "33333333-3333-3333-3333-333333333333",
    "email": "parent1@example.com",
    "prenom": "Paul",
    "nom": "PARENT",
    "statut": "actif",
    "telephone": "0601020304"
  },
  "co_parent": {
    "id": "44444444-4444-4444-4444-444444444444",
    "email": "coparent1@example.com",
    "prenom": "Clara",
    "nom": "COPARENT",
    "role": "parent",
    "statut": "actif"
  },
  "parentChildren": []
 }
 ```
 > **Note :** le front lit `user` (pas `utilisateur`). La doc `11_API.md` § Parents mentionne encore `utilisateur` / `id_co_parent` seul — le contrat **effectif** côté Nest/TypeORM est l’entité `Parents` sérialisée (`user`, `co_parent`, `parentChildren`, …).
 ---
 ## 4. État backend
 ### Relations (déjà en place)
 - `findAll()` et `findOne(user_id)` chargent **`co_parent`** ;
 - FK : `parents.id_co_parent` → `utilisateurs.id` ;
 - inscription couple : les deux sens renseignés en principe (`auth.service.ts`).
 ### Livraison back (#131)
 - `mapParentForApi` / `sanitizeUserForApi` : réponses `GET/PATCH/POST/DELETE` parents **sans** `password`, `token_creation_mdp`, `password_reset_*` sur `user` et `co_parent`.
 **Checklist validation :**
 - [x] `GET /parents/:id` renvoie `co_parent` peuplé quand `id_co_parent` est non null
 - [x] `GET /parents` (liste) inclut `co_parent`
 - [x] `prenom` / `nom` du co-parent présents
 - [x] Pas de fuite `password` / tokens sur `user` ni `co_parent`
 ---
 ## 5. Points d’attention (hors périmètre immédiat)
 | Sujet | Détail |
 |-------|--------|
 | **Lien inverse** | Si B est co-parent de A (`A.id_co_parent = B`) mais `B.id_co_parent` est `null`, le sous-titre **ne s’affichera pas** sur la fiche de B. Pas de résolution inverse côté front. |
 | **Familles > 2 adultes** | Sous-titre = co-parent direct (`id_co_parent`) uniquement. |
 | **Trou AM ↔ enfants en garde** | Pas de lien AM–enfant aujourd’hui (à documenter / traiter plus tard). |
 ---
 ## 6. Fichiers back concernés
 | Fichier | Rôle |
 |---------|------|
 | `backend/src/routes/parents/parents.service.ts` | `findOne`, `findAll` + relations |
 | `backend/src/routes/parents/parents.controller.ts` | `mapParentForApi` sur les réponses |
 | `backend/src/routes/parents/parents.mapper.ts` | Sérialisation API |
 | `backend/src/common/utils/sanitize-user-for-api.ts` | Masquage secrets |
 | `backend/src/entities/parents.entity.ts` | relation `co_parent` |
 ---
 ## 7. Références
 - `docs/28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md` §6.1
 - Ticket Gitea **#131**
@@ -1,36 +0,0 @@
 # Archivé docs/archive/temporaires/ — export jetable, supprimer si inutile.
 Point tickets frontend (API Gitea) - 27/01/2026
 ================================================
 Issues avec label "frontend" : 20 (ouvertes: 12, fermees: 8)
 Num | Etat   | Titre
 ----+--------+--------------------------------------------------------
 35 | open   | [Frontend] Écran Création Gestionnaire
 36 | closed | [Frontend] Inscription Parent - Étape 1 (Parent 1)
 37 | closed | [Frontend] Inscription Parent - Étape 2 (Parent 2)
 38 | closed | [Frontend] Inscription Parent - Étape 3 (Enfants)
 39 | closed | [Frontend] Inscription Parent - Étapes 4-6 (Finalisatio
 40 | closed | [Frontend] Inscription AM - Panneau 1 (Identité)
 41 | closed | [Frontend] Inscription AM - Panneau 2 (Infos pro)
 42 | closed | [Frontend] Inscription AM - Finalisation
 43 | open   | [Frontend] Écran Création Mot de Passe
 44 | closed | [Frontend] Dashboard Gestionnaire - Structure
 45 | open   | [Frontend] Dashboard Gestionnaire - Liste Parents
 46 | open   | [Frontend] Dashboard Gestionnaire - Liste AM
 47 | open   | [Frontend] Écran Changement MDP Obligatoire
 48 | open   | [Frontend] Gestion Erreurs & Messages
 49 | open   | [Frontend] Écran Gestion Documents Légaux (Admin)
 50 | open   | [Frontend] Affichage dynamique CGU lors inscription
 51 | open   | [Frontend] Écran Logs Admin (optionnel v1.1)
 54 | open   | [Tests] Tests E2E Frontend
 82 | closed | [Frontend] Adapter �cran Login pour mobile
 83 | closed | [Frontend] Adapter �cran Choix Inscription pour mobile
 Suivi doc 23_LISTE-TICKETS (Gitea #73,78,79,81,82,83):
  #73 closed labels=[]
  #78 closed labels=[]
  #79 closed labels=[]
  #81 closed labels=[]
  #82 closed (écran Login mobile)
  #83 closed labels=['frontend', 'p3', 'phase-1', 'ux']
@@ -1,10 +1,11 @@
 # Temporaires
-Fichiers **non numérotés** de travail (brouillons, listes de tickets exportées,
+Dossier **vide** après clôture 0.1.0 (purge sept. 2026).
 alignements UI en cours, etc.).
- Préfixe conseillé pour les nouveaux fichiers jetables : **`TEMP_`** ou
+Si un brouillon de travail est nécessaire un temps :
-  **`WIP_`** dans ce dossier.
+
- **Suppression** : dès que la fonctionnalité est livrée ou le sujet clos,
+- le placer ici avec préfixe `TEMP_` / `WIP_` ;
-  supprimer le fichier (ou le déplacer vers `obsolete/` si une trace utile
+- le **supprimer** dès livraison (ne pas laisser pourrir) ;
-  reste nécessaire).
+- pour une trace utile durable → bilan de version ou archive `obsolete/`.
 Ne plus utiliser `docs/tmp/`.
@@ -1,244 +0,0 @@
 # #112 — Alignement front après évolution back (reprise dossier complet)
 **Branche déployée :** `feature/112-reprise-apres-refus-front`  
 **Commit back :** `d70577b1` — `feat(#112): reprise après refus — dossier complet GET/PATCH`  
 **Date :** 2026-06-16
 Ce document décrit le **contrat API réel** après extension du back, et ce que le front doit encore brancher pour exploiter le dossier complet (au-delà de l’identité seule).
 ---
 ## 1. Endpoints (inchangés côté URL)
 | Méthode | Route | Auth |
 |---------|-------|------|
 | `GET` | `/api/v1/auth/reprise-dossier?token={uuid}` | Public |
 | `PATCH` | `/api/v1/auth/reprise-resoumettre` | Public |
 | `POST` | `/api/v1/auth/reprise-identify` | Public (inchangé) |
 > **Note :** le ticket #111 parlait de `PUT` ; l’implémentation reste en **`PATCH`** (comme avant).
 ---
 ## 2. `GET /auth/reprise-dossier` — réponse enrichie
 ### Champs communs (toujours présents)
 Identiques à avant : `id`, `email`, `prenom`, `nom`, `telephone`, `adresse`, `ville`, `code_postal`, `numero_dossier`, `role`, `photo_url`, `genre`, `situation_familiale`.
 ### Rôle `parent` (+ champs #119)
 Alignés sur `DossierFamilleCompletDto` :
 ```json
 {
  "parents": [
    {
      "user_id": "uuid",
      "email": "…",
      "prenom": "…",
      "nom": "…",
      "telephone": "…",
      "adresse": "…",
      "ville": "…",
      "code_postal": "…",
      "statut": "refuse",
      "co_parent_id": "uuid-parent-entity"
    }
  ],
  "enfants": [
    {
      "id": "uuid-enfant",
      "first_name": "Emma",
      "last_name": "MARTIN",
      "genre": "F",
      "status": "actif",
      "birth_date": "2023-02-15T00:00:00.000Z",
      "due_date": null,
      "photo_url": "/uploads/photos/…",
      "consent_photo": true,
      "est_multiple": false
    }
  ],
  "texte_motivation": "Nous recherchons…"
 }
 ```
 **Mapping front suggéré :**
 | JSON back | Modèle / wizard parent |
 |-----------|-------------------------|
 | `parents[]` | `UserRegistrationData.parent1` + `parent2` (matcher par `email` ou ordre : titulaire = `id` du GET racine) |
 | `enfants[].first_name` / `last_name` | `ChildData.firstName` / `lastName` |
 | `enfants[].birth_date` | `ChildData.birthDate` (ISO → `DateTime`) |
 | `enfants[].due_date` | `ChildData.dueDate` (enfant `a_naitre`) |
 | `enfants[].status` | `actif` = né, `a_naitre` = à naître |
 | `enfants[].photo_url` | `ApiConfig.absoluteMediaUrl()` + conserver pour reprise sans re-upload |
 | `enfants[].id` | **Obligatoire** pour le PATCH (update par id) |
 | `enfants[].est_multiple` | `grossesse_multiple` si utilisé |
 | `texte_motivation` | étape présentation / motivation |
 Si `numero_dossier` absent : pas de `parents[]` / `enfants[]` / `texte_motivation` (identité seule).
 ### Rôle `assistante_maternelle`
 Champs racine + fiche pro (structure **aplatie**, pas de sous-objet `user`) :
 ```json
 {
  "consentement_photo": true,
  "date_naissance": "1985-03-12T00:00:00.000Z",
  "lieu_naissance_ville": "Paris",
  "lieu_naissance_pays": "France",
  "numero_agrement": "AGR-2024-12345",
  "nir": "123456789012345",
  "date_agrement": "2024-06-01T00:00:00.000Z",
  "nb_max_enfants": 4,
  "place_disponible": 2,
  "biographie": "…"
 }
 ```
 **Mapping `AmRegistrationData` :**
 | JSON back | Champ front |
 |-----------|-------------|
 | `nb_max_enfants` | `capaciteAccueil` |
 | `place_disponible` | `placesDisponibles` |
 | `numero_agrement` | `numeroAgrement` |
 | `biographie` | `biographie` / présentation |
 | `photo_url` | déjà géré via `RepriseSession.photoUrl` |
 ---
 ## 3. `PATCH /auth/reprise-resoumettre` — body étendu
 ### Commun
 ```json
 { "token": "uuid-reprise" }
 ```
 ### Parent — champs à envoyer depuis le wizard
 | Champ PATCH | Source wizard | Notes |
 |-------------|---------------|-------|
 | `prenom`, `nom`, `telephone`, `adresse`, `ville`, `code_postal` | Parent 1 (titulaire token) | Champs racine |
 | `co_parent_prenom`, `co_parent_nom`, `co_parent_telephone` | Parent 2 | |
 | `co_parent_meme_adresse`, `co_parent_adresse`, `co_parent_code_postal`, `co_parent_ville` | Parent 2 adresse | |
 | `texte_motivation` **ou** `presentation_dossier` | Étape motivation | Les deux alias acceptés |
 | `enfants[]` | Liste enfants | Voir ci-dessous |
 **Structure `enfants[]` (miroir inscription + `id` obligatoire) :**
 ```json
 {
  "id": "uuid-enfant-existant",
  "prenom": "Emma",
  "nom": "MARTIN",
  "date_naissance": "2023-02-15",
  "date_previsionnelle_naissance": null,
  "genre": "F",
  "photo_base64": "data:image/jpeg;base64,…",
  "photo_filename": "emma.jpg",
  "grossesse_multiple": false
 }
 ```
 - **v1 back :** update par `id` uniquement — pas de création/suppression d’enfant.
 - Si `id` inconnu pour ce dossier → **400** `Enfant inconnu pour ce dossier : {id}`.
 - Sans nouvelle photo : ne pas envoyer `photo_base64` (l’existant est conservé).
 ### AM — champs à envoyer
 | Champ PATCH | Source |
 |-------------|--------|
 | Identité + `photo_url` ou `photo_base64` + `photo_filename` | Étapes 1–2 |
 | `consentement_photo`, `date_naissance`, `lieu_naissance_ville`, `lieu_naissance_pays` | Identité |
 | `numero_agrement`, `nir`, `date_agrement` | Pro |
 | `capacite_accueil`, `places_disponibles` | Pro |
 | `biographie` | Présentation |
 Validation NIR identique à l’inscription si `nir` fourni.
 ### Réponse succès (nouveau format)
 ```json
 {
  "message": "Dossier resoumis avec succès. Il est de nouveau en attente de validation.",
  "statut": "en_attente",
  "user_id": "uuid",
  "numero_dossier": "2026-000021"
 }
 ```
 Code HTTP : **200** (pas de corps `Users` brut comme l’ancien back).
 ### Effet métier
 - **Parent :** tous les users `role=parent` avec le même `numero_dossier` passent en `en_attente` ; `token_reprise` invalidé sur **tous** (symétrique refus #110).
 - **AM :** un seul user.
 ### E-mail accusé resoumission (parent)
 Après `PATCH` réussi, un e-mail est envoyé à **chaque parent** du dossier (`sendResoumissionPendingEmail`) :
 - confirmation de resoumission ;
 - rappel du **numéro de dossier** ;
 - mention « en attente de validation ».
 Échec SMTP : logué, **ne bloque pas** la resoumission (même règle que l'inscription initiale).
 ---
 ## 4. Fichiers front à modifier (checklist)
 ### Modèles
 - [ ] `lib/models/reprise_dossier.dart` — parser `parents[]`, `enfants[]`, `texte_motivation`, champs AM
 - [ ] Réutiliser ou mapper vers `DossierFamilleEnfant` / structures existantes (#119 admin) si possible
 ### Session / préremplissage
 - [ ] `lib/services/reprise_session.dart`
  - `applyToParent` : remplir parent1/parent2 depuis `parents[]`, enfants, motivation
  - `applyToAm` : remplir tous les champs AM
 ### API
 - [ ] `lib/services/auth_service.dart` — `resoumettreReprise()` : accepter body complet (parent + AM), pas seulement identité
 - [ ] Étendre `UserRegistrationData` / `AmRegistrationData` helpers `toReprisePatchBody()` si utile
 ### Écrans fin de parcours
 - [ ] `parent_register_step5_screen.dart` — PATCH avec co-parent, enfants, motivation
 - [ ] `am_register_step4_screen.dart` — PATCH avec fiche AM complète
 ### Hors scope back (inchangé)
 RIB / IBAN / attestation CAF (étape 5 wizard parent) : **non persistés** — rien à envoyer en reprise.
 ### Non implémenté front (ticket #112 initial)
 - [ ] Modale login « J’ai un numéro de dossier » → `POST /auth/reprise-identify` (back prêt, front absent)
 ---
 ## 5. Tests manuels suggérés
 1. Refuser un dossier parent complet (≥1 enfant + co-parent + motivation).
 2. Ouvrir le lien mail `/reprise?token=…`.
 3. Vérifier dans DevTools que le GET contient `enfants[]` et `texte_motivation`.
 4. Après branchement front : wizard prérempli sur toutes les étapes.
 5. Resoumettre → statut `en_attente` pour les deux parents ; dossier visible file validation admin (#119).
 ---
 ## 6. Références code back
 ```
 backend/src/routes/auth/dto/reprise-dossier.dto.ts
 backend/src/routes/auth/dto/resoumettre-reprise.dto.ts
 backend/src/routes/auth/dto/enfant-reprise.dto.ts
 backend/src/routes/auth/auth.service.ts  → getRepriseDossier, resoumettreReprise
 backend/src/routes/parents/dto/dossier-famille-complet.dto.ts
 ```
@@ -1,132 +0,0 @@
 # #131 — Fiche AM éditable + affiliation enfants (note front → back)
 **Ticket :** #131 (partie AM, doc `28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md` §6.1)  
 **Date :** 2026-06-01  
 **Statut front :** modale livrée (2 onglets) — **API affiliation AM↔enfant à implémenter**
 ---
 ## 1. Comportement UI (front)
 Modale `AdminAmEditModal` — même shell que la fiche parent (~930 px) :
 | Onglet | Contenu |
 |--------|---------|
 | **Identité & professionnel** | `IdentityBlock` éditable + grille pro (agrément, ville résidence, capacité, places, NIR/agrément date en lecture seule, biographie, switch disponible) + gélule statut |
 | **Enfants accueillis** | Liste cartes enfants (réutilise `AdminChildrenAffiliationPanel` / `AdminEnfantUserCard`) + rattacher / détacher |
 En-tête : prénom nom · sous-titre `Zone · Agrément · Dossier`.
 ---
 ## 2. Endpoints consommés
 ### Déjà existants (partiels)
 | Méthode | Route | Usage |
 |---------|-------|-------|
 | `GET` | `/api/v1/assistantes-maternelles` | Liste AM |
 | `GET` | `/api/v1/assistantes-maternelles/:userId` | Détail (403 possible pour `administrateur` → fallback liste) |
 | `PATCH` | `/api/v1/users/:userId` | Identité + statut (admin / super_admin uniquement) |
 | `PATCH` | `/api/v1/assistantes-maternelles/:userId` | Champs pro (gestionnaire / super_admin) |
 ### À créer (recommandé — miroir parent #131 / #115)
 | Méthode | Route | Rôle |
 |---------|-------|------|
 | `PATCH` | `/api/v1/assistantes-maternelles/:userId/fiche` | Mise à jour unifiée identité + pro + statut (`super_admin`, `gestionnaire`, `administrateur`) |
 | `POST` | `/api/v1/assistantes-maternelles/:userId/enfants/:enfantId` | Rattacher un enfant |
 | `DELETE` | `/api/v1/assistantes-maternelles/:userId/enfants/:enfantId` | Détacher un enfant |
 | `GET` | `/api/v1/assistantes-maternelles/:userId` | Inclure `amChildren[]` (relation enfant) |
 Le front appelle déjà ces routes ; en l’absence de `PATCH …/fiche`, il tente un fallback `PATCH users` + `PATCH assistantes-maternelles` (échoue selon le rôle connecté).
 ---
 ## 3. Modèle de données affiliation AM ↔ enfant
 **À définir côté BDD** (pas de table dédiée aujourd’hui, contrairement à `enfants_parents`) :
 Proposition alignée parent :
 ```sql
 -- Piste : enfants_assistantes_maternelles
 CREATE TABLE enfants_assistantes_maternelles (
  id_am UUID NOT NULL REFERENCES utilisateurs(id) ON DELETE CASCADE,
  id_enfant UUID NOT NULL REFERENCES enfants(id) ON DELETE CASCADE,
  PRIMARY KEY (id_am, id_enfant)
 );
 ```
 Réponse API attendue sur `GET /assistantes-maternelles/:id` :
 ```json
 {
  "user_id": "uuid-am",
  "user": { "id": "…", "prenom": "Claire", "nom": "MARTIN", "statut": "actif" },
  "approval_number": "AGR-2024-12345",
  "residence_city": "Bezons",
  "max_children": 4,
  "places_available": 2,
  "available": true,
  "amChildren": [
    {
      "child": {
        "id": "uuid-enfant",
        "first_name": "Emma",
        "last_name": "MARTIN",
        "status": "actif",
        "birth_date": "2023-02-15"
      }
    }
  ]
 }
 ```
 Le front parse `amChildren` / `am_children` / `assistanteChildren` (même logique que `parentChildren`).
 ---
 ## 4. Body `PATCH …/fiche` suggéré
 ```json
 {
  "nom": "MARTIN",
  "prenom": "Claire",
  "email": "claire@example.com",
  "telephone": "0612345678",
  "adresse": "5 place Bellecour",
  "ville": "Lyon",
  "code_postal": "69002",
  "statut": "actif",
  "approval_number": "AGR-2024-12345",
  "residence_city": "Lyon",
  "max_children": 4,
  "places_available": 2,
  "biography": "…",
  "available": true
 }
 ```
 NIR et date d’agrément : lecture seule dans la modale (modification hors périmètre admin v1).
 ---
 ## 5. Fichiers front concernés
 | Fichier | Rôle |
 |---------|------|
 | `frontend/lib/widgets/admin/common/admin_am_edit_modal.dart` | Modale 2 onglets |
 | `frontend/lib/widgets/admin/common/admin_children_affiliation_panel.dart` | Liste enfants partagée parent/AM |
 | `frontend/lib/widgets/admin/common/admin_status_capsule.dart` | Gélule statut partagée |
 | `frontend/lib/models/assistante_maternelle_model.dart` | Parse champs pro + `amChildren` |
 | `frontend/lib/services/user_service.dart` | `getAssistanteMaternelle`, `updateAmFiche`, `attachEnfantToAm`, `detachEnfantFromAm` |
 | `frontend/lib/widgets/admin/assistante_maternelle_management_widget.dart` | Ouverture modale au clic Modifier |
 ---
 ## 6. Références
 - Fiche parent : `PATCH /parents/:id/fiche`, `POST|DELETE /parents/:id/enfants/:enfantId`
 - Ticket Gitea **#131**, **#115**
 - `docs/archive/temporaires/TEMP_131-back-fiche-parent-co-parent.md`
@@ -1,124 +0,0 @@
 # #131 — En-tête fiche parent : co-parent (note front → back)
 **Ticket :** #131 (fiche parent dashboard, doc `28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md` §6.1)  
 **Date :** 2026-06-01  
 **Statut front :** livré (en-tête dynamique)  
 **Modif backend demandée :** **aucune** — ce document fixe le contrat attendu et invite à valider que l’existant le couvre.
 ---
 ## 1. Comportement UI (front)
 Dans la modale **fiche parent** (`AdminParentEditModal`) :
 | Zone | Contenu |
 |------|---------|
 | **Titre** | `prenom` + `nom` du parent affiché (plus le libellé fixe « Fiche parent ») |
 | **Sous-titre** | `Co-parent : {prenom} {nom}` — affiché **uniquement** si un co-parent est connu |
 Le titre se met à jour en direct pendant l’édition des champs nom/prénom.  
 Le sous-titre provient du co-parent **chargé depuis l’API** (pas saisi à la main dans la modale).
 ---
 ## 2. Endpoints consommés
 | Méthode | Route | Usage front |
 |---------|-------|-------------|
 | `GET` | `/api/v1/parents` | Liste parents (onglet Parents) |
 | `GET` | `/api/v1/parents/:userId` | Rechargement fiche après rattachement/détachement enfant |
 | `PATCH` | `/api/v1/parents/:userId/fiche` | Sauvegarde identité + statut (inchangé) |
 Rôles : `super_admin`, `gestionnaire`, `administrateur` (selon route).
 ---
 ## 3. Contrat JSON attendu pour `co_parent`
 Le front parse `ParentModel.fromJson` avec la clé **`co_parent`** (snake_case), objet utilisateur imbriqué.
 ### Champs minimum utilisés pour le sous-titre
 | Clé JSON | Usage |
 |----------|--------|
 | `co_parent` | Objet ou absent/`null` |
 | `co_parent.id` | Identifiant (futur lien cliquable éventuel) |
 | `co_parent.prenom` | Affichage |
 | `co_parent.nom` | Affichage |
 Affichage front : `'{prenom} {nom}'.trim()` → libellé `Co-parent : …`.
 ### Exemple de fragment de réponse (`GET /parents/:id`)
 ```json
 {
  "user_id": "33333333-3333-3333-3333-333333333333",
  "numero_dossier": "2026-000042",
  "user": {
    "id": "33333333-3333-3333-3333-333333333333",
    "email": "parent1@example.com",
    "prenom": "Paul",
    "nom": "PARENT",
    "statut": "actif",
    "telephone": "0601020304"
  },
  "co_parent": {
    "id": "44444444-4444-4444-4444-444444444444",
    "email": "coparent1@example.com",
    "prenom": "Clara",
    "nom": "COPARENT",
    "role": "parent",
    "statut": "actif"
  },
  "parentChildren": []
 }
 ```
 > **Note :** le front lit `user` (pas `utilisateur`). La doc `11_API.md` § Parents mentionne encore `utilisateur` / `id_co_parent` seul — le contrat **effectif** côté Nest/TypeORM est l’entité `Parents` sérialisée (`user`, `co_parent`, `parentChildren`, …).
 ---
 ## 4. État backend (à valider, pas à refaire)
 D’après le code actuel (`parents.service.ts`) :
 - `findAll()` et `findOne(user_id)` chargent déjà la relation **`co_parent`** ;
 - la FK métier est `parents.id_co_parent` → `utilisateurs.id` ;
 - à l’inscription couple, les deux sens sont en principe renseignés (`auth.service.ts`).
 **Checklist validation back :**
 - [ ] `GET /parents/:id` renvoie bien `co_parent` peuplé quand `id_co_parent` est non null
 - [ ] `GET /parents` (liste) inclut aussi `co_parent` (sous-titre disponible dès l’ouverture sans re-fetch)
 - [ ] Les champs `prenom` / `nom` du co-parent sont présents dans la réponse JSON
 Si ces trois points passent en recette, **aucun changement backend n’est nécessaire** pour cette fonctionnalité.
 ---
 ## 5. Points d’attention (hors périmètre immédiat)
 | Sujet | Détail |
 |-------|--------|
 | **Lien inverse** | Si le parent B est le co-parent de A (`A.id_co_parent = B`) mais que `B.id_co_parent` est `null`, le sous-titre **ne s’affichera pas** sur la fiche de B. Le front ne fait pas de résolution inverse. À traiter côté back **seulement si** des données legacy ont un lien à sens unique. |
 | **Familles > 2 adultes** | Le sous-titre n’affiche que le co-parent direct (`id_co_parent`). Les autres responsables liés uniquement via `enfants_parents` ne sont pas listés ici (cf. doc 28 §6). |
 | **Données sensibles** | Vérifier que la sérialisation de `co_parent` n’expose pas `password` / tokens (même remarque que pour `user`). |
 ---
 ## 6. Fichiers front concernés
 | Fichier | Rôle |
 |---------|------|
 | `frontend/lib/models/parent_model.dart` | Parse `co_parent` → `AppUser? coParent` |
 | `frontend/lib/widgets/admin/common/admin_parent_edit_modal.dart` | Titre + sous-titre |
 | `frontend/lib/services/user_service.dart` | `getParents()` / `getParent()` |
 ---
 ## 7. Références
 - `docs/28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md` §6.1
 - `backend/src/routes/parents/parents.service.ts` — `findOne`, `findAll`
 - `backend/src/entities/parents.entity.ts` — relation `co_parent`
 - Ticket Gitea **#131**
@@ -1,46 +0,0 @@
 # TEMP — Alignement front / API (inscription AM & validation gestionnaire)
 > **Archivé** (`docs/archive/temporaires/`) — **fichier temporaire** ; à
 > **supprimer** une fois le front livré ou le sujet clos (voir
 > `docs/archive/temporaires/README.md`).
 Ce document décrit les changements **côté API** et ce que **Flutter** doit faire pour rester aligné. Aucune modification front n’a été faite dans le chantier backend associé.
 ## 1. `POST /auth/register/am` — lieu de naissance obligatoire
 - **`lieu_naissance_ville`** et **`lieu_naissance_pays`** sont **obligatoires** (non vides après trim, min. **2 caractères** chacun, max 100).
 - Réponses **400** si manquants ou invalides (messages class-validator).
 - **Action front** : champs obligatoires dans le parcours AM (étapes identité / naissance), validation UI avant envoi ; afficher les erreurs renvoyées par l’API.
 ## 2. Réponse `GET /dossiers/:numeroDossier` (type `am`)
 Sous `dossier.user`, l’API peut inclure :
 | Clé JSON | Description |
 |----------|-------------|
 | `date_naissance` | Date (si renseignée à l’inscription) |
 | `lieu_naissance_ville` | Ville de naissance |
 | `lieu_naissance_pays` | Pays de naissance |
 | `consentement_photo` | Booléen (exposé dans `dossier.user`) |
 À la **racine** de `dossier` (objet AM), champs déjà renvoyés par le backend : `disponible`, `annees_experience`, `specialite`, `nb_max_enfants`, `place_disponible`, etc.
 **Action front** :
 - Étendre **`AppUser.fromJson` / `toJson`** (`lib/models/user.dart`) pour mapper `date_naissance`, `lieu_naissance_ville`, `lieu_naissance_pays`, `consentement_photo`.
 - Étendre **`DossierAM.fromJson`** (`lib/models/dossier_unifie.dart`) pour parser `disponible`, `annees_experience`, `specialite` à la racine du dossier (noms snake_case comme dans la réponse JSON Nest).
 ## 3. `ValidationAmWizard` (admin)
 Afficher pour cohérence avec le formulaire d’inscription :
 - **Informations personnelles** : date de naissance, ville / pays de naissance, consentement photo (Oui/Non).
 - **Informations professionnelles** : disponibilité, années d’expérience, spécialité (afficher « – » si `null`).
 ## 4. `place_disponible` à l’inscription
 - Le backend initialise **`place_disponible`** sur la fiche AM à la **même valeur** que **`capacite_accueil`** à la création. Le wizard peut donc afficher une valeur cohérente avec la capacité sans champ séparé côté public.
 ---
 *Dernière mise à jour : alignement backend branche `feature/120-inscription-am-photo-backend`.*
@@ -1,244 +0,0 @@
 # #112 — Alignement front après évolution back (reprise dossier complet)
 **Branche déployée :** `feature/112-reprise-apres-refus-front`  
 **Commit back :** `d70577b1` — `feat(#112): reprise après refus — dossier complet GET/PATCH`  
 **Date :** 2026-06-16
 Ce document décrit le **contrat API réel** après extension du back, et ce que le front doit encore brancher pour exploiter le dossier complet (au-delà de l’identité seule).
 ---
 ## 1. Endpoints (inchangés côté URL)
 | Méthode | Route | Auth |
 |---------|-------|------|
 | `GET` | `/api/v1/auth/reprise-dossier?token={uuid}` | Public |
 | `PATCH` | `/api/v1/auth/reprise-resoumettre` | Public |
 | `POST` | `/api/v1/auth/reprise-identify` | Public (inchangé) |
 > **Note :** le ticket #111 parlait de `PUT` ; l’implémentation reste en **`PATCH`** (comme avant).
 ---
 ## 2. `GET /auth/reprise-dossier` — réponse enrichie
 ### Champs communs (toujours présents)
 Identiques à avant : `id`, `email`, `prenom`, `nom`, `telephone`, `adresse`, `ville`, `code_postal`, `numero_dossier`, `role`, `photo_url`, `genre`, `situation_familiale`.
 ### Rôle `parent` (+ champs #119)
 Alignés sur `DossierFamilleCompletDto` :
 ```json
 {
  "parents": [
    {
      "user_id": "uuid",
      "email": "…",
      "prenom": "…",
      "nom": "…",
      "telephone": "…",
      "adresse": "…",
      "ville": "…",
      "code_postal": "…",
      "statut": "refuse",
      "co_parent_id": "uuid-parent-entity"
    }
  ],
  "enfants": [
    {
      "id": "uuid-enfant",
      "first_name": "Emma",
      "last_name": "MARTIN",
      "genre": "F",
      "status": "actif",
      "birth_date": "2023-02-15T00:00:00.000Z",
      "due_date": null,
      "photo_url": "/uploads/photos/…",
      "consent_photo": true,
      "est_multiple": false
    }
  ],
  "texte_motivation": "Nous recherchons…"
 }
 ```
 **Mapping front suggéré :**
 | JSON back | Modèle / wizard parent |
 |-----------|-------------------------|
 | `parents[]` | `UserRegistrationData.parent1` + `parent2` (matcher par `email` ou ordre : titulaire = `id` du GET racine) |
 | `enfants[].first_name` / `last_name` | `ChildData.firstName` / `lastName` |
 | `enfants[].birth_date` | `ChildData.birthDate` (ISO → `DateTime`) |
 | `enfants[].due_date` | `ChildData.dueDate` (enfant `a_naitre`) |
 | `enfants[].status` | `actif` = né, `a_naitre` = à naître |
 | `enfants[].photo_url` | `ApiConfig.absoluteMediaUrl()` + conserver pour reprise sans re-upload |
 | `enfants[].id` | **Obligatoire** pour le PATCH (update par id) |
 | `enfants[].est_multiple` | `grossesse_multiple` si utilisé |
 | `texte_motivation` | étape présentation / motivation |
 Si `numero_dossier` absent : pas de `parents[]` / `enfants[]` / `texte_motivation` (identité seule).
 ### Rôle `assistante_maternelle`
 Champs racine + fiche pro (structure **aplatie**, pas de sous-objet `user`) :
 ```json
 {
  "consentement_photo": true,
  "date_naissance": "1985-03-12T00:00:00.000Z",
  "lieu_naissance_ville": "Paris",
  "lieu_naissance_pays": "France",
  "numero_agrement": "AGR-2024-12345",
  "nir": "123456789012345",
  "date_agrement": "2024-06-01T00:00:00.000Z",
  "nb_max_enfants": 4,
  "place_disponible": 2,
  "biographie": "…"
 }
 ```
 **Mapping `AmRegistrationData` :**
 | JSON back | Champ front |
 |-----------|-------------|
 | `nb_max_enfants` | `capaciteAccueil` |
 | `place_disponible` | `placesDisponibles` |
 | `numero_agrement` | `numeroAgrement` |
 | `biographie` | `biographie` / présentation |
 | `photo_url` | déjà géré via `RepriseSession.photoUrl` |
 ---
 ## 3. `PATCH /auth/reprise-resoumettre` — body étendu
 ### Commun
 ```json
 { "token": "uuid-reprise" }
 ```
 ### Parent — champs à envoyer depuis le wizard
 | Champ PATCH | Source wizard | Notes |
 |-------------|---------------|-------|
 | `prenom`, `nom`, `telephone`, `adresse`, `ville`, `code_postal` | Parent 1 (titulaire token) | Champs racine |
 | `co_parent_prenom`, `co_parent_nom`, `co_parent_telephone` | Parent 2 | |
 | `co_parent_meme_adresse`, `co_parent_adresse`, `co_parent_code_postal`, `co_parent_ville` | Parent 2 adresse | |
 | `texte_motivation` **ou** `presentation_dossier` | Étape motivation | Les deux alias acceptés |
 | `enfants[]` | Liste enfants | Voir ci-dessous |
 **Structure `enfants[]` (miroir inscription + `id` obligatoire) :**
 ```json
 {
  "id": "uuid-enfant-existant",
  "prenom": "Emma",
  "nom": "MARTIN",
  "date_naissance": "2023-02-15",
  "date_previsionnelle_naissance": null,
  "genre": "F",
  "photo_base64": "data:image/jpeg;base64,…",
  "photo_filename": "emma.jpg",
  "grossesse_multiple": false
 }
 ```
 - **v1 back :** update par `id` uniquement — pas de création/suppression d’enfant.
 - Si `id` inconnu pour ce dossier → **400** `Enfant inconnu pour ce dossier : {id}`.
 - Sans nouvelle photo : ne pas envoyer `photo_base64` (l’existant est conservé).
 ### AM — champs à envoyer
 | Champ PATCH | Source |
 |-------------|--------|
 | Identité + `photo_url` ou `photo_base64` + `photo_filename` | Étapes 1–2 |
 | `consentement_photo`, `date_naissance`, `lieu_naissance_ville`, `lieu_naissance_pays` | Identité |
 | `numero_agrement`, `nir`, `date_agrement` | Pro |
 | `capacite_accueil`, `places_disponibles` | Pro |
 | `biographie` | Présentation |
 Validation NIR identique à l’inscription si `nir` fourni.
 ### Réponse succès (nouveau format)
 ```json
 {
  "message": "Dossier resoumis avec succès. Il est de nouveau en attente de validation.",
  "statut": "en_attente",
  "user_id": "uuid",
  "numero_dossier": "2026-000021"
 }
 ```
 Code HTTP : **200** (pas de corps `Users` brut comme l’ancien back).
 ### Effet métier
 - **Parent :** tous les users `role=parent` avec le même `numero_dossier` passent en `en_attente` ; `token_reprise` invalidé sur **tous** (symétrique refus #110).
 - **AM :** un seul user.
 ### E-mail accusé resoumission (parent)
 Après `PATCH` réussi, un e-mail est envoyé à **chaque parent** du dossier (`sendResoumissionPendingEmail`) :
 - confirmation de resoumission ;
 - rappel du **numéro de dossier** ;
 - mention « en attente de validation ».
 Échec SMTP : logué, **ne bloque pas** la resoumission (même règle que l'inscription initiale).
 ---
 ## 4. Fichiers front à modifier (checklist)
 ### Modèles
 - [ ] `lib/models/reprise_dossier.dart` — parser `parents[]`, `enfants[]`, `texte_motivation`, champs AM
 - [ ] Réutiliser ou mapper vers `DossierFamilleEnfant` / structures existantes (#119 admin) si possible
 ### Session / préremplissage
 - [ ] `lib/services/reprise_session.dart`
  - `applyToParent` : remplir parent1/parent2 depuis `parents[]`, enfants, motivation
  - `applyToAm` : remplir tous les champs AM
 ### API
 - [ ] `lib/services/auth_service.dart` — `resoumettreReprise()` : accepter body complet (parent + AM), pas seulement identité
 - [ ] Étendre `UserRegistrationData` / `AmRegistrationData` helpers `toReprisePatchBody()` si utile
 ### Écrans fin de parcours
 - [ ] `parent_register_step5_screen.dart` — PATCH avec co-parent, enfants, motivation
 - [ ] `am_register_step4_screen.dart` — PATCH avec fiche AM complète
 ### Hors scope back (inchangé)
 RIB / IBAN / attestation CAF (étape 5 wizard parent) : **non persistés** — rien à envoyer en reprise.
 ### Non implémenté front (ticket #112 initial)
 - [ ] Modale login « J’ai un numéro de dossier » → `POST /auth/reprise-identify` (back prêt, front absent)
 ---
 ## 5. Tests manuels suggérés
 1. Refuser un dossier parent complet (≥1 enfant + co-parent + motivation).
 2. Ouvrir le lien mail `/reprise?token=…`.
 3. Vérifier dans DevTools que le GET contient `enfants[]` et `texte_motivation`.
 4. Après branchement front : wizard prérempli sur toutes les étapes.
 5. Resoumettre → statut `en_attente` pour les deux parents ; dossier visible file validation admin (#119).
 ---
 ## 6. Références code back
 ```
 backend/src/routes/auth/dto/reprise-dossier.dto.ts
 backend/src/routes/auth/dto/resoumettre-reprise.dto.ts
 backend/src/routes/auth/dto/enfant-reprise.dto.ts
 backend/src/routes/auth/auth.service.ts  → getRepriseDossier, resoumettreReprise
 backend/src/routes/parents/dto/dossier-famille-complet.dto.ts
 ```
@@ -1,89 +0,0 @@
 # 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`
@@ -1,73 +0,0 @@
 # 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`
@@ -1,83 +0,0 @@
 # 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`
@@ -1,65 +0,0 @@
 # 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
@@ -1,77 +0,0 @@
 # 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`
@@ -1,167 +0,0 @@
 # 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`)
@@ -1,35 +0,0 @@
 # 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).
@@ -1,169 +0,0 @@
 # 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)
@@ -1,54 +0,0 @@
 # 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)
@@ -1,203 +0,0 @@
 # 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é
@@ -1,75 +0,0 @@
 # 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`
@@ -1,14 +0,0 @@
 # 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`