fix(product-import): crear categoría/colección si no existe en vez de descartarla en silencio

El importador solo enlazaba categoría/colección cuando el nombre del CSV
matcheaba exacto (case-insensitive) una ya existente -- si no había match,
category_ids/collection_id quedaban undefined sin ningún error. Así quedó
el producto "Hello Kitty & Friends" importado sin colección: la colección
nunca existió en la tienda, el importador nunca la creó ni avisó.

Ahora, si el nombre no matchea, se crea la categoría/colección nueva
(createProductCategoriesWorkflow / createCollectionsWorkflow) con el mismo
slugify() ASCII-safe que ya usa el handle del producto, por la misma razón:
el default de Medusa no quita tildes/eñes y rompe la ruta pública.

El producto ya importado se corrigió en caliente vía Admin API (colección
creada + enlazada + handle corregido de "hello-kitty-&-friends" a
"hello-kitty-friends"), sin esperar este deploy.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01THZFwPzrwv6VAbuwmaf5vR

workloads/commerce-backend/src/api/admin/product-import/route.ts

@@ -7,7 +7,9 @@ import type {
   IStockLocationService,
 } from "@medusajs/framework/types";
 import {
+  createCollectionsWorkflow,
   createInventoryItemsWorkflow,
+  createProductCategoriesWorkflow,
   createProductsWorkflow,
   uploadFilesWorkflow,
 } from "@medusajs/medusa/core-flows";
@@ -20,6 +22,15 @@ import { csvRowsToObjects, parseCsv } from "../../../lib/csv";
 // fila se procesa independiente (una foto rota o categoria mal escrita
 // no tumba el resto del archivo).
 //
+// categoria/coleccion: si el nombre no matchea una categoria/coleccion
+// ya existente (case-insensitive), se crea nueva -- antes se descartaba
+// en silencio y el producto quedaba sin categoria/coleccion sin avisar
+// (confirmado en vivo: "Hello Kitty & Friends" nunca se creo como
+// coleccion). El handle de la nueva categoria/coleccion se genera con
+// el mismo slugify() ASCII-safe de mas abajo, por la misma razon que el
+// handle del producto: el default de Medusa no quita tildes/enies y
+// rompe la ruta publica.
+//
 // Las fotos se descargan del origen y se re-alojan en el mismo
 // MinIO/S3 que ya usa el resto del catalogo (uploadFilesWorkflow ->
 // mismo File Module Provider de medusa-config.ts, ya corre en el NAS).
@@ -53,6 +64,28 @@ type RowResult = {
   error?: string;
 };
 
+// Medusa genera el handle por defecto solo en minusculas + espacios a
+// guiones, sin quitar tildes/enies -- confirmado en vivo: 3 productos
+// importados con titulo acentuado (ej. "niñas", "Lógicos") quedaron con
+// handle como "...niñas..." y daban 404 real al entrar por
+// shop.cruzcloud.net (el tunel/ingress publico rompe rutas con UTF-8
+// no-ASCII en el path, aunque el mismo request funciona perfecto pegandole
+// directo al servicio dentro del cluster). Se genera el handle nosotros
+// mismos, ASCII-only, en vez de dejarselo al default de Medusa. El sufijo
+// corto evita colisiones entre titulos parecidos/repetidos sin necesidad
+// de revisar unicidad antes de crear.
+function slugify(title: string, uniquePart: string): string {
+  const base = title
+    .normalize("NFD")
+    .replace(/[̀-ͯ]/g, "")
+    .toLowerCase()
+    .replace(/[^a-z0-9]+/g, "-")
+    .replace(/^-+|-+$/g, "")
+    .slice(0, 80)
+    .replace(/-+$/g, "");
+  return `${base || "producto"}-${uniquePart}`;
+}
+
 function extensionFromContentType(contentType: string | null, url: string): string {
   if (contentType?.includes("png")) return "png";
   if (contentType?.includes("webp")) return "webp";
@@ -193,14 +226,40 @@ export async function POST(req: MedusaRequest<{ csv: string }>, res: MedusaRespo
       const inventoryItemId = inventoryItems[0]?.id;
       if (!inventoryItemId) throw new Error("No se pudo crear el registro de inventario");
 
-      const categoryId = row.categoria ? categoryByName.get(row.categoria.toLowerCase().trim()) : undefined;
-      const collectionId = row.coleccion ? collectionByName.get(row.coleccion.toLowerCase().trim()) : undefined;
+      const categoryName = row.categoria?.trim();
+      let categoryId = categoryName ? categoryByName.get(categoryName.toLowerCase()) : undefined;
+      if (categoryName && !categoryId) {
+        const { result: createdCategories } = await createProductCategoriesWorkflow(req.scope).run({
+          input: {
+            product_categories: [
+              { name: categoryName, handle: slugify(categoryName, `${Date.now().toString(36)}${index}`) },
+            ],
+          },
+        });
+        categoryId = createdCategories[0].id;
+        categoryByName.set(categoryName.toLowerCase(), categoryId);
+      }
+
+      const collectionName = row.coleccion?.trim();
+      let collectionId = collectionName ? collectionByName.get(collectionName.toLowerCase()) : undefined;
+      if (collectionName && !collectionId) {
+        const { result: createdCollections } = await createCollectionsWorkflow(req.scope).run({
+          input: {
+            collections: [
+              { title: collectionName, handle: slugify(collectionName, `${Date.now().toString(36)}${index}`) },
+            ],
+          },
+        });
+        collectionId = createdCollections[0].id;
+        collectionByName.set(collectionName.toLowerCase(), collectionId);
+      }
 
       await createProductsWorkflow(req.scope).run({
         input: {
           products: [
             {
               title,
+              handle: slugify(title, `${Date.now().toString(36)}${index}`),
               description: row.descripcion || undefined,
               status: "published",
               thumbnail: uploadedFiles[0]?.url,

workloads/docs-portal/docs/arquitectura/sesion-tmux-persistente.md

@@ -37,6 +37,9 @@ flowchart LR
     SSH["Cliente SSH<br/>(laptop / tablet / lo que sea)"] -->|docker exec| C["Contenedor tmux-host<br/>--network host, --restart unless-stopped"]
     C --> T["tmux server<br/>sesión 'lab'"]
     T --> CC["proceso claude<br/>(Claude Code)"]
+    C --> HC["healthcheck.sh (background)<br/>cada 30 min"]
+    HC -.->|curl| NET["gitea.cruzcloud.net"]
+    HC -.->|recrea si falta| T
     C -.->|bind mount| DATA["/DATA (host)<br/>repos y configs del lab"]
     C -.->|bind mount| SOCK["/var/run/docker.sock (host)<br/>control de Docker/k3d"]
     C -.->|bind mount| HOME["/DATA/AppData/k3d-lab-v3/claude-code-home (host)<br/>-> /root/.claude"]
@@ -49,7 +52,17 @@ reinicia.
 
 ## Contenedor: `tmux-host`
 
+La imagen se construye desde `scripts/tmux-host/Dockerfile` (antes era
+un `docker run ... alpine sh -c "apk add ..."` inline — mismo contenido,
+pero ahora como imagen versionada en vez de reinstalar todo en cada
+arranque). El Dockerfile fija `WORKDIR /DATA/AppData/k3d-lab-v3/lab-cruzcloud`
+(la raíz del lab, con `CLAUDE.md`, `apps-registry/`, `platform-infra/` y
+`scripts/`) y agrega `healthcheck.sh` (ver más abajo) como proceso en
+background del contenedor.
+
 ```bash
+docker build -t tmux-host:local scripts/tmux-host
+
 docker run -d \
   --name tmux-host \
   --restart unless-stopped \
@@ -59,9 +72,15 @@ docker run -d \
   -v /DATA/AppData/k3d-lab-v3/claude-code-home:/root/.claude \
   -v /DATA/AppData/k3d-lab-v3/claude-code-home.json:/root/.claude.json \
   --network host \
-  alpine sh -c "apk add --no-cache tmux docker-cli bash curl git kubectl nodejs npm && npm install -g @anthropic-ai/claude-code && git config --global --add safe.directory '*' && tail -f /dev/null"
+  tmux-host:local
 ```
 
+`WORKDIR` hace que `docker exec` (y por lo tanto `lab-session.sh`)
+arranquen ya posicionados en la raíz del lab sin tener que navegar a
+mano — `lab-session.sh` además pasa la ruta explícita vía `tmux new -c`
+por las dudas, para no depender de que `docker exec` herede el `WORKDIR`
+de la imagen.
+
 | Volumen | Destino | Por qué |
 |---|---|---|
 | `/DATA` | `/DATA` | Acceso a los repos (`apps-registry`, `platform-infra`, `scripts`) y configs del lab, mismos paths que en el host |
@@ -195,13 +214,47 @@ Si la sesión `lab` existe, se adjunta a ella (mismo shell, mismo
 ejemplo justo después de que el contenedor se recreó desde cero— la
 crea. No hay que recordar cuál de los dos casos aplica.
 
+## Chequeo de salud automático (cada 30 min)
+
+`scripts/tmux-host/healthcheck.sh` corre en background dentro del
+propio contenedor (lanzado por `entrypoint.sh`, el `ENTRYPOINT` de la
+imagen) y cada `HEALTHCHECK_INTERVAL_SEC` (1800s por defecto) hace dos
+chequeos independientes, con una respuesta distinta según el tipo de
+falla:
+
+- **Conectividad de red real** (`curl` a `https://gitea.cruzcloud.net/`):
+  si falla, **solo se registra** en el log y se notifica por Telegram —
+  el contenedor nunca intenta "arreglar" la red del host. Un problema de
+  red puede ser de hardware/BIOS (deuda técnica ya conocida, ver
+  `incidente-medusa-crashloop-2026-08.md`), fuera del alcance real de un
+  contenedor.
+- **Existencia de la sesión tmux `lab`** (`tmux has-session`): si no
+  existe, **sí se recrea automáticamente** (`tmux new-session -d -s lab
+  -c <WORKDIR>`) — es solo recuperar el propio entorno de trabajo del
+  contenedor, no tocar infraestructura externa, así que es seguro
+  hacerlo sin intervención humana.
+
+Todo evento (chequeo ok, falla de red, sesión recreada) queda en
+`/DATA/AppData/k3d-lab-v3/tmux-host/logs/health.log` — persistente en
+`/DATA`, no solo en el stdout del contenedor (que se pierde con
+`docker logs` al recrearlo). Las notificaciones de Telegram reusan el
+mismo bot/`chat_id` ya configurado para `scripts/lab-agent/`
+(`lab-agent.env`), en vez de duplicar credenciales entre los dos
+agentes del lab.
+
+Para probar el intervalo sin esperar 30 minutos, se puede levantar el
+contenedor con `-e HEALTHCHECK_INTERVAL_SEC=60` (solo para pruebas en un
+contenedor descartable — nunca cambiar esto en el `tmux-host` real sin
+volver a 1800 después).
+
 ## Qué sobrevive a qué
 
 | Evento | ¿Sobrevive la sesión tmux (`lab`)? | ¿Sobrevive el login de Claude Code? |
 |---|---|---|
 | Corte de SSH / cerrar la terminal / cambiar de dispositivo | Sí — es exactamente el caso que este setup resuelve | Sí |
-| `docker restart tmux-host` (reinicio del NAS) | **No** — el proceso `tmux server` muere con el contenedor; `lab-session.sh` crea una sesión nueva automáticamente | Sí, vía el volumen montado en `/root/.claude` |
-| `docker rm` + recrear el contenedor desde cero | No | Sí, vía el mismo volumen — no hace falta volver a autenticar ni reconfirmar el diálogo de confianza del folder (ver el mount de `claude-code-home.json`) |
+| `docker restart tmux-host` (reinicio del NAS) | **No al toque, pero se auto-recupera solo** — el proceso `tmux server` muere con el contenedor; `healthcheck.sh` la recrea en el próximo ciclo (máx. 30 min) sin intervención, o `lab-session.sh` la crea al instante si alguien se reconecta antes | Sí, vía el volumen montado en `/root/.claude` |
+| `docker rm` + recrear el contenedor desde cero | No, pero igual se auto-recupera sola (mismo mecanismo de arriba) | Sí, vía el mismo volumen — no hace falta volver a autenticar ni reconfirmar el diálogo de confianza del folder (ver el mount de `claude-code-home.json`) |
+| Falla de red real del host/NAS | N/A | N/A — `healthcheck.sh` la detecta y notifica, pero no la corrige (fuera de su alcance) |
 
 ## Validación en vivo
 

workloads/docs-portal/docs/decisiones/0008-identidad-navy-coral.md

@@ -1,9 +1,18 @@
 # ADR 0008 — Identidad visual "Navy & Coral" para ARI Shopping
 
-**Estado:** aceptada (implementación en curso, por sub-fases)
-**Fecha:** 2026-08-27
+**Estado:** aceptada, con enmienda de paleta (ver §8) — sub-fases 1 a 4
+completas, sub-fase 5 parcial (ver §9)
+**Fecha:** 2026-08-27 (enmendada 2026-09-06)
 **Reemplaza a:** [ADR 0007](0007-identidad-visual-propia.md) (Opción 2, "Atelier cálido")
 
+> **Nota de vigencia:** la paleta descrita en §4 ("Navy & Coral":
+> marino `#122844` / coral `#D85A30` / coral claro `#F0997B`) fue la
+> dirección **aprobada e implementada en las sub-fases 1-3**, pero fue
+> **reemplazada el mismo día** por una paleta azul/amarillo estilo
+> Walmart (rama `fix/adr0008-walmart-palette-blue-yellow`, ver §8). Los
+> valores reales en producción hoy están en §8, no en §4. Se deja §4
+> intacto como registro histórico de la decisión original.
+
 ## 1. Contexto
 
 Este es el tercer intento de identidad visual propia para ARI Shopping,
@@ -168,3 +177,66 @@ definitivo; los alias se eliminan por completo al cerrar la sub-fase
   `commerce-backend`, `platform-infra`, ni CI nuevo.
 - `docs-portal` se actualiza con capturas/descripción del resultado
   final una vez cada sub-fase esté validada en producción, no antes.
+
+## 8. Enmienda 2026-08-27 tarde: pivote de paleta a azul/amarillo
+
+Horas después de mergear la sub-fase 3 (product card + grid), se
+mergeó `fix/adr0008-walmart-palette-blue-yellow`: la paleta "Navy &
+Coral" de §4 se descartó en producción y se reemplazó por una paleta
+azul/amarillo (mismo patrón "estética Walmart" ya usado como
+referencia de UX en ADR 0007). Esta decisión **no quedó documentada
+como enmienda en su momento** — se detecta y se registra aquí recién
+el 2026-09-06, al auditar el estado real del código contra este
+documento.
+
+Valores reales en `globals.css` hoy (los nombres de token de §4 se
+conservan, pero apuntan a estos valores, no a los de la tabla
+original):
+
+| Token | Valor real | Uso |
+|---|---|---|
+| `--color-ari-marino` | `#0055B8` (azul) | ancla: header, footer, fondo de hero, botón de búsqueda |
+| `--color-ari-coral` | `#0055B8` (azul, mismo valor que marino) | CTA "Agregar al carrito", precio destacado |
+| `--color-ari-coral-claro` | `#FFC220` (amarillo) | badges de oferta/urgencia, acento del isotipo, botón "yellow" del hero |
+
+Nota: `ari-coral` y `ari-marino` son el mismo azul (`#0055B8`) — a
+diferencia de la especificación original de §4, donde marino y coral
+eran colores distintos. Cualquier lectura de este ADR para decisiones
+de diseño futuras debe partir de esta tabla, no de §4.
+
+El isotipo (mariposa de 4 elipses, §4) tampoco se implementó como se
+describe: el logo vigente es `logo-ari-circular.svg` (rama
+`adr0008-logo-circular-header`), un lockup circular distinto al
+descrito en la tabla de coordenadas de §4. `logo-ari.svg` (rectangular,
+el que sí sigue la spec original) quedó sin usarse en el header.
+
+## 9. Estado real por sub-fase (auditado 2026-09-06)
+
+Auditoría contra el código en `main`, no contra el plan de §6.
+
+| # | Sub-fase | Estado | Evidencia |
+|---|---|---|---|
+| 1 | Tokens base + logo | ✅ completa (con la paleta enmendada en §8, no la de §4) | `globals.css`, `logo-ari.svg` inicial, luego reemplazado por circular en sub-fase posterior |
+| 2 | Header + footer (incl. limpieza de §5) | ✅ completa | `navbar.tsx`, restos arcoíris (gradiente ámbar/lima, línea cian/violeta/fucsia de §5) eliminados |
+| 3 | Product card + grid + badges | ✅ completa | `product-card.tsx` en tokens `ari-*` |
+| 4 | Home (hero, tiles, secciones) | ✅ completa | `hero-carousel.tsx`, `category-tiles.tsx` (varias iteraciones: pastel → scrim → foto flotante → foto más grande, todas mergeadas) |
+| 5 | Página de producto + drawers de carrito/wishlist | ⚠️ **parcial** | `product-purchase.tsx`/página de producto sí migraron (rama `adr0008-product-purchase-mobile-y-badge`). **`cart-drawer.tsx` y `wishlist-drawer.tsx` no tienen ningún token `ari-*` — nunca se tocaron.** No hay rama mergeada que los mencione. |
+
+**Deuda abierta, no asumir resuelta:**
+
+- Los alias de compatibilidad de §6 (`ari-ciruela`, `ari-cobre`,
+  `ari-carbon`, `ari-carbon-oscuro`, `ari-terracota-oscuro`,
+  `ari-hueso`) **siguen en uso real en `button.tsx`**
+  (`focus-visible:ring-ari-cobre/40`, `bg-ari-ciruela`,
+  `hover:border-ari-cobre`) — la condición de cierre de §6 ("los alias
+  se eliminan por completo al cerrar la sub-fase 5") no se cumplió.
+  Confirma que la sub-fase 5 no está cerrada, más allá de los drawers.
+- Ramas mergeadas fuera del plan original de 5 sub-fases de §6, sin
+  enmienda que las registre: `adr0008-megamenu-mobile-overflow`,
+  `adr0008-club-ari-y-novedades`, `adr0008-club-ari-imagen-azul`. Son
+  trabajo real en producción, pero expanden el alcance de este ADR sin
+  quedar documentado como tal.
+- `docs-portal` (este documento) es la primera actualización desde el
+  cierre de la sub-fase 3 — la condición de §7 ("se actualiza con
+  capturas/descripción... una vez cada sub-fase esté validada") no se
+  vino cumpliendo sub-fase por sub-fase como se planeó.

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.207
+          image: gitea.cruzcloud.net/devops/docs-portal:v1.0.224
           # 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/medusa/patches/deployment.yaml

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