# Architect — F-052

## Diagnóstico
- Las URLs de imagen de producto se almacenan como `/uploads/<uuid>.<ext>` en `catalog_product_images.url`.
- Solo el admin (`apps/admin/public/uploads/`) tiene esos archivos.
- El frontend (3003) y el storefront (3005) sirven estáticos desde sus propios `public/`, que no contienen `uploads/`.
- El backend (3000) no tiene una ruta `/uploads/` y por tanto tampoco puede servirlos.
- Resultado: `<img src="/uploads/...">` desde frontend/storefront → 404.

## Solución elegida
**Sincronizar `public/uploads/` del admin al frontend y al storefront en cada upload, y al arranque.**

Pasos:
1. Crear un helper que, ante una subida nueva en el admin (`/api/upload`), copie el archivo a `frontend/public/uploads/` y `storefront/public/uploads/` después de escribirlo.
2. Al arranque de `monolith.sh`, sincronizar los archivos existentes con `rsync` para cubrir el caso "arranque en frío sin uploads aún".
3. El backend sigue siendo solo API; no se añade ruta `/uploads/`.

Razón de no añadir ruta backend:
- Mantener el backend libre de filesystem compartido.
- Evita acoplarse a `process.cwd()` del backend, que es distinto al del admin.
- El admin es el único origen de uploads.

## Alternativas descartadas
- **Ruta `/uploads/` en el backend**: requiere cambiar `cwd` o aceptar una ruta absoluta; complica el deployment.
- **Proxy desde frontend a admin**: añade un round-trip y un puerto extra en la URL.

## Acceptance
- Tras subir una imagen desde el admin, esa imagen aparece como 200 en:
  - `GET http://192.168.18.93:3003/uploads/<file>`
  - `GET http://192.168.18.93:3005/uploads/<file>`
- Tras un restart del monolito, los uploads ya existentes se sincronizan.
- `next build` no falla por assets faltantes.