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
- [**01 - Cahier des Charges**](./01_CAHIER-DES-CHARGES.md) - Cahier des charges complet du projet P'titsPas (V1.3 - 24/11/2025)
+## Architecture & infra

-### Architecture & Infrastructure
- [**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
+| Doc | Contenu |
+|-----|---------|
+| [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
- [**04 - Roadmap Générale**](./04_ROADMAP-GENERALE.md) - Roadmap complète du projet (Phases 1 à 5+)
+## Workflows & métier

-### Développement
- [**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
- [**14 - Note backend config setup**](./14_NOTE-BACKEND-CONFIG-SETUP.md) - Setup configuration
- [**92 - Note backend gestionnaires**](./92_NOTE-BACKEND-GESTIONNAIRES.md) - Gestionnaires
- [**99 - Règles de codage**](./99_REGLES-CODAGE.md) - Conventions de code
+| Doc | Contenu |
+|-----|---------|
+| [20 — Workflow création de compte](./20_WORKFLOW-CREATION-COMPTE.md) | Inscription / validation |
+| [juridique/](./juridique/README.md) | CGU / CGC / privacy + [22 technique](./juridique/22_DOCUMENTS-LEGAUX.md) |
+| [CHARTE_GRAPHIQUE.md](./CHARTE_GRAPHIQUE.md) | Charte UI |

-### Workflows Fonctionnels
- [**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
+## Projet & outillage

-### Juridique (sources & technique)
- [**Dossier juridique**](./juridique/README.md) - Index : CGU/CGC en Markdown,
-  export PDF, lien vers la doc technique n°22
+| Doc | Contenu |
+|-----|---------|
+| [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)
- [**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)
+## Audit

-### Archive & convention de nommage
- [**Dossier archive**](./archive/README.md) - Fichiers **sans** `NN_` déplacés
-  (temporaires, obsolètes) ; règles de rangement et suppression
- Pointeur : [PROCEDURE-API-GITEA.md](./PROCEDURE-API-GITEA.md) → voir **26**
+| Doc | Contenu |
+|-----|---------|
+| [90 — Audit YNOV](./90_AUDIT.md) | Analyse code étudiant |

-### Exceptions de nommage (racine `docs/`)
-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`
+## Archive

-### Administration (À créer)
- [**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
+| Emplacement | Usage |
+|-------------|--------|
+| [archive/](./archive/README.md) | Obsolete / temporaires |
+| [archive/obsolete/](./archive/obsolete/) | CDC SuperNounou, ancienne liste tickets, backlog Phase 2 figé, notes ponctuelles |

-### Frontend (À créer)
- [**40 - Frontend Flutter**](./40_FRONTEND.md) - Structure de l'application mobile/web
+## Données de test

-### Audit & Analyse
- [**90 - Audit du projet YNOV**](./90_AUDIT.md) - Analyse complète du code étudiant et fonctionnalités
+| Doc | Contenu |
+|-----|---------|
+| [test-data/](./test-data/README.md) | Jeux utilisateurs test |

-## 🚀 Quick Start
+## Quick start

 ```bash
-# Cloner le projet
-git clone ssh://gitea-jmartin/jmartin/app.git ptitspas-app
-
-# Lancer l'environnement de développement
+git clone … ptitspas-app
 cd ptitspas-app
 docker compose up -d
-
-# Accéder aux services
-Frontend: https://app.ptits-pas.fr
-API: https://app.ptits-pas.fr/api
-PgAdmin: https://app.ptits-pas.fr/pgadmin
+# Front https://app.ptits-pas.fr — API /api — PgAdmin /pgadmin
 ```

-## 🔗 Liens utiles
+## Liens

- **Gitea** : https://git.ptits-pas.fr
- **Production** : 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
+- Gitea : https://git.ptits-pas.fr/jmartin/petitspas  
+- Prod : https://app.ptits-pas.fr  

+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 |
-|---------|----------|---------|------------|
-| **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** |
+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)**.

-### 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/
-├── 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
+├── 23_SUIVI-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
-`docs/` qui ne sont plus des **références actives**, ou qui sont des
-**brouillons / temporaires**.
+Fichiers **hors références actives** : brouillons livrés, CDC historiques, listes figées.

 ## Règle de nommage (racine `docs/`)

- Les documents **normatifs** à la racine portent un préfixe **`NN_`**
-  (deux chiffres), ex. `23_LISTE-TICKETS.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.
+- Documents **normatifs** : préfixe **`NN_`**.
+- Exceptions héritage listées dans [00_INDEX.md](../00_INDEX.md) (`CHARTE_GRAPHIQUE.md`, `EVOLUTIONS_CDC.md`).

-## Sous-dossiers ici
+## Sous-dossiers

 | Dossier | Usage |
 |---------|--------|
-| [**temporaires/**](./temporaires/) | Notes jetables, exports de travail.
-  **Supprimables** quand la tâche associée est close. |
-| [**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. |
+| [**temporaires/**](./temporaires/) | Brouillons jetables. **Vider** dès livraison. |
+| [**obsolete/**](./obsolete/) | Doc remplacée (CDC SuperNounou, ancienne liste tickets, notes ponctuelles, backlog Phase 2 figé). |

-## Hors `docs/` racine
+## Politique `tmp/`

-Les dossiers thématiques (**`juridique/`**, **`test-data/`**, etc.) peuvent
-contenir des fichiers sans `NN_` : la règle `NN_` s’applique surtout aux
-fichiers **directement** sous `docs/`.
+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.
@@ -4,11 +4,13 @@ Ancienne documentation **déplacée** depuis `docs/` :

 | Fichier | Motif |
 |---------|--------|
-| `PROCEDURE-API-GITEA.md` | Doublon fonctionnel de
-  [**26_GITEA-API.md**](../../26_GITEA-API.md). |
-| `ARCHITECTURE_TECHNIQUE.md` | Non référencé ; la vue d’ensemble est dans
-  [**02_ARCHITECTURE.md**](../../02_ARCHITECTURE.md). |
-| `STATUS-APPLICATION.md` | Instantané daté ; non tenu comme doc vivante. |
+| `PROCEDURE-API-GITEA.md` | Doublon de [26_GITEA-API.md](../../26_GITEA-API.md) |
+| `ARCHITECTURE_TECHNIQUE.md` | Remplacé par [02_ARCHITECTURE.md](../../02_ARCHITECTURE.md) |
+| `STATUS-APPLICATION.md` | Instantané daté |
+| `23_LISTE-TICKETS.md` | Liste Phase 1 figée (avr. 2026) — suivi = Gitea + bilans |
+| `25_PHASE-2-BACKLOG.md` | Backlog technique figé — voir [05_VERSIONS…](../../05_VERSIONS-ET-MILESTONES.md) |
+| `SuperNounou_*` | CDC / SSS historiques |
+| `14_NOTE-BACKEND-CONFIG-SETUP.md` | Note ticket ponctuelle |
+| `92_NOTE-BACKEND-GESTIONNAIRES.md` | Note ticket ponctuelle |

-Après vérification qu’aucun lien externe ne pointe encore vers ces chemins, on
-peut **supprimer** ce sous-dossier ou ne garder que des pointeurs minimalistes.
+Mémoire produit des versions livrées : [29_BILAN-VERSION-0.1.0.md](../../29_BILAN-VERSION-0.1.0.md).
@@ -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,
-alignements UI en cours, etc.).
+Dossier **vide** après clôture 0.1.0 (purge sept. 2026).

- Préfixe conseillé pour les nouveaux fichiers jetables : **`TEMP_`** ou
-  **`WIP_`** dans ce dossier.
- **Suppression** : dès que la fonctionnalité est livrée ou le sujet clos,
-  supprimer le fichier (ou le déplacer vers `obsolete/` si une trace utile
-  reste nécessaire).
+Si un brouillon de travail est nécessaire un temps :
+
+- le placer ici avec préfixe `TEMP_` / `WIP_` ;
+- le **supprimer** dès livraison (ne pas laisser pourrir) ;
+- 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`