feat(#168): API couples de garde parent (liste + couple courant).

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

backend/src/entities/parents.entity.ts

@@ -5,6 +5,7 @@ import {
 import { Users } from './users.entity';
 import { ParentsChildren } from './parents_children.entity';
 import { Dossier } from './dossiers.entity';
+import { AmChildren } from './am_children.entity';
 
 @Entity('parents', { schema: 'public' })
 export class Parents {
@@ -25,6 +26,17 @@ export class Parents {
   @Column({ name: 'numero_dossier', length: 20, nullable: true })
   numero_dossier?: string;
 
+  /**
+   * Placement AM↔enfant sélectionné sur le TdB parent (couple actif) — ticket #168.
+   * Null = le front prend le premier couple actif retourné par l’API.
+   */
+  @Column({ name: 'id_placement_garde_courant', type: 'uuid', nullable: true })
+  id_placement_garde_courant?: string | null;
+
+  @ManyToOne(() => AmChildren, { nullable: true, onDelete: 'SET NULL' })
+  @JoinColumn({ name: 'id_placement_garde_courant', referencedColumnName: 'id' })
+  placement_garde_courant?: AmChildren | null;
+
   // Lien vers enfants via la table enfants_parents
   @OneToMany(() => ParentsChildren, pc => pc.parent)
   parentChildren: ParentsChildren[];

backend/src/routes/parents/dto/couples-garde.dto.ts

@@ -0,0 +1,61 @@
+import { ApiProperty, ApiPropertyOptional } from '@nestjs/swagger';
+
+/** Identité minimale enfant pour le bandeau couple — ticket #168 */
+export class CoupleGardeEnfantDto {
+  @ApiProperty({ format: 'uuid' })
+  id: string;
+
+  @ApiPropertyOptional()
+  prenom?: string | null;
+
+  @ApiPropertyOptional()
+  nom?: string | null;
+
+  @ApiPropertyOptional()
+  photo_url?: string | null;
+}
+
+/** Identité minimale AM pour le bandeau couple — ticket #168 */
+export class CoupleGardeAmDto {
+  @ApiProperty({ format: 'uuid', description: 'UUID utilisateur de l’AM' })
+  id: string;
+
+  @ApiPropertyOptional()
+  prenom?: string | null;
+
+  @ApiPropertyOptional()
+  nom?: string | null;
+
+  @ApiPropertyOptional()
+  photo_url?: string | null;
+}
+
+/** Un couple de garde = placement actif enfant ↔ AM */
+export class CoupleGardeDto {
+  @ApiProperty({
+    format: 'uuid',
+    description: 'Id du placement (enfants_assistantes_maternelles.id)',
+  })
+  id: string;
+
+  @ApiProperty({ type: CoupleGardeEnfantDto })
+  enfant: CoupleGardeEnfantDto;
+
+  @ApiProperty({ type: CoupleGardeAmDto })
+  am: CoupleGardeAmDto;
+
+  @ApiProperty({ description: 'True si c’est le couple actuellement sélectionné' })
+  courant: boolean;
+}
+
+export class CouplesGardeResponseDto {
+  @ApiProperty({ type: [CoupleGardeDto] })
+  couples: CoupleGardeDto[];
+
+  @ApiPropertyOptional({
+    format: 'uuid',
+    nullable: true,
+    description: 'Id du couple courant (null si aucun / premier couple implicite côté client)',
+  })
+  couple_courant_id: string | null;
+}

backend/src/routes/parents/dto/definir-couple-garde-courant.dto.ts

@@ -0,0 +1,13 @@
+import { ApiProperty } from '@nestjs/swagger';
+import { IsNotEmpty, IsUUID } from 'class-validator';
+
+/** Corps PUT couple de garde courant — ticket #168 */
+export class DefinirCoupleGardeCourantDto {
+  @ApiProperty({
+    format: 'uuid',
+    description: 'Id du placement (enfants_assistantes_maternelles.id) à sélectionner',
+  })
+  @IsUUID()
+  @IsNotEmpty()
+  couple_id: string;
+}

backend/src/routes/parents/parents.controller.spec.ts

@@ -13,7 +13,10 @@ describe('ParentsController', () => {
     createParentDossierStaff: jest.fn(),
     addCoParentStaff: jest.fn(),
   };
-  const parentsServiceMock = {};
+  const parentsServiceMock = {
+    listerCouplesGarde: jest.fn(),
+    definirCoupleGardeCourant: jest.fn(),
+  };
   const userServiceMock = {};
 
   beforeEach(async () => {
@@ -39,6 +42,31 @@ describe('ParentsController', () => {
     expect(controller).toBeDefined();
   });
 
+  it('listerCouplesGarde délègue au service (#168)', async () => {
+    parentsServiceMock.listerCouplesGarde.mockResolvedValue({
+      couples: [],
+      couple_courant_id: null,
+    });
+    const res = await controller.listerCouplesGarde('parent-uuid');
+    expect(parentsServiceMock.listerCouplesGarde).toHaveBeenCalledWith('parent-uuid');
+    expect(res.couples).toEqual([]);
+  });
+
+  it('definirCoupleGardeCourant délègue au service (#168)', async () => {
+    parentsServiceMock.definirCoupleGardeCourant.mockResolvedValue({
+      couples: [{ id: 'pl-1', courant: true }],
+      couple_courant_id: 'pl-1',
+    });
+    const res = await controller.definirCoupleGardeCourant('parent-uuid', {
+      couple_id: 'pl-1',
+    });
+    expect(parentsServiceMock.definirCoupleGardeCourant).toHaveBeenCalledWith(
+      'parent-uuid',
+      'pl-1',
+    );
+    expect(res.couple_courant_id).toBe('pl-1');
+  });
+
   it('createDossier delegates to authService.createParentDossierStaff with CGU accepted', async () => {
     authServiceMock.createParentDossierStaff.mockResolvedValue({
       message: 'Dossier famille créé et validé. Un e-mail de création de mot de passe a été envoyé.',

backend/src/routes/parents/parents.controller.ts

@@ -8,6 +8,7 @@ import {
   Param,
   Patch,
   Post,
+  Put,
   UseGuards,
 } from '@nestjs/common';
 import { ParentsService } from './parents.service';
@@ -39,6 +40,8 @@ import { User } from 'src/common/decorators/user.decorator';
 import { PendingFamilyDto } from './dto/pending-family.dto';
 import { DossierFamilleCompletDto } from './dto/dossier-famille-complet.dto';
 import { mapParentForApi, mapParentsForApi } from './parents.mapper';
+import { CouplesGardeResponseDto } from './dto/couples-garde.dto';
+import { DefinirCoupleGardeCourantDto } from './dto/definir-couple-garde-courant.dto';
 
 @ApiTags('Parents')
 @ApiBearerAuth('access-token')
@@ -51,6 +54,39 @@ export class ParentsController {
     private readonly authService: AuthService,
   ) {}
 
+  @Get('me/couples-garde')
+  @Roles(RoleType.PARENT)
+  @ApiOperation({
+    summary: 'Lister les couples de garde du parent connecté — ticket #168',
+    description:
+      'Retourne les placements actifs enfant↔AM rattachés au parent, ' +
+      'avec indication du couple courant (bandeau TdB quotidien).',
+  })
+  @ApiResponse({ status: 200, type: CouplesGardeResponseDto })
+  @ApiResponse({ status: 403, description: 'Réservé au rôle parent' })
+  @ApiResponse({ status: 404, description: 'Parent introuvable' })
+  listerCouplesGarde(@User('id') userId: string): Promise<CouplesGardeResponseDto> {
+    return this.parentsService.listerCouplesGarde(userId);
+  }
+
+  @Put('me/couples-garde/courant')
+  @Roles(RoleType.PARENT)
+  @ApiOperation({
+    summary: 'Définir le couple de garde courant — ticket #168',
+    description:
+      'Persiste la préférence de couple actif (enfant|nounou) pour contextualiser le TdB.',
+  })
+  @ApiBody({ type: DefinirCoupleGardeCourantDto })
+  @ApiResponse({ status: 200, type: CouplesGardeResponseDto })
+  @ApiResponse({ status: 400, description: 'Couple hors périmètre du parent' })
+  @ApiResponse({ status: 404, description: 'Parent ou couple introuvable' })
+  definirCoupleGardeCourant(
+    @User('id') userId: string,
+    @Body() dto: DefinirCoupleGardeCourantDto,
+  ): Promise<CouplesGardeResponseDto> {
+    return this.parentsService.definirCoupleGardeCourant(userId, dto.couple_id);
+  }
+
   @Roles(RoleType.SUPER_ADMIN, RoleType.ADMINISTRATEUR, RoleType.GESTIONNAIRE)
   @Post('dossier')
   @HttpCode(HttpStatus.CREATED)

backend/src/routes/parents/parents.module.ts

@@ -5,6 +5,7 @@ import { JwtModule } from '@nestjs/jwt';
 import { Parents } from 'src/entities/parents.entity';
 import { DossierFamille, DossierFamilleEnfant } from 'src/entities/dossier_famille.entity';
 import { ParentsChildren } from 'src/entities/parents_children.entity';
+import { AmChildren } from 'src/entities/am_children.entity';
 import { ParentsController } from './parents.controller';
 import { ParentsService } from './parents.service';
 import { Users } from 'src/entities/users.entity';
@@ -13,7 +14,14 @@ import { AuthModule } from '../auth/auth.module';
 
 @Module({
     imports: [
-        TypeOrmModule.forFeature([Parents, Users, DossierFamille, DossierFamilleEnfant, ParentsChildren]),
+        TypeOrmModule.forFeature([
+            Parents,
+            Users,
+            DossierFamille,
+            DossierFamilleEnfant,
+            ParentsChildren,
+            AmChildren,
+        ]),
         forwardRef(() => UserModule),
         forwardRef(() => AuthModule),
         JwtModule.registerAsync({

backend/src/routes/parents/parents.service.spec.ts

@@ -1,12 +1,43 @@
+import { BadRequestException, NotFoundException } from '@nestjs/common';
 import { Test, TestingModule } from '@nestjs/testing';
+import { getRepositoryToken } from '@nestjs/typeorm';
 import { ParentsService } from './parents.service';
+import { Parents } from 'src/entities/parents.entity';
+import { Users } from 'src/entities/users.entity';
+import { DossierFamille } from 'src/entities/dossier_famille.entity';
+import { ParentsChildren } from 'src/entities/parents_children.entity';
+import { AmChildren } from 'src/entities/am_children.entity';
 
-describe('ParentsService', () => {
+describe('ParentsService — couples de garde (#168)', () => {
   let service: ParentsService;
 
+  const parentsRepository = {
+    findOne: jest.fn(),
+    update: jest.fn(),
+  };
+  const parentsChildrenRepository = {
+    find: jest.fn(),
+    findOne: jest.fn(),
+  };
+  const amChildrenRepository = {
+    find: jest.fn(),
+    findOne: jest.fn(),
+  };
+
   beforeEach(async () => {
+    jest.clearAllMocks();
     const module: TestingModule = await Test.createTestingModule({
-      providers: [ParentsService],
+      providers: [
+        ParentsService,
+        { provide: getRepositoryToken(Parents), useValue: parentsRepository },
+        { provide: getRepositoryToken(Users), useValue: {} },
+        { provide: getRepositoryToken(DossierFamille), useValue: {} },
+        {
+          provide: getRepositoryToken(ParentsChildren),
+          useValue: parentsChildrenRepository,
+        },
+        { provide: getRepositoryToken(AmChildren), useValue: amChildrenRepository },
+      ],
     }).compile();
 
     service = module.get<ParentsService>(ParentsService);
@@ -15,4 +46,107 @@ describe('ParentsService', () => {
   it('should be defined', () => {
     expect(service).toBeDefined();
   });
+
+  describe('listerCouplesGarde', () => {
+    it('retourne une liste vide si le parent n’a pas d’enfant', async () => {
+      parentsRepository.findOne.mockResolvedValue({
+        user_id: 'p1',
+        id_placement_garde_courant: null,
+      });
+      parentsChildrenRepository.find.mockResolvedValue([]);
+
+      const res = await service.listerCouplesGarde('p1');
+      expect(res).toEqual({ couples: [], couple_courant_id: null });
+      expect(amChildrenRepository.find).not.toHaveBeenCalled();
+    });
+
+    it('mappe les placements actifs en couples et marque le courant', async () => {
+      parentsRepository.findOne.mockResolvedValue({
+        user_id: 'p1',
+        id_placement_garde_courant: 'pl-2',
+      });
+      parentsChildrenRepository.find.mockResolvedValue([
+        { enfantId: 'e1' },
+        { enfantId: 'e2' },
+      ]);
+      amChildrenRepository.find.mockResolvedValue([
+        {
+          id: 'pl-1',
+          amId: 'am-1',
+          child: { id: 'e1', first_name: 'Léo', last_name: 'M', photo_url: null },
+          am: { user: { prenom: 'Marie', nom: 'N', photo_url: '/a.jpg' } },
+        },
+        {
+          id: 'pl-2',
+          amId: 'am-2',
+          child: { id: 'e2', first_name: 'Léa', last_name: 'M', photo_url: null },
+          am: { user: { prenom: 'Sophie', nom: 'P', photo_url: null } },
+        },
+      ]);
+
+      const res = await service.listerCouplesGarde('p1');
+      expect(res.couples).toHaveLength(2);
+      expect(res.couple_courant_id).toBe('pl-2');
+      expect(res.couples[1].courant).toBe(true);
+      expect(res.couples[0].am.prenom).toBe('Marie');
+      expect(res.couples[0].enfant.prenom).toBe('Léo');
+    });
+
+    it('404 si parent inconnu', async () => {
+      parentsRepository.findOne.mockResolvedValue(null);
+      await expect(service.listerCouplesGarde('x')).rejects.toBeInstanceOf(
+        NotFoundException,
+      );
+    });
+  });
+
+  describe('definirCoupleGardeCourant', () => {
+    it('persiste le couple si l’enfant est rattaché au parent', async () => {
+      parentsRepository.findOne.mockResolvedValue({
+        user_id: 'p1',
+        id_placement_garde_courant: null,
+      });
+      amChildrenRepository.findOne.mockResolvedValue({
+        id: 'pl-1',
+        enfantId: 'e1',
+        date_fin: null,
+      });
+      parentsChildrenRepository.findOne.mockResolvedValue({
+        parentId: 'p1',
+        enfantId: 'e1',
+      });
+      parentsRepository.update.mockResolvedValue({ affected: 1 });
+      // second call via listerCouplesGarde
+      parentsChildrenRepository.find.mockResolvedValue([{ enfantId: 'e1' }]);
+      amChildrenRepository.find.mockResolvedValue([
+        {
+          id: 'pl-1',
+          amId: 'am-1',
+          child: { id: 'e1', first_name: 'Léo', last_name: null, photo_url: null },
+          am: { user: { prenom: 'Marie', nom: null, photo_url: null } },
+        },
+      ]);
+
+      const res = await service.definirCoupleGardeCourant('p1', 'pl-1');
+      expect(parentsRepository.update).toHaveBeenCalledWith(
+        { user_id: 'p1' },
+        { id_placement_garde_courant: 'pl-1' },
+      );
+      expect(res.couple_courant_id).toBe('pl-1');
+      expect(res.couples[0].courant).toBe(true);
+    });
+
+    it('400 si le couple n’appartient pas au parent', async () => {
+      parentsRepository.findOne.mockResolvedValue({ user_id: 'p1' });
+      amChildrenRepository.findOne.mockResolvedValue({
+        id: 'pl-1',
+        enfantId: 'e99',
+      });
+      parentsChildrenRepository.findOne.mockResolvedValue(null);
+
+      await expect(
+        service.definirCoupleGardeCourant('p1', 'pl-1'),
+      ).rejects.toBeInstanceOf(BadRequestException);
+    });
+  });
 });

backend/src/routes/parents/parents.service.ts

@@ -5,7 +5,7 @@ import {
   NotFoundException,
 } from '@nestjs/common';
 import { InjectRepository } from '@nestjs/typeorm';
-import { In, Repository } from 'typeorm';
+import { In, IsNull, Repository } from 'typeorm';
 import { Parents } from 'src/entities/parents.entity';
 import { DossierFamille } from 'src/entities/dossier_famille.entity';
 import { RoleType, Users } from 'src/entities/users.entity';
@@ -20,6 +20,8 @@ import {
 import { ParentsChildren } from 'src/entities/parents_children.entity';
 import { Children } from 'src/entities/children.entity';
 import { UpdateParentFicheAdminDto } from './dto/update-parent-fiche-admin.dto';
+import { AmChildren } from 'src/entities/am_children.entity';
+import { CouplesGardeResponseDto } from './dto/couples-garde.dto';
 
 @Injectable()
 export class ParentsService {
@@ -32,6 +34,8 @@ export class ParentsService {
     private readonly dossierFamilleRepository: Repository<DossierFamille>,
     @InjectRepository(ParentsChildren)
     private readonly parentsChildrenRepository: Repository<ParentsChildren>,
+    @InjectRepository(AmChildren)
+    private readonly amChildrenRepository: Repository<AmChildren>,
   ) {}
 
   // Création d’un parent
@@ -505,4 +509,108 @@ export class ParentsService {
     }
     return raw.map((r: { id: string }) => r.id);
   }
+
+  /**
+   * Liste les couples de garde (enfant ↔ AM) du parent connecté — ticket #168.
+   * Un couple = un placement actif dans enfants_assistantes_maternelles pour un enfant du parent.
+   */
+  async listerCouplesGarde(parentUserId: string): Promise<CouplesGardeResponseDto> {
+    const parent = await this.parentsRepository.findOne({
+      where: { user_id: parentUserId },
+    });
+    if (!parent) {
+      throw new NotFoundException('Parent introuvable');
+    }
+
+    const liensEnfants = await this.parentsChildrenRepository.find({
+      where: { parentId: parentUserId },
+      select: ['enfantId'],
+    });
+    const enfantIds = liensEnfants.map((l) => l.enfantId);
+    if (enfantIds.length === 0) {
+      return { couples: [], couple_courant_id: null };
+    }
+
+    const placements = await this.amChildrenRepository.find({
+      where: { enfantId: In(enfantIds), date_fin: IsNull() },
+      relations: ['child', 'am', 'am.user'],
+      order: { date_debut: 'ASC' },
+    });
+
+    let idCourant = parent.id_placement_garde_courant ?? null;
+    const idsValides = new Set(placements.map((p) => p.id));
+    if (idCourant && !idsValides.has(idCourant)) {
+      idCourant = null;
+      await this.parentsRepository.update(
+        { user_id: parentUserId },
+        { id_placement_garde_courant: null },
+      );
+    }
+    if (!idCourant && placements.length === 1) {
+      idCourant = placements[0].id;
+    }
+
+    const couples = placements.map((p) => {
+      const amUser = p.am?.user;
+      return {
+        id: p.id,
+        enfant: {
+          id: p.child.id,
+          prenom: p.child.first_name ?? null,
+          nom: p.child.last_name ?? null,
+          photo_url: p.child.photo_url ?? null,
+        },
+        am: {
+          id: p.amId,
+          prenom: amUser?.prenom ?? null,
+          nom: amUser?.nom ?? null,
+          photo_url: amUser?.photo_url ?? null,
+        },
+        courant: idCourant != null && p.id === idCourant,
+      };
+    });
+
+    return {
+      couples,
+      couple_courant_id: idCourant,
+    };
+  }
+
+  /**
+   * Persiste le couple de garde actif pour le parent — ticket #168.
+   */
+  async definirCoupleGardeCourant(
+    parentUserId: string,
+    coupleId: string,
+  ): Promise<CouplesGardeResponseDto> {
+    const parent = await this.parentsRepository.findOne({
+      where: { user_id: parentUserId },
+    });
+    if (!parent) {
+      throw new NotFoundException('Parent introuvable');
+    }
+
+    const placement = await this.amChildrenRepository.findOne({
+      where: { id: coupleId, date_fin: IsNull() },
+    });
+    if (!placement) {
+      throw new NotFoundException('Couple de garde introuvable ou inactif');
+    }
+
+    const lien = await this.parentsChildrenRepository.findOne({
+      where: { parentId: parentUserId, enfantId: placement.enfantId },
+    });
+    if (!lien) {
+      throw new BadRequestException(
+        'Ce couple ne concerne pas un enfant rattaché à ce parent',
+      );
+    }
+
+    await this.parentsRepository.update(
+      { user_id: parentUserId },
+      { id_placement_garde_courant: coupleId },
+    );
+
+    return this.listerCouplesGarde(parentUserId);
+  }
 }

database/BDD.sql

@@ -154,7 +154,10 @@ CREATE INDEX idx_assistantes_maternelles_numero_dossier
 CREATE TABLE parents (
     id_utilisateur UUID PRIMARY KEY REFERENCES utilisateurs(id) ON DELETE CASCADE,
     id_co_parent UUID REFERENCES utilisateurs(id),
-    numero_dossier VARCHAR(20)
+    numero_dossier VARCHAR(20),
+    -- Préférence couple de garde actif (TdB quotidien) — ticket #168
+    -- FK ajoutée après création de enfants_assistantes_maternelles (voir ALTER plus bas)
+    id_placement_garde_courant UUID
 );
 
 CREATE INDEX idx_parents_numero_dossier
@@ -206,6 +209,16 @@ CREATE UNIQUE INDEX uq_enfant_garde_active
     ON enfants_assistantes_maternelles (id_enfant)
     WHERE date_fin IS NULL;
 
+-- FK couple courant parent → placement (#168) — après table enfants_assistantes_maternelles
+ALTER TABLE parents
+  ADD CONSTRAINT fk_parents_placement_garde_courant
+  FOREIGN KEY (id_placement_garde_courant)
+  REFERENCES enfants_assistantes_maternelles(id) ON DELETE SET NULL;
+
+CREATE INDEX idx_parents_placement_garde_courant
+  ON parents(id_placement_garde_courant)
+  WHERE id_placement_garde_courant IS NOT NULL;
+
 -- ==========================================================
 -- Table : dossier_famille (inscription parent — ticket #119)
 -- ==========================================================

database/migrations/2026_parent_placement_garde_courant.sql

@@ -0,0 +1,10 @@
+-- Ticket #168 — Couple de garde courant (préférence parent)
+-- Idempotent : safe à rejouer.
+
+ALTER TABLE parents
+  ADD COLUMN IF NOT EXISTS id_placement_garde_courant UUID
+    REFERENCES enfants_assistantes_maternelles(id) ON DELETE SET NULL;
+
+CREATE INDEX IF NOT EXISTS idx_parents_placement_garde_courant
+  ON parents(id_placement_garde_courant)
+  WHERE id_placement_garde_courant IS NOT NULL;

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

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

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

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

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

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

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

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

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

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

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

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

docs/tmp/154-matrice-suppression.md

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

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

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

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

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

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

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

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

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

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

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