@selesai/code 0.9.4 → 0.9.5

package/CHANGELOG.md

@@ -2,6 +2,12 @@
 
 All notable changes to `@selesai/code` will be documented in this file.
 
+## [0.9.5] - 2026-08-23
+
+### Added
+- **Questions in non-TUI modes.** The bundled `question` tool now works outside the terminal TUI (e.g. RPC/VS Code hosts): questions are answered through the host's `extension_ui_request` dialogs (`select`/`input`) instead of throwing, mirroring Cline/Kilo. Multi-select questions preserve full multi-selection when the host supports the new `multiselect` UI method, with single-select fallback for older hosts.
+- **`multiselect` extension UI method.** `ExtensionUIContext.multiselect()` prompts for multiple choices and returns `string[] | undefined`. In RPC mode it emits an `extension_ui_request` with `method: "multiselect"` and accepts an `extension_ui_response` with a `values` array.
+
 ## [0.9.4] - 2026-08-22
 
 ### Changed

package/README.md

@@ -81,7 +81,7 @@ DuckDuckGo works as the default search path. Optional first-run onboarding can c
 
 ### Interactive questions
 
-The bundled `question` tool gives the agent a real TUI for decisions instead of forcing every clarification through plain text. It supports:
+The bundled `question` tool gives the agent a real UI for decisions instead of forcing every clarification through plain text. It supports:
 
 - single- and multi-select options
 - descriptions and context summaries

package/dist/core/extensions/types.d.ts

@@ -68,6 +68,8 @@ export type EditorFactory = (tui: TUI, theme: EditorTheme, keybindings: Keybindi
 export interface ExtensionUIContext {
     /** Show a selector and return the user's choice. */
     select(title: string, options: string[], opts?: ExtensionUIDialogOptions): Promise<string | undefined>;
+    /** Show a multi-select dialog and return the user's selections (labels), or undefined if cancelled. */
+    multiselect?(title: string, options: string[], opts?: ExtensionUIDialogOptions): Promise<string[] | undefined>;
     /** Show a confirmation dialog. */
     confirm(title: string, message: string, opts?: ExtensionUIDialogOptions): Promise<boolean>;
     /** Show a text input dialog. */

package/dist/extensions/question/index.ts

@@ -1,6 +1,6 @@
 // Batch-first interactive question tool.
 
-import type { ExtensionAPI, KeybindingsManager, Theme } from "@selesai/code";
+import type { ExtensionAPI, ExtensionUIContext, KeybindingsManager, Theme } from "@selesai/code";
 import {
 	Container,
 	type Component,
@@ -18,6 +18,78 @@ import {
 import { buildQuestionAnswers, prepareQuestions, saveDraftQuestion } from "./batch.ts";
 import { BOX_BORDER_LEFT, BOX_BORDER_OVERHEAD, BOX_BORDER_RIGHT, DISABLED_SHORTCUT, QUESTION_VERSION } from "./constants.ts";
 import { createSelectionResponse, createTextResponse, formatQuestionResponse, formatResponseSummary, oneLine, previewText, trimText } from "./helpers.ts";
+
+/**
+ * Answer a question outside the terminal TUI (e.g. RPC/extension mode) using
+ * the per-mode ExtensionUIContext, which emits extension_ui_request dialogs
+ * (select/input) that the VS Code host renders. Mirrors Cline/Kilo: a pending
+ * question is surfaced in the webview and blocks until the user answers.
+ */
+function answerQuestionViaUi(question: PreparedQuestion, ctx: { ui: ExtensionUIContext }): Promise<QuestionResponse | null> {
+	const title = question.context ? `${question.question}
+
+${question.context}` : question.question;
+	if (question.type === "text") {
+		return ctx.ui.input(title).then((text) => createTextResponse(text));
+	}
+	const optionLabels = new Map(question.options.map((option) => [option.label, option.value] as const));
+	const optionValues = question.options.map((option) => option.value);
+	const labels = question.options.map((option) => option.label);
+	if (question.type === "select") {
+		return ctx.ui
+			.select(title, labels)
+			.then((selected) => {
+				if (selected === undefined) return null;
+				const value = optionLabels.get(selected);
+				const isOther = value === undefined;
+				if (isOther) {
+					if (!question.allowOther) return null;
+					return ctx.ui.input(title).then((text) => createSelectionResponse([], text ?? undefined));
+				}
+				return createSelectionResponse([value]);
+			});
+	}
+	// RPC/webview hosts can preserve true multi-selection. Older hosts fall back to
+	// one choice rather than making the question tool unavailable entirely. When
+	// allowOther is set the host sees an explicit "Other" choice, surfacing a free
+	// text follow-up exactly like the TUI wizard.
+	if (ctx.ui.multiselect) {
+		const other = question.allowOther ? ["Other"] : [];
+		return ctx.ui.multiselect(title, [...labels, ...other]).then((selected) => {
+			if (selected === undefined) return null;
+			const values = selected.filter((label) => label !== "Other").map((label) => optionLabels.get(label)).filter((value): value is string => value !== undefined);
+			if (question.allowOther && selected.includes("Other")) {
+				return ctx.ui.input(title).then((text) => createSelectionResponse(values, text ?? undefined));
+			}
+			return createSelectionResponse(values);
+		});
+	}
+	return ctx.ui.select(title, labels).then((selected) => {
+		if (selected === undefined) return null;
+		const value = optionLabels.get(selected);
+		return value === undefined
+			? question.allowOther ? ctx.ui.input(title).then((text) => createSelectionResponse([], text ?? undefined)) : null
+			: createSelectionResponse([value]);
+	});
+}
+
+/**
+ * Non-TUI fallback that answers each question in sequence via the host UI.
+ * Returns null when the user cancels any question.
+ */
+async function answerQuestionsViaUi(questions: PreparedQuestion[], ctx: { ui: ExtensionUIContext }): Promise<QuestionResponse[] | null> {
+	const answers: QuestionResponse[] = [];
+	for (const question of questions) {
+		const response = await answerQuestionViaUi(question, ctx);
+		if (response === null) return null;
+		answers.push(response);
+	}
+	return answers;
+}
+
+function buildAnswersFromResponses(questions: PreparedQuestion[], responses: QuestionResponse[]): QuestionAnswer[] {
+	return questions.map((question, index) => ({ id: question.id, status: "answered" as const, response: responses[index]! }));
+}
 import { QuestionList } from "./question-list.ts";
 import { MultiSelect, SingleSelect } from "./selection-mode.ts";
 import { QuestionParamsSchema } from "./schemas.ts";
@@ -557,14 +629,17 @@ export default function questionExtension(pi: ExtensionAPI) {
 		async execute(_toolCallId, params, signal, onUpdate, ctx) {
 			const prepared = prepareQuestions(params.questions);
 			if ("error" in prepared) throw new Error(prepared.error);
-			if (ctx.mode !== "tui") throw new Error("Question requires terminal TUI mode.");
 			if (signal?.aborted) return { content: [{ type: "text", text: "Question cancelled" }], details: { status: "cancelled", reason: "user" } satisfies QuestionToolResult };
 
 			onUpdate?.({ content: [{ type: "text", text: `Waiting for answers to ${prepared.questions.length} question${prepared.questions.length === 1 ? "" : "s"}...` }] });
-			const result = await ctx.ui.custom<QuestionToolResult>((tui, theme, keybindings, done) => {
-				if (signal) signal.addEventListener("abort", () => done({ status: "cancelled", reason: "user" }), { once: true });
-				return new BatchQuestionComponent(prepared.questions, tui, theme, keybindings, done);
-			});
+			const result: QuestionToolResult | undefined = ctx.mode === "tui"
+				? await ctx.ui.custom<QuestionToolResult>((tui, theme, keybindings, done) => {
+					if (signal) signal.addEventListener("abort", () => done({ status: "cancelled", reason: "user" }), { once: true });
+					return new BatchQuestionComponent(prepared.questions, tui, theme, keybindings, done);
+				})
+				: await answerQuestionsViaUi(prepared.questions, ctx).then((responses) =>
+					responses ? { status: "submitted" as const, answers: buildAnswersFromResponses(prepared.questions, responses) } : { status: "cancelled" as const, reason: "user" as const },
+				);
 			if (!result) throw new Error("Question TUI did not return a result.");
 
 			if (result.status === "cancelled") {

package/dist/extensions/question/tests/wizard.test.ts

@@ -197,13 +197,29 @@ describe("question wizard", () => {
 		expect(emitted2).toEqual(["question:submitted"]);
 	});
 
-	it("rejects non-TUI modes and invalid params", async () => {
+	it("uses extension UI requests in RPC mode", async () => {
 		let tool: any;
 		questionExtension({ registerTool: (entry: unknown) => (tool = entry), events: { emit() {} } } as any);
+		const result = await tool.execute("call", { questions: [{ type: "select", question: "Choose", options: [{ value: "x", label: "X" }] }] }, undefined, undefined, {
+			mode: "rpc",
+			ui: { select: async () => "X" },
+		} as any);
+		expect(result.details).toEqual({ status: "submitted", answers: [{ id: "q1", status: "answered", response: { kind: "selection", values: ["x"] } }] });
+	});
 
-		await expect(tool.execute("call", { questions: [{ type: "select", question: "Q", options: [{ value: "x", label: "X" }] }] }, undefined, undefined, {
+	it("preserves multiple RPC selections", async () => {
+		let tool: any;
+		questionExtension({ registerTool: (entry: unknown) => (tool = entry), events: { emit() {} } } as any);
+		const result = await tool.execute("call", { questions: [{ type: "multiselect", question: "Choose many", options: [{ value: "a", label: "A" }, { value: "b", label: "B" }] }] }, undefined, undefined, {
 			mode: "rpc",
-		} as any)).rejects.toThrow("Question requires terminal TUI mode.");
+			ui: { multiselect: async () => ["A", "B"] },
+		} as any);
+		expect(result.details).toEqual({ status: "submitted", answers: [{ id: "q1", status: "answered", response: { kind: "selection", values: ["a", "b"] } }] });
+	});
+
+	it("rejects invalid params", async () => {
+		let tool: any;
+		questionExtension({ registerTool: (entry: unknown) => (tool = entry), events: { emit() {} } } as any);
 
 		await expect(tool.execute("call", { questions: [] }, undefined, undefined, {
 			mode: "tui",

package/dist/modes/rpc/rpc-mode.js

@@ -81,6 +81,7 @@ export async function runRpcMode(runtimeHost) {
      */
     const createExtensionUIContext = () => ({
         select: (title, options, opts) => createDialogPromise(opts, undefined, { method: "select", title, options, timeout: opts?.timeout }, (r) => "cancelled" in r && r.cancelled ? undefined : "value" in r ? r.value : undefined),
+        multiselect: (title, options, opts) => createDialogPromise(opts, undefined, { method: "multiselect", title, options, timeout: opts?.timeout }, (r) => "cancelled" in r && r.cancelled ? undefined : "values" in r ? r.values : undefined),
         confirm: (title, message, opts) => createDialogPromise(opts, false, { method: "confirm", title, message, timeout: opts?.timeout }, (r) => "cancelled" in r && r.cancelled ? false : "confirmed" in r ? r.confirmed : false),
         input: (title, placeholder, opts) => createDialogPromise(opts, undefined, { method: "input", title, placeholder, timeout: opts?.timeout }, (r) => "cancelled" in r && r.cancelled ? undefined : "value" in r ? r.value : undefined),
         notify(message, type) {

package/dist/modes/rpc/rpc-types.d.ts

@@ -418,6 +418,13 @@ export type RpcExtensionUIRequest = {
     title: string;
     options: string[];
     timeout?: number;
+} | {
+    type: "extension_ui_request";
+    id: string;
+    method: "multiselect";
+    title: string;
+    options: string[];
+    timeout?: number;
 } | {
     type: "extension_ui_request";
     id: string;
@@ -473,6 +480,10 @@ export type RpcExtensionUIResponse = {
     type: "extension_ui_response";
     id: string;
     value: string;
+} | {
+    type: "extension_ui_response";
+    id: string;
+    values: string[];
 } | {
     type: "extension_ui_response";
     id: string;

package/docs/extensions.md

@@ -9,7 +9,7 @@ Extensions are TypeScript modules that extend pi's behavior. They can subscribe
 **Key capabilities:**
 - **Custom tools** - Register tools the LLM can call via `pi.registerTool()`
 - **Event interception** - Block or modify tool calls, inject context, customize compaction
-- **User interaction** - Prompt users via `ctx.ui` (select, confirm, input, notify)
+- **User interaction** - Prompt users via `ctx.ui` (select, multiselect, confirm, input, notify)
 - **Custom UI components** - Full TUI components with keyboard input via `ctx.ui.custom()` for complex interactions
 - **Custom commands** - Register commands like `/mycommand` via `pi.registerCommand()`
 - **Session persistence** - Store state that survives restarts via `pi.appendEntry()`
@@ -2201,6 +2201,9 @@ Extensions can interact with users via `ctx.ui` methods and customize how messag
 // Select from options
 const choice = await ctx.ui.select("Pick one:", ["A", "B", "C"]);
 
+// Multi-select from options (string[] | undefined; optional in hosts that do not support it)
+const choices = await ctx.ui.multiselect?.("Pick many:", ["A", "B", "C"]);
+
 // Confirm dialog
 const ok = await ctx.ui.confirm("Delete?", "This cannot be undone");
 

package/docs/rpc.md

@@ -1008,7 +1008,7 @@ Extensions can request user interaction via `ctx.ui.select()`, `ctx.ui.confirm()
 
 There are two categories of extension UI methods:
 
-- **Dialog methods** (`select`, `confirm`, `input`, `editor`): emit an `extension_ui_request` on stdout and block until the client sends back an `extension_ui_response` on stdin with the matching `id`.
+- **Dialog methods** (`select`, `multiselect`, `confirm`, `input`, `editor`): emit an `extension_ui_request` on stdout and block until the client sends back an `extension_ui_response` on stdin with the matching `id`.
 - **Fire-and-forget methods** (`notify`, `setStatus`, `setWidget`, `setTitle`, `set_editor_text`): emit an `extension_ui_request` on stdout but do not expect a response. The client can display the information or ignore it.
 
 If a dialog method includes a `timeout` field, the agent-side will auto-resolve with a default value when the timeout expires. The client does not need to track timeouts.
@@ -1046,6 +1046,23 @@ Prompt the user to choose from a list. Dialog methods with a `timeout` field inc
 
 Expected response: `extension_ui_response` with `value` (the selected option string) or `cancelled: true`.
 
+#### multiselect
+
+Prompt the user to choose zero or more options from a list. Dialog methods with a `timeout` field include the timeout in milliseconds; the agent auto-resolves with `undefined` if the client doesn't respond in time.
+
+```json
+{
+  "type": "extension_ui_request",
+  "id": "uuid-10",
+  "method": "multiselect",
+  "title": "Which regions?",
+  "options": ["us-east", "eu-west", "ap-southeast"],
+  "timeout": 10000
+}
+```
+
+Expected response: `extension_ui_response` with `values` (the selected option strings) or `cancelled: true`.
+
 #### confirm
 
 Prompt the user for yes/no confirmation.
@@ -1172,7 +1189,7 @@ Set the text in the input editor. Fire-and-forget.
 
 ### Extension UI Responses (stdin)
 
-Responses are sent for dialog methods only (`select`, `confirm`, `input`, `editor`). The `id` must match the request.
+Responses are sent for dialog methods only (`select`, `multiselect`, `confirm`, `input`, `editor`). The `id` must match the request.
 
 #### Value response (select, input, editor)
 
@@ -1180,6 +1197,12 @@ Responses are sent for dialog methods only (`select`, `confirm`, `input`, `edito
 {"type": "extension_ui_response", "id": "uuid-1", "value": "Allow"}
 ```
 
+#### Values response (multiselect)
+
+```json
+{"type": "extension_ui_response", "id": "uuid-10", "values": ["us-east", "ap-southeast"]}
+```
+
 #### Confirmation response (confirm)
 
 ```json
@@ -1188,7 +1211,7 @@ Responses are sent for dialog methods only (`select`, `confirm`, `input`, `edito
 
 #### Cancellation response (any dialog)
 
-Dismiss any dialog method. The extension receives `undefined` (for select/input/editor) or `false` (for confirm).
+Dismiss any dialog method. The extension receives `undefined` (for select/multiselect/input/editor) or `false` (for confirm).
 
 ```json
 {"type": "extension_ui_response", "id": "uuid-3", "cancelled": true}

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@selesai/code",
-	"version": "0.9.4",
+	"version": "0.9.5",
 	"description": "Maintained, extension-first Pi coding agent with built-in workflows, subagents, web research, questions, skills, and an enhanced terminal UI.",
 	"type": "module",
 	"repository": {

package/docs/research/kilo-vscode-and-selesai-integration.md

@@ -1,319 +0,0 @@
-# Kilo Code VS Code Architecture and Selesai Integration Feasibility
-
-**Research date:** 2026-08-20  
-**Repositories:** [Kilo Code](https://github.com/Kilo-Org/kilocode), this Selesai Code repository  
-**Question:** Does Kilo use RPA or another integration mechanism, and can Selesai provide a similar or better VS Code extension?
-
-## Executive conclusion
-
-Kilo Code is **not primarily an RPA application** and its core is not an LSP client/server. It is a layered VS Code product:
-
-1. A normal VS Code extension host (`packages/kilo-vscode`) activated through `vscode` APIs.
-2. Webview-based UI surfaces (sidebar, panels, agent manager, settings, diffs).
-3. A lazily spawned local Kilo CLI backend (`kilo serve --port 0`).
-4. An SDK/client connection from the extension host to that backend over authenticated local HTTP APIs and SSE event streaming.
-5. Separate WebSocket paths for selected features such as PTY terminal streaming and cloud event service.
-6. MCP client transports for tool/server integration: local stdio subprocesses and remote HTTP/SSE transports.
-
-The important correction to a simplistic “Webview only” description is that **Webview `postMessage` is only the UI bridge**. In the current Kilo repository, the extension also connects to a local backend server. The extension spawns the backend, discovers its ephemeral port from stdout, gives it a generated password, and uses an SDK plus HTTP/SSE with Basic authentication.
-
-Selesai can absolutely support a comparable VS Code extension. The shortest path is a VS Code extension-host backend that starts `selesai --mode rpc` and adapts the existing strict JSONL RPC client/events into a Webview. The best long-term path is probably a two-tier design:
-
-- **MVP:** local child process + existing Selesai RPC over private stdin/stdout.
-- **Better product integration:** a small authenticated local HTTP/SSE or WebSocket server facade, or direct in-process SDK use where safe, with a stable VS Code-oriented protocol.
-
-Selesai already has unusually strong agent/session/extension primitives. Its main missing pieces for Kilo-level VS Code integration are a polished VS Code package, a durable UI protocol/adapter, explicit trust UX, and (if remote or multi-client use is desired) authenticated network transport.
-
-## 1. What Kilo actually uses
-
-### 1.1 VS Code extension activation
-
-Kilo's extension is a conventional TypeScript VS Code extension. The activation function accepts `vscode.ExtensionContext`, constructs shared services, and registers views/providers through the VS Code API:
-
-- [`packages/kilo-vscode/src/extension.ts`](https://github.com/Kilo-Org/kilocode/blob/main/packages/kilo-vscode/src/extension.ts#L45-L61) — `activate(context)` and shared `KiloConnectionService`.
-- [`packages/kilo-vscode/src/extension.ts`](https://github.com/Kilo-Org/kilocode/blob/main/packages/kilo-vscode/src/extension.ts#L131-L143) — creates `KiloProvider` and calls `vscode.window.registerWebviewViewProvider(...)`.
-- The extension manifest/build configuration is in [`packages/kilo-vscode/package.json`](https://github.com/Kilo-Org/kilocode/blob/main/packages/kilo-vscode/package.json) and the repository root package configuration.
-
-This is ordinary VS Code extension-host architecture, not RPA automation of the VS Code UI.
-
-### 1.2 Webview UI bridge
-
-Kilo's chat and panels use Webviews. The extension host attaches a Webview and receives structured messages with `webview.onDidReceiveMessage`; it sends state, stream, and command results back using `webview.postMessage`:
-
-- [`KiloProvider.ts`](https://github.com/Kilo-Org/kilocode/blob/main/packages/kilo-vscode/src/KiloProvider.ts#L987-L1019) — `attachToWebview`, handler setup, interception, and routing.
-- [`KiloProvider.ts`](https://github.com/Kilo-Org/kilocode/blob/main/packages/kilo-vscode/src/KiloProvider.ts#L1013-L1040) — inbound message handling and dispatch.
-- [`extension.ts`](https://github.com/Kilo-Org/kilocode/blob/main/packages/kilo-vscode/src/extension.ts#L137-L143) — sidebar Webview registration.
-
-The Webview bridge is **structured local message passing across the VS Code extension/Webview boundary**. It is not HTTP RPC, LSP, or RPA.
-
-### 1.3 The extension spawns a local backend
-
-The current code explicitly documents that the CLI backend starts lazily rather than during extension activation:
-
-> “The CLI backend is NOT spawned here; it starts lazily when a webview connects or when ensureBackendForAutocomplete() triggers it.”
-
-Source: [`packages/kilo-vscode/src/extension.ts`](https://github.com/Kilo-Org/kilocode/blob/main/packages/kilo-vscode/src/extension.ts#L45-L49).
-
-The server manager starts a local CLI process with an ephemeral port:
-
-- [`server-manager.ts`](https://github.com/Kilo-Org/kilocode/blob/main/packages/kilo-vscode/src/services/cli-backend/server-manager.ts#L92-L120) — spawns `cliPath serve --port 0` with a workspace-derived cwd.
-- [`server-manager.ts`](https://github.com/Kilo-Org/kilocode/blob/main/packages/kilo-vscode/src/services/cli-backend/server-manager.ts#L118-L161) — passes environment, including `KILO_SERVER_PASSWORD`, parent PID, VS Code metadata, and `stdio: ["ignore", "pipe", "pipe"]`.
-- [`server-manager.ts`](https://github.com/Kilo-Org/kilocode/blob/main/packages/kilo-vscode/src/services/cli-backend/server-manager.ts#L167-L177) — reads child stdout and parses the selected port.
-
-This is a **local child process plus local server** architecture. It is RPC-like in the broad sense, but it is not RPA.
-
-### 1.4 HTTP/API client and SSE events
-
-`KiloConnectionService` owns one backend manager, one Kilo SDK client, and one SSE adapter for multiple UI providers:
-
-- [`connection-service.ts`](https://github.com/Kilo-Org/kilocode/blob/main/packages/kilo-vscode/src/services/cli-backend/connection-service.ts#L80-L99) — describes and declares the shared service, client, and SSE adapter.
-- [`connection-service.ts`](https://github.com/Kilo-Org/kilocode/blob/main/packages/kilo-vscode/src/services/cli-backend/connection-service.ts#L149-L150) — lazy startup/connection entrypoint.
-- [`types.ts`](https://github.com/Kilo-Org/kilocode/blob/main/packages/kilo-vscode/src/services/cli-backend/types.ts#L1-L20) — server configuration includes `baseUrl` and `password`.
-
-The extension checks backend health over HTTP with Basic authentication:
-
-- [`connection-service.ts`](https://github.com/Kilo-Org/kilocode/blob/main/packages/kilo-vscode/src/services/cli-backend/connection-service.ts#L733-L777) — periodic `GET ${baseUrl}/global/health`, `Authorization: Basic ...`, and reconnect behavior.
-
-Thus the current Kilo architecture is more accurately:
-
-```text
-VS Code Webview
-   │ postMessage / onDidReceiveMessage
-   ▼
-Kilo extension host
-   │ Kilo SDK over authenticated localhost HTTP
-   │ SSE event stream
-   ▼
-local `kilo serve --port 0` process
-   │
-   ├─ model/provider APIs
-   ├─ sessions/tools/filesystem
-   └─ MCP clients
-```
-
-### 1.5 WebSockets are feature-specific, not the basic UI bridge
-
-The repository has WebSocket use for feature-specific paths. For example, the Agent Manager terminal routes PTY bytes over a WebSocket rather than through Webview messages:
-
-- [`terminal-manager.ts`](https://github.com/Kilo-Org/kilocode/blob/main/packages/kilo-vscode/src/agent-manager/terminal-manager.ts#L1-L10) — describes PTY output over `/pty/:id/connect` WebSocket.
-- [`terminal-routing.ts`](https://github.com/Kilo-Org/kilocode/blob/main/packages/kilo-vscode/src/agent-manager/terminal-routing.ts#L242-L248) — builds an authenticated loopback WebSocket URL with `auth_token`.
-- [`event-service-client.ts`](https://github.com/Kilo-Org/kilocode/blob/main/packages/kilo-vscode/src/kiloclaw/event-service-client.ts#L1-L10) — cloud event-service ticket flow and WebSocket subprotocol.
-
-This demonstrates that Kilo chooses transport by use case: Webview messages for UI commands/state, HTTP/SSE for backend API/events, and WebSocket for high-volume or cloud event paths.
-
-### 1.6 MCP is an integration protocol, not the extension connection
-
-Kilo's MCP code imports multiple official MCP SDK transports:
-
-- [`packages/opencode/src/mcp/index.ts`](https://github.com/Kilo-Org/kilocode/blob/main/packages/opencode/src/mcp/index.ts#L15-L19) — `StreamableHTTPClientTransport`, `SSEClientTransport`, and `StdioClientTransport`.
-- [`packages/opencode/src/mcp/index.ts`](https://github.com/Kilo-Org/kilocode/blob/main/packages/opencode/src/mcp/index.ts#L369-L389) — local MCP config launches a command using `StdioClientTransport` with cwd/environment.
-
-MCP lets the coding agent connect to tools/resources exposed by configured MCP servers. It does **not** appear to be the protocol connecting Kilo's VS Code Webview to its extension host. Those are separate layers.
-
-## 2. Is it RPA, LSP, RPC, or something else?
-
-| Technology | Kilo role | Conclusion |
-|---|---|---|
-| RPA (Robotic Process Automation) | None identified as a framework/protocol | No. Agentic file/terminal/browser automation is not conventional RPA architecture. |
-| VS Code Extension API | Activation, commands, views, workspace, terminals, Webviews | Yes; foundational. |
-| Webview message bridge | UI ↔ extension host messages | Yes; local structured messaging. |
-| Local child process | Extension starts `kilo serve` | Yes. |
-| HTTP | Extension ↔ local backend API and health checks | Yes; authenticated localhost API. |
-| SSE | Backend event stream to extension | Yes. |
-| WebSocket | PTY and selected cloud/event paths | Yes, feature-specific. |
-| MCP | Agent ↔ configured external tools/resources | Yes; separate integration layer. |
-| LSP | Language server/client lifecycle | No evidence of core LSP architecture. |
-| JSON-RPC | Not the main current VS Code connection identified in Kilo | Do not assume this is Kilo's transport. |
-
-## 3. What Selesai already provides
-
-### 3.1 Existing RPC mode
-
-Selesai RPC is a headless JSONL protocol over a child process:
-
-- [`docs/rpc.md`](../rpc.md) — protocol, commands, event stream, extension UI protocol, framing, and client examples.
-- [`src/modes/rpc/rpc-mode.ts`](../../src/modes/rpc/rpc-mode.ts) — server implementation over stdin/stdout.
-- [`src/modes/rpc/rpc-types.ts`](../../src/modes/rpc/rpc-types.ts) — typed commands, responses, events, and extension UI messages.
-- [`src/modes/rpc/rpc-client.ts`](../../src/modes/rpc/rpc-client.ts) — typed subprocess client and request correlation.
-- [`src/rpc-entry.ts`](../../src/rpc-entry.ts) — RPC executable entrypoint.
-
-The transport is strict LF-delimited JSONL. It has request IDs for responses and asynchronous events for streaming output/tool lifecycle. A VS Code extension can spawn:
-
-```text
-selesai --mode rpc --cwd <workspace> [other options]
-```
-
-(or spawn the packaged Node CLI with equivalent arguments), then:
-
-1. Write one JSON object plus `\n` to stdin.
-2. Parse stdout one LF record at a time.
-3. Correlate `type: "response"` records by `id`.
-4. Render `message_update`, `tool_execution_*`, and lifecycle events.
-5. Wait for `agent_settled`/`agent_end`, not merely prompt acceptance.
-6. Answer `extension_ui_request` records when an extension asks for a dialog.
-
-This is sufficient for a local VS Code extension MVP.
-
-### 3.2 Direct SDK option
-
-Selesai also exports a direct TypeScript/Node SDK:
-
-- [`docs/sdk.md`](../sdk.md) — `createAgentSession`, `createAgentSessionRuntime`, event subscription, tools, sessions, cwd, auth, and resources.
-- [`src/core/sdk.ts`](../../src/core/sdk.ts) — SDK options and construction.
-- [`src/index.ts`](../../src/index.ts) — public exports.
-
-A VS Code extension host is itself Node-based, so it can potentially use `createAgentSession()` in-process. Advantages are lower latency, no JSON serialization, direct typed events, and custom tool/resource integration. Disadvantages are tighter coupling, more difficult fault isolation, extension-host memory/lifecycle risk, and the need to manage session replacement and extension binding carefully.
-
-### 3.3 Existing extension system and RPC UI support
-
-Selesai extensions can register tools, commands, event handlers, and UI operations. In RPC mode, dialog and notification UI is translated into an explicit request/response protocol:
-
-- [`docs/extensions.md`](../extensions.md) — extension API and security model.
-- [`docs/rpc.md`](../rpc.md) — `select`, `confirm`, `input`, `editor`, `notify`, status, widget, title, and editor-text requests.
-
-This is a useful foundation for mapping agent permission questions to VS Code dialogs, status bar items, notifications, and editor input.
-
-## 4. Selesai versus Kilo: capability comparison
-
-| Capability | Kilo current approach | Selesai current position | Assessment |
-|---|---|---|---|
-| VS Code package | Dedicated `packages/kilo-vscode` extension | No dedicated VS Code extension found in this repository | Kilo leads on product packaging. |
-| Main UI | Multiple Webviews/panels/providers | RPC UI protocol can feed a new Webview | Selesai has protocol primitives; Kilo has finished UI. |
-| Agent backend isolation | Spawned local CLI server | Spawned local RPC process | Both isolate backend; Selesai MVP is simpler. |
-| Backend network API | Authenticated localhost HTTP + SSE | No TCP/HTTP RPC server; stdin/stdout JSONL | Kilo leads for multi-client/network-capable architecture. |
-| Transport auth | Generated password; Basic/loopback auth | No RPC auth handshake; private pipes only | Selesai needs auth before exposing network transport. |
-| Streaming | SSE and WebSocket for relevant paths | JSONL event stream | Both support streaming; Selesai JSONL is easy to adapt. |
-| Sessions | Backend session APIs and shared connection service | Rich RPC/SDK session lifecycle and tree operations | Selesai is strong at protocol-level session control. |
-| Extensions/plugins | Agent/runtime extensions and Kilo services | Extension-first tools/events/UI; RPC-compatible UI | Selesai is potentially more extensible, but needs VS Code UX. |
-| MCP | Local stdio and remote transports | Extension/tool ecosystem exists; MCP parity should be audited separately | Kilo has explicit MCP transport integration. |
-| Terminal/PTy | Dedicated terminal manager and WebSocket streaming | RPC bash exists; no Kilo-equivalent VS Code PTY bridge identified | Kilo leads for native terminal UX. |
-| Trust/security | Backend password and process lifecycle controls | Explicit extension trust exists, but RPC has no auth | Selesai needs a dedicated integration security model. |
-| In-process embedding | Backend/client architecture | First-class SDK | Selesai may be better for tightly integrated custom clients. |
-
-## 5. Feasibility: how to build a Selesai VS Code extension
-
-### Phase 1 — local MVP (recommended first)
-
-Build a conventional VS Code extension with:
-
-```text
-VS Code Webview UI
-       │ vscode.postMessage
-       ▼
-Extension host controller
-       │ child_process / existing RpcClient
-       ▼
-selesai --mode rpc (private stdin/stdout)
-```
-
-Minimum components:
-
-- `ExtensionHostController`: owns one Selesai process per workspace/session.
-- `RpcClientAdapter`: wraps the existing `RpcClient`; add or expose extension UI request handling if the current public client does not already do so.
-- `WorkspaceManager`: resolves workspace cwd, session directory, and project trust.
-- `EventStore`: maps streamed events into Webview state, with bounded history and reconnection handling.
-- `WebviewProvider`: chat, streaming text, tool calls, approval questions, model picker, session picker.
-- `Command` registrations: open sidebar, new session, abort, steer, follow-up, model selection.
-- `dispose()` handling: send shutdown/EOF, wait briefly, terminate if necessary.
-
-This does **not** need RPA, LSP, MCP, or a network server.
-
-### Phase 2 — native VS Code experience
-
-Add the features that make an extension feel better than a terminal wrapper:
-
-- Inline editor selection/context actions (“Ask Selesai about this”, “Fix this”).
-- Diff-aware edit review using VS Code `WorkspaceEdit` or controlled file edits.
-- Native permission prompts for writes, shell commands, and external tools.
-- Diagnostics/code actions where agent output can be represented safely.
-- Native terminal/task integration and cancellation.
-- Status bar progress, notifications, output channel, and session restoration.
-- Workspace-specific context files and explicit trust prompts.
-- Webview state restoration and multiple workspace/session routing.
-
-### Phase 3 — Kilo-like backend facade (only if needed)
-
-If Selesai needs multiple clients, remote control, or richer WebSocket/SSE behavior, add an authenticated local server mode rather than exposing raw stdin/stdout through an ad-hoc bridge.
-
-Suggested shape:
-
-```text
-VS Code extension ── authenticated HTTP/SSE or WebSocket ── Selesai server
-```
-
-Requirements before shipping:
-
-- Bind to loopback by default, never `0.0.0.0` by accident.
-- Generate a high-entropy per-process secret.
-- Require authentication on every endpoint/stream.
-- Scope sessions and cwd to the requesting workspace/client.
-- Validate origin and reject cross-workspace access.
-- Provide process parent watchdog and graceful shutdown.
-- Avoid leaking session paths, API keys, prompts, or tool output in logs.
-- Define protocol versioning and event replay/reconnect semantics.
-- Add rate limits and explicit authorization for destructive operations.
-
-## 6. Key risks and design decisions
-
-### Security
-
-Selesai's RPC stdin/stdout is relatively safe because it is private to the spawned child process. It has no token, handshake, or authorization layer. It must **not** simply be put behind a TCP port. A Kilo-like server facade needs authentication, loopback binding, workspace isolation, and process lifecycle controls.
-
-Selesai extensions execute with full system permissions, as documented in [`docs/extensions.md`](../extensions.md). The VS Code extension should not silently enable untrusted project-local extensions or resources. Mirror VS Code's workspace trust decision in the agent startup path.
-
-### Prompt completion versus acceptance
-
-RPC prompt acceptance is not completion. The UI must track the asynchronous event stream and mark a run complete only on the settled/end lifecycle event. This is essential for streaming text, tool progress, approval prompts, and cancellation.
-
-### RPC UI limitations
-
-RPC mode supports dialogs and simple status/widget notifications but not all TUI capabilities. A VS Code adapter needs to decide how to map or replace unsupported methods such as custom TUI components, terminal raw input, and theme-specific rendering.
-
-### Process versus in-process SDK
-
-Use RPC first when reliability and isolation matter. Use the SDK when the extension needs deep typed access and can own the agent lifecycle. A hybrid is possible: keep the default backend out-of-process, offer an in-process mode for development/advanced integrations.
-
-### Multi-root workspaces
-
-Both resource discovery and tool paths depend on cwd. The extension must choose and persist a workspace root/session mapping rather than relying on the extension host's process cwd. For multi-root workspaces, each session should carry an explicit workspace directory.
-
-## 7. Recommended product strategy
-
-Selesai can be “similar or better than Kilo” if it focuses on its existing strengths instead of copying every transport immediately:
-
-1. **Ship a focused Webview extension over existing RPC.** This delivers value quickly and preserves process isolation.
-2. **Use Selesai's extension-first model as the differentiator:** custom tools, lifecycle hooks, prompt/context injection, subagents, workflows, and provider customization.
-3. **Provide native approvals and diffs**, rather than exposing a terminal transcript inside a Webview.
-4. **Add robust session restoration and workspace routing.** Selesai's RPC/session APIs already provide a good base.
-5. **Add an authenticated HTTP/SSE server only when remote/multi-client requirements justify it.** Do not introduce a network daemon solely to imitate Kilo.
-6. **Add MCP transport parity deliberately** if tool-server interoperability is a product requirement; keep MCP separate from the VS Code UI protocol.
-
-### Final answer to the user's questions
-
-- **Did Kilo connect using RPA?** No evidence. It uses VS Code APIs, Webview messages, a spawned local CLI backend, authenticated localhost HTTP/SSE, feature-specific WebSockets, and MCP for external tools.
-- **Can Selesai connect through RPC?** Yes. Existing Selesai RPC is a strong local integration seam: strict JSONL over a private child process with typed commands/events and extension UI requests.
-- **Can Selesai have a similar or better VS Code extension?** Yes. A local RPC-backed extension is straightforward and likely the right MVP. Selesai can exceed Kilo in extensibility and session/workflow customization, while Kilo currently has an advantage in mature VS Code UX, native terminal/PTY integration, backend HTTP/SSE, and polished multi-provider UI.
-
-## Primary-source references
-
-### Kilo Code
-
-- [Extension activation](https://github.com/Kilo-Org/kilocode/blob/main/packages/kilo-vscode/src/extension.ts)
-- [Kilo Webview provider](https://github.com/Kilo-Org/kilocode/blob/main/packages/kilo-vscode/src/KiloProvider.ts)
-- [CLI server manager](https://github.com/Kilo-Org/kilocode/blob/main/packages/kilo-vscode/src/services/cli-backend/server-manager.ts)
-- [Shared backend connection service](https://github.com/Kilo-Org/kilocode/blob/main/packages/kilo-vscode/src/services/cli-backend/connection-service.ts)
-- [Backend server config](https://github.com/Kilo-Org/kilocode/blob/main/packages/kilo-vscode/src/services/cli-backend/types.ts)
-- [MCP transports](https://github.com/Kilo-Org/kilocode/blob/main/packages/opencode/src/mcp/index.ts)
-- [PTY WebSocket routing](https://github.com/Kilo-Org/kilocode/blob/main/packages/kilo-vscode/src/agent-manager/terminal-routing.ts)
-- [PTY WebSocket manager](https://github.com/Kilo-Org/kilocode/blob/main/packages/kilo-vscode/src/agent-manager/terminal-manager.ts)
-
-### Selesai Code
-
-- [`docs/rpc.md`](../rpc.md)
-- [`docs/sdk.md`](../sdk.md)
-- [`docs/extensions.md`](../extensions.md)
-- [`src/modes/rpc/rpc-mode.ts`](../../src/modes/rpc/rpc-mode.ts)
-- [`src/modes/rpc/rpc-types.ts`](../../src/modes/rpc/rpc-types.ts)
-- [`src/modes/rpc/rpc-client.ts`](../../src/modes/rpc/rpc-client.ts)
-- [`src/core/sdk.ts`](../../src/core/sdk.ts)
-- [`src/index.ts`](../../src/index.ts)