Port TUI sidebar to v2 CLI-plugin slot API

[frap129]

Question

Port the TUI sidebar (tui/index.tsx, tui/slots/sidebar-content.tsx) to the v2 CLI-plugin API:

• Module contract: v2 default export { id, setup(ctx) } (v1's (api, options, meta) TuiPlugin is rejected; our current { id, tui } shape would fail isPlugin).
• Slot: api.slots.register({ order, slots: { sidebar_content } }) → ctx.ui.slot({ target: "sidebar.content", placement, render }) (check exact claim schema in packages/plugin/src/tui/* on the sst/opencode beta branch; placement kinds prepend/append/before/after/replace).
• Rebuild data flow: v1 read matched-rule state via api.client + file reads; v2 CLI-plugin ctx has data stores (cached session/message stores + data.on event bus), client (OpenCodeClient), theme/themeMode. Check whether matched-rule state (still written to ~/.opencode/state/opencode-rules/{sessionID}.json by the server) is best read via the new client, storage, or direct fs read.
• Keep peer deps (solid-js ≥1.9, @opentui/* ≥0.5.10); verify the build (build-tui.mjs) still emits dist/tui/index.js with the right shape for Host.resolve (./tui entry).

[frap129]

Resolution

Ported in 7645b46-series (working tree, v2 branch). The v2 CLI-plugin contract is Definition from @opencode-ai/plugin/tui ({ id, setup(ctx) }), exported via export * as Plugin — type as Plugin.Definition, not Plugin itself.

• Module contract: tui/index.tsx default-exports { id: 'opencode-rules', async setup(ctx) } (type Plugin.Definition). Build verified: dist/tui/index.js default export has keys id, setup (Host.resolve shape).
• Slot: ctx.ui.slot({ append: 'sidebar.content', render }) — the claim's placement keys are mutually exclusive (append/prepend/before/after/replace); slot input is { sessionID } (camelCase, not v1's session_id). Additive append keeps host sidebar content; replace would suppress it.
• Data flow: matched-rule state stays server-written to ~/.opencode/state/opencode-rules/{sessionID}.json; the TUI keeps reading it by direct fs read (readMatchedRulesState). Chosen over ctx.client/storage because the file already exists, is session-scoped, and the sidebar only needs a periodic refresh — data stores hold session/message stores, not our state; storage.store would add a second source of truth.
• Project dir: ctx.data.session.root(sessionID) replaces v1 api.state.path.directory (LocationRef.directory).
• Theme: ctx.theme is a ResolvedTheme (no .current wrapper); colors read text.default, text.subdued, text.feedback.success.default from @opencode-ai/theme/tui.
• Events: refresh triggers subscribe via ctx.data.on('session.message.content.updated' | 'session.status') — v2 event payloads carry data.sessionID (v1's message.updated/properties.sessionID is gone). session.synthetic events confirmed as the durable-rule signal shape (data.sessionID).
• Type deps: the real v2 types require @opencode-ai/client + @opencode-ai/theme peers; both added as devDeps pinned 0.0.0-beta-18999 and the vendored v1 shim tui/types/opencode-plugin-tui.d.ts deleted (it ambient-shadowed node_modules resolution). No new runtime deps; build-tui.mjs unchanged.
• Props: SidebarContent now takes { sessionId, projectDir, data, theme }; mount test updated and passing.

Verified: aubx tsc --noEmit clean, aube run lint clean, full suite 548/548, bun run build-tui.mjs emits correct shape. Live behavior still rides the e2e validation ticket (graduated from map fog).