[Suggestion] Prepare opencode-wlib for OpenCode v2 plugin API #4

Is your feature request related to a problem? Please describe.

opencode-wlib currently targets the V1 TUI plugin API. OpenCode V2 intentionally changes the plugin API, and V1 plugins do not work in V2. The shared library should be migrated first so consumers such as opencode-model-usage and opencode-persona-injector can port their plugin-specific code on top of a stable V2 wlib contract.

This issue is limited to shared-library changes. Server telemetry, SQLite usage queries, plugin-specific dialogs, and application configuration belong in the consuming plugin repositories.

Describe the solution you'd like

Prepare a V2-focused wlib release with the following changes:

• Define the supported V2 compatibility policy and release boundary; do not mix V1 and V2 host APIs in the same runtime adapter.
• Replace @opencode-ai/plugin/tui TuiPluginApi type dependencies with the V2 CLI plugin context types.
• Update src/core/command.ts to use context.keymap.layer and the V2 command shape.
• Map V1 command fields to V2 fields: name to id, category to group, namespace/palette metadata to palette, slashName to slash.name, and inline key bindings to bind plus command IDs in bindings.
• Update src/core/keys.ts to register dialog layers through the V2 keymap API, preserving priorities, cleanup, and modal dispatch behavior.
• Replace the V1 binding object contract with a V2-compatible binding/command contract while keeping help-row generation deterministic.
• Update src/core/theme.ts to consume V2 semantic theme tokens and preserve RGBA values without string coercion.
• Update src/ui/dialog.tsx to accept the V2 plugin context/renderer and integrate with context.ui.dialog.set({ size }) instead of setSize().
• Preserve responsive width and height fitting behavior during the dialog API transition.
• Update src/ui/export-controller.tsx to use the V2 keymap layer, dialog lifecycle, and theme contract.
• Review help-overlay.tsx, export-overlay.tsx, export-result-overlay.tsx, and copied-flash.tsx for V2 type or lifecycle assumptions; keep presentational components host-agnostic where possible.
• Decide whether src/core/system.ts should retain its filesystem sidecar contract or gain an explicit storage abstraction; V2 plugin storage is plugin-scoped and does not automatically replace cross-plugin sharing.
• Keep pure helpers (clipboard, dialog-fit, export, export-state, file, help, log, reload, scroll, and system snapshot math) framework-independent.
• Update all wlib unit-test mocks from registerLayer and V1 command metadata to the V2 keymap.layer contract.
• Add tests for V2 command mapping, layer cleanup, priority handling, theme token normalization, RGBA pass-through, and responsive dialog sizing.
• Update README/API documentation and examples to use V2 terminology and imports.
• Update the migration guide with the new import paths and consumer migration sequence.
• Bump the submodule consumers only after the V2 wlib tests pass.

Acceptance criteria

• wlib has no dependency on the legacy TuiPluginApi or api.keymap.registerLayer contract.
• Command and dialog helpers work with the V2 CLI plugin context.
• Existing pure helper behavior remains unchanged unless explicitly documented.
• All wlib tests pass with the V2-compatible mocks.
• The migration path for opencode-model-usage and opencode-persona-injector is documented.
• V1 and V2 support boundaries are explicit; V1 compatibility is not implied by the V2 release.

Additional context

OpenCode's V2 migration documentation identifies plugin APIs as an intentional breaking change and states that V1 plugins will not work in V2. V1 and V2 can remain installed side by side under different executables (opencode and opencode2), but a plugin implementation must be ported for V2.

References:

• https://opencode.ai/v2/docs/migrate-v1
• https://opencode.ai/v2/docs/build/plugins
• https://opencode.ai/v2/docs/build/plugins/cli

Media

N/A