Reportado en produccion: el carrito mostraba el logo generico de ARI
en vez de la foto del producto. Verificado en vivo: item.thumbnail
viene null en la respuesta de Medusa para todo el catalogo real
(confirmado tambien contra /store/products directamente -- el campo
thumbnail del producto es null en la fuente, no solo omitido en la
respuesta del carrito). El catalogo ya resuelve esto cayendo a
images[0] (mapProduct() en medusa.ts); la linea del carrito necesita
pedir esa relacion explicita via fields=*items.product.images (no
viene por defecto) y aplicar el mismo fallback.
Primer corte de checkout real, a proposito acotado: el carrito pasa de
estado 100% local (localStorage con productos completos) a sincronizar
con un cart_id real de Medusa via /api/cart/* (rutas puente
same-origin, mismo patron que /api/search -- MEDUSA_BACKEND_URL es DNS
interno del cluster, no resuelve desde el navegador).
Formas de respuesta de la API verificadas en vivo con un carrito de
prueba real antes de escribir el mapeo (no asumidas contra
documentacion): agregar el mismo variant_id dos veces hace merge de
cantidad automatico (no crea linea duplicada); eliminar una linea
devuelve el carrito actualizado en 'parent', no en 'cart' como los
demas endpoints.
La firma publica de useCartStore (addItem/removeItem/updateQuantity/
items) no cambia, asi que ningun componente consumidor (cart-drawer,
navbar, product-card, product-purchase, mobile-add-to-cart) necesito
tocarse. Sigue cerrando por WhatsApp -- direccion/envio/pago quedan
para los siguientes cortes del ADR 0009.
Verificado el codigo/README real de los dos unicos paquetes de Medusa
que aparecen buscando 'PayU' (@tax1driver/medusa-payu y
medusa-plugin-payu de rigby-sh, este ultimo archivado desde
2025-03-21): ambos usan la terminologia de la API de PayU Polonia/CEE
(clientId/posId/secondKey, OAuth), no la de PayU LatAm
(apiLogin/apiKey/accountId, developers.payulatam.com, la que cubre
Colombia). 'PayU' es una marca compartida por dos productos distintos.
La decision de negocio (PayU como proveedor) se mantiene -- cambia la
via tecnica: integracion via modulo de pago custom
(AbstractPaymentProvider de Medusa) contra la API real de PayU LatAm,
mismo tipo de esfuerzo que EnvioClick, no instalacion de plugin.
De paso, documenta las shipping options ya creadas y verificadas en
produccion (stock location, fulfillment set, service zone Colombia,
shipping option de 5.000 COP) incluyendo el paso no documentado que
las dejaba invisibles para el Store API (vinculo a sales channel).
Dato de negocio real del usuario: cuentas disponibles son Davivienda,
Lulo Bank y Banco de Bogota -- ninguna Bancolombia ni Nequi.
Verificado el mismo dia: Wompi exige cuenta Bancolombia o al menos
Nequi solo para REGISTRARSE como comercio (aunque la liquidacion
despues pueda ir a cualquier banco) -- ninguno de los bancos
disponibles califica sin abrir una cuenta nueva. PayU solo exige
cuenta bancaria colombiana a nombre del comercio, sin banco
especifico, y ya soporta PSE + Nequi + Daviplata para el cliente sin
importar el banco del comercio -- cubre exactamente lo que se pidio
(PSE + Nequi 'y demas bancos').
Estado pasa de propuesta a aceptada. Wompi se deja documentado como
deuda a reevaluar si en el futuro se abre cuenta Bancolombia/Nequi --
no se descarta por limitacion tecnica del plugin, solo por el
requisito de registro actual.
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.
promo-backpacks.webp tenia el fondo punteado violeta/morado del
esquema arcoiris original, notado al confirmar el fix anterior de
Club ARI (el panel de texto ya paso a azul solido, pero la foto de al
lado seguia con su propio color viejo).
Sin herramienta de generacion de imagenes disponible, se reconstruye
el mismo efecto (fondo punteado + fotos estilo polaroid) con CSS
(radial-gradient azul sobre fondo amarillo, circulo decorativo azul)
y 3 fotos reales de producto ya existentes en public/images/products/
en vez de la foto compuesta vieja.
Dos leftovers del esquema original notados de pasada durante las
pruebas de ADR 0008 (fuera del alcance original de logo/buscador/
hero/tiles, pero mismo patron): la etiqueta 'Novedades' en
text-fuchsia-600 y la seccion 'Club ARI' con gradiente
cyan-500/blue-600/violet-600 + badge text-yellow-300.
Ambos pasan a los tokens de marca (ari-coral, ari-marino solido,
ari-coral-claro) -- ya no queda ningun gradiente ni color hardcodeado
del esquema arcoiris original en el home.
Reportado en produccion: con object-contain + margenes grandes
(inset-x-6 top-6 bottom-24) la foto quedaba chica y centrada, con
mucho espacio muerto del pastel alrededor -- no se parecia a la
referencia real de Walmart que mando el usuario, donde la foto
aprovecha casi toda la tarjeta.
Cambia a object-cover (recorta en vez de contener) dentro de un marco
mas delgado (inset-3 en vez de inset-x-6/top-6), dejando solo un
margen fino del pastel visible como marco alrededor de la foto.
El usuario mando una captura real de walmart.com: en las tarjetas de
producto la foto no cubre la tarjeta completa, flota contenida sobre
un fondo pastel solido -- exactamente el mismo patron que ya usan las
tarjetas sin foto de esta seccion (Bebes, Educativos, etc.), solo que
Juguetes/Mochilas rompian el patron con la foto a pantalla completa +
una franja de degradado para el texto (el intento anterior, tambien
reportado como no convincente).
Reemplaza fill+object-cover a pantalla completa por una foto
contenida (object-contain) en la mitad superior de la tarjeta, dejando
el fondo pastel visible alrededor -- coherente con el resto de la
seccion. Elimina el campo scrim, ya no hace falta.
npm run build fallaba en CI (runs 201 y 202, ambos commits que incluian
hero-carousel.tsx) con 'slide is possibly undefined' -- indexar
slides[index] con TypeScript estricto (noUncheckedIndexedAccess) tipa
el resultado como Slide | undefined aunque el indice siempre sea
valido en runtime (useState(0) + modulo en el autoplay + clicks solo
a indices validos).
Como el build nunca genero una imagen nueva, Argo seguia sirviendo
v1.0.197 (el commit anterior al carrusel) -- el hero y los tiles-scrim
en produccion nunca reflejaron estos dos cambios ya mergeados a main.
Este fix desbloquea ambos builds.
Reportado en produccion: las tarjetas con foto (Juguetes, Mochilas)
usaban una franja de degradado blanca generica para el texto, y se
veian desconectadas de las tarjetas solidas vecinas (rosa, verde,
etc.) de la misma seccion. La franja ahora usa el mismo pastel
asignado a esa categoria (from-amber-100 / from-sky-100) en vez de
blanco, y se agranda ligeramente (h-2/5 -> h-3/5) para mas presencia.
Reemplaza hero-bento.tsx (grid estatico de 3 tarjetas en fucsia/rosa/
rojo/violeta del esquema arcoiris original, nunca migrado -- sub-fase
4 del ADR 0008 pendiente) por hero-carousel.tsx: un slide a la vez
sobre fondo azul de marca (--color-ari-marino) para los tres
mensajes promocionales existentes, con dots de paginacion clicables
abajo (patron pedido explicitamente por el usuario) y autoplay cada
6s (respeta prefers-reduced-motion). Actualiza app/page.tsx para usar
el componente nuevo y elimina hero-bento.tsx.
Reportado en produccion: en mobile aparecian dos botones 'Añadir al
carrito' apilados. ProductPurchase.tsx nunca ocultaba su boton en
mobile, y MobileAddToCart.tsx (barra fija abajo, solo lg:hidden) ya
cubre esa misma accion ahi -- se agrega hidden lg:inline-flex al
primero para que solo uno este visible por breakpoint.
De paso, dos leftovers del esquema arcoiris original en la misma
pagina, vistos en la misma sesion de pruebas: el badge de variante
seleccionada (border-fuchsia-500 bg-fuchsia-50 text-fuchsia-700 -> azul
de marca) y la etiqueta de categoria/coleccion (text-fuchsia-600 ->
ari-coral).
Reemplaza el lockup rectangular (logo-ari.svg) por un isotipo circular
nuevo (logo-ari-circular.svg) con el icono mariposa + wordmark 'ARI
shopping' integrados dentro del mismo circulo azul -- el formato que
tenia la version previa a ADR 0008, preferido sobre el rectangulo
segun mockup de referencia del usuario. El footer conserva el lockup
rectangular, donde si tiene sentido como bloque de color autocontenido
sobre el fondo oscuro.
category-tiles.tsx (PromoTile, compartido entre home y grid de
catalogo) nunca se toco en ninguna sub-fase de ADR 0008 -- la sub-fase
4 ('Home: hero, tiles, secciones') quedo pendiente de implementar
(confirmado: no existe merge fix/adr0008-*-subfase4-* en el historial).
Seguia con gradientes saturados rojo/violeta/magenta/cian del esquema
arcoiris original, confirmado visualmente en produccion.
Reemplaza los gradientes por fondos pastel solidos (amber/sky/rose/
emerald/orange/violet-100, patron Walmart-inspirado), texto oscuro
sobre el pastel, boton circular de accion en azul de marca
(--color-ari-marino) en vez de blanco/negro generico, y los acentos
fucsia/cian del encabezado de seccion por los tokens de marca.
El outline de accesibilidad global (input:focus-visible, azul de
marca, globals.css) y el indicador de foco propio del wrapper
(focus-within:border-ari-marino + ring amarillo) se mostraban ambos a
la vez -- redondear el outline (commit anterior) evito el rectangulo
recto pero seguia leyendose como dos bordes anidados, reportado en
produccion (v1.0.193).
focus-visible:outline-none en el input iguala la especificidad de la
regla global (mismo patron que ya usa buttonVariants en button.tsx) y
deja el indicador de foco del wrapper como el unico visible -- no se
pierde accesibilidad, se elimina la duplicacion.
globals.css define input:focus-visible { outline: 3px solid
rgb(0 85 184 / .5); ... } como indicador de foco por teclado global,
intencional (no se toca). Le gana en especificidad CSS a la utilidad
outline-none de Tailwind, asi que seguia mostrandose sobre el input
propio del buscador (commit anterior) -- pero como ese input no tenia
border-radius, se veia como un rectangulo de esquinas rectas
superpuesto al pill redondeado, reportado en produccion (v1.0.192).
Agrega rounded-full al input para que el mismo outline (que se debe
conservar) siga el contorno del pill en vez de cortarlo.
El fix anterior (focus:border-0 focus:ring-0) no elimino de forma
confiable el focus:ring-4 focus:ring-cyan-300/30 hardcodeado del
componente <Input> compartido dentro de este contenedor compuesto
(input + boton circular en el mismo wrapper) -- reportado en
produccion (v1.0.191): un segundo ring amarillo se superponia y
cortaba visualmente el boton de la lupa al hacer click.
En vez de seguir peleando el override via tailwind-merge, el buscador
deja de usar el <Input> compartido y usa un <input> nativo con sus
propias clases minimas, sin nada que sobreescribir.
El Input base (components/ui/input.tsx) trae focus:border-cyan-500 y
focus:ring-4 focus:ring-cyan-300/30 hardcodeados. La correccion
anterior del buscador solo anulaba focus-visible:ring-0, una variante
distinta a :focus -- el ring cian del componente base seguia
disparandose al hacer click, superpuesto al ring amarillo del wrapper
nuevo (dos anillos visibles a la vez, reportado por el usuario en
produccion tras el deploy de v1.0.190).
focus:border-0 focus:ring-0 anula correctamente ambas utilidades del
Input base via tailwind-merge (mismo variant+propiedad).
predictive-search.tsx nunca estuvo en el alcance de ninguna sub-fase
de ADR 0008 (sub-fase 2 solo tocaba navbar.tsx/footer.tsx), asi que
seguia con el borde degradado cian/violeta/fucsia y acentos violeta
del esquema arcoiris original -- confirmado visualmente en produccion
(captura del usuario) y en el codigo.
Reemplaza el wrapper de gradiente por un input con borde solido y un
boton circular azul (--color-ari-marino) con la lupa a la derecha, en
vez del icono flotando a la izquierda sobre el degradado. Foco usa
ring amarillo (--color-ari-coral-claro), igual que el resto de
componentes interactivos del sitio (button.tsx). Hover/foco del panel
de resultados y del boton 'Buscar en todo el catalogo' pasan de
violeta a los tokens de marca.
El header de /images/:path* (7 dias, pensado para fotos de producto
que no cambian) tambien alcanzaba a los assets de marca (logo,
favicon), que si cambian con cada iteracion de identidad visual.
Confirmado en vivo contra shop.cruzcloud.net: Cloudflare seguia
sirviendo el logo de la iteracion anterior 'Navy & Coral'
(fill #122844/#D85A30) mas de 14h despues de que el pod ya corria
v1.0.185 con el logo 'Azul & Amarillo' (#0055B8/#FFC220) --
cf-cache-status: HIT, age: 51378s, last-modified anterior al redeploy.
No es un bug del logo.svg en si (el contenido del archivo ya era
correcto desde la sub-fase 1 de ADR 0008) sino de una politica de
cache compartida con assets que no deberian tener el mismo TTL.
hasTrustDialogAccepted vive en ~/.claude.json (archivo suelto en
/root), no dentro de ~/.claude/ que ya estaba montado -- se perdia en
cada recreacion del contenedor pese a que el login si persistia.
Fix: bind mount archivo-a-archivo, sembrado con el .claude.json ya
confirmado. Verificado en vivo: claude arranca sin re-pedir el
dialogo tras recrear el contenedor.
El comando docker run documentado no funcionaba realmente desde
dentro del contenedor: /DATA/AppData es un symlink absoluto a
/media/HDD-Storage/AppData, que queda roto si solo se monta /DATA.
Agrega el mount que falta, el git safe.directory necesario (baked en
el arranque, no persiste en el volumen de credenciales), y documenta
ambos gotchas con como se detectaron.
Explica el problema que resuelve (persistencia de sesion ante cortes
de red/dispositivo, distinto de limites de cuota), la arquitectura
del contenedor tmux-host, y por que Docker en vez de instalacion
nativa (squashfs read-only en ZimaOS).
ADR 0008: pivote de paleta de "Navy & Coral" a "Azul & Amarillo"
(Walmart-inspirada), confirmado explicitamente por el usuario. Sub-fases
1-3 ya en main heredan la paleta nueva via CSS vars sin tocarse.
Merge directo local, patron estandar aprobado para cierres de sub-fase
de este proyecto (ver sub-fases 1-2).
devops
gitea-actions