Encontrado probando en vivo con navegador real (Docker + Playwright):
una búsqueda de 2+ caracteres sin coincidencias no mostraba nada -- ni
"Buscando…" ni ningún mensaje. El usuario quedaba sin feedback de que
su búsqueda de verdad corrió. Se agrega un estado vacío con el botón
de buscar en todo el catálogo (esa búsqueda completa puede usar
criterios más amplios que el autocompletado).
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01THZFwPzrwv6VAbuwmaf5vR
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.
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).
devopsandClaude Sonnet 5