v0.19.1

Patch Changes

• Add OpenCode as a supported agent. ok init — and the desktop first-launch consent dialog plus the create-project dialog — now writes an open-knowledge MCP server entry to opencode.json (project-local, and ~/.config/opencode/opencode.json for a global install), using OpenCode's mcp config shape and the same resilient launcher every other editor gets. OpenCode reads the Open Knowledge skill from the shared .agents/skills/ directory it already scans, so no extra skill copy is written.

  OpenCode is also wired into the Ask AI composer and Open-in-Agent menus as a terminal CLI: it appears as "OpenCode (CLI)" in the Terminal section and launches opencode '<prompt>' in the docked terminal. (It's terminal-only — no URL scheme — so it's deliberately absent from the GUI deep-link Desktop section.)

  Adds an OpenCode integration page and brand logo to the docs site.

• Rename the product brand from "Open Knowledge" to "OpenKnowledge" (one word) across the desktop app, CLI output, MCP/skill copy, and docs.

  The macOS app, its helper bundle, the DMG artifact, and the userData directory are renamed. A one-time, identity-verified migration runs on the first launch of a renamed build: it relocates an existing user's app state (recent projects, window restore, auto-update cache) from ~/Library/Application Support/Open Knowledge/ to .../OpenKnowledge/, but only after verifying the legacy directory is ours (its state.json parses as our schema), so another vendor's identically-named directory is never touched. It copies, verifies, then removes the legacy directory; any failure degrades to a clean first run.

  Technical identifiers are unchanged: the npm package @inkeep/open-knowledge, the macOS appId com.inkeep.open-knowledge, the openknowledge:// deep-link scheme, the openknowledge.ai domain, and the open-knowledge MCP server name. "Open Knowledge Format" (Google's external standard) is also preserved.

• Fix jumpy, inconsistent mouse-wheel scrolling inside full-screen terminal apps that capture the mouse (the claude TUI, vim, less, top). In mouse-tracking mode xterm.js forwards one mouse-wheel report per OS wheel event with no accumulation, so the high-frequency event stream from trackpad momentum and free-spin/fast-scroll wheels floods the app — scrolling that lurches and can run away ("rocket scroll"). The terminal now accumulates fractional rows of travel and emits one wheel report per whole row of distance crossed, so scroll tracks the actual distance moved regardless of how many events deliver it: gentle drags and fast flicks over the same distance scroll the same amount, with no dead zone and a per-event clamp that absorbs momentum spikes. Normal scrollback (no mouse-capturing app) additionally gets smooth scrolling. Desktop only.

• Tune embedded-terminal wheel scrolling to feel closer to a native terminal (e.g. Ghostty). The smooth mouse-tracking scroll added previously was correct but sluggish: macOS bakes velocity acceleration into wheel deltas, and the per-event clamp was clipping the accelerated fast-flick range. The mouse-mode accumulator now uses a modest base sensitivity with a higher per-event cap so OS acceleration carries through — fast flicks travel far while slow drags stay gentle — and normal scrollback gets a faster per-notch travel. Desktop only.