Aplica la paleta marino/coral al navbar y footer, reemplazando los
ultimos restos del esquema arcoiris original (barra de promo
amber/lima, linea decorativa cyan/violeta/fucsia, pills y mega-menu
fucsia/violeta) documentados en el ADR 0008 seccion 5. Aplica
logo-ari.svg (lockup nuevo) en navbar y footer, reemplazando
logo-ari.png y el marco circular que no encajaba con el aspect ratio
del lockup.
Ver docs-portal/docs/decisiones/0008-identidad-navy-coral.md.
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.
El smoke test en aislamiento (boton CTA terracota + precio en
Fraunces) no se puede juzgar de forma justa rodeado del resto de la
pagina, que sigue en la paleta anterior (badges NUEVO/TOP en fucsia/
amarillo, fondo blanco) -- choque visual real, no una direccion de
marca evaluable. Ademas la direccion terracota/artesanal en si no era
lo que se buscaba (se quiere premium/serio, no rustico).
Vuelve product-card.tsx y button.tsx a su estado anterior a Sub-fase
1. globals.css/layout.tsx quedan con los tokens y next/font ya
integrados (nadie los consume todavia, cero impacto visual) para no
rehacer ese trabajo de infraestructura -- la proxima iteracion de
diseno se construye y aprueba en una preview aislada (fuera del
storefront real) antes de volver a tocar produccion.
Identidad visual propia (ver docs-portal/docs/decisiones/0007-identidad-visual-propia.md):
paleta terracota/espresso/pino/crema/carbon reemplaza los tokens
--color-ari-cyan/magenta/yellow/blue (confirmado sin uso en ningun
componente antes de tocarlos). Fraunces + Inter cargadas via
next/font/google (antes "Inter" era solo un fallback de CSS sin
garantia real de carga).
Cambio minimo a proposito: nueva variant "primary" en button.tsx sin
tocar la clase base compartida (radio, ring de foco quedan igual para
el resto del sitio), aplicada como smoke test unico en el CTA y el
precio de ProductCard. El resto de la propagacion (header, footer,
badges, home, product detail) queda para las Sub-fases 2-5, cada una
con su propio gate.
Validado con `docker build --target builder` (npm ci + next build con
typecheck completo) -- compila limpio.
Verificado en vivo contra shop.cruzcloud.net: /store/search reporta
estimatedTotalHits (campo `count`) en 0 cuando limit=0, aunque
facetDistribution si trae los valores correctos (limit>=1 lo reporta
bien). El bucket "Todas"/"Todos" del sidebar de facetas (Fase 3b)
dependia de ese campo -- ahora suma los valores de la propia
facetDistribution, que da el total real sin ese problema.
Fase 3b (ultima) de ADR 0006 Etapa 2: los conteos de categoria/marca/edad
del sidebar de /catalog dejan de ser un snapshot client-side fijo. Ahora
se refetchean en vivo contra /api/search en cada cambio de filtro (query
debounced 300ms), tres llamadas paralelas -- una por dimension, cada una
omitiendo su propio filtro para preservar el patron Amazon de "cuantos
resultados habria si eligiera este otro valor".
- catalog-client.tsx: useMemo client-side originales pasan a ser fallback
(mock/shopify sin searchWithFacets, o cuando la categoria activa es un
grupo raiz sintetico que Meilisearch no puede filtrar).
- ProductFilters gana `limit` opcional; /api/search y el provider medusa
lo reenvian -- las llamadas de solo-conteo piden limit=0 para no
rehidratar precios de productos que no se van a mostrar.
PredictiveSearch pasa de filtrar en memoria el arreglo completo de
productos (prop products, substring match) a un fetch debounced
(250ms, con AbortController) contra la nueva ruta /api/search --
mismo componente visual, solo cambia de donde salen los datos, tal
como pide el ADR 0006 seccion 5.
/api/search (nueva, server-side) es el puente same-origin: el
componente es cliente y no puede pegarle directo al provider
server-side (MEDUSA_BACKEND_URL es DNS interno del cluster, no
resuelve desde el navegador).
CatalogProvider gana un metodo OPCIONAL searchWithFacets? (no cambia
la firma de getProducts/searchProducts) -- mock.ts y shopify.ts
compilan sin tocarlos, siguen sin implementarlo. medusa.ts lo
implementa contra /store/search (Fase 2), reutilizando mapProduct()
ya que la ruta devuelve el mismo shape de producto que /store/products.
searchProducts tambien se repunta a /store/search, dejando de usar el
?q= + re-filtro client-side de fetchProducts/matchesFilters para busqueda
(que sigue sirviendo para navegacion sin busqueda, sin cambios).
Navbar deja de pasarle products a PredictiveSearch (ya no los necesita)
pero los sigue recibiendo el mismo -- collections todavia se deriva de
ahi.
Limpieza: borrado patches/frontend-medusa-env.yaml, confirmado
huerfano (ningun kustomization lo referencia; el patch que si esta
vivo es frontend/patches/deployment.yaml).
Validado: build completo de Docker (target builder) -- npm ci,
next build con typecheck, /api/search aparece en la tabla de rutas
generada. Cero errores nuevos (los warnings de ESLint son
preexistentes en catalog-client.tsx, no tocado en esta fase).
tsconfig tiene noUncheckedIndexedAccess -- promoRoots[promoIndex %
promoRoots.length] tipa como Category | undefined aunque en runtime
siempre es valido (promoRoots.length > 0 ya se verifico antes de este
punto). Extraido a una constante con guard explicito para que TS
angoste el tipo. Sin cambio de comportamiento.
Detectado por el build real en main tras el merge de #41 -- no se
puede correr tsc localmente en esta maquina (ver notas de sesiones
anteriores), asi que esto solo lo valida el CI post-merge.
ADR 0005 seccion 3 (patron Walmart), ultimo item de la sub-fase de
componentes visuales: "grid de catalogo con tiles promocionales
intercalados, no solo tarjetas de producto homogeneas".
`category-tiles.tsx` ya era ese mismo primitivo visual (usado en el
home) -- se extrajo el tile individual a un componente exportado
`PromoTile` (mismo look, sin cambio visual en el home) para
reutilizarlo en `catalog-client.tsx`: un tile cada
PROMO_TILE_INTERVAL=8 productos, ciclando por las categorias raiz
(excluye la raiz que el usuario ya esta viendo via el breadcrumb de
#40). Si no hay jerarquia de categorias disponible, la grilla queda
igual que antes (solo productos) -- degradacion sin romper nada.
Depende de #40 (breadcrumb + categoryNodes en CatalogClient) -- mismo
archivo, se apila sobre esa rama en vez de main.
ADR 0005 seccion 3 (patron Amazon), primer item de "Filtros facetados
en sidebar con breadcrumb de categoria":
- Breadcrumb (Inicio > raiz > hija) armado caminando parentId sobre la
jerarquia real de categorias (misma que ya consume el mega-menu de
navbar.tsx), no un dato nuevo -- CatalogClient ahora recibe el
arreglo `categories: Category[]` completo ademas del
`categoryGroups` ya existente
- Conteo por valor en cada filtro de la sidebar (Categoria/Marca/Edad),
ej. "Marca (12)": se calcula client-side sobre los productos que ya
pasan el resto de filtros activos, cada dimension excluyendose a si
misma (patron faceted-count estandar). Sin Meilisearch por ahora,
como preveia el ADR ("server-side simple por ahora")
Filtrado existente refactorizado a funciones matchesX() puras y
reutilizadas tanto por `filtered` como por los conteos, sin cambiar el
comportamiento de filtrado ya validado.
Expone ProductVariant.inventoryQuantity (ya calculado desde
variant.inventory_quantity en Medusa, hoy colapsado al booleano
available) y lo usa para mostrar "Quedan N" cuando el stock real es
bajo (<=5), tanto en la tarjeta de producto como en la ficha. null
indica inventario no gestionado (backorder / manage_inventory=false),
donde nunca se muestra un numero. ADR 0005 seccion 3 (patron eBay).
Catalogo mock actualizado (data/products.json) con
inventoryQuantity=null en todas las variantes para seguir tipando
contra Product[] via `satisfies`.
Reutiliza Product.variants[].{name,value,available}, ya expuesto por el
provider de Medusa (variant.options[0]), para swatches clicables en la
tarjeta del catalogo/home -- no solo en la ficha de producto. Solo se
muestra cuando el producto tiene mas de una variante; la variante
seleccionada se usa al agregar al carrito. ADR 0005 seccion 3 (patron
eBay), cero cambio de modelo de datos.
Reutiliza Product.compareAtPrice (ya calculado en el provider de Medusa
via original_amount > calculated_amount) para mostrar precio tachado +
badge de descuento en la grilla/catalogo, no solo en la ficha de
producto. ADR 0005 seccion 3, patron Walmart -- cero cambio de modelo
de datos.
Reemplaza la fila horizontal de pildoras por categoria (ADR 0005 seccion
3, patron Walmart) por un trigger unico "Departamentos" que abre un
panel multi-columna con las 6 categorias raiz y sus hijos, activado por
hover (mouse) o tap (touch), con cierre por click-fuera y Escape.
next build fallaba en tsc: defaultTile no tenia la propiedad opcional
image, asi que la union de tipos entre tileContent[handle] y defaultTile
perdia esa propiedad y content.image no compilaba. Se extrae el tipo
TileContent y se anota defaultTile con el, igual que tileContent.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_013dunTcReWMKhWgCPkvAVHD
Sub-fase 2 de Etapa 2 (ADR 0005 seccion 6). Navbar y CategoryTiles usaban
arrays hardcodeados (Figuras/Peluches/Mochilas/Marvel) que ya no coinciden
con los nombres reales de categoria en Medusa desde que se elimino
legacyProductMeta (PR #29) -- todos esos links de navegacion quedaron
rotos silenciosamente (0 productos al filtrar).
- lib/headless: nuevo tipo Category + metodo getCategories() en
CatalogProvider (medusa via /store/product-categories, mock deriva de
su catalogo plano, shopify sin implementar como el resto de sus metodos).
- Navbar: arbol real de categorias (6 raices/21 nodos), dropdown de
hijos por raiz en desktop, lista anidada en el sheet movil. Colecciones
del sheet ahora se derivan de los productos reales en vez de un array
hardcodeado con 2 nombres obsoletos (Marvel/Frozen vs. los reales
Universo Marvel/Reino de Frozen).
- CategoryTiles: tiles de home por categoria raiz real; imagen solo donde
ya existe asset, gradiente honesto donde no (no hay fotografia para las
6 raices todavia, deuda explicita del ADR).
- catalog-client/catalog page: cuando el query param `category` es una
raiz con hijos, se expande a los nombres reales de sus hijos para que
el filtro (igualdad exacta de producto.category) siga funcionando --
sin esto, tiles/nav apuntando a una raiz mostrarian 0 productos porque
ningun producto tiene la raiz asignada directamente.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_013dunTcReWMKhWgCPkvAVHD
devops
