# Análisis general

## Resumen ejecutivo

Contingencia es una aplicación pequeña de captura y seguimiento de pedidos, construida sobre CodeIgniter Application Starter. El código define un circuito de registro público, consulta administrativa, finalización de renglones y exportación de datos. La simplicidad del monolito facilita localizar la lógica, pero varias reglas dependen exclusivamente del navegador y la protección de las páginas no se extiende a los endpoints que manipulan sus datos.

La prioridad técnica es consolidar integridad y control de acceso del flujo existente. La suite actual comprueba el funcionamiento básico del framework, pero todavía no demuestra la corrección del dominio.

## Alcance funcional observado

| Función | Estado en código |
| --- | --- |
| Consultar catálogo de artículos | Lectura completa de `items` para el formulario. |
| Capturar cliente y varios artículos | Implementado con carrito temporal en JavaScript. |
| Guardar pedido | Inserta cabecera y detalles mediante dos operaciones independientes. |
| Iniciar/cerrar sesión | Delegado a CodeIgniter Shield, con vista de login personalizada. |
| Consultar pedidos | DataTables consume la API y muestra una fila por detalle. |
| Completar un detalle | Actualiza su estado a `completed`. |
| Completar selección | Actualización por lote a partir de IDs de detalles. |
| Eliminar un detalle | Borrado lógico; elimina lógicamente la cabecera si queda vacía. |
| Exportar | Opciones CSV, Excel, PDF y portapapeles configuradas en DataTables. |
| Estadísticas | Ruta y vista existentes, sin indicadores implementados. |
| Gestión de catálogo y usuarios desde la aplicación | Sin módulos propios localizados; usuarios mediante mecanismos de Shield. |

La implementación fue revisada en código; no se ejercitó este circuito completo en navegador.

## Tecnologías y dependencias

| Capa | Declaración / versión bloqueada |
| --- | --- |
| PHP | `^8.2`; contenedor configurado para 8.3; CLI verificado en 8.5.0. |
| Framework | `codeigniter4/framework ^4.7` → `v4.7.2`. |
| Autenticación | `codeigniter4/shield ^1.3` → `v1.3.0`. |
| Configuración persistente | Dependencia transitiva `codeigniter4/settings v2.3.0`. |
| Pruebas | PHPUnit `10.5.63`, Faker `v1.24.1`, vfsStream `v1.6.12`. |
| Base de datos | Configuración principal `MySQLi`, UTF-8 de cuatro bytes. |
| Frontend | Vistas PHP y bibliotecas JavaScript distribuidas como archivos estáticos. |
| Servidor local | FrankenPHP y Caddy; integración declarativa con DAMP. |
| Analítica | Matomo incluido en formulario, login y layout administrativo. |

## Tamaño e inventario

En el momento de la revisión, `app/` contenía 89 archivos, `tests/` 10 y `public/` 1.348, aproximadamente 57,4 MB en este último directorio. El volumen de archivos públicos corresponde principalmente a recursos de la plantilla y bibliotecas; no equivale a complejidad funcional propia ni al peso transferido por cada página.

El núcleo de negocio tiene cinco controladores, dos modelos, dos entidades y cinco migraciones propias. `OrderDetail::index()` y `Dashboard::index()` son métodos vacíos. `welcome_message.php` conserva la página del starter sin una ruta explícita hacia ella.

## Aspectos favorables

- Separación MVC reconocible y puntos de entrada fáciles de ubicar.
- Dependencias PHP fijadas mediante `composer.lock`.
- Autenticación reutilizada de Shield en lugar de una implementación propia.
- Query Builder para acceso a datos y clave foránea entre detalles y cabeceras.
- Borrado lógico en ambos modelos y transacción al eliminar el último detalle.
- Migraciones con operaciones de subida y bajada declaradas.
- Composer, arranque de rutas, lint PHP y pruebas existentes pasan localmente.

## Áreas de mejora principales

1. **Acceso:** proteger los datos y acciones administrativas, no solamente el HTML del dashboard.
2. **Integridad:** validar en el servidor, limitar campos aceptados y guardar cabecera/detalles atómicamente.
3. **Contrato:** aclarar IDs de detalle, estados y significado de los resultados por lote.
4. **Interfaz:** corregir selección de SKU, duplicados y estados del botón de guardado.
5. **Pruebas:** cubrir comportamiento del dominio y migraciones en un motor compatible con producción.
6. **Operación:** documentar catálogo inicial, aprovisionamiento de usuarios y dependencia de DAMP.

Los detalles y evidencias se encuentran en [HALLAZGOS.md](HALLAZGOS.md).

## Límites del diagnóstico

No se inspeccionó el contenido de la base de datos ni se confirmó qué migraciones están aplicadas. No se midieron tiempos de respuesta, concurrencia o capacidad. Tampoco se ejecutó una auditoría de vulnerabilidades de dependencias ni una validación visual. La descripción de infraestructura corresponde al estado local, que incluye cambios previos sin commit.