Arquitectura por épica · El sistema y el hilo de punta a punta

Actualizado el 18-oct-2026. Primera versión: 74 épicas con su arquitectura, construidas sobre ADR-12.

Qué responde. Cómo se arma el Nuevo PIM como un solo sistema y cómo se entrelazan sus 74 épicas, de la propuesta que entra hasta el producto publicado en cada canal.

Para quién. Todos los equipos del Nuevo PIM, de Entrada Única y de Foro, y arquitectura.

Estado. [Propuesta] del TL del Nuevo PIM, 18-oct-2026, construida sobre ADR-12. La spec de cada épica dice el qué; estas páginas, el cómo.

Fuente. docs/arquitectura/por-epica/, generada con generar.py; los datos de cada épica están en epicas/ y los comunes en base/.

En 30 segundos

Un solo sistema. El Nuevo PIM, Entrada Única Catalogación y Foro son uno: un backend por módulos, una sola base pim y un solo BFF del portal por el que llegan las pantallas. Lo decidió el TL en ADR-12, con las decisiones 19 y 20 del backend compartido.
Cada dato tiene un dueño. Cada colección la escribe un solo módulo; los demás la leen por su API o se enteran por sus eventos.
Cada épica es un engranaje. Dice qué recibe, qué entrega, qué APIs construye y cuáles usa. Hoy son 74 de 74 épicas y 346 APIs citadas.
Todo llega al mismo punto. Da igual por dónde entre una propuesta (pantalla, archivo, plantilla en línea o API de terceros): sigue el mismo hilo hasta «PE-9 · Publicado por canal».
Para leer una épica: su contexto (quién participa), su flujo (en qué orden), sus APIs (con request y response) y a quién le entrega.

1. Un solo sistema

La entrada tiene tres puertas. Las pantallas (el portal de catalogación, con el módulo de Foro, y el portal del estudio) llegan por un solo BFF del portal, que valida el token, aplica los permisos de pantalla y compone; no guarda datos ni decide reglas. El agente del estudio entra directo a Activos digitales. Los sistemas de proveedores y sellers entran por el gateway de terceros. Cada módulo vuelve a validar el token (ADR-05), y los sistemas externos sólo hablan con los adaptadores.

No hay capa de compatibilidad: cada pantalla se cambia una sola vez al BFF, en la oleada en que existe su módulo dueño (R1 catálogo, categorías, activos y avisos; R2 propuestas, carga masiva, reportes, Foro y el estudio), y en R3 se apagan con tráfico cero los backends de Entrada Única y de Foro y P360.

El Nuevo PIM como un solo sistema

🟩 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

2. El hilo de punta a punta

El producto pasa por las etapas como por una línea de ensamble. Entre una etapa y la siguiente hay un punto de encuentro: el estado exacto en que una deja el producto para que la otra lo tome.

El hilo de punta a punta

Punto	Qué significa
PE-C · Catálogo vigente	Plantillas, atributos, listas, reglas, diccionarios y categorías publicados por Catálogo (MS-01). Todas las etapas los leen por la API de MS-01 y se enteran de sus cambios por catalog.governance.changed.
PE-T · Usuario con permisos y bitácora	Quien llama ya se identificó, MS-13 dice qué puede hacer, y cada cambio queda en la bitácora de MS-05. Lo usan todas las etapas.
PE-1 · Propuesta en Borrador	Existe un documento en products con estado Borrador, negocio, origen (PORTAL, BULK, PARTNER_API) y dueño. Da igual por dónde entró: de aquí en adelante es el mismo producto.
PE-2 · Sin duplicado	La evaluación de MS-06 quedó guardada en el producto: no está en la lista negra y no existe otro igual. Si ya existía, en Mercaderías no se duplica y en Marketplace se vuelve oferta (sale del hilo como OFFER_CREATED).
PE-3 · Plantilla asignada	El producto tiene plantilla y negocio, y la vista efectiva de MS-01 dice qué pedir y qué es obligatorio.
PE-4 · Propuesta enviada	Estado En revisión, con los obligatorios completos y la Validación automática aprobada.
PE-5 · Visto bueno dado	Estado Creación de SKU: Compras aceptó (Mercaderías) o la Calificación de IA confirmó lo que el SKU necesita (Marketplace). Se pidió el artículo a SAP con SAP_CREATION_REQUESTED.
PE-6 · SKU asignado	Estado En enriquecimiento: SAP devolvió el 122, cada variante tiene SKU y se abrieron en paralelo las tareas de foto, secciones con dueño y, si hace falta, Gobierno de Datos.
PE-7 · Imágenes listas	La tarea Foro o Carga de imagen se cerró: las imágenes están en MS-11 con URL congelada y ligadas a su variante y posición.
PE-8 · Aprobado	Estado Aprobado: calidad y categoría aprobadas, sin tareas que bloqueen. Cada canal del negocio queda en Pendiente y se pide la publicación con PUBLICATION_REQUESTED.
PE-9 · Publicado por canal	Cada destino devolvió su acuse: el canal está Publicado (o Error, que se republica). Es el punto final del hilo: aquí llegan todas las entradas.
PE-10 · Cambio aprobado	Un cambio a un producto aprobado pasó su Revisión del cambio o el Repoblamiento: el producto vuelve a Aprobado y los canales afectados pasan de Publicado a Enviado (regresa a PE-8).
PE-M · Producto migrado	MS-03 cargó el producto desde P360 con su estado y su estado por canal: entra al hilo en PE-8 o PE-9 sin repetir las etapas.

3. Las etapas

Arquitectura de la etapa 0 · Entrada: ¿Por dónde entra una propuesta? 5 épicas.
Arquitectura de la etapa 1 · ¿Ya existe?: ¿Está prohibida o ya la tenemos? 6 épicas.
Arquitectura de la etapa 2 · Plantilla: ¿Qué datos hay que pedirle? 4 épicas.
Arquitectura de la etapa 3 · Captura: ¿Ya tiene todo lo obligatorio? 7 épicas.
Arquitectura de la etapa 4 · Visto bueno: ¿Alguien la aprueba para crear el SKU? 4 épicas.
Arquitectura de la etapa 5 · SKU en SAP: ¿SAP ya creó el artículo? 4 épicas.
Arquitectura de la etapa 6 · Imágenes: ¿Quién pone la foto y ya está? 7 épicas.
Arquitectura de la etapa 7 · Calidad y categoría: ¿El producto está bien para venderse? 4 épicas.
Arquitectura de la etapa 8 · Publicación: ¿Ya llegó a cada canal? 5 épicas.
Arquitectura de la etapa 9 · Modificación: ¿Qué pasa si cambian un producto publicado? 2 épicas.
Arquitectura · Configuración del catálogo: ¿Con qué reglas se catalogan los productos? 8 épicas.
Arquitectura · Lo transversal: ¿Qué sostiene a todas las etapas? 13 épicas.
Arquitectura · Migración y convivencia: ¿Cómo llegan los productos que ya existen? 5 épicas.

4. Cómo leer una página de épica

En 30 segundos: qué resuelve, quién es el dueño y qué recibe y entrega.
Diagrama de contexto: las piezas que participan, con el módulo dueño resaltado.
Diagrama de flujo: el camino principal, numerado; los otros caminos van aparte.
APIs: primero las que construye la épica y luego las que usa; cada una se abre con su request, su response y sus errores.
Eventos, datos e historias: qué avisa, qué guarda y qué historia de usuario cubre cada parte.

Las piezas, las colecciones, los eventos y las convenciones están en Arquitectura por épica · Piezas, datos, eventos y reglas; todas las APIs, en Arquitectura por épica · Catálogo de APIs.

Qué falta decidir

ID	Qué falta
PD-26	Dónde vive el directorio único: ADR-12 lo pone en Identidad y acceso (MS-13).
PD-29	Ratificar el modelo de estados B (ciclo de vida, tareas y estado por canal) sobre el que corre el hilo.
ADR-12	Registrar la decisión en la primera sesión de la TDA.

Fuentes

[D] ADR-12 · Un solo sistema: backend compartido y una sola base.
[D] docs/arquitectura/por-epica/base/: piezas, colecciones, eventos, hilo y endpoints de partida.
[D] docs/arquitectura/maquina-de-estados-to-be/propuesta-maquina-de-estados.md §7.
[D] docs/arquitectura/omega-a-pim-headless/contratos-api.md: convenciones y endpoints.
[D] trazabilidad/features/: las 74 fichas de épica.