# medis-tools

Herramientas de alto rendimiento para Medis365. Por ahora la única es el **exportador de expedientes**.

## Requisitos

- **Go 1.26.2 o superior** — solo en las máquinas donde se compila (tu Mac y el usuario de deploy del servidor). El web server **no** necesita Go.
- **make** — ejecuta los comandos del Makefile.
- **MySQL 8** accesible (conexión vía `config.json`).
- **tzdata** en el sistema — la herramienta fija la zona horaria a `America/Mexico_City`; sin él, `exportar` falla. macOS ya lo incluye.

## Instalación

`medis-tools` vive como **checkout hermano de `medis-back`** (mismo directorio padre): medis-back invoca al exportador con `realpath(FCPATH . '../medis-tools')`.

### macOS (desarrollo local)

```bash
# 1. Go y make
brew install go            # Go 1.26.2+  (verifica: go version)
xcode-select --install     # incluye make, si aún no lo tienes

# 2. Dependencias del módulo y verificación de compilación
cd /ruta/a/medis-tools
make tidy
go vet ./...

# 3. Crea config.json en la raíz (formato en «Configuración», más abajo)

# 4. Prueba de humo (necesita config.json + BD)
make dev accion=alcance db=<codigo_cliente> modules=expedientes
```

macOS ya trae `tzdata`, así que `America/Mexico_City` funciona sin configurar nada. Para uso local siempre usas `make dev` (compila y corre en un paso).

### Linux (servidores de pruebas y producción)

Clave: el usuario del web server (**`www-data`**) solo **ejecuta** el binario ya compilado; **Go solo hace falta para compilarlo** en el deploy. Así `www-data` no necesita Go, ni caché de Go, ni salida a internet.

```bash
# ---- 1. Paquetes del sistema (una vez) ----
sudo apt update
sudo apt install -y make tzdata ca-certificates git

# ---- 2. Go, solo para compilar en el deploy ----
ARCH=$(dpkg --print-architecture)                       # amd64 o arm64
curl -Lo /tmp/go.tgz "https://go.dev/dl/go1.26.2.linux-${ARCH}.tar.gz"
sudo rm -rf /usr/local/go && sudo tar -C /usr/local -xzf /tmp/go.tgz
sudo ln -sf /usr/local/go/bin/go /usr/local/bin/go
go version                                              # go version go1.26.2 linux/...

# ---- 3. Repo hermano de medis-back + config.json del entorno ----
# medis-tools y medis-back comparten directorio padre.
# Crea config.json en la raíz (ver «Configuración»); credenciales,
# `central` y `clientes_dir` son PROPIAS de cada entorno (pruebas ≠ producción).

# ---- 4. Compilar (paso de cada deploy) ----
cd /ruta/a/medis-tools
make build                                              # -> bin/exportador-expedientes

# ---- 5. Permisos para el usuario del web server ----
sudo chown -R www-data:www-data exportaciones           # ahí escribe zip/estatus/log
sudo chown www-data:www-data config.json
sudo chmod 640 config.json                              # www-data lo lee (trae la contraseña de BD)

# ---- 6. Verificar como lo invoca PHP (usuario www-data) ----
sudo -u www-data bash -c 'cd /ruta/a/medis-tools && make -s exec accion=estatus'                                         # el binario corre
sudo -u www-data bash -c 'cd /ruta/a/medis-tools && make -s exec accion=alcance db=<codigo_cliente> modules=expedientes' # conecta a BD
```

**Notas del servidor**

- **`tzdata` es obligatorio**: sin él la exportación termina en `ERROR` (`LoadLocation("America/Mexico_City")`).
- **Invocación on-demand**: medis-back corre `make exec` por cada request; no hay daemon ni servicio que mantener.
- **Pruebas vs producción**: el setup es idéntico; solo cambia `config.json` (en producción `clientes_dir` suele ser `medis-demo-pro`).
- **El primer `make build` necesita internet** para descargar los módulos de Go. Si producción no tiene salida a internet: compila en pruebas y copia el repo (con su `bin/exportador-expedientes`), o pre-puebla el module cache con `go mod download`.
- **El binario no es 100% autónomo**: lee las fuentes tipográficas de `assets/` en tiempo de ejecución, por lo que el repo (con `assets/`) debe estar presente y `make exec` se corre desde la raíz del repo (medis-back ya hace `cd` ahí).

**Actualizar en cada deploy**

```bash
cd /ruta/a/medis-tools
git pull
make build
```

No hace falta repetir permisos: `bin/` y `exportaciones/` están fuera de git, y el binario recompilado queda ejecutable para `www-data`.

## Configuración

Crea `config.json` en la raíz (ignorado por git; **obligatorio** para `exportar` y `alcance`):

```json
{
	"db": {
		"usuario": "root",
		"password": "",
		"host": "localhost"
	},
	"central": "CENTRAL",
	"clientes_dir": "../medis-back/clientes"
}
```

Los campos omitidos usan esos valores por defecto. El puerto es fijo (`3306`); la base a exportar se pasa con `-db`, no aquí.

- **`central`**: nombre real de la base central que las queries referencian como `CENTRAL`; se sustituye automáticamente.
- **`clientes_dir`**: directorio **padre** de las carpetas de archivos de cliente (se le concatena `{db}`). En producción suele ser `medis-demo-pro`. Solo lo usa el módulo `archivos`.

## Comandos

```bash
make dev     # go run (uso local; recompila en cada corrida)
make build   # compila bin/exportador-expedientes (paso de deploy)
make exec    # ejecuta el binario YA compilado (lo invoca medis-back; requiere 'make build' antes)
make tidy    # limpia go.mod / go.sum
```

Los flags se pasan como variables: `make dev accion=... db=... modules=... medic=... password=...` (la variable `modules` mapea al flag `-modulos`).

## Exportador de expedientes

### Acciones

| Acción | Descripción |
|--------|-------------|
| `exportar` | Genera los PDFs y los empaqueta en un ZIP cifrado |
| `estatus` | Devuelve el JSON de estado de la última exportación |
| `alcance` | Cuenta cuántos registros hay por módulo antes de exportar |

### Flags

| Flag | Requerido en | Descripción |
|------|-------------|-------------|
| `-accion` | siempre | `exportar`, `estatus` o `alcance` |
| `-db` | `exportar`, `alcance` | Nombre de la base MySQL |
| `-modulos` | `exportar` | Módulos separados por coma |
| `-password` | `exportar` | Contraseña para cifrar el ZIP |
| `-medic` | opcional | ID(s) de médico para filtrar pacientes |

### Módulos

| Módulo | Contenido |
|--------|-----------|
| `general` | Clínica, médicos y lista de pacientes |
| `expedientes` | Expediente clínico por paciente |
| `agenda` | Citas agendadas |
| `caja` | Cargos, abonos y cotizaciones por paciente |
| `archivos` | Archivos del cliente en `{clientes_dir}/{db}/` |

### Ejemplo

```bash
make dev accion=exportar db=clinica_db modules=general,expedientes,caja,archivos password=mi_password
make dev accion=alcance db=clinica_db    # consultar alcance antes de exportar
```

### Salida (en `exportaciones/`)

- **`{db}.zip`** — ZIP cifrado con PDFs y archivos del cliente.
- **`estatus.json`** — estado de la última exportación (ver abajo).
- **`exportacion.log`** — log de la última corrida (se sobreescribe).

### estatus.json

```json
{
  "db": "clinica_db",
  "modulos": ["expedientes", "caja"],
  "medicos": [],
  "pacientes_total": 120,
  "fecha_inicio": "2026-06-25 10:00:00 AM",
  "fecha_fin": "2026-06-25 10:05:42 AM",
  "duracion_segundos": 342.5,
  "duracion_segundos_pdfs": 330.16,
  "duracion_segundos_compresion": 12.34,
  "pico_ram_mb": 412.5,
  "peso_pdfs_mb": 180.4,
  "peso_archivos_mb": 95.2,
  "peso_zip_mb": 210.7,
  "progreso": 100,
  "estatus": "COMPLETADO",
  "mensaje": "Exportación completada"
}
```

- `estatus` es `EN_PROCESO`, `COMPLETADO` o `ERROR`; `modulos` no incluye `general`.
- `pico_ram_mb` (RAM máxima del proceso) se actualiza en cada escritura; las duraciones y los `peso_*_mb` se llenan al completar (mientras tanto quedan en cero, igual que `fecha_fin`).