petitspas/docs/31_MINI-SPEC-QUOTIDIEN-PARENT-AM.md

# Mini-spec — Quotidien parent / AM

> **Statut :** figée pour backlog (sept. 2026)  
> **Réf. visuelle :** [maquettes/courantes/maquette-dashboard-parent-quotidien-v4.png](./maquettes/courantes/maquette-dashboard-parent-quotidien-v4.png)  
> **Découpage tickets :** [30_DECOUPAGE-TICKETS-QUOTIDIEN.md](./30_DECOUPAGE-TICKETS-QUOTIDIEN.md)  
> **CDC :** vision d’origine conservée ; priorités UX évoluées (blog central, couple enfant–nounou)

## 1. Objectif

Construire les **espaces parent et AM du quotidien** : tableau de bord 3 colonnes, file de cartes (absences / congés / sorties), **blog** (cœur du jour), **messagerie** AM et RPE. Logiciel réel peuplé de données ; une démo = sync live multi-écrans (parent / AM / gestionnaire).

## 2. UI — contrainte non négociable

- Look **papier / pastel**, lignée **login / inscription** (`paper2.png`), pas le dashboard staff violet Material
- PC paysage : **3 colonnes** égales
- Mobile : **swipe** entre les 3 panneaux ; TdB / Agenda / Contrat via nav dédiée

### Architecture front — maximiser les widgets partagés

Parent et AM sont **quasi identiques** : **ne pas dupliquer** les colonnes métier.

| Brique | Usage |
|--------|--------|
| Widget **Blog** | Colonne milieu parent **et** AM (+ entrée publication gestionnaire qui réutilise le composeur) |
| Widget **Messagerie** | Colonne droite parent **et** AM (+ vue gestionnaire RPE) |
| Widget **flux de cartes** | Colonne gauche parent **et** AM (actions / droits selon rôle) |
| Widget **bandeau couple** | Variante *enfant\|nounou* (parent) vs *enfant\|parent(s)* (AM) — même composant paramétré |
| Coquille TdB 3 colonnes | Layout / bandeau navig commun ; le rôle injecte le couple + droits |

Principe : **briques correctement encapsulées** (API claire props / callbacks), branchées sur le même back ; seules les **différences de rôle** (qui crée quoi, libellés d’action) restent hors du widget partagé.


## 3. Layout TdB

| Colonne | Contenu |
|---------|---------|
| **Gauche** | Couple actif · flux de **cartes** · actions (ex. Déclarer une absence) |
| **Milieu** | **Blog** — affichage **par défaut** à l’arrivée |
| **Droite** | **Messagerie** seule — onglets Mess. AM (défaut) \| Mess. RPE |

Bandeau : **TdB** · **Agenda** · **Contrat** · menu user (recherche AM, paramètres…).

### Parent — couple

- Un bandeau **enfant | nounou** (photos + noms)
- Plusieurs gardes → dropdown unique (bascule de couple)
- Une seule garde → affichage informatif (pas de chevron)

### AM — couple (miroir)

- Bandeau **enfant | parent(s)**
- 2 parents : noms empilés à droite ; 1 parent : nom centré
- Pas de photo parent obligatoire (option profil plus tard)

## 4. Canaux (ne pas mélanger)

| Canal | Rôle |
|-------|------|
| **Cartes** | Décisions / futur proche : absences, congés, maladie AM, sorties à valider |
| **Blog** | Mémoire / actus du quotidien (texte + photos) — **indispensable**, plus un module optionnel CDC §9 |
| **Mess. AM** | Chat foyer ↔ AM (style WhatsApp : texte, emoji, images) |
| **Mess. RPE** | Privée par défaut ; ajout de participants pour médiation / conflit |

## 5. Règles métier V1 (absences / congés)

| Type | Qui initie | Validation / effet |
|------|------------|-------------------|
| Absence enfant | Parent | Pas de veto AM ; période **acceptée** tout de suite ; bulle info AM |
| Congé AM | AM | **1 parent** accepte **ou** refuse (+ motivation) → bounce AM (modif/renvoi ou DELETE) |
| Modification congé AM déjà accepté | AM | Même `id` absence ; re-validation parents ; dates actives = anciennes tant qu’en attente |
| Modification absence enfant | Parent | Update immédiat + bulle **ack** AM (OK) |
| Maladie AM | AM | Parent **ack** (« bien reçu ») ; **aucun** doc médical |
| Sortie / sondage | — | **Plus tard** (types optionnels) |

**Stockage :** table `absences_garde` (1 ligne = période, `id_placement`, `expire_at`). Les **cartes** collectent ; elles ne sont pas la source de vérité. Annulation = DELETE.

**Péremption cartes :** mémoire courte (`retention_days` / `purge_at`) — pas un historique de vie (≠ messagerie).

- Mess. AM : les **2 parents** voient le **même** fil — **pas** de masquage V1
- Blog auteurs V1 : **AM** + **gestionnaire (RPE)** — parent auteur = plus tard
- Couple actif filtre cartes + messagerie + blog (hypothèse produit : **oui**)

## 6. Hors périmètre de ce jalon

- Page **Contrat** riche (Pajemploi, CP…) — stub bandeau OK
- **Agenda** calendrier riche — stub bandeau OK
- Notifications CDC fourre-tout (paiement, dossier…)
- Masquage messages ; posts blog parent
- Carnet repas/sieste (roadmap Phase 4)

## 7. Critères « effet démo » (acceptation)

Avec données peuplées, sur au moins 2 supports :

1. Parent et AM voient le **même contexte de garde** (couple / enfant)
2. Parent déclare une **absence** → carte visible côté AM
3. AM publie un **post blog** (texte + photo) → visible colonne blog parent
4. Gestionnaire publie une **annonce RPE** → visible sur les TdB concernés
5. Message **Mess. AM** d’un côté → apparaît de l’autre (près temps réel)
6. Look conforme charte papier / pastel

## 8. Point de départ code

- Parent : `frontend/lib/screens/home/parent_screen/ParentDashboardScreen.dart` + `dashbord_parent/`
- AM : `frontend/lib/screens/am/am_dashboard_screen.dart` (placeholder)
- Cartes couleurs : `frontend/assets/cards/` (7 teintes max)

## 9. Ordre de build suggéré

Voir [30_DECOUPAGE-TICKETS-QUOTIDIEN.md](./30_DECOUPAGE-TICKETS-QUOTIDIEN.md) § ordre — A (coquille parent) → C (cartes) → D (blog) → E (messagerie) → B (miroir AM) → RPE → F/G (mobile + seeds).