Auditoría técnica estratégica · Confidencial

PromoInk AI — estado actual y stack objetivo

Diagnóstico del desarrollo heredado, causas de sus límites, y el camino técnico más eficiente para construir lo que el cliente requiere — priorizando eficiencia sobre reutilización.

PROYECTO  PromoInk AI · Fase 1 MVP BASE  WordPress 7.0.2 + WooCommerce PREPARADO POR  Sergio Duran · Technical Lead FECHA  2026-07-28
Veredicto

Lo construido es un MVP de vitrina, no una plataforma: WooCommerce funciona como tienda, pero la lógica que diferencia a PromoInk (diseñador, precios, decoración, asesor IA) vive apretada en plugins, jQuery y blobs de postmeta, sin modelo de datos ni capa de aplicación. Es un techo arquitectónico, no un problema de código puntual. La recomendación es híbrida: conservar WooCommerce como back-end de comercio (catálogo, carrito, checkout, pagos, pedidos) y reconstruir los diferenciadores sobre un stack desacoplado con esquema de datos real y una capa de IA con Claude + GPT. Rehacer el comercio sería desperdicio; seguir sobre el enfoque actual bloquea la mitad del contrato.

01

Estado actual

Radiografía medida sobre el código y la base de datos reales del sitio desplegado, no sobre la propuesta.

~30K
Líneas PHP custom
4 plugins propios; el 68 % en un solo plugin de conectores
~9.6K
Líneas JS custom
designer.js = 6.345 líneas, monolítico, jQuery, 0 módulos
4
Personalizadores solapados
Artifi + Zakeke (SaaS) + swc-v7 + promoink-decorator
0
Esquema de datos propio
Todo en _swc_config serializado + 4 tablas sueltas
3
Proveedores SOAP
PCNA + SanMar + SAGE/PromoPlace (PromoStandards)

Inventario de componentes propios

ComponenteRolTecnologíaEstado real
build_pcna_v620.615 LOC PHPImport + conectores PCNA/SanMar/SAGEPHP + SOAP; feeds vía WP All ImportParcial
swc-v72.766 PHP · 6.345 JSProduct Designer (canvas)Fabric.js desde CDN + jQuery, sin buildParcial
swc-supplier-automation-v25.509 LOC PHPÓrdenes de compra + tracking + tarifasPHP + SOAP; FedEx/UPS en sandboxParcial
promoink-decorator820 PHP · 1.645 JSDecorador virtual alternoPHP monolito + JSRedundante
Modelo de datos4 tablas + postmetaDiseños, colores, POswp_swcpd_saved_designs, _swc_configAusente como esquema
Capa bilingüe EN/ESRequisito central del contrato (WS2)Sin Polylang/WPMLNo existe
Asesor de campañas IAEl corazón de la nueva visión (WS14–16)OpenAI solo para análisis de imagen/colorNo existe

Integraciones vivas: catálogo PCNA/SanMar/SAGE apuntando a producción; envío de órdenes en test; Stripe en LIVE; SanMar sale a través de un proxy Cloudflare de terceros (eabucam.workers.dev) no propiedad del cliente.

02

Cobertura contra los 16 workstreams

El contrato (Exhibit A) define 16 workstreams. Los 1–9 son el MVP cotizado; los 10–16 son la expansión "AI Campaign Advisor". Así están hoy:

WSWorkstreamEstadoEvidencia
1Audit & TransitionHechoEste informe + despliegue seguro
2Plataforma bilingüe EN/ESFaltaSin capa de traducción
3Product DesignerParcialFabric.js monolítico; sin versionado/print-ready/móvil sólidos
4Product Data / importParcialWP All Import; sin normalización idempotente
5CommerceBase OKWooCommerce + Stripe live
6Supplier IntegrationsParcialSOAP funcional; órdenes en test; proxy externo
7Connector FrameworkParcialCódigo por proveedor, sin clase base reutilizable clara
8Deployment & OperationsHechoAislamiento, SSL, backups, fail2ban, hardening
9QA & HandoverPendienteSin matriz de pruebas ni docs formales
10Universal Product & Decoration SchemaFaltaDatos en _swc_config, no en un esquema
11Decoration Import & MappingFaltaSin normalización de terminología ni cola de revisión
12Decoration Pricing EngineFalta / inseguroPrecio se calculaba en el cliente (vuln. crítica ya parcheada)
13Visual Template & Print-Zone MappingFaltaSin plantillas por familia con coords relativas
14AI Campaign Advisor FoundationFaltaOpenAI solo analiza imágenes, no asesora
15Recommendation Knowledge LayerFaltaSin taxonomía ni reglas de scoring
16Auditability & Human ReviewFaltaSin estados AUTO_READY / MANUAL_REVIEW

Lectura: los WS 1, 5 y 8 están sólidos; los 3, 4, 6, 7 son bases parciales reutilizables como conocimiento (no como código); toda la mitad de "inteligencia" (10–16) — que es lo que hace único a PromoInk — está por construir.

03

Por qué el desarrollo anterior quedó limitado

No es falta de esfuerzo: son techos estructurales. Cada punto está respaldado por evidencia del propio código.

L1

WordPress como toda la plataforma, no como una pieza

La lógica de negocio (diseñador, precios, decoración) se fuerza dentro de plugins y de blobs serializados en _swc_config. Sin un modelo de datos, no hay dónde vivir el precio, las zonas o las reglas — por eso el precio terminó calculándose en el navegador.

Evidencia: 79 tablas, ninguna de esquema de decoración/precio; el precio del carrito se leía del $_POST (vulnerabilidad crítica que ya corregí).
L2

Frontend sin herramientas modernas

El diseñador es un único archivo de 6.345 líneas de JavaScript con Fabric.js cargado desde un CDN y jQuery, sin bundler, sin componentes, sin módulos ES6. Es inmantenible y no permite la UX que pide el contrato (móvil, versionado, export imprenta 300 DPI).

Evidencia: designer.js = 6.345 LOC, 0 clases/imports ES6, 18 usos de jQuery; sin package.json/webpack/vite en ningún plugin.
L3

Cuatro personalizadores solapados = reinicios sin arquitectura

Conviven Artifi (SaaS), Zakeke (SaaS), swc-v7 y promoink-decorator. Es la huella de intentar el mismo problema cuatro veces sin una decisión de arquitectura — y arrastra el vendor-lock-in que el contrato quiere eliminar.

Evidencia: plugin Zakeke presente + referencias a Artifi en 3 clases de build_pcna_v6 + dos diseñadores custom.
L4

El problema de dominio que el estándar no resuelve

PromoStandards entrega las áreas de decoración como medidas físicas, no como píxeles sobre las fotos. El dev anterior intentó "dibujar los 26.000 a mano" — inviable. Falta el paso que hace escalar esto: un pipeline de calibración por familia.

Evidencia: los XSD del estándar no tienen campos de coordenadas; el reto de los 26k productos del video del cliente.
L5

Integración por parches, no por diseño

SanMar sale a través de un Cloudflare Worker de terceros para alcanzar el endpoint SOAP en el puerto 8080. Funciona, pero es un workaround con un secreto en infraestructura que no es del cliente — frágil y contra la exigencia de ownership.

Evidencia: sanmar_proxy_url = …eabucam.workers.dev en la configuración; import de feeds delegado a WP All Import.
L6

Sin capa de datos = sin las funciones "inteligentes"

Un asesor de campañas, un motor de precios auditable y una consola de revisión necesitan un modelo relacional. Como no existe, esas funciones simplemente no pudieron nacer: OpenAI quedó reducido a analizar imágenes, no a asesorar.

Evidencia: OpenAI se invoca solo en class-designer-image-selector y class-color-resolver; cero tablas de campaña/recomendación.
04

Stack objetivo

Principio rector: no reconstruir lo que WooCommerce hace bien; reconstruir los diferenciadores sobre un stack desacoplado con un esquema de datos real. Verde = se conserva. Azul = se construye nuevo.

Construir

Storefront + Designer Next.js · React · TypeScript

  • Front headless que reemplaza la vitrina Elementor y el monolito jQuery.
  • Ruteo i18n /en · /es con SSR/SSG → resuelve el bilingüe (WS2) como arquitectura, no como plugin, con SEO/hreflang correcto.
  • Designer como componente real (Fabric.js/Konva) con zonas de impresión desde el esquema, versionado, aprobación y export imprenta 300 DPI; Three.js para los 3 productos piloto en 3D. Retira Artifi + Zakeke.
▼ REST / Store API ▼
Construir

Servicios de aplicación Node / Python · API propia

  • Esquema Universal de Producto y Decoración (WS10) en Postgres: variantes, métodos, ubicaciones, dimensiones + unidad, tiers de precio, procedencia, confianza, estado de revisión.
  • Motor de precios (WS12) determinista y auditable en el servidor — blank + tiers + setup + run + decoración + margen, con snapshot por cotización. Cierra por diseño la clase de vulnerabilidad que parcheé.
  • Framework de conectores (WS6/7): clase base (auth, mapeo, reintentos, logging, fallback), imports idempotentes; elimina el proxy Cloudflare y la fragilidad de WP All Import.
  • Pipeline de decoración (WS11/13) — servicio Python "clasificar y calibrar": segmentación de silueta + calibración medida→píxel por familia + score de confianza + cola de revisión humana.
▼ órdenes · pagos · clientes ▼
Conservar

WooCommerce como back-end de comercio WordPress · headless

  • Catálogo, carrito, checkout, Stripe (live), pedidos, impuestos, cuentas, emails transaccionales.
  • Es plumbing genuinamente difícil y ya probado — reconstruirlo sería puro desperdicio y riesgo. Se expone vía Store API/REST y deja de renderizar la UI.

Reusar vs. rehacer: de las ~40K líneas actuales, lo reutilizable no es el código sino el conocimiento de dominio — los mapeos SOAP campo-a-campo de PCNA/SanMar/SAGE y las reglas de negocio. Eso se porta; el monolito del diseñador y el pricing en cliente se descartan.

05

Capa de IA — Anthropic + GPT

El Asesor de Campañas (WS14–16) es donde Claude encaja de forma casi perfecta: los 10 golden tests exigen salida estructurada, cero alucinación y revisión humana — exactamente lo que dan las structured outputs + tool use.

Asesor de campañas claude-opus-5

El razonamiento del estratega. Salida forzada al esquema de los golden tests.

  • output_config.format → 3 productos rankeados + rationale + restricciones + estado de precio/stock + confianza + alternativas.
  • Tool use contra el esquema real (catálogo, inventario, precio) → cumple "nunca inventar datos del proveedor".
  • Prompt caching del contexto de catálogo y reglas; bilingüe EN/ES nativo.

Escala y coste claude-sonnet-5

Casi calidad Opus a $3/$15 por millón. Para volumen del asesor en producción.

  • Mismo contrato de salida estructurada; se conmuta por ruta según coste/latencia.
  • claude-haiku-4-5 para extracción barata del intake (objetivo, audiencia, presupuesto…).

Visión / imagen GPT-4o · vision

Se conserva OpenAI donde ya está cableado (análisis de imagen/color) y como opción del pipeline de decoración.

  • Clasificación de familia y refinamiento de anclas en el pipeline de zonas.
  • El archivo de producción siempre lleva la medida real del API — el dibujo es solo guía.

Auditabilidad WS16

Cada recomendación guarda prompt/modelo/regla/snapshot y estado.

  • Estados AUTO_READY / PREVIEW_READY / MANUAL_REVIEW.
  • Las structured outputs hacen trivial persistir el rastro de decisión en el esquema.

Por qué Claude para el asesor y GPT para imagen: el asesor se juzga con un rubric de 10 casos con umbral 85/100 y prohibición de alucinar; salida estructurada + herramientas de grounding son la vía directa a pasar ese rubric. GPT ya está integrado para lo visual, así que se mantiene ahí en vez de reescribir.

06

Ruta por fases

Alineada con el faseo que el propio contrato insinúa (fundaciones primero; asesor/pipeline por Change Order).

FASE 0 ✓

Asegurar y desplegar lo existente

Hecho: sitio aislado, endurecido y en producción como referencia viva y fuente de datos. Vulnerabilidades críticas corregidas.

FASE 1

Fundaciones del stack nuevo

Esquema Postgres + servicio de conectores (idempotente, sin proxy externo) + shell del storefront Next.js + Designer MVP para las 2 familias piloto (~500 SKUs) + motor de precios en servidor. WooCommerce queda como back-end de comercio.

FASE 2

Pipeline de decoración

Calibrar el piloto, medir el % real de automatización, y escalar hacia los 26.000 con números medidos. Se reusa el editor de zonas del dev anterior como herramienta de excepciones.

FASE 3

Asesor de campañas + auditabilidad

Claude con structured outputs + tool use contra los 10 golden tests; consola de revisión y estados AUTO_READY/MANUAL_REVIEW. Bilingüe completo. Retiro de Artifi + Zakeke.

Lo que necesito para arrancar la Fase 1

  • Confirmar org de GitHub propiedad del cliente (hoy el repo está en una cuenta personal — exigencia contractual 9.1).
  • Decidir alojamiento del esquema/servicios (mismo Hetzner aislado, o infra dedicada del cliente).
  • Aprobar el set piloto (2 familias / ~500 SKUs) para dimensionar el pipeline con datos reales.
  • Mover el proxy SanMar y las llaves de proveedor a infraestructura y cuentas del cliente.
PROMOINK AI · AUDITORÍA TÉCNICA · CONFIDENCIAL Sergio Duran · 2026-07-28