FT-IA-06 · Asistente conversacional para que el seller reporte errores

En 30 segundos

Un seller que oferta sobre un producto que ya existe no puede modificarlo, y hoy para reportar un error depende de su KAM. Esta épica le da un asistente: escribe en lenguaje natural qué ve mal (le falta una foto, un dato) o por qué su producto no avanza; el asistente lo entiende con el estatus y los motivos del PIM, le explica lo que pueda y le arma un reporte que el seller confirma y que llega como tarea a Gobierno de Datos.

• Módulo dueño: MS-15 IA y enriquecimiento. También participan: MS-02 Producto, MS-06 Evaluación, MS-14 Avisos y ayuda.
• Etapa T · Transversal. Recibe de otras épicas y entrega a otras épicas.
• APIs: construye 2 y usa 3 que construyen otras épicas.
• Eventos: publica 1 y consume 1.

1. Dónde encaja

Recibe

Entrega

Tareas que abre o cierra: Gobierno de Datos.

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 ¿Por qué no avanza mi producto?

3.2 Error en un paso del alta

4. Si algo sale mal

• El modelo del asistente no responde. La pantalla ofrece el formulario corto de reporte (producto, paso, qué falta) y el reporte llega igual a Gobierno de Datos.
• El asistente no tiene el dato para explicar. Lo dice y ofrece mandar el reporte; nunca inventa un motivo: sólo usa el estatus, los motivos y la calificación del PIM.
• El seller manda muchos mensajes seguidos. MS-15 responde 429 y pide esperar; los reportes ya confirmados no se pierden.
• Gobierno de Datos no atiende el reporte a tiempo. El reloj de plazos del motor escala la tarea de su cola; el seller ve el reporte «en atención» con su fecha.

5. APIs

Las que construye esta épica (2)

{
  "conversationId": null,
  "context": {
    "productId": "PRD-0001190",
    "sku": "1000001190",
    "step": "DETALLE_OFERTA"
  },
  "message": "Estoy colgando este producto y le falta la foto del empaque"
}

{
  "success": true,
  "data": {
    "conversationId": "cnv-0000412",
    "reply": "Entendido: al producto 1000001190 le falta la foto del empaque. ¿Mando el reporte para que lo corrijan?",
    "reportDraft": {
      "draftId": "rpt-0000077",
      "productId": "PRD-0001190",
      "step": "DETALLE_OFERTA",
      "errorType": "FALTA_IMAGEN",
      "detail": "Falta la foto del empaque",
      "suggestedQueue": "REPORTES_SELLERS"
    },
    "statusExplanation": null
  }
}

{
  "reportDraftId": "rpt-0000077",
  "source": "ASSISTANT",
  "step": "DETALLE_OFERTA",
  "errorType": "FALTA_IMAGEN",
  "detail": "Falta la foto del empaque",
  "sku": "1000001190"
}

{
  "success": true,
  "data": {
    "reportId": "rep-0000301",
    "productId": "PRD-0001190",
    "taskId": "tsk-60412",
    "taskType": "GOBIERNO_DE_DATOS",
    "queue": "REPORTES_SELLERS",
    "status": "OPEN",
    "visibleToSeller": "En atención"
  }
}

Las que usa y construye otra épica (3)

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-IA-06-1. El PIM no construye un chat por pantalla: expone el asistente como una API (API-15-009) con el contexto del producto y del paso. Si existe una iniciativa transversal de asistentes, su asistente usa esta misma API y el PIM sólo pone los datos y recibe los reportes. Por qué: No construir dos asistentes y que cualquier canal reporte igual. Se apoya en PEN-48, ADR-12.
• D-IA-06-2. El reporte lo confirma el seller y lo registra MS-02 como tarea de Gobierno de Datos en la cola «Reportes de sellers», ligada al producto y al paso; Gobierno de Datos lo resuelve o lo manda al dueño del dato (FT-PRD-05). El asistente no escribe en el producto ni abre tareas por su cuenta. Por qué: Con coincidencia el seller no modifica el SKU existente: el reporte es su vía para pedir la corrección, y la IA propone mientras la persona confirma. Se apoya en RF-ENR-15, RN-MAT-18.
• D-IA-06-3. Lo que el asistente explica sale del estatus que ve el seller y de los motivos de MS-02, y de la calificación de MS-06; si no hay dato, lo dice. Un producto que no alcanza la calificación se explica como «por completar», no como rechazo. Por qué: El asistente no puede contradecir lo que muestra el portal ni inventar motivos. Se apoya en RN-CAL-06, FT-RAC-05.
• D-IA-06-4. La conversación se guarda en ai_jobs con el seller y el producto, para saber qué se le dijo; el asistente rechaza y no guarda datos de clientes ni de pago si aparecen en el mensaje. Por qué: Trazabilidad de lo que respondió la IA sin guardar datos que el PIM no debe tener. Se apoya en ADR-12.

Qué falta decidir

También siguen abiertos: PEN-48, Si el asistente es una iniciativa transversal para todas las áreas o lo construye el PIM.

Fuentes

1. [D] trazabilidad/features/FT-IA-06-asistente-conversacional-reporte-errores.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.