FT-IA-02 · Sugerencia de plantilla por IA a partir del producto…

En 30 segundos

El seller no conoce el árbol de plantillas y elige mal, lo que causa rechazos y cobros por grupos de artículo equivocados. Esta épica toma lo que se sacó de la imagen o de la URL, busca en el catálogo el producto más parecido y propone su plantilla general de familia con la pregunta «¿es tu plantilla?». Si dice que no, elige otra en el árbol; si ninguna sirve, elige su familia y se le asigna la plantilla general o «otros», sin levantar un ticket.

• Módulo dueño: MS-15 IA y enriquecimiento. También participan: MS-01 Catálogo, MS-02 Producto.
• Etapa 2 · Plantilla. Recibe «PE-2 · Sin duplicado» y entrega «PE-3 · Plantilla asignada».
• APIs: construye 1 y usa 5 que construyen otras épicas.
• Eventos: publica 1 y consume 2.

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 No es mi plantilla

3.2 Ninguna plantilla sirve

3.3 Medir las sugerencias

4. Si algo sale mal

• La IA no responde. La pantalla muestra el selector de plantillas completo, con la plantilla general de cada familia primero; el seller no se queda detenido.
• La sugerencia es equivocada. El seller responde «no es mi plantilla» y elige otra; cuenta como sugerencia rechazada en las métricas de esa familia.
• El seller cambia de plantilla con valores ya prellenados. Se conservan, como sugerencias por confirmar, sólo los valores cuyos atributos existen en la plantilla nueva; los demás se descartan y quedan en el trabajo de IA.
• La familia no tiene plantilla general. Se asigna «otros» de la familia y el caso queda en las métricas para que Gobierno de Producto decida si crea una plantilla (FT-IA-04).

5. APIs

Las que construye esta épica (1)

{
  "business": "MKP",
  "evaluationId": "evl-0000733",
  "productId": null,
  "inputs": {
    "sourceJobId": "job-0003311",
    "imageAssetIds": [
      "ast-0004410"
    ],
    "title": "Bujía de iridio para motor de 4 tiempos",
    "homologueHints": [
      "PRD-0002277"
    ],
    "family": null
  },
  "max": 3
}

{
  "success": true,
  "data": {
    "suggestionId": "sug-7f3a",
    "question": "¿Es tu plantilla?",
    "items": [
      {
        "templateId": "EU4-0412",
        "path": "Automotriz > Refacciones > Refacciones generales",
        "family": "REFACCIONES",
        "general": true,
        "confidence": 0.88,
        "homologue": {
          "productId": "PRD-0002277",
          "productName": "Bujía de platino para motocicleta"
        }
      },
      {
        "templateId": "EU4-0398",
        "path": "Automotriz > Motocicletas > Accesorios",
        "family": "MOTOCICLETAS",
        "general": true,
        "confidence": 0.41,
        "homologue": null
      }
    ],
    "fallback": null
  }
}

Las que usa y construye otra épica (5)

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-02-1. La sugerencia sale del producto homólogo más parecido del catálogo (búsqueda por imagen y texto en el embedding lake) y siempre propone la plantilla general de su familia, no una por producto; hasta tres opciones con su confianza. Por qué: Las plantillas por producto generan rechazos; cada familia tiene una plantilla general y así siempre hay un papá. Se apoya en RN-PLA-10, RN-PLA-12, RF-ENR-05, FT-PLT-05.
• D-IA-02-2. Reusa lo extraído en la identificación (el trabajo de IA de FT-REF-04) y los candidatos cercanos de la evaluación; no vuelve a leer la página ni a pagar el modelo. Por qué: Un solo pago por propuesta y la misma lectura del producto en toda el alta. Se apoya en RF-ENR-05, DEC-40.
• D-IA-02-3. Sólo hay sugerencia cuando el alta entró por imagen o URL; por características el seller elige en el selector de plantillas, y sin insumo no se inventa una. Por qué: Es la ruta acordada por camino; sin imagen ni texto la IA adivinaría. Se apoya en RN-ENR-06, PEN-16.
• D-IA-02-4. Si el seller cambia de plantilla, se conservan como sugerencias por confirmar sólo los valores cuyos atributos existen en la plantilla nueva; los demás se descartan y quedan en el trabajo de IA por si vuelve atrás. Por qué: No se pierde lo útil, no se arrastran datos que la nueva plantilla no pide y todo sigue pasando por la confirmación del usuario. Se apoya en RN-ENR-05.
• D-IA-02-5. Sin plantilla que sirva, el seller elige su familia y se le asigna la general o «otros» de esa familia, sin ticket; el caso se cuenta para que Gobierno de Producto decida si pide a la IA una plantilla nueva (FT-IA-04). Por qué: Hoy la plantilla que no existe se resuelve con un ticket que detiene al seller. Se apoya en RF-CAT-09, PEN-15.
• D-IA-02-6. La aceptación se mide con la asignación que guarda MS-02 con el suggestionId (CLASSIFICATION_CHANGED), no con lo que reporte la pantalla. Por qué: Una sola fuente de verdad para las métricas por familia. Se apoya en RF-ENR-06, RF-ENR-09.

Qué falta decidir

También siguen abiertos: PEN-15, Confirmar con Marketplace las ramas cuando no hay plantilla (preguntas por familia o «otros»); PEN-16, Qué hacer en un alta manual desde cero sin imagen ni URL (aquí: el seller elige en el selector).

Fuentes

1. [D] trazabilidad/features/FT-IA-02-sugerencia-plantilla-por-homologo.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.