qol-arch-channelslisted

# qol-arch-channels Four channels, pick one. Don't invent a fifth. | Channel | Direction | Use for | Wire | |---|---|---|---| | Pull | plugin -> host | Plugin asks now | `RuntimeRequest::GetState` | | Subscribe | plugin -> host (stream) | Plugin reacts to host changes | `RuntimeRequest::Subscribe { events }` + new `RuntimeEvent` variant | | Action | host -> plugin | Host tells plugin to do something | `DaemonRequest { action }` | | Capability | static | Per-OS feature gate | `qol_platform::PlatformCapabilities` | ## Rules - Event variants are past-tense VerbNoun: `FocusChanged`, `MonitorsChanged`, `LauncherAppsSynced`. - Payloads are additive only. Breaking shape = new variant, never rename. - Use `#[serde(default)]` on new fields so old subscribers still parse. - A tray-owned helper process is not automatically a fifth host/plugin channel. The native settings singleton socket only activates qol-tray's own GPUI host; panel persistence and `SettingsRuntime::tray` keep plugin config, queries, and actions on the existing HTTP and action paths. See `qol-project:qol-plugin-gpui-surfaces` before adding settings IPC. ## Agent-facing tool surfaces Exposing a qol capability's tools to terminal agents (pi, Claude Code, codex, kimi) is a boundary, not a fifth host/plugin channel. The same tools can reach every agent; the surface is the contract, not a per-agent fork. - Own the tool contract once, in the capability's headless layer. Example: `tools/qol-cli/src/commands/s