FT-MIG-04 · Convivencia P360 ↔ nuevo PIM

En 30 segundos

Mientras P360 siga vivo es la fuente, y el Nuevo PIM tiene que seguirlo sin desfase aunque las pantallas ya trabajen sobre el PIM desde R1 y R2. Esta épica mantiene la copia al día, escribe en P360 por MS-03 lo que se cambia en las pantallas nuevas, detecta lo que se desvía y lleva el corte de R3: P360 queda sin tráfico y el PIM pasa a ser la fuente, con vuelta atrás probada.

• Módulo dueño: MS-03 Migración y convivencia. También participan: MS-02 Producto, MS-05 Auditoría.
• Etapa M · Migración. Recibe de otras épicas y entrega «PE-M · Producto migrado».
• APIs: construye 4 y usa 7 que construyen otras épicas.
• Eventos: publica 2 y consume 0.

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 Deriva: lo que la sincronización no vio

3.2 Corte de R3 con go/no-go y vuelta atrás

3.3 P360 quita un EAN (adaptador hasta R3)

4. Si algo sale mal

• P360 rechaza una escritura que el PIM ya validó. MS-03 deja el recibo como rechazado con el motivo de P360; Producto no cambia su copia y quien hizo el cambio ve el rechazo en su recibo. Si P360 dijo que no, nada se reintenta solo.
• La familia cambió en P360 mientras alguien la editaba en la pantalla nueva. La escritura responde 409 VERSION_CONFLICT con la versión de P360; el portal recarga la familia y la persona decide sobre lo vigente. Las pantallas de P360 de lo que ya se mudó quedan en sólo lectura.
• La sincronización se atrasa más de 60 minutos. Se enciende la alarma del tablero de convivencia; los recibos de P360 son durables, así que MS-03 retoma desde su cursor sin perder ni duplicar.
• Falla una compuerta del go. No hay go: P360 nunca dejó de ser la fuente, se liberan hacia P360 las escrituras retenidas y todo sigue como en R2. Volver toma menos de una hora.
• Hay que volver a P360 después del go. Hasta el día 14, MS-03 sigue escribiendo en P360 cada cambio del PIM con los procesos de salida de P360 apagados; volver es regresar Producto al modo de convivencia sin recapturar nada. Después del día 14 sólo se corrige hacia adelante.

5. APIs

Las que construye esta épica (4)

{
  "writeId": "wr-55e0c2-1",
  "origin": {
    "module": "MS-02",
    "requestId": "req-55e0c2",
    "actor": {
      "area": "GOBIERNO_DE_DATOS",
      "role": "Gobierno"
    }
  },
  "entity": {
    "type": "PRODUCT",
    "productId": "PRD-0004812",
    "legacyIdentifier": "1033301",
    "expectedVersion": 7
  },
  "operation": "UPDATE_VALUES",
  "changes": [
    {
      "path": "variants[VAR-0004812-01].attributes.COLOR",
      "before": "ROJO",
      "after": "AZUL"
    },
    {
      "path": "attributes.ALTO_EMPAQUE",
      "before": null,
      "after": "32 cm"
    }
  ]
}

{
  "success": true,
  "data": {
    "requestId": "req-p3w-7781",
    "status": "ACCEPTED",
    "receiptUrl": "/internal/migration/p360-writes/req-p3w-7781"
  }
}

null

{
  "success": true,
  "data": {
    "requestId": "req-p3w-7781",
    "writeId": "wr-55e0c2-1",
    "status": "APPLIED",
    "p360": {
      "operation": "UPDATE_VALUES",
      "answeredAt": "2026-10-18T15:04:09Z",
      "result": "OK"
    },
    "reloadedVersion": 8,
    "finishedAt": "2026-10-18T15:04:11Z"
  }
}

null

{
  "success": true,
  "data": {
    "phase": "R2",
    "source": {
      "catalog": "P360",
      "products": "P360"
    },
    "sync": {
      "receipts": {
        "lagSeconds": 340,
        "p95LagSeconds": 610,
        "lastPosition": "rcpt-88412311",
        "alarm": false
      },
      "groupSweep": {
        "lastRunAt": "2026-10-18T15:00:00Z",
        "diffs": 0
      },
      "presence": {
        "lastRunAt": "2026-10-18T06:00:00Z",
        "missing": 3,
        "extra": 0
      },
      "hash": {
        "lastFullRunAt": "2026-10-12T04:00:00Z",
        "diffs": 0,
        "weeksWithoutDrift": 2
      }
    },
    "writesToP360": {
      "pending": 4,
      "failedLast24h": 1,
      "p95Seconds": 6
    },
    "connections": [
      {
        "id": "S4",
        "name": "Productos a la tienda por el broker",
        "replacement": "MS-08 al Product Data Service",
        "trafficLast7d": 0
      },
      {
        "id": "E15",
        "name": "122 de ECC",
        "replacement": "MS-07",
        "trafficLast7d": 3104
      },
      {
        "id": "UPC-EANS",
        "name": "P360 quita un EAN (API-02-074)",
        "replacement": "Se borra con P360 en R3",
        "trafficLast7d": 57
      },
      {
        "id": "EU-SYNC",
        "name": "Conciliación de P360 contra la base de Entrada Única",
        "replacement": "Se apaga; la cubre la conciliación de MS-03",
        "trafficLast7d": 0
      }
    ],
    "readyToCut": false,
    "blockers": [
      "E15 todavía lo lee P360"
    ]
  }
}

{
  "requestedBy": "catalog-product",
  "size": 1000,
  "reason": "Se gastó el 80 % del bloque 1033000"
}

{
  "success": true,
  "data": {
    "blockId": "blk-1034000",
    "from": "1034000",
    "to": "1034999",
    "reservedAt": "2027-05-03T10:15:00Z"
  }
}

Las que usa y construye otra épica (7)

Su request y su response están en la página de la épica que la construye.

6. Eventos

Publica

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-MIG-04-1. Un solo maestro por dato: hasta el corte de R3, P360 es la fuente de producto y de catálogo, y el PIM es una copia que MS-03 mantiene por cuatro vías (recibos durables con relectura de la familia, barrido de grupos cada 600 s, presencia diaria por rangos y huella semanal). Sólo MS-03 escribe en la copia, por la carga interna. Por qué: Sólo con eventos a Omega le faltaron 6,828 productos; un consumidor nuevo de la cola de P360 le quitaría mensajes a los que ya existen. Se apoya en PD-11, DMS-85, DMS-76.
• D-MIG-04-2. Las pantallas cambian una sola vez al BFF por oleadas (R1 catálogo, categorías, activos y avisos; R2 propuestas, variantes, carga masiva, reportes, el módulo M6 y el portal del estudio), sin capa de compatibilidad. Mientras P360 sea la fuente, Producto valida con sus reglas y escribe en P360 por MS-03 (API-03-009): MS-03 aplica con los servicios de P360, en orden por familia, relee y recarga la copia en segundos, y el recibo del usuario se cierra con el de MS-03. Por qué: Es la decisión 20 que adopta ADR-12: nadie más que MS-03 escribe en P360 y la copia nunca se adelanta a la fuente, así que no hay dos maestros. Se apoya en ADR-12, PD-12, RSG-48.
• D-MIG-04-3. PD-12 queda así: el catálogo no se congela ni corta antes. Si su administración pasa al PIM en R1, se escribe en P360 por MS-03 igual que el producto, y lo que los servicios de P360 no acepten se sigue editando en P360 hasta R3. Catálogo y producto pasan juntos a ser fuente en el corte de R3. Por qué: Congelar de R1 a R3 dejaría a Gobierno de Datos meses sin ajustar plantillas, y cortar el catálogo antes obligaría a P360 a validar productos con un catálogo que ya no es suyo. Se apoya en PD-12, DEC-PLT-13.
• D-MIG-04-4. Los cambios de la convivencia avisan con los eventos normales del dueño y origen P360_SYNC, para la bitácora y las cachés; los adaptadores los ignoran hasta el go porque P360 sigue entregando a los destinos. La carga completa sigue sin eventos (D-ARQ-01-7). Por qué: Sin aviso, las cachés de vistas y la bitácora no verían los cambios de meses de convivencia; sin el filtro por origen, se publicaría dos veces. Se apoya en DMS-81, DEC-65, FT-ARQ-01.
• D-MIG-04-6. Corte de R3 con guion y go/no-go: retener escrituras hacia P360, último tramo, conciliación final, valor de la secuencia y primer bloque de Identifier, siembra del estado de entrega y firma del comité. A los criterios G1–G7 del plan se suma G8: cada conexión de P360 con reemplazo y tráfico cero (API-03-007). En el go se encienden MS-07, MS-08 y MS-10 por interfaz y el emisor de avisos del PIM en la misma ventana en que se apaga el de P360; no se republica el catálogo. A más tardar en R3 se apagan, cuando su tráfico llega a cero, el backend de Entrada Única, el servicio de catálogo de Foro, el el servicio de usuarios de Foro y P360. Por qué: Nada se apaga mientras tenga una conexión sin reemplazo o tráfico; encender cada salida en la ventana evita dos productores. Se apoya en DMS-87, DMS-88, RN-MIG-07, FT-INT-06.
• D-MIG-04-7. Vuelta atrás: antes del go no hay nada que deshacer, porque P360 nunca dejó de ser la fuente. Del go al día 14, MS-03 sigue escribiendo en P360 cada cambio del PIM con los procesos de salida de P360 apagados, y volver es regresar Producto al modo de convivencia; los fronts no cambian de dirección porque siempre llaman al BFF. Al día 14 se apaga la escritura y P360. Por qué: Sin capa de compatibilidad ya no se vuelve cambiando la URL de los fronts; mantener P360 al día 14 días evita recapturar a mano. Se apoya en DMS-89, PD-12.
• D-MIG-04-8. Desde el go y mientras P360 siga encendido, Producto toma bloques de 1,000 Identifier de la secuencia de la base de P360 por MS-03 (API-03-008) con dos de reserva; al apagar P360 sigue con su contador propio. Antes del go el PIM no crea productos: los crea P360 por la escritura de MS-03. Por qué: Una vuelta atrás no debe repetir números que ya dio el PIM. Se apoya en DMS-78, DMS-83.
• D-MIG-04-9. La convivencia sigue el orden de las oleadas: catálogo y usuarios antes de R1, productos antes de R2. La corrida de usuarios (tipo USERS de API-03-001) concilia por la cuenta del proveedor de identidad a los usuarios de P360, Entrada Única y Foro antes de que el directorio sea la fuente en R2; las contraseñas no se migran. Por qué: Cada pantalla que cambia al BFF necesita su copia completa y a sus usuarios desde su primer día. Se apoya en ADR-12, FT-USR-01.

Qué falta decidir

Fuentes

1. [D] trazabilidad/features/FT-MIG-04-convivencia-sincronizacion-y-corte.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.