variant.available (calculado en lib/headless/providers/medusa.ts a
partir de manage_inventory/allow_backorder/inventory_quantity) ya
llegaba correcto hasta el componente, pero ningun boton de compra lo
usaba -- se podia seguir agregando al carrito un producto con stock 0.
Afecta product-purchase.tsx (pagina de producto), mobile-add-to-cart.tsx
(barra fija mobile) y product-card.tsx (tarjetas de catalogo): boton
deshabilitado + label "Agotado" en los tres, mas badge/overlay en la
tarjeta de catalogo.
TS2769: la anotacion explicita {location_id: string} no calzaba con el
tipo Maybe<InventoryLevel> que infiere query.graph para location_levels.
Se quita la anotacion y se deja inferir, con optional chaining.
Nueva pestana "Inventario" en el sidebar del Admin (src/admin/routes/
inventario), pensada para un usuario no tecnico: una fila por producto
(catalogo real confirmado 1 variante por producto), switch para activar
seguimiento de stock, input de cantidad que guarda solo, badge de stock
bajo (<=5 unidades) y activacion/desactivacion en bloque por seleccion.
No reemplaza la vista nativa de Inventory de Medusa, es un atajo.
Backend: src/api/admin/inventory-panel/route.ts + workflow propio
src/workflows/attach-inventory-item-to-variant.ts para vincular un
InventoryItem nuevo a una variante existente (Medusa no lo hace solo al
togglear manage_inventory en un producto ya creado -- confirmado en vivo
contra un producto [DEMO] antes de escribir el codigo).
Nombres de campos y workflows verificados contra los .d.ts reales
instalados en el pod (no solo contra la documentacion, que no cubre bien
este flujo de vincular inventario a una variante existente).
Implementa el flujo completo de OAuth social de Medusa para el
storefront: boton "Continuar con Google" en account-dialog, ruta proxy
que arranca el flujo (GET /api/customer/google/start) y pagina de
callback en /auth/google/callback (coincide con GOOGLE_CALLBACK_URL del
secret) que resuelve el code/state contra el backend, decodifica el JWT
para distinguir cliente nuevo vs existente, crea el customer si hace
falta y refresca el token a sesion final -- mismo patron de
store/customer-store.ts que login/register por email.
Flujo verificado en vivo contra el backend ya desplegado (GET
/auth/customer/google, /auth/customer/google/callback con state
invalido, /auth/token/refresh con bearer invalido) antes de escribir el
codigo, no solo contra la documentacion.
npm run build (medusa build) carga medusa-config.ts, que ahora exige
GOOGLE_CLIENT_ID/GOOGLE_CLIENT_SECRET/GOOGLE_CALLBACK_URL via required().
Sin valores dummy en el builder stage, el build fallaba con "Error in
loading config: La variable GOOGLE_CLIENT_ID es obligatoria" -- mismo
patron ya usado para JWT_SECRET/MEILISEARCH_API_KEY.
Agrega el modulo @medusajs/medusa/auth con providers emailpass (explicito,
para no perder el default al customizar el modulo) y google, leyendo
GOOGLE_CLIENT_ID/GOOGLE_CLIENT_SECRET/GOOGLE_CALLBACK_URL desde
commerce-secrets con required().
Pedido explicito del usuario tras probar el login real: el boton de
'Mi cuenta' estaba oculto en mobile (hidden sm:inline-flex, solo
alcanzable desde el menu hamburguesa). Pasa a estar siempre visible en
el header, y agrega un punto verde cuando hay sesion iniciada -- mismo
patron visual que los badges de cantidad de carrito/favoritos, pero de
presencia (con sesion o sin ella), no de conteo.
Conecta el dialogo 'Tu cuenta ARI' (antes solo ofrecia WhatsApp) al
Store API real de Medusa. Flujo verificado en vivo con un cliente de
prueba real antes de escribir el codigo: registro -> crear customer
-> login -> /store/customers/me, todo confirmado funcionando.
Detalle no documentado que se confirmo en vivo: el token que devuelve
/auth/customer/emailpass/register sirve para crear el customer via
POST /store/customers, pero no queda como sesion real -- hay que
loguear de nuevo (/auth/customer/emailpass) para obtener el token de
sesion. Mensajes de error tambien verificados: correo repetido -> 401
'Identity with email already exists'; credenciales invalidas -> 401
'Invalid email or password'.
Mismo patron arquitectonico que el carrito real (ADR 0009): rutas
puente /api/customer/* (MEDUSA_BACKEND_URL es DNS interno, no resuelve
desde el navegador), store de Zustand con sesion persistida y
resincronizada contra el servidor al rehidratar. WhatsApp se mantiene
como opcion secundaria, ya no es la unica salida.
Reemplaza los inputs de texto libre de Ciudad/Departamento por dos
selects en cascada, poblados con el dataset oficial de DIVIPOLA (33
departamentos + 1123 municipios, fuente proyecto26/colombia,
verificado contra la codificacion real del DANE antes de incorporarlo
-- id 5001 = Medellin, departmentId 5 = Antioquia, etc.). Sin
dependencia npm nueva (JSON estatico + helper propio).
Se guarda el id DIVIPOLA seleccionado en el estado del formulario, no
solo el nombre -- EnvioClick (la integracion de envios real que
reemplazara la tarifa fija de este ADR) va a necesitar identificar la
ciudad sin ambiguedad, y las transportadoras colombianas referencian
ciudades por este codigo. El nombre derivado del id sigue siendo lo
que se manda a Medusa (shipping_address espera texto, no cambia el
contrato existente).
Siguiente corte tras el carrito real: pagina /checkout de 3 pasos
(direccion -> envio -> confirmar) contra el Store API real, usando la
shipping option que ya se verifico en produccion. Endpoints nuevos
(setShippingAddress, getShippingOptions, addShippingMethod) probados
en vivo con un carrito de prueba real antes de escribir el codigo --
direccion, opciones de envio y total ya confirmados correctos
(80.000 + 5.000 = 95.000).
El pago (PayU custom) sigue sin existir, asi que el ultimo paso sigue
siendo WhatsApp -- pero ahora el mensaje incluye direccion, metodo de
envio y total real en vez de solo la lista de productos. El boton del
CartDrawer pasa de abrir WhatsApp directo a llevar a /checkout.
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).
devops
gitea-actions