Motivo

Hubo cambios incompatibles en el SDK y en los contratos públicos de mensajes, eventos y plugins de OpenCode 2.1. Hay que determinar cuáles afectan realmente a este proyecto e investigar si existen otros cambios relevantes, sin asumir que actualizar OpenCode produce por sí solo una incompatibilidad.

Este issue es de investigación y propuesta. No autoriza implementación, actualización de dependencias/configuración, probes de runtime, commits, PR ni releases.

Cambios conocidos que deben revisarse

Según el changelog oficial de v2.1.0 y upstream #57260:

• Los datos de replay pasan a native en las superficies que antes usaban state, providerState o resultState; el esquema exportado pasa de SessionMessage.ProviderState a SessionMessage.Native y el resultado del hook de compactación usa native.
• Llamadas y resultados de herramientas comparten tool.native, con mezcla superficial y precedencia del resultado. El estado de ejecución sigue en tool.state; no debe renombrarse.
• Las escrituras públicas de credenciales de tipo key deben usar metadata para las respuestas de configuración, en lugar de Credential.Key.configuration. La compatibilidad de lectura/importación no conserva ese campo para nuevas escrituras.
• Las nuevas compactaciones de resumen sustituyen recent por la referencia metadata.keepID; el texto legado puede aparecer como metadata.recent.
• providerContext se sustituye por native.messages y cambian las condiciones de replay de compactación.
• Se elimina session.compacted; las suscripciones deben revisarse contra session.compaction.started y session.compaction.ended.

Upstream indica que sesiones, credenciales e importaciones antiguas siguen siendo legibles mediante decodificadores de compatibilidad, sin migración de base de datos. Esto no demuestra compatibilidad de los consumidores de la API pública.

Investigar también

No limitar la revisión a esos renombres. Comparar la versión realmente usada por el proyecto con las fuentes oficiales de 2.1:

• SDK/API, schemas, eventos y suscripciones; hooks y carga de plugins; permisos, contexto y comportamiento de ejecución que el proyecto consuma.
• Adiciones documentadas como client.permission.saved.update, filtros/actualización de archivo de sesiones, filtro idle en mensajes y ctx.session.list paginado. Considerarlas solo si afectan una superficie usada; no adoptarlas por novedad.
• Cambios pertinentes de duración de comandos TUI, captura/terminación de shell, transporte/reintentos, compactación y discovery de skills.
• El diff v2.1.0...v2.1.1, no solo el changelog: al revisar el 20-10-2026 no había una sección propia de 2.1.1. Verificar versión exacta de host, SDK/plugin y dependencia indirecta, sin asumir que tag, paquete publicado e instalación local coinciden.

Alcance específico de ChangeBudget

• Priorizar la integración OpenCode y sus hooks context/evaluate, los inputs de permisos y metadata, la identidad de operación/sesión y cualquier tipo/evento SDK realmente usado.
• Comprobar que cambios en permisos guardados o campos de herramientas no alteran la autoridad efectiva ni las decisiones del guard. El estado de ejecución no debe confundirse con datos de replay.
• Preservar núcleo determinista, CLI independiente, validación de identidad/contexto/vigencia y límites del contrato. Nada de fail-open, ampliación automática, degradación a auditoría o evasión del guard mediante CLI.
• Mantener #53 como tracker de Guardian V2 y #46 como dueño de autoridad upstream; este diagnóstico no autoriza ni sustituye sus cambios. Respetar #55.

Referencia local: README e integración OpenCode.

Entrega y criterios de cierre

• Inventario acotado de las superficies realmente consumidas, con versión/ref y archivo o contrato correspondiente.
• Matriz por cambio: APLICA / NO APLICA / POR CONFIRMAR, evidencia local y upstream, impacto y siguiente paso. Documentar también los cambios adicionales encontrados; no confundir ausencia de prueba con compatibilidad.
• Separar incompatibilidad comprobada, riesgo potencial, comportamiento ya compatible y limitación externa. Si no aplica, cerrar con evidencia sin forzar cambios.
• Proponer la corrección mínima o documentar que no hace falta; reutilizar los issues propietarios y evitar refactors o ampliaciones de producto.
• Definir pruebas deterministas focalizadas para los contratos afectados. Solo proponer una comprobación de runtime real si resuelve una incertidumbre necesaria, con versión exacta, entorno y autorización explícita antes de ejecutarla; distinguir evidencia estática/sintética de runtime.
• Registrar el resultado y los límites de lo verificado. La investigación no equivale a certificar toda la suite ni a autorizar implementación.