Propuesta, no aceptada: investiga el estado real de Medusa 2.18.0 para
soportar checkout de verdad (hoy el carrito cierra por WhatsApp).
Verificado contra codigo real y documentacion oficial de Medusa
(2026-08-28): cero shipping options configuradas (bloqueador
independiente del proveedor de pago), Stripe es de primera clase en
Medusa v2 pero no acepta comercios registrados en Colombia
(confirmado contra stripe.com/global), PayU tiene compatibilidad
declarada con Medusa 2.4.0+, Wompi no documenta version de Medusa ni
actividad reciente.
Deja la eleccion de proveedor de pago explicitamente pendiente de
decision de negocio del usuario -- no es algo que se pueda resolver
en el codigo.
Reemplaza ADR 0007 (Atelier calido, ciruela/carbon/cobre) tras dos
ciclos de implementar-y-descartar en produccion. Esta vez la direccion
se valido con mockups fuera de este entorno antes de tocar codigo.
- globals.css: paleta marino/coral/coral-claro + alias temporales de
los tokens de ADR 0007 (se resuelven ya contra la paleta nueva para
no dejar catalog-client/product-card/button.tsx sin estilo hasta que
cada sub-fase migre el nombre de clase; se eliminan en la sub-fase 5).
- layout.tsx: Poppins peso 700 reemplaza a Domine en --font-display.
- Nuevo isotipo (mariposa de 4 elipses) como logo-ari.svg (lockup) y
app/icon.svg (favicon reducido, convencion Next.js App Router);
favicon.png anterior eliminado por no estar referenciado.
- docs: ADR 0008 con la cronologia completa y el hallazgo de los
gradientes arcoiris nunca actualizados en navbar.tsx; ADR 0007
marcado como superseded sin borrar su contenido.
Validado con npm ci + typecheck + lint + build de produccion via
Docker (no hay node/npm en este shell) y verificando el CSS
compilado: los alias resuelven a la paleta nueva y las utilities
bg-ari-ciruela/text-ari-carbon/bg-ari-hueso se siguen generando.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01F8c83sjFBP7c4m4UVN5d3d
Identidad visual propia premium (ver docs-portal/docs/decisiones/0007-identidad-visual-propia.md,
revision 2). Correccion de proceso respecto al intento anterior
(v1.0.176, revertido): en vez de un token aislado en un solo boton,
esta pasada toca de punta a punta los componentes que se ven juntos en
la misma pantalla para que ninguna card quede a mitad de camino.
- globals.css: paleta ciruela/carbon-oscuro/cobre/hueso (reemplaza
cyan/magenta/yellow/blue, confirmado sin uso previo). Domine
(titulares/precio) + Inter (UI/cuerpo) via next/font/google -- antes
"Inter" era solo un fallback de CSS sin garantia real de carga.
- button.tsx: variant "magenta" renombrada a "primary" (ya no es
magenta, es ciruela solida) y su color redefinido -- renombrada en
los 8 archivos que la usaban para no dejar un nombre enganoso.
Radio base rounded-full -> rounded-lg, ring de foco retintado.
- product-card.tsx: badges NUEVO/TOP/descuento en la paleta nueva (no
mas fucsia/amarillo neon), precio en Domine, radio y sombra
consistentes con el boton.
- catalog-client.tsx: solo clases de color/radio en breadcrumb, filtro
de precio, pills de filtro y boton de reset -- cero cambios de
logica.
Header, footer, home y pagina de producto/drawers quedan con la
paleta anterior a proposito -- Sub-fases 2, 4 y 5 pendientes.
Validado con `docker build --target builder` (npm ci + next build con
typecheck completo) -- compila limpio.
Propuesta de rediseno visual del storefront, aprobada por el usuario
tras una correccion de direccion explicita: no clonar la estetica de
Amazon, adoptar los principios de UX del mercado (jerarquia visual,
densidad sin saturacion, senales de confianza, contraste) para
construir una identidad propia y distintiva -- paleta terracota/
espresso/pino/crema validada con contraste WCAG AA real, tipografia
Fraunces+Inter, lenguaje de forma propio, 3 detalles deliberados no
genericos.
Alcance: solo visual, no toca catalogo/backend/taxonomia ni la
estructura de navegacion ya construida en ADR 0005. Plan de
implementacion en 5 sub-fases (tokens -> header/footer -> product
card+catalog -> home -> product detail/drawers), sin codigo de
produccion tocado todavia.
Reemplaza los placeholders "TODO (fase 2+)" por narrativa completa,
grounded en el codigo/manifiestos/incidentes reales del lab (no
generico):
- ADR 0001 (por que k3d) y ADR 0002 (por que Argo CD): pasan de
template vacio a Contexto/Opciones/Decision/Consecuencias reales,
apoyados en known-issues.md (blackhole MTU) y en la config real de
ecommerce-app.yaml.
- vision-general.md: el "por que" de cada frontera de confianza del
diagrama.
- gitops-flujo.md: ejemplo real con hashes de commit (Fase 3b de
ADR 0006, v1.0.171 -> hotfix -> v1.0.172), selfHeal explicado con el
syncPolicy real del repo.
- red-y-exposicion.md: diagrama de terminacion TLS real, por que todo
va "proxied", patron de diagnostico "interno sano, publico roto".
- glosario.md: 9 terminos nuevos, cada uno con ejemplo real y
verificado del repo (Namespace, ResourceQuota, LimitRange,
NetworkPolicy, Deployment, Service, Ingress, StatefulSet, Init
container).
- notas-sueltas.md: MinIO/S3, limites reales del subscriber
revalidate-storefront.ts, que se automatizaria desde cero.
Validado con `docker build --target build` (mkdocs build --strict,
mismo paso que el pipeline real) -- cero links rotos, cero warnings.
Aprobada tras el diagnóstico de memoria del host (swap saturado
resuelto, ~500-700MiB liberados al desactivar monitoring). Agrega
nota de implementación con 3 desviaciones reales encontradas al
verificar el código fuente del plugin en el tag v1.4.1 antes de
escribir código: no hace falta subscriber propio (el plugin trae los
suyos), las rutas del plugin no devuelven facetDistribution (se
agrega una ruta Store API propia), y se conecta vía plugins: no
modules:. Ninguna cambia la decisión, solo el cómo.
Etapa 1 (auditoria/propuesta, sin codigo) de la Etapa 3 de Fase 5:
motor de busqueda y filtros facetados reales, reemplazando el
filtrado/conteo 100% client-side que dejo la sub-fase 3 de Etapa 2.
Verificado contra documentacion oficial vigente (no memoria de
entrenamiento):
- Medusa no tiene modulo de busqueda propio integrado con
Meilisearch; el Search Module nativo llego en Medusa 2.19, y el
plugin comunitario @rokmohar/medusa-plugin-meilisearch se conecta a
el solo desde su version ^2.0.0 (requiere Medusa >=2.19). Nuestro
backend corre Medusa 2.18.0 -- la version compatible es la linea
^1.4.1 del plugin (Medusa >=2.15 <2.19), documentada como deuda
tecnica explicita si se sube Medusa mas adelante.
- Impacto de recursos evaluado contra el estado real del host (swap
al 100%, mismo tipo de contencion que el incidente de Gitea):
Meilisearch recomendado sobre Typesense por menor huella de RAM y
por ser el unico con integracion Medusa mantenida para nuestra
version -- comparacion mantenida breve porque la diferencia es
clara, sin profundizar mas de lo necesario.
- Diseno de indexacion (campos buscables/filtrables/ordenables),
sincronizacion (mismo patron de subscriber por eventos que
revalidate-storefront.ts, sumando product-category.* al set de
eventos) y UI de facetas/autocompletado (reutiliza catalog-client.tsx
y CatalogProvider.searchProducts ya existentes, sin componentes
nuevos).
Cross-referencia agregada en ADR 0004 (que ya habia identificado
Meilisearch como paso natural) y entrada nueva en mkdocs.yml.
Etapa 2 (implementacion) NO arranca hasta aprobacion explicita de esta
propuesta.
Estado seguia diciendo "propuesta -- pendiente de aprobacion antes de
Etapa 2" aunque las 3 sub-fases (datos/categorias, navegacion,
componentes visuales -- PRs #29-#42) ya estan implementadas y en
produccion desde el 2026-08-25. Actualiza el header de estado y
reemplaza la seccion 6 (antes "Proximos pasos" pendiente de
aprobacion) por el resumen real de lo ejecutado, dejando explicito que
sigue pendiente borrar el usuario admin temporal de la auditoria y que
no hay Etapa 3 definida todavia.
Fase 5 Etapa 1: auditoria del catalogo actual (categorias/colecciones
de Medusa sin uso real, nav hardcodeado, bug de +categories en Store
API), decision de evolucionar el stack en vez de reescribirlo,
patrones UX de Amazon/eBay/Walmart y taxonomia de 21 categorias ya
creada en Medusa junto con 9 productos [DEMO] validados en vivo en
shop.cruzcloud.net como linea base pre-rediseno.
Agrega lo que faltaba para desplegar workloads/docs-portal/ (ya existente
sin commitear): deployment/service/ingress + kustomization siguiendo el
patrón de workloads/nginx, Applications de workload y gobernanza
separadas, y el workflow de Gitea Actions (build+push a Gitea Registry,
bump de versión en el manifiesto) siguiendo el mismo patrón que
build.yaml/build-medusa.yaml.
devops
