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.
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.
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).
Motor de busqueda self-hosted, sin que Medusa lo conozca todavia
(eso es Fase 2). Mismo patron que redis/postgres/minio en este mismo
namespace: StatefulSet + PVC via volumeClaimTemplates en local-path,
nunca Deployment ni emptyDir -- el indice de Meilisearch necesita
sobrevivir a un reinicio del pod para no reindexar todo desde cero.
Imagen getmeili/meilisearch:v1.53.1 (ultimo release estable no-RC,
verificado contra la API de GitHub, no memoria de entrenamiento).
Recursos exactos del ADR (request 100m/256Mi, limit 500m/768Mi).
Sin securityContext explicito -- verificado en vivo que la imagen no
trae un usuario no-root (Alpine minimo, /etc/passwd sin usuario
dedicado), misma convencion que redis.yaml/minio.yaml en este repo,
que tampoco fuerzan runAsNonRoot.
MEILISEARCH_HOST (no secreto) va al ConfigMap commerce-config.
MEILI_MASTER_KEY/MEILISEARCH_API_KEY (mismo valor, dos nombres de env
var -- uno para el servidor, otro para el futuro plugin de Medusa en
Fase 2) documentados en secrets.template.yaml; el valor real ya se
aplico al Secret commerce-secrets en el cluster antes de este merge
(patch puntual, no via create-commerce-secrets.sh completo -- ese
script regenera TODAS las credenciales en cada corrida y hubiera
rotado postgres/redis/minio ya en uso).
commerce.cruzcloud.net (medusa-svc) has no route at "/" — Medusa only
serves /health, /app (admin), /store, etc. lab-agent's generic public
domain check flagged the resulting 404 as an anomaly every cycle even
though the service is healthy.
Adds a Traefik Middleware (redirectRegex) scoped to the commerce host
that 301s "/" to "/app", so the DNS/routing layer owns the entry point
instead of every client (including monitoring) having to know to
append /app manually. Regex includes the host explicitly because the
same Ingress also routes media.cruzcloud.net and shares
router.middlewares at the Ingress-annotation level.
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.
Bug preexistente (no introducido en esta sesion, solo expuesto): "/" se
prerenderizaba en build time dentro del Dockerfile, donde
HEADLESS_PROVIDER/MEDUSA_* no existen todavia (solo se inyectan en runtime
via el Deployment de k8s) -- el provider caia a "mock" y ese HTML quedaba
cacheado 1 año (confirmado en vivo: x-nextjs-prerender:1,
Cache-Control: s-maxage=31536000, x-nextjs-cache:HIT). El carrusel de
"Novedades" del home ya mostraba productos mock desde antes; recien se
noto con el nav data-driven de la sub-fase 2 porque las categorias mock
("Figuras"/"Peluches"/"Mochilas") son obviamente distintas a las reales.
/catalog y /product/[slug] no sufren esto porque ya son dinamicos
(searchParams / params fuerzan SSR).
export const dynamic = "force-dynamic" en app/page.tsx y app/layout.tsx
(el layout comparte el fetch del Navbar con TODAS las rutas -- forzarlo
ahi tambien protege contra que una pagina futura reintroduzca el mismo
bug). Decision del usuario: priorizar datos reales sobre el cacheo
estatico de 1 año.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_013dunTcReWMKhWgCPkvAVHD
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
- Trivy IaC escaneaba solo el patch aislado de Kustomize
(workloads/ecommerce/frontend/patches/deployment.yaml), no lo que
realmente corre en el clúster. Eso generaba falsos positivos en todo
lo heredado del base remoto de platform-templates (runAsNonRoot,
seccompProfile) porque el patch nunca los repite. Se instala kubectl,
se renderiza el kustomization completo y se escanea ese output.
- readOnlyRootFilesystem pasa de false a true en el contenedor del
frontend: revisando next.config.ts (optimización de imágenes) y
app/api/revalidate/route.ts (revalidateTag sin cache handler custom),
la imagen sí escribe a ./.next/cache en runtime. Se agregan volúmenes
emptyDir para .next/cache y /tmp.
Los 17 productos legacy ya tienen category, collection, brand, ageRange,
imagenes y featured/isNew reales en Medusa (migrados en fix #2/#2b de
Etapa 2 sub-fase 1), por lo que el fallback hardcodeado en mapProduct()
ya no aporta nada y solo duplica datos que pueden desincronizarse.
devops
