docs: norme merge squash (feature→develop→master)

Propagation depuis develop.

Co-authored-by: Julien Martin <julien.martin@ptits-pas.fr>

bash.exe.stackdump

@@ -0,0 +1,28 @@
+Stack trace:
+Frame         Function      Args
+0007FFFFAC10  00021005FEBA (000210285F48, 00021026AB6E, 000000000000, 0007FFFF9B10) msys-2.0.dll+0x1FEBA
+0007FFFFAC10  0002100467F9 (000000000000, 000000000000, 000000000000, 0007FFFFAEE8) msys-2.0.dll+0x67F9
+0007FFFFAC10  000210046832 (000210285FF9, 0007FFFFAAC8, 000000000000, 000000000000) msys-2.0.dll+0x6832
+0007FFFFAC10  000210068F86 (000000000000, 000000000000, 000000000000, 000000000000) msys-2.0.dll+0x28F86
+0007FFFFAC10  0002100690B4 (0007FFFFAC20, 000000000000, 000000000000, 000000000000) msys-2.0.dll+0x290B4
+0007FFFFAEF0  00021006A49D (0007FFFFAC20, 000000000000, 000000000000, 000000000000) msys-2.0.dll+0x2A49D
+End of stack trace
+Loaded modules:
+000100400000 bash.exe
+7FFE2CD00000 ntdll.dll
+7FFE2C1F0000 KERNEL32.DLL
+7FFE29C90000 KERNELBASE.dll
+7FFE2B8C0000 USER32.dll
+7FFE2A090000 win32u.dll
+7FFE2C410000 GDI32.dll
+7FFE29730000 gdi32full.dll
+7FFE29860000 msvcp_win.dll
+7FFE2A930000 ucrtbase.dll
+000210040000 msys-2.0.dll
+7FFE2C350000 advapi32.dll
+7FFE2B810000 msvcrt.dll
+7FFE2CC10000 sechost.dll
+7FFE2AB30000 RPCRT4.dll
+7FFE28D10000 CRYPTBASE.DLL
+7FFE29B50000 bcryptPrimitives.dll
+7FFE2CAD0000 IMM32.DLL

docs/24_DECISIONS-PROJET.md

@@ -1,7 +1,7 @@
 # 📋 Décisions Projet - P'titsPas
 
-**Version** : 1.2  
-**Date** : 16 Juin 2026  
+**Version** : 1.3  
+**Date** : 24 Septembre 2026  
 **Auteur** : Équipe PtitsPas
 
 ---
@@ -465,19 +465,34 @@ docs/
 
 ---
 
-### 26. Branches Git
+### 26. Branches Git + merge squash (norme)
 
-**Décision** : ✅ **Stratégie simple : master + feature branches**
+**Décision** : ✅ **`develop` + `master` + `feature/*`, merges en squash**
 
 **Justification** :
 - Simplicité (petite équipe)
-- Flexibilité
+- Historique lisible sur `develop` / `master` (1 commit = 1 ticket)
+- Déploiement prod uniquement depuis `master`
 
 **Branches** :
-- `master` : Production
-- `archive/*` : Archives (ex: maquette initiale)
-- `migration/*` : Migrations (ex: intégration YNOV)
-- `feature/*` : Nouvelles fonctionnalités
+- `master` : Production (déploiement auto)
+- `develop` : Intégration / recette
+- `feature/*` : Ticket en cours (depuis `develop`)
+- `archive/*`, `migration/*` : Archives / migrations ponctuelles
+
+**Flux (norme à partir de #169+)** :
+1. Branche `feature/N-…` depuis `develop`
+2. PR **feature → `develop`** : merge **squash** (`Do: squash` côté Gitea)
+3. Quand un lot est prêt : PR **`develop` → `master`** : merge **squash** également
+4. Message squash : `feat(#N): …` / `fix(#N): …` + `Closes #N` si applicable
+
+**Exception** : les merges `--no-ff` déjà poussés (ex. #167, #168) restent tels quels — pas de réécriture d’historique.
+
+**API Gitea** (rappel) :
+```http
+POST /repos/jmartin/petitspas/pulls/{index}/merge
+{"Do":"squash","MergeTitleField":"feat(#N): …","MergeMessageField":"Closes #N"}
+```
 
 ---
 

docs/26_GITEA-API.md

@@ -116,10 +116,17 @@ curl -s -H "Authorization: token $GITEA_TOKEN" \
   "https://git.ptits-pas.fr/api/v1/repos/jmartin/petitspas/pulls?state=open" | jq .
 
 # Créer une PR (head = branche source, base = branche cible)
+# Norme : feature/* → develop, puis develop → master
 curl -s -X POST -H "Authorization: token $GITEA_TOKEN" \
   -H "Content-Type: application/json" \
-  -d '{"head":"develop","base":"master","title":"Titre de la PR"}' \
+  -d '{"head":"feature/XX-nom","base":"develop","title":"feat(#XX): Titre","body":"Closes #XX"}' \
   "https://git.ptits-pas.fr/api/v1/repos/jmartin/petitspas/pulls"
+
+# Merger en squash (norme — voir 24_DECISIONS-PROJET.md §26)
+curl -s -X POST -H "Authorization: token $GITEA_TOKEN" \
+  -H "Content-Type: application/json" \
+  -d '{"Do":"squash","MergeTitleField":"feat(#XX): Titre","MergeMessageField":"Closes #XX"}' \
+  "https://git.ptits-pas.fr/api/v1/repos/jmartin/petitspas/pulls/{index}/merge"
 ```
 
 ### 3.4 Branches

docs/27_BRIEFING-FRONTEND.md

@@ -194,6 +194,9 @@ frontend/lib/
 
 ## Workflow Git
 
+Norme projet : **squash merge** (voir [24_DECISIONS-PROJET.md](./24_DECISIONS-PROJET.md) §26).  
+Cible habituelle : `feature/*` → `develop` ; puis `develop` → `master` quand le lot est prêt.
+
 ```bash
 # 1. Créer une branche feature
 git checkout develop
@@ -204,15 +207,22 @@ git checkout -b feature/XX-nom-ticket
 git add .
 git commit -m "feat(#XX): Description courte"
 
-# 3. Pousser et créer PR
+# 3. Pousser et créer PR vers develop
 git push -u origin feature/XX-nom-ticket
 
-# 4. Créer PR vers master via Gitea ou API
+# 4. Créer PR (base = develop)
 curl -X POST \
-  -H "Authorization: token giteabu_1796c6aace0e2ef7e4fdb49cdc3bc1bf8ee31fbc" \
+  -H "Authorization: token $GITEA_TOKEN" \
   -H "Content-Type: application/json" \
-  -d '{"title":"feat(#XX): Titre","body":"Description\n\nCloses #XX","head":"feature/XX-nom-ticket","base":"master"}' \
+  -d '{"title":"feat(#XX): Titre","body":"Description\n\nCloses #XX","head":"feature/XX-nom-ticket","base":"develop"}' \
   "https://git.ptits-pas.fr/api/v1/repos/jmartin/petitspas/pulls"
+
+# 5. Merger en squash (pas merge commit)
+curl -X POST \
+  -H "Authorization: token $GITEA_TOKEN" \
+  -H "Content-Type: application/json" \
+  -d '{"Do":"squash","MergeTitleField":"feat(#XX): Titre","MergeMessageField":"Closes #XX"}' \
+  "https://git.ptits-pas.fr/api/v1/repos/jmartin/petitspas/pulls/{index}/merge"
 ```
 
 ---

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

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

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

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

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

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

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

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

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

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

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

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

docs/tmp/154-matrice-suppression.md

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

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

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

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

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

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

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

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

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

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

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

scripts/gitea-list-open-issues-by-milestone.js

@@ -0,0 +1,144 @@
+/**
+ * Liste les issues Gitea ouvertes pour un milestone donné (ex. 0.1.0).
+ * Usage : node scripts/gitea-list-open-issues-by-milestone.js [milestone]
+ * Token : .gitea-token (racine), GITEA_TOKEN, ou docs/27_BRIEFING-FRONTEND.md
+ */
+const https = require('https');
+const fs = require('fs');
+const path = require('path');
+
+const repoRoot = path.join(__dirname, '..');
+const REPO = 'jmartin/petitspas';
+const milestoneWanted = (process.argv[2] || '0.1.0').trim();
+
+let token = process.env.GITEA_TOKEN;
+if (!token) {
+  try {
+    const tokenFile = path.join(repoRoot, '.gitea-token');
+    if (fs.existsSync(tokenFile)) token = fs.readFileSync(tokenFile, 'utf8').trim();
+  } catch (_) {}
+}
+if (!token) {
+  try {
+    const briefing = fs.readFileSync(
+      path.join(repoRoot, 'docs/27_BRIEFING-FRONTEND.md'),
+      'utf8',
+    );
+    const m = briefing.match(/Token:\s*(giteabu_[a-f0-9]+)/);
+    if (m) token = m[1].trim();
+  } catch (_) {}
+}
+if (!token) {
+  console.error('Token non trouvé : .gitea-token ou GITEA_TOKEN');
+  process.exit(1);
+}
+
+function getJson(apiPath) {
+  return new Promise((resolve, reject) => {
+    const opts = {
+      hostname: 'git.ptits-pas.fr',
+      path: `/api/v1/repos/${REPO}${apiPath}`,
+      method: 'GET',
+      headers: {
+        Authorization: 'token ' + token,
+        Accept: 'application/json',
+      },
+    };
+    const req = https.request(opts, (res) => {
+      let d = '';
+      res.on('data', (c) => (d += c));
+      res.on('end', () => {
+        if (res.statusCode !== 200) {
+          reject(new Error(`HTTP ${res.statusCode}: ${d.slice(0, 500)}`));
+          return;
+        }
+        try {
+          resolve(JSON.parse(d));
+        } catch (e) {
+          reject(e);
+        }
+      });
+    });
+    req.on('error', reject);
+    req.end();
+  });
+}
+
+async function fetchAllOpenIssues() {
+  const out = [];
+  let page = 1;
+  const limit = 50;
+  for (;;) {
+    const qs = new URLSearchParams({
+      state: 'open',
+      type: 'all',
+      page: String(page),
+      limit: String(limit),
+    });
+    const batch = await getJson(`/issues?${qs}`);
+    if (!Array.isArray(batch) || batch.length === 0) break;
+    out.push(...batch);
+    if (batch.length < limit) break;
+    page += 1;
+    if (page > 40) break;
+  }
+  return out;
+}
+
+function milestoneMatches(m, wanted) {
+  if (!m) return false;
+  const t = (m.title || '').trim();
+  return t === wanted || t === `v${wanted}`;
+}
+
+async function main() {
+  let milestones;
+  try {
+    milestones = await getJson('/milestones?state=all');
+  } catch (e) {
+    milestones = [];
+    console.warn('Milestones non lisibles:', e.message);
+  }
+
+  const known = Array.isArray(milestones)
+    ? milestones.map((m) => m.title).filter(Boolean)
+    : [];
+  if (known.length) {
+    console.log('Milestones connus sur le dépôt :', known.join(', '));
+  }
+
+  const issues = await fetchAllOpenIssues();
+  const filtered = issues.filter((i) => milestoneMatches(i.milestone, milestoneWanted));
+
+  console.log('');
+  console.log(`## Issues ouvertes — milestone « ${milestoneWanted} » (${filtered.length})`);
+  console.log('');
+  if (filtered.length === 0) {
+    console.log(
+      'Aucune issue ouverte avec ce milestone. Vérifier sur Gitea que les tickets ' +
+        '0.1.0 portent bien le milestone, ou élargir la requête.',
+    );
+    console.log('');
+    console.log(`(Total issues ouvertes sans filtre milestone : ${issues.length})`);
+    const withM = issues.filter((i) => i.milestone);
+    if (withM.length) {
+      console.log('');
+      console.log('Issues ouvertes qui ont *un* milestone :');
+      for (const i of withM) {
+        console.log(`- #${i.number} [${i.milestone.title}] ${i.title}`);
+      }
+    }
+    process.exit(0);
+  }
+
+  for (const i of filtered.sort((a, b) => a.number - b.number)) {
+    const labels = (i.labels || []).map((l) => l.name).join(', ');
+    console.log(`- **#${i.number}** — ${i.title}`);
+    if (labels) console.log(`  - Labels : ${labels}`);
+  }
+}
+
+main().catch((e) => {
+  console.error(e);
+  process.exit(1);
+});

tests/scripts/register-parent-bernard-test.mjs

@@ -0,0 +1,103 @@
+/**
+ * POST /api/v1/auth/register/parent — foyer mono-parent (1 parent + 1 enfant).
+ * Inspiré de register-parent-lecomte-test.mjs.
+ * Email : sophie.bernard@example.com
+ *
+ * Usage : node tests/scripts/register-parent-bernard-test.mjs [BASE_URL]
+ */
+
+import fs from 'fs';
+import path from 'path';
+import https from 'https';
+import http from 'http';
+import { fileURLToPath } from 'url';
+
+const __dirname = path.dirname(fileURLToPath(import.meta.url));
+const photosDir = path.join(__dirname, '..', 'ressources', 'photos');
+
+function toDataUri(filePath) {
+  const buf = fs.readFileSync(filePath);
+  return `data:image/png;base64,${buf.toString('base64')}`;
+}
+
+const presentationDossier =
+  "Je suis Sophie BERNARD, mère isolée de Jules. J'ai la garde complète de mon fils. " +
+  "Je recherche une assistante maternelle bienveillante à Bezons. " +
+  "Merci pour l'étude de notre dossier.";
+
+const body = {
+  email: 'sophie.bernard@example.com',
+  prenom: 'Sophie',
+  nom: 'BERNARD',
+  telephone: '0611223344',
+  adresse: '12 Rue des Lilas',
+  code_postal: '95870',
+  ville: 'Bezons',
+  // Pas de co-parent (mono-parent).
+  enfants: [
+    {
+      prenom: 'Jules',
+      nom: 'BERNARD',
+      date_naissance: '2024-06-10',
+      genre: 'H',
+      // Réutilise une photo de test existante.
+      photo_base64: toDataUri(path.join(photosDir, 'lecomte-maxime.png')),
+      photo_filename: 'jules_bernard.png',
+    },
+  ],
+  presentation_dossier: presentationDossier,
+  acceptation_cgu: true,
+  acceptation_privacy: true,
+};
+
+const json = JSON.stringify(body);
+const baseArg = process.argv[2] || 'https://app.ptits-pas.fr';
+const base = new URL(baseArg.endsWith('/') ? baseArg.slice(0, -1) : baseArg);
+const url = new URL('/api/v1/auth/register/parent', `${base.protocol}//${base.host}`);
+
+const opts = {
+  hostname: url.hostname,
+  port: url.port || (url.protocol === 'https:' ? 443 : 80),
+  path: url.pathname,
+  method: 'POST',
+  headers: {
+    'Content-Type': 'application/json',
+    Accept: 'application/json',
+    'Content-Length': Buffer.byteLength(json, 'utf8'),
+  },
+};
+
+const lib = url.protocol === 'https:' ? https : http;
+
+console.error(`POST ${url.href} (payload ~${Math.round(json.length / 1024)} Ko)`);
+
+const req = lib.request(opts, (res) => {
+  let data = '';
+  res.on('data', (c) => {
+    data += c;
+  });
+  res.on('end', () => {
+    console.log('HTTP', res.statusCode);
+    try {
+      const j = JSON.parse(data);
+      console.log(JSON.stringify(j, null, 2));
+    } catch {
+      console.log(data.slice(0, 4000));
+    }
+    if (res.statusCode < 200 || res.statusCode >= 300) process.exit(1);
+  });
+});
+
+req.on('error', (e) => {
+  console.error('Erreur réseau:', e.message);
+  process.exit(1);
+});
+
+req.setTimeout(120000, () => {
+  req.destroy();
+  console.error('Timeout 120s');
+  process.exit(1);
+});
+
+req.write(json);
+req.end();