chore(gitops): deploy Docs Portal v1.0.283 [skip ci]

El segundo reinicio real del NAS confirmo que /etc/sysctl.d/99-disable-ipv6.conf
se aplica al arrancar (disable_ipv6=1 sin sysctl -p manual). Se cierran
todos los pendientes del playbook y se reescribe la lista sin sintaxis de
tasklist/tachado, que el portal renderizaba literal.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_018r19s4H8MBGegqToqw5guP

.gitea/workflows/build.yaml

@@ -126,8 +126,20 @@ jobs:
 
     env:
       APP_DIR: workloads/ecommerce
-      MANIFEST_FILE: workloads/ecommerce/frontend/patches/deployment.yaml
+      # Cambio 2026-09-14: todo push a main promueve a STAGING
-      KUSTOMIZE_DIR: workloads/ecommerce/frontend
+      # automaticamente (workloads/ecommerce-staging), no a Produccion
+      # directo -- decision del usuario para dejar de probar cambios en
+      # vivo contra Prod.
+      # Cambio 2026-09-20: la promocion de Staging a Produccion (antes
+      # scripts/promote-to-production.sh, manual con confirmacion
+      # interactiva) ahora corre sola en este mismo job -- ver el step
+      # "Promover a Produccion (CD)" mas abajo, justo despues del de
+      # Staging. Decision explicita del usuario: cero gate humano entre
+      # Staging y Produccion. El script manual queda solo como
+      # herramienta de rollback/excepcion, ya no es el camino normal.
+      MANIFEST_FILE: workloads/ecommerce-staging/frontend/patches/deployment.yaml
+      PROD_MANIFEST_FILE: workloads/ecommerce/frontend/patches/deployment.yaml
+      KUSTOMIZE_DIR: workloads/ecommerce-staging/frontend
       IMAGE_NAME: gitea.cruzcloud.net/devops/ecommerce-frontend
 
     steps:
@@ -579,6 +591,13 @@ jobs:
 
           sed -i -E             "s|(image: ${IMAGE_NAME}:).*|\1${VERSION}|g"             "${MANIFEST_FILE}"
 
+          # El footer (workloads/ecommerce/components/layout/footer.tsx) lee
+          # process.env.APP_VERSION para mostrar la versión real desplegada
+          # -- este bump la mantiene igual al tag de la imagen de arriba.
+          # -0777 (slurp): el nombre y el valor están en líneas distintas del
+          # YAML, un sed de una sola línea no puede verlos juntos.
+          perl -0777 -pi -e "s/(- name: APP_VERSION\n\s*value: ).*/\${1}${VERSION}/"             "${MANIFEST_FILE}"
+
           git add "${MANIFEST_FILE}"
 
           if git diff --cached --quiet; then
@@ -592,6 +611,48 @@ jobs:
           # sobrescribir commits ajenos o promocionar una versión antigua.
           git push origin HEAD:main
 
+      # Automatiza lo que antes era scripts/promote-to-production.sh (paso
+      # manual con confirmación interactiva, read -rp). Decisión del
+      # usuario 2026-09-20: cero pasos manuales entre Staging y
+      # Producción — la misma imagen que acaba de promocionar a Staging
+      # arriba se promueve sola a Producción, sin gate humano en el
+      # medio. Mismo sed/perl que el script manual (mismo MANIFEST, otro
+      # archivo), corriendo como un segundo commit separado justo
+      # después del de Staging — no se pisan en un solo commit porque
+      # Staging y Producción son releases conceptualmente distintos
+      # (permite revertir uno sin tocar el otro).
+      - name: Promover a Producción (CD)
+        if: steps.promotion.outputs.promote == 'true'
+        shell: bash
+        run: |
+          set -euo pipefail
+
+          VERSION="${{ steps.vars.outputs.VERSION }}"
+
+          git config user.name "Cristian Felipe"
+          git config user.email "[email protected]"
+
+          # Re-fetch: el step de Staging de arriba ya pusheó un commit a
+          # main en este mismo job -- sin este refresh, este checkout
+          # local queda un commit atrás y el push de abajo se rechaza.
+          git fetch origin main
+          git checkout -B main origin/main
+
+          sed -i -E             "s|(image: ${IMAGE_NAME}:).*|\1${VERSION}|g"             "${PROD_MANIFEST_FILE}"
+
+          perl -0777 -pi -e "s/(- name: APP_VERSION\n\s*value: ).*/\${1}${VERSION}/"             "${PROD_MANIFEST_FILE}"
+
+          git add "${PROD_MANIFEST_FILE}"
+
+          if git diff --cached --quiet; then
+            echo "Producción ya está en ${VERSION}."
+            exit 0
+          fi
+
+          git commit             -m "chore: promote ${VERSION} to production [skip ci]"
+
+          git push origin HEAD:main
+
       - name: Resumen del pipeline
         if: always()
         shell: bash

apps/ecommerce-staging-app.yaml

@@ -0,0 +1,26 @@
+apiVersion: argoproj.io/v1alpha1
+kind: Application
+
+metadata:
+  name: ecommerce-staging-app
+  namespace: argocd
+
+spec:
+  project: default
+
+  source:
+    repoURL: https://gitea.cruzcloud.net/devops/apps-registry.git
+    targetRevision: main
+    path: workloads/ecommerce-staging
+    kustomize: {}
+
+  destination:
+    server: https://kubernetes.default.svc
+    namespace: ecommerce-staging
+
+  syncPolicy:
+    automated:
+      prune: true
+      selfHeal: true
+    syncOptions:
+      - CreateNamespace=true

apps/ecommerce-staging-governance-app.yaml

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

workloads/commerce-backend/medusa-config.ts

@@ -160,7 +160,7 @@ module.exports = defineConfig({
             options: {
               apiKey: required("ENVIOCLICK_API_KEY"),
               sandbox: process.env.ENVIOCLICK_SANDBOX !== "false",
-              originDaneCode: process.env.ENVIOCLICK_ORIGIN_DANE_CODE || "11001000",
+              originDaneCode: process.env.ENVIOCLICK_ORIGIN_DANE_CODE || "76001000",
               originAddress: required("ENVIOCLICK_ORIGIN_ADDRESS"),
               originCompany: process.env.ENVIOCLICK_ORIGIN_COMPANY || "ARI Shopping",
               originFirstName: process.env.ENVIOCLICK_ORIGIN_FIRST_NAME || "ARI",

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

@@ -38,11 +38,22 @@ import { csvRowsToObjects, parseCsv } from "../../../lib/csv";
 // generaba un producto duplicado con handle distinto (confirmado en
 // vivo con "Hello Kitty & Friends": misma fila re-subida para sumar
 // fotos, dos productos con el mismo titulo en la tienda). El match es
-// por titulo exacto (case-insensitive/trim), igual que categoria y
+// por titulo normalizado (case/espacios/guiones-comillas tipograficas,
-// coleccion; en un match, las fotos nuevas se agregan a las que ya
+// ver normalizeTitleForMatch), igual que categoria y coleccion; en un
-// tenia (no se reemplazan) y la descripcion se actualiza si la fila
+// match, las fotos nuevas se agregan a las que ya tenia (no se
-// trae una. No toca precio/cantidad/categoria/coleccion del producto
+// reemplazan) y la descripcion se actualiza si la fila trae una. No
-// existente -- eso se edita a mano en el admin si hace falta.
+// toca precio/cantidad/categoria/coleccion del producto existente --
+// eso se edita a mano en el admin si hace falta.
+//
+// El match era por titulo exacto (case-insensitive/trim) hasta que
+// volvio a duplicar "Toy Story 5 - Woody": la fila reimportada traia
+// un guion largo "–" (pegado desde Excel/Sheets, que autocorrige "-" a
+// en-dash) en vez del guion normal "-" del producto original, asi que
+// el string no calzaba y se creo un producto nuevo en vez de
+// actualizar el existente (confirmado en vivo 2026-09-19). Ademas de
+// guiones, se normalizan comillas tipograficas por la misma razon --
+// cualquier CSV pegado desde un editor de texto enriquecido puede
+// traerlas.
 //
 // Las fotos se descargan del origen y se re-alojan en el mismo
 // MinIO/S3 que ya usa el resto del catalogo (uploadFilesWorkflow ->
@@ -88,6 +99,22 @@ type RowResult = {
 // 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.
+// Colapsa variantes de guion (-, en-dash, em-dash, minus) y comillas
+// tipograficas a su forma ASCII antes de comparar titulos, para que un
+// re-import pegado desde Excel/Sheets/Word (que autocorrigen esos
+// caracteres) siga matcheando el producto ya existente. Ver nota mas
+// arriba sobre "Toy Story 5 - Woody".
+function normalizeTitleForMatch(title: string): string {
+  return title
+    .normalize("NFKC")
+    .replace(/[‐-―−]/g, "-")
+    .replace(/[‘’‛]/g, "'")
+    .replace(/[“”‟]/g, '"')
+    .replace(/\s+/g, " ")
+    .trim()
+    .toLowerCase();
+}
+
 function slugify(title: string, uniquePart: string): string {
   const base = title
     .normalize("NFD")
@@ -190,13 +217,13 @@ export async function POST(req: MedusaRequest<{ csv: string }>, res: MedusaRespo
   }
 
   const categoryByName = new Map(
-    categories.filter((c) => c.name).map((c) => [c.name.toLowerCase().trim(), c.id]),
+    categories.filter((c) => c.name).map((c) => [normalizeTitleForMatch(c.name), c.id]),
   );
   const collectionByName = new Map(
-    collections.filter((c) => c.title).map((c) => [c.title.toLowerCase().trim(), c.id]),
+    collections.filter((c) => c.title).map((c) => [normalizeTitleForMatch(c.title), c.id]),
   );
   const productByTitle = new Map(
-    existingProducts.filter((p) => p.title).map((p) => [p.title.toLowerCase().trim(), p]),
+    existingProducts.filter((p) => p.title).map((p) => [normalizeTitleForMatch(p.title), p]),
   );
 
   const results: RowResult[] = [];
@@ -228,7 +255,7 @@ export async function POST(req: MedusaRequest<{ csv: string }>, res: MedusaRespo
         },
       });
 
-      const existingProduct = productByTitle.get(title.toLowerCase());
+      const existingProduct = productByTitle.get(normalizeTitleForMatch(title));
       if (existingProduct) {
         await updateProductsWorkflow(req.scope).run({
           input: {
@@ -262,7 +289,7 @@ export async function POST(req: MedusaRequest<{ csv: string }>, res: MedusaRespo
       if (!inventoryItemId) throw new Error("No se pudo crear el registro de inventario");
 
       const categoryName = row.categoria?.trim();
-      let categoryId = categoryName ? categoryByName.get(categoryName.toLowerCase()) : undefined;
+      let categoryId = categoryName ? categoryByName.get(normalizeTitleForMatch(categoryName)) : undefined;
       if (categoryName && !categoryId) {
         const { result: createdCategories } = await createProductCategoriesWorkflow(req.scope).run({
           input: {
@@ -272,11 +299,11 @@ export async function POST(req: MedusaRequest<{ csv: string }>, res: MedusaRespo
           },
         });
         categoryId = createdCategories[0].id;
-        categoryByName.set(categoryName.toLowerCase(), categoryId);
+        categoryByName.set(normalizeTitleForMatch(categoryName), categoryId);
       }
 
       const collectionName = row.coleccion?.trim();
-      let collectionId = collectionName ? collectionByName.get(collectionName.toLowerCase()) : undefined;
+      let collectionId = collectionName ? collectionByName.get(normalizeTitleForMatch(collectionName)) : undefined;
       if (collectionName && !collectionId) {
         const { result: createdCollections } = await createCollectionsWorkflow(req.scope).run({
           input: {
@@ -286,7 +313,7 @@ export async function POST(req: MedusaRequest<{ csv: string }>, res: MedusaRespo
           },
         });
         collectionId = createdCollections[0].id;
-        collectionByName.set(collectionName.toLowerCase(), collectionId);
+        collectionByName.set(normalizeTitleForMatch(collectionName), collectionId);
       }
 
       await createProductsWorkflow(req.scope).run({

workloads/docs-portal/docs/aprendizajes/notas-sueltas.md

@@ -82,3 +82,69 @@
   uno de "agregar una clave a un secret ya vivo" deberían haber sido
   dos herramientas distintas desde el principio, no una sola que hay
   que saber cuándo NO correr completa.
+
+## CSS Grid: un scroller horizontal sin `min-w-0` puede desbordar todo el grid
+
+Encontrado en producción (2026-09-13/14) en la página de producto del
+storefront: un síntoma que parecía un bug de imágenes ("se ve como si
+abriera en tamaño real" en Chrome/Edge Android) resultó ser, en
+realidad, un desborde de layout. El carrusel horizontal de "También te
+puede gustar" (`overflow-x-auto`, sin `flex-wrap`) vivía como hijo
+directo de un CSS Grid. Por spec, el tamaño mínimo automático de un
+item de grid es el tamaño mínimo de su contenido **a menos que el
+propio item** tenga `overflow` distinto de `visible` — y como el `div`
+que envolvía al carrusel no lo tenía, el ancho mínimo intrínseco de
+*todas* las tarjetas del carrusel sin wrappear se contaba como el
+mínimo de esa columna, forzando **todo el grid compartido** (imagen,
+título, specs) a ~800px de ancho en un viewport real de ~380px.
+
+**Lección reusable:** cualquier fila con scroll horizontal (carrusel,
+tira de miniaturas, chips de filtro) que sea hijo directo de un CSS
+Grid necesita `min-w-0` en su wrapper (o `overflow` seteado
+directamente en el item de grid) — si no, su contenido sin wrappear
+puede reventar el ancho de todo el grid en silencio, y el síntoma
+visible no tiene nada que ver con imágenes ni con DPR. Diagnosticado
+en vivo comparando `window.innerWidth` (reportaba el ancho
+desbordado) contra el viewport real del dispositivo.
+
+## Rediseño de página de producto y correcciones de datos reales (2026-09-13/14)
+
+Sesión de correcciones guiadas por capturas reales del usuario en
+navegadores reales (no reportes abstractos):
+
+- **Bodega mal configurada:** `ENVIOCLICK_ORIGIN_DANE_CODE` apuntaba a
+  Bogotá (`11001000`) cuando la bodega real está en Santiago de Cali,
+  Valle del Cauca (`76001000`) — afectaba el cálculo real de envío
+  (EnvíoClick) en cada checkout. Corregido en el ConfigMap del
+  frontend, en `commerce-backend/medusa-config.ts` (incluyendo un
+  fallback obsoleto que también apuntaba a Bogotá) y en el registro
+  real de la bodega en Medusa (vía admin temporal, mismo patrón que el
+  resto del lab para ediciones puntuales en vivo).
+- **Redes sociales y páginas de ayuda reales:** el footer enlazaba
+  cuentas placeholder; se verificó en vivo la cuenta real de Instagram
+  antes de linkearla (la primera sugerida no era la correcta) y se
+  activaron los enlaces reales de Instagram/Facebook/WhatsApp, además
+  de las páginas `/cambios` y `/preguntas-frecuentes` con contenido
+  real (ya existían en código, no estaban enlazadas).
+- **Zoom estilo Amazon en la galería de producto:** iteración en tres
+  pasos hasta llegar a lo pedido — `transform: scale()` sobre una
+  imagen ya recortada por `object-cover` (no funcionaba: lo recortado
+  nunca estaba en el DOM), superposición in-place (técnicamente
+  correcta pero no la UX pedida), y finalmente una lupa que sigue el
+  cursor más un panel lateral que magnifica esa región — el patrón
+  real de Amazon. El tamaño/posición del panel se calcula en JS contra
+  `window.innerWidth/innerHeight` en cada `mousemove` (no un
+  breakpoint CSS fijo), con fallback a la superposición in-place si no
+  hay espacio.
+- **Barra flotante de "Añadir al carrito" en mobile: removida, no
+  reajustada.** Pasó por varias iteraciones de lógica de
+  mostrar/ocultar (con `IntersectionObserver`) que seguían
+  superponiéndose a otro contenido en capturas reales del usuario. En
+  vez de seguir ajustando el umbral, se eliminó el componente por
+  completo y se dejó el botón inline normal, visible también en
+  mobile — el mismo patrón que usa la mayoría de tiendas. Verificado
+  con Playwright: cero elementos `position: fixed` en la página de
+  producto.
+- **Ambiente de Staging + versión real en el footer:** ver
+  [ADR 0011](../decisiones/0011-ambiente-staging.md) para el detalle
+  completo.

workloads/docs-portal/docs/arquitectura/plugins-y-subagentes.md

@@ -0,0 +1,111 @@
+# Plugins y subagentes de Claude Code (sesión "lab")
+
+Inventario de qué plugins/skills se instalaron en la sesión principal
+`lab` (no `cloud-practice`, que sigue su propia línea de práctica
+multi-cloud — ver [ADR 0012](../decisiones/0012-practica-multicloud-gcp-azure.md))
+y qué subagentes propios se configuraron, con la fuente real de cada
+uno y por qué se aceptó o se descartó.
+
+## Por qué esto queda documentado como el resto del lab
+
+Dos frentes reales motivaron esto: (a) trabajo visual del storefront
+ARI Shopping — ADR 0008 ya costó tres ciclos completos de
+implementar-y-descartar una identidad en producción por no verla
+renderizada antes de aprobarla; (b) crecimiento de habilidades de
+Platform Engineering/DevOps. Un plugin instala instrucciones que
+Claude sigue automáticamente, algunos con hooks que se ejecutan sin
+pedir confirmación en cada uso — se aplicó la misma disciplina de
+verificación que el resto del lab: quién publica (Anthropic vs
+comunitario), qué permisos/hooks declara, y popularidad como señal de
+confianza, antes de instalar cualquiera que no fuera 100% de Anthropic.
+
+## Plugins instalados
+
+| Plugin | Marketplace | Publica de verdad | Hooks | Notas |
+|---|---|---|---|---|
+| `frontend-design` | `claude-plugins-official` | **Anthropic** (verificado en `plugin.json`) | Ninguno | Solo skills, sin red externa |
+| `context7` | `claude-plugins-official` | **Upstash** (tag `community-managed` — está *hospedado* en el catálogo oficial, no *publicado* por Anthropic) | Sin hooks, pero es un MCP que manda cada consulta al servidor remoto de Upstash (`mcp.context7.com`) | Aceptado con esa salvedad explícita de datos saliendo a un tercero |
+| `superpowers` | `claude-plugins-official` | **Jesse Vincent** (`obra/superpowers`, MIT, 288k+ ⭐ en GitHub) — **NO es de Anthropic** pese a estar listado en el catálogo oficial | Sí: `SessionStart` corre un script que inyecta contexto en cada sesión nueva (revisado: solo lee su propio skill local, sin red ni nada destructivo) | Aceptado con esa salvedad — cambia comportamiento de arranque sin pedir confirmación cada vez |
+| `gitops-workflows` | `devops-skills` (`ahmedasmar/devops-claude-skills`) | Ahmad Asmar (comunitario) | Ninguno (skill pura, sin ejecución automática) | |
+| `k8s-troubleshooter` | `devops-skills` | Ahmad Asmar | Ninguno | |
+| `ci-cd` | `devops-skills` | Ahmad Asmar | Ninguno | |
+| `monitoring-observability` | `devops-skills` | Ahmad Asmar | Ninguno | |
+
+**Descartados, no instalados:**
+
+- **`iac-terraform`** (del mismo marketplace `devops-skills`) — descartado a propósito, no por falta de calidad. Terraform ya se maneja aparte vía `hashicorp/agent-skills` en la sesión `cloud-practice` (ver ADR 0012 Fase 2); instalarlo acá también duplicaría/confundiría la fuente de verdad.
+- **`aws-cost-optimization`** (mismo marketplace) — no se pidió, se dejó afuera para no sumar alcance no solicitado.
+- **`theme-factory`** — investigado y descartado: el mismo nombre aparece en al menos 4 fuentes comunitarias distintas y no relacionadas entre sí (`kivilaid`, `shipshitdev`, `composiohq`, etc.), ninguna en el catálogo oficial de Anthropic. Sin una fuente única verificable, no se instaló nada con ese nombre.
+- **`ui-theme-designer`** (alternativa considerada del catálogo oficial) — es de **SAP SE**, específico para el SAP Fiori Design System / UI5 Web Components. No tiene nada que ver con el stack real de ARI Shopping (Next.js + Tailwind) — se descartó por no aplicar, no por falta de confianza.
+
+## Subagentes propios (`~/.claude/agents/`)
+
+Tres subagentes con propósito acotado y tools restringidas, definidos
+como archivos markdown con frontmatter YAML (formato estándar de
+Claude Code — ver [documentación oficial](https://code.claude.com/docs/en/sub-agents)).
+
+### `devsecops-auditor`
+
+Solo lectura y explicación del pipeline DevSecOps real (Gitleaks,
+Trivy, Semgrep, Syft, Cosign) en `apps-registry`/`platform-infra`/
+`scripts`. `tools: Read, Grep, Glob, Bash` + `disallowedTools: Write,
+Edit` — nunca modifica código de producción, su único output es
+diagnóstico contra el YAML/config real, citando archivo:línea, nunca
+teoría genérica de CI/CD.
+
+### `frontend-critic`
+
+Revisa visualmente un cambio del storefront **antes** de aprobarlo —
+formaliza la disciplina "simular antes de implementar" que costó tres
+ciclos de descarte en ADR 0008. Regla dura: si no puede ver el
+resultado renderizado en esa corrida puntual, el veredicto es "no
+puedo aprobar esto sin verlo", nunca un aprobado condicional.
+
+Vía de verificación, en orden de preferencia:
+1. Chrome DevTools / Claude in Chrome — **hoy no disponible en esta
+   sesión** (corre headless dentro de `tmux-host`, sin navegador real
+   conectado — mismo gotcha ya documentado para Claude in Chrome en
+   general).
+2. Playwright vía Docker en la NAS (el workaround ya validado este
+   mismo lab, ver `.browser-scratch/README.md`) contra
+   `shop.cruzcloud.net`/`staging.cruzcloud.net` reales.
+
+Usa la skill `frontend-design` (oficial, ver tabla de arriba) como
+marco de criterio de calidad visual.
+
+### `cloud-cost-auditor`
+
+Definido de antemano, a propósito, **sin nada que auditar todavía**.
+Necesita los MCP de GCP/Azure que se configuran en la sesión
+`cloud-practice` (ADR 0012) para funcionar — no va a tener recursos
+reales que revisar hasta que esa línea de trabajo pase de la Fase 1.
+Su propio system prompt tiene la regla dura de decir explícitamente
+"no tengo nada que auditar todavía" en vez de inventar un análisis si
+lo invocan antes de tiempo. No es un bloqueante para nada de lo demás,
+solo queda listo para cuando aplique.
+
+## Alcance y persistencia de la instalación
+
+Los 7 plugins quedaron en **`scope: user`** (confirmado con
+`claude plugin list`), no a nivel de proyecto de un repo específico.
+Los 3 subagentes viven en `~/.claude/agents/` (también scope de
+usuario, ubicación estándar según la doc oficial).
+
+**Verificado en vivo que sobrevive a un reinicio del contenedor**,
+mismo criterio que el resto de la configuración persistente de
+`tmux-host` (ver [Sesión tmux persistente](sesion-tmux-persistente.md)):
+`stat -c '%d' /root/.claude` y `stat -c '%d'
+/DATA/AppData/k3d-lab-v3/claude-code-home` devuelven el mismo device
+ID — es el mismo bind mount ya validado para login/confianza de
+carpeta, no un directorio efímero del contenedor.
+
+**Gotcha encontrado en vivo:** tanto los plugins como los subagentes
+nuevos **no quedaron activos en la misma sesión donde se instalaron/
+crearon** — la doc oficial de subagentes dice que se cargan sin
+reinicio, *excepto* la primera vez que se crea el directorio
+`~/.claude/agents/` (que no existía antes en este lab). Confirmado en
+vivo: invocar `devsecops-auditor` en la misma sesión dio
+`Agent type 'devsecops-auditor' not found`. Ambos (plugins y
+subagentes) quedan pendientes de confirmar activos recién en el
+próximo arranque real de la sesión — no es una falla de instalación,
+es el comportamiento documentado.

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

@@ -230,9 +230,15 @@ falla:
   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
+  -c <WORKDIR>`, seguido de `tmux send-keys -t lab claude --remote-control
-  contenedor, no tocar infraestructura externa, así que es seguro
+  --continue Enter` — ver gotcha "sesión recreada pero sin Claude Code
-  hacerlo sin intervención humana.
+  adentro" más abajo, y los gotchas de Remote Control y `--continue`
+  agregados el 2026-09-20) — es solo recuperar el propio entorno de
+  trabajo del contenedor, no tocar infraestructura externa, así que es
+  seguro hacerlo sin intervención humana. Si `WORKDIR` todavía no está
+  montado (ver gotcha siguiente),
+  no se crea la sesión esa vuelta — se reintenta en el próximo ciclo en
+  vez de crearla mal posicionada.
 
 Todo evento (chequeo ok, falla de red, sesión recreada) queda en
 `/DATA/AppData/k3d-lab-v3/tmux-host/logs/health.log` — persistente en
@@ -247,14 +253,169 @@ 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).
 
+## Gotcha: sesión recreada, pero sin Claude Code adentro (reinicio completo del NAS, 2026-09-19)
+
+Distinto al caveat de persistencia de sesión de más abajo (ese cubre "el
+*proceso* muere pero el contenedor sigue vivo" — cerrar la sesión `lab` a
+mano, o un crash del propio `claude`). Este es otro escenario: **el HOST
+completo se apaga y vuelve a arrancar desde cero** (corte de luz, no un
+`docker restart` ordenado) — reordena cuándo arrancan Docker, la red y los
+montajes de `/DATA`/`/media/HDD-Storage` entre sí, algo que un
+`docker restart` normal nunca ejercita porque el host ya estaba arriba.
+
+Tras un corte de luz real, se encontró que el usuario se reconectó a la
+sesión `lab` y encontró un shell vacío, no Claude Code corriendo. Dos
+causas distintas, ambas corregidas:
+
+1. **La sesión tmux SÍ se recreaba sola** (confirmado en `health.log`: el
+   contenedor arrancó y la sesión `lab` quedó recreada en cuestión de
+   segundos), pero `check_tmux_session()` nunca lanzó `claude` adentro —
+   solo garantizaba que existiera el *shell*, no que el proceso de Claude
+   Code estuviera corriendo. El diagrama de arquitectura de este mismo doc
+   siempre mostró `T --> CC["proceso claude"]` como si fuera automático,
+   pero el código nunca lo implementó — el hueco quedó invisible mientras
+   nadie pasó por un reinicio completo real del NAS (en un `docker
+   restart` normal, el `claude` que ya estaba corriendo dentro de la
+   sesión simplemente sigue vivo, porque ahí el proceso *no* muere).
+   **Fix:** `check_tmux_session()` ahora llama `launch_claude_in_session()`
+   (`tmux send-keys -t lab claude Enter`) justo después de crear la sesión
+   — solo cuando la crea de cero, nunca sobre una sesión que ya existe (no
+   se reinyecta `claude` sobre un pane con trabajo en curso).
+2. **Riesgo de carrera no ejercitado todavía, pero real:** `WORKDIR`
+   (`/DATA/AppData/k3d-lab-v3/lab-cruzcloud`) llega vía el symlink absoluto
+   `/DATA/AppData -> /media/HDD-Storage/AppData` (ver el gotcha del symlink
+   más arriba). Si el storage externo (`/media/HDD-Storage`) tarda en
+   montarse en el host más de lo que tarda Docker en arrancar este
+   contenedor — plausible después de un corte de luz, no de un simple
+   restart —, `mkdir -p "$LOG_DIR"` fallaba en silencio (`set -u` sin
+   `-e`) y ese arranque quedaba *sin ningún rastro* en el log, y
+   `tmux new-session -c "$WORKDIR"` habría creado la sesión mal
+   posicionada (o fallado) contra un directorio que todavía no existe.
+   **Fix:** `wait_for_workdir()` reintenta con backoff (pasos de 5s, hasta
+   `STARTUP_MOUNT_WAIT_MAX_SEC=120` por defecto) a que `WORKDIR` exista
+   antes de tocar el log o crear la sesión; si sigue sin existir pasado
+   ese máximo, se registra el error explícitamente y se reintenta en el
+   siguiente ciclo (30 min) en vez de fallar una sola vez y quedarse así.
+
+**Validado en vivo:** imagen reconstruida (`tmux-host:test-fix`) y probada
+en un contenedor descartable aparte (mismos mounts de `/DATA` y
+`/media/HDD-Storage`, sin tocar el `tmux-host` real) — `docker stop` +
+`docker start` (arranque desde cero, no `restart`) recreó la sesión `lab`
+con `claude` corriendo adentro sin intervención manual, en ~1 segundo.
+
+## Gotcha: Remote Control nunca se activaba solo (2026-09-20)
+
+Con la sesión `lab` recreándose sola y `claude` corriendo adentro (gotcha
+anterior), quedaba un problema distinto y más sutil: la sesión servía
+perfecto para trabajar vía `docker exec`/`lab-session.sh`, pero nunca
+aparecía como controlable remotamente en claude.ai — como si Remote
+Control jamás se hubiera activado.
+
+**Causa raíz (confirmado en vivo 2026-09-20):** Remote Control es
+opt-in por lanzamiento, vía el flag `claude --remote-control [nombre]`
+de la CLI. Nada en `launch_claude_in_session()` lo pasaba nunca, así
+que `remoteEnabled` en `~/.claude.json` quedaba en `false` para siempre
+porque nadie lo pedía. No existe un paso separado de confirmación
+"¿Activar Remote Control? y/n" más allá del diálogo normal de
+confianza del folder (una hipótesis inicial de que sí existía tal paso,
+y de que había una clave `remoteControlAtStartup` en `settings.json`,
+resultó falsa al revisar directamente los archivos de configuración
+reales).
+
+**Cómo se detectó:** lanzar `claude --remote-control` a mano (en una
+ventana de tmux en foreground, no vía un `!` de un solo uso que se
+mata al terminar) sí registró la sesión y apareció en la lista de
+sesiones activas de claude.ai como `zimaos-quizzical` — el hostname del
+contenedor (`ZimaOS`) se usa como prefijo por defecto del nombre de
+sesión remota.
+
+**Fix:** cambiar la línea `tmux send-keys` en
+`launch_claude_in_session()` para lanzar `claude --remote-control` en
+vez de `claude` a secas.
+
+**Validado en vivo:** tras reconstruir la imagen y swapear el
+contenedor real (ver el gotcha del swap más abajo), `health.log`
+registró `'claude --remote-control' lanzado...` al recrear la sesión, y
+el pane de tmux mostró `/remote-control is active` con un link de
+sesión válido — sin que nadie lo activara a mano.
+
+## Gotcha: cada recreación de la sesión empezaba una conversación en blanco (2026-09-20)
+
+Con Remote Control ya activándose solo, quedaba una fricción menor pero
+molesta: cada vez que la sesión `lab` se recreaba (reinicio del NAS,
+`docker rm` + recrear, o el propio healthcheck reaccionando a un
+crash), `launch_claude_in_session()` arrancaba una conversación
+completamente nueva. El contexto de trabajo en curso —no las
+credenciales ni la confianza del folder, que sí persisten vía volumen—
+se perdía cada vez, sin relación con los límites de cuota (ver la nota
+al principio de este doc).
+
+**Fix:** agregar `-c`/`--continue` (retoma la conversación más reciente
+en el directorio de trabajo actual) al comando de lanzamiento:
+`claude --remote-control --continue`. Si no hay ninguna conversación
+previa en `WORKDIR`, el propio CLI arranca una nueva sin error — no
+hace falta lógica condicional en el script.
+
+**Validado en vivo — la prueba más fuerte posible:** el swap que
+desplegó este mismo cambio (ver gotcha siguiente) mató la sesión de
+Claude Code que lo estaba ejecutando. Del otro lado, la *misma
+conversación* siguió sin cortarse, con el mismo ID de sesión, sin
+ninguna intervención manual — evidencia directa de que `--continue`
+efectivamente retoma la conversación y no solo que el contenedor volvió
+a levantar.
+
+## Gotcha: actualizar la imagen de `tmux-host` en caliente mata al propio proceso que hace el swap (2026-09-20)
+
+Este contenedor tiene un problema estructural para actualizarse a sí
+mismo: el proceso de Claude Code que ejecutaría `docker stop tmux-host
+&& docker rm tmux-host && docker run ... tmux-host:nueva-imagen` corre
+*dentro* del propio contenedor `tmux-host` — el primer `docker stop`
+mata su propia shell a mitad de la secuencia, dejando el swap a medio
+terminar (visto en vivo: un primer intento así falló en silencio).
+
+**Fix:** correr la secuencia de swap desde un contenedor *sibling*
+efímero, no desde dentro de `tmux-host`:
+
+```bash
+docker run --rm \
+  -v /var/run/docker.sock:/var/run/docker.sock \
+  -v /DATA/AppData/k3d-lab-v3/tmux-host:/tmux-host-cfg \
+  docker:cli sh /tmux-host-cfg/swap-retry.sh
+```
+
+Como este helper solo comparte el socket de Docker (no vive *dentro*
+del contenedor `tmux-host`), detener y recrear `tmux-host` no lo afecta
+a él ni al proceso que lo lanzó desde el host. El script
+(`swap-retry.sh`, junto a sus logs, vive en
+`/DATA/AppData/k3d-lab-v3/tmux-host/` — mismo path físico que
+`/media/HDD-Storage/AppData/k3d-lab-v3/tmux-host/`, ver el gotcha del
+symlink más arriba) deja un log fechado por corrida en `logs/` con el
+`docker ps` y un `grep` sobre `healthcheck.sh` dentro de la imagen
+nueva, para verificar sin tener que adivinar si el fix realmente quedó
+adentro.
+
+**Validado en vivo dos veces (2026-09-20):** el fix de Remote Control y
+el de `--continue` se desplegaron cada uno con este mismo mecanismo,
+ambos confirmados por `docker ps` (imagen e `CreatedAt` nuevos) y por
+`health.log` mostrando la línea de lanzamiento esperada inmediatamente
+después del swap.
+
 ## Qué sobrevive a qué
 
-| Evento | ¿Sobrevive la sesión tmux (`lab`)? | ¿Sobrevive el login de Claude Code? |
+| Evento | ¿Sobrevive la sesión tmux (`lab`)? | ¿Sobrevive el login de Claude Code? | ¿Retoma la misma conversación? |
-|---|---|---|
+|---|---|---|---|
-| Corte de SSH / cerrar la terminal / cambiar de dispositivo | Sí — es exactamente el caso que este setup resuelve | Sí |
+| Corte de SSH / cerrar la terminal / cambiar de dispositivo | Sí — es exactamente el caso que este setup resuelve | Sí | Sí — el proceso `claude` ni se entera |
-| `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 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` | Sí, desde el 2026-09-20 — `--continue` retoma la conversación más reciente en `WORKDIR` (ver gotcha arriba) |
-| `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`) |
+| `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`) | Sí, mismo mecanismo — validado en vivo durante el swap de imagen del 2026-09-20 |
-| 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) |
+| 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) | N/A |
+| Expiración del token OAuth de Claude Code | Sí — el proceso `claude` sigue vivo en el pane, pero muestra `Login expired` y Remote Control queda desconectado (`OAuth token unavailable`) | **No** — requiere `/login` manual (una vez alcanza: el volumen de credenciales es compartido) y después `/remote-control` en **cada** sesión ya abierta. Recrear el contenedor **no** lo arregla | Sí, una vez reautenticado — misma sesión, mismo proceso |
+
+!!! warning "Incidente relacionado"
+    La fila de expiración del token OAuth salió del
+    [incidente de la cadena de 4 fallos en `tmux-host` (2026-09-25/26)](../playbooks/incidente-tmux-host-cadena-fallos-2026-09-25.md).
+    El síntoma "no aparecen las sesiones remotas" llevó a eliminar el
+    contenedor, aunque la causa real era un token vencido. **Antes de
+    tocar el contenedor, mirá el pane de cada sesión.**
 
 ## Validación en vivo
 

workloads/docs-portal/docs/decisiones/0010-pago-envio-reales-y-storefront.md

@@ -425,3 +425,66 @@ Resultados reales, uno por uno (código de cada prueba en
     un dispositivo real.
 21b. **Accesibilidad del checkout completo** por teclado (no solo el
     buscador) — tab order y foco visible en los 3 pasos.
+22. **Importación manual de imágenes no se reflejaba en el storefront —
+    RESUELTO 2026-09-20, con un giro real durante la verificación.**
+    Reportado por el usuario 2026-09-20. Causa raíz #1 (caché
+    multi-pod): `medusaFetch()` en `lib/headless/providers/medusa.ts`
+    usaba `next:{revalidate:60,tags:["medusa-products"]}`, caché en
+    memoria por-pod que sobrevivía a `force-dynamic`. Con
+    `frontend-deploy` en 2 réplicas sin cacheHandler compartido, el POST
+    de `/api/revalidate` del subscriber de Medusa solo llegaba a uno de
+    los dos pods — el otro seguía sirviendo datos viejos hasta que el
+    TTL expirara solo. Una edición puntual + revisar al toque tenía
+    ~50% de chance de pegarle al pod stale; una importación CSV (mucho
+    más lenta) le daba tiempo de sobra al TTL para expirar en ambos.
+    **Fix #1:** se sacó el `next.revalidate`/`tags` del fetch.
+
+    Verificado en vivo por el usuario con una edición real (agregó
+    varias fotos manuales al producto `minnie-y-mickey-mouse`): las
+    fotos sí se reflejaron al toque, confirmando el fix #1 — pero
+    apareció un segundo síntoma real, no relacionado: "el zoom
+    interactivo no se visualiza" en las fotos subidas a mano, aunque sí
+    en las de CSV. **Causa raíz #2** (`components/product/product-gallery.tsx`):
+    el panel/overlay de zoom arma `backgroundImage: \`url(${selected})\``
+    sin comillas — un nombre de archivo con espacio y paréntesis (ej.
+    `descarga (4)-xxx.png`, el patrón por defecto de Chrome al descargar
+    una imagen sin renombrarla, exactamente como quedan las subidas
+    manuales, a diferencia de las de CSV que llegan con nombres
+    saneados) rompe la sintaxis de `url()` sin comillas — el navegador
+    descarta el valor completo en silencio (`backgroundImage: none`).
+    La lupa (recuadro) sí aparecía porque no depende de la URL; solo el
+    panel/overlay quedaba en blanco. **Fix #2:** comillas alrededor de
+    la URL en las dos ocurrencias del patrón. Verificado en vivo contra
+    las 9 fotos reales del producto (2 de CSV + 7 manuales con
+    espacio+paréntesis) con Playwright: `computed backgroundImage`
+    pasó de `none` a `url("...")` correcto en las 7 que fallaban, sin
+    tocar las 2 que ya andaban bien.
+23. **En mobile (viewport real de 320px), la página se cortaba y
+    obligaba a scrollear horizontalmente — RESUELTO 2026-09-20.**
+    Reportado por el usuario con captura real de `shop.cruzcloud.net`.
+    **No era la galería de imágenes** (esa clase de bug con `min-w-0`
+    ya estaba corregida desde la sesión anterior, confirmado en vivo
+    que seguía sana). Dos causas reales encontradas por separado,
+    reproducidas con Playwright contra un viewport de 320×480 real:
+    - **Footer, bloque "Newsletter"** (`components/layout/footer.tsx`):
+      el párrafo de texto, sin `min-w-0`, le pedía al grid item su
+      ancho de una sola línea sin wrappear (~335px, medido en vivo)
+      en vez de dejarse achicar — forzaba la única columna del grid
+      (`sm:grid-cols-2 lg:grid-cols-4`, sin `grid-cols-1` propio pero
+      con auto-stacking correcto por debajo de `sm`) a 335px de ancho,
+      arrastrando la página entera. Mismo bug de fondo que el ya
+      documentado en la galería, en un grid en vez de un
+      `overflow-x-auto`.
+    - **Navbar, fila de "Departamentos"/"Todo"** (`components/layout/navbar.tsx`):
+      los 3 items de esa fila (botón de menú, "Departamentos", "Todo")
+      tenían los tres `shrink-0` — ninguno podía achicarse, así que si
+      los tres no entraban en 320px, desbordaban sí o sí (`min-w-0` no
+      aplica cuando el ítem no está pensado para achicarse). Fix:
+      ocultar el texto "Departamentos" en mobile (queda ícono + flecha,
+      con `aria-label` agregado para no perder accesibilidad), libera
+      espacio suficiente para que quepan los tres.
+    Verificado en vivo con Playwright (viewport 320×480 real, no
+    emulación de dispositivo con DPR) contra staging y producción
+    después del deploy: `document.documentElement.scrollWidth ===
+    clientWidth` en home y en página de producto, en ambos ambientes —
+    sin overflow.

workloads/docs-portal/docs/decisiones/0011-ambiente-staging.md

@@ -0,0 +1,115 @@
+# ADR 0011 — Ambiente de Staging para el storefront
+
+**Estado:** aceptada — desplegado y verificado en vivo
+**Fecha:** 2026-09-14
+
+## Contexto
+
+Hasta este punto, todo cambio de frontend se probaba directamente
+contra `shop.cruzcloud.net` (producción): el mismo push a `main` que
+disparaba el build de imagen también actualizaba el manifiesto real
+que sirve tráfico. Cada iteración de UI (rediseño de la página de
+producto, zoom estilo Amazon, ajustes mobile) implicaba validar en
+vivo sobre el sitio real, sin una red de contención — un cambio roto
+llegaba directo al usuario final antes de poder revertirlo.
+
+El usuario pidió explícitamente un ambiente de Staging para dejar de
+probar en producción ("Me interesa crear el ambiente Staging para no
+estar probando en Prod").
+
+## Opciones consideradas
+
+| Opción | A favor | En contra |
+|---|---|---|
+| **Namespace + Ingress propios, backend compartido con Prod** — elegida | Cero costo adicional de Postgres/Medusa/Meilisearch en un NAS ya ajustado de recursos; rápido de armar reusando el mismo patrón workload+governance de `ecommerce` | Staging y Prod comparten datos reales (catálogo, inventario, órdenes) — no aísla pruebas que muten datos de negocio |
+| Backend propio para Staging (Postgres/Medusa/Meilisearch duplicados) | Aislamiento completo, se podrían probar migraciones de datos sin riesgo | Duplica el consumo de recursos de la NAS sin necesidad todavía (decisión explícita del usuario de descartar esto por ahora) |
+| Feature flags / preview deploys por PR en vez de un ambiente fijo | Sin infraestructura nueva que mantener | Gitea Actions en este lab no tiene un mecanismo de preview-per-branch ya armado; más esfuerzo de tooling que un namespace nuevo |
+
+## Decisión
+
+Namespace `ecommerce-staging` nuevo, con su propio Ingress
+(`staging.cruzcloud.net`) y su propio Deployment de frontend (misma
+imagen Docker que Prod), pero apuntando al **mismo backend Medusa** que
+producción (`medusa-svc.ecommerce.svc.cluster.local:9000` — FQDN
+cross-namespace, un nombre corto solo resuelve dentro del mismo
+namespace). Flujo de promoción: **todo push a `main` despliega a
+Staging automáticamente**; promover a Producción es una acción manual
+separada (`scripts/promote-to-production.sh`).
+
+## Qué se armó
+
+- `apps-registry/workloads/ecommerce-staging/` — overlay Kustomize:
+  1 réplica (no 2 como Prod — ambiente de verificación, no de tráfico
+  real), requests/limits más chicos, mismo `securityContext` que Prod
+  (mismas restricciones del Dockerfile: `runAsUser` numérico,
+  `NET_BIND_SERVICE`, `readOnlyRootFilesystem`).
+- `apps-registry/apps/ecommerce-staging-app.yaml` +
+  `ecommerce-staging-governance-app.yaml` — Applications de Argo CD
+  (workload + governance separadas, misma convención que el resto del
+  lab).
+- `platform-infra/ecommerce-staging-governance/` — ResourceQuota,
+  LimitRange y NetworkPolicy propios del namespace nuevo.
+- `.gitea/workflows/build.yaml` — el paso de CD (`Actualizar
+  Manifiesto GitOps`) ahora apunta a
+  `workloads/ecommerce-staging/frontend/patches/deployment.yaml` en
+  vez del manifiesto de Prod: cada push a `main` bumpea el tag de
+  imagen (y, desde el mismo día, la variable `APP_VERSION` — ver nota
+  de implementación) de Staging automáticamente.
+- `scripts/promote-to-production.sh` — lee el tag actualmente
+  desplegado en Staging, pide confirmación explícita, y lo aplica al
+  manifiesto real de Producción (`workloads/ecommerce/frontend/patches/deployment.yaml`).
+  Nunca corre automáticamente: es la única vía para que un cambio
+  llegue a `shop.cruzcloud.net`.
+- Secrets `commerce-storefront` y `gitea-registry-secret` copiados
+  (no regenerados) desde el namespace `ecommerce` hacia
+  `ecommerce-staging`, para que el frontend de Staging tenga las
+  mismas credenciales reales contra el backend compartido.
+
+## Descubrimiento de red real (no solo Kubernetes)
+
+Confirmado en vivo el mismo día: aunque Cloudflare tiene un wildcard
+`*.cruzcloud.net`, eso **no alcanza** para exponer un Ingress nuevo. La
+cadena real es Cloudflare → túnel `cloudflared` → **Nginx Proxy
+Manager** → `k3d-lab-cluster-serverlb` (puerto 90) → Traefik → Service.
+Cada subdominio que ya funciona (`shop`, `commerce`, `media`, etc.)
+tiene su propia fila de Proxy Host en NPM apuntando a
+`192.168.68.61:90`. Un Ingress nuevo sin esa fila devuelve la página
+por defecto de NPM aunque Traefik ya esté enrutando bien internamente
+— verificado con `curl -H "Host: staging.cruzcloud.net"
+http://192.168.68.61:90/` (funcionaba) contra el dominio público
+(seguía devolviendo la página por defecto hasta que se agregó la fila
+en NPM). Ver [Red y exposición](../arquitectura/red-y-exposicion.md).
+Esta fila de NPM la agregó el usuario manualmente — no hay credenciales
+de ese panel disponibles para automatizarlo.
+
+## Nota de implementación (2026-09-14): versión real visible en el footer
+
+El footer mostraba un string fijo (`v4.1`), inútil para distinguir a
+simple vista si Staging y Producción están en la misma versión.
+Se agregó una variable de entorno `APP_VERSION` (leída en
+`footer.tsx` vía `process.env.APP_VERSION`, sin necesidad de prefijo
+`NEXT_PUBLIC_` por ser un Server Component) a ambos manifiestos de
+Deployment; el mismo paso del CD que bumpea el tag de imagen ahora
+también bumpea `APP_VERSION` (vía `perl -0777` para una sustitución
+multilínea, ya que el nombre y el valor de la variable viven en líneas
+distintas del YAML — un `sed` de una sola línea no alcanza).
+`promote-to-production.sh` hace el mismo bump al promover. Verificado
+en vivo con Playwright: tras el primer push, Staging mostró `v1.0.263`
+mientras Producción seguía en `v4.1` (la imagen vieja no leía la
+variable); tras promover, ambos ambientes quedaron visualmente
+distinguibles por versión real en su footer.
+
+## Consecuencias
+
+- Ganado: ningún cambio de frontend vuelve a validarse por primera vez
+  contra tráfico real; Staging y Producción ahora se distinguen a
+  simple vista por la versión mostrada en el footer.
+- Deuda aceptada: Staging comparte datos reales de negocio con
+  Producción (mismo Medusa/Postgres) — una prueba que cree o modifique
+  órdenes/inventario en Staging afecta datos reales. Si esto se vuelve
+  un problema, la opción descartada de backend propio para Staging
+  queda como camino de escalamiento.
+- Para revertir: apuntar de nuevo `MANIFEST_FILE`/`KUSTOMIZE_DIR` en
+  `build.yaml` hacia `workloads/ecommerce/...` y eliminar el namespace
+  `ecommerce-staging` — el namespace de Producción no cambia de forma
+  en ningún momento de este ADR.

workloads/docs-portal/docs/decisiones/0012-practica-multicloud-gcp-azure.md

@@ -0,0 +1,321 @@
+# ADR 0012 — Práctica multi-cloud: GCP y Azure DevOps en paralelo al lab ZimaOS
+
+**Estado:** aceptada — Fase 1 (Google Workspace) completa y verificada
+en vivo, con un giro real: el MCP self-hosted planeado
+(`taylorwilsdon/google_workspace_mcp`) quedó abandonado por un límite
+real de esa librería (ver §Fase 1), reemplazado por los Connectors
+nativos de claude.ai. Fases 2-4 quedan documentadas como roadmap,
+explícitamente no implementadas hasta que se pidan en una sesión
+futura.
+**Fecha:** 2026-09-20 (Fase 1 cerrada 2026-09-21)
+
+## Contexto
+
+El lab GitOps de CruzCloud (ZimaOS + k3d + Gitea + Argo CD) ya prueba en
+vivo, con rigor de ADR, patrones que después se pueden proponer en
+trabajo real con clientes — pero corre íntegro sobre hardware propio,
+sin tocar ningún proveedor de nube público. Dos motivaciones concretas
+empujan a abrir una segunda línea de práctica en paralelo:
+
+1. **Practicar herramientas que el cliente actual restringe.** Ciertas
+   plataformas/herramientas de nube no están disponibles en el entorno
+   de trabajo del cliente actual — la única forma real de ganar
+   experiencia con ellas es un entorno propio.
+2. **Preparar propuestas de arquitectura con evidencia, no solo teoría.**
+   Poder decir "ya lo corrí, así se ve, esto cuesta X" en una propuesta
+   a un cliente vale más que una descripción de manual.
+3. **Portafolio.** Los mismos ADRs, diagramas y decisiones documentadas
+   que ya sostiene este lab sirven como muestra de trabajo verificable.
+
+**Alcance confirmado explícitamente por el usuario, no asumido:**
+
+- **Entorno paralelo, no migración.** ZimaOS sigue siendo el lab
+  principal — nada de lo de acá reemplaza nada de lo ya construido.
+- **Cuentas personales únicamente.** Nunca credenciales del cliente
+  actual ni de ningún cliente futuro — separación total.
+- **Costo cero o mínimo**, con alertas de presupuesto como red de
+  seguridad desde el primer recurso pago que se cree (ver
+  [Análisis de costo](#analisis-de-costo-explicito) más abajo).
+- Mismo rigor documental que el resto del lab: un ADR por decisión
+  arquitectónica real, diagramas Mermaid, cifras verificadas en vivo o
+  contra fuente primaria (no contra un blog de terceros sin
+  corroborar — ver el caso del supuesto MCP "oficial" de Google
+  Workspace en la [Fase 1](#fase-1-ejecutada-google-workspace-con-un-giro-real-en-la-implementacion)).
+
+## Diagrama del lab actual (ZimaOS)
+
+Versión simplificada, con solo los componentes relevantes para la
+comparación de este ADR — el diagrama completo (con Traefik,
+`serverlb`, cada `Host` de Ingress, etc.) vive en
+[Visión general](../arquitectura/vision-general.md).
+
+```mermaid
+flowchart LR
+    User(["Usuario"]) -->|HTTPS| CF["Cloudflare Tunnel<br/>(sin puertos abiertos)"]
+    CF --> NPM["Nginx Proxy Manager<br/>enrutamiento por dominio"]
+    NPM --> K3D["k3d<br/>(cluster K8s local, Docker)"]
+
+    subgraph K3D_INT["Dentro de k3d"]
+        ARGO["Argo CD"] -->|sync| APPS["Apps reales<br/>(ecommerce, docs-portal)"]
+        GIT["Gitea<br/>(auto-alojado)"] -.->|watch repos| ARGO
+    end
+    K3D --> K3D_INT
+```
+
+**Costo real:** $0 — hardware propio (NAS ZimaOS), sin proveedor de
+nube de por medio.
+
+## Diagrama Fase 1 — entorno paralelo en GCP (VM + k3s)
+
+**Esto NO es GKE administrado.** Es una VM `e2-micro` corriendo k3s
+self-managed, elegida específicamente para mantener el costo real en
+$0 — GKE (administrado, ver [Fase 4](#fase-4-documentar-no-ejecutar-gke-real-con-spot-auto-apagado))
+no tiene una vía 100% gratuita permanente (ver el análisis de costo
+más abajo).
+
+```mermaid
+flowchart LR
+    User(["Usuario / Claude"]) -->|SSH / kubectl| VM["Compute Engine e2-micro<br/>Always Free — us-west1/us-central1/us-east1<br/>NO es GKE administrado"]
+
+    subgraph VM_INT["Dentro de la VM"]
+        K3S["k3s<br/>(single-node, self-managed)"]
+        ARGO2["Argo CD<br/>(instancia propia, no la de ZimaOS)"] -->|sync| APPS2["Manifiestos del nuevo repo<br/>(mismo patrón base+overlay<br/>de platform-templates)"]
+    end
+    VM --> VM_INT
+
+    GIT_EXISTENTE["Gitea existente<br/>gitea.cruzcloud.net<br/>(reusado, repo nuevo, NO uno nuevo)"] -.->|watch| ARGO2
+```
+
+**Por qué reusar el Gitea existente en vez de levantar uno nuevo en
+GCP:** el objetivo es practicar el patrón GitOps completo (Kustomize
+base+overlay + Argo CD sincronizando) con el mínimo de piezas nuevas —
+levantar un segundo Gitea solo sumaría superficie a mantener sin
+enseñar nada nuevo sobre GCP en sí. El *cómputo* (la VM, k3s) es lo que
+cambia de proveedor; el origen de verdad (Git) se queda donde ya
+funciona.
+
+**Costo real:** $0 — `e2-micro` es Always Free **de forma permanente**
+(no es el trial de $300/90 días), siempre que la VM viva en
+`us-west1`, `us-central1` o `us-east1` y no supere 1 instancia
+no-preemptible + 30 GB-mes de disco persistente estándar + 1 GB/mes de
+salida hacia Norteamérica — límites reales del programa, verificados
+contra la documentación oficial de Google Cloud.[^1]
+
+## Fase futura (no implementada) — GKE real con Spot + auto-apagado
+
+Marcada explícitamente como **fase futura, no implementada** — ver
+[Fase 4](#fase-4-documentar-no-ejecutar-gke-real-con-spot-auto-apagado)
+para cuándo se decidiría ejecutarla.
+
+```mermaid
+flowchart LR
+    TF["Terraform<br/>(provisiona todo)"] --> GKE["GKE Standard<br/>1 cluster zonal"]
+    GKE --> NP["Node pool<br/>Spot VMs (e2-small)"]
+
+    SCHED["Cloud Scheduler<br/>(cron: apagar/prender)"] -->|invoca| FN["Cloud Run/Functions<br/>job de auto-apagado"]
+    FN -->|resize node pool<br/>a 0 / de vuelta| NP
+
+    style GKE fill:#333,stroke:#f90,color:#fff
+    style NP fill:#333,stroke:#f90,color:#fff
+    style SCHED fill:#333,stroke:#f90,color:#fff
+    style FN fill:#333,stroke:#f90,color:#fff
+```
+
+### Mecanismo de auto-apagado: comparación antes de recomendar
+
+Dos mecanismos reales existen para esto; se investigaron ambos antes de
+elegir uno, sin asumir cuál es "obviamente" mejor:
+
+| | Escalar node pool a 0 | Destruir/recrear cluster completo (`terraform apply`/`destroy` programado) |
+|---|---|---|
+| Qué apaga | Solo el cómputo (los nodos) | Todo, incluido el control plane |
+| Ahorra el fee de control plane ($0.10/hora) | No — pero **ya está cubierto por el crédito mensual de $74.40** para un único cluster, así que no hay nada real que ahorrar ahí | Sí, pero es un ahorro sobre algo que ya es $0 |
+| Tiempo de "volver a prender" | ~1-3 min (crear nodos sobre un cluster que ya existe) | ~5-10 min (crear el cluster entero de cero) |
+| Piezas para automatizarlo | Cloud Scheduler → Cloud Function/Run → 1 llamada a la API de GKE (resize node pool) | Cloud Scheduler → runner con Terraform + credenciales + state remoto seguro → `apply`/`destroy` completo |
+| Riesgo de drift/config perdida | Bajo — el cluster nunca se borra | Mayor — cualquier cosa hecha fuera de Terraform se pierde en cada destroy |
+| Patrón documentado en la industria | Sí, es el patrón estándar (Cloud Scheduler + Pub/Sub + Cloud Function), con casos reales de ~30% de ahorro de cómputo en clusters no-críticos[^2] | Existe, pero es la opción menos común para este caso puntual |
+
+**Recomendación (sin implementar todavía):** escalar el node pool a
+0/de vuelta vía Cloud Scheduler + Cloud Function, no destruir/recrear
+el cluster completo. Razón concreta: el crédito de $74.40/mes **ya
+cubre el fee de control plane de un único cluster exista o no exista
+un nodo adentro** — destruir el cluster entero no ahorra nada sobre
+ese componente porque ya es $0, y a cambio suma la complejidad real de
+manejar Terraform state de forma segura dentro de un cron job
+automatizado, más un tiempo de arranque 3-5x más largo. La única razón
+real para preferir destruir/recrear sería eliminar *toda* huella en
+GCP entre usos (por ejemplo, para no depender de que el crédito
+mensual siga existiendo) — no es el caso acá.
+
+## Tabla comparativa
+
+| | Lab actual (ZimaOS) | GCP Fase 1 (VM + k3s) | GCP Fase futura (GKE + Spot) |
+|---|---|---|---|
+| Cómputo | NAS propio, Docker/k3d | Compute Engine `e2-micro` | GKE Standard, node pool Spot `e2-small` |
+| ¿Kubernetes administrado? | No (k3d local) | No (k3s self-managed) | Sí (GKE Standard) |
+| Control plane | N/A (local) | N/A (k3s corre en la misma VM) | $0.10/hora — cubierto por crédito de $74.40/mes para 1 cluster |
+| Cómputo de nodos | $0 (hardware propio) | $0 (Always Free permanente) | ~$7-10/mes (Spot `e2-small`, sin cubrir por ningún crédito) |
+| GitOps | Argo CD + Gitea, ambos autoalojados | Argo CD propio en la VM, mismo Gitea reusado | Igual que Fase 1, sobre GKE |
+| Costo mensual real | $0 | $0 | ~$7-10/mes (no $0) |
+| Estado | En producción, uso diario | A ejecutar esta sesión (Parte 2/3) | Documentado, no implementado |
+
+## Análisis de costo explícito
+
+**No existe un GKE administrado 100% gratis de forma permanente.** El
+crédito de $74.40/mes por cuenta de facturación cubre exactamente el
+fee de control plane ($0.10/hora) de **un** cluster zonal Standard o
+Autopilot — nunca el cómputo real. GKE Autopilot factura desde el
+primer pod que se programa (vCPU/memoria/almacenamiento por pod), sin
+ningún equivalente al Always Free de Compute Engine; GKE Standard sí
+puede correr sobre un único nodo Spot/preemptible barato (~$7/mes para
+un `e2-small`, verificado contra tarifas actuales), pero ese cómputo
+nunca es gratis.[^3]
+
+**La única ruta de costo cero real y permanente es Compute Engine
+`e2-micro` (Always Free) + k3s self-managed** — exactamente la Fase 1
+de este ADR. No es el trial de $300/90 días (que expira y no es
+"gratis", es prepago con reloj corriendo); es un beneficio permanente
+del programa de nivel gratuito de Google Cloud, activo mientras la VM
+cumpla los límites de región/tamaño/tráfico ya descritos arriba.
+
+**Activar cualquier billing account de GCP requiere tarjeta igual**,
+incluso para quedarse exclusivamente en recursos Always Free — Google
+verifica el medio de pago aunque el cargo real sea $0. Detalle no
+obvio, verificado contra documentación oficial: **las alertas de
+presupuesto no se pueden configurar mientras la cuenta esté operando
+sobre crédito gratuito de prueba** — hace falta pasar la cuenta de
+facturación a estado "paga" (el uso real sigue siendo $0 si no se sale
+del Always Free) para que la opción de crear un presupuesto/alerta
+quede disponible.[^4] **Recomendación:** hacer ese paso — pasar a
+cuenta de facturación paga — como parte del setup inicial, y configurar
+de inmediato una alerta de presupuesto en **$1-5 USD** como red de
+seguridad, antes de crear ningún recurso más allá de lo cubierto por
+Always Free.
+
+## Secuencia de fases
+
+Todas documentadas acá; **solo la Fase 1 se ejecuta en esta sesión.**
+Las Fases 2-4 no se implementan sin pedido explícito en una sesión
+futura — quedan como roadmap, no como trabajo en curso.
+
+### Fase 1 (ejecutada) — Google Workspace, con un giro real en la implementación
+
+**Objetivo cumplido — acceso real a Google Calendar desde Claude,
+verificado en vivo — pero por un camino distinto al planeado
+originalmente.** Detalle de la investigación previa (qué MCP usar,
+oficial vs comunitario) — resumen: **no existe un MCP oficial de
+Google Workspace** publicado por Google (se verificó explícitamente
+buscando en los GitHub `google`/`googleworkspace` oficiales — no
+aparece ninguno; un solo blog de terceros afirma que "ya existe uno
+oficial" sin que ninguna otra fuente lo corrobore, así que se descarta
+esa afirmación por no verificable). Se optó por
+`taylorwilsdon/google_workspace_mcp` (comunitario, el más completo y
+activamente mantenido: 120+ herramientas, OAuth 2.1, +2500 estrellas)
+como primer intento, self-hosted dentro de `tmux-host`.
+
+**Ese self-hosted quedó abandonado — límite real encontrado en la
+librería, no un error de configuración.** El servidor usa FastMCP's
+`GoogleProvider`/`OAuthProxy`, que construye el `redirect_uri`
+enviado a Google directamente desde su propio `base_url` — **no**
+desde la variable `GOOGLE_OAUTH_REDIRECT_URI` que el proyecto expone
+(esa variable solo valida entradas, no arma la salida real; hallazgo
+confirmado leyendo el código fuente instalado, no la documentación
+pública). Y `base_url` es la misma variable de la que depende por
+default `issuer_url`, que el SDK de MCP exige sea HTTPS salvo que sea
+literalmente `localhost`/`127.0.0.1` (chequeo hardcodeado en
+`mcp/server/auth/routes.py:validate_issuer_url`, sin variable de
+entorno que lo salte). Resultado: **no hay combinación de variables
+de entorno que satisfaga a la vez** "el navegador del usuario debe
+poder llegar al callback" (necesita un dominio real, no `localhost`)
+y "el issuer debe ser HTTPS o `localhost`" — `workspace-mcp` no
+expone `issuer_url` por separado de `base_url` en su capa de
+configuración (confirmado en `core/server.py`: solo pasa `base_url` a
+`GoogleProvider(...)`).
+
+**Decisión del usuario ante ese límite:** en vez de armar un proxy
+HTTPS con certificado autofirmado (infraestructura extra, fricción de
+certificado no confiable en cada uso) o parchear el paquete instalado
+a mano (frágil, se pierde en cualquier reinstalación), se usaron los
+**Connectors nativos de claude.ai** (Google Calendar, vía el
+directorio de conectores de la cuenta, fuera de Claude Code por
+completo) — mismo resultado práctico (Claude con acceso real al
+calendario personal), infraestructura cero de nuestro lado, sin
+tocar código de terceros. Contrapartida real: es una integración de
+cuenta de claude.ai, no un MCP configurado dentro del proyecto
+`platform-multicloud` — no aparece como herramienta en sesiones de
+Claude Code (`lab`/`cloud-practice`), solo en el chat normal de
+claude.ai.
+
+**Verificado en vivo:** pregunta real en claude.ai normal ("¿qué
+tengo en el calendario esta semana?") devolvió una respuesta correcta
+revisando 3 calendarios reales de la cuenta (principal, Familia,
+festivos de Colombia) vía la herramienta `Google Calendar: Lists
+calendar events`, con razonamiento correcto sobre qué cuenta como
+"esta semana" dado el día/hora real de la consulta.
+
+### Fase 2 (documentar, no ejecutar) — Terraform aislado
+
+Instalar el marketplace oficial de HashiCorp Agent Skills, y practicar
+aprovisionando algo mínimo y desechable en GCP. Nota para cuando se
+ejecute: HashiCorp también publica un **MCP Server de Terraform**
+propio y oficial (`hashicorp/terraform-mcp-server`, integra con el
+Terraform Registry y HCP Terraform) — es una pieza distinta a los
+Agent Skills (el MCP es el "tubo" hacia herramientas reales; los
+Skills son paquetes de conocimiento/instrucciones) y vale la pena
+evaluar si se usan juntos o solo uno de los dos en ese momento.
+
+### Fase 3 (documentar, no ejecutar) — Azure DevOps en paralelo
+
+MCP oficial `microsoft/azure-devops-mcp` (confirmado como el oficial y
+activamente mantenido por Microsoft, hay varios forks/alternativas
+comunitarias que no son la vía recomendada). Replicar el mismo
+pipeline DevSecOps que ya corre en Gitea Actions para este lab
+(Gitleaks → Trivy → Semgrep → Syft → Cosign) como Azure Pipelines YAML,
+en un proyecto personal — mismo objetivo de práctica que la Fase 1:
+tener el patrón ya probado para proponerlo en trabajo con clientes que
+usen Azure DevOps.
+
+### Fase 4 (documentar, no ejecutar) — GKE real con Spot + auto-apagado
+
+Solo si se decide conscientemente asumir el costo bajo pero no-cero
+(~$7-10/mes, ver el análisis de costo arriba) — vía Terraform, node
+pool Spot, y el mecanismo de auto-apagado recomendado en la sección de
+arriba (escalar a 0, no destruir/recrear el cluster).
+
+## Opciones consideradas
+
+| Opción | A favor | En contra |
+|---|---|---|
+| Entorno paralelo en GCP+Azure (elegido) | Practica exactamente lo que el cliente actual restringe; portafolio con evidencia real; ZimaOS sigue intacto | Dos entornos más que mantener; curva de aprendizaje de dos proveedores nuevos a la vez |
+| Migrar el lab completo a un solo cloud | Un solo entorno que mantener | Pierde justo lo que se quiere conservar (costo $0, control total de hardware); no es lo que se pidió |
+| Solo AWS (el "default" de la industria) | Ecosistema más grande | El cliente actual ya usa/restringe otras plataformas específicas — practicar AWS no cierra esa brecha puntual |
+| GKE administrado desde el día 1 (saltear la VM self-managed) | Más parecido a "producción real" desde el inicio | Rompe el requisito de costo cero explícito del usuario — ningún tier de GKE es gratis de forma permanente |
+
+## Decisión
+
+Se abre una línea de práctica multi-cloud paralela al lab ZimaOS, en
+cuentas personales, arrancando por Compute Engine `e2-micro` (Always
+Free) + k3s self-managed en GCP como Fase 1 de cómputo, y Google
+Workspace vía MCP comunitario (`taylorwilsdon/google_workspace_mcp`)
+como primer MCP a configurar en esta sesión. Terraform, Azure DevOps y
+GKE administrado quedan documentados como Fases 2-4, sin implementar.
+
+## Consecuencias
+
+- **Se gana** un segundo entorno real, documentado con el mismo rigor
+  de ADR que ya sostiene el lab, listo para mostrar en propuestas a
+  clientes — sin tocar nunca credenciales de cliente.
+- **Se sacrifica/queda como deuda técnica:** la Fase 1 de GCP usa k3s
+  self-managed, no un Kubernetes administrado real — cualquier lección
+  específica de operar GKE (autoscaling nativo, node pools, IAM de
+  GCP) queda pendiente hasta la Fase 4, y esa fase sí tiene costo real
+  (~$7-10/mes) que hoy no se está pagando.
+- **Para revertir:** dar de baja la VM `e2-micro` y (si se llegó a
+  crear) el node pool de la Fase 4 — ningún componente de este ADR
+  toca o depende del lab ZimaOS existente, así que no hay nada que
+  revertir de ese lado.
+
+[^1]: [Compute Engine Free Tier — Google Cloud](https://cloud.google.com/free/docs/compute-getting-started), [GCP Free Tier Complete Guide 2026](https://agentdeals.dev/gcp-free-tier-2026)
+[^2]: [Reduce Your GKE Bill with Cloud Scheduler by Scaling to Zero](https://chimbu.medium.com/reduce-your-gke-bill-with-cloud-scheduler-by-scaling-to-zero-during-off-peak-hours-9796bb4f7b8b), [Scaling GKE Standard Clusters to Zero](https://medium.com/@gustavo.romerobenitez_34616/scaling-gke-standard-clusters-to-zero-56bf5270510e)
+[^3]: [GKE Pricing Guide 2026 — Sedai](https://sedai.io/blog/google-cloud-kubernetes-cluster-cost), [e2-small pricing — Economize](https://www.economize.cloud/resources/gcp/pricing/compute-engine/e2-small/), [Google Kubernetes Engine pricing — Google Cloud](https://cloud.google.com/kubernetes-engine/pricing)
+[^4]: [Google Cloud Free Trial FAQs](https://cloud.google.com/signup-faqs), [Create, edit, or delete budgets and budget alerts — Google Cloud](https://docs.cloud.google.com/billing/docs/how-to/budgets)

workloads/docs-portal/docs/decisiones/0013-iniciativas-clientes.md

@@ -0,0 +1,122 @@
+# ADR 0013 — Iniciativas de clientes: Google Apps Script y AppSheet
+
+**Estado:** aceptada — **fase prioritaria**, precede la reanudación de
+las Fases 2-4 del [ADR 0012](0012-practica-multicloud-gcp-azure.md).
+Scaffold del repo en curso; primeras iniciativas reales se agregan
+sesión a sesión, a medida que se comparten.
+**Fecha:** 2026-09-21
+
+## Contexto
+
+Iniciativas propias de la empresa (no del lab), trabajadas con **cuenta
+personal de Google** — dos herramientas concretas: **Google Apps
+Script** (código, automatizaciones) y **Google AppSheet** (apps
+no-code sobre Sheets). Se abre como fase separada del ADR 0012 y con
+prioridad sobre él por decisión explícita: retomar las Fases 2-4 del
+lab (Terraform, Azure DevOps, GKE) espera a que esto avance primero.
+
+**Restricción dura, no negociable:** ningún repo ni documento de esta
+iniciativa contiene credenciales, datos ni información real de
+cliente. Apps Script versiona código (lógica), nunca datos. AppSheet
+no tiene export de código — solo se documenta desde afuera (tablas,
+columnas, expresiones, capturas), nunca se copian datos reales de
+ninguna hoja de cálculo al repo.
+
+## Opciones consideradas
+
+### Apps Script: MCP vs. `clasp`
+
+| Opción | A favor | En contra |
+|---|---|---|
+| MCP para Apps Script | Interacción conversacional directa | **No existe un MCP oficial de Google.** Se verificó explícitamente buscando — solo hay servidores comunitarios (`mohalmah/google-appscript-mcp-server`, `whichguy/gas_mcp`, entre otros), ninguno publicado por Google. Se descartan sin evaluar más a fondo: no hay necesidad de agregar una dependencia comunitaria no verificada cuando existe una CLI oficial que cubre el caso de uso completo. |
+| **`clasp`** (elegido) | CLI oficial de Google (`@google/clasp`), mantenida por el equipo de Apps Script, cubre push/pull/login/versiones/despliegues | Requiere login interactivo (OAuth) — mitigado: el login lo corre el dueño de la cuenta, nunca se comparte el código de autorización |
+
+### AppSheet: qué se puede versionar
+
+Se verificó contra la documentación oficial vigente (no se asumió):
+**AppSheet no expone ningún mecanismo de export de la definición de la
+app** (tablas virtuales, vistas, expresiones, automatizaciones) hacia
+un formato versionable con git. La única superficie exportable es la
+app en sí vía la consola de AppSheet, no un artefacto de código. Existe
+un addon de terceros ("App Script Saver") pero es específico de Apps
+Script, no de AppSheet, y no se evaluó como parte de esta decisión
+(mismo criterio que con los MCP: no se instala nada de terceros sin
+pasar primero por la verificación de publicador/permisos ya establecida
+en el lab).
+
+**Decisión sobre AppSheet:** no se intenta versionar la app —se
+documenta desde afuera. La documentación (markdown + capturas) es la
+única fuente versionada; la app real en la consola de AppSheet sigue
+siendo la fuente de verdad operativa, con el riesgo explícito de que
+la documentación quede desactualizada (ver Consecuencias).
+
+## Decisión
+
+Repo privado nuevo `client-initiatives` en Gitea (separado de
+`apps-registry`/`platform-infra`/`scripts`/`platform-multicloud` — ni
+lab GitOps ni práctica multi-cloud, es su propia categoría). Estructura:
+una carpeta por iniciativa bajo `apps-script/` (proyecto `clasp`
+completo, con su propio `.clasp.json`) o `appsheet/` (documentación +
+plantilla de estructura vacía). Mismo criterio de versionado semántico
+y modularidad que ya usa `docs-portal`.
+
+**Flujo Apps Script:** rama `fix/*` → diff mostrado → `merge --no-ff`
+a `main`. `clasp push` (subir el código a Google) es una confirmación
+explícita **aparte**, nunca agrupada con el merge a git — son dos
+sistemas de versionado distintos (git para el repo, Apps Script para
+las versiones desplegadas) y no deben confundirse.
+
+**Gitleaks:** se agrega al pipeline del repo nuevo. Nota real
+encontrada al planificar esto: Gitleaks hoy solo corre en
+`apps-registry` (3 workflows) — `platform-infra` y `scripts` no tienen
+Gitea Actions configurado en absoluto, no hay "los otros tres repos con
+Gitleaks" como se asumió al principio. Se replica el step exacto que
+ya usa `apps-registry` (Gitleaks v8.21.2, `--no-git --redact`, reporte
+JSON) por ser el único precedente real en el lab.
+
+## Fases
+
+### Fase A — Google Apps Script
+
+1. Scaffold del repo `client-initiatives` (estructura, Gitleaks,
+   convenciones documentadas).
+2. Login de `clasp` (`clasp login --no-localhost`) corrido por el
+   dueño de la cuenta — verificación posterior de que
+   `~/.clasprc.json` queda fuera de cualquier repo y con `chmod 600`.
+3. Primeras iniciativas: pendientes de compartir, se agregan una por
+   una bajo `apps-script/<slug>/` a medida que llegan.
+
+### Fase B — Google AppSheet
+
+1. Por cada app existente: documentar tablas, columnas y expresiones
+   en markdown, más capturas del estado actual, bajo
+   `appsheet/<slug>/`.
+2. Plantilla de estructura de datos vacía si aplica (schema, nunca
+   filas reales).
+3. Limitación dejada explícita en cada README de iniciativa: sin diff
+   automático posible entre esta doc y la app real.
+
+## En pausa mientras esta fase esté activa
+
+Por decisión explícita del usuario, prioridad sobre lo ya documentado
+en el ADR 0012 y el resto del lab:
+
+- **Swap de `tmux-host`** — no se corre en esta fase.
+- **[Fase 4 del ADR 0012](0012-practica-multicloud-gcp-azure.md#fase-4-documentar-no-ejecutar-gke-real-con-spot-auto-apagado)**
+  (GKE real con Spot + auto-apagado) — sigue solo documentada.
+- **Prueba del skill `frontend-design`** (pendiente desde la
+  instalación de plugins del 2026-09-20) — no se ejecuta.
+
+Tampoco se toca NPM, `cloudflared`, ni `lab-agent` durante esta fase.
+
+## Consecuencias
+
+- Se gana un espacio versionado y auditado (Gitleaks) para
+  automatizaciones reales de la empresa, sin mezclar nada con el lab
+  GitOps ni con la práctica multi-cloud.
+- Se acepta como deuda consciente que la documentación de AppSheet
+  puede desincronizarse de la app real — no hay forma técnica de
+  evitarlo, solo disciplina de actualizarla.
+- Revertir esta decisión implicaría: eliminar el repo
+  `client-initiatives` (las iniciativas seguirían existiendo en Google,
+  solo se perdería el historial versionado y la documentación externa).

workloads/docs-portal/docs/playbooks/incidente-tmux-host-cadena-fallos-2026-09-25.md

@@ -0,0 +1,385 @@
+# Incidente: cadena de 4 fallos en `tmux-host` (2026-09-25/26)
+
+| | |
+|---|---|
+| **Ventana del incidente** | Noche del 2026-09-25 al 26 (hora local); en `health.log`, de 2026-09-26 04:11Z a ~06:20Z |
+| **Servicio afectado** | Contenedor `tmux-host`: las sesiones `lab` y `cloud-practice` de Claude Code y su Remote Control desde claude.ai (ver [Sesión tmux persistente](../arquitectura/sesion-tmux-persistente.md)) |
+| **Impacto** | Las sesiones remotas no aparecían en claude.ai. Mientras se intentaba arreglar, se perdió el login y la confianza del folder, el supervisor del healthcheck quedó muerto y `claude` no podía conectarse a Anthropic |
+| **Disparador** | Se eliminó el contenedor `tmux-host` a mano creyendo que era la causa |
+
+## Contexto / disparador
+
+El síntoma inicial era uno solo: **"no toma las sesiones remotas"**. Las
+sesiones de Claude Code dentro de `tmux-host` no aparecían en claude.ai.
+Parecía un problema del contenedor, así que se eliminó `tmux-host` para
+recrearlo desde cero.
+
+En realidad ese síntoma tenía una causa que no tenía nada que ver con el
+contenedor: el token OAuth estaba vencido (causa **d**, más abajo). Al
+recrear el contenedor, la mitad de la noche se fue en resolver tres fallos
+reales que *aparecieron* en el camino (causas **a**, **b** y **c**). Cada
+uno se encontró recién después de resolver el anterior. Recién al final
+apareció la causa original.
+
+!!! info "Fuentes de la evidencia"
+    Este playbook se escribió desde dentro del `tmux-host` ya recuperado.
+    Los datos marcados **(verificado)** se confirmaron contra el estado
+    real del sistema al escribirlo: `docker inspect`, `docker images`,
+    `health.log`, `sysctl`, `curl`, `git diff` y los panes de tmux. Los
+    marcados **(reportado)** vienen del relato de la sesión de
+    recuperación. Esa sesión se hizo desde fuera del contenedor y no dejó
+    transcript ni historial de shell que se pueda revisar.
+
+---
+
+## Causa a — Contenedor recreado sin los volúmenes de autenticación
+
+**Síntoma.** Al recrear `tmux-host`, `claude` volvía a pedir login y el
+diálogo de confianza del folder. `--continue` no encontraba ninguna
+conversación previa y arrancaba una en blanco.
+
+**Diagnóstico.** El `docker run` que se usó para recrear el contenedor
+se armó de memoria. Tenía solo 3 de los 5 volúmenes documentados en
+[Sesión tmux persistente](../arquitectura/sesion-tmux-persistente.md)
+**(reportado)**. Faltaban justamente los dos de autenticación y estado
+de Claude Code:
+
+| Volumen faltante | Qué se perdía |
+|---|---|
+| `/DATA/AppData/k3d-lab-v3/claude-code-home` → `/root/.claude` | Credenciales OAuth, historial de conversaciones (por eso `--continue` no encontraba nada), plugins y memoria |
+| `/DATA/AppData/k3d-lab-v3/claude-code-home.json` → `/root/.claude.json` | Confianza del folder y el flag de Remote Control |
+
+Sin esos mounts, `/root/.claude*` vive en el filesystem efímero del
+contenedor, así que cada recreación arrancaba "de fábrica". El contenedor
+se reconstruyó varias veces con el mismo comando incompleto antes de
+comparar contra el doc de arquitectura **(reportado)**. `health.log`
+muestra las sesiones recreándose desde cero a las 04:11Z, 04:40Z, 04:49Z,
+05:03Z, 05:18Z, 06:08Z y 06:10Z **(verificado)**.
+
+**Fix.** Recrear el contenedor con el `docker run` completo de la
+sección *Contenedor: `tmux-host`* del doc de arquitectura. Los 5 volúmenes
+van juntos, sin excepciones.
+
+**Validación en vivo (verificado).** `docker inspect tmux-host` sobre el
+contenedor final (creado `2026-09-26T06:10:55Z`, imagen
+`tmux-host:2026-09-26-fix-real`) lista los 5 mounts:
+
+```
+/var/run/docker.sock                          -> /var/run/docker.sock
+/DATA/AppData/k3d-lab-v3/claude-code-home      -> /root/.claude
+/DATA/AppData/k3d-lab-v3/claude-code-home.json -> /root/.claude.json
+/DATA                                          -> /DATA
+/media/HDD-Storage                             -> /media/HDD-Storage
+```
+
+La sesión `lab` retomó la conversación anterior con `--continue`, sin
+pedir de nuevo la confianza del folder.
+
+!!! warning "Lección"
+    **Antes de improvisar un `docker run` de memoria, leer siempre el doc
+    de arquitectura que ya existe.** El comando completo y el motivo de
+    cada volumen ya estaban documentados en `sesion-tmux-persistente.md`.
+    El tiempo perdido reconstruyendo con un comando incompleto salió de no
+    abrirlo primero.
+
+---
+
+## Causa b — `set -e` heredado mataba al supervisor del healthcheck
+
+**Síntoma.** `healthcheck.sh` corre en background y no tenía quién lo
+relanzara si moría. Para cubrir eso se agregó a `entrypoint.sh` un
+supervisor: un loop que lo relanza tras 10 s. Aun así, cuando
+`healthcheck.sh` terminaba con error, no se relanzaba y el contenedor
+seguía vivo sin healthcheck.
+
+**Diagnóstico.** `entrypoint.sh` tenía `set -eu` desde antes. El
+supervisor corre como función en un subshell (`supervise_healthcheck &`)
+y hereda el `-e`. Cuando `healthcheck.sh` devolvía un código distinto de
+cero, `set -e` mataba al propio subshell del supervisor *en esa misma
+línea*, antes de llegar al `echo WARN` y al `sleep 10` que lo relanzaban.
+Es decir, el supervisor moría justo en el único caso para el que existía.
+
+**Paso en falso: el fix que nunca llegó al disco.** La primera
+"corrección" (`set -eu` → `set -u`) nunca se guardó en el archivo, y la
+imagen se reconstruyó dos veces con el contenido viejo **(reportado)**.
+La evidencia sigue en el host **(verificado)**: las etiquetas
+`tmux-host:2026-09-25-supervised` y `tmux-host:2026-09-25-supervised-v2`
+apuntan a la **misma imagen, `ad7f6eff9537`**. Docker reutilizó todas las
+capas porque el archivo no había cambiado. Recién después de confirmar
+con `cat entrypoint.sh` que el cambio no estaba, se guardó de verdad y se
+construyó `tmux-host:2026-09-26-fix-real` (`7e4c94bf0bc8`, 05:03Z).
+
+**Fix.** En `scripts/tmux-host/entrypoint.sh`:
+
+```diff
+-set -eu
++set -u
+ 
+-/usr/local/bin/healthcheck.sh &
++supervise_healthcheck() {
++  while true; do
++    /usr/local/bin/healthcheck.sh
++    echo "$(date -u +%Y-%m-%dT%H:%M:%SZ) WARN: healthcheck.sh salio inesperadamente (exit=$?) -- relanzando en 10s" \
++      >> /DATA/AppData/k3d-lab-v3/tmux-host/logs/health.log 2>/dev/null || true
++    sleep 10
++  done
++}
+ 
++supervise_healthcheck &
+ exec tail -f /dev/null
+```
+
+**Validación en vivo (verificado).** `health.log` registra el supervisor
+actuando en un caso real. `healthcheck.sh` murió por SIGKILL, se registró
+el aviso y se relanzó solo 10 segundos después:
+
+```
+2026-09-26T05:04:17Z WARN: healthcheck.sh salio inesperadamente (exit=137) -- relanzando en 10s
+[2026-09-26T05:04:27Z] === healthcheck inicio (intervalo=1800s) ===
+```
+
+!!! warning "Lección"
+    **Verificar el archivo en disco (`cat`, `git diff`) ANTES de
+    reconstruir la imagen.** No hay que asumir que el editor guardó el
+    cambio. Dos etiquetas de imagen con el mismo ID indican que el build
+    no tuvo cambios.
+
+---
+
+## Causa c — IPv6 roto en el NAS: timeout de conexión a Anthropic
+
+**Síntoma.** Con el contenedor ya bien montado, `claude` fallaba al
+arrancar con `Unable to connect to Anthropic services` a los ~10 s.
+
+**Diagnóstico** con `curl -v https://api.anthropic.com/` **(reportado)**:
+
+1. El resolver devolvía primero la dirección IPv6 de `api.anthropic.com`.
+2. La ruta IPv6 del NAS no sale a internet: el intento fallaba al
+   instante con `Network unreachable`.
+3. El fallback automático a IPv4 terminaba funcionando, pero la conexión
+   completa tardaba **~14 s**. Eso es más que el timeout interno de
+   Claude Code (~10 s), así que el CLI se rendía antes de que el
+   fallback llegara a conectar.
+
+**Primer intento: parche parcial.**
+`NODE_OPTIONS=--dns-result-order=ipv4first` le indica a Node que prefiera
+IPv4 al resolver. Ayudó, pero no resultó confiable en todos los casos
+**(reportado)**, y además solo corregía el proceso de Node, no la red del
+host. Se descartó y no quedó en la imagen: el contenedor final no tiene
+`NODE_OPTIONS` en su entorno **(verificado)**.
+
+**Fix de raíz.** Deshabilitar IPv6 a nivel de sistema operativo del NAS,
+en caliente y persistente:
+
+```bash
+# En caliente
+sysctl -w net.ipv6.conf.all.disable_ipv6=1
+sysctl -w net.ipv6.conf.default.disable_ipv6=1
+
+# Persistente: /etc/sysctl.d/99-disable-ipv6.conf del host
+# (NO /etc/sysctl.conf -- ver "Validación tras reinicio real" abajo)
+net.ipv6.conf.all.disable_ipv6 = 1
+net.ipv6.conf.default.disable_ipv6 = 1
+```
+
+Esto se tiene que hacer **en el host, no dentro del contenedor**.
+`tmux-host` corre con `--network host`, así que comparte el network
+namespace del NAS. Docker no permite fijar sysctls de red
+(`--sysctl net.*`) en un contenedor con `--network host`, porque
+cambiarían la red de todo el host.
+
+**Validación en vivo (verificado, 2026-09-26 ~06:40Z):**
+
+```
+$ sysctl net.ipv6.conf.all.disable_ipv6 net.ipv6.conf.default.disable_ipv6
+net.ipv6.conf.all.disable_ipv6 = 1
+net.ipv6.conf.default.disable_ipv6 = 1
+
+$ getent ahosts api.anthropic.com
+160.79.104.10   STREAM api.anthropic.com        # solo IPv4, sin AAAA
+
+$ curl -w 'connect=%{time_connect}s total=%{time_total}s' https://api.anthropic.com/
+ip=160.79.104.10 connect=0.035s total=0.65s      # antes: ~14 s
+```
+
+`/etc/sysctl.conf` en el host contiene las dos líneas (escrito
+2026-09-26 05:55:53Z). En ZimaOS, `/` es un `squashfs` de solo lectura,
+pero `/etc` es un overlay con capa de escritura en
+`/mnt/overlay/upper_etc` (ext4 en `/dev/sdc7`), así que el archivo
+persiste.
+
+### Validación tras reinicio real: `/etc/sysctl.conf` no alcanzaba (2026-09-26)
+
+Se reinició el NAS a propósito (~17:13Z) para probar la persistencia.
+Resultado **(verificado)**:
+
+- `/etc/sysctl.conf` **sí** sobrevivió al reinicio con las dos líneas
+  (el overlay de `/etc` persiste).
+- Pero `sysctl net.ipv6.conf.all.disable_ipv6` volvió a dar **`0`**: el
+  archivo existía y **nunca se aplicó** al arrancar.
+
+**Causa.** En ZimaOS, `systemd-sysctl` solo carga `/etc/sysctl.d/*.conf`
+(y `/usr/lib/sysctl.d/`, `/lib/sysctl.d/`). Otras distros traen un
+symlink `/etc/sysctl.d/99-sysctl.conf -> ../sysctl.conf` que hace que
+`/etc/sysctl.conf` también se lea al arrancar. **ZimaOS no lo trae**, así
+que escribir en `/etc/sysctl.conf` funciona solo en caliente (con
+`sysctl -p`) y no sobrevive un reinicio. Nada avisa del problema: el
+archivo está, el contenido es correcto y el valor igual vuelve a `0`.
+
+**Por qué no se rompió enseguida.** Tras el reinicio el host no tenía
+ninguna IPv6 global utilizable, así que `getaddrinfo` no devolvía la AAAA
+de `api.anthropic.com` y todo salía por IPv4. Pero `curl -6` seguía
+fallando (`Could not connect to server`). Si el router vuelve a entregar
+una IPv6 global por SLAAC, vuelve el timeout. Funcionaba por casualidad,
+no porque estuviera corregido.
+
+**Fix.** Mover la configuración a un drop-in que ZimaOS sí lee:
+`/etc/sysctl.d/99-disable-ipv6.conf` (mismas dos líneas).
+
+Para aplicarlo en caliente sin reiniciar: dentro de `tmux-host`,
+`/proc/sys` es de solo lectura (`sysctl -w` → `Read-only file system`).
+Hace falta un contenedor privilegiado de un solo uso en la red del host,
+o `sudo sysctl -p` directo en el host:
+
+```bash
+docker run --rm --privileged --network host \
+  -v /etc/sysctl.d:/etc/sysctl.d:ro \
+  alpine sysctl -p /etc/sysctl.d/99-disable-ipv6.conf
+```
+
+**Validado en vivo (verificado, 2026-09-26 ~19:15Z):**
+`disable_ipv6 = 1` en `all` y `default`, ninguna dirección IPv6 global en
+el host y `curl` a `api.anthropic.com` por IPv4 (`connect=0.035s`).
+
+!!! warning "Lección"
+    "El archivo de configuración persistió" no es lo mismo que "la
+    configuración se aplica al arrancar". La única validación real de
+    algo persistente es **reiniciar y medir el valor efectivo**, no
+    revisar que el archivo siga ahí.
+
+!!! success "Confirmado con un segundo reinicio real (2026-09-26 ~19:37Z)"
+    Tras reiniciar el NAS de nuevo, sin correr ningún `sysctl -p` a mano:
+    `disable_ipv6 = 1` en `all` y `default`, y `curl` a
+    `api.anthropic.com` por IPv4 (`connect=0.035s`). El drop-in de
+    `/etc/sysctl.d/` **sí** se aplica al arrancar. El único IPv6 que queda
+    es la ULA de `virbr0` (red interna de libvirt, `NO-CARRIER`,
+    `tentative`), que no sale a internet y no afecta.
+
+    Sigue sin verificarse si una **actualización de ZimaOS** pisa
+    `upper_etc`. Después de cada update del SO, revisar
+    `sysctl net.ipv6.conf.all.disable_ipv6`.
+
+---
+
+## Causa d — Token OAuth vencido: Remote Control desconectado sin recuperación automática
+
+**Síntoma.** Con todo lo anterior resuelto, las sesiones remotas
+*seguían* sin aparecer en claude.ai. Este era el síntoma original de la
+noche.
+
+**Diagnóstico (verificado).** Ambos procesos `claude --remote-control
+--continue` estaban corriendo (`ps`), y el healthcheck había recreado
+las dos sesiones sin problema (`health.log`, 06:10:58Z). Así que el
+auto-arranque funcionaba. El contenido de los panes de tmux mostró la
+causa:
+
+- Sesión `lab`: `Login expired · Please run /login`
+- Sesión `cloud-practice`:
+  `Remote Control disconnected — OAuth token unavailable — run /login to restore Remote Control`
+
+El token OAuth de Claude Code había vencido. No había ningún problema de
+red, de contenedor ni de volúmenes. **Esta causa no tenía relación con
+ninguna de las tres anteriores.** Eliminar el contenedor nunca podría
+haberla resuelto.
+
+**Fix.**
+
+1. `/login` en **una** sesión. Las credenciales viven en
+   `/root/.claude/.credentials.json`, que es el volumen compartido por
+   todas las sesiones del contenedor.
+2. `/remote-control` → **1. Enable Remote Control** en **cada** sesión ya
+   abierta. Un proceso `claude` que ya estaba corriendo **no** se
+   reconecta solo al renovarse el token. Hay que reactivarlo en cada uno.
+   Para una sesión a la que no estás adjunto:
+
+   ```bash
+   tmux send-keys -t cloud-practice '/remote-control' Enter
+   # aparece el menú con "1. Enable Remote Control" ya seleccionado
+   tmux send-keys -t cloud-practice Enter
+   ```
+
+**Validación en vivo (verificado).** El pane de `cloud-practice` pasó a
+mostrar `/remote-control is active · Continue here, on your phone, or at
+https://claude.ai/code/session_…`, y en `lab` se activó con
+`/remote-control` después del `/login`. Las dos sesiones volvieron a
+aparecer en claude.ai.
+
+!!! tip "Diferencia clave con las otras causas"
+    El healthcheck **sí** recrea sola una sesión tmux caída, y `--continue`
+    retoma la conversación. Un **token vencido no se recupera solo**: hace
+    falta que una persona se reautentique (`/login`) y reactive Remote
+    Control (`/remote-control`) en cada sesión abierta. Recrear el
+    contenedor no lo arregla. Con los volúmenes bien montados, el
+    contenedor nuevo lee el mismo token vencido.
+
+---
+
+## Cronología resumida
+
+Horas en UTC, según `health.log`, `docker images` y los timestamps de
+archivos cuando existen.
+
+| Hora (UTC) | Qué pasó | ¿Resolvió el síntoma original? |
+|---|---|---|
+| antes de 04:11 | Remote Control se desconecta porque vence el token OAuth (causa **d**, todavía sin identificar) | — |
+| ~04:10 | Se elimina `tmux-host` creyendo que es la causa | No |
+| 04:11 → 05:18 | Varias recreaciones con un `docker run` de memoria, sin los mounts de auth: se pide login y confianza de nuevo y `--continue` arranca vacío (causa **a**) | No, y además empeoró |
+| 04:39 | Se agrega el supervisor del healthcheck; builds `supervised` y `supervised-v2`, **misma imagen `ad7f6eff9537`** (el fix de `set -e` no estaba guardado) | No |
+| 05:03 | Se confirma con `cat`, se guarda de verdad y se construye `fix-real` (`7e4c94bf0bc8`) con `set -u` (causa **b**) | No |
+| 05:04 | El supervisor relanza `healthcheck.sh` tras un `exit=137`: primera prueba real | No |
+| hasta ~05:55 | `claude` falla con `Unable to connect to Anthropic services`; con `curl -v` se ve IPv6 unreachable y ~14 s de fallback; se prueba `NODE_OPTIONS` (parcial) | No |
+| 05:55 | Se deshabilita IPv6 en el host, en caliente y en `/etc/sysctl.conf` (causa **c**) | No |
+| 06:10 | Contenedor final: `fix-real` + los 5 volúmenes, recreado según el doc de arquitectura (causa **a** cerrada) | No: Remote Control sigue desconectado |
+| ~06:20 | Los panes muestran `Login expired` / `OAuth token unavailable` → `/login` + `/remote-control` en cada sesión (causa **d**) | **Sí** |
+
+**Camino corto para la próxima vez.** Si "no aparecen las sesiones
+remotas", **antes de tocar el contenedor** mirar el pane de cada sesión:
+
+```bash
+for s in $(tmux ls -F '#S'); do echo "== $s"; tmux capture-pane -p -t "$s" | grep -v '^\s*$' | tail -5; done
+```
+
+Si aparece `Login expired` u `OAuth token unavailable`, la solución es
+`/login` + `/remote-control`. No hace falta nada más.
+
+## Lección general
+
+Un solo síntoma ("no toma las sesiones remotas") puede tener **varias
+causas independientes superpuestas**. En este caso, tres de ellas las
+provocó el propio intento de arreglo. Que la primera causa real
+encontrada se haya resuelto no significa que era *la* causa del síntoma.
+
+Lo que destrabó el incidente fue seguir verificando con evidencia
+concreta después de cada fix, en vez de asumir que "ya quedó": el
+contenido de los panes, `health.log`, `docker inspect`, `docker images`
+(IDs repetidos) y `curl -v`. Cada una de las cuatro causas se confirmó
+con un dato observable, no por deducción.
+
+## Pendientes
+
+Todos cerrados el 2026-09-26:
+
+- **Hecho: commitear el fix de `entrypoint.sh`.** Mergeado a `main` del
+  repo `scripts` (`510cc41`). Antes se verificó que `entrypoint.sh` y
+  `healthcheck.sh` del repo fueran idénticos (md5) a los de la imagen
+  `fix-real` en producción.
+- **Hecho: validar IPv6 tras un reinicio real.** El primer reinicio
+  **falló**: `/etc/sysctl.conf` no se aplica al arrancar en ZimaOS. Se movió
+  a `/etc/sysctl.d/99-disable-ipv6.conf`, y un segundo reinicio confirmó
+  que ahora sí se aplica solo (ver la causa c).
+- **Hecho: limpiar las etiquetas de imagen viejas de `tmux-host`.** Quedan
+  solo `2026-09-26-fix-real` (vigente) y `2026-09-20-uv` (rollback).
+
+Queda una sola vigilancia abierta, sin fecha: después de cada actualización
+de ZimaOS, revisar que `/etc/sysctl.d/99-disable-ipv6.conf` siga existiendo
+y que `disable_ipv6` siga en `1`.

workloads/docs-portal/mkdocs.yml

@@ -86,6 +86,7 @@ nav:
       - Flujo GitOps: arquitectura/gitops-flujo.md
       - Agente de monitoreo: arquitectura/agente-monitoreo.md
       - Sesión tmux persistente: arquitectura/sesion-tmux-persistente.md
+      - Plugins y subagentes: arquitectura/plugins-y-subagentes.md
       - Glosario: arquitectura/glosario.md
   - Decisiones (ADRs):
       - "0001 · Por qué k3d": decisiones/0001-por-que-k3d.md
@@ -97,6 +98,10 @@ nav:
       - "0007 · Identidad visual propia": decisiones/0007-identidad-visual-propia.md
       - "0008 · Identidad Navy & Coral": decisiones/0008-identidad-navy-coral.md
       - "0009 · Checkout real": decisiones/0009-checkout-real.md
+      - "0010 · Pago y envío reales": decisiones/0010-pago-envio-reales-y-storefront.md
+      - "0011 · Ambiente de Staging": decisiones/0011-ambiente-staging.md
+      - "0012 · Práctica multi-cloud GCP/Azure": decisiones/0012-practica-multicloud-gcp-azure.md
+      - "0013 · Iniciativas de clientes": decisiones/0013-iniciativas-clientes.md
       - Plantilla ADR: decisiones/plantilla-adr.md
   - Playbooks:
       - Crashloop Medusa: playbooks/incidente-crashloop-medusa.md
@@ -109,6 +114,7 @@ nav:
       - Realm HTTP y Cosign: playbooks/incidente-cosign-realm-http-tunnel-2026-08.md
       - Contención de recursos Gitea/runner: playbooks/incidente-contencion-recursos-gitea-runner-2026-08.md
       - Blackhole MTU cross-node: playbooks/incidente-mtu-blackhole-cross-node-2026-08.md
+      - "Cadena de fallos tmux-host": playbooks/incidente-tmux-host-cadena-fallos-2026-09-25.md
       - "Migración a platform-templates": playbooks/migracion-platform-templates-2026-08.md
   - Aprendizajes:
       - Notas sueltas: aprendizajes/notas-sueltas.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.242
+          image: gitea.cruzcloud.net/devops/docs-portal:v1.0.283
           # 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-staging/frontend/kustomization.yaml

@@ -0,0 +1,51 @@
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+
+namespace: ecommerce-staging
+
+resources:
+  - https://gitea.cruzcloud.net/devops/platform-templates.git//k8s-manifests/base?ref=main
+
+patches:
+  # Mismo criterio que workloads/ecommerce/frontend/kustomization.yaml:
+  # sin anchors/aliases de YAML a propósito (el parser de Gitea Actions no
+  # los resuelve en "on:", pero acá aplica igual por consistencia con el
+  # resto del repo). Ingress propio via ingress-staging.yaml en vez del
+  # generico de 1-backend del base.
+  - target:
+      kind: Ingress
+      name: app-ingress
+    patch: |-
+      $patch: delete
+      apiVersion: networking.k8s.io/v1
+      kind: Ingress
+      metadata:
+        name: app-ingress
+  - target:
+      kind: Deployment
+      name: app-deployment
+    path: patches/deployment.yaml
+  - target:
+      kind: Service
+      name: app-svc
+    path: patches/service.yaml
+
+  - target:
+      kind: Deployment
+      name: app-deployment
+    patch: |-
+      - op: replace
+        path: /metadata/name
+        value: frontend-deploy
+      - op: replace
+        path: /spec/template/spec/containers/0/ports
+        value:
+          - name: http
+            containerPort: 80
+  - target:
+      kind: Service
+      name: app-svc
+    patch: |-
+      - op: replace
+        path: /metadata/name
+        value: frontend-svc

workloads/ecommerce-staging/frontend/patches/deployment.yaml

@@ -0,0 +1,89 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: app-deployment
+  labels:
+    app: frontend
+spec:
+  # 1 réplica (no 2 como Producción): Staging es para verificar cambios
+  # antes de promover, no para servir tráfico real -- alcanza, y deja más
+  # margen de recursos en la NAS para el resto del cluster.
+  replicas: 1
+  strategy:
+    type: RollingUpdate
+    rollingUpdate:
+      maxUnavailable: 0
+      maxSurge: 1
+  selector:
+    matchLabels:
+      app: frontend
+  template:
+    metadata:
+      labels:
+        app: frontend
+    spec:
+      securityContext:
+        runAsUser: 1001
+      containers:
+        - name: app
+          image: gitea.cruzcloud.net/devops/ecommerce-frontend:v1.0.275
+          env:
+            # Ver comentario en workloads/ecommerce/frontend/patches/deployment.yaml
+            - name: APP_VERSION
+              value: v1.0.275
+            - name: HEADLESS_PROVIDER
+              value: medusa
+            # Backend COMPARTIDO con Producción a propósito (decisión del
+            # usuario 2026-09-14: armar un backend propio para Staging
+            # -Postgres/Medusa/Meilisearch- duplicaría el consumo de la
+            # NAS sin necesidad todavía). FQDN cross-namespace: "ecommerce"
+            # es el namespace real de medusa-svc -- el nombre corto
+            # "medusa-svc" solo resuelve dentro del mismo namespace.
+            - name: MEDUSA_BACKEND_URL
+              value: http://medusa-svc.ecommerce.svc.cluster.local:9000
+            - name: MEDUSA_REGION_ID
+              value: reg_01KZT86WPAH7A7ZZRDSX3350V2
+          envFrom:
+            - secretRef:
+                name: commerce-storefront
+          readinessProbe:
+            httpGet:
+              path: /api/health
+              port: http
+          livenessProbe:
+            httpGet:
+              path: /api/health
+              port: http
+          # Mismo securityContext que Producción -- ver comentario largo en
+          # workloads/ecommerce/frontend/patches/deployment.yaml (misma
+          # imagen, mismos motivos: runAsUser numérico por el Dockerfile
+          # usando "nextjs" por nombre, NET_BIND_SERVICE por el puerto 80,
+          # volumenes por el cache de Next.js con root filesystem de solo
+          # lectura).
+          securityContext:
+            allowPrivilegeEscalation: false
+            readOnlyRootFilesystem: true
+            capabilities:
+              drop:
+                - ALL
+              add:
+                - NET_BIND_SERVICE
+          # Requests/limits mas chicos que Produccion -- una sola replica
+          # de verificacion, no trafico real.
+          resources:
+            requests:
+              cpu: 50m
+              memory: 128Mi
+            limits:
+              cpu: 500m
+              memory: 512Mi
+          volumeMounts:
+            - name: next-cache
+              mountPath: /app/.next/cache
+            - name: tmp
+              mountPath: /tmp
+      volumes:
+        - name: next-cache
+          emptyDir: {}
+        - name: tmp
+          emptyDir: {}

workloads/ecommerce-staging/frontend/patches/service.yaml

@@ -0,0 +1,11 @@
+apiVersion: v1
+kind: Service
+metadata:
+  name: app-svc
+spec:
+  selector:
+    app: frontend
+  ports:
+    - name: http
+      port: 80
+      targetPort: 80

workloads/ecommerce-staging/ingress-staging.yaml

@@ -0,0 +1,19 @@
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: ecommerce-staging-ingress
+  annotations:
+    traefik.ingress.kubernetes.io/router.entrypoints: web
+spec:
+  ingressClassName: traefik
+  rules:
+    - host: staging.cruzcloud.net
+      http:
+        paths:
+          - path: /
+            pathType: Prefix
+            backend:
+              service:
+                name: frontend-svc
+                port:
+                  number: 80

workloads/ecommerce-staging/kustomization.yaml

@@ -0,0 +1,8 @@
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+
+namespace: ecommerce-staging
+
+resources:
+  - frontend/
+  - ingress-staging.yaml

workloads/ecommerce/app/cambios/page.tsx

@@ -0,0 +1,57 @@
+import type { Metadata } from "next";
+import { MessageCircle, PackageOpen, ShieldCheck, Truck } from "lucide-react";
+import { Button } from "@/components/ui/button";
+
+export const metadata: Metadata = { title: "Cambios | ARI Shopping" };
+
+const WHATSAPP_URL = "https://wa.me/573016138155";
+
+export default function CambiosPage() {
+  return (
+    <section className="mx-auto max-w-3xl px-4 py-14 lg:py-20">
+      <span className="text-xs font-black uppercase tracking-[.18em] text-ari-coral">Ayuda</span>
+      <h1 className="mt-3 text-4xl font-black tracking-tight sm:text-5xl">Cambios</h1>
+      <p className="mt-5 text-lg leading-8 text-slate-600">
+        Si tu pedido no es lo que esperabas, te ayudamos a cambiarlo.
+      </p>
+
+      <div className="mt-10 grid gap-6 sm:grid-cols-2">
+        <div className="rounded-2xl border border-slate-200 p-6">
+          <PackageOpen className="size-6 text-ari-marino" />
+          <h2 className="mt-3 font-black">5 días hábiles</h2>
+          <p className="mt-2 text-sm leading-6 text-slate-600">
+            Tenés 5 días hábiles desde que recibís tu pedido para solicitar un cambio.
+          </p>
+        </div>
+        <div className="rounded-2xl border border-slate-200 p-6">
+          <Truck className="size-6 text-ari-marino" />
+          <h2 className="mt-3 font-black">Envío de vuelta sin costo</h2>
+          <p className="mt-2 text-sm leading-6 text-slate-600">
+            ARI Shopping asume el costo del envío de vuelta del producto — no tenés que pagar nada extra.
+          </p>
+        </div>
+        <div className="rounded-2xl border border-slate-200 p-6">
+          <ShieldCheck className="size-6 text-ari-marino" />
+          <h2 className="mt-3 font-black">Condiciones</h2>
+          <p className="mt-2 text-sm leading-6 text-slate-600">
+            El producto debe estar sin usar, con su empaque y etiquetas originales.
+          </p>
+        </div>
+        <div className="rounded-2xl border border-slate-200 p-6">
+          <MessageCircle className="size-6 text-ari-marino" />
+          <h2 className="mt-3 font-black">¿Cómo lo pido?</h2>
+          <p className="mt-2 text-sm leading-6 text-slate-600">
+            Escribinos por WhatsApp con tu número de pedido y coordinamos la recolección y el cambio.
+          </p>
+        </div>
+      </div>
+
+      <Button asChild variant="primary" size="lg" className="mt-10">
+        <a href={WHATSAPP_URL} target="_blank" rel="noopener noreferrer">
+          <MessageCircle className="size-5" />
+          Solicitar un cambio por WhatsApp
+        </a>
+      </Button>
+    </section>
+  );
+}

workloads/ecommerce/app/contacto/page.tsx

@@ -0,0 +1,63 @@
+import type { Metadata } from "next";
+import { Mail, MapPin, MessageCircle } from "lucide-react";
+import { Button } from "@/components/ui/button";
+
+export const metadata: Metadata = { title: "Contacto | ARI Shopping" };
+
+// Numero real confirmado en vivo (probando el boton "Confirmar por
+// WhatsApp" del checkout con navegador real): mismo canal que ya usan
+// los clientes para confirmar pedidos, consistencia a proposito.
+const WHATSAPP_URL = "https://wa.me/573016138155";
+// Correo corporativo nuevo ([email protected] -> reenviado por
+// Cloudflare Email Routing a la casilla real) -- ver nota de
+// implementacion en ADR 0010 para el paso manual de DNS pendiente.
+const CONTACT_EMAIL = "[email protected]";
+
+export default function ContactoPage() {
+  return (
+    <section className="mx-auto max-w-2xl px-4 py-14 text-center lg:py-20">
+      <span className="text-xs font-black uppercase tracking-[.18em] text-ari-coral">Ayuda</span>
+      <h1 className="mt-3 text-4xl font-black tracking-tight sm:text-5xl">Contacto</h1>
+      <p className="mt-5 text-lg leading-8 text-slate-600">
+        ¿Tenés una pregunta sobre tu pedido, un producto o un cambio? Escribinos, te respondemos lo antes posible.
+      </p>
+
+      <div className="mt-10 grid gap-4 sm:grid-cols-2">
+        <a
+          href={WHATSAPP_URL}
+          target="_blank"
+          rel="noopener noreferrer"
+          className="flex flex-col items-center gap-3 rounded-2xl border border-slate-200 p-6 transition hover:border-ari-marino hover:bg-ari-marino/5"
+        >
+          <MessageCircle className="size-7 text-ari-marino" />
+          <div>
+            <p className="font-black">WhatsApp</p>
+            <p className="mt-1 text-sm text-slate-500">+57 301 613 8155</p>
+          </div>
+        </a>
+        <a
+          href={`mailto:${CONTACT_EMAIL}`}
+          className="flex flex-col items-center gap-3 rounded-2xl border border-slate-200 p-6 transition hover:border-ari-marino hover:bg-ari-marino/5"
+        >
+          <Mail className="size-7 text-ari-marino" />
+          <div>
+            <p className="font-black">Correo</p>
+            <p className="mt-1 text-sm text-slate-500">{CONTACT_EMAIL}</p>
+          </div>
+        </a>
+      </div>
+
+      <div className="mt-10 flex items-center justify-center gap-2 text-sm text-slate-500">
+        <MapPin className="size-4" />
+        Despachamos desde Santiago de Cali, Colombia
+      </div>
+
+      <Button asChild variant="primary" size="lg" className="mt-10">
+        <a href={WHATSAPP_URL} target="_blank" rel="noopener noreferrer">
+          <MessageCircle className="size-5" />
+          Escribirnos por WhatsApp
+        </a>
+      </Button>
+    </section>
+  );
+}

workloads/ecommerce/app/envios/page.tsx

@@ -0,0 +1,66 @@
+import type { Metadata } from "next";
+import { Calculator, Clock, MapPinned, Truck } from "lucide-react";
+
+export const metadata: Metadata = { title: "Envíos | ARI Shopping" };
+
+// ADR 0010 §2: el costo de envio se calcula en vivo con EnvioClick (peso +
+// direccion), no es un valor fijo -- el copy de abajo describe ese
+// comportamiento real, no un placeholder. Transportadoras reales
+// confirmadas en una cotizacion en vivo contra la API de EnvioClick
+// (PIBOX, COORDINADORA, ENVIA, RAPPI, TCC) -- EnvioClick cotiza entre
+// ellas y el sistema toma automaticamente la mas economica por pedido.
+const CARRIERS = ["Coordinadora", "Envía", "TCC", "Rappi", "Pibox"];
+
+export default function EnviosPage() {
+  return (
+    <section className="mx-auto max-w-3xl px-4 py-14 lg:py-20">
+      <span className="text-xs font-black uppercase tracking-[.18em] text-ari-coral">Ayuda</span>
+      <h1 className="mt-3 text-4xl font-black tracking-tight sm:text-5xl">Envíos</h1>
+      <p className="mt-5 text-lg leading-8 text-slate-600">
+        Hacemos envíos a nivel nacional desde nuestra bodega en Santiago de Cali, Valle del Cauca
+      </p>
+
+      <div className="mt-10 grid gap-6 sm:grid-cols-2">
+        <div className="rounded-2xl border border-slate-200 p-6">
+          <Calculator className="size-6 text-ari-marino" />
+          <h2 className="mt-3 font-black">Costo calculado en tiempo real</h2>
+          <p className="mt-2 text-sm leading-6 text-slate-600">
+            El valor del envío se calcula automáticamente según el peso de tu pedido y la dirección de entrega —
+            lo ves exacto en el checkout antes de pagar, nunca es una tarifa a ciegas.
+          </p>
+        </div>
+        <div className="rounded-2xl border border-slate-200 p-6">
+          <Truck className="size-6 text-ari-marino" />
+          <h2 className="mt-3 font-black">Transportadoras aliadas</h2>
+          <p className="mt-2 text-sm leading-6 text-slate-600">
+            Cotizamos automáticamente entre {CARRIERS.join(", ")} y asignamos la tarifa más conveniente para cada
+            pedido.
+          </p>
+        </div>
+        <div className="rounded-2xl border border-slate-200 p-6">
+          <Clock className="size-6 text-ari-marino" />
+          <h2 className="mt-3 font-black">Tiempos de entrega</h2>
+          <p className="mt-2 text-sm leading-6 text-slate-600">
+            Varían según la transportadora asignada y tu ciudad — una vez despachado tu pedido te compartimos el
+            número de guía para hacerle seguimiento.
+          </p>
+        </div>
+        <div className="rounded-2xl border border-slate-200 p-6">
+          <MapPinned className="size-6 text-ari-marino" />
+          <h2 className="mt-3 font-black">Cobertura</h2>
+          <p className="mt-2 text-sm leading-6 text-slate-600">
+            Envíos a todo el territorio nacional colombiano desde nuestra bodega en Santiago de Cali, Valle del Cauca
+          </p>
+        </div>
+      </div>
+
+      <p className="mt-10 text-sm text-slate-500">
+        ¿Tenés dudas puntuales sobre un pedido? Escribinos por{" "}
+        <a href="/contacto" className="font-bold text-ari-marino hover:underline">
+          nuestros canales de contacto
+        </a>
+        .
+      </p>
+    </section>
+  );
+}

workloads/ecommerce/app/preguntas-frecuentes/page.tsx

@@ -0,0 +1,72 @@
+import type { Metadata } from "next";
+import Link from "next/link";
+import { Accordion, AccordionContent, AccordionItem, AccordionTrigger } from "@/components/ui/accordion";
+
+export const metadata: Metadata = { title: "Preguntas frecuentes | ARI Shopping" };
+
+// Solo preguntas cuya respuesta es un hecho real del storefront (ver
+// ADR 0009/0010) -- nada de metodos de pago, plazos u opciones que no
+// esten realmente implementados.
+const FAQS: { question: string; answer: React.ReactNode }[] = [
+  {
+    question: "¿Qué métodos de pago aceptan?",
+    answer: "Pagás por PSE, con transferencia directa desde tu banco. Podés pagar como persona natural o jurídica.",
+  },
+  {
+    question: "¿A qué ciudades hacen envíos?",
+    answer: "A todo el territorio nacional colombiano. El costo del envío se calcula automáticamente según tu dirección y lo ves en el checkout antes de pagar.",
+  },
+  {
+    question: "¿Cuánto tarda en llegar mi pedido?",
+    answer: (
+      <>
+        Depende de la transportadora asignada y tu ciudad — más detalle en{" "}
+        <Link href="/envios" className="font-bold text-ari-marino hover:underline">
+          Envíos
+        </Link>
+        .
+      </>
+    ),
+  },
+  {
+    question: "¿Puedo cambiar un producto que no me sirvió?",
+    answer: (
+      <>
+        Sí, tenés 5 días hábiles desde que lo recibís y nosotros asumimos el envío de vuelta — más detalle en{" "}
+        <Link href="/cambios" className="font-bold text-ari-marino hover:underline">
+          Cambios
+        </Link>
+        .
+      </>
+    ),
+  },
+  {
+    question: "Tengo otra pregunta, ¿cómo los contacto?",
+    answer: (
+      <>
+        Escribinos por WhatsApp o correo desde{" "}
+        <Link href="/contacto" className="font-bold text-ari-marino hover:underline">
+          Contacto
+        </Link>
+        , te respondemos lo antes posible.
+      </>
+    ),
+  },
+];
+
+export default function PreguntasFrecuentesPage() {
+  return (
+    <section className="mx-auto max-w-3xl px-4 py-14 lg:py-20">
+      <span className="text-xs font-black uppercase tracking-[.18em] text-ari-coral">Ayuda</span>
+      <h1 className="mt-3 text-4xl font-black tracking-tight sm:text-5xl">Preguntas frecuentes</h1>
+      <Accordion type="single" collapsible className="mt-10">
+        {FAQS.map((faq) => (
+          <AccordionItem key={faq.question} value={faq.question}>
+            <AccordionTrigger>{faq.question}</AccordionTrigger>
+            <AccordionContent>{faq.answer}</AccordionContent>
+          </AccordionItem>
+        ))}
+      </Accordion>
+    </section>
+  );
+}

workloads/ecommerce/app/product/[slug]/page.tsx

@@ -1,7 +1,7 @@
 import type { Metadata } from "next";
 import { notFound } from "next/navigation";
 import { Accordion, AccordionContent, AccordionItem, AccordionTrigger } from "@/components/ui/accordion";
-import { MobileAddToCart } from "@/components/product/mobile-add-to-cart";
+import { ProductCard } from "@/components/product/product-card";
 import { ProductCarousel } from "@/components/product/product-carousel";
 import { ProductGallery } from "@/components/product/product-gallery";
 import { ProductPurchase } from "@/components/product/product-purchase";
@@ -24,7 +24,17 @@ export const dynamic = "force-dynamic";
 export async function generateMetadata({ params }: ProductPageProps): Promise<Metadata> {
   const { slug } = await params;
   const product = await getProductBySlug(slug);
-  return product ? { title: product.name, description: product.shortDescription, openGraph: { images: [product.image] } } : { title: "Producto" };
+  // notFound() se llama aquí (no solo en el componente de abajo) porque
+  // generateMetadata se resuelve por completo ANTES de que Next empiece a
+  // transmitir la respuesta -- el <Suspense> del navbar (categorías, ver
+  // navbar.tsx) hace que el layout raíz empiece a stream-ear con status 200
+  // antes de que un notFound() lanzado dentro del componente de la página
+  // pueda cambiarlo (confirmado en vivo: cualquier slug inexistente devolvía
+  // HTTP 200 con el contenido de app/not-found.tsx, rompiendo SEO/crawlers
+  // que sí miran el status code). Llamarlo aquí evita el problema porque esta
+  // fase bloquea el stream por diseño.
+  if (!product) notFound();
+  return { title: product.name, description: product.shortDescription, openGraph: { images: [product.image] } };
 }
 
 export default async function ProductPage({ params }: ProductPageProps) {
@@ -33,5 +43,84 @@ export default async function ProductPage({ params }: ProductPageProps) {
   if (!product) notFound();
   const products = await getProducts();
   const recommended = products.filter((candidate) => candidate.id !== product.id && (candidate.category === product.category || candidate.collection === product.collection)).slice(0, 8);
-  return <><section className="mx-auto grid max-w-7xl gap-10 px-4 py-10 lg:grid-cols-[1.08fr_.92fr] lg:py-16"><ProductGallery images={product.images} name={product.name} /><div><span className="text-xs font-black uppercase tracking-[.18em] text-ari-coral">{product.category} · {product.collection}</span><h1 className="mt-3 text-4xl font-black tracking-tight sm:text-6xl">{product.name}</h1><p className="mt-5 text-lg leading-8 text-slate-600">{product.description}</p><div className="mt-8"><ProductPurchase product={product} /></div><Accordion type="single" collapsible className="mt-8"><AccordionItem value="details"><AccordionTrigger>Detalles del producto</AccordionTrigger><AccordionContent>Marca: {product.brand}. Edad recomendada: {product.ageRange}. La disponibilidad y presentación final se confirman con Ari Shopping.</AccordionContent></AccordionItem><AccordionItem value="shipping"><AccordionTrigger>Envíos y entregas</AccordionTrigger><AccordionContent>Coordinamos envíos nacionales y entrega según ubicación. Los tiempos se confirman durante la cotización.</AccordionContent></AccordionItem></Accordion></div></section>{recommended.length > 0 && <section className="mx-auto max-w-7xl px-4 pb-24"><h2 className="mb-7 text-3xl font-black">También te puede gustar</h2><ProductCarousel products={recommended} /></section>}<MobileAddToCart product={product} /></>;
+  // Categoría distinta a propósito -- antes repetía los primeros 2 del
+  // mismo "recommended" que ya alimenta el carrusel de abajo (mismos
+  // productos en dos lugares de la página, reportado por el usuario).
+  // Un cross-sell real de otra categoría aporta algo que el carrusel no
+  // muestra, en vez de duplicarlo.
+  const crossCategory = products.filter((candidate) => candidate.id !== product.id && candidate.category !== product.category);
+  const crossSell = crossCategory.find((candidate) => candidate.available) ?? crossCategory[0];
+
+  return (
+    <>
+      {/* max-w-[1600px] (antes max-w-7xl/1280px) y una 3ra columna desde
+          xl -- aprovecha pantallas grandes en vez de dejar el buy box
+          apretado contra el texto o cortado por el panel de zoom de al
+          lado (ver ProductGallery). Por debajo de xl, el buy box cae al
+          flujo normal en la 2da columna, sin duplicar el componente en
+          el DOM.
+          El buy box ocupa las 2 filas (xl:row-span-2) para no quedar
+          atado a la altura de galería+descripción -- "También te puede
+          gustar" pasa a ser la 2da fila debajo de esas dos columnas
+          (xl:col-span-2), en paralelo al buy box sticky, en vez de
+          esperar a que termine la columna más alta antes de aparecer. */}
+      <section className="mx-auto grid max-w-[1600px] gap-x-10 gap-y-12 px-4 py-10 lg:grid-cols-[1.08fr_.92fr] lg:py-16 xl:grid-cols-[1.1fr_.75fr_360px] xl:grid-rows-[auto_auto]">
+        <ProductGallery images={product.images} name={product.name} />
+        <div className="min-w-0">
+          <span className="text-xs font-black uppercase tracking-[.18em] text-ari-coral">{product.category} · {product.collection}</span>
+          <h1 className="mt-3 text-4xl font-black tracking-tight sm:text-6xl">{product.name}</h1>
+          <p className="mt-5 text-sm leading-6 text-slate-600">{product.description}</p>
+          {/* Antes escondido detrás de un click en el acordeón --
+              siempre visible, estilo Amazon, con los mismos datos
+              reales que ya existían (marca/edad/categoría/colección),
+              sin inventar specs que el catálogo no tiene. */}
+          <h2 className="mb-4 mt-8 text-sm font-black uppercase tracking-wide text-slate-500">Detalles del producto</h2>
+          <dl className="grid grid-cols-2 gap-x-6 gap-y-4 rounded-2xl border border-slate-200 p-5 text-sm sm:grid-cols-4">
+            <div><dt className="text-slate-400">Marca</dt><dd className="mt-0.5 font-bold text-slate-900">{product.brand}</dd></div>
+            <div><dt className="text-slate-400">Edad recomendada</dt><dd className="mt-0.5 font-bold text-slate-900">{product.ageRange}</dd></div>
+            <div><dt className="text-slate-400">Categoría</dt><dd className="mt-0.5 font-bold text-slate-900">{product.category}</dd></div>
+            <div><dt className="text-slate-400">Colección</dt><dd className="mt-0.5 font-bold text-slate-900">{product.collection}</dd></div>
+          </dl>
+          <Accordion type="single" collapsible className="mt-6">
+            <AccordionItem value="shipping">
+              <AccordionTrigger>Envíos y entregas</AccordionTrigger>
+              <AccordionContent>Coordinamos envíos nacionales y entrega según ubicación. Los tiempos se confirman durante la cotización.</AccordionContent>
+            </AccordionItem>
+          </Accordion>
+        </div>
+        {/* Buy box estilo Amazon: precio/variantes/carrito en su propia
+            tarjeta, sticky desde xl mientras el resto de la pagina
+            scrollea. El cross-sell es de OTRA categoría a propósito --
+            evita repetir lo que ya muestra el carrusel de "También te
+            puede gustar" de abajo (mismo criterio de categoría/colección
+            que ese carrusel), aportando un producto genuinamente distinto
+            en vez de duplicado. */}
+        <div className="min-w-0 xl:sticky xl:top-24 xl:row-span-2 xl:self-start">
+          <div className="rounded-2xl border border-slate-200 p-6 shadow-sm">
+            <ProductPurchase product={product} />
+          </div>
+          {crossSell && (
+            <div className="mt-6">
+              <h2 className="mb-4 text-xs font-black uppercase tracking-[.14em] text-slate-500">También te puede interesar</h2>
+              <ProductCard product={crossSell} />
+            </div>
+          )}
+        </div>
+        {/* min-w-0 es necesario: sin esto, el carrusel horizontal
+            (overflow-x-auto interno) contaba como item de este grid, y su
+            ancho minimo intrinseco (la suma de TODAS las cards sin
+            wrappear, ya que el scroller no tiene flex-wrap) empujaba todo
+            el grid completo a ~800px en mobile -- afectaba a TODA la
+            columna compartida (imagen, titulo, specs), no solo al
+            carrusel. Confirmado en vivo: sin min-w-0 el grid medía 783px
+            en un viewport real de 380px; con min-w-0 vuelve a 380px. */}
+        {recommended.length > 0 && (
+          <div className="min-w-0 pb-16 lg:col-span-2">
+            <h2 className="mb-7 text-3xl font-black">También te puede gustar</h2>
+            <ProductCarousel products={recommended} />
+          </div>
+        )}
+      </section>
+    </>
+  );
 }

workloads/ecommerce/commerce/configmap.yaml

@@ -38,12 +38,13 @@ data:
   # reemplaza la tarifa fija. Solo config no sensible; ENVIOCLICK_API_KEY
   # va en secrets.template.yaml. ENVIOCLICK_SANDBOX=true usa el endpoint
   # de guía de pruebas (/shipment_sandbox) -- la cotización siempre usa
-  # tarifas reales, no tiene modo sandbox. Origen = bodega Bogotá
+  # tarifas reales, no tiene modo sandbox. Origen = bodega Santiago de
-  # ("Bodega principal ARI Shopping", sin dirección física real cargada
+  # Cali, Valle del Cauca ("Bodega principal ARI Shopping") -- corregido
-  # todavía -- ENVIOCLICK_ORIGIN_ADDRESS es un placeholder hasta que la
+  # 2026-09-12: el código DANE cargado originalmente era el de Bogotá
-  # haya).
+  # (11001000) por error; toda cotización real hecha antes de esta
+  # fecha calculó la tarifa desde el origen equivocado.
   ENVIOCLICK_SANDBOX: "true"
-  ENVIOCLICK_ORIGIN_DANE_CODE: "11001000"
+  ENVIOCLICK_ORIGIN_DANE_CODE: "76001000"
   ENVIOCLICK_ORIGIN_ADDRESS: "Cra 100 #42-65"
   ENVIOCLICK_ORIGIN_COMPANY: "ARI Shopping"
   ENVIOCLICK_ORIGIN_EMAIL: "[email protected]"

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.239
+          image: gitea.cruzcloud.net/devops/ecommerce-medusa:v1.0.265
           imagePullPolicy: IfNotPresent
           command:
             - node
@@ -86,7 +86,7 @@ spec:
 
       containers:
         - name: app
-          image: gitea.cruzcloud.net/devops/ecommerce-medusa:v1.0.239
+          image: gitea.cruzcloud.net/devops/ecommerce-medusa:v1.0.265
           imagePullPolicy: IfNotPresent
           envFrom:
             - configMapRef:

workloads/ecommerce/components/layout/footer.tsx

@@ -1,10 +1,51 @@
 import Link from "next/link";
 import { Facebook, Instagram, MessageCircle } from "lucide-react";
 
+// APP_VERSION la actualiza el propio CI (.gitea/workflows/build.yaml) al
+// mismo tiempo que el tag de la imagen -- antes decia "v4.1" fijo,
+// inutil para distinguir a simple vista si Staging y Produccion estan
+// en la misma version o no.
+const appVersion = process.env.APP_VERSION || "dev";
+
+// Las 4 paginas de "Ayuda" ya tienen contenido real (app/envios,
+// app/cambios, app/preguntas-frecuentes, app/contacto).
+const HELP_LINKS = [
+  { label: "Preguntas frecuentes", href: "/preguntas-frecuentes" },
+  { label: "Envíos", href: "/envios" },
+  { label: "Cambios", href: "/cambios" },
+  { label: "Contacto", href: "/contacto" },
+];
+
+// Cuentas reales confirmadas por el usuario (Instagram verificado en
+// vivo antes de linkearlo -- la primera cuenta sugerida, @arishopping,
+// no era la real). El link de WhatsApp usa el mismo numero real ya
+// confirmado en /contacto y en el fallback del checkout.
+const SOCIAL_LINKS = [
+  { label: "Instagram", href: "https://www.instagram.com/ari_shopping1/", Icon: Instagram },
+  { label: "Facebook", href: "https://www.facebook.com/share/1Dkmvko6HF/", Icon: Facebook },
+  { label: "WhatsApp", href: "https://wa.me/573016138155", Icon: MessageCircle },
+];
+
+const SHOP_LINKS = [
+  { label: "Novedades", href: "/catalog" },
+  { label: "Juguetes", href: "/catalog" },
+  { label: "Mochilas", href: "/catalog" },
+  { label: "Regalos", href: "/catalog" },
+];
+
 export function Footer() {
-  return <footer className="bg-ari-marino text-white"><div className="mx-auto grid max-w-7xl gap-10 px-4 py-14 sm:grid-cols-2 lg:grid-cols-4"><div><div className="flex flex-col items-start gap-3"><img src="/images/brand/logo-ari.svg" alt="ARI shopping" className="h-11 w-auto" width={200} height={64} />{/* eslint-disable-line @next/next/no-img-element -- vector propio, next/image no optimiza SVG sin habilitar dangerouslyAllowSVG */}<p className="text-xs text-white/60">Tesoros para cada aventura.</p></div><div className="mt-5 flex gap-3"><Instagram /><Facebook /><MessageCircle /></div></div><FooterColumn title="Compra" links={["Novedades", "Juguetes", "Mochilas", "Regalos"]} /><FooterColumn title="Ayuda" links={["Preguntas frecuentes", "Envíos", "Cambios", "Contacto"]} /><div><h3 className="font-black">Newsletter</h3><p className="mt-3 text-sm leading-6 text-white/60">Recibe lanzamientos y promociones especiales.</p><div className="mt-4 flex rounded-full bg-white p-1"><input className="min-w-0 flex-1 bg-transparent px-4 text-sm text-slate-950 outline-none" placeholder="Tu correo" /><button className="rounded-full bg-ari-coral px-4 text-sm font-black text-white">Unirme</button></div></div></div><div className="border-t border-white/10 py-5 text-center text-xs text-white/50">© 2026 ARI Shopping · Frontend headless v4.1 · GitOps</div></footer>;
+  return <footer className="bg-ari-marino text-white"><div className="mx-auto grid max-w-7xl gap-10 px-4 py-14 sm:grid-cols-2 lg:grid-cols-4"><div><div className="flex flex-col items-start gap-3"><img src="/images/brand/logo-ari.svg" alt="ARI shopping" className="h-11 w-auto" width={200} height={64} />{/* eslint-disable-line @next/next/no-img-element -- vector propio, next/image no optimiza SVG sin habilitar dangerouslyAllowSVG */}<p className="text-xs text-white/60">Tesoros para cada aventura.</p></div><div className="mt-5 flex gap-3">{SOCIAL_LINKS.map(({ label, href, Icon }) => <a key={label} href={href} target="_blank" rel="noopener noreferrer" aria-label={label} className="text-white/80 transition hover:text-ari-coral-claro"><Icon /></a>)}</div></div><FooterColumn title="Compra" links={SHOP_LINKS} /><FooterColumn title="Ayuda" links={HELP_LINKS} />{/* min-w-0: sin esto, un grid item de texto toma como minimo su ancho
+    max-content (una sola linea, "Recibe lanzamientos y promociones
+    especiales." sin wrappear, ~335px) en vez de dejarse achicar y
+    wrappear dentro del track del grid -- confirmado en vivo 2026-09-20
+    contra un viewport real de 320px: la columna entera del footer (y
+    con ella, la pagina completa) quedaba forzada a 335px de ancho por
+    este unico parrafo. Mismo bug de fondo que el ya documentado en
+    product-gallery.tsx/app/product/[slug]/page.tsx, en un grid en vez
+    de un overflow-x-auto. */}
+<div className="min-w-0"><h3 className="font-black">Newsletter</h3><p className="mt-3 text-sm leading-6 text-white/60">Recibe lanzamientos y promociones especiales.</p><div className="mt-4 flex rounded-full bg-white p-1"><input className="min-w-0 flex-1 bg-transparent px-4 text-sm text-slate-950 outline-none" placeholder="Tu correo" /><button className="rounded-full bg-ari-coral px-4 text-sm font-black text-white">Unirme</button></div></div></div><div className="border-t border-white/10 py-5 text-center text-xs text-white/50">© 2026 ARI Shopping · Frontend headless {appVersion} · GitOps</div></footer>;
 }
 
-function FooterColumn({ title, links }: { title: string; links: string[] }) {
+function FooterColumn({ title, links }: { title: string; links: { label: string; href: string }[] }) {
-  return <div><h3 className="font-black">{title}</h3><div className="mt-4 grid gap-3 text-sm text-white/60">{links.map((link) => <Link key={link} href="/catalog" className="hover:text-ari-coral-claro">{link}</Link>)}</div></div>;
+  return <div><h3 className="font-black">{title}</h3><div className="mt-4 grid gap-3 text-sm text-white/60">{links.map((link) => <Link key={link.label} href={link.href} className="hover:text-ari-coral-claro">{link.label}</Link>)}</div></div>;
 }

workloads/ecommerce/components/layout/navbar.tsx

@@ -261,10 +261,18 @@ function DepartmentsMegaMenu({ tree, isActive }: { tree: CategoryNode[]; isActiv
         onClick={() => setOpen((value) => !value)}
         aria-expanded={open}
         aria-haspopup="true"
+        aria-label="Departamentos"
         className={`flex items-center gap-1.5 ${pillClass(open)}`}
       >
         <LayoutGrid className="size-4" />
-        Departamentos
+        {/* Texto oculto en mobile: los 3 items de esta fila (menu, este
+            boton, "Todo") tienen shrink-0 -- ninguno se achica, asi que si
+            los tres no entran, desbordan la pagina entera (confirmado en
+            vivo 2026-09-20 contra 320px real: 14px de overflow horizontal
+            con el texto visible). No es un caso de min-w-0 faltante (ese
+            fix asume que el item PUEDE achicarse) -- ocultar la palabra
+            mas larga de la fila es lo que de verdad libera espacio. */}
+        <span className="hidden sm:inline">Departamentos</span>
         <ChevronDown className={`size-3.5 opacity-70 transition-transform ${open ? "rotate-180" : ""}`} />
       </button>
 

workloads/ecommerce/components/product/mobile-add-to-cart.tsx

@@ -1,25 +0,0 @@
-"use client";
-
-import { ShoppingBag } from "lucide-react";
-import { Button } from "@/components/ui/button";
-import type { Product } from "@/lib/headless/types";
-import { useCartStore } from "@/store/cart-store";
-
-export function MobileAddToCart({ product }: { product: Product }) {
-  const addItem = useCartStore((state) => state.addItem);
-  const outOfStock = product.variants[0]?.available === false;
-  return (
-    <div className="fixed inset-x-0 bottom-0 z-40 border-t border-slate-200 bg-white/95 p-3 shadow-2xl backdrop-blur lg:hidden">
-      <Button
-        variant="primary"
-        size="lg"
-        className="w-full"
-        disabled={outOfStock}
-        onClick={() => addItem(product, product.variants[0]?.id)}
-      >
-        <ShoppingBag />
-        {outOfStock ? "Agotado" : "Añadir al carrito"}
-      </Button>
-    </div>
-  );
-}

workloads/ecommerce/components/product/product-gallery.tsx

@@ -7,28 +7,82 @@ import { Dialog, DialogContent, DialogTrigger } from "@/components/ui/dialog";
 
 interface Offset { x: number; y: number }
 interface DragState { pointerId: number; startX: number; startY: number; originX: number; originY: number }
-interface HoverZoomOrigin { x: number; y: number }
+interface HoverZoomState {
+  lensLeft: number;
+  lensTop: number;
+  lensSize: number;
+  bgX: number;
+  bgY: number;
+  showPanel: boolean;
+  panelLeft: number;
+  panelTop: number;
+  panelSize: number;
+}
 
-// Zoom automatico al pasar el cursor (estilo lupa clasico de e-commerce)
+// Zoom estilo "lupa" de Amazon: un recuadro semitransparente sobre la
-// sobre la imagen principal -- solo mouse (mousemove no dispara de forma
+// imagen (la lupa) marca la region que se esta mirando, y un panel
-// continua en touch, asi que en mobile simplemente no aparece el efecto,
+// aparte a la derecha muestra esa misma region ampliada -- sin recortar
-// sin romper nada). Independiente del zoom interactivo del modal
+// nada de la pantalla ni pedirle al usuario que haga scroll para verlo
-// (click -> Dialog con scale/drag), que sigue igual.
+// completo (a diferencia de un primer intento que escalaba la imagen
+// in-place con transform, donde para ver el borde superior había que
+// mover el cursor fuera del viewport visible). Solo mouse (mousemove no
+// dispara de forma continua en touch); en mobile no aparece el efecto,
+// sin romper nada. Independiente del zoom interactivo del modal (click
+// -> Dialog con scale/drag), que sigue igual.
+//
+// El panel usa background-image con la foto completa (no la version ya
+// recortada por object-cover) a proposito -- escalar la imagen recortada
+// nunca iba a revelar las partes recortadas (ej. la cabeza de una figura
+// de accion en una foto vertical). background-size en un solo valor
+// (ancho%, alto en "auto") preserva el aspect ratio real de la foto
+// completa.
+//
+// El tamaño/posicion del panel se calculan en cada mousemove contra el
+// viewport real (window.innerWidth/innerHeight), no con un breakpoint
+// fijo tipo "lg:block" -- a resoluciones altas con la ventana angosta
+// (o el layout de la pagina dejando poco espacio a la derecha de la
+// imagen) un tamaño fijo terminaba saliéndose de la pantalla. Si no
+// entra un panel de al menos PANEL_MIN_SIZE, se cae automáticamente al
+// overlay in-place (misma imagen completa como fondo, dentro de la
+// propia caja) en vez de mostrar un panel cortado.
 const HOVER_ZOOM_SCALE = 2.2;
+const LENS_RATIO = 1 / HOVER_ZOOM_SCALE;
+const PANEL_MARGIN = 16;
+const PANEL_MAX_SIZE = 480;
+const PANEL_MIN_SIZE = 220;
+const VIEWPORT_EDGE_PADDING = 16;
 
 export function ProductGallery({ images, name }: { images: string[]; name: string }) {
   const [selected, setSelected] = useState(images[0] ?? "");
   const [open, setOpen] = useState(false);
   const [scale, setScale] = useState(1);
   const [offset, setOffset] = useState<Offset>({ x: 0, y: 0 });
-  const [hoverZoom, setHoverZoom] = useState<HoverZoomOrigin | null>(null);
+  const [hoverZoom, setHoverZoom] = useState<HoverZoomState | null>(null);
   const drag = useRef<DragState | null>(null);
 
   const trackHoverZoom = (event: MouseEvent<HTMLButtonElement>) => {
     const rect = event.currentTarget.getBoundingClientRect();
+    const lensSize = rect.width * LENS_RATIO;
+    const cursorX = event.clientX - rect.left;
+    const cursorY = event.clientY - rect.top;
+    const lensLeft = Math.min(Math.max(cursorX - lensSize / 2, 0), rect.width - lensSize);
+    const lensTop = Math.min(Math.max(cursorY - lensSize / 2, 0), rect.height - lensSize);
+
+    const availableWidth = window.innerWidth - rect.right - PANEL_MARGIN - VIEWPORT_EDGE_PADDING;
+    const availableHeight = window.innerHeight - VIEWPORT_EDGE_PADDING * 2;
+    const panelSize = Math.min(PANEL_MAX_SIZE, availableWidth, availableHeight);
+    const panelTop = Math.min(Math.max(rect.top, VIEWPORT_EDGE_PADDING), window.innerHeight - panelSize - VIEWPORT_EDGE_PADDING);
+
     setHoverZoom({
-      x: ((event.clientX - rect.left) / rect.width) * 100,
+      lensLeft,
-      y: ((event.clientY - rect.top) / rect.height) * 100,
+      lensTop,
+      lensSize,
+      bgX: (lensLeft / (rect.width - lensSize)) * 100,
+      bgY: (lensTop / (rect.height - lensSize)) * 100,
+      showPanel: panelSize >= PANEL_MIN_SIZE,
+      panelLeft: rect.right + PANEL_MARGIN,
+      panelTop,
+      panelSize,
     });
   };
 
@@ -55,28 +109,91 @@ export function ProductGallery({ images, name }: { images: string[]; name: strin
   };
 
   return (
-    <div className="grid gap-4 lg:grid-cols-[86px_1fr]">
+    <div className="min-w-0 grid gap-4 lg:grid-cols-[86px_1fr]">
+      {/* min-w-0: esta tira de miniaturas es un overflow-x-auto (scroll
+          horizontal) igual que el carrusel de "También te puede gustar"
+          en app/product/[slug]/page.tsx -- mismo bug si este componente
+          termina como item de un grid externo sin min-w-0: para productos
+          con muchas fotos, el ancho minimo intrinseco de TODAS las
+          miniaturas sin wrappear puede forzar overflow horizontal en toda
+          la pagina en mobile. */}
       <div className="order-2 flex gap-3 overflow-x-auto lg:order-1 lg:flex-col">
-        {images.map((image) => <button type="button" key={image} onClick={() => { setSelected(image); reset(); }} className={`relative aspect-square w-20 shrink-0 overflow-hidden rounded-2xl border-2 ${selected === image ? "border-fuchsia-500" : "border-transparent"}`}><Image src={image} alt="" fill sizes="80px" className="object-cover" /></button>)}
+        {/* object-contain (no object-cover): fotos de producto con relacion
+            de aspecto muy vertical (ej. 933x1500, confirmado en vivo para
+            este catalogo) perdian la cabeza o los pies recortados al forzar
+            el cuadrado con cover -- reportado por el usuario viendo las
+            miniaturas. contain deja la miniatura completa siempre, con
+            "letterbox" del mismo bg-slate-50 que usa la imagen principal. */}
+        {images.map((image) => <button type="button" key={image} onClick={() => { setSelected(image); reset(); }} onMouseEnter={() => { setSelected(image); reset(); }} className={`relative aspect-square w-20 shrink-0 overflow-hidden rounded-2xl border-2 bg-slate-50 ${selected === image ? "border-fuchsia-500" : "border-transparent"}`}><Image src={image} alt="" fill sizes="80px" className="object-contain" /></button>)}
       </div>
+      <div className="relative order-1 lg:order-2">
         <Dialog open={open} onOpenChange={changeOpen}>
           <DialogTrigger asChild>
             <button
               type="button"
-            className="group relative order-1 aspect-square cursor-zoom-in overflow-hidden rounded-[2rem] bg-slate-50 lg:order-2"
+              className="group relative aspect-square w-full cursor-zoom-in overflow-hidden rounded-[2rem] bg-slate-50"
               onMouseMove={trackHoverZoom}
               onMouseLeave={() => setHoverZoom(null)}
             >
+              {/* unoptimized a proposito: confirmado en vivo (createImageBitmap
+                  sobre los bytes reales vs. el <img> renderizado) que a DPR
+                  alto (2.6+, cualquier Android real) Chromium reporta
+                  naturalWidth/Height de un candidato del srcset mucho más
+                  chico del que dice currentSrc -- bug del propio motor de
+                  Chromium en la selección de candidato con sizes="100vw" en
+                  fill, no algo corrupto en el archivo ni en nuestro caché
+                  (el archivo decodifica perfecto vía fetch+createImageBitmap
+                  fuera de <img>). Reproducido igual en Chrome y Edge Android
+                  (ambos Chromium) y en Chromium headless. unoptimized deja
+                  un solo recurso real por foto -- sin candidatos entre los
+                  que el bug pueda elegir mal. */}
+              {/* object-contain (no object-cover): mismo motivo que las
+                  miniaturas -- fotos verticales (933x1500 confirmado en
+                  este catalogo) perdian la cabeza al forzar el cuadrado.
+                  Reportado en vivo: al seleccionar esa foto, Buzz aparecia
+                  sin cabeza en la imagen principal. */}
               <Image
                 src={selected}
                 alt={name}
                 fill
                 priority
-              sizes="(max-width: 1024px) 100vw, 50vw"
+                unoptimized
-              className="object-cover transition-transform duration-150 ease-out"
+                className="object-contain"
+              />
+              {/* Lupa: recuadro que marca la region ampliada -- solo cuando
+                  hay lugar real para el panel de al lado (showPanel,
+                  calculado contra el viewport real, no un breakpoint
+                  fijo). Sin espacio para el panel se usa el overlay
+                  in-place como fallback, para cualquier resolucion. */}
+              {hoverZoom?.showPanel && (
+                <div
+                  aria-hidden
+                  data-testid="gallery-lens"
+                  className="pointer-events-none absolute border-2 border-white bg-white/25 shadow-lg"
+                  style={{ left: hoverZoom.lensLeft, top: hoverZoom.lensTop, width: hoverZoom.lensSize, height: hoverZoom.lensSize }}
+                />
+              )}
+              <div
+                aria-hidden
+                data-testid="gallery-inplace-overlay"
+                className="pointer-events-none absolute inset-0 bg-slate-50 transition-opacity duration-150 ease-out"
                 style={{
-                transform: `scale(${hoverZoom ? HOVER_ZOOM_SCALE : 1})`,
+                  opacity: hoverZoom && !hoverZoom.showPanel ? 1 : 0,
-                transformOrigin: hoverZoom ? `${hoverZoom.x}% ${hoverZoom.y}%` : "center",
+                  // Comillas dentro de url() a proposito: sin ellas, un
+                  // espacio o parentesis literal en el nombre de archivo
+                  // (ej. "descarga (4)-xxx.png", el patron por defecto de
+                  // Chrome al descargar una imagen sin renombrarla -- asi
+                  // quedan las subidas manuales, a diferencia de las
+                  // importadas por CSV) rompe la sintaxis de url() sin
+                  // comillas -- el navegador descarta el valor completo en
+                  // silencio (backgroundImage queda "none"). Confirmado en
+                  // vivo 2026-09-20: reportado por el usuario como "el zoom
+                  // interactivo no se visualiza" solo en fotos subidas a
+                  // mano por el admin, nunca en las de CSV.
+                  backgroundImage: `url("${selected}")`,
+                  backgroundRepeat: "no-repeat",
+                  backgroundSize: `${HOVER_ZOOM_SCALE * 100}%`,
+                  backgroundPosition: hoverZoom ? `${hoverZoom.bgX}% ${hoverZoom.bgY}%` : "center",
                 }}
               />
               <span className="absolute bottom-5 right-5 inline-flex items-center gap-2 rounded-full bg-white px-4 py-2 text-xs font-black shadow-xl"><ZoomIn className="size-4" />Zoom interactivo</span>
@@ -86,7 +203,7 @@ export function ProductGallery({ images, name }: { images: string[]; name: strin
           <div className="grid min-h-[70vh] grid-rows-[1fr_auto]">
             <div className="relative overflow-hidden bg-slate-950" onWheel={wheel} onPointerDown={pointerDown} onPointerMove={pointerMove} onPointerUp={pointerEnd} onPointerCancel={pointerEnd} onDoubleClick={() => applyScale(scale > 1 ? 1 : 2)} style={{ touchAction: "none", cursor: scale > 1 ? "grab" : "zoom-in" }}>
               <div className="absolute inset-6 transition-transform duration-100 will-change-transform" style={{ transform: `translate3d(${offset.x}px, ${offset.y}px, 0) scale(${scale})` }}>
-                <Image src={selected} alt={name} fill sizes="95vw" className="select-none object-contain" draggable={false} />
+                <Image src={selected} alt={name} fill unoptimized className="select-none object-contain" draggable={false} />
               </div>
               <div className="pointer-events-none absolute left-5 top-5 rounded-full bg-black/65 px-3 py-1.5 text-xs font-black text-white backdrop-blur">Rueda o botones para acercar · Arrastra para mover</div>
             </div>
@@ -100,6 +217,27 @@ export function ProductGallery({ images, name }: { images: string[]; name: strin
           </div>
           </DialogContent>
         </Dialog>
+
+        {hoverZoom?.showPanel && (
+          <div
+            aria-hidden
+            data-testid="gallery-zoom-panel"
+            className="pointer-events-none fixed z-30 overflow-hidden rounded-[2rem] border border-slate-200 bg-white shadow-2xl"
+            style={{
+              left: hoverZoom.panelLeft,
+              top: hoverZoom.panelTop,
+              width: hoverZoom.panelSize,
+              height: hoverZoom.panelSize,
+              // Ver el comentario en el overlay in-place de arriba -- mismo
+              // fix, mismo motivo (comillas necesarias dentro de url()).
+              backgroundImage: `url("${selected}")`,
+              backgroundRepeat: "no-repeat",
+              backgroundSize: `${HOVER_ZOOM_SCALE * 100}%`,
+              backgroundPosition: `${hoverZoom.bgX}% ${hoverZoom.bgY}%`,
+            }}
+          />
+        )}
+      </div>
     </div>
   );
 }

workloads/ecommerce/components/product/product-purchase.tsx

@@ -1,6 +1,7 @@
 "use client";
 
-import { CheckCircle2, ShoppingBag, TriangleAlert, Truck, XCircle } from "lucide-react";
+import { CheckCircle2, RotateCcw, ShoppingBag, TriangleAlert, Truck, XCircle } from "lucide-react";
+import Link from "next/link";
 import { useState } from "react";
 import { Button } from "@/components/ui/button";
 import type { Product } from "@/lib/headless/types";
@@ -40,11 +41,14 @@ export function ProductPurchase({ product }: { product: Product }) {
         <strong className="text-3xl font-black">{formatMoney(product.price, product.currency)}</strong>
         {product.compareAtPrice && <del className="text-slate-400">{formatMoney(product.compareAtPrice, product.currency)}</del>}
       </div>
-      {/* oculto en mobile: MobileAddToCart (barra fija abajo, lg:hidden) ya cubre esa misma accion ahi -- sin el hidden aqui, ambos se mostraban a la vez. */}
+      {/* Un solo botón, visible también en mobile -- sin barra flotante
+          aparte (se probó, pero terminaba tapando contenido de abajo al
+          scrollear, ej. "También te puede interesar"; el usuario pidió
+          sacarla y dejar el botón normal como en la mayoría de tiendas). */}
       <Button
         variant="primary"
         size="lg"
-        className="hidden w-full lg:inline-flex"
+        className="w-full"
         disabled={outOfStock}
         onClick={() => addItem(product, variantId)}
       >
@@ -73,6 +77,21 @@ export function ProductPurchase({ product }: { product: Product }) {
           Envíos nacionales
         </span>
       </div>
+      {/* Franja de confianza real (estilo Walmart) -- enlaza a las
+          páginas reales de /envios y /cambios en vez de repetir texto
+          suelto, con los datos reales que confirmó el usuario (5 días
+          hábiles, envío de vuelta a cargo de ARI Shopping). Nada
+          inventado: mismas políticas ya publicadas en el footer. */}
+      <div className="mt-3 grid gap-2 text-sm">
+        <Link href="/envios" className="flex items-center gap-2 font-bold text-slate-600 hover:text-ari-marino hover:underline">
+          <Truck className="size-4 text-cyan-600" />
+          Envíos calculados en el checkout · ver detalles
+        </Link>
+        <Link href="/cambios" className="flex items-center gap-2 font-bold text-slate-600 hover:text-ari-marino hover:underline">
+          <RotateCcw className="size-4 text-ari-marino" />
+          Cambios en 5 días hábiles, envío de vuelta gratis
+        </Link>
+      </div>
     </div>
   );
 }

workloads/ecommerce/frontend/patches/deployment.yaml

@@ -25,8 +25,14 @@ spec:
         runAsUser: 1001
       containers:
         - name: app
-          image: gitea.cruzcloud.net/devops/ecommerce-frontend:v1.0.240
+          image: gitea.cruzcloud.net/devops/ecommerce-frontend:v1.0.275
           env:
+            # La actualiza el mismo paso del CD (.gitea/workflows/build.yaml)
+            # que bumpea el tag de la imagen -- el footer la lee
+            # (process.env.APP_VERSION) para mostrar la versión real
+            # desplegada en vez de un "v4.1" fijo.
+            - name: APP_VERSION
+              value: v1.0.275
             - name: HEADLESS_PROVIDER
               value: medusa
             - name: MEDUSA_BACKEND_URL

workloads/ecommerce/lib/headless/providers/medusa.ts

@@ -111,14 +111,26 @@ async function medusaFetch<T>(
 
   const publishableKey = process.env.MEDUSA_PUBLISHABLE_KEY;
 
+  // Sin next.revalidate/tags a proposito (reportado por el usuario
+  // 2026-09-20: imagenes editadas a mano en Medusa no se reflejaban en
+  // el storefront, pero por CSV si). Causa real: frontend-deploy corre 2
+  // replicas sin cacheHandler compartido -- cada pod tenia su propio
+  // cache en memoria de este fetch (next.revalidate:60), y el POST de
+  // /api/revalidate (revalidateTag) del subscriber de Medusa solo le
+  // llegaba a UNO de los dos pods via el Service, dejando al otro
+  // sirviendo la respuesta vieja hasta que el TTL expirara solo. Una
+  // edicion puntual + revisar al toque tenia ~50% de chance de pegarle
+  // al pod stale; una importacion CSV (minutos de duracion) le daba
+  // tiempo de sobra al TTL para expirar en ambos pods, disimulando el
+  // mismo bug. Las paginas que consumen esto ya son force-dynamic /
+  // dinamicas por diseño (ver comentario en app/page.tsx y
+  // app/product/[slug]/page.tsx) -- este next.revalidate competia contra
+  // esa intencion en vez de cumplirla. Sin este bloque, Next 15 no
+  // cachea el fetch por default dentro de una ruta dinamica.
   const response = await fetch(url, {
     headers: publishableKey
       ? { "x-publishable-api-key": publishableKey }
       : undefined,
-    next: {
-      revalidate: 60,
-      tags: ["medusa-products"],
-    },
   });
 
   if (!response.ok) {