# Instalación — labSoft

## a. Requerimientos

- PHP 8.1 o superior, con extensiones: `mysqli`, `mbstring`, `json`, `intl` (las que ya trae CodeIgniter 4 por defecto)
- MySQL 5.7+ o MariaDB equivalente
- Servidor web (Apache con `mod_rewrite`, que es lo que ya corre en Hostinger/sistematlan.com)
- Composer (solo si vas a modificar dependencias; el proyecto ya viene con `vendor/` listo)

## b. Configurar el `.env`

1. Copia `.env.example` a `.env`.
2. Llena los valores reales:
   - `app.baseURL` — la URL pública del sitio (con `/` al final).
   - `database.default.*` — credenciales de tu base de datos MySQL.
   - `encryption.key` — genera una con `php spark key:generate` (necesaria para sesiones/CSRF).
3. Deja `CI_ENVIRONMENT = production` en el servidor real (solo usa `development` en tu máquina local).
4. **Nunca subas `.env` a git** — ya está en `.gitignore`.

## c. Ejecutar `schema.sql` y `seed.sql`

Ambos scripts asumen una base de datos MySQL nueva (no existente):

```bash
mysql -u tu_usuario -p < database/schema.sql
mysql -u tu_usuario -p laboratorios_bello < database/seed.sql
```

- `schema.sql` crea la base de datos `laboratorios_bello` y todas sus tablas (incluye su propio `CREATE DATABASE IF NOT EXISTS`).
- `seed.sql` inserta lo mínimo para operar: sucursal principal + su consecutivo, usuario admin, configuración de puntos, y el catálogo de 87 análisis con sus plantillas de captura de resultados.
- Ambos se validaron ejecutándolos de punta a punta contra MySQL real antes de esta entrega.

Después de los SQL, instala dependencias y ejecuta las **migraciones** (agregan los campos de
auditoría/soft delete, la bitácora `auditoria`, y desde 2026-07 las tablas de **CodeIgniter
Shield** — `users`, `auth_identities`, `auth_groups_users`, ... — a las que se migra la vieja
tabla `usuario` preservando IDs):

```bash
composer install               # requerido: el auth usa codeigniter4/shield + settings
php spark migrate --all        # --all: incluye las migraciones de Shield y Settings
```

### BD vacía (solo migraciones, sin schema.sql)

Desde 2026-07-28 la migración `CreateCoreBusinessTables` crea las tablas de negocio
base (`analisis`, `ventas`, `maximos`, …) si no existen. Luego el resto de migraciones
añade tenant/auditoría/Shield.

```bash
php spark migrate --all
```

Sigue siendo **recomendable** importar `database/seed.sql` para
catálogo y usuario inicial de laboratorio; las migraciones no sustituyen el seed de análisis.
Si la BD se creó a medias y falló a mitad, vuelve a correr `migrate --all` (idempotente).

> Los cambios de esquema nuevos ya no se agregan a `schema.sql`; viven en `app/Database/Migrations/`.
> El login sigue siendo por usuario (no email); los emails de `auth_identities` son placeholders internos.

**Usuario inicial:**
```
login:    admin
password: CambiaEstaPassword123
```
Cámbiala de inmediato desde Admin › Usuarios tras el primer login.

## d. Configurar el VirtualHost / subdominio

El **document root debe apuntar a la carpeta `public/`**, no a la raíz del proyecto (así es como ya corre Cháchara Infernal en el mismo hosting). Ejemplo de VirtualHost:

```apache
<VirtualHost *:80>
    ServerName laboratorios.tudominio.com
    DocumentRoot /ruta/al/proyecto/lab-bello/public
    <Directory /ruta/al/proyecto/lab-bello/public>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>
```

Si el panel de hosting no permite cambiar el document root (algunos hostings compartidos con subdominios en carpetas fijas), sube todo el proyecto y crea un `.htaccess` en la raíz que redirija a `public/` — pero el hosting actual (Hostinger) sí permite apuntar el subdominio directo a `public/`, que es la opción recomendada.

`public/.htaccess` ya viene configurado (mod_rewrite estándar de CI4, probado).

## e. Primer login y qué configurar primero

1. Entra con `admin` / `CambiaEstaPassword123` y cambia la contraseña (Admin › Usuarios › Cambiar contraseña).
2. **Sucursales** (Admin › Sucursales): revisa/ajusta la "Sucursal Principal" creada por el seed, o agrega las demás sucursales reales.
3. **Precios** (Admin › Precios): todos los análisis entran en $0.00 — captúralos antes de operar (edición por fila o ajuste masivo por %).
4. **Empleados y usuarios** (Admin › Empleados): crea las cuentas del personal real (cada una puede generar su usuario de acceso en el mismo paso).
5. **Configuración de puntos** (Admin › Configuración): ajusta `puntos_max`/`descuento_max` si 30 puntos / 10% no aplica a tu operación.

---

## Pendientes conocidos (no incluidos en estos 20 días)

- **Lector de huella digital** — requiere hardware específico, fuera de alcance.
- **App móvil para resultados**, **notificaciones por WhatsApp/email**, **dashboard con gráficas**, **backup automático** — no solicitados en el plan original.
- **Carrito de venta no sobrevive una expiración de sesión.** La sesión dura 2 horas (`app/Config/Session.php`), suficiente para una venta normal. Si expira a mitad de una cotización, el carrito en sesión se pierde y el empleado es redirigido a `/login` sin aviso explícito de la pérdida — no hay forma de detectarlo después del hecho porque la sesión anterior ya no es accesible. Si esto se vuelve un problema real en producción, la solución sería persistir el carrito en una tabla (`cotizacion_borrador` o similar) en lugar de solo en sesión.
- **CRUD de Clientes, Empleados y Sucursales sin validación server-side** de campos obligatorios (solo HTML5 `required`, evitable con una petición directa). Se corrigió puntualmente en Admin › Análisis (Día 19) porque el checklist lo pedía explícitamente; el resto de los CRUDs quedan con el mismo patrón que tenían desde que se escribieron.