# ADR-003: Provisión inicial de datos al alta (familia y niño)

| Metadata | Valor |
|----------|-------|
| **Estado** | Aceptado (implementado) |
| **Fecha** | 2026-07-12 |
| **Autor(es)** | Jaume Garriga Maestre |
| **Supersede** | — |

## Contexto

Una familia recién registrada empezaba con la app vacía: había que crear a mano
todos los materiales, actividades y rutinas. El objetivo es que cualquier familia
arranque con un **dataset inicial útil**: material escolar típico y rutinas de
tarde apropiadas a la edad de cada niño (tramos 8-9 / 10-11 / 12-14, tomados de la
literatura de desarrollo de autonomía en TDAH), sin impedir personalizarlo después.

Restricción estructural clave: los datos cuelgan de `family_id` y `child_id`, que
son **datos de runtime** (se crean al registrarse), no de esquema.

## Opciones Consideradas

### Opción A: INSERTs en un changeset Liquibase

| Pros | Contras |
|------|---------|
| Versionado junto al esquema | **Inviable**: Liquibase corre ANTES que cualquier ApplicationRunner; en la migración no existe aún ninguna familia a la que apuntar (FK NOT NULL) |

### Opción B: Ampliar el DataSeeder

| Pros | Contras |
|------|---------|
| Sencillo | Solo actúa con BD vacía (familia demo); las familias reales que se registren después no reciben nada |

### Opción C: Servicio de provisión invocado en el alta (elegida)

| Pros | Contras |
|------|---------|
| Se ejecuta exactamente cuando existen los datos padre (familia/niño) | Lógica de negocio adicional que testear |
| La edad del niño está disponible en su alta → tramo correcto | El catálogo posterior al alta no se "resincroniza" (decisión consciente) |
| Transaccional con el registro: o todo o nada | |

## Decisión

**Opción C.** `InitialDatasetService` con dos operaciones:

- `provisionFamily(family)` — en `AuthService.register()`: catálogo de materiales
  escolares típicos (9) + catálogo completo de rutinas (14).
- `provisionChildRoutines(child)` — en `ChildService.create()`: asigna a L-V las
  rutinas del catálogo cuyo `minAge` ≤ edad del niño (acumulativo: base 0 /
  organización 10 / corresponsabilidad 12).

El `DataSeeder` demo **delega en el mismo servicio** (una sola fuente de verdad) y
solo añade sus extras (actividades del horario, premios, eventos).

## Trade-offs

### Optimizamos para:
- **Time-to-value de la familia**: la app es útil desde el minuto uno.
- **Adecuación evolutiva**: las responsabilidades crecen con la edad del niño.

### Sacrificamos:
- **Sincronización posterior**: si la familia borra rutinas del catálogo, los niños
  creados después reciben solo las que sigan existiendo (se busca por etiqueta ES).
  Aceptable: respeta la personalización de la familia.
- **Contenido opinado**: el set inicial es una propuesta pedagógica, no neutra;
  mitigado porque todo es editable desde el panel.

### Asunciones que podrían invalidar esta decisión:
- Si el dataset inicial necesitara variar por idioma/región o ser configurable por
  el admin, reconsiderar moverlo a datos (tabla de plantillas) en vez de código.

## Consecuencias

- (+) El registro deja a la familia lista para usar; el alta de un niño de 13 años
  le pone 14 rutinas x 5 días sin tocar nada.
- (−) El seed vive en código Java (constantes): cambiarlo requiere release. Asumido
  para v1 doméstica.

## Criterios de Éxito

- [x] Registro → 9 materiales + 14 rutinas de catálogo (test verde).
- [x] Niño de 8 → 25 asignaciones; niño de 13 → 70 (test verde).
- [x] Demo y familias reales comparten la misma provisión (DataSeederIT verde).

## Referencias

- `backend/.../service/InitialDatasetService.java` (+ test)
- `backend/.../security/AuthService.java`, `service/ChildService.java`, `bootstrap/DataSeeder.java`
- ADR-002 (el catálogo reutilizable es prerrequisito de esta provisión)