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

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>
2026-09-14 17:45:52 +02:00 · 2026-09-14 17:45:43 +02:00 · 2026-09-14 17:29:31 +02:00 · 2026-09-14 17:29:13 +02:00 · 2026-09-14 12:46:46 +02:00 · 2026-09-14 11:05:47 +02:00
26 changed files with 379 additions and 1107 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
-```