FT-RAC-02 · Score de calidad del producto

En 30 segundos

En Marketplace no hay un comprador que dé el visto bueno: lo da una calificación. Esta épica calcula si el producto tiene sus obligatorios (sí o no), qué tan completo está en recomendados y opcionales y qué tan coherentes son su imagen, título y atributos. Antes del SKU sólo frena lo que el SKU necesita; lo que no alcanza regresa al seller como «Por completar», sin rechazo. El seller ve su calificación mientras captura y qué le falta para subirla.

• Módulo dueño: MS-06 Evaluación. También participan: MS-01 Catálogo, MS-02 Producto, MS-14 Avisos y ayuda, MS-15 IA y enriquecimiento.
• Etapa 4 · Visto bueno. Recibe «PE-4 · Propuesta enviada» y entrega «PE-5 · Visto bueno dado».
• APIs: construye 1 y usa 13 que construyen otras épicas.
• Eventos: publica 3 y consume 2.

1. Dónde encaja

Recibe

Entrega

Cambios de estado que hace

Tareas que abre o cierra: Calificación de IA, Corrección, QA manual.

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 no alcanza: regresa sin rechazo

3.2 Incoherencias y calificación mientras captura

3.3 Variante nueva: color contra su foto

4. Si algo sale mal

• La propuesta no tiene lo que el SKU necesita (o no alcanza el mínimo que el negocio configuró). Regresa a Borrador con una Corrección de origen calificación; el seller ve «Por completar» con lo que falta y cuánto sube cada dato, y recibe un aviso. No es un rechazo.
• MS-15 no responde la coherencia. La calificación se guarda con «confianza pendiente» y no frena el visto bueno, porque la confianza decide la publicación y no el SKU; QA con IA la revisa después.
• Falta el grupo de artículos o la sección. No pasa: MS-06 responde REVIEW y MS-02 abre Gobierno de Datos (FT-IA-04); al resolverse, MS-02 vuelve a pedir la calificación.
• La plantilla cambió entre el envío y la calificación. MS-06 califica con la vista efectiva de la versión enviada y guarda con qué versión lo hizo; con TEMPLATE_VIEW_CHANGED renueva su caché para la siguiente.

5. APIs

Las que construye esta épica (1)

{
  "mode": "PREVIEW",
  "productId": "PRD-0004812",
  "version": 7,
  "draftValues": {
    "MATERIAL": "PLASTICO_ABS",
    "CABLE_INCLUIDO": "SI"
  }
}

{
  "success": true,
  "data": {
    "productId": "PRD-0004812",
    "version": 7,
    "business": "MKP",
    "mode": "PREVIEW",
    "mandatory": {
      "status": "PASS",
      "missing": []
    },
    "completeness": {
      "value": 72,
      "recommended": {
        "filled": 4,
        "total": 6,
        "weight": 2
      },
      "optional": {
        "filled": 3,
        "total": 10,
        "weight": 1
      }
    },
    "confidence": {
      "value": 0.91,
      "computedForVersion": 6,
      "incoherences": []
    },
    "total": 66,
    "vistoBueno": {
      "passes": true,
      "minimum": 0,
      "gates": {
        "mandatory": "PASS",
        "template": "PASS",
        "itemGroup": "PASS",
        "identification": "PASS"
      }
    },
    "publicationBand": "REVISION_PRIORITARIA",
    "improvements": [
      {
        "attribute": "PUERTOS_SALIDA",
        "label": "Puertos de salida",
        "level": "RECOMMENDED",
        "gain": 6
      },
      {
        "attribute": "PESO_NETO",
        "label": "Peso neto",
        "level": "OPTIONAL",
        "gain": 3
      }
    ],
    "thresholdsVersion": 4
  }
}

Las que usa y construye otra épica (13)

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-RAC-02-1. El visto bueno de Marketplace (Calificación de IA, T05) es una calificación de sí o no sobre lo que el SKU necesita: obligatorios completos, plantilla, grupo de artículos y sección asignados, e identificación limpia (sin lista negra ni coincidencia abierta). El score de calidad se calcula en el mismo momento y viaja al producto, pero sólo frena el SKU si el negocio configura un mínimo de visto bueno (arranca en 0); su uso principal es decidir la publicación por rangos (FT-RAC-03). Por qué: Concilia «dos carreteras» con «lo que no alcanza no avanza»: antes del SKU sólo se exige lo que el SKU necesita y la calidad del contenido frena la publicación de cada canal, como proponen FT-FLU-01, FT-FLU-02 y FT-RAC-03. Se apoya en PD-24, RN-CAL-06, RN-GEN-03, DEC-48.
• D-RAC-02-2. La fórmula: obligatorios como sí o no (si faltan, la calificación es 0); completitud de recomendados y opcionales llenos, ponderada por nivel (arranque 2 y 1, y llenar siempre sube); confianza, la coherencia de imagen, título y atributos que da MS-15; total igual a completitud por confianza. Pesos, mínimo y rangos son por negocio en validation_thresholds, con plan y vista previa del impacto. Por qué: Dos componentes y tres clases de atributo, como se acordó, con valores configurables porque los del taller son sólo ejemplos. Se apoya en DEC-45, RN-CAL-08, RN-CAL-09, RN-CAL-10.
• D-RAC-02-3. Lo que no alcanza regresa a Borrador (T04) con una Corrección de origen calificación, que el seller ve como «Por completar» con lo que le falta y cuánto sube cada dato; no es un rechazo. Por qué: «Si no cumplen, no avanzan», sin castigar al seller con un rechazo. Se apoya en RN-CAL-06, DEC-46.
• D-RAC-02-4. La calificación que decide la calcula MS-06 con lo guardado (OFFICIAL); la de la pantalla es vista previa con los valores que se están capturando y la última confianza calculada, que se renueva cuando se guarda un cambio que la afecta. Por qué: El seller ve su avance al momento sin que se corra la IA en cada tecla, y la pantalla nunca decide. Se apoya en RF-CAL-10, RN-CAL-10.
• D-RAC-02-5. En Mercaderías y Suburbia la calificación se calcula igual pero es informativa: Compras la ve en su visto bueno y el proveedor en su propuesta; no frena nada. Por qué: Ahí el visto bueno es de Compras; la calificación ayuda a decidir sin cambiar quién decide. Se apoya en RF-CAL-06, DUD-32.
• D-RAC-02-6. El color de una variante nueva contra su foto lo revisa MS-15 con el umbral de su tarea (configuración de MS-15); debajo, MS-02 abre QA manual y la variante no avanza hasta que QA la apruebe. Al cambiar el umbral, la siguiente variante ya usa el nuevo. Por qué: La IA propone y una persona decide lo dudoso, sin revisar a mano todas las variantes. Se apoya en RF-CAL-07, PD-27.

Qué falta decidir

También siguen abiertos: PEN-36, Valores de pesos, mínimo y rangos (aquí 2 y 1, mínimo 0 y rangos 85 y 95); PEN-37, Cerrar que los obligatorios cuentan como sí o no y no como porcentaje; PEN-38, Qué pasa con un producto completo pero incoherente (aquí: no frena el SKU, sí la publicación).

Fuentes

1. [D] trazabilidad/features/FT-RAC-02-score-calidad-completitud-confianza.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.