# Desarrollo, infraestructura y verificación

## Requisitos

- PHP compatible con `^8.2`; el Dockerfile usa PHP 8.3.
- Composer y extensiones requeridas por las dependencias. Para la aplicación, también `mysqli`; para las pruebas predeterminadas, `sqlite3`.
- MySQL o motor compatible con las migraciones propias.
- Escritura en `writable/`.
- Servidor con raíz documental en **`public/`**.

## Preparación local

Procedimiento orientativo derivado del código; no se ejecutaron aquí la instalación de base de datos, la carga de catálogo ni el alta de usuarios.

1. Instalar las dependencias fijadas:

   ```sh
   composer install
   ```

2. Si no existe `.env`, copiar la plantilla `env`. Configurar `CI_ENVIRONMENT`, `app.baseURL` y `database.default.*` con los datos del entorno local. Mantener el `.env` existente cuando ya esté configurado.
3. Crear una base de datos de desarrollo y ejecutar sus migraciones, incluyendo namespaces de dependencias:

   ```sh
   php spark migrate --all
   ```

4. Cargar el catálogo `items`. **No existe seed ni importador propio versionado**; se necesita acordar la fuente del catálogo.
5. Crear un usuario con Shield, por ejemplo mediante su comando interactivo:

   ```sh
   php spark shield:user create
   ```

6. Iniciar el servidor local y usar una `app.baseURL` coherente con su dirección:

   ```sh
   php spark serve
   ```

El registro web está deshabilitado. `shield:setup` no es parte necesaria de este procedimiento: el repositorio ya contiene la configuración de Shield.

## Entorno Docker / DAMP observado

| Archivo | Función |
| --- | --- |
| `Dockerfile` | Imagen `dunglas/frankenphp:1-php8.3`; instala extensiones y configura Caddy. |
| `docker-compose.yml` | Servicio `app`, montaje `./:/app`, Caddyfile de solo lectura y red externa `damp`. |
| `Caddyfile` | HTTP en puerto 80, raíz `/app/public`, `php_server`, reescritura y log a stdout. |
| `Dampfile` | Declara `contingencia.test`, PHP 8.3, raíz `public` y creación de `contingencia_db`. |

El servicio limita memoria a 512 MB, CPU a 1,5 y procesos a 256. Compose configura desarrollo y usa `damp-db:3306` como servidor de base de datos. Las credenciales de desarrollo están escritas en el Compose; sus valores no se duplican en estos documentos.

**Dependencias operativas:** Compose no define el servicio MySQL, no publica puertos al host y requiere una red ya existente. El acceso por `contingencia.test` depende del entorno DAMP y su resolución/enrutamiento. `docker compose up --build` por sí solo no aprovisiona toda esa infraestructura.

La imagen no copia el código de aplicación ni instala sus dependencias con Composer: depende del bind mount y de un `vendor/` preparado. Por ello, el Dockerfile actual describe un runtime de desarrollo, no una imagen autocontenida de despliegue. Caddy tiene HTTPS automático desactivado; una eventual terminación TLS externa no está documentada en el repositorio.

## Comandos de diagnóstico

```sh
composer validate --no-check-publish
composer check-platform-reqs
php spark routes
php vendor/bin/phpunit --no-coverage --no-logging --do-not-cache-result
```

También existe `composer test`, que ejecuta PHPUnit con la configuración estándar. `phpunit.xml.dist` usa el bootstrap del framework y normalmente genera artefactos en `build/`; el comando usado en esta revisión desactiva cobertura, logs de PHPUnit y caché de resultados.

## Resultados obtenidos el 2026-09-28

Entorno: macOS, PHP CLI **8.5.0**, Composer **2.8.12**.

| Comprobación | Resultado |
| --- | --- |
| `composer validate --no-check-publish` | `composer.json` válido. |
| `composer check-platform-reqs` | Todos los requisitos declarados de las dependencias instaladas satisfechos. |
| `php spark routes` | Arranque correcto; CI 4.7.2 y rutas efectivas obtenidas. |
| PHPUnit sin cobertura/logs/caché | **5 pruebas, 7 aserciones, todas correctas.** |
| `php -l` | **88 archivos comprobados, 0 fallos**: PHP de `app/`, `tests/` y entradas `public/index.php`, `preload.php`, `spark`, `builds`. |

La verificación de requisitos de Composer no prueba conectividad MySQL ni comprueba todos los requisitos operativos opcionales. El lint no ejecuta la lógica del negocio.

### Qué prueban los tests existentes

- `tests/unit/HealthTest.php`: constantes de arranque y formato de URL base.
- `tests/session/ExampleSessionTest.php`: escritura/lectura simple de sesión.
- `tests/database/ExampleDatabaseTest.php`: consulta y soft delete del modelo de ejemplo.

Los tests de base usan su propio esquema de soporte. No prueban `OrderModel`, `OrderDetailModel`, controladores de pedidos, autorización de rutas ni migraciones propias. No se localizaron workflows en `.github/workflows/`.

## Verificaciones futuras pertinentes

Al intervenir el flujo de pedidos, añadir pruebas de acceso anónimo/autenticado, validación, persistencia atómica, ID inexistente, conteo real del lote y borrado del último detalle. Para cambios de esquema, verificar migración y reversión en una base MySQL aislada. Para cambios del formulario, probar selección de producto, duplicados, edición de cantidades y recuperación tras un error de guardado.

## Estado de trabajo preservado

El análisis partió de cambios locales en `Caddyfile`, `Dockerfile`, `docker-compose.yml` y de `Dampfile` sin seguimiento. Esos archivos no se modificaron durante esta tarea. No se ejecutaron migraciones ni peticiones de creación, finalización o borrado sobre datos de la aplicación.