Saltar a contenido

Matriz de trasplante PulseCommerce → Commerce

Fecha: 2026-08-31
Regla: PulseCommerce se consulta sólo como referencia; no se modifica ni se copian secretos/configuración de su entorno.

Backend

Capacidad existente Decisión Tratamiento en Commerce
Usuarios, organizaciones y membresías Adaptar Mantener vocabulario TimeLiber y RLS propio de Commerce.
MFA y políticas de contraseña Reutilizar patrón Trasplantar con namespaces propios y pruebas; no compartir tablas.
connections y estados Adaptar Usar integration_connections + shopify_installations; conservar soft delete.
OAuth state/CSRF Reutilizar patrón El estado debe vivir en Connect/Commerce con TTL, audience y tenant intent.
Cifrado Fernet de credenciales Reutilizar patrón Nueva clave Commerce; nunca reutilizar ENCRYPTION_KEY de PulseCommerce.
Refresh offline expirable Reutilizar/adaptar Mantener rotación atómica y marcar reautorización cuando expire.
GraphQL Shopify Reutilizar patrón Sólo queries read-only iniciales; eliminar mutations demo.
Webhooks e inbox Adaptar Commerce persiste receipt/RLS; Connect sólo verifica/autentica la entrega.
Workers/sync jobs Adaptar Ejecutar en infraestructura Commerce; idempotencia por organización+shop+cursor.
Billing y planes Posponer No requerido para validar conexión inicial.

Frontend

Superficie PulseCommerce Decisión Tratamiento
Auth/login/MFA Adaptar Commerce tiene sesión propia; Connect no duplica login.
Selector de organización Reutilizar patrón La acción “Conectar Shopify” debe nacer en la organización activa.
ConnectShopifyForm Adaptar No pedir dominio manualmente para Public App; redirigir a Shopify.
Pantalla de conexiones Reutilizar patrón Consumir /organizations/{id}/integrations de Commerce.
Pedidos Shopify Posponer Primero instalar, consultar y reconciliar sin PII.
Páginas legales Adaptar Usar contenido jurídico propio, dominio y responsable de Commerce.
E2E de OAuth Reutilizar estructura Cambiar URLs, app/client ID, tienda y tenant de pruebas.

Lo que no se debe trasladar

  • .env, client secrets, tokens, URLs privadas o credenciales de PulseCommerce.
  • SQLite/Prisma como almacenamiento de producción para Commerce.
  • Modelos SQLAlchemy de PulseCommerce importados directamente.
  • write_* scopes o mutations de demostración del template.
  • Suposición de que un dominio Shopify escrito por el usuario es suficiente para autorizar una instalación pública.
  • Tenants compartidos entre verticales.

Decisión operativa

El backend Commerce ya contiene una primera fundación propia de identidad, tenancy, intents, RLS y contratos. Antes de ampliar esa fundación, cada módulo debe compararse con el equivalente de PulseCommerce y justificarse como:

  1. reutilización de patrón;
  2. adaptación aislada;
  3. funcionalidad nueva necesaria;
  4. descartada por duplicación.

El siguiente incremento de código debe ser el linking OAuth DEV y no otra ronda de autenticación, tenants o CRUD paralelo.