Merge branch 'fix/promote-script-sin-perl-2026-09-20'

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

promote-to-production.sh

@@ -1,12 +1,17 @@
 #!/usr/bin/env bash
 set -Eeuo pipefail
 
-# Promueve el tag de imagen del frontend actualmente desplegado en Staging
+# OBSOLETO como camino normal desde 2026-09-20: la promoción de Staging a
-# (workloads/ecommerce-staging/frontend/patches/deployment.yaml) al
+# Producción ahora corre sola dentro de .gitea/workflows/build.yaml (step
-# manifiesto real de Producción (workloads/ecommerce/frontend/patches/
+# "Promover a Producción (CD)"), en el mismo job que ya despliega a
-# deployment.yaml). Es la contraparte manual del job "Actualizar
+# Staging -- decisión del usuario de eliminar el gate humano entre los
-# Manifiesto GitOps (CD)" de .gitea/workflows/build.yaml, que desde
+# dos ambientes. En uso normal este script ya no hace nada (Producción
-# 2026-09-14 solo actualiza Staging automáticamente en cada push a main.
+# va a estar al día apenas termine el pipeline).
+#
+# Se conserva solo como herramienta de excepción/rollback manual --
+# ej. forzar Producción a una versión de Staging vieja sin pasar por un
+# build nuevo. Mismo sed/perl que el step automático del pipeline, con
+# la diferencia de que este sí pide confirmación interactiva.
 #
 # Asume que este repo (scripts) y apps-registry están clonados como
 # hermanos bajo el mismo directorio del lab (mismo layout que
@@ -49,8 +54,15 @@ git checkout -B main origin/main
 sed -i -E "s|(image: ${IMAGE_NAME}:).*|\1${STAGING_VERSION}|g" "${PROD_MANIFEST}"
 
 # Mismo bump que hace build.yaml en Staging -- el footer lee APP_VERSION
-# para mostrar la version real desplegada.
+# para mostrar la version real desplegada. awk en vez de perl (usado en
-perl -0777 -pi -e "s/(- name: APP_VERSION\n\s*value: ).*/\${1}${STAGING_VERSION}/" "${PROD_MANIFEST}"
+# build.yaml, donde sí está disponible porque corre en un runner
+# ubuntu-latest): el host real de ZimaOS donde se corre este script a
+# mano no trae perl instalado (confirmado en vivo 2026-09-20), a
+# diferencia de sed/awk que sí son parte del sistema base.
+awk -v ver="${STAGING_VERSION}" '
+  /- name: APP_VERSION/ { print; getline; sub(/value:.*/, "value: " ver); print; next }
+  { print }
+' "${PROD_MANIFEST}" > "${PROD_MANIFEST}.tmp" && mv "${PROD_MANIFEST}.tmp" "${PROD_MANIFEST}"
 
 git add "${PROD_MANIFEST}"
 if git diff --cached --quiet; then

tmux-host/healthcheck.sh

@@ -114,10 +114,14 @@ launch_claude_in_session() {
   # sin la flag, "remoteEnabled" queda en false para siempre porque nadie
   # la pide). El nombre de sesion remota usa el hostname del contenedor
   # (ZimaOS) como prefijo por defecto.
-  if tmux send-keys -t "$SESSION" "claude --remote-control" Enter 2>>"$LOG_FILE"; then
+  # --continue (-c): retoma la conversacion mas reciente en WORKDIR en vez
-    log "TMUX: 'claude --remote-control' lanzado dentro de la sesion recien creada"
+  # de arrancar una sesion en blanco cada vez que se recrea el pane (reinicio
+  # del NAS, crash del contenedor, etc). Si no hay conversacion previa en el
+  # directorio, el propio CLI arranca una nueva sin error.
+  if tmux send-keys -t "$SESSION" "claude --remote-control --continue" Enter 2>>"$LOG_FILE"; then
+    log "TMUX: 'claude --remote-control --continue' lanzado dentro de la sesion recien creada"
   else
-    log "TMUX: ERROR al lanzar 'claude --remote-control' dentro de la sesion recien creada"
+    log "TMUX: ERROR al lanzar 'claude --remote-control --continue' dentro de la sesion recien creada"
   fi
 }