[Research/Implementation] Evaluate OpenCode V2 2.2.0–2.2.5 improvements for OlympusAgents #101

Objetivo

Evaluar de manera focalizada y con evidencia las capacidades y cambios entre OpenCode V2 2.2.0 y 2.2.5 para decidir cuáles aportan valor real a OlympusAgents, cuáles requieren compatibilidad/ajustes y cuáles deben diferirse. Para oportunidades aprobadas, definir cortes de implementación pequeños y verificables, evitando duplicar capacidades nativas.

Separación de responsabilidades: el estudio exhaustivo del /goal nativo y la portabilidad del workflow Goal-Driven pertenece a #100. La filosofía y las autorizaciones siguen regidas por #92, que es una referencia permanente, no un ticket implementable.

Fuentes upstream

• CHANGELOG oficial de OpenCode V2.
• Instrucciones de sesión por clave — #56550.
• Subscripciones de eventos filtradas — #58864.
• Nuevo Goal Mode — #59437 (análisis dedicado: [Research] Native /goal vs. reusable evidence-gated mission workflow #100).
• Managed integration/MCP/skill/plugin policies — #60315.
• Schedules en serve y coordinación — #60478.
• Artifacts experimentales — #60351.
• Buffer porcentual de compaction — #60647.

Inventario de oportunidades: priorizar por impacto demostrado

Además, registrar mejoras del host que podríamos aprovechar sin desarrollar código propio: diagnósticos read/edit, alias bash→shell con permisos existentes, correcciones de razonamiento, persistent PTY y cambios de actualización del servicio Windows.

Bloque A — Compatibility gate antes de adoptar

• Fijar versión/commit oficial publicado y verificar el gate local de última versión de OpenCode publicada en GitHub antes de cualquier futura release de Olympus (sin suponer que 2.2.5 seguirá siendo la última).
• Inventariar imports, SDK/protocol, plugins, extensiones TUI, subprocesos, scripts Windows/WSL y dependencias reales de Olympus; identificar usos de:
  • cambio @opencode/ai root Promise / @opencode/ai/effect y entrypoints retirados;
  • OpenTUI mínimo 0.8 desde 2.2.3;
  • métodos experimentales bajo client.experimental, sin depender ciegamente de alias deprecados;
  • acción GitHub de OpenCode retirada en 2.2.0;
  • nuevas políticas e implicaciones de bash/ shell.
• Comprobar las rutas TUI, run --standalone, SDK y host realmente usadas. No extrapolar un PASS de fixture a toda la instalación.
• Verificar explícitamente autenticación ChatGPT por suscripción y ausencia de nuevas rutas con API keys/servicios de pago; OAuth configurado por sí solo no demuestra facturación excluida. Si falta evidencia, documentar BLOCKED/UNKNOWN sin ejecutar inferencias de riesgo.
• Proteger baseline, usuarios, permisos, procesos ajenos, worktrees, sesiones y evidencias preexistentes.

Bloque B — Decisiones con evidencia

Para cada capacidad priorizada:

1. Confirmar contrato en versión/tag objetivo (documentación, fuente y breaking changes).
2. Mapear integración actual, beneficio esperado, coste de mantenimiento, seguridad y compatibilidad.
3. Decidir ADOPT_NATIVE / THIN_ADAPTER / EXPERIMENT / DEFER / REJECT con justificación.
4. Diseñar la prueba mínima que puede refutar el beneficio y comparar contra baseline cuando proceda.
5. Medir consumo/tiempo, intervenciones humanas, fiabilidad, frecuencia de compaction, eventos y suites repetidas sin inventar porcentajes ni inferir costes reales desde datos internos.
6. Registrar brechas que ameriten cambio de producto y no crear issues independientes por cada hallazgo menor.

Bloque C — Implementación condicionada

• Proponer uno o pocos slices cohesionados de bajo riesgo (por ejemplo, instrucciones por clave + lectura de estado, o filtrado de eventos), con tests focalizados y compatibilidad.
• Solicitar/usar una autorización end-to-end acotada para el slice aprobado conforme a [NO BORRAR][REFERENCIA] Filosofía OlympusAgents: Goal-Driven · Loop-Executed · Evidence-Gated #92; correcciones relacionadas quedan en la misma misión.
• Reutilizar contratos nativos y evidencia válida; evitar framework/daemon/scheduler/loop alternativo sin brecha demostrada.
• Revisar diff, comportamientos runtime realmente afectados y gates proporcionales.
• Entregar estado DONE / NEEDS_DECISION / BLOCKED / BUDGET_EXCEEDED / FAILED con evidencia y siguiente decisión. No reportar MERGED o RELEASED sin autorización y gates correspondientes.

Criterios de aceptación del issue

• Matriz de compatibilidad 2.2.0→2.2.5 contrastada con el código/contratos reales de Olympus.
• Matriz de decisiones por funcionalidad con impacto, pruebas, riesgo, esfuerzo, versión mínima y justificación.
• Backlog corto y ordenado de slices implementables; evitar crecimiento innecesario del WIP.
• Pruebas focalizadas y registro de métricas para decisiones que se presenten como mejoras efectivas.
• Si se implementa un slice autorizado: sus tests, revisión y evidencia de integración cumplen su contrato específico.
• [Research] Native /goal vs. reusable evidence-gated mission workflow #100 conserva en exclusiva la investigación/diseño portable de /goal; [NO BORRAR][REFERENCIA] Filosofía OlympusAgents: Goal-Driven · Loop-Executed · Evidence-Gated #92 permanece sin cambios.
• El bloqueo previo de v0.4.12 qualification/release no se considera resuelto por esta investigación ni por actualizar el host.

Alcance y prohibiciones

La creación de este issue no autoriza modificar código/configuración, instalar/actualizar el host, ejecutar un runtime de pago, alterar autenticación, publicar, mergear, cambiar permisos ni saltar gates. Se puede realizar investigación read-only bajo un encargo posterior; cualquier implementación deberá estar acotada y autorizada conforme a #92.

No abrir un nuevo frente de implementación mientras otro trabajo activo no termine o no esté bloqueado honestamente. Priorizar resultados de producto y evidencia proporcional.