Auth: ANTHROPIC_API_KEY_FILE queda vacío por defecto — claude -p usa el
login de suscripción ya activo (~/.claude/.credentials.json) en vez de
una API key root-only. Se descartó ese diseño en vivo al confirmar que
no había API key real disponible; además elimina la necesidad de crear
secretos root-only vía sudo. Consecuencia: el futuro servicio systemd
debe correr como devops, no root. CLAUDE_BIN/KUBECTL_BIN se agregan por
ruta absoluta (ninguno está en el PATH de root/systemd).
Bugs encontrados y corregidos durante la prueba end-to-end contra el
cluster real (deployment canario desechable):
- execute_corrective_action se invocaba en un subshell ($()), perdiendo
sus variables de resultado (LAST_ACTION_*) -> crash "unbound
variable". Ahora usa el exit status de la función, invocada directo.
- DRY_RUN marcaba blocked=true en state.json como si la acción hubiera
sido real, contaminando una corrida real posterior sobre el mismo
recurso. Ahora el estado solo se actualiza fuera de DRY_RUN.
También: GITEA_TOKEN_FILE pasa a /DATA (dueño devops, sin sudo), y
media.cruzcloud.net se excluye de PUBLIC_DOMAINS (uso personal, no es
parte del lab).
Prueba e2e completa documentada en apps-registry:
docs/arquitectura/agente-monitoreo.md.
Invoca claude -p con --allowedTools "" y --json-schema para que el
modelo solo devuelva una decisión estructurada, nunca ejecute comandos
directamente. Se descartó dar un Bash tool con patrón por prefijo tras
confirmar en vivo que --allowedTools "Bash(cmd)" también permite
"cmd && inyectado" (coincidencia por prefijo, no exacta) — inseguro
para comandos root-capaces como kubectl/docker. El wrapper bash es el
único ejecutor, y revalida cada decisión contra su propio cálculo de
elegibilidad (umbral 10min, rate limit 30min, ventana horaria para
medusa-deploy, bloqueo tras intento sin recuperación) antes de actuar.
Validado en vivo (dry-run) contra el cluster real hasta el paso de
invocar claude -p, que falla correctamente por falta del secreto
ANTHROPIC_API_KEY_FILE (no creado a propósito, ver README).
Documents and makes repeatable the Admin API writes for Fase 5 Etapa 2
sub-fase 1: assign real Medusa collections (Toy Story, Intensamente,
Lilo & Stitch, Universo Marvel, Reino de Frozen) to 9 legacy products,
and the missing "Figuras de accion" category to cybertron-sentinel.
Categories for the 17 legacy products were already correct and are
untouched.
Confirmado empiricamente: el limite real esta entre payload interno 1420
(OK) y 1450 (100% perdida sin ICMP, blackhole real). k3s no expone
--flannel-mtu en esta version, asi que se aplica en vivo sobre la interfaz
de cada nodo (no persiste en config, se reaplica en cada start/create).
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_011FqYP3Wf1W63Qmh7qgXAAT
El contenedor gitea-runner se creaba sin ningun limite de CPU/memoria
(docker run plano), compitiendo directamente con gitea (que ademas
tenia cpu-shares=90, muy por debajo del default de Docker de 1024).
Causa raiz confirmada en vivo el 2026-08-15: durante un build pesado
de commerce-backend, tanto gitea como gitea-runner se reiniciaron
solos (ExitCode=0, RestartCount=0 en ambos -- restart limpio disparado
externamente, no un crash) coincidiendo con 502 Bad Gateway del runner
y memoria del host casi agotada. Mismo patron ya visto y documentado
en incidentes anteriores (2026-07-30, 2026-08-11).
Se agrega --cpu-shares 512 (menos prioridad relativa que gitea) y
--memory 8g / --memory-swap 10g al runner. El fix de cpu-shares de
gitea (90 -> 1024) va en docker-compose.yml, fuera de este repo -- no
tengo acceso de escritura root a ese archivo, queda para aplicar
manualmente.
Este cambio solo afecta a la proxima creacion del contenedor
(create_gitea_runner_container es idempotente); no se aplica solo al
contenedor que ya esta corriendo.
Necesario para que el subscriber revalidate-storefront.ts (repo
apps-registry, rama fix/medusa-price-instant-revalidate) pueda llamar
a POST /api/revalidate en el storefront con autenticación.
create-commerce-secrets.sh genera el valor y lo imprime (única
excepción a "no imprimir credenciales") porque hay que pegarlo tal
cual en create-storefront-secret.sh: ambos secrets necesitan el mismo
valor.
Postgres corre sin SSL configurado (imagen postgres:17-alpine estandar,
sin certificados). El cliente pg de Medusa intenta negociar SSL por
defecto al no encontrar sslmode explicito en la URL, lo que cuelga 10s
y hace fallar el initContainer migrations con CrashLoopBackOff.
Verificado con un pod efimero usando la imagen real de la app: con
sslmode=disable la migracion conecta al instante y corre exitosamente.
Documenta el flujo reproducible ejecutado el 2026-08-09: deteccion de
inconsistencia, rama, commit, intento SSH fallido por proxy Cloudflare,
fallback a HTTPS con credential helper, push y merge del PR.
Persistencia Real: Al usar los volúmenes -v hacia /DATA/AppData/..., los datos de ArgoCD no desaparecerán nunca aunque borres el clúster.
Modo "Insecure": He automatizado el patch de server.insecure, eliminando la fricción con los certificados SSL de tu Nginx Proxy Manager.
Idempotencia: El script intenta borrar el clúster y recrearlo, asegurando que siempre partas de un estado limpio pero con tus datos intactos en el disco.
Recuperación automática: Al incluir el docker update --restart=always, si ZimaOS se reinicia, todos los componentes del clúster volverán a subir solos sin intervención manual.
devops
