4.8 KiB
Herramienta Browser para OpenCode: idea y funcionamiento
Proposito
Este documento recoge ideas, acuerdos y criterios sobre la futura herramienta browser para OpenCode.
Su objetivo es servir como espacio vivo de trabajo mientras seguimos conversando sobre posibilidades, tecnologias, formas de implementacion y decisiones funcionales, antes de pasar a fases de diseno tecnico o construccion detallada.
Idea general de la herramienta
La herramienta permitira que OpenCode pueda usar un navegador para probar proyectos del workspace, moviendose por la aplicacion e interactuando con ella de forma similar a como lo haria un usuario real.
La referencia funcional buscada es un comportamiento parecido al de Antigravity: navegar por la app, ejecutar flujos, interactuar con la interfaz y comprobar si la funcionalidad desarrollada responde como se espera.
Vision funcional inicial
Cuando la herramienta este hecha, se espera que pueda:
- abrir la aplicacion objetivo en un navegador controlado
- recorrer pantallas y flujos reales
- hacer acciones de usuario como clic, escritura, seleccion, scroll y navegacion
- comprobar resultados esperados en cada paso
- recoger evidencia util cuando algo falle o cuando una comprobacion deba quedar registrada
- devolver al agente informacion util sobre lo ocurrido durante la prueba
Modos de ejecucion
Visible como modo por defecto
El modo visible sera el modo principal de uso de la herramienta.
Se considera el modo mas adecuado cuando lo que se quiere comprobar esta ligado a la interaccion real con la aplicacion y a la experiencia de uso:
- comportamiento de la interfaz
- navegacion entre pantallas
- interacciones propias de usuario
- validacion funcional de flujos completos
- observacion directa de lo que ocurre en pantalla
Headless como modo no principal
El modo headless no sera el comportamiento por defecto.
Se utilizara cuando lo que se quiera comprobar no dependa principalmente de la interaccion visible de usuario, sino del comportamiento interno o tecnico del sistema, por ejemplo:
- comunicacion con backend
- entradas y salidas de informacion
- interacciones con disco, almacenamiento o estado interno
- validaciones tecnicas no centradas en UX
Forma de uso esperada
- El agente podra usar esta herramienta igual que usa el resto de herramientas, cuando la necesite para resolver la tarea que este realizando.
- El usuario tambien podra pedir expresamente al agente que use la herramienta browser para una tarea concreta.
- Debe existir una forma de activar o desactivar su uso segun prefiera el usuario.
- El agente debera respetar esa configuracion para no usar la herramienta cuando el usuario no quiera que intervenga.
Criterio estructural principal
La herramienta debe construirse como una solucion externa a OpenCode.
Esto implica que tanto el browser como su forma de instalacion, ejecucion e instrucciones de uso para el agente deben quedar fuera del nucleo interno de OpenCode, para que una actualizacion de OpenCode no afecte al funcionamiento de esta herramienta.
El objetivo es que la integracion sea estable, desacoplada y mantenible, evitando depender de modificaciones internas del proyecto OpenCode.
Telemetria en tiempo real (fase posterior)
En la version actual, la herramienta funciona con un modelo request/response por accion:
- el agente invoca una tool
- la tool ejecuta
- la tool devuelve resultado estructurado
Con lo ya implementado (diagnostico, artifacts, reportes), este modelo cubre bien el uso principal en desarrollo.
Que aportaria incluir telemetria en tiempo real mas adelante
- stream en vivo de eventos de ejecucion (consola, red, errores, cambios de estado)
- observacion continua sin esperar al fin de cada accion
- mejor soporte para casos intermitentes o muy complejos
- mejor operacion para soporte de clientes cuando haya que mirar una sesion en directo
Que haria falta para incluirla
- un servicio paralelo local (sidecar) separado del MCP principal
- un canal de eventos push (
WebSocketoSSE) - un esquema de eventos estandar para pasos, diagnostico y estado
Decision actual
- no incluir telemetria en tiempo real en esta version
- mantenerla documentada como mejora de continuidad para fases posteriores
- priorizar primero estabilidad funcional, diagnostico estructurado y reporte util para desarrollo
Por definir
- si
external_webdebe estar habilitado o deshabilitado por defecto - si desde la v1 debe existir allowlist de dominios permitidos
- si las acciones sensibles deben requerir confirmacion explicita del usuario
- como se gestionaran
CAPTCHA,2FAo pasos que requieran intervencion manual
Estado del documento
Documento inicial abierto para seguir recogiendo ideas y acuerdos antes de entrar en diseno tecnico, arquitectura o implementacion.