# Gestión de Consultas — Núcleo (primera entrega de código real)

Esta es la primera pieza de código real de "Gestión de Consultas", construida módulo
por módulo como acordamos. Incluye el núcleo: **Consultas por día** + **confirmación
de citas agendadas desde app.hde** + **Atención clínica** en la ficha de cada cita.

## Qué SÍ incluye esta entrega

- Login real del personal (contra la tabla `usuarios` que ya existe en `prannetc_hde_app`).
- Matriz de permisos ya corregida y confirmada contigo: Soporte y Gerencia con acceso
  total; Administradora con sus funciones + Liquidación; Secretaria con lo necesario
  para el día a día; Profesional (`especialista`) viendo solo lo administrativo de sus
  propias consultas, en solo lectura.
- **Consultas por día**: lista las citas ya agendadas de una fecha, agrupadas por
  profesional, con un selector de fecha y de profesional.
- **Confirmación de citas agendadas desde la app**: se ve el comprobante de pago que
  subió la paciente, y al confirmar (presencial o virtual) el sistema registra la
  confirmación y dispara el aviso por correo y WhatsApp — ver siguiente sección sobre
  el modo de notificaciones.
- **Atención clínica** (historia clínica, receta, informe médico, orden de
  laboratorio) dentro de la misma ficha de cita, con el reparto de permisos que
  confirmaste: la profesional edita, Gerencia y Soporte ven en solo lectura,
  Administradora y Secretaria no acceden (Ley 29733).
- Cambiar el estado de seguimiento de una cita (Se atendió / En espera / Programada /
  No asistió / Cancelada / Reprogramada).

## Qué NO incluye todavía (próximos módulos, uno a la vez)

Calendario de horarios/turnos libres (depende del módulo de Horarios), Pacientes,
Liquidación, Trazabilidad, Importar Excel, Usuarios, Configuración, Soporte, Agenda
Smart, paquetes de Nutrición, eliminar/exportar PDF de la ficha, edición de los datos
del paciente. Todo esto se construye en los siguientes incrementos, revisando cada uno
contigo antes de seguir — tal como acordamos.

## Notificaciones por correo y WhatsApp — todavía en modo simulado

Dejaste pendiente de decidir el proveedor de correo y de WhatsApp. Mientras tanto,
`api/lib/config.php` tiene `GC_NOTIF_MODO = 'log'`: el sistema funciona con total
normalidad (la secretaria confirma, el estado cambia, la paciente queda "notificada"
en el registro), pero el envío real NO ocurre — queda registrado en
`storage/notificaciones.log` lo que se habría enviado. Cuando decidas el proveedor,
completa los dos bloques marcados `TODO` en `api/lib/notificaciones.php`
(`gc_enviar_correo` y `gc_enviar_whatsapp`) y cambia `GC_NOTIF_MODO` a `'activo'`.

Para las citas virtuales, por ahora es la secretaria (o quien confirme) quien pega el
enlace de la reunión al confirmar — igual que hoy lo haría manualmente. Generarlo en
automático necesitaría conectar la API de Google Calendar/Meet, que es otra decisión
aparte que podemos evaluar más adelante si te interesa.

## ⚠️ Antes de instalar: verifica el esquema real

Esta plataforma se construyó usando el **análisis de estructura** que hicimos del
esquema de `prannetc_hde_app` (Fase 1 del plan del proyecto), no viendo línea por
línea cada tabla. Los nombres de columna que asume el código (ver los comentarios al
inicio de `api/lib/auth.php`, `api/lib/clinica.php` y `api/modulos/citas.php`) son el
resultado de ese análisis, no una copia exacta y verificada del `SHOW CREATE TABLE`
real. Antes de instalar:

1. Ejecuta `SHOW COLUMNS FROM usuarios;`, `SHOW COLUMNS FROM citas;`,
   `SHOW COLUMNS FROM pacientes;`, `SHOW COLUMNS FROM especialistas;`,
   `SHOW COLUMNS FROM historias_clinicas;`, `SHOW COLUMNS FROM prescripciones;`,
   `SHOW COLUMNS FROM prescripcion_items;`, `SHOW COLUMNS FROM informes_medicos;`,
   `SHOW COLUMNS FROM ordenes_laboratorio;` contra tu base real.
2. Compara esos nombres contra los que usan los archivos de `api/`.
3. Si algo no coincide (por ejemplo si `pacientes.nombres` en realidad se llama
   `pacientes.nombre_completo`), avísame con la lista real y te entrego el ajuste —
   es un cambio rápido y acotado, no hay que rehacer nada.

Esto es exactamente la misma precaución que ya usamos con `sql/01_nucleo_consultas_app.sql`
(ver el Paso 0 de ese archivo): nunca se ejecuta nada a ciegas contra la base real.

## Verificación ya hecha en esta entrega

- `php -l` sin errores en los 9 archivos PHP.
- Probado con un servidor PHP local: las rutas exigen sesión donde deben (401), el
  login valida datos antes de tocar la base (400), los errores de conexión a la base
  se muestran de forma controlada sin exponer detalles técnicos (500 con mensaje
  genérico), y las rutas inexistentes devuelven 404 — todo sin errores de PHP en los
  logs.
- Pantalla de login probada en navegador (Playwright): carga la paleta e identidad
  visual real, y maneja con normalidad tanto la ausencia de sesión como el error de
  conexión a una base de datos (todavía sin configurar en este entorno de prueba).
- Lo que **no** se pudo probar aquí: el flujo completo contra datos reales (login
  exitoso, listar un día con citas, confirmar una cita, guardar la atención clínica),
  porque este entorno de trabajo no tiene un servidor MySQL/MariaDB disponible para
  levantar una copia de prueba de tu base. Por eso el Paso 0 de arriba es
  obligatorio antes de usarlo con pacientes reales.