Lizandro GuarnizoandClaude Opus 5
018fb13332
Nuevo módulo `soporte` con la documentación del proyecto en cuatro secciones:
manual de usuario (visible para todos), y documentación técnica, arquitectura
y operación (solo administradores).
- Markdown.php: renderizador propio del subconjunto que usa la documentación
(encabezados, listas anidadas, tablas, código, citas). Escapa todo el texto
antes de aplicar formato, así que los .md no pueden inyectar HTML. Se
prefirió un archivo auditable a incorporar una dependencia externa.
- DocIndex.php: descubre los .md, arma el árbol, resuelve acceso por sección
y construye el índice del buscador.
- Generadores.php: expande marcadores {{modulos}}, {{endpoints}}, {{tablas}},
{{roles}} y {{servicios}} leyendo el código y la base en cada carga, para
que los inventarios no puedan quedar desactualizados.
Se registra en SYSTEM_MODULES y se concede a los 12 roles con permission=read.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3.4 KiB
Visión general
Este sistema es el ERP del Laboratorio Clínico Ximena Caicedo. Nació como un bot de WhatsApp y creció hasta cubrir la operación diaria del laboratorio: turnos presenciales, toma de muestras, domicilios, órdenes médicas, formularios firmados digitalmente y facturación del día.
Qué resuelve
| Área | Qué hace el sistema |
|---|---|
| Atención por WhatsApp | Bot que responde, agenda, envía consentimientos y encuestas |
| Turnero presencial | Kiosko, recepción, estaciones de toma de muestras, pantallas de TV |
| Domicilios | Agendamiento y asignación de enfermeros a visitas domiciliarias |
| Formularios | Consentimientos y fichas clínicas firmadas digitalmente |
| Laboratorio | Pacientes, órdenes médicas, exámenes, EPS, empresas, médicos |
Las tres capas
El código está organizado en tres niveles, de lo más general a lo más específico:
erp.php punto de entrada único del ERP
└── core/App.php arranque, sesión, enrutamiento, control de acceso
└── modules/<slug>/views/<vista>.php la pantalla concreta
└── modules/<slug>/api/*.php endpoints que consume por fetch
Debajo de todo eso están los servicios (services/), que encapsulan lo que habla con el mundo exterior — sobre todo la API de WhatsApp — y las clases de dominio (classes/lab/), que concentran las reglas de negocio de pacientes, domicilios, órdenes y formularios.
Convivencia con el sistema anterior
Hay dos generaciones de código funcionando a la vez, y es intencional:
- Archivos sueltos en la raíz (
lab_domicilios.php,index.php,ver_formulario_enviado.php, …). Es el sistema original. Siguen siendo el código real de muchas pantallas. - Módulos en
modules/. Es la estructura nueva. Algunos módulos son pantallas completas (turnero, registro de exámenes); otros son apenas un puente que incluye el archivo viejo.
Un ejemplo de puente, modules/lab_domicilios/views/index.php:
require_once APP_ROOT . '/lab_domicilios.php';
La migración es gradual y a propósito: mover una pantalla al nuevo esquema no obliga a mover las demás. Al leer el código, el archivo de la raíz suele ser el que manda; el módulo solo aporta el registro en el menú y el control de acceso.
Stack
| Componente | Detalle |
|---|---|
| Lenguaje | PHP 7.4+ (en producción corre sobre versiones más recientes) |
| Base de datos | MariaDB 11.8 |
| Frontend | HTML server-side + JavaScript sin framework; Bootstrap 5 y Font Awesome |
| Mensajería | WhatsApp Cloud API (Meta) |
| IA | Google Gemini Flash — asistente LIA del dashboard del turnero |
| Dependencias | Predis, Monolog, Guzzle, phpdotenv (vía Composer) |
No hay build step ni framework de frontend: las vistas son PHP que emite HTML y el JavaScript va embebido en la misma vista. Es deliberado — mantiene el despliegue en un simple git pull.
Por dónde seguir
- Enrutamiento y módulos — cómo una URL llega a una pantalla
- Roles y permisos — quién ve qué
- Modelo de datos — las 91 tablas, agrupadas
- Integración con WhatsApp — el punto más delicado del sistema