From 8391dd15c226b46ad484a21add046d564ddb14c4 Mon Sep 17 00:00:00 2001 From: Jeroen Schweitzer Date: Sun, 17 May 2026 20:42:44 +0200 Subject: [PATCH] register D-68 + Q-32/Q-33 in the governance index MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit D-68 (dual integration surface — Bash CLI primary, MCP secondary) landed in 8074bf4 inadvertently; this lands its index pointer in README.md and the two open questions D-68 spawned. - Q-32: tool surface — minimum /ide vs extended `mcp__clide__*`. - Q-33: transport — SSE / WebSocket / stdio / all. No behavior change. Governance bookkeeping only. Co-Authored-By: Claude Opus 4.7 (1M context) --- governance/README.md | 3 +++ governance/questions/architecture.md | 12 ++++++++++++ 2 files changed, 15 insertions(+) diff --git a/governance/README.md b/governance/README.md index 69089db2..44aa29d7 100644 --- a/governance/README.md +++ b/governance/README.md @@ -109,6 +109,7 @@ You might also want, project-permitting: - [D-65: License compatibility matrix](decisions/tooling.md#d-65-license-compatibility-matrix) — _tooling_ - [D-66: Line coverage gate at 95%, ratcheted from current](decisions/testing.md#d-66-line-coverage-gate-at-95-ratcheted-from-current) — _testing_ - [D-67: Pql changelog files are committed alongside code](decisions/process.md#d-67-pql-changelog-files-are-committed-alongside-code) — _process_ +- [D-68: Dual integration surface — Bash CLI primary, MCP secondary](decisions/architecture.md#d-68-dual-integration-surface--bash-cli-primary-mcp-secondary) — _architecture_ ## Open questions @@ -142,6 +143,8 @@ You might also want, project-permitting: - [Q-29: Branch picker location](questions/architecture.md#q-29-branch-picker-location) — _architecture_ - [Q-30: Focus behavior when editor is dirty and viewer is peeked](questions/architecture.md#q-30-focus-behavior-when-editor-is-dirty-and-viewer-is-peeked) — _architecture_ - [Q-31: XWayland fallback for frameless — proper Wayland protocol needed](questions/architecture.md#q-31-xwayland-fallback-for-frameless--proper-wayland-protocol-needed) — _architecture_ +- [Q-32: MCP tool surface — minimum slash-ide or extended clide tools?](questions/architecture.md#q-32-mcp-tool-surface--minimum-slash-ide-or-extended-clide-tools) — _architecture_ +- [Q-33: MCP transport — SSE, WebSocket, stdio, or all?](questions/architecture.md#q-33-mcp-transport--sse-websocket-stdio-or-all) — _architecture_ ## Rejected diff --git a/governance/questions/architecture.md b/governance/questions/architecture.md index 12e7903b..dbdb0aaa 100644 --- a/governance/questions/architecture.md +++ b/governance/questions/architecture.md @@ -125,4 +125,16 @@ ticket persistence. - **Source:** 2026-04-23 D-57 implementation. +### Q-32: MCP tool surface — minimum slash-ide or extended clide tools? +- **Status:** Open +- **Question:** [D-68](../decisions/architecture.md#d-68-dual-integration-surface-bash-cli-primary-mcp-secondary) commits clide to an `/ide`-compatible MCP server. The minimum surface is the two tools Claude Code's `/ide` integration currently expects: `mcp__ide__getDiagnostics` (lint/diagnostics for a file) and `mcp__ide__executeCode` (run code in a Jupyter kernel). Do we stop there, or also expose a `mcp__clide__*` namespace with higher-leverage tools (`open_file`, `goto_symbol`, `pql_query`, `pane_spawn`, `git_status`, …) so MCP clients other than Claude Code (Cursor, Windsurf, VS Code Copilot) can drive clide as a real backend? +- **Context:** The minimum surface keeps clide a good citizen in the `/ide` ecosystem and avoids duplicating the CLI in MCP form. The extended surface would let non-Claude-Code MCP clients integrate richly, but invites surface bloat (every CLI verb tempted to gain an MCP twin) and a maintenance second front. Note that for *Claude-Code-in-a-clide-pane*, the CLI surface already covers this — extended MCP tools serve external MCP clients only. +- **Source:** [D-68](../decisions/architecture.md#d-68-dual-integration-surface-bash-cli-primary-mcp-secondary). + +### Q-33: MCP transport — SSE, WebSocket, stdio, or all? +- **Status:** Open +- **Question:** Claude Code's `/ide` integration connects via SSE-IDE or WS-IDE (URL passed at startup). MCP also supports stdio for process-spawn clients. Which transport(s) should clide's MCP server expose — SSE only (the most common `/ide` server pattern), SSE + WS (broader compatibility), or all three including stdio? +- **Context:** Transport choice affects discovery and lifecycle. SSE/WS need a port and a published URL, which collides with the `XDG_RUNTIME_DIR` Unix-socket model used for the CLI; we'd likely publish the URL alongside the socket path (env var or `XDG_RUNTIME_DIR` discovery file). stdio is process-per-client and works for clients that prefer process-spawn over network. Decision interacts with [Q-32](#q-32-mcp-tool-surface-minimum-slash-ide-or-extended-clide-tools) — if the surface stays at the `/ide` minimum, SSE alone is sufficient. +- **Source:** [D-68](../decisions/architecture.md#d-68-dual-integration-surface-bash-cli-primary-mcp-secondary). + ---