FT-REF-02 · Blacklist de Marketplace por marca, negocio y grupo de…

En 30 segundos

Marketplace no quiere que un seller dé de alta marcas que Liverpool vende directamente. Esta épica revisa la marca de cada propuesta de seller contra una lista negra en cuanto se conoce, en el alta individual, por API y en cada renglón de la carga masiva, y si está vetada termina el alta con una explicación. Gobierno de Producto mantiene la lista (marcas, marcas por negocio, grupos de artículos y sellers autorizados por marca) sin levantar un ticket.

• Módulo dueño: MS-06 Evaluación. También participan: MS-01 Catálogo, MS-02 Producto, MS-03 Migración y convivencia.
• Etapa 1 · ¿Ya existe?. Recibe «PE-1 · Propuesta en Borrador», «PE-C · Catálogo vigente» y entrega «PE-2 · Sin duplicado».
• APIs: construye 1 y usa 10 que construyen otras épicas.
• Eventos: publica 3 y consume 1.

1. Dónde encaja

Recibe

Entrega

Cambios de estado que hace

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 Si la marca está vetada

3.2 Gobierno de Producto mantiene las listas

3.3 Variante de un seller no autorizado

4. Si algo sale mal

• La marca está vetada. La pantalla lo dice antes de guardar: «no se puede catalogar: son productos que comercializa Liverpool (1P o Mercaderías)». Si la propuesta llega a guardarse (por API, o porque la marca salió de la URL o cambió después), MS-02 la descarta en la misma operación o la cancela con el motivo, y sus EAN quedan libres. El intento queda en la evaluación.
• MS-06 no puede leer la lista negra y no tiene copia vigente en caché. No deja pasar nada: responde 503; la propuesta no se da por identificada y MS-02 reintenta. El seller ve que se está revisando su marca.
• Se veta una marca que ya tiene propuestas en curso. La caché de MS-06 se renueva con RULE_CHANGED y la siguiente evaluación ya la aplica. Las propuestas que pasaron antes se vuelven a evaluar al enviarse (Validación automática) y ahí se cancelan con explicación; lo ya publicado no se toca.
• El seller cambia la marca después de pasar la revisión. MS-02 vuelve a pedir la evaluación; si la marca nueva está vetada, la propuesta se cancela con el motivo. No hay forma de saltarse la revisión cambiando datos.

5. APIs

Las que construye esta épica (1)

{
  "subject": {
    "productId": "PRD-0004812",
    "version": 1,
    "business": "MKP",
    "origin": "PORTAL",
    "owner": {
      "type": "SELLER",
      "id": "SELLER-0001"
    }
  },
  "purpose": "NEW_PROPOSAL",
  "mode": "INDIVIDUAL",
  "identity": {
    "brandCode": "MARCA01",
    "model": "PF-100",
    "ean": "7501234567893",
    "productType": "PERFUME",
    "itemGroup": null,
    "attributes": {
      "CONTENIDO_ML": 100,
      "GENERO": "MUJER"
    }
  },
  "imageAssetId": null,
  "pdpUrl": null
}

{
  "success": true,
  "data": {
    "evaluationId": "evl-0000731",
    "kind": "IDENTIFICATION",
    "status": "DONE",
    "evaluatedAt": "2026-10-18T16:02:11Z",
    "validUntil": "2026-10-19T16:02:11Z",
    "blacklist": {
      "blocked": false,
      "rulesChecked": [
        "MKP_BANNED_BRAND",
        "MKP_BANNED_ITEM_GROUP",
        "MKP_BRAND_ALLOWED_SELLERS"
      ],
      "rulesVersion": 12
    },
    "matches": [
      {
        "productId": "PRD-0001190",
        "business": "MER",
        "sku": "1000001190",
        "productName": "Perfume floral para mujer 100 ml",
        "matchType": "EAN",
        "confidence": 1.0,
        "fieldsMatched": [
          "EAN",
          "MARCA"
        ]
      }
    ],
    "decision": {
      "action": "STOCK_OUT",
      "reasonCode": "EXISTS_IN_MER",
      "targetSku": "1000001190",
      "targetBusiness": "MER",
      "message": "Este producto ya lo vende Liverpool. Puedes ofertar sobre su SKU sin cambiar su contenido."
    },
    "nearCandidates": [],
    "thresholdsVersion": 4
  }
}

Las que usa y construye otra épica (10)

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-REF-02-1. La lista negra vive en governance_rules de Catálogo (MS-01), que la administra; MS-06 sólo la evalúa. A los nueve tipos de regla se suman dos: MKP_BANNED_BRAND (marca, con negocio protegido opcional) y MKP_BRAND_ALLOWED_SELLERS (sellers autorizados por marca); los grupos siguen en MKP_BANNED_ITEM_GROUP. MS-06 la guarda en caché y la renueva con RULE_CHANGED. Por qué: Un dato, un dueño: Catálogo ya es dueño de las reglas de captura y clasificación. El modelo del 2-oct sólo tenía grupos vetados y los talleres piden la marca como llave principal. Se apoya en DEC-PLT-14, RF-MAT-02, DUD-32, ADR-12.
• D-REF-02-2. Cómo bloquea: una marca vetada sin negocio o un grupo vetado bloquean siempre, en cuanto se conoce la marca y aunque no haya coincidencia; una marca vetada para un negocio (Liverpool o Suburbia) bloquea sólo cuando el producto coincide con uno de ese negocio, y eso lo aplica FT-FLU-03. Lo que migra del LOV 4714 entra como veto general, que es como funciona hoy. Por qué: Concilia las dos lecturas del taller (general por marca y marca más negocio) sin perder la paridad, y abre la lista de Suburbia que hoy no existe. Se apoya en PEN-18, RN-MAT-04, RN-MAT-06, DEC-32.
• D-REF-02-3. La lista negra sólo aplica a propuestas de sellers de Marketplace; a las de Mercaderías y Suburbia no. Por qué: Son las marcas que Liverpool vende directamente: aplicada a sus propios proveedores bloquearía su surtido. Se apoya en RF-MAT-01, RN-MAT-05.
• D-REF-02-4. Hay dos momentos y una sola regla. La pantalla revisa marca y EAN antes de guardar (API-06-005) para avisar de inmediato; la que decide es la evaluación que pide MS-02 (API-06-001) al guardar la propuesta, cuando cambian la marca, el EAN, el grupo de artículos, el negocio o el seller, al ligar una variante y otra vez en la Validación automática al enviar. Si dice BLOCK, MS-02 descarta la propuesta en la misma operación (o la cancela si ya existía) y libera sus EAN. Las reglas y la respuesta son las mismas para la pantalla, la carga masiva y la API. Por qué: El aviso temprano evita capturar en vano y la evaluación en el servidor evita que alguien le dé la vuelta cambiando la marca después o saltándose la pantalla. Se apoya en RN-MAT-07, DEC-29, DEC-56, RF-MAT-20.
• D-REF-02-5. Si MS-06 no puede leer la lista negra y no tiene copia vigente, no deja pasar: responde 503 y MS-02 reintenta. Cada intento queda en la evaluación (validation_results) aunque no se cree nada, con la regla que aplicó. Por qué: Dejar pasar por una falla técnica publicaría marcas prohibidas; guardar los intentos permite medir la evasión, que hoy no se ve. Se apoya en RF-MAT-01, RSG-12.

Qué falta decidir

También siguen abiertos: PEN-18, Ratificar con Marketplace y Gobierno de Producto el modelo de llave (aquí conviven veto general y veto por negocio) y si los grupos vetados se conservan; PEN-20, Confirmar con Marketplace qué pasa en la rama Liverpool con marca vetada y el caso «con permiso».

Fuentes

1. [D] trazabilidad/features/FT-REF-02-blacklist-de-marketplace.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.