@selesai/code 0.9.0 → 0.9.2

package/CHANGELOG.md

@@ -2,6 +2,16 @@
 
 All notable changes to `@selesai/code` will be documented in this file.
 
+## [0.9.2] - 2026-08-20
+
+### Fixed
+- **Token-In premium model availability.** Restore the bundled `auto-premium` model so existing premium model selections continue to resolve while the default remains the supported `tokenin/auto:max`.
+
+## [0.9.1] - 2026-08-20
+
+### Fixed
+- **Token-In model defaults.** Use the supported `auto` model for the main session and core subagent roles, remove the unsupported `auto-premium` default, and update its bundled context window to 384K.
+
 ## [0.9.0] - 2026-08-20
 
 ### Added

package/dist/defaults/models.json

@@ -15,7 +15,7 @@
           "name": "Auto",
           "reasoning": true,
           "input": ["text"],
-          "contextWindow": 256000,
+          "contextWindow": 393216,
           "maxTokens": 64000,
           "thinkingLevelMap": {
             "minimal": null,
@@ -28,10 +28,10 @@
         },
         {
           "id": "auto-premium",
-          "name": "Auto Premium",
+          "name": "Auto",
           "reasoning": true,
           "input": ["text"],
-          "contextWindow": 256000,
+          "contextWindow": 393216,
           "maxTokens": 64000,
           "thinkingLevelMap": {
             "minimal": null,

package/dist/defaults/settings.json

@@ -9,7 +9,7 @@
     "keepRecentTokens": 32000,
     "reserveTokens": 64000
   },
-  "defaultModel": "auto-premium",
+  "defaultModel": "auto",
   "defaultProvider": "tokenin",
   "defaultThinkingLevel": "max",
   "doubleEscapeAction": "tree",
@@ -44,13 +44,13 @@
   "subagents": {
     "agentOverrides": {
       "architect": {
-        "model": "tokenin/auto-premium:max"
+        "model": "tokenin/auto:max"
       },
       "builder": {
-        "model": "tokenin/auto-premium:max"
+        "model": "tokenin/auto:max"
       },
       "commentator": {
-        "model": "tokenin/auto-premium:max"
+        "model": "tokenin/auto:max"
       },
       "explorer": {
         "model": "tokenin/auto:max"

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

@@ -0,0 +1,319 @@
+# 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)

package/package.json

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