# Preguntas pendientes para Verena Heufler

> Documento consolidado a partir de todos los `docs/supuestos-FN.md` del proyecto HelpMI
> (última actualización: 2026-08-03, tras F0–F6-adelantado, F3.5 y F4). Cada pregunta indica
> qué se ha asumido mientras tanto y dónde está documentada la decisión con más detalle.
> Revisar y resolver **antes del UAT (F9)** — las marcadas 🔴 son bloqueantes antes de eso.

---

## 🔴 Bloqueantes — afectan a lógica ya construida y testeada

### 1. Modelo real del límite de citas
Producción (`admin.mgm.concloo.net`) parece limitar por **"casos activos" por terapeuta**
(config. global "Maximale Beratungstermine pro Therapeut" = 3, con override individual por
terapeuta), no por lo que asumimos:
- F2B: máximo 2 citas por terapeuta por día (general, todos los terapeutas).
- F3: máximo total acumulado de citas para terapeutas **no-socios**.

**¿Cuál es el modelo real?** Si es el de "casos activos", hay que rediseñar lógica síncrona
que ya está implementada y testeada (mutex/locks en `TerminBookingService`). No se ha tocado
nada de esto todavía a la espera de esta respuesta. La ficha de cada Therapeut en producción
también muestra campos ligados a este modelo (`Aktive Fälle`, `max-Termine`, `max`,
`block-new`) que tampoco se han replicado por la misma razón.
📄 `docs/supuestos-F3.5.md` (filas "Límite real de citas" y "Campos de Therapeut ligados al límite de citas")

### 2. Destinatario e periodicidad del informe mensual
El informe mensual (78 columnas, XLSX) ya se genera automáticamente el día 1 de cada mes y se
guarda en disco, pero **no se envía a nadie** — no hay dirección de email confirmada.

**¿A quién se debe enviar? ¿Con qué periodicidad exacta?**
📄 `docs/supuestos-F4.md` (fila "Informe mensual"), `docs/supuestos-F5.md` (fila "Destinatario del informe mensual automático")

### 3. Rol de Betreuer
**¿El Betreuer tiene login propio en el sistema?** Por ahora se modela como un campo de texto
libre (`termins.betreuer_name`), sin tabla ni rol de autenticación propio.
📄 `docs/supuestos-F1.md` (fila "Login de Betreuer") — pregunta original del plan, bloqueante desde F2B/F3, sigue abierta.

---

## 🟠 Integraciones externas (relevantes antes de F7)

### 4. ~~CRM: ¿solve360 o HubSpot?~~ — RESUELTO (2026-08-04): HubSpot
El cliente confirmó que el CRM real será **HubSpot**. Producción sigue sincronizando en vivo
contra solve360 hoy (usuario + API token + registro de última sincronización) — la migración a
HubSpot está pendiente de implementar (F7 solo construyó el esqueleto arquitectónico,
`HubSpotCrmAdapter` sin llamadas HTTP reales todavía). Queda como trabajo futuro: implementar la
integración real (autenticación API, mapeo de campos, sincronización de contactos/actividades) y
decidir qué pasa con la integración solve360 existente (¿se apaga de golpe, o convive durante una
transición?).
📄 `docs/supuestos-F3.5.md` (fila "Integración solve360 (CRM)"), `docs/supuestos-F7.md`

### 5. Verificación de membresía ("Mitglied")
Producción tiene una conexión SQL directa a una base de datos de WordPress externa (tabla de
usuarios) — probable mecanismo real para determinar si un terapeuta es socio, en vez de (o
además de) el campo manual que tenemos.

**¿Cómo se determina realmente el estatus de socio? ¿Sigue siendo necesaria esa integración?**
⚠️ Las credenciales de esa conexión se vieron expuestas en texto plano durante la auditoría —
recomendamos rotarlas independientemente de esta respuesta.
📄 `docs/supuestos-F3.5.md` (fila "Verificación de membresía vía WordPress")

---

## 🟡 Datos y campos (hallazgos de la auditoría F3.5)

### 6. Países Italy y Slovakia
Se encontraron terapeutas activos en Italy (7) y Slovakia (1) en producción.
**¿Siguen operativos, o están en fase de cierre?**
📄 `docs/supuestos-F3.5.md` (fila "Países soportados")

### 7. Los 7 asesores reales
**¿Siguen todos activos de cara al cutover (F10)?** (Dr. Petra Blum, Gunter Schlegel, Eciel
Hölzler, Ina Chammah, Dr. Andrea Stecher Schilling, Dr. Renate Schied, Dr. Ursula Bubendorfer)
📄 `docs/supuestos-F3.5.md` (fila "Catálogo de Berater")

### 8. Campo "Fallnummer Referenz"
Visto en producción como un campo de texto libre distinto del Fallnummer secuencial normal.
**¿Qué significa? ¿Dispara alguna lógica, o es puramente informativo?** No implementado
todavía por no poder confirmar su semántica sin acceso al código original.
📄 `docs/supuestos-F3.5.md` (fila "Campo Fallnummer Referenz")

### 9. Anamnesis clínica ampliada — ¿portal y export?
Se añadieron 14 campos clínicos nuevos vistos en producción (Hauptsymptome, Auslöser,
Operationen, etc.), pero solo en el panel admin.
**¿Deben capturarse también en el portal público (F3)? ¿Deben incluirse en el export XLSX
de F5?** (el CSV de referencia usado para F5 no los mostraba explícitamente)
📄 `docs/supuestos-F3.5.md` (fila "Anamnesis clínica ampliada")

### 10. Los 4 campos de notas/comentarios
Producción distingue **4** campos, no 3 como se pensó al principio: "Kommentar zum Termin"
(visible, sobre la cita en sí), "Interner Kommentar zum Termin" (interno), "Fallnummer
Referenz" (pregunta 8) y "Therapieempfehlung / Notizen" (nunca visible al terapeuta). Ya
replicados los 4 como campos separados (el primero se había pasado por alto en las primeras
rondas de revisión y se añadió en una cuarta pasada).
**¿Cuál es el propósito exacto de cada uno?** (para redactar bien las etiquetas de ayuda)
📄 `docs/supuestos-F3.5.md` (filas "Tercer campo de notas internas" y "Kommentar zum Termin — comentario visible, cuarto campo")

### 10b. ¿Importa quién cancela la cita?
Producción distingue 3 estados independientes en el detalle de una cita (Aktiv, Erledigt,
**Vom Therapeut abgesagt**), mientras nuestra implementación usa un único estado
(`pendiente`/`completada`/`cancelada`) que no registra si fue el terapeuta quien canceló,
frente a un asesor/admin.
**¿Tiene esta distinción alguna relevancia de negocio** (por ejemplo, un email distinto en
F4, o un desglose distinto en las estadísticas de F5)? No se ha tocado el flujo de
cancelación ya testeado hasta confirmar esto.
📄 `docs/supuestos-F3.5.md` (fila "Distinción Vom Therapeut abgesagt vs. cancelación general")

### 10c. ¿Los festivos se aplican realmente por país en producción?
El formulario y listado de Feiertage/Ferien de producción **no tienen ningún campo de país**
— es una lista plana de 12 festivos, sin distinguir DE/AT/CH/IT/SK, a pesar de incluir
festivos claramente nacionales de un solo país (ej. "Nationalfeiertag Österreich"). Nuestra
implementación sí filtra festivos por país del asesor.
**¿Producción realmente excluye festivos según el país del asesor al calcular
disponibilidad, o los aplica a todos los asesores por igual (posible limitación del sistema
original)?** Si es lo segundo, nuestra implementación sería una mejora intencional sobre el
comportamiento real de producción, no algo que haya que igualar.
📄 `docs/supuestos-F3.5.md` (fila "Feiertag sin campo de país en producción")

### 11. Reagendar una cita — ¿mismo Fallnummer?
Producción tiene un botón dedicado "Termin verschieben" (reagendar), no implementado todavía.
**¿Debe conservar el mismo Fallnummer/FAX-Code, o generar uno nuevo?**
📄 `docs/supuestos-F3.5.md` (fila "Acción Termin verschieben")

### 12. Uso de las 4 direcciones de email del terapeuta y "Login-Name"
Se añadieron los campos (`email`, `email_2`, `email_3`, `email_fachkreis`, `login_name`) pero
sin lógica de negocio.
**¿Para qué se usa cada dirección de email? ¿Qué tipo de notificación recibe cada una?
¿El "Login-Name" tiene algún uso más allá de ser un identificador?**
📄 `docs/supuestos-F3.5.md` (fila "Campos adicionales de Therapeut"), `docs/supuestos-F4.md` (fila "Recipientes")

### 12b. "Betreut durch" (Betreuer persistente) vs. `termins.betreuer_name` (por-cita) — y campo "new-date"
Detectado tras revisión del cliente sobre la ficha de Therapeut en producción: existe un
campo **"Betreut durch"** (columna "assigned to" en el listado) que asigna un Betreuer de
forma **persistente al terapeuta**, distinto del campo `termins.betreuer_name` que asumimos
desde F1 (texto libre, reintroducido en cada cita). Ya añadido como `betreuer_asignado` en
`Therapeut`, sin sustituir el campo existente en `Termin`.
**¿Cuál es el modelo correcto — el Betreuer se asigna una vez por terapeuta y se hereda en
todas sus citas, o se reintroduce en cada cita como asumimos? ¿Deben convivir ambos campos,
o hay que eliminar uno?** También sin confirmar: el campo `new-date` (booleano) visto en la
misma ficha — **¿qué marca? ¿terapeutas recién dados de alta?**
📄 `docs/supuestos-F3.5.md` (fila "Campos adicionales de Therapeut, segunda ronda"), `docs/supuestos-F1.md` (fila "Login de Betreuer")

### 13. Género "divers"
Añadido como tercera opción de Geschlecht (junto a weiblich/männlich).
**¿Ya se usa en producción? ¿Hace falta revisar el texto legal/DSGVO antes de exponerlo
en el portal público?**
📄 `docs/supuestos-F3.5.md` (fila "Listas configurables")

### 14. Modelo de disponibilidad — ¿Slots discretos?
Producción gestiona 109 slots individuales por asesor/día/hora (cada uno con su propio
interruptor activo/inactivo), en vez del horario semanal calculado que usamos nosotros.
**¿Merece la pena migrar a ese modelo antes de F9, o el horario calculado actual es
suficiente?** (ya pasa todos los tests de disponibilidad y es más simple de mantener)
📄 `docs/supuestos-F3.5.md` (fila "Modelo de Slots discreto")

---

## 🟢 Preguntas del plan original (F1–F3), aún sin cerrar

### 15. Herencia de citas del sustituto
**¿Un asesor sustituto hereda todas las citas ya existentes del asesor ausente, o solo
gestiona las nuevas durante la ausencia?** Por ahora ve y puede editar todas (incluidas las
preexistentes), pero no puede crear citas nuevas manualmente.
📄 `docs/supuestos-F2A.md`, `docs/supuestos-F2B.md`

### 16. Editabilidad del comentario interno
**¿El `interner_kommentar` debe ser editable solo por `admin`, o también por el `berater`
asignado/sustituto?** Actualmente lo pueden editar ambos.
📄 `docs/supuestos-F2B.md`

### 17. Textos exactos de toda la interfaz y los emails
Todos los textos (admin, portal, emails de F4) son una redacción razonable en alemán/español,
no textos oficiales acordados. **Validar literalmente antes de producción.**
📄 Todos los `docs/supuestos-FN.md`, especialmente `docs/supuestos-F4.md`

### 18. Acceso al dashboard de estadísticas para `berater`
El plan tiene una contradicción interna: en un punto dice que el dashboard está "fuera de
alcance" para `berater`, en otro lo lista como pregunta pendiente (¿debería ver sus propias
métricas?). Por ahora es exclusivo de `admin`.
**¿Debe `berater` tener acceso, aunque sea limitado a sus propias citas?**
📄 `docs/supuestos-F5.md`

### 19. Plazos de retención/purga de datos
Producción purga festivos expirados a los 28 días y citas expiradas a los 120 días (con 60
días de vista residual para Berater/Therapeut). No implementado todavía (pertenece a F8).
**¿Estos plazos son requisito DSGVO, o solo housekeeping operativo?** Si son requisito legal,
condicionan el diseño de F8.
📄 `docs/supuestos-F3.5.md` (fila "Reglas de retención/purga de datos")

---

## Notas de seguridad relacionadas (no son preguntas, son avisos)

- Durante la auditoría de F3.5 se vieron expuestas en texto plano, en el panel de producción,
  la contraseña del SQL Server (integración WordPress) y el token de API de solve360.
  **Se recomienda rotar ambas credenciales** independientemente de las respuestas anteriores.
- Ninguna de las preguntas anteriores ha bloqueado el desarrollo técnico hasta ahora — todo lo
  que no dependía de estas respuestas ya está implementado y testeado. Las respuestas de
  Verena solo son necesarias antes de F9 (UAT) y, en el caso de la pregunta 1 (límite de
  citas), antes de tocar la lógica síncrona ya construida.
- Tras dos rondas de revisión (la primera solo del listado de Berater, la segunda del
  formulario de edición completo, a petición del cliente), se encontraron y ya se
  implementaron sin necesidad de esperar respuesta de Verena: color de calendario, cierre de
  sesión automático configurable por asesor, y forzar cambio de contraseña — no tienen
  ambigüedad de negocio, solo se habían pasado por alto en la primera auditoría.
  📄 `docs/supuestos-F3.5.md` (fila "Campos de seguridad/UX en Berater, tercera revisión")