docs(adr): decisiones de auth, catálogo de rutinas y provisión inicial

docs/adr/adr-003-provision-inicial-dataset.md

@@ -0,0 +1,90 @@
+# 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)