Fase 2 fix: /store/search resuelve currency_code, no solo region_id

Confirmado en vivo: pasar solo region_id a QueryContext no alcanza --
"Method calculatePrices requires currency_code in the pricing
context" persistia. A diferencia de /store/products nativo (resuelto
por el middleware setPricingContext), esta ruta propia no pasa por esa
cadena, asi que resuelve la moneda real de la region con un
query.graph adicional antes de pedir calculated_price -- no asume COP
fijo por si el catalogo suma otra region/moneda despues.

apps/monitoring-app.yaml

@@ -1,40 +0,0 @@
-apiVersion: argoproj.io/v1alpha1
-kind: Application
-
-metadata:
-  name: monitoring-app
-  namespace: argocd
-
-spec:
-  project: default
-
-  source:
-    repoURL: https://prometheus-community.github.io/helm-charts
-    chart: kube-prometheus-stack
-    targetRevision: 58.3.3
-
-    helm:
-      parameters:
-        - name: prometheusOperator.admissionWebhooks.patch.ttlSecondsAfterFinished
-          value: "60"
-
-      valuesObject:
-        grafana:
-          ingress:
-            enabled: true
-            ingressClassName: traefik
-            hosts:
-              - grafana.cruzcloud.net
-
-  destination:
-    server: https://kubernetes.default.svc
-    namespace: monitoring
-
-  syncPolicy:
-    automated:
-      prune: true
-      selfHeal: true
-
-    syncOptions:
-      - CreateNamespace=true
-      - ServerSideApply=true

apps/monitoring-governance-app.yaml

@@ -1,20 +0,0 @@
-apiVersion: argoproj.io/v1alpha1
-kind: Application
-metadata:
-  name: monitoring-governance
-  namespace: argocd
-spec:
-  project: default
-  source:
-    repoURL: https://gitea.cruzcloud.net/devops/platform-infra.git
-    path: monitoring-governance
-    targetRevision: main
-  destination:
-    server: https://kubernetes.default.svc
-    namespace: monitoring
-  syncPolicy:
-    automated:
-      prune: true
-      selfHeal: true
-    syncOptions:
-      - CreateNamespace=true

workloads/commerce-backend/Dockerfile

@@ -21,7 +21,9 @@ ENV CI=true \
     S3_ACCESS_KEY_ID=build-access-key \
     S3_SECRET_ACCESS_KEY=build-secret-key \
     S3_BUCKET=ari-shopping \
-    S3_ENDPOINT=http://127.0.0.1:9000
+    S3_ENDPOINT=http://127.0.0.1:9000 \
+    MEILISEARCH_HOST=http://127.0.0.1:7700 \
+    MEILISEARCH_API_KEY=build-only-meili-key
 
 COPY package.json package-lock.json .npmrc ./
 

workloads/commerce-backend/medusa-config.ts

@@ -10,6 +10,91 @@ const required = (name: string): string => {
   return value
 }
 
+// Mismos campos derivados de metadata/categories/collection/variants que
+// mapProduct() en workloads/ecommerce/lib/headless/providers/medusa.ts --
+// el documento indexado debe reflejar exactamente lo que el storefront
+// ya muestra, no una vista distinta del catálogo.
+function stringMetadata(
+  metadata: Record<string, unknown> | null | undefined,
+  key: string,
+): string {
+  const value = metadata?.[key]
+  return typeof value === "string" ? value : ""
+}
+
+function booleanMetadata(
+  metadata: Record<string, unknown> | null | undefined,
+  key: string,
+): boolean {
+  const value = metadata?.[key]
+  return value === true || value === "true"
+}
+
+async function meilisearchProductTransformer(
+  document: Record<string, unknown>,
+) {
+  const metadata = (document.metadata ?? null) as Record<
+    string,
+    unknown
+  > | null
+  const categories = document.categories as
+    | Array<{ name?: string | null }>
+    | null
+    | undefined
+  const collection = document.collection as { title?: string | null } | null
+  const variants = document.variants as
+    | Array<{
+        inventory_quantity?: number | null
+        manage_inventory?: boolean | null
+        allow_backorder?: boolean | null
+        prices?: Array<{
+          amount?: number | null
+          currency_code?: string | null
+        }> | null
+      }>
+    | null
+    | undefined
+  const variant = variants?.[0]
+  const tags = document.tags as Array<{ value?: string | null }> | null
+
+  const category =
+    categories?.[0]?.name || stringMetadata(metadata, "category") || "Variedades"
+
+  const available =
+    !variant ||
+    variant.allow_backorder === true ||
+    variant.manage_inventory === false ||
+    (variant.inventory_quantity ?? 0) > 0
+
+  // variants.calculated_price requiere currency_code/region_id en el
+  // contexto de pricing, que el workflow de sync interno del plugin no
+  // provee -- hace fallar TODO el job de indexado (confirmado en vivo:
+  // "Method calculatePrices requires currency_code in the pricing
+  // context"). variants.prices es la lista cruda de precios (sin
+  // resolver promociones/reglas), no necesita contexto -- alcanza para
+  // el filtro/orden por precio en la busqueda, que no necesita el
+  // precio final promocional.
+  const copPrice = variant?.prices?.find(
+    (price) => price.currency_code?.toLowerCase() === "cop",
+  )
+
+  return {
+    id: document.id,
+    name: document.title || "Producto ARI Shopping",
+    shortDescription: document.subtitle || document.title || "",
+    description: document.description || "",
+    category,
+    collection: collection?.title || stringMetadata(metadata, "collection") || "",
+    brand: stringMetadata(metadata, "brand") || "ARI Shopping",
+    ageRange: stringMetadata(metadata, "ageRange") || "Todas",
+    tags: (tags || []).map((tag) => tag.value).filter(Boolean),
+    price: typeof copPrice?.amount === "number" ? copPrice.amount : null,
+    available,
+    isNew: booleanMetadata(metadata, "isNew"),
+    featured: booleanMetadata(metadata, "featured"),
+  }
+}
+
 module.exports = defineConfig({
   projectConfig: {
     databaseUrl: required("DATABASE_URL"),
@@ -73,4 +158,72 @@ module.exports = defineConfig({
       },
     },
   ],
+
+  // ADR 0006 Etapa 2. Sin required(): a diferencia de S3/DB, Meilisearch
+  // es un servicio nuevo y todavia no probado en produccion en un host
+  // con historial de swap saturado -- si esta caido o mal configurado,
+  // el plugin se degrada solo (soporta enabled:false, "silently skipped"
+  // segun su propio README) en vez de tumbar el arranque de Medusa
+  // entero, que es lo que si haria required().
+  plugins: [
+    {
+      resolve: "@rokmohar/medusa-plugin-meilisearch",
+      options: {
+        config: {
+          host: process.env.MEILISEARCH_HOST ?? "",
+          apiKey: process.env.MEILISEARCH_API_KEY ?? "",
+        },
+        settings: {
+          products: {
+            type: "products",
+            enabled: Boolean(process.env.MEILISEARCH_HOST),
+            primaryKey: "id",
+            // Campos que el plugin pide via query.graph antes de pasarlos
+            // al transformer de arriba -- si falta alguno acá, llega
+            // undefined al transformer sin importar lo que este haga.
+            fields: [
+              "id",
+              "title",
+              "subtitle",
+              "description",
+              "handle",
+              "status",
+              "thumbnail",
+              "metadata",
+              "tags.value",
+              "categories.name",
+              "collection.title",
+              "variants.inventory_quantity",
+              "variants.manage_inventory",
+              "variants.allow_backorder",
+              "variants.prices.amount",
+              "variants.prices.currency_code",
+            ],
+            indexSettings: {
+              // Tabla de ADR 0006 §3: Buscable / Filtrable-faceta / Ordenable.
+              searchableAttributes: [
+                "name",
+                "shortDescription",
+                "description",
+                "category",
+                "collection",
+                "brand",
+                "tags",
+              ],
+              filterableAttributes: [
+                "category",
+                "collection",
+                "brand",
+                "ageRange",
+                "price",
+                "available",
+              ],
+              sortableAttributes: ["price", "isNew", "featured"],
+            },
+            transformer: meilisearchProductTransformer,
+          },
+        },
+      },
+    },
+  ],
 })

workloads/commerce-backend/package-lock.json

@@ -12,7 +12,8 @@
         "@medusajs/admin-sdk": "2.18.0",
         "@medusajs/cli": "2.18.0",
         "@medusajs/framework": "2.18.0",
-        "@medusajs/medusa": "2.18.0"
+        "@medusajs/medusa": "2.18.0",
+        "@rokmohar/medusa-plugin-meilisearch": "^1.4.1"
       },
       "devDependencies": {
         "@swc/core": "^1.7.28",
@@ -6561,6 +6562,28 @@
         "node": ">=14.0.0"
       }
     },
+    "node_modules/@rokmohar/medusa-plugin-meilisearch": {
+      "version": "1.4.3",
+      "resolved": "https://registry.npmjs.org/@rokmohar/medusa-plugin-meilisearch/-/medusa-plugin-meilisearch-1.4.3.tgz",
+      "integrity": "sha512-+iStv5sc2vuLk+O7OcQLlNR99fMBhGdBOJMCmDJYoTFGhzBA4ZEV18IIr2xqxUDgdQo1haF0TtYv3JmRQUuY1w==",
+      "license": "MIT",
+      "dependencies": {
+        "meilisearch": "^0.56.0"
+      },
+      "engines": {
+        "node": ">=22"
+      },
+      "peerDependencies": {
+        "@medusajs/admin-sdk": "^2.15.2",
+        "@medusajs/framework": "^2.15.2",
+        "@medusajs/medusa": "^2.15.2",
+        "@medusajs/ui": "^4.1.12",
+        "@tanstack/react-query": "5.64.2",
+        "awilix": "^8.0.1",
+        "react": "^18",
+        "react-dom": "^18"
+      }
+    },
     "node_modules/@rolldown/pluginutils": {
       "version": "1.0.0-beta.27",
       "resolved": "https://registry.npmjs.org/@rolldown/pluginutils/-/pluginutils-1.0.0-beta.27.tgz",
@@ -11774,6 +11797,12 @@
         "node": ">= 0.6"
       }
     },
+    "node_modules/meilisearch": {
+      "version": "0.56.0",
+      "resolved": "https://registry.npmjs.org/meilisearch/-/meilisearch-0.56.0.tgz",
+      "integrity": "sha512-kBXba8DcSrLWHYqopCm2JL90oBy97VdIfHkP1ii7/eHufeEEEk9Zu5Vv/IFQpNzmhEpWszVFVlGvZoI6QJeGzA==",
+      "license": "MIT"
+    },
     "node_modules/merge-descriptors": {
       "version": "1.0.3",
       "resolved": "https://registry.npmjs.org/merge-descriptors/-/merge-descriptors-1.0.3.tgz",

workloads/commerce-backend/package.json

@@ -14,7 +14,8 @@
     "@medusajs/admin-sdk": "2.18.0",
     "@medusajs/cli": "2.18.0",
     "@medusajs/framework": "2.18.0",
-    "@medusajs/medusa": "2.18.0"
+    "@medusajs/medusa": "2.18.0",
+    "@rokmohar/medusa-plugin-meilisearch": "^1.4.1"
   },
   "devDependencies": {
     "@swc/core": "^1.7.28",

workloads/commerce-backend/src/api/store/search/route.ts

@@ -0,0 +1,197 @@
+import type { MedusaRequest, MedusaResponse } from "@medusajs/framework";
+import {
+  ContainerRegistrationKeys,
+  QueryContext,
+} from "@medusajs/framework/utils";
+import {
+  MEILISEARCH_MODULE,
+  type MeiliSearchService,
+} from "@rokmohar/medusa-plugin-meilisearch";
+
+// Las rutas /store/meilisearch/* que trae el plugin (ver ADR 0006 nota de
+// implementacion) no devuelven facetDistribution -- necesitamos esta
+// ruta propia para pedirlo explicitamente via additionalOptions.facets,
+// que el servicio del plugin reenvia tal cual al cliente Meilisearch.
+const FACETS = ["category", "collection", "brand", "ageRange"];
+
+// Mismos campos que ya usa el storefront contra /store/products
+// (workloads/ecommerce/lib/headless/providers/medusa.ts) -- una vez que
+// Meilisearch nos da los ids candidatos, volvemos a Medusa via
+// query.graph para precio/inventario reales, nunca confiamos en el
+// valor indexado (puede tener unos segundos de retraso respecto al
+// evento de sincronizacion).
+const PRODUCT_FIELDS = [
+  "id",
+  "handle",
+  "title",
+  "subtitle",
+  "description",
+  "thumbnail",
+  "external_id",
+  "metadata",
+  "images.url",
+  "tags.value",
+  "categories.name",
+  "collection.title",
+  "variants.id",
+  "variants.title",
+  "variants.sku",
+  "variants.manage_inventory",
+  "variants.allow_backorder",
+  "variants.inventory_quantity",
+  "variants.calculated_price.calculated_amount",
+  "variants.calculated_price.original_amount",
+  "variants.calculated_price.currency_code",
+  "variants.options.value",
+  "variants.options.option.title",
+];
+
+function stringParam(
+  query: MedusaRequest["query"],
+  name: string,
+): string | undefined {
+  const value = query[name];
+  return typeof value === "string" && value.length > 0 ? value : undefined;
+}
+
+function numberParam(
+  query: MedusaRequest["query"],
+  name: string,
+): number | undefined {
+  const value = stringParam(query, name);
+  if (!value) return undefined;
+  const parsed = Number(value);
+  return Number.isFinite(parsed) ? parsed : undefined;
+}
+
+// Meilisearch usa comillas dobles para valores de filtro con espacios;
+// escapamos las que vengan en el propio valor para no romper la sintaxis.
+function escapeFilterValue(value: string): string {
+  return value.replace(/\\/g, "\\\\").replace(/"/g, '\\"');
+}
+
+export async function GET(req: MedusaRequest, res: MedusaResponse) {
+  const meilisearchService = req.scope.resolve<MeiliSearchService>(
+    MEILISEARCH_MODULE,
+  );
+  const query = req.scope.resolve(ContainerRegistrationKeys.QUERY);
+
+  const q = stringParam(req.query, "q") ?? "";
+  const limit = numberParam(req.query, "limit") ?? 24;
+  const offset = numberParam(req.query, "offset") ?? 0;
+  // calculated_price exige region_id/currency_code en el contexto de
+  // pricing o query.graph tira "Method calculatePrices requires
+  // currency_code in the pricing context" (mismo error que ya rompio el
+  // job de sync -- ver medusa-config.ts). El storefront ya manda
+  // region_id contra /store/products (medusa.ts, regionId()); esta ruta
+  // espera el mismo query param.
+  const regionId = stringParam(req.query, "region_id");
+
+  const filterParts: string[] = [];
+  for (const facet of ["category", "collection", "brand", "ageRange"]) {
+    const value = stringParam(req.query, facet);
+    if (value) {
+      filterParts.push(`${facet} = "${escapeFilterValue(value)}"`);
+    }
+  }
+  const minPrice = numberParam(req.query, "minPrice");
+  const maxPrice = numberParam(req.query, "maxPrice");
+  if (typeof minPrice === "number") filterParts.push(`price >= ${minPrice}`);
+  if (typeof maxPrice === "number") filterParts.push(`price <= ${maxPrice}`);
+
+  const indexes = await meilisearchService.getIndexesByType("products");
+
+  if (indexes.length === 0) {
+    // Meilisearch no configurado o el indice "products" esta
+    // deshabilitado -- degradar a "sin resultados" en vez de 500, el
+    // frontend cae de nuevo a su propio filtrado si esta ruta falla.
+    res.json({ products: [], facetDistribution: {}, count: 0, limit, offset });
+    return;
+  }
+
+  const results = await Promise.all(
+    indexes.map((indexKey) =>
+      meilisearchService.search(indexKey, q, {
+        filter: filterParts.length ? filterParts.join(" AND ") : undefined,
+        paginationOptions: { limit, offset },
+        additionalOptions: { facets: FACETS },
+      }),
+    ),
+  );
+
+  const hits = results.flatMap((result) => result.hits);
+  const totalCount = results.reduce(
+    (sum, result) => sum + result.estimatedTotalHits,
+    0,
+  );
+
+  const facetDistribution: Record<string, Record<string, number>> = {};
+  for (const result of results) {
+    const resultFacets = (
+      result as unknown as {
+        facetDistribution?: Record<string, Record<string, number>>;
+      }
+    ).facetDistribution;
+    if (!resultFacets) continue;
+    for (const [facet, values] of Object.entries(resultFacets)) {
+      facetDistribution[facet] ??= {};
+      for (const [value, count] of Object.entries(values)) {
+        facetDistribution[facet][value] =
+          (facetDistribution[facet][value] ?? 0) + count;
+      }
+    }
+  }
+
+  const productIds = hits.map((hit) => (hit as { id: string }).id);
+
+  if (productIds.length === 0) {
+    res.json({ products: [], facetDistribution, count: 0, limit, offset });
+    return;
+  }
+
+  // calculatePrices exige currency_code en el contexto -- no alcanza con
+  // region_id solo (a diferencia de /store/products nativo, que lo
+  // resuelve el middleware setPricingContext; esta ruta no pasa por esa
+  // cadena). Resolvemos la moneda real de la region en vez de asumir COP
+  // fijo, por si el catalogo suma otra region/moneda mas adelante.
+  let currencyCode: string | undefined;
+  if (regionId) {
+    const { data: regions = [] } = await query.graph({
+      entity: "region",
+      fields: ["id", "currency_code"],
+      filters: { id: regionId },
+    });
+    currencyCode = regions[0]?.currency_code;
+  }
+
+  const { data: products = [] } = await query.graph({
+    entity: "product",
+    fields: PRODUCT_FIELDS,
+    filters: { id: productIds },
+    context:
+      regionId && currencyCode
+        ? {
+            variants: {
+              calculated_price: QueryContext({
+                region_id: regionId,
+                currency_code: currencyCode,
+              }),
+            },
+          }
+        : {},
+  });
+
+  // Preserva el ranking de relevancia de Meilisearch -- query.graph no
+  // garantiza el mismo orden que la busqueda.
+  const orderedProducts = [...products].sort(
+    (a, b) => productIds.indexOf(a.id) - productIds.indexOf(b.id),
+  );
+
+  res.json({
+    products: orderedProducts,
+    facetDistribution,
+    count: totalCount,
+    limit,
+    offset,
+  });
+}

workloads/docs-portal/docs/decisiones/0004-evaluacion-stack-multi-categoria.md

@@ -109,7 +109,10 @@ Un motor de búsqueda dedicado (Meilisearch, autohospedado) queda
 identificado como el siguiente paso natural una vez el catálogo
 crezca más allá de ~100 productos activos, pero no es parte del
 alcance inmediato de Etapa 2 — se revisará cuando ese techo esté
-cerca.
+cerca. **Actualización 2026-08-25:** terminada la Etapa 2 (ver
+[ADR 0005](0005-rediseno-storefront.md)), el disparador real resultó
+ser la complejidad de facetas de la taxonomía, no el volumen de
+productos — ver [ADR 0006](0006-motor-busqueda-facetas.md).
 
 **Compatibilidad con Medusa Admin confirmada:** ninguna de las tres
 opciones evaluadas, incluida la elegida, toca

workloads/docs-portal/docs/decisiones/0006-motor-busqueda-facetas.md

@@ -0,0 +1,297 @@
+# ADR 0006 — Motor de búsqueda y filtros facetados (Fase 5, Etapa 3)
+
+**Estado:** aceptada — Etapa 2 en implementación (aprobada 2026-08-26 tras diagnóstico de memoria del host)
+**Fecha:** 2026-08-25
+
+## Contexto
+
+[ADR 0004](0004-evaluacion-stack-multi-categoria.md) ya identificó un
+motor de búsqueda dedicado (Meilisearch, autohospedado) como "el
+siguiente paso natural" para ARI Shopping, pero lo dejó fuera del
+alcance de Etapa 2 explícitamente hasta que el catálogo se acercara al
+techo real de ~100 productos activos que impone
+`fetchProducts(filters, limit = 100)` en `medusa.ts`.
+
+**Ese techo todavía no llegó** — el catálogo real hoy son 26 productos
+(17 legacy + 9 demo, ver [ADR 0005](0005-rediseno-storefront.md)
+sección 5), lejos de 100. El disparador de esta propuesta no es el
+techo de volumen sino la **complejidad de facetas**: la Etapa 2 ya
+construyó una taxonomía real de 6 categorías raíz / 21 nodos
+(navegación, mega-menú, breadcrumb — PRs #36-42) y un filtrado con
+conteo por valor (`categoryCounts`/`brandCounts`/`ageCounts` en
+`catalog-client.tsx`, PR #40) que hoy se calcula **100% client-side**
+sobre los productos ya traídos — el mismo patrón de "deuda de
+alcance" que el hallazgo #4 de ADR 0004 ya señaló, ahora con más
+dimensiones de filtro que multiplicar. Sigue siendo tratable a 26
+productos; deja de serlo mucho antes de llegar a 100 si el catálogo
+crece a la vez en número de productos y en dimensiones filtrables.
+
+Restricción no negociable, igual que en toda la Fase 5: el flujo
+**Admin → evento `product.updated` → `revalidate-storefront.ts` →
+`revalidateTag("medusa-products")`**, que hoy mantiene el storefront
+sincronizado sin intervención manual, no se toca. Cualquier índice de
+búsqueda debe sincronizarse por el mismo mecanismo de eventos, nunca
+por un cron ni un paso manual.
+
+## 1. Estado real de la integración Medusa v2 + Meilisearch
+
+Verificado contra la documentación oficial vigente el 2026-08-25, no
+contra memoria de entrenamiento:
+
+- **Medusa no tiene un módulo de búsqueda propio integrado con
+  Meilisearch hoy.** La guía oficial
+  (`docs.medusajs.com/resources/integrations/guides/meilisearch`) es
+  un tutorial de módulo custom desde cero (`npm install meilisearch` +
+  workflows/subscribers propios) — no un paquete instalable.
+- **Medusa sí introdujo un "Search Module" propio en la versión
+  2.19.0.** El paquete comunitario `@rokmohar/medusa-plugin-meilisearch`
+  (el más usado y mantenido para Meilisearch+Medusa) se conecta a ese
+  Search Module desde su versión `^2.0.0`, pero esa versión del plugin
+  **requiere Medusa `^2.19.0`**.
+- **Nuestro backend corre Medusa `2.18.0`** (`commerce-backend/package.json`)
+  — justo por debajo de ese corte. La tabla de compatibilidad del
+  plugin (`github.com/rokmohar/medusa-plugin-meilisearch`) resuelve
+  esto: la línea `^1.4.1` soporta `Medusa >= 2.15 < 2.19`, servidor
+  Meilisearch `>= 1.5`, Node `>= 22`. El propio repo lo explica: *"The
+  2.19 release removed the search interface the v1 line was written
+  against, so the two lines do not overlap: v1 stops at Medusa 2.18,
+  v2 starts at 2.19."*
+- Node de `commerce-backend` ya es `22.18.0` (Dockerfile) — cumple el
+  mínimo del plugin sin cambios.
+
+**Implicación concreta:** para adoptar Meilisearch sin subir de
+versión Medusa (fuera de alcance de este ADR — sería su propia
+migración), la pieza a instalar es `@rokmohar/medusa-plugin-meilisearch@^1.4.1`,
+no la última versión del plugin. Esto es deuda técnica documentada,
+no un obstáculo: si en el futuro se sube Medusa a `2.19+`, migrar a la
+línea `^2.0.0` del plugin (y al Search Module nativo) es el camino
+recto.
+
+## 2. Impacto de recursos
+
+Estado real del host ZimaOS al momento de esta auditoría (`free -h`,
+`docker stats`): 15 GiB RAM totales, **swap al 100% (5.2/5.2 GiB
+usados)**, solo 351 MiB realmente libres (6.5 GiB "available" vía
+cache reclamable), 4 vCPU — la misma clase de contención que ya forzó
+el fix de `cpu_shares` de Gitea. Cualquier servicio nuevo en este host
+es una decisión de capacidad real, no teórica.
+
+- **Meilisearch no publica un mínimo de RAM oficial.** Su propio FAQ
+  (`meilisearch.com/docs/resources/help/faq`) solo dice que "más RAM
+  implica búsquedas más rápidas" y recomienda ~10x el tamaño del
+  dataset crudo en disco — sin piso duro. La cifra de "~1 GiB
+  cómodo" que circula en blogs de la comunidad es una estimación, no
+  una garantía del proveedor — se cita aquí como referencia, no como
+  hecho verificado.
+- Meilisearch usa almacenamiento memory-mapped: el índice puede vivir
+  parcialmente en disco cuando no entra en RAM, degradando latencia en
+  vez de fallar. A la escala actual (26 productos, dataset de KB) el
+  uso real de RAM del índice en sí es insignificante — el costo es el
+  proceso base de Meilisearch, no el dataset.
+- **Comparación con Typesense** (pedida explícitamente, mantenida
+  breve porque la diferencia relevante para este caso es clara y no
+  requiere más profundidad): Typesense mantiene el índice completo en
+  RAM (~30% más RAM que Meilisearch para el mismo dataset, según
+  benchmarks públicos) y, a diferencia de Meilisearch, **no tiene
+  ningún plugin ni integración con Medusa** — habría que escribir la
+  sincronización completa desde cero igual que con la guía "custom"
+  de Meilisearch, pero sin ninguna base comunitaria mantenida
+  compatible con nuestra versión de Medusa. Con Meilisearch ya
+  teniendo un plugin activo para `Medusa 2.18` y menor huella de RAM,
+  no hay motivo para evaluar Typesense más a fondo en este caso.
+- **Recomendación:** desplegar Meilisearch en k3d con `requests`/`limits`
+  explícitos y conservadores desde el día uno (ej. `request: 256Mi/0.1
+  CPU`, `limit: 768Mi/0.5 CPU` — a ajustar con datos reales de uso, no
+  supuestos), y tratarlo como el mismo tipo de riesgo operativo que ya
+  se vivió con Gitea: monitorear consumo real post-despliegue antes de
+  darlo por estable. Dado el swap ya saturado, este es el punto de
+  mayor incertidumbre de toda la propuesta — más que la elección de
+  motor de búsqueda en sí.
+
+## 3. Modelo de indexación
+
+Basado en la taxonomía real ya viva en Medusa (Etapa 2) y en
+`Product`/`Category` de `lib/headless/types.ts`:
+
+| Campo | Buscable (texto, tolerante a typos) | Filtrable / faceta | Ordenable |
+|---|---|---|---|
+| `name` | Sí | No | No |
+| `shortDescription` / `description` | Sí | No | No |
+| `category` (nombre de la hoja real) | Sí | Sí (con conteo) | No |
+| `collection` | Sí | Sí (con conteo) | No |
+| `brand` | Sí | Sí (con conteo) | No |
+| `ageRange` | No | Sí (con conteo) | No |
+| `tags` | Sí | No | No |
+| `price` | No | Sí (rango) | Sí |
+| `compareAtPrice` | No | No | No (solo se usa para el badge, no como filtro) |
+| `isNew` / `featured` | No | No | Sí (orden "Novedades"/"Destacados", igual que hoy) |
+| `available` | No | Sí (booleano) | No |
+| `slug`, `thumbnail`, `id` | No | No | No (solo se devuelven, no se indexan como facetas) |
+
+La jerarquía de categorías (raíz/hija) no se indexa como un campo
+aparte: el índice guarda el nombre de la hoja real tal como hoy lo
+hace `product.category`, y el breadcrumb/mega-menú siguen resolviendo
+la jerarquía contra `/store/product-categories` (sin cambios, ya
+funciona desde la sub-fase 2). El motor de búsqueda resuelve
+**búsqueda de texto + conteo de facetas**, no reemplaza la fuente de
+la jerarquía.
+
+## 4. Diseño de sincronización
+
+Mismo patrón que `revalidate-storefront.ts`, no uno nuevo: un
+subscriber adicional en `commerce-backend/src/subscribers/` (ej.
+`sync-search-index.ts`) que reacciona a eventos y le pide al plugin
+que reindexe el documento afectado — nunca Medusa escribiendo
+directamente en Meilisearch fuera de este canal.
+
+Eventos a escuchar, confirmados en la documentación oficial de
+eventos de Medusa (`docs.medusajs.com/resources/events-reference`):
+
+- `product.created` / `product.updated` / `product.deleted`
+- `product-variant.created` / `product-variant.updated` / `product-variant.deleted`
+  (mismo set que ya usa `revalidate-storefront.ts`, hoy validado en
+  producción)
+- **Nuevo respecto al subscriber actual:** `product-category.created`
+  / `product-category.updated` / `product-category.deleted` — un
+  cambio de nombre o jerarquía de categoría debe refrescar las
+  facetas del índice, y hoy `revalidate-storefront.ts` no escucha
+  estos eventos porque el storefront los resuelve en cada request
+  contra `/store/product-categories` directamente, sin necesidad de
+  revalidación. El índice de búsqueda sí necesita enterarse.
+
+**Punto a verificar en vivo en Etapa 2, no asumido aquí:** existe al
+menos un reporte público de un evento `product-collection.updated`
+que no se disparaba de forma confiable en ciertas versiones de Medusa
+(`github.com/medusajs/medusa/issues/11197`). Antes de dar por cerrado
+el diseño de sincronización hay que repetir exactamente la validación
+que ya se hizo para `revalidate-storefront.ts` en la auditoría de
+Etapa 1 de Fase 5: crear/editar una categoría real vía Admin y
+confirmar en vivo que el evento llega al subscriber, no confiar en que
+la documentación coincide con el comportamiento real de `2.18.0`
+(el mismo tipo de brecha que ya se encontró una vez con la relación
+`+categories` de `/store/products`).
+
+## 5. Diseño de UI — filtros facetados y búsqueda
+
+**Filtros facetados (sidebar de `/catalog`):** mismo layout que ya
+construyó la sub-fase 3 (`catalog-client.tsx`, PR #40) — sidebar con
+"Categoría"/"Marca"/"Edad" como pills con conteo entre paréntesis y
+slider de precio máximo. Lo único que cambia es **de dónde sale el
+conteo**: hoy `categoryCounts`/`brandCounts`/`ageCounts` se calculan
+recorriendo el arreglo de productos ya traído en el cliente; con el
+motor de búsqueda, esos conteos vienen del propio Meilisearch
+(`facetDistribution`) en la misma respuesta que trae los productos
+filtrados, sin recorrer nada en el navegador. El breadcrumb no cambia
+— sigue resolviéndose contra la jerarquía real de categorías, no
+contra el índice de búsqueda.
+
+```
+Inicio > Mochilas y morrales > Marvel                 breadcrumb real (sin cambios)
+┌────────────┬──────────────────────────────────────┐
+│ Categoría  │  [buscador con autocompletado]        │  ← nuevo
+│ ☐ Marvel(6)│  [card][card][card]                   │
+│ ☐ Frozen(4)│  [card][card][card]                   │
+│ Marca      │                                        │
+│ ☐ Disney(2)│  conteos ahora vienen de Meilisearch,  │
+│ Precio     │  no de recorrer el arreglo en cliente  │
+│ [====○===] │                                        │
+└────────────┴──────────────────────────────────────┘
+```
+
+**Búsqueda con autocompletado (barra del navbar):** hoy
+`PredictiveSearch` (`components/search/predictive-search.tsx`) filtra
+por substring sobre los productos ya cargados en memoria del cliente —
+funciona a 26 productos, no escala y no tolera errores de tipeo (ADR
+0004, hallazgo #5). Se reemplaza la fuente de datos del mismo
+componente visual por `searchProducts(query)` del `CatalogProvider`
+(interfaz que **ya existe** en `lib/headless/types.ts`, sin necesidad
+de un tipo nuevo) apuntando a Meilisearch en vez de al `?q=` de
+Medusa: tolerancia a typos y ranking por relevancia nativos del motor,
+mismo contrato de datos que ya consume el dropdown de resultados —
+cero cambio de componente React, solo de qué hay detrás de
+`CatalogProvider.searchProducts`.
+
+## Opciones consideradas
+
+| Opción | A favor | En contra |
+|---|---|---|
+| **Meilisearch autohospedado** (`@rokmohar/medusa-plugin-meilisearch@^1.4.1`, sincronizado por eventos) | Plugin comunitario activo y compatible con nuestra versión exacta de Medusa (2.18); menor huella de RAM que la alternativa evaluada; almacenamiento memory-mapped se degrada en vez de fallar bajo presión de memoria; mismo patrón de subscriber que `revalidate-storefront.ts`, cero riesgo para ese flujo | Ningún paquete "oficial" de Medusa (el plugin es comunitario, no del core); atado a la línea `v1` del plugin mientras no se suba Medusa a 2.19+; un servicio más para operar en un host ya con swap saturado |
+| **Typesense autohospedado** | Autocompletado ~2x más rápido según benchmarks públicos | Cero integración con Medusa (habría que escribir la sincronización completa desde cero, igual esfuerzo que la guía "custom" de Meilisearch pero sin base comunitaria); ~30% más RAM que Meilisearch para el mismo dataset, el peor trade-off posible dado el estado actual del host |
+| **Módulo custom desde cero** (seguir la guía oficial de Medusa, sin el plugin de rokmohar) | Sin dependencia de un paquete de terceros; control total | Reimplementa lo que el plugin comunitario ya resuelve (declaración de índices, reindexado atómico, tracking de escrituras); más superficie propia para mantener sin ganancia clara sobre usar el plugin ya compatible con 2.18 |
+| **No adoptar motor de búsqueda todavía** (seguir con filtrado 100% client-side) | Cero riesgo, cero componente nuevo | No resuelve la deuda de facetas ya identificada en ADR 0004 y agravada por la sub-fase 3; el techo de complejidad de filtros llega antes que el de 100 productos si el catálogo sigue creciendo en categorías |
+
+## Decisión
+
+**Meilisearch autohospedado**, vía `@rokmohar/medusa-plugin-meilisearch@^1.4.1`
+(no la última versión del plugin — esa exige Medusa 2.19+, fuera de
+alcance), sincronizado por el mismo patrón de subscriber por eventos
+que ya usa `revalidate-storefront.ts`, con `product-category.*` sumado
+al set de eventos existente. Se despliega en k3d con límites de
+recursos conservadores desde el primer día y se trata como
+experimento a monitorear, no como capacidad garantizada, dado el
+estado actual de memoria del host.
+
+**No se sube la versión de Medusa como parte de esta decisión** —
+queda como deuda técnica documentada para cuando se justifique
+migrar a la línea `v2` del plugin y al Search Module nativo de
+Medusa.
+
+## Consecuencias
+
+- Se gana: conteo de facetas real (no client-side), búsqueda tolerante
+  a errores de tipeo con ranking por relevancia, y una arquitectura
+  que ya no depende del techo de 100 productos de `fetchProducts`.
+- Se acepta como deuda técnica: quedar atado a la línea `v1` del
+  plugin de Meilisearch mientras Medusa siga en `2.18.x`; migrar a
+  Medusa `2.19+` es un proyecto aparte, no parte de esta Etapa 3.
+- Riesgo operativo real y no resuelto todavía por este ADR: el host ya
+  corre con el swap saturado — el despliegue de Etapa 2 debe empezar
+  con límites de recursos conservadores y validación en vivo de
+  consumo real antes de confiar en el servicio, siguiendo la misma
+  lección que dejó el incidente de recursos de Gitea.
+- Revertir esta decisión implica desinstalar el plugin y el
+  subscriber nuevo, y volver el buscador/filtrado a 100% client-side
+  — no hay migración de datos que deshacer, porque Meilisearch nunca
+  es la fuente de verdad, solo una copia de solo lectura indexada
+  desde Medusa.
+
+## Nota de implementación (2026-08-26, antes de escribir código de Etapa 2)
+
+Antes de tocar código se verificó el código fuente real de
+`@rokmohar/medusa-plugin-meilisearch` en el tag exacto `v1.4.1`
+(`github.com/rokmohar/medusa-plugin-meilisearch`), no su README
+genérico ni memoria de entrenamiento — misma disciplina que ya destapó
+el bug de `+categories` en `/store/products`. Aparecieron tres
+desviaciones reales respecto al diseño de §4/§5 de este ADR:
+
+1. **No se escribe un subscriber nuevo.** El plugin trae sus propios
+   subscribers (`meilisearch-product-upsert.ts`,
+   `meilisearch-category-upsert.ts`, variantes/colección/inventario),
+   auto-registrados al instalar el paquete — el propio README dice
+   *"You don't need custom subscribers anymore, you can remove them."*
+   Escribir `sync-search-index.ts` como describe §4 causaría doble
+   indexado. La escucha de `product-category.*` que pedía §4 ya viene
+   incluida en los subscribers del plugin.
+2. **Las rutas Store API del plugin no devuelven `facetDistribution`**,
+   pese a que §5 asume que sí. El servicio interno
+   (`MeiliSearchService.search()`) sí puede pedirlo vía
+   `additionalOptions: { facets: [...] }`, pero las rutas
+   empaquetadas nunca lo piden ni lo reenvían. Se agrega una ruta
+   Store API propia (`src/api/store/search/route.ts`) que resuelve el
+   servicio del plugin desde el container y arma
+   `{ products, facetDistribution }`. Consecuencia positiva no
+   buscada: Meilisearch queda 100% `ClusterIP`-only, sin Ingress, sin
+   key pública ni ruta de red navegador→Meilisearch — todo pasa por
+   Medusa.
+3. **El plugin se conecta vía un array `plugins:` nuevo en
+   `medusa-config.ts`**, no otra entrada en `modules:` (el único
+   precedente en este repo, el file-provider S3, usa `modules:`), y
+   usa nombres de env var propios (`MEILISEARCH_HOST`/
+   `MEILISEARCH_API_KEY`, leídos por el plugin) distintos del env var
+   del servidor Meilisearch en sí (`MEILI_MASTER_KEY`, leído por el
+   contenedor `getmeili/meilisearch`) — mismo valor, dos nombres de
+   secret.
+
+Ninguna de las tres cambia la decisión ni sus consecuencias — cambian
+el cómo, no el qué. Plan de implementación completo, fase por fase,
+en la sesión que aprobó esta Etapa 2 (2026-08-26).

workloads/docs-portal/mkdocs.yml

@@ -92,6 +92,7 @@ nav:
       - "0003 · HTTP/2 sobre QUIC": decisiones/0003-por-que-http2-sobre-quic-tunnel.md
       - "0004 · Stack multi-categoría": decisiones/0004-evaluacion-stack-multi-categoria.md
       - "0005 · Rediseño storefront": decisiones/0005-rediseno-storefront.md
+      - "0006 · Motor de búsqueda y facetas": decisiones/0006-motor-busqueda-facetas.md
       - Plantilla ADR: decisiones/plantilla-adr.md
   - Playbooks:
       - Crashloop Medusa: playbooks/incidente-crashloop-medusa.md

workloads/docs-portal/patches/deployment.yaml

@@ -25,7 +25,7 @@ spec:
         runAsNonRoot: false
       containers:
         - name: app
-          image: gitea.cruzcloud.net/devops/docs-portal:v1.0.159
+          image: gitea.cruzcloud.net/devops/docs-portal:v1.0.164
           # El base saca TODAS las capabilities. Probado en vivo y
           # revertido: con drop: ALL (aunque se agregue NET_BIND_SERVICE
           # de vuelta) el propio entrypoint de nginx:1.27-alpine falla al

workloads/ecommerce/commerce/configmap.yaml

@@ -19,3 +19,8 @@ data:
   S3_ENDPOINT: http://minio-svc:9000
   S3_REGION: us-east-1
   S3_BUCKET: ari-products
+
+  # Leido por el plugin @rokmohar/medusa-plugin-meilisearch (nombre de
+  # env var del plugin, no del servidor Meilisearch en si -- ver
+  # MEILI_MASTER_KEY en secrets.template.yaml).
+  MEILISEARCH_HOST: http://meilisearch-svc:7700

workloads/ecommerce/commerce/ingress-commerce.yaml

@@ -4,6 +4,7 @@ metadata:
   name: commerce-ingress
   annotations:
     traefik.ingress.kubernetes.io/router.entrypoints: web
+    traefik.ingress.kubernetes.io/router.middlewares: ecommerce-commerce-redirect-app@kubernetescrd
 spec:
   ingressClassName: traefik
   rules:

workloads/ecommerce/commerce/kustomization.yaml

@@ -7,5 +7,7 @@ resources:
   - redis.yaml
   - minio.yaml
   - minio-bootstrap-job.yaml
+  - meilisearch.yaml
   - medusa/
   - ingress-commerce.yaml
+  - middleware-commerce-redirect.yaml

workloads/ecommerce/commerce/medusa/patches/deployment.yaml

@@ -65,7 +65,7 @@ spec:
               memory: 64Mi
 
         - name: migrations
-          image: gitea.cruzcloud.net/devops/ecommerce-medusa:v1.0.127
+          image: gitea.cruzcloud.net/devops/ecommerce-medusa:v1.0.166
           imagePullPolicy: IfNotPresent
           command:
             - node
@@ -86,7 +86,7 @@ spec:
 
       containers:
         - name: app
-          image: gitea.cruzcloud.net/devops/ecommerce-medusa:v1.0.127
+          image: gitea.cruzcloud.net/devops/ecommerce-medusa:v1.0.166
           imagePullPolicy: IfNotPresent
           envFrom:
             - configMapRef:

workloads/ecommerce/commerce/meilisearch.yaml

@@ -0,0 +1,86 @@
+apiVersion: v1
+kind: Service
+metadata:
+  name: meilisearch-svc
+spec:
+  selector:
+    app: commerce-meilisearch
+  ports:
+    - name: http
+      port: 7700
+      targetPort: 7700
+---
+apiVersion: apps/v1
+kind: StatefulSet
+metadata:
+  name: commerce-meilisearch
+spec:
+  serviceName: meilisearch-svc
+  replicas: 1
+  selector:
+    matchLabels:
+      app: commerce-meilisearch
+  template:
+    metadata:
+      labels:
+        app: commerce-meilisearch
+    spec:
+      terminationGracePeriodSeconds: 30
+      containers:
+        - name: meilisearch
+          image: getmeili/meilisearch:v1.53.1
+          imagePullPolicy: IfNotPresent
+          env:
+            - name: MEILI_MASTER_KEY
+              valueFrom:
+                secretKeyRef:
+                  name: commerce-secrets
+                  key: MEILI_MASTER_KEY
+            - name: MEILI_ENV
+              value: production
+            # Sin telemetria a un tercero por defecto (misma postura del
+            # resto del namespace: nada de egress no explicado).
+            - name: MEILI_NO_ANALYTICS
+              value: "true"
+          ports:
+            - name: http
+              containerPort: 7700
+          # /health no requiere auth (confirmado en vivo) -- sirve tal
+          # cual para las dos probes, igual que minio usa sus propios
+          # endpoints /minio/health/*.
+          readinessProbe:
+            httpGet:
+              path: /health
+              port: http
+            initialDelaySeconds: 5
+            periodSeconds: 10
+            timeoutSeconds: 5
+            failureThreshold: 6
+          livenessProbe:
+            httpGet:
+              path: /health
+              port: http
+            initialDelaySeconds: 15
+            periodSeconds: 20
+            timeoutSeconds: 5
+            failureThreshold: 6
+          resources:
+            requests:
+              cpu: 100m
+              memory: 256Mi
+            limits:
+              cpu: 500m
+              memory: 768Mi
+          volumeMounts:
+            - name: meilisearch-data
+              mountPath: /meili_data
+  volumeClaimTemplates:
+    - metadata:
+        name: meilisearch-data
+      spec:
+        accessModes:
+          - ReadWriteOnce
+        storageClassName: local-path
+        resources:
+          requests:
+            storage: 5Gi

workloads/ecommerce/commerce/middleware-commerce-redirect.yaml

@@ -0,0 +1,16 @@
+apiVersion: traefik.io/v1alpha1
+kind: Middleware
+metadata:
+  name: commerce-redirect-app
+spec:
+  # Redirige solo la raíz exacta de commerce.cruzcloud.net a /app (admin de
+  # Medusa) — el regex incluye el host a propósito: esta Middleware se
+  # referencia desde el mismo Ingress que también enruta media.cruzcloud.net,
+  # y sin el host en el regex un request a la raíz de ese otro dominio
+  # también matchearía (ambas rutas comparten Ingress -> mismas
+  # router.middlewares). Si el regex no matchea, Traefik deja pasar el
+  # request sin modificarlo.
+  redirectRegex:
+    regex: "^https?://commerce\\.cruzcloud\\.net/$"
+    replacement: "https://commerce.cruzcloud.net/app"
+    permanent: true

workloads/ecommerce/commerce/secrets.template.yaml

@@ -23,6 +23,14 @@ stringData:
   JWT_SECRET: CAMBIAR
   COOKIE_SECRET: CAMBIAR
 
+  # Master key del servidor Meilisearch (StatefulSet commerce-meilisearch,
+  # env MEILI_MASTER_KEY del propio contenedor getmeili/meilisearch) Y
+  # credencial que usa el plugin de Medusa para autenticarse contra el
+  # -- MISMO valor, dos nombres de secret porque cada lado (servidor vs.
+  # plugin cliente) usa su propia convencion de nombre de env var.
+  MEILI_MASTER_KEY: CAMBIAR
+  MEILISEARCH_API_KEY: CAMBIAR
+
   # Debe ser el MISMO valor que REVALIDATE_SECRET en el Secret
   # commerce-storefront: el subscriber de Medusa lo envía como header
   # x-revalidate-secret al invocar POST /api/revalidate en el storefront.