FT-ACT-03 · Imágenes del seller por URL con validación y corrección…

En 30 segundos

Muchos sellers ya tienen sus fotos en su propio sitio web. Con esta épica pegan la URL de cada imagen en la plantilla, por color y posición, y Activos digitales la descarga una sola vez, la revisa, le corrige el tamaño, la resolución y el centrado y la guarda junto a la original. La tienda nunca usa la URL del seller, y una imagen que sólo sirve para buscar coincidencias no se liga al producto.

• Módulo dueño: MS-11 Activos digitales. También participan: MS-02 Producto, MS-06 Evaluación, MS-13 Identidad y acceso, MS-14 Avisos y ayuda.
• Etapa 6 · Imágenes. Recibe «PE-3 · Plantilla asignada» y entrega «PE-7 · Imágenes listas».
• APIs: construye 1 y usa 7 que construyen otras épicas.
• Eventos: publica 4 y consume 3.

1. Dónde encaja

Recibe

Entrega

2. Diagrama de contexto

Quién participa y cómo se conecta. Las pantallas llegan por el BFF del portal, que valida el token y compone; cada módulo vuelve a validar el token y decide sus permisos con los roles de MS-13.

🟩 Verde: nuevo, se construye · 🟦 Azul: ya existe y se queda, se reutiliza su código · 🟧 Naranja: temporal o se retira (se apaga en R3) · ⬜ Gris: sistema externo · ★ módulo dueño

3. Diagrama de flujo

El camino principal, paso por paso. Cuando una pantalla llama a un módulo se ven dos flechas: la pantalla al BFF y el BFF al módulo. Los eventos salen del outbox del módulo después de guardar; quien los consume ignora los repetidos.

3.1 Imagen sólo para buscar coincidencias

3.2 URL por la API de terceros o en carga masiva

4. Si algo sale mal

• La URL no se puede leer sin credenciales. MS-11 la rechaza con el motivo «URL no pública»; el seller lo ve en el recibo y en su campana, corrige la URL y la vuelve a registrar.
• La imagen no se puede corregir. Si está corrupta o su proporción no se arregla con el centrado y los márgenes de la ficha, se rechaza con el motivo de hoy («Error en proporción», «DPI insuficiente», «Imagen corrupta o formato no correcto»). La imagen de consulta sí sirve para buscar coincidencias.
• La URL es de un dominio que el seller no registró, por ejemplo de la competencia. El registro responde 422 BUSINESS_ERROR; en la carga masiva o por API se rechaza ese renglón con su motivo y los demás siguen.
• El servidor del seller tarda o falla. MS-11 reintenta tres veces durante diez minutos; después rechaza con «No se pudo descargar». Nada se publica desde el servidor del seller.
• El seller cambia la foto en su servidor después de registrarla. No cambia nada en la tienda: Liverpool sirve su propia copia. Para cambiarla, el seller registra otra vez la URL y se crea un activo nuevo.

5. APIs

Las que construye esta épica (1)

{
  "productId": "PRD-0009120",
  "scope": "COLOR",
  "colorCode": "ROJO",
  "assetType": "PRINCIPAL",
  "position": 1,
  "sourceUrl": "imagenes.seller0001.ejemplo/playeras/rojo-frente.jpg",
  "kind": "FILE",
  "purpose": "PRODUCT",
  "origin": "SELLER_URL"
}

{
  "success": true,
  "data": {
    "requestId": "req-6b0d13",
    "assetId": "ast-9e40a2",
    "status": "ACCEPTED",
    "receiptUrl": "/api/v2/asset-receipts/req-6b0d13"
  }
}

Las que usa y construye otra épica (7)

Su request y su response están en la página de la épica que la construye.

6. Eventos

Publica

Consume

7. Datos

Cada colección tiene un solo dueño, el único que escribe en ella.

8. Historias que cubre

9. Decisiones de esta épica

Las tomó el TL como arquitecto; quedan como [Propuesta] hasta que el equipo de la épica las revise.

• D-ACT-03-1. El seller da URL públicas y MS-11 descarga la imagen una sola vez y la sirve desde la red de entrega de Liverpool; nunca se publica ni se enlaza la URL del seller. Por qué: Decide la mitad de PD-21 que toca al seller: con URL externas la tienda dependería de servidores ajenos y las fotos cambiarían sin control. Se apoya en PD-21, RSG-33, RF-IMG-01.
• D-ACT-03-2. La corrección técnica (72 DPI, tamaño a la ficha y centrado con los márgenes de 25 px) es procesamiento fijo dentro de MS-11, no IA. Se guarda la original junto a la corregida y el recibo dice qué se corrigió. Por qué: Son reglas medibles que no necesitan un modelo; deja la IA para lo que sí la necesita y responde la parte de DUD-35 que toca a esta épica. Se apoya en DUD-35, RF-IMG-04.
• D-ACT-03-3. Imagen de consulta e imagen de carga son dos propósitos del mismo registro: con MATCHING la copia es temporal (24 horas), no exige la ficha y nunca se liga al producto; con PRODUCT se valida y, si no cumple ni se puede corregir, se rechaza. Por qué: Lo pide RF-IMG-05 y evita que una foto de búsqueda termine publicada. Se apoya en RF-IMG-05, PEN-53.
• D-ACT-03-4. «URL propias» quiere decir dominios que el seller registró en su ficha de tercero en MS-13. En la carga masiva y por API, un renglón con otro dominio se rechaza con su motivo; los demás siguen. Por qué: Es la forma verificable de RN-IMG-11; una lista de competidores nunca estaría completa. Las URL se capturan dentro del archivo de plantilla, como respondió S20 para PEN-57. Se apoya en PEN-57, RN-IMG-11.
• D-ACT-03-5. La captura por URL se construye para el alta de sellers del TO-BE (R4) y sirve igual a proveedores de Mercaderías, como se acordó en S16; mientras tanto el seller sigue cargando archivos por el portal contra el mismo MS-11. Por qué: PD-02 propone el alta TO-BE de sellers en R4; el registro por URL no cambia el resto del flujo. Se apoya en PD-02, S16-RF-01.

Qué falta decidir

También siguen abiertos: PEN-57, Definir cuándo corre la revisión de calidad de la imagen en la carga masiva; PEN-53, Decidir si se usan imágenes del scraping cuando no hay coincidencia.

Fuentes

1. [D] trazabilidad/features/FT-ACT-03-imagenes-seller-por-url.md: la ficha de la épica, con sus historias, reglas y bloqueos.
2. [D] ADR-12 · Un solo sistema: backend compartido y una sola base (sección 3.4).
3. [D] docs/arquitectura/por-epica/base/: piezas, colecciones, eventos y el hilo de punta a punta.
4. [D] docs/arquitectura/omega-a-pim-headless/contratos-api.md: convenciones y endpoints de partida.
5. [D] docs/arquitectura/maquina-de-estados-to-be/propuesta-maquina-de-estados.md §7: estados, tareas y canales.
6. [I] Las decisiones de la sección 9 son del TL sobre esas fuentes.