## Supuestos adoptados en F1

| Decisión | Supuesto adoptado | Alternativa descartada | Quién debe validar |
|---|---|---|---|
| Login de Betreuer | No tiene login propio. Se modela como campo de texto libre `termins.betreuer_name`, sin tabla `betreuer` ni rol `betreuer`. | Tabla `betreuer` con relación FK y rol de autenticación propio (Spatie Permission), como sugiere el modelo propuesto en `helpmi-spec.html` (con campos `email`/`activo`). | **Verena** — la spec marca esto explícitamente como "pendiente de confirmar". Bloqueante antes de F2B/F3 según el plan. |
| Nombre de columna del CRM en `Termin` | Se usa `solve360_id` en `therapeuts` (nombre real de la cabecera del CSV de producción), y se añade `hubspot_id` como campo separado nullable para la migración futura a HubSpot (F7). | Usar solo `hubspot_id` como indica la spec, ignorando que el CSV real usa `solve360-ID`. | Dev / Verena — confirmar si `solve360_id` se elimina tras la migración a HubSpot o convive con `hubspot_id`. |
| Almacenamiento de los 61 productos por cita | Tabla pivote normalizada `termin_medikament` (muchos-a-muchos), en vez de 61 columnas booleanas físicas en `termins` como en el CSV. | Replicar literalmente las 61 columnas booleanas en la tabla `termins`. | Dev — decisión técnica, no de negocio. El export XLSX (F5) reconstruirá las 61 columnas en el orden exacto del CSV a partir de la tabla pivote. |
| Campos obligatorios del formulario de anamnesis | Se modelan como `nullable` en la BD: `betreff`, `hauptthema`/`kategorie_id` y `unterkategorie_id` son la excepción (kategorie_id es NOT NULL); `weitere_angaben`, `geschlecht`, `alter_range`, `gewicht`, `groesse`, `plz` son nullable. Solo `dsgvo_accepted` es obligatorio (boolean, default false). | Marcar todos los campos de anamnesis como obligatorios por defecto. | Verena — la spec no declara explícitamente cuáles son obligatorios; se infirió de que `Weitere Angaben` aparece vacío en el CSV real. Validar antes de F3 (formulario público). |
| País de los 3 asesores | Los tres (`Dr. Petra Blum`, `Gunter Schlegel`, `Dr. Ursula Bubendorfer`) se siembran con `country = 'DE'`. | Consultar el país real de cada asesor si difiere. | Verena — el CSV de marzo 2026 solo mostraba terapeutas de Germany, no confirma el país del asesor mismo. |
| Días de antelación de agenda del asesor | 30 días para los tres asesores (`advance_days`), configurable por asesor vía el campo, pero con el mismo valor inicial para todos. | Definir un valor distinto por asesor desde el inicio. | Verena — pregunta explícitamente listada como pendiente en F2A ("¿Cuántos días de antelación puede ver el asesor su agenda? ¿configurable por asesor o global?"). |
| Festivos sembrados | Solo festivos **nacionales** de DE/AT/CH para 2026 (no festivos regionales/Bundesland). | Modelar festivos por región/Land dentro de cada país. | Dev — suficiente para la lógica de disponibilidad de F2B; ampliar si el negocio lo requiere. |
| 2FA | Se usa `pragmarx/google2fa-laravel` en vez del feature nativo de 2FA de Fortify (deshabilitado en `config/fortify.php`), respetando el stack exacto fijado en el plan. Columnas `google2fa_secret` y `google2fa_enabled` añadidas a `users`. | Usar el feature `Features::twoFactorAuthentication()` de Fortify (más simple pero fuera del stack listado). | Dev — decisión técnica para no desviarse de `docs/helpmi-planificacion.md` § Stack exacto. Falta implementar el middleware/UI de verificación TOTP (pendiente para F2A). |
| Registro público de usuarios | Deshabilitado (`Features::registration()` removido de Fortify). Los usuarios del panel los crea un admin vía `artisan make:filament-user` o el futuro `UserResource`. | Permitir auto-registro. | Dev — coherente con que HelpMI es un panel interno, no una plataforma de alta libre. |

Este archivo se revisa con Verena antes del UAT (F9). Si algún supuesto está mal, se corrige antes de F9.